[starklevnertz]

But no systemd distro is saying “we want to dump systemd but we can’t because it’s too tightly Coupled” are they?

Or maybe the maintainers are I don’t know do you have links to show this is the case?

Systemd is used by all major linux flavors because it’s the best solution for the problems it solves.

The distro maintainers are too smart to be stuck with systemd against their will.

And it’s linux …. make a better solution, if it’s truly better it’ll be used.

[p_l]

That's a bit of revisionist history.

Systemd was minority pretty much till GNOME 3.8 introduced super-hard dependencies on it through an interface that was supposedly documented (Ubuntu sunk a bunch of money trying to keep alternative implementation running).

For many a distro, it became a question - "do we include GNOME, or do we drop it?" and that was impetus to move to systemd

[esarbe]

This is simply not true[0]. To quote:

> This is really unfortunate, but GNOME 3.8 does not require logind. I discussed the non-dependency of logind+systemd on #gentoo-desktop and why they thought different. Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that.

Systemd was adopted because it was (and still is) simply superior in many aspects to previously available process managers, because application developers had it up to here to maintain n different init scripts for n different distributions and distribution packagers didn't want to have to write custom init scripts for each application anymore.

As an example, check out the discussion around the adoption of systemd in Debian[1].

[0] https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

[1] https://www.debian.org/vote/2019/vote_002

[p_l]

It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults?

And no, not in "GDM doesn't clean up after itself", which was given as explanation for the infamous "systemd now defaults to destroying everything in a session on logout" change few years later. (Which GDM could require anyway earlier, but apparently somehow it wasn't enough)

There is a lot of good ideas that went into systemd though, and I'd agree that a lot of anger is in how badly they are implemented (the only reason I do not complain more about systemctl is because upstart managed to be even worse). In my copious free time, I've been tinkering at alternative, but even if I disagree at the format of systemd service files, it includes a parser for them.

[esarbe]

> It might be because people did report on in trying to run GNOME 3.8 without logind, and reported massive faults?

If you by 'it' mean the fact that the distributions switched to systemd, I would be declined to discount the speculation that 'it was because people did report in trying to run GNOME 3.8 without logind [...]'. Do you honestly think that Fedora, Arch or any of the other distributions would not try to evaluate other strategies of getting GNOME 3.8 to run? Replacing the process manager and PID0 is not an endeavor chosen lightly - it is a massive undertaking that every distribution would have weight very carefully. "Oh, there are people having trouble running GNOME 3.8 without systemd present" seems not to be enough reason to go through all the pain of switching to systemd.

It's rather that systemd offered something that systemd offered something that the preceding mess of shell scripts and conventions didn't offer; consistency and reliability, as much as you might doubt that. Have a look at the Debian general resolution with regards to systemd and the provided arguments by the proponents[0].

> I've been tinkering at alternative

I would be very glad if your alternative implementation were even modestly successful. And I'd be thoroughly thankful if it managed to replace systemd.

Not because I think systemd is badly implemented (I've yet to see any actual evidence in that regard from any detractor) but because systemd needs competition and I would prefer to see some well established and stable protocols between the individual parts of systemd. That will only happen if said protocols get also provided by alternative implementations.

With regards to you re-using the systemd configuration format; that's probably a smart move. Systemd is at this point a well established fact and anyone trying to best it at its game will have to make is as easy to migrate as possible. Hurdles like a new file format might well be too much for an indifferent user.

[0] https://www.debian.org/vote/2019/vote_002

[p_l]

Fedora and Arch are literally the early adopters of systemd, long before GNOME 3.8. GNOME 3.8 made hard dependencies on logind because it was default in Fedora - Arch similarly was working full tilt on implementing all proposed things from systemd long before GNOME 3.8 release (I know, I had lost my only on-hand system due to one of those changes applying badly and making it unbootable)

As for supporting configuration format - it's an obvious move, though more as "import" rather than only source of truth (different internal data models), and the format... is not exactly good (mostly due to lack of sane defaults that start to hit you once you wander beyond functionality that can be summarised as "SysV initd plus dependencies")

[esarbe]

> GNOME 3.8 made hard dependencies on logind because it was default in Fedora

Looks like we're still in disagreement about this. As far as I can tell, there was never a 'hard' dependency of GNOME 3.8 on logind; logind was an optional dependency[0].

> beyond functionality that can be summarised as "SysV initd plus dependencies"

I would attribute that to the lack of similar "service manager" functionality in other "boot managers". That comes down to the hesitancy of these "boot managers" to embrace the role of "service managers". There's tons of functionality that the systemd project (not necessarily the pid0 binary) introduced to make services run consistently and reliably. They paved the way in that regard and we're still waiting for contenders to catch up.

[0] https://mail.gnome.org/archives/desktop-devel-list/2013-Marc...