>>38 I disagree.

I have used systemd ever since it entered SID (back when wheezy was testing). It has nice, consistent command line tools and usefully pretty-printed output. It replaces the System V runlevels with more intuitive targets. And it is an absolutely awful idea.

Where tools like insserv compute dependencies and adjust the order of start and parallelisation whenever a job is added, systemd does it during the boot. And it uses lazy evaluation, which is a good thing in principle, because it means that only jobs that need to be started are started. And systemd starts them only as soon as they are called for, which means that as soon as a connection is made to port 443, systemd launches the web server, which launches its modules, one if which is PHP, which requires the fastgci spawner, and also the MySQL database, which upon launching performs a self test and clean-ups and replays transactions as needed, whereupon it may or may not be ready to serve the request of the CMS written in PHP to refrech the page cache for the apache, so that the reqeust on port 443 can finally be served, long after it has timed out. That is called socket based activation, and it makes your boot so much faster, after backtracking through the dependencies as late as possible has made that moot.

But at least it is not sysvinit with its abominable inittab.

One nice feature about systemd is that it communicates via named pipes. When the pipes are out of sync, or otherwise break, it only requires restarting systemd to re-initialize them, and with systemd as PID 1, that means rebooting the entire system. Which you can do easily with systemd, as long as the pipes are in sync. Fortunately, the pipes breaking only happened on my system a couple of times. I really appreciate how systemd made the reset button shine, and well worth the investment after I hadn't used it for almost a decade. I don't know what I would have done had I tested systemd on a remote system.