5 ms·

Folks who evangelise these "just as good as systemd" solutions always hide a key factor. There is a reason systemd took over, its massively supported and widel

Folks who evangelise these "just as good as systemd" solutions always hide a key factor. There is a reason systemd took over, its massively supported and widely tested.

actionfromafar 2y ago
It couldn't be massively supported until it took over, though? It's more than a little platform effect going on, it's not all by virtue of systemd being just all over great. It has some great ideas but it's an entire world unto itself which feels very NIH-ish. Edit: I think it serves as both a warning and an inspiration. Don't let a duct tape solution (such as for instance boot via rc shell files) live for too long, or it might be replaced by something baroque.
- trueismywork 2y ago
  Ideas are just 1% if implementation. Systemd (while being a little problematic in beginning) has had huge amount of amazing work being done in it.
  - p_l 2y ago
    Doesn't mean the result is all that good. Having dealt with it for some time now, the amount of "good idea, bad implementation" I hit is too damn high. And it's nigh impossible to replace for various reasons, including at one point critical interfaces that various user-important programs depended on being a constant treadmill of updates, lack of documentation, and hidden dependencies on internals.
    - awilfox 2y ago
      It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made. And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well. At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people. Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.
    - btreecat 2y ago
      Do you have specific examples or just general grievances rehashing past claims?
      - actionfromafar 2y ago
        Can't specific examples be rehashes of past grievances? It hasn't changed much. The log is annoying and sometimes freezes while it compresses or something, for instance. That's old.
        happymellon 2y ago
        Depends on whether its already been resolved?
      - p_l 2y ago
        Various, but don't have time to rehash all of them - the following are just things that I was either bitten by fresh or constantly suffered from in last year: - The utterly broken in places interface (one of the worst offenders is systemctl show non-existing-unit dumping you a screenful of systemd unit parameters instead of "this unit does not exist") - Bonkers defaults the moment you step outside of the minimum case for new unit - spent ridiculous amount of time dealing with that trying to make a self-restarting service with sane values for restart timer etc. - Lack of documentation resulting in having to read the source code (which is horrible code, IMO), which I can only figure as being result of built-in assumption that any resource consumed by systemd is exclusively for systemd use. Which causes problems sometimes (my specific case was totally undocumented values used by systemd secrets mechanism wrt to TPM2, which caused hard to diagnose errors)
- mardifoufs 2y ago
  But systemd was already widely supported not even 2 or 3 years after its original release. The reason it built its network effect is because it was better. Sure, a lot of it is also due to the classic Redhat NIH and their marketing push for their own solutions regardless of if other stuff already exists, but in this specific case systemd was also very very useful from the get go.
- nineteen999 2y ago
  It wasn't widely tested until it took over either.
