4 ms·

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

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_login/ https://www.theregister.com/2026/01/26/plasma_6_6_systemd_lo...

Cu3PO42 9mo ago
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 9mo ago
  which current alternatives have you tried?
  - Cu3PO42 9mo ago
    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 9mo ago
      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 9mo ago
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.

Cu3PO42 9mo ago

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 9mo ago
which current alternatives have you tried?
- Cu3PO42 9mo ago
  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 9mo ago
    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 9mo ago

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.