Systemd: The Biggest Myths

One reason is that pulseaudio broke audio for many Linux users (including me). Linux audio has long been problematic but had reached a point of stability when pulseaudio was adopted by some of the major distributions. I have no idea if the problem was that pulseaudio was broken, with distributors messing up, or with Linux audio drivers.

When a problem is easily solved by just an "apt-get remove X" it is easy to start hating the piece of software. No matter who was actually at fault.

I remember watching this video and Poettering's argument were very sound and he has managed to repel most (if not all) Draxinger's points.

The problem with "it's not the UNIX way" argument is that a lot of people don't care about UNIX that much, they just want a good system. Poettering mentions in that video that all his, and his colleagues' work (pulseaudio, consolekit, udev into udisks/upower) has been done because there was an actual demand for those features. There is a reason why most distributions use their work even as people complain about them.

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.

5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also 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.)

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 require systemd, making that software difficult (or impossible) to port to BSD.

14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work.

15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again?

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 is forcing you to do something.

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 inherently bad about systemd.

But, what is 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.

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.

There are currently 23946[1] FreeBSD ports. Nothing I ever needed in the last 15 years of using FreeBSD was missing. Yes, dependency on glibc and the Linux kernel is sometimes annoying, but in practice it is not an insurmountable problem. Dependency on the Linux kernel is rare and dependency on glibc can usually be easily fixed and upstream is usually happy to accept patches. Systemd is different because there is a lot of software that might decide to use it and you can't just work around it.

[1] http://www.freebsd.org/ports/

You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax.

To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd services look as if they are a lot less boiler-plate than the typical debian init-script.

https://wiki.archlinux.org/index.php/Systemd/Services (e.g. dropbear is very simple)