DaSHacka 2y ago
The improved boot times are likely largely due to systemd's parallelization, OpenRC's support is buggy and OpenRC overall is known to be quite slow. Thankfully, there are plenty of other non-systemd inits besides OpenRC :)
mrfinn 2y ago
Yes, it's massively sponsored as well. So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition.
- SubjectToChange 2y ago
  People seem to not appreciate that Lennart Poettering managed to get systemd from concept to shipping in RHEL 7 in under four years. At that point I'm not even sure anyone at Red Hat had even asked for it, they had already transitioned to Upstart for RHEL 6 after all. Whatever your opinion of Poettering may be, you have to admit that he has tenacity. So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition. There is a substantial selection bias in the complaints towards systemd. At the very least it seems that Red Hat's customers didn't have a problem with it. For most Linux users, it was a minor change, but for distro maintainers it was a massive relief[1]. Again, Lennart Poettering actually took the initiative to develop systemd and get it adopted. By comparison, detractors of systemd did not develop a competitive alternative. Thus, it's hardly a surprise that systemd ended up steamrolling the competition. Ultimately systemd is what users deserve because no person or company bothered to make something better. [1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
  - bluGill 2y ago
    There is a lot to hate about systemd, but in the end anything like it is very hard and few people have the time/energy to attempt something.
  - izacus 2y ago
    As it happens way too commonly, the loudest in OSS communities are ones that have zero stake in building or maintaining the projects they criticize. It's easy to just rant if everyone else has to pick up the extrenalities.
    - actionfromafar 2y ago
p_l 2y ago
The inflection point was GNOME 3.8 not working properly with anything other than systemd and it being night impossible to implement compatible alternatives for some of the interfaces involved.
- djbusby 2y ago
  Right! If you wanted new Gnome you needed systemd - illusion of choice.
blueflow 2y ago
Systemd always is ahead with new features. Which is nice if its a feature you need, and double worse if it crashes your machine, like logind sending your machine into a bugged suspend. Which makes systemd linuxes unusable for newbies on some hardware. I used OpenRC because, not knowing about logind.conf, i had no other choice.
USiBqidmOOkAqRb 2y ago
Yet systemd doesn't have an equivalent to runit's sv once. Also, everything's so opaque that I can't figure out why nftables ruleset isn't loaded on boot, but systemctl restart works correctly (all on Ubuntu 24 server without any kind of frills added).
- rascul 2y ago
  > Yet systemd doesn't have an equivalent to runit's sv once. I'm not familiar with runit. Is this approximately equivalent to 'systemctl start service' when service uses the default of Restart=no ?
  - USiBqidmOOkAqRb 2y ago
    Yes, but, as the name implies, only once, and selectively at runtime. If you have a service and issue sv once on it, it will not be restarted, but its configuration is not changed so it will run normally after system restart.
    - XorNot 2y ago
      That's a one-shot service[1]. RemainAfterExit=yes is what achieves the effect (i.e. if the process terminates it is regarded as still active for system-dependency purposes / status unless you purposefully mark it otherwise). [1] https://www.redhat.com/sysadmin/systemd-oneshot-service https://www.redhat.com/sysadmin/systemd-oneshot-service
- vidarh 2y ago
  > Yet systemd doesn't have an equivalent to runit's sv once. It's a design difference - systemd assumes services know whether they are intended to run once or restart under various conditions. If you want that behaviour it's just a matter of a tweak to the .service file. > Also, everything's so opaque that I can't figure out why nftables ruleset isn't loaded on boot Has it been disabled? ("systemctl enable [service name]" will enable it)
biorach 2y ago
> Folks who evangelise these "just as good as systemd" solutions always hide a key factor. No one in these comments was "evangelising" and no one was hiding anything. If you want to have a technical discussion about the merits of various init systems you can do it without inflammatory language and without reviving debates that almost everybody is sick of
doublerabbit 2y ago
> There is a reason systemd took over, its massively supported and widely tested. Partly due to that it's funded and forced upon by corporate. Any product can excel if resources are available.
- Foxboron 2y ago
  Nobody forced us, Arch Linux, to adopt systemd.
  - hedora 2y ago
    That choice did get me to switch off an arch derivative to Devuan. Also, the purported benefits in this post (which I guess is authoritative for the project?): https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Haven’t panned out for me. 8: logind being repeatedly and completely busted (in 2022-2024) got me to try Debian again. 9: Debian taking 10’s of seconds to boot (just like manjaro), when devuan does it faster than a monitor sync got me to switch to devuan. (And, yes, since logind regularly wedges, I spend lots of time rebooting). Hotplug worked fine for me way before systemd existed, so that’s not a benefit either.
throwaway984393 2y ago
[dead]
cthalupa 2y ago
> There is a reason systemd took over, its massively supported and widely tested. Yes. The people behind it held key positions at Red Hat, freedesktop.org, etc. I'm not calling them some shadowy cabal pulling strings behind the scenes, but it would be silly to discount the political sway the people that started the project have. Being widely-tested also hasn't keep it from producing system bricking issues, such as this debacle just a few months ago: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/pull/33383 https://github.com/systemd/systemd/pull/33383 Or that time that systemd mounted efivarfs as rw making it possible to brick your motherboard https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Or the time back around 2012ish when an update caused the dhcp lease renewal portion to get wedged and took many thousands of servers offline until the service could be manually restarted or the machine rebooted. Or there was that time when OpenSSH was compromised because they pulled in systemd components to handle notifications: https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4 Then there are all the weird choices that are inconsistent with the rest of the ecosystem, like showing asterisks when typing in passwords instead of nothing: https://github.com/systemd/systemd/issues/8495 https://github.com/systemd/systemd/issues/8495 Even formerly simple things like log collection for systems not hooked up to Splunk or similar is now a chore. Most distros not longer include rsyslog by default, and pulling log files out of the journal is a painful process. Before, if I wanted to rip out the past week's logs for analysis, it'd usually mean just grabbing some gzip'ed files that were relatively small in size. Journalctl files are significantly larger in size for similar timeframes. OK, so how about I just interact with the journal directly and tell it to dump just the parts I care about? This is quite resource intensive on smaller VMs running in cloud providers and can severely degrade the overall system performance, so now I have to artificially slow things down and get it piecemeal or schedule it to run during off hours when the performance hit won't matter. I work with systemd daily. It is enough to make me wish I had to work with systemd never. I'm not some sysvinit purist, either - I like SMF on solaris quite a bit!

Folks who evangelise these "just as good as systemd" solutions always hide a key factor. There is a reason systemd took over, its massively supported and widely tested.

actionfromafar 2y ago

It couldn't be massively supported until it took over, though? It's more than a little platform effect going on, it's not all by virtue of systemd being just all over great. It has some great ideas but it's an entire world unto itself which feels very NIH-ish. Edit: I think it serves as both a warning and an inspiration. Don't let a duct tape solution (such as for instance boot via rc shell files) live for too long, or it might be replaced by something baroque.

trueismywork 2y ago
Ideas are just 1% if implementation. Systemd (while being a little problematic in beginning) has had huge amount of amazing work being done in it.
- p_l 2y ago
  Doesn't mean the result is all that good. Having dealt with it for some time now, the amount of "good idea, bad implementation" I hit is too damn high. And it's nigh impossible to replace for various reasons, including at one point critical interfaces that various user-important programs depended on being a constant treadmill of updates, lack of documentation, and hidden dependencies on internals.
  - awilfox 2y ago
    It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made. And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well. At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people. Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.
  - btreecat 2y ago
    Do you have specific examples or just general grievances rehashing past claims?
    - actionfromafar 2y ago
      Can't specific examples be rehashes of past grievances? It hasn't changed much. The log is annoying and sometimes freezes while it compresses or something, for instance. That's old.
      - happymellon 2y ago
        Depends on whether its already been resolved?
    - p_l 2y ago
      Various, but don't have time to rehash all of them - the following are just things that I was either bitten by fresh or constantly suffered from in last year: - The utterly broken in places interface (one of the worst offenders is systemctl show non-existing-unit dumping you a screenful of systemd unit parameters instead of "this unit does not exist") - Bonkers defaults the moment you step outside of the minimum case for new unit - spent ridiculous amount of time dealing with that trying to make a self-restarting service with sane values for restart timer etc. - Lack of documentation resulting in having to read the source code (which is horrible code, IMO), which I can only figure as being result of built-in assumption that any resource consumed by systemd is exclusively for systemd use. Which causes problems sometimes (my specific case was totally undocumented values used by systemd secrets mechanism wrt to TPM2, which caused hard to diagnose errors)
mardifoufs 2y ago
But systemd was already widely supported not even 2 or 3 years after its original release. The reason it built its network effect is because it was better. Sure, a lot of it is also due to the classic Redhat NIH and their marketing push for their own solutions regardless of if other stuff already exists, but in this specific case systemd was also very very useful from the get go.
nineteen999 2y ago
It wasn't widely tested until it took over either.

DaSHacka 2y ago

The improved boot times are likely largely due to systemd's parallelization, OpenRC's support is buggy and OpenRC overall is known to be quite slow. Thankfully, there are plenty of other non-systemd inits besides OpenRC :)

