[benterix]

OK you're missing the historical context here. To make this story extremely short, the author of Systemd was already known for another project that was causing problems to Linux users but was shipped early. And when Systemd was released, it has several issues, too, so some distros like Debian withheld the switch. But at some point the folks at Red Hat decided to tie Systemd to the login mechanism for Gnome. I don't believe there was any hidden agenda here, it was just more logical for them. However, this caused huge headache for package maintainers of non-Systemd distros. There was the whole drama with voting, Debian project leader leaving, Devuan appearing and so on.

I believe most people moved on, but the way it was all done somehow didn't feel right.

[embedding-shape]

Ok, yes, I wasn't aware of the history, I use whatever my distribution uses as default, and been doing that for decades now, as that tends to be less hassle, so been using systemd for a while because of that.

With this new knowledge about the history, I still feel the same as the original question. AFAIK, no one is forcing people/distributions to adopt systemd. It might be easier, and most takes the easiest route, but that's OK, right? That doesn't mean that you cannot make another choice, maybe involving more work, but you can still make that choice, unless again I miss something obvious here.

[mid-kid]

The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certain program that now depends on it.

This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.

[Izkata]

> Systemd's components don't play well with established standards

Here's my favorite (quickly searched for, this links to other threads): https://www.reddit.com/r/programming/comments/4ldewx/systemd...

As far as I know systemd never changed the default, people only stopped complaining because distros now override it.

[ndsipa_pomu]

Is that "logout" referring to a user explicitly logging out from a desktop environment? I can't imagine it would apply to a closed SSH session, or at least it wouldn't make sense if it did.

[Izkata]

According to the Bugzilla case it links to (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394):

> It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine.

And the reddit comments include a link to a tmux issue where the suggested solution is for tmux to add systemd as a dependency (https://github.com/tmux/tmux/issues/428). Includes some back-and-forth about how all sorts of software would have to change in similar ways to accommodate systemd, instead of systemd just playing nicely with decades of established practice.

[ndsipa_pomu]

I had no idea about that. Does seem a bizarre choice for systemd to do that.

I admin a whole bunch of headless servers and so am often SSHing to them and running long running jobs. Some of them run VNC sessions, and I certainly wouldn't want a VNC session to kill of other SSH sessions by the same user. At least with VNC, I almost never "logout" - they're often autostarted (by systemd) and just get killed when the machine gets rebooted.

[direwolf20]

To be clear: systemd works fine to start/stop services. Usually. If you have a working system with systemd, it's rarely worth ripping out and replacing. That's just more risk than reward.

But that doesn't mean it's good.

[7bit]

Citing PulseAudio adds nothing here. Distros decided to ship it early, just like systemd later ... that choice wasn’t pushed by Poettering. Dragging in an earlier project without making an actual technical or governance argument is just character framing. It’s not evidence, it’s a smear.

[benterix]

No, I decided to include it to explain the emotional response to Systemd. I didn't mean to offend anyone. That stuff didn't work and broken things were pushed on people again, that's why some revolted.

[Izkata]

PulseAudio never really got stable though, people switched to PipeWire so they wouldn't have to deal with it.

[Hikikomori]

At the time desktop Linux projects like consolekit were an unmaintained mess, it needed replacements. Systemd also supported cgroups V2 and people really wanted to use that. No conspiracy or underhandedness required.

[benterix]

I don't think anyone would ever object against systemd as a project, it would make as much sense as objecting against, say, GNU Chess. All software has bugs, and they're gradually worked out. But the way it was introduced that made many people upset.

[Hikikomori]

The way it was introduced was that many people could see the value in cgroups V2 and being able to drop unmaintained projects. Maintainers of distros and projects sometimes did this against some users wants, but in my opinion there was just lots of baseless complaining without creating an alternative.