Great answer. I do use systemd boot on one of my systems as well. It isn’t exactly systemd itself is it? Simply a boot loader packaged as part of the general systemd boot suite, right?
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)
Yeah exactly. It does have some features that require integration with the init system, which systemd obviously supports, but it could be used independently of systemd quite happily, and other init systems could easily support those integrations.
Great answer. I do use systemd boot on one of my systems as well. It isn’t exactly systemd itself is it? Simply a boot loader packaged as part of the general systemd boot suite, right?
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)
Yeah exactly. It does have some features that require integration with the init system, which systemd obviously supports, but it could be used independently of systemd quite happily, and other init systems could easily support those integrations.