Remix.run Logo
simoncion 3 hours ago

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

JdeBP 3 hours ago | parent | next [-]

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

dijit 3 hours ago | parent | prev [-]

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.

simoncion 3 hours ago | parent [-]

> "Systemd as the last init we ever create" ... they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...

Yeah, that rhetoric was maddening. Poettering and crew were -and continue to be- absolutely incapable of maintaining a project of such scope and importance.

Do you remember the fucking kdbus saga? I really wish the folks on the kernel side of that who were responsible for asking careful, technical questions, thinking deeply about the answers that they got, and cutting through the bluster and misdirection they received had been the ones in charge of deciding the new Debian init system for... Jessie, was it?

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

I've heard from many folks who have tried to reimplement substantial parts of the SystemD. [0] They report that the documentation is woefully inadequate, the interactions between components get incredibly complex, and the project maintainers have a habit of breaking things whenever they feel like it. This breakage doesn't matter to things they maintain, because they can make changes to account for it... but for "out of tree" reimplementations, well, they are -perhaps correctly- entirely disinterested in worrying about those.

> So, systemd is the last init we'll ever have, just like I feared.

Eh. I still hold hope that Debian or some other major distro will notice how unsuited the SystemD maintainers are to long-term stewardship of something so wide-reaching and critically important and cast about for alternatives. We'll see.

[0] This is a shorthand for "Systemd Project", not a slur against it. It sucks that systemd(1) and the project that contain it share the same name. [1]

[1] For a real-world example of the sort of conversation this confusion causes, check out [2]

[2] <https://news.ycombinator.com/item?id=48716382>