> Honestly, sysvinit and the existing userspace does all I need it to do. The extra benefits systemd offers I can do using existing tools. Need to reliably kill a service? Use the cgroups tools and put the service into its own cgroup, and then kill all processes in the cgroup later. Need tamper-evident logging? Use the rsyslog tools. Need dependency-based boot? insserv has got you covered. Need automatic device-node creation, and the ability to run programs based on device events? udev did this just fine before systemd.

And yet nothing integrated all those features well enough to get people to widely adopt them. systemd services make it trivial to run a process in its own cgroup, isolate it, log everything about it, activate services as needed, and manage and track services launched in response to devices. There's nothing stopping you from building your own Linux distribution that integrates all of those tools, and there are certainly enough systemd opponents to try. If they build something compelling, people might use it.

(Also, insserv doesn't come close to the parallel boot that systemd enables, via socket activation, bus activation, and similar. If B and C depend on A, insserv lets you start B and C in parallel, but systemd lets you start A, B, and C in parallel.)

> Systemd's components are tightly-coupled. How, pray tell, do I run logind without systemd as PID 1? How, pray tell, do I remove journald? Oh, that's right. I can't. By design. That makes it monolithic.

To run logind without systemd, you can wait for the cgmanager folks to provide an implementation of equivalent cgroup management functionality for logind to use. Until then, your complaint is much like the complaints about systemd not running on Linux: Linux has features other OSes don't, and systemd intentionally takes advantage of them, "by design". Does that make the combination of systemd and the Linux kernel "monolithic"?

This is "by design" in much the same way that a program using features from Python 2.7 that don't work in Python 2.6 does so "by design". And it's perfectly reasonable for a project to refuse patches for compatibility with Python 2.6 and say "upgrade to 2.7". Just like it's perfectly reasonable for some projects to say "run Linux" or "run systemd", because it has features that nothing else does.

> By contrast, X.org and Xfree86 (an example from the article) were largely interchangeable.

They were in the start, when X.org initially forked from the XFree86 codebase. But today, you cannot drop XFree86 underneath a modern desktop environment and expect it to work; it'll complain about the myriad X extensions introduced in X.org to make those desktop environments possible. And yet, nobody noticed, because nobody cares about XFree86 anymore.