mrfinn 2y ago

Yes, it's massively sponsored as well. So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition.

SubjectToChange 2y ago
People seem to not appreciate that Lennart Poettering managed to get systemd from concept to shipping in RHEL 7 in under four years. At that point I'm not even sure anyone at Red Hat had even asked for it, they had already transitioned to Upstart for RHEL 6 after all. Whatever your opinion of Poettering may be, you have to admit that he has tenacity. So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition. There is a substantial selection bias in the complaints towards systemd. At the very least it seems that Red Hat's customers didn't have a problem with it. For most Linux users, it was a minor change, but for distro maintainers it was a massive relief[1]. Again, Lennart Poettering actually took the initiative to develop systemd and get it adopted. By comparison, detractors of systemd did not develop a competitive alternative. Thus, it's hardly a surprise that systemd ended up steamrolling the competition. Ultimately systemd is what users deserve because no person or company bothered to make something better. [1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
- bluGill 2y ago
  There is a lot to hate about systemd, but in the end anything like it is very hard and few people have the time/energy to attempt something.
- izacus 2y ago
  As it happens way too commonly, the loudest in OSS communities are ones that have zero stake in building or maintaining the projects they criticize. It's easy to just rant if everyone else has to pick up the extrenalities.
  - actionfromafar 2y ago

p_l 2y ago

The inflection point was GNOME 3.8 not working properly with anything other than systemd and it being night impossible to implement compatible alternatives for some of the interfaces involved.

djbusby 2y ago
Right! If you wanted new Gnome you needed systemd - illusion of choice.

blueflow 2y ago

Systemd always is ahead with new features. Which is nice if its a feature you need, and double worse if it crashes your machine, like logind sending your machine into a bugged suspend. Which makes systemd linuxes unusable for newbies on some hardware. I used OpenRC because, not knowing about logind.conf, i had no other choice.

USiBqidmOOkAqRb 2y ago

Yet systemd doesn't have an equivalent to runit's sv once. Also, everything's so opaque that I can't figure out why nftables ruleset isn't loaded on boot, but systemctl restart works correctly (all on Ubuntu 24 server without any kind of frills added).

rascul 2y ago
> Yet systemd doesn't have an equivalent to runit's sv once. I'm not familiar with runit. Is this approximately equivalent to 'systemctl start service' when service uses the default of Restart=no ?
- USiBqidmOOkAqRb 2y ago
  Yes, but, as the name implies, only once, and selectively at runtime. If you have a service and issue sv once on it, it will not be restarted, but its configuration is not changed so it will run normally after system restart.
  - XorNot 2y ago
    That's a one-shot service[1]. RemainAfterExit=yes is what achieves the effect (i.e. if the process terminates it is regarded as still active for system-dependency purposes / status unless you purposefully mark it otherwise). [1] https://www.redhat.com/sysadmin/systemd-oneshot-service https://www.redhat.com/sysadmin/systemd-oneshot-service
vidarh 2y ago
> Yet systemd doesn't have an equivalent to runit's sv once. It's a design difference - systemd assumes services know whether they are intended to run once or restart under various conditions. If you want that behaviour it's just a matter of a tweak to the .service file. > Also, everything's so opaque that I can't figure out why nftables ruleset isn't loaded on boot Has it been disabled? ("systemctl enable [service name]" will enable it)

biorach 2y ago

> Folks who evangelise these "just as good as systemd" solutions always hide a key factor. No one in these comments was "evangelising" and no one was hiding anything. If you want to have a technical discussion about the merits of various init systems you can do it without inflammatory language and without reviving debates that almost everybody is sick of

doublerabbit 2y ago

> There is a reason systemd took over, its massively supported and widely tested. Partly due to that it's funded and forced upon by corporate. Any product can excel if resources are available.

Foxboron 2y ago
Nobody forced us, Arch Linux, to adopt systemd.
- hedora 2y ago
  That choice did get me to switch off an arch derivative to Devuan. Also, the purported benefits in this post (which I guess is authoritative for the project?): https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Haven’t panned out for me. 8: logind being repeatedly and completely busted (in 2022-2024) got me to try Debian again. 9: Debian taking 10’s of seconds to boot (just like manjaro), when devuan does it faster than a monitor sync got me to switch to devuan. (And, yes, since logind regularly wedges, I spend lots of time rebooting). Hotplug worked fine for me way before systemd existed, so that’s not a benefit either.

throwaway984393 2y ago

[dead]

cthalupa 2y ago

> There is a reason systemd took over, its massively supported and widely tested. Yes. The people behind it held key positions at Red Hat, freedesktop.org, etc. I'm not calling them some shadowy cabal pulling strings behind the scenes, but it would be silly to discount the political sway the people that started the project have. Being widely-tested also hasn't keep it from producing system bricking issues, such as this debacle just a few months ago: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/pull/33383 https://github.com/systemd/systemd/pull/33383 Or that time that systemd mounted efivarfs as rw making it possible to brick your motherboard https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Or the time back around 2012ish when an update caused the dhcp lease renewal portion to get wedged and took many thousands of servers offline until the service could be manually restarted or the machine rebooted. Or there was that time when OpenSSH was compromised because they pulled in systemd components to handle notifications: https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4 Then there are all the weird choices that are inconsistent with the rest of the ecosystem, like showing asterisks when typing in passwords instead of nothing: https://github.com/systemd/systemd/issues/8495 https://github.com/systemd/systemd/issues/8495 Even formerly simple things like log collection for systems not hooked up to Splunk or similar is now a chore. Most distros not longer include rsyslog by default, and pulling log files out of the journal is a painful process. Before, if I wanted to rip out the past week's logs for analysis, it'd usually mean just grabbing some gzip'ed files that were relatively small in size. Journalctl files are significantly larger in size for similar timeframes. OK, so how about I just interact with the journal directly and tell it to dump just the parts I care about? This is quite resource intensive on smaller VMs running in cloud providers and can severely degrade the overall system performance, so now I have to artificially slow things down and get it piecemeal or schedule it to run during off hours when the performance hit won't matter. I work with systemd daily. It is enough to make me wish I had to work with systemd never. I'm not some sysvinit purist, either - I like SMF on solaris quite a bit!