[embedding-shape]

How is it someone's else's fault for that systemd has dependencies or that others depend on systemd?

If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox?

I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn't modular enough? Use something else then that is modular.

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

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

[blell]

Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.

[belorn]

I don't get it. If you install openbsd, you get dependencies that openbsd developers has chosen. You can try to remove every aspect of those choices but at some point it won't be openbsd anymore.

Is the claim here that Red Hat is unnecessary coupling their critical parts of the distribution in ways that other distributions would not do? A few examples here would be nice.

[direwolf20]

OpenBSD is a monolithic system with kernel and userspace developed together. Linux was a bazaar.

[embedding-shape]

So if you don't like that, don't you still have the choice not to use software developed by Red Hat?

[logicprog]

They do, they just want to whine about software other people made (that they don't contribute to) doing something they don't like.

[account42]

Embrace extend extinguish tactics, now celebrated in Linux land.

[embedding-shape]

You had choices before, you still have choices, how is that EEE? There never been more distributions available.

[direwolf20]

At every stage of EEE, you have choices. All but one are made more unappealing as the EEE process progresses.

[JCattheATM]

You had choices not to use $technology that Microsoft embraced, extended and then extinguished, how is that not EEE?

[embedding-shape]

EEE is about taking existing standards/software and making it eventually incompatible with FOSS. That's very different from creating a new thing, and asking people to use that. AFAIK, they're not replacing anything (but maybe I missed something), so I don't see it as the same as what Microsoft did back in the day.

[Hikikomori]

Did anything else support cgroups V2?

[logicprog]

Which software has hard dependencies on systemd?

Also, it's not just RedHat that's depending on systemd, as if its a conspiracy on their part.

https://www.theregister.com/2026/01/26/plasma_6_6_systemd_lo...

[Cu3PO42]

Gnome, for example. GDM now needs systemd's userdb.

It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.

[t43562]

which current alternatives have you tried?

[Cu3PO42]

I've looked at OpenRC, RUnit and S6. I haven't recently run any of them "in production", however.

Personally, I am a strong believer that declaring the desired state is a lot easier to get right than actually writing the code to get there. Beyond that, I'm not saying any of these are bad at being what they are, systemd just has more features, some of which I really like. Two examples I'm actively using currently are automount units and socket activation (S6 also has socket activation). I have some remote folders mounted via SSHFS automatically when I access them and this is incredibly useful for my workflow.

Could I find tools to slot into other init systems that do this for me? Probably. But systemd has this neatly packaged up, easy to configure and easy to introspect state.

[direwolf20]

Runit (not RUnit) seems pretty cool.

It uses a folder with a subfolder for every service. Each subfolder contains a script called run. The system runs the run script. If it exits, it waits two seconds and runs it again. Repeatedly. It's very worse–is–better.

There are commands to control the services and check their status. For example, if a file called down exists next to the run script, it won't run it. This is how you disable a service.

It checks for service folders being created and deleted. New folders are started, and deleted ones are stopped cleanly. They can also be symlinks, so you don't need to worry about deleting a running service folder and you can remove a service from init without erasing the scripts you wrote.

The whole system is useful in many situations and not only as pid 1.

Maybe one day I'll invent a runit–based distribution.

[eth0up]

Dependencies may be becoming less properties of software, and more so properties of the distro's systemd wiring.

More and more software will assimilate systemd features. Free distros will patch, shim, emulate, flounder. Or in GPT parlance "Dependencies are no longer intrinsic properties of software; they are emergent properties of a distribution's systemd orchestration layer"

Meanwhile, gripes, fears etc,

'Linux' becomes interpreted vs inspectable.

Requires superfluous new literacy

Convolutes logs, tools Obscures causality

Centralized control above Unix process model

Fair well ps aux, hello systemctl, cgtop, gls

KILL (less lethalized) superceded, replaced by service stop and mask

Surrender chains for events, ie buggy debugging or complexity accretion

General obfuscation beneath the hood

Centralized ... indexed, logs vs text streams

And....

Upstream assumes systemd

Some resist

Costs rise

Optional becomes expected

Accidental incompatibility

And... systemd ingurgitates one by one, policy, supervision, logging, identity, dependency management and the rest of the world... digests it, and from the aether emerges a sweet smiley face, disgorging forth a monolithic mutant avatar, with Linux features.

I'll be quiet happy to be wrong about everything. Feel free to slaughter everything I've written. I don't even oppose systemd - I simply perceive it as a singularity that's drawing everything around me towards it. Wrong would definitely be good, so please don't hold back. I won't seek pardon for the rant though, because true or false, it's honest.

Edit: I was reading through my threads and thought the parent was asking me, though wasn't. I've unintentionally barged in here, but I'll leave the comment anyway, as it references a very big concern of mine.

[direwolf20]

If Google spends millions of dollars pushing Chrome on everyone, then it's their fault everyone is using Chrome.

[blueflow]

With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.

Want to run xterm? Requires Xorg. rootless Xorg requires udev, udev turned into a systemd component. want to run xterm without systemd? good luck, you are now the maintainer of your own LFS.

[cbolton]

The udev developers decided that it made sense to move udev into systemd. If you disagree and want choice, you can fork udev. Actually some people did that, so you can run xterm with eudev instead of udev and thus avoid systemd (though eudev seems hardly maintained now, with the latest release in 2023).

I think it's true that it's an exhausting battle to keep all those parts independent when 95% of the devs/money agree it's better to integrate them. But it wouldn't be fair either for the 5% to put on the others the burden of keeping things independent because of their own preferences...

[mid-kid]

eudev was just a copy of the udev part of systemd, with some patches to build on musl, and work without systemd. All of that has been upstreamed now, LFS has instructions on how to build udev from the latest systemd release, without building systemd itself.

[zbentley]

Yeah, it’s miserable; xterm shouldn’t require Xorg. It should be agnostic to display system and not force the X monoculture on everyone. Classic Microsoft gestapo tactics: shoehorn Xorg dependencies into tons of unrelated apps and thus curtail user freedom to run xterm with a WinForms or Wayland display system. It’s appalling.

[VladStanimir]

From the project documentation: "The xterm program is a terminal emulator for the X Window System." The application does not require xorg it requires an x11 server.

It just so happens that until recently xorg was the only game in town as far as Linux x11 servers are concerned.

[direwolf20]

xterm is literally x terminal but it's not systemd terminal

[yjftsjthsd-h]

xterm runs on Wayland and arcan; you should pick a different strawman

[embedding-shape]

> With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.

Yes, but this is hardly a unique systemd/Linux problem. I despise TypeScript for various reasons, always preferred vanilla JavaScript over TypeScript. So if I'm met with "Huh, this library is using TypeScript, am I ready to deal with that", I make the choice to not depend on that, even though half of the ecosystem uses TypeScript.

Going against the grain comes with more work probably, but this is also a choice we make, because we have strong feelings and opinions about something.

[direwolf20]

Languages are confined. I don't speak Rust — yet — so when I want to modify some software that is written in Rust that is a disappointment. However, the effect of software being written in Rust is limited to that software and its libraries. It doesn't infect your system the way systemd does.