It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file.
It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
And all the system managers that followed UNIX philosophy failed in being as straight forward as systemd, you know, the whole point of that Unix philosophy is to be more straight forward
It works, and it works well. It does what it says on the tin. It brings together multiple disparate functionalities to a level that most end users need, while also having the ability to replace a lot of those functionalities (systemd-resolved, systemd-networkd, systemd-timesyncd as examples) with other services if that's what your deployment needs.
It replaces the old style of services being just a bunch of shell scripts that ran one after another. It provides a consistent interface to configure, start, stop, restart, enable, disable, and monitor those services. It allows dynamism by creating service templates, allowing you to launch six different variants of a service using the same base service configuration.
It also allows you to take advantage of a lot of Linux's security features, by implementing service-level restrictions on filesystems, network access, user IDs, PIDs, and so on. It even provides the ability to listen on a socket and pass connections to a process, meaning you could have a network-listening daemon that doesn't even actually have access to your network.
It provides cgroup integration so that you can limit the resources provided to an individual service so that you can prevent one process from causing issues with the rest of your hardware. It can even point a service at a separate root directory, essentially chrooting a service before it even starts.
It provides tooling so that individual services can interact with one another, and so that user-space tooling (either theirs or a custom d-bus client) can interact with services, and provides functionality for validating whether or not the user has permissions to do so. It also provides functionality to easily override configuration in override files, allowing you to make local changes without changing the files that were distributed, making it easy to debug whether it's your changes or not that are causing an issue, or to test changes without worrying about putting things back.
It eliminates the issues of having multiple different services, often either conflicting or overlapping, to provide the things it provides. Multiple separate configuration files, configuration syntaxes, and so on. It eliminates the need for distros to create config generation tooling to produce the right config files to tie each service together, and then write their own daemons or cronjobs to check each of them for changes.
And all of this functionality is, essentially, optional. I can do a hundred different things with a service file, but I don't have to; I can basically write a service file in ten lines of ini-compatible configuration, using (and being aware of) none of that functionality, and it works fine, or I can write a service file that locks a service into its own network, with no access to the existing filesystem, only the most basic entries in /dev, only the files it needs in /etc, limited by seccomp filters, using systemd's watchdog functionality to restart it if it hangs or gets overloaded, limiting it to specific CPU cores and changing CPU and IO weighting, limiting the number of processes that it can create, and even filtering which system calls it's allowed to use.
In short, it's a system that can be very easy to use and start working with, but provides more functionality and complexity than I think almost anyone realizes. It's the most capable and simplest way of handling system services, and the extra pieces just make it less complex to add functionality like network management, name lookups, boot management, and so on to your system if all you need is the basics.
It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file.
It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
Just saw Lennart Poettering speak at Fosdem and perhaps it’s even more Unix-y then system V init :)
And all the system managers that followed UNIX philosophy failed in being as straight forward as systemd, you know, the whole point of that Unix philosophy is to be more straight forward
Here, "system managers" and "straight forward" are pretty loaded terms...
I'll elaborate on this if you like.
It works, and it works well. It does what it says on the tin. It brings together multiple disparate functionalities to a level that most end users need, while also having the ability to replace a lot of those functionalities (systemd-resolved, systemd-networkd, systemd-timesyncd as examples) with other services if that's what your deployment needs.
It replaces the old style of services being just a bunch of shell scripts that ran one after another. It provides a consistent interface to configure, start, stop, restart, enable, disable, and monitor those services. It allows dynamism by creating service templates, allowing you to launch six different variants of a service using the same base service configuration.
It also allows you to take advantage of a lot of Linux's security features, by implementing service-level restrictions on filesystems, network access, user IDs, PIDs, and so on. It even provides the ability to listen on a socket and pass connections to a process, meaning you could have a network-listening daemon that doesn't even actually have access to your network.
It provides cgroup integration so that you can limit the resources provided to an individual service so that you can prevent one process from causing issues with the rest of your hardware. It can even point a service at a separate root directory, essentially chrooting a service before it even starts.
It provides tooling so that individual services can interact with one another, and so that user-space tooling (either theirs or a custom d-bus client) can interact with services, and provides functionality for validating whether or not the user has permissions to do so. It also provides functionality to easily override configuration in override files, allowing you to make local changes without changing the files that were distributed, making it easy to debug whether it's your changes or not that are causing an issue, or to test changes without worrying about putting things back.
It eliminates the issues of having multiple different services, often either conflicting or overlapping, to provide the things it provides. Multiple separate configuration files, configuration syntaxes, and so on. It eliminates the need for distros to create config generation tooling to produce the right config files to tie each service together, and then write their own daemons or cronjobs to check each of them for changes.
And all of this functionality is, essentially, optional. I can do a hundred different things with a service file, but I don't have to; I can basically write a service file in ten lines of ini-compatible configuration, using (and being aware of) none of that functionality, and it works fine, or I can write a service file that locks a service into its own network, with no access to the existing filesystem, only the most basic entries in /dev, only the files it needs in /etc, limited by seccomp filters, using systemd's watchdog functionality to restart it if it hangs or gets overloaded, limiting it to specific CPU cores and changing CPU and IO weighting, limiting the number of processes that it can create, and even filtering which system calls it's allowed to use.
In short, it's a system that can be very easy to use and start working with, but provides more functionality and complexity than I think almost anyone realizes. It's the most capable and simplest way of handling system services, and the extra pieces just make it less complex to add functionality like network management, name lookups, boot management, and so on to your system if all you need is the basics.
it's a good argument