5 ms·

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep rep

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

nlgza 7y ago
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.
AsyncAwait 7y ago
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.
mprovost 7y ago
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.
- AnthonyMouse 7y ago
  The problem, of course, being that for most init systems the "end users" are the distro maintainers but for systemd, because it spreads itself into so many other things, it also impacts the sysadmins and the upstream third party package developers. Who then complain about it and are met with "it was good enough for Debian and Fedora" even though they aren't the ones complaining.
bmn__ 7y ago
> 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.
mindslight 7y ago
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?

nlgza 7y ago

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.

AsyncAwait 7y ago

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.

mprovost 7y ago

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.

AnthonyMouse 7y ago
The problem, of course, being that for most init systems the "end users" are the distro maintainers but for systemd, because it spreads itself into so many other things, it also impacts the sysadmins and the upstream third party package developers. Who then complain about it and are met with "it was good enough for Debian and Fedora" even though they aren't the ones complaining.

bmn__ 7y ago

> 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.

mindslight 7y ago

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?