[lmm]

> And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative?

Because it's tightly coupled to everything (particularly to the few profitable parts of linux - most open-source is maintained on a shoestring, so it's pretty cheap to take control over development of even vital low-level infrastructure). This is how systemd bypassed the bikeshedding problem of there being half a dozen replacement inits but no clear consensus, with the result that everything relied on a lowest common denominator. But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.

[3np]

> But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.

You can, though? And many distros do by default.

Don’t like systemd-boot? You can replace it with grub.

Don’t like systemd-networkd? You can replace it with networkctl. Want to use it but prefer to handle Wireguard tunnels with wg-quick? Fine!

Don’t like systemd-resolved? You can replace it with dnsmasq.

Don’t like systemd-cryptsetup? systemd won’t care if some other system takes care of your LUKS partitions.

Etc, etc.

[fsflover]

https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

[3np]

That’s a short list of other packages (none of which I think are part of a base Linux install, correct me if I’m wrong) that have decided to depend on systemd?

[IshKebab]

Where's the "hard dependency on libc" list? Or "hard dependency on Bash"?

It's ridiculous to imagine that no program is allowed to depend on SystemD.

[lmm]

> Where's the "hard dependency on libc" list?

There are multiple libc implementations. libc independence is important and valuable. You'll probably find a "hard dependency on glibc" list in the documentation of e.g. Alpine.

> Or "hard dependency on Bash"?

Ubuntu will have a list from when they switched to ash as /bin/sh. Again, multiple implementations and independence are important, and something the linux community generally cares about.

[IshKebab]

> There are multiple libc implementations

You could make another SystemD implementation if you really wanted. The point is that there are plenty of APIs - even ones with a single implementation - that nobody bats an eye about programs having a "hard dependency" on, but suddenly for SystemD it's apparently a big issue?

It's bullshit technical excuses to hide the real reasons people object to SystemD, which are more embarrassing.

[lmm]

> You could make another SystemD implementation if you really wanted.

No you can't, because they don't offer stable interfaces as a matter of deliberate policy.

[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")

[kaba0]

Why was it chosen by debian multiple times with the most democratic process out there?

[lmm]

It was forced through by breaking the rules of the process and overruling the committee that should have made that decision. Many old-school Debian maintainers quit in disgust at that point, so if subsequent votes have been in systemd's favour then that's probably why.

[kaba0]

Some source would be interesting, because it is just blind words otherwise. Also, Arch and several other distros made the choice independently. I am fairly sure Red Hat is not some evil entity kidnapping the families of maintainers making them switch to systemd..

[esarbe]

No rules were broken.[0]

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