3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly.<p>5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is <i>also</i> difficult. A big part of the pushback from people over systemd is that it <i>also</i> replaced syslog, and did so with its own custom binary log format. To quote from a forum thread I started shortly after updating my old system to systemd, "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." (I ended up abandoning that distribution altogether after that and a number of other frustrations, and the response from the forums.)<p>13. The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to <i>require</i> systemd, making that software difficult (or impossible) to port to BSD.<p>14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work.<p>15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again?<p>19. systemd may not "force" you to do anything, up until your distribution adopts it, pushes it as an update, and then you find yourself spending hours trying to figure out how to troubleshoot a problem that didn't exist before the update. Then it certainly <i>is</i> forcing you to do something.<p>Here's the problem in a nut shell as I see it: if systemd had been the default in Linux for the last ten years, probably the tool chain around it would be mature enough to meet everyone's needs, we would all be accustomed to the specific commands needed to control and interact with and debug systemd stuff, and if someone came along and proposed replacing everything with a syslog daemon and a pile of init scripts, there'd be rage and outcry. That is to say, I don't see anything <i>inherently</i> bad about systemd.<p>But, what <i>is</i> enormously frustrating is to have something that works, and be well adapted to it, so that if something breaks I know exactly where to look, and then have all of that be replaced by a foreign system that breaks old things in new ways and requires hours spent trying to figure out what the hell happened.<p>If the replacement system offers serious benefits over the old system, that offsets the pain slightly. In this case, I've yet to see what the actual benefits are; I have no idea what problems systemd is attempting to solve which are so severe, so immediate, so intractable that they require a jarring change to some of the fundamental parts of the operating system.