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