> It's dramatically simpler and more intuitive than what it replaced
I hope you're being deeply ironic.
It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.
> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
Read: A confusing mess of different daemons, scripts, and configuration files, which neither worked together elegantly, were simple to configure, nor were easy to debug. Before systemd I would avoid writing custom daemon configurations at all costs because when I did I would need to learn how this version of this distro did it, fiddle with the byzantine mess of scripts, and inevitibly debug multiple subtle issues, now it's basically trivial to get a new daemon running, and I extremely rarely need to debug issues (And I have had to track down systemd bugs due to obscure use cases like one systemd unit modifying other systemd unit configs at the same time another systemd unit with multiple execstart lines is running).
I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user.
With systemd? 5 lines or so of boilerplate, independent of distro.
Depending how you look?
Here is a great example: disable the service before installing -- i.e. make sure that even if someone installs the service, it won't get activated.
On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.
rleigh|5 years ago
I hope you're being deeply ironic.
It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.
jcelerier|5 years ago
As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
rcxdude|5 years ago
Read: A confusing mess of different daemons, scripts, and configuration files, which neither worked together elegantly, were simple to configure, nor were easy to debug. Before systemd I would avoid writing custom daemon configurations at all costs because when I did I would need to learn how this version of this distro did it, fiddle with the byzantine mess of scripts, and inevitibly debug multiple subtle issues, now it's basically trivial to get a new daemon running, and I extremely rarely need to debug issues (And I have had to track down systemd bugs due to obscure use cases like one systemd unit modifying other systemd unit configs at the same time another systemd unit with multiple execstart lines is running).
downerending|5 years ago
josteink|5 years ago
I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user.
With systemd? 5 lines or so of boilerplate, independent of distro.
I don’t know about you, but I call that simple.
theamk|5 years ago
On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.