I don't know if I qualify as an "end user" to you, but I definitely have complaints. I started with an open mind about systemd, because I'm not so attached to any init system in general. So my issue is not that systemd is a monolith or breaks with tradition (sysv init scripts were also a hot mess). My problem is that systemd looks and acts like a freshly written proof of concept that needs to be polished up, but when you dig in to debug a problem you're having, you inevitably end up at bug reports that condescendingly defend the current state of affairs as desired behavior.

"Your issue is user error, because systemd doesn't provide the logical guarantee you want, and adding a hook is outside the scope of systemd." I've run into several instances of this, the worse one being around unit ordering and network interfaces. I eventually solved it with a hack service that put 'sleep 90' between network.target and network-online.target. So much for that startup parallelism.

Another issue is that a dependency loop will cause it to just randomly drop units. There's no insight into this until you notice it happening and go digging. In the abstract, yes there is nothing else systemd could do apart from refuse to boot. Except the problem has only been dragged into the abstract by using a configuration model that punts on real world concerns.

Both of these are exacerbated by magic processes that half-parse crypttab/fstab/interfaces to create runtime units. I don't know if these are from Debian or the upstream. But if the systemd way is better, why haven't those been fully moved to native systemd?

> Debian and Fedora apparently decided

That's not how I remember it. Fedora was pushed to adoption (thread starter characterises it as an internal "power play"), and Debian was presented a fait accompli (article summarises Russ Allbery with "[not] systemd-vs-the-alternatives, but how-much-of-systemd").

> And I never heard an end user complain.

This is ridiculous! I can also claim the world is always dark when I shut my eyes.

Linux mailing lists are full with complaints. A recurring one was an error message that suggests running a command as remedy, only for that command to also error out. (The remedy was formulated wrong.) By then, systemd already had a version number in the hundreds.

It is even easier with daemontools, which is much more lightweight and follows the Unix philosophy.

But somehow distro maintainers can never integrate djbware for political reasons. In the case of RedHat, also NIH syndrome.

The article did a good job articulating that the "end users" of an init system aren't sysadmins, they're distro maintainers. If most distros have switched then it must make things better for them.

Exactly, my biggest problem with the systemd complainers is that it's all kind of abstract things, like it's not the Unix philosophy, which in practice doesn't mean much and certainly doesn't automatically mean it's a bad thing.

SysVinit was a horrible, inconsistent mess of bash scripts of per-individual-developer variations in quality and not insignificant variations between distros, or even individual services within the same disto, I wouldn't hold that as the cornerstone of the Unix philosophy, that is if one's intention is to paint it in a positive light.