4 ms·

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

by blell 8mo ago

embedding-shape 8mo ago
So if you don't like that, don't you still have the choice not to use software developed by Red Hat?
- logicprog 8mo ago
  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 8mo ago
  Embrace extend extinguish tactics, now celebrated in Linux land.
  - embedding-shape 8mo ago
    You had choices before, you still have choices, how is that EEE? There never been more distributions available.
    - JCattheATM 8mo ago
      You had choices not to use $technology that Microsoft embraced, extended and then extinguished, how is that not EEE?
      - embedding-shape 8mo ago
        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.
        JCattheATM 8mo ago
        I think it's similar. We have a big powerful company pushing their solution, pushing more and more software to depend on that solution, so people who want to exercise their choice not to have an increasingly uphill battle to do so. That doesn't seem so different from what Microsoft used to do, as even back then there was always choice if people decided to get together and exercise it, but practically in both cases it's an uphill battle.
    - direwolf20 8mo ago
      At every stage of EEE, you have choices. All but one are made more unappealing as the EEE process progresses.
logicprog 8mo ago
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 8mo 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 8mo ago
    which current alternatives have you tried?
    - Cu3PO42 8mo 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 8mo 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.
belorn 8mo ago
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 8mo ago
  OpenBSD is a monolithic system with kernel and userspace developed together. Linux was a bazaar.
Hikikomori 8mo ago
Did anything else support cgroups V2?

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

by blell 8mo ago

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

embedding-shape 8mo ago

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

logicprog 8mo ago
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 8mo ago
Embrace extend extinguish tactics, now celebrated in Linux land.
- embedding-shape 8mo ago
  You had choices before, you still have choices, how is that EEE? There never been more distributions available.
  - JCattheATM 8mo ago
    You had choices not to use $technology that Microsoft embraced, extended and then extinguished, how is that not EEE?
    - embedding-shape 8mo ago
      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.
      - JCattheATM 8mo ago
        I think it's similar. We have a big powerful company pushing their solution, pushing more and more software to depend on that solution, so people who want to exercise their choice not to have an increasingly uphill battle to do so. That doesn't seem so different from what Microsoft used to do, as even back then there was always choice if people decided to get together and exercise it, but practically in both cases it's an uphill battle.
  - direwolf20 8mo ago
    At every stage of EEE, you have choices. All but one are made more unappealing as the EEE process progresses.

logicprog 8mo ago

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

belorn 8mo ago

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 8mo ago
OpenBSD is a monolithic system with kernel and userspace developed together. Linux was a bazaar.

Hikikomori 8mo ago

Did anything else support cgroups V2?