6 ms·

That's good for you! Isn't that a selfish view, though? "Works for me,so I don't care that systemd is creating dependencies everywhere for everyone else". I a

• embedding-shape 8mo ago
  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.
  • 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?
  • blueflow 8mo ago
    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.
    • embedding-shape 8mo ago
      > 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 8mo ago
        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.
    • cbolton 8mo ago
      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...
      • 8mo ago
  • benterix 8mo ago
    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 8mo ago
      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 8mo ago
        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.
  • direwolf20 8mo ago
    If Google spends millions of dollars pushing Chrome on everyone, then it's their fault everyone is using Chrome.
• jabl 8mo ago
  > I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives. You can? The system where I'm writing this uses systemd, yet networking is handled by NetworkManager and not systemd-networkd. Time keeping is handled by chrony and not systemd-timesyncd (or whatever the systemd NTP client was called). Etc. Systemd in fact has many components that are optional. Of course, there are also parts of it that are non-optional, just like many other collections of related software. > Isn't linux about choice? Linux is "about choice" to the extent that the source code is freely available, and if you don't like what upstream is doing, you have the choice to fork it and do whatever you want. "Linux is about choice" does not extend to upstream maintainers being obligated to cater to every whim of every end user. Case in point, Devuan: Not being satisfied with the path Debian was taking, they exercised their choice and are now doing their own thing. Good for them! And to the extent this has reduced the frequency of systemd haters starting yet another anti-systemd flame war on the Debian mailing lists, it seems to me Debian has won too. Hooray!
• PunchyHamster 8mo ago
  You can turn most parts off. Maybe don't talk about stuff you have not much idea about ? There is point to complain about distros turning it on by default but you could have systemd where systemd just does unit management and not much more. The hardest part to get rid of would probably be journald as this parasite's log format is just... not good in any metric but it isn't easy to replace either if you want to keep systemd functionality
• direwolf20 8mo ago
  You have the choice to use either Debian or Devuan.