alt Hacker News> Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago.
As a Gentoo user for the past ~quarter-century, I'd say that it's more that -unlike Debian- Gentoo has been using a system service manager that's way better than the classic SysV init for approximately forever.
The early discussion of systemd-as-init [0] was pretty much 100% focused on how much better systemd-as-init was than classic SysV init. When restricted like this, systemd-as-init is an obvious winner. But, when you consider other init systems -such as OpenRC- that provide a bunch of useful scaffolding and support tools (rather than demanding you reimplement all that yourself) the benefits of using systemd-as-init are far less clear.
I've mentioned this before in an HN comment or two from way back when, but I'm really mad at myself for not recognizing how extremely important the "What should Debian adopt to replace the incredibly ancient SysV init?" discussion was and failing to take part in it. OpenRC was knocked out of contention for reasons that were never really clear to me, and I'd have loved to put a bunch of time and effort into fixing whatever deficiencies the Debian folks believed made it unworthy of consideration.
Oh well.
[0] ...as well as some-to-much contemporary discussion...
Replies
Yes, exactly.
"Systemd-vs-SysV" was never the concern for me personally, it was always "Systemd as the last init we ever create" based on how it's being built, and I always tried to argue that it was a hard pill to swallow because there were already better foundations in the world (SMF, for my favourite example), people didn't want to have that discussion, they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
So, systemd is the last init we'll ever have, just like I feared.
The OpenRC people in Debian only really noticed the discussion when it reached the technical committee. There was an effort to put OpenRC into contention, and all of the technical committee people who did evaluations included it in their evaluations. The problem was that OpenRC as it existed on Debian at the time was lacking. People argued that it could with a little work do the things that the technical committee people pointed out, but the counterargument was that the decision really had to be made at that point, given the argument that had built up. I do recommend reading the discussions by Russ Alberry and others about OpenRC on the technical committee mailing list back then.
Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.
* https://jdebp.uk/FGA/debian-systemd-packaging-hoo-hah.html
Interesting tidbit:
People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did all of the repetitive common stuff.
* https://unix.stackexchange.com/a/480897/5132
* https://manpages.debian.org/trixie/sysvinit-utils/init-d-scr...