5 ms·

I don't care: I can administer with relatively high confidence any Redhat- or Debian-derivate. Thanks to systems. Most issues regarding systemd I encountered w

I don't care: I can administer with relatively high confidence any Redhat- or Debian-derivate. Thanks to systems. Most issues regarding systemd I encountered were due to a halfway adoption (Debian). Some things like timers are a bit more cumbersome than "the old way", but I wouldn't want to miss the added robustness. Most things systemd implements lead to _less_ issues. And writing a systemd unit is pretty easy, contrary to the old bash script mess. So, no. Keep your Poettering-Bashing to yourself. I'd rather invest the time in geokking the systemd choices deeper.

jackielii 9mo ago
Well said!
McDyver 9mo ago
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 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. Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain
- embedding-shape 9mo 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 9mo ago
    Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.
    - embedding-shape 9mo ago
      So if you don't like that, don't you still have the choice not to use software developed by Red Hat?
      - logicprog 9mo 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 9mo ago
        Embrace extend extinguish tactics, now celebrated in Linux land.
        embedding-shape 9mo ago
        You had choices before, you still have choices, how is that EEE? There never been more distributions available.
        JCattheATM 9mo ago
        You had choices not to use $technology that Microsoft embraced, extended and then extinguished, how is that not EEE?
        embedding-shape 9mo 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.
  - blueflow 9mo 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 9mo 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 9mo 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 9mo 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...
      - 9mo ago
  - benterix 9mo 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 9mo 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 9mo 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 9mo ago
    If Google spends millions of dollars pushing Chrome on everyone, then it's their fault everyone is using Chrome.
- jabl 9mo 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 9mo 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 9mo ago
  You have the choice to use either Debian or Devuan.
PunchyHamster 9mo ago
you can use and like and still complain about things that should be better or were better under old. systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS. > And writing a systemd unit is pretty easy, contrary to the old bash script mess. We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement. One example: A java app that writes its own pid. The status subcommand relies on the pid existing. so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler
- cbolton 9mo ago
  > inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS. What about "systemctl --force --force poweroff" ?
  - teddyh 9mo ago
    With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.
    - cbolton 9mo ago
      Yes you're right.
psychoslave 9mo ago
One system to rule them all, blame any issue encountered on lake of full adoption, and label them as defamation. What could go wrong?
zkag101 9mo ago
You could do the same in a less invasive manner with daemontools like forever. Not only on Linux, but on BSD as well. But people need a corporate and worse knockoff shoved down their throats, because DJ Bernstein is independent and we cannot have independent people in software.
- zbentley 9mo ago
  I wrote a lot of daemontools wrappers and non-shell forking daemons. Doing this is really, really error prone and fragile. Why the hell should I have to learn about double forking and PIDfe validation (and process groups and pty-or-not and all those other esoterica that daemontools still requires you to engage with if you want to do something outlandish like “run a program with a graphical component at boot”) just to make something run in the background?
  - direwolf20 9mo ago
    You shouldn't. You should let it run in the foreground and let the system manager switch to the background before running it, if it wants to. This has many advantages, mostly simplicity. I am not familiar with daemontools but I think it includes something similar to runit, which likes your processes to run in the foreground.
    - zbentley 9mo ago
      In daemontools' happy path, you're 100% right. However, the happy path is very, very narrow. It breaks down as soon as you have to deal with: - Set(e)uid daemons or any background service that needs to run as a different user than the one launching the service. - Programs that report readiness somehow (the equivalent of the "notify" systemd type). Plenty of services won't crash when they should, so a standard for "it's all the way up" is useful. - Start timeouts and failures. If daemontools is your only authority of the "status" result, recognizing a started-but-hung service is hard. Even if your service has some other "yes, the binary exists, but is it working?" check, getting daemontools+init to probe that and appropriately react to start timeouts can be fussy. - Services that themselves spawn subprocesses (either forking or running separate child programs). Parent-process crashes are a recipe for orphaned things running and consuming resources/doing who knows what. You can solve this with a cgroup/namespacing/prctls to control orphan reparenting, but that's super hard to get right. Systemd has a one-liner for "on stop, kill this service and any program that was ever spawned in its tree". Having implemented the equivalent code to KillMode=control-group a in a few different "this has to be really reliable and bug-free" contexts now, having to manually manage this when managing services is a recipe for disaster. You'd think you know when your services will/won't have child processes, but you'd be wrong a lot (e.g. oddball JVM tracing sidecars, Pythons that always run a multiprocessing helper even if they don't use multiprocessing, Redis sometimes forking and doing bgsave, Erlang with its DNS-management child procs, literally anything ever written in Perl, Postgres, and so on. You would think that most managed child processes in big, mature software projects will know to kill themselves if their parent crashes for whatever reason. You would be wrong). - Inter-service dependencies. Yes, many init systems take that on, but now you have the daemonization system and the init system--separate tools to configure, with overlap and expectations about each other. - Race conditions around setting up pidfiles/locks when first deploying a service. Sure, once it's installed flock(2) will work fine, but what if you're installing a new distribution of the service and the installer picks a different lock directory from the one in use by the running service? There are a lot more things I could list, but I'd rather not go back there. Having to manage this stuff by hand was a pretty low point for our field--as fully clued-in as sysadmins felt, we made a lot of mistakes, and made an environment that was deeply hostile to non-expert operators who just wanted to run a service and forget about it. Systemd's far from perfect, but the challenges of doing this stuff with daemontools and friends weren't just "this is a worse implementation than systemd"; they were "this is existentially harder than using systemd precisely because it follows the 'unix philosophy' and maximizes control of (and thus responsibility for) an area where simple cases are often ... not".
rpdillon 9mo ago
Are you worried that you're going to become subject to attestation via systemd?
cmxch 9mo ago
Only if you have no issue with the bloat of additional binary parsing of essentially text logs.
- direwolf20 9mo ago
  Text parsing isn't any better. There are many things wrong with systemd but this isn't a useful thing to get angry about.

jackielii 9mo ago

Well said!

McDyver 9mo ago

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 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. Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain

embedding-shape 9mo 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 9mo ago
  Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.
  - embedding-shape 9mo ago
    So if you don't like that, don't you still have the choice not to use software developed by Red Hat?
    - logicprog 9mo 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 9mo ago
      Embrace extend extinguish tactics, now celebrated in Linux land.
      - embedding-shape 9mo ago
        You had choices before, you still have choices, how is that EEE? There never been more distributions available.
        JCattheATM 9mo ago
        You had choices not to use $technology that Microsoft embraced, extended and then extinguished, how is that not EEE?
        embedding-shape 9mo 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.
- blueflow 9mo 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 9mo 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 9mo 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 9mo 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...
    - 9mo ago
- benterix 9mo 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 9mo 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 9mo 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 9mo ago
  If Google spends millions of dollars pushing Chrome on everyone, then it's their fault everyone is using Chrome.
jabl 9mo 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 9mo 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 9mo ago
You have the choice to use either Debian or Devuan.

PunchyHamster 9mo ago

you can use and like and still complain about things that should be better or were better under old. systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS. > And writing a systemd unit is pretty easy, contrary to the old bash script mess. We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement. One example: A java app that writes its own pid. The status subcommand relies on the pid existing. so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler

cbolton 9mo ago
> inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS. What about "systemctl --force --force poweroff" ?
- teddyh 9mo ago
  With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.
  - cbolton 9mo ago
    Yes you're right.

psychoslave 9mo ago

One system to rule them all, blame any issue encountered on lake of full adoption, and label them as defamation. What could go wrong?

zkag101 9mo ago

You could do the same in a less invasive manner with daemontools like forever. Not only on Linux, but on BSD as well. But people need a corporate and worse knockoff shoved down their throats, because DJ Bernstein is independent and we cannot have independent people in software.

zbentley 9mo ago
I wrote a lot of daemontools wrappers and non-shell forking daemons. Doing this is really, really error prone and fragile. Why the hell should I have to learn about double forking and PIDfe validation (and process groups and pty-or-not and all those other esoterica that daemontools still requires you to engage with if you want to do something outlandish like “run a program with a graphical component at boot”) just to make something run in the background?
- direwolf20 9mo ago
  You shouldn't. You should let it run in the foreground and let the system manager switch to the background before running it, if it wants to. This has many advantages, mostly simplicity. I am not familiar with daemontools but I think it includes something similar to runit, which likes your processes to run in the foreground.
  - zbentley 9mo ago
    In daemontools' happy path, you're 100% right. However, the happy path is very, very narrow. It breaks down as soon as you have to deal with: - Set(e)uid daemons or any background service that needs to run as a different user than the one launching the service. - Programs that report readiness somehow (the equivalent of the "notify" systemd type). Plenty of services won't crash when they should, so a standard for "it's all the way up" is useful. - Start timeouts and failures. If daemontools is your only authority of the "status" result, recognizing a started-but-hung service is hard. Even if your service has some other "yes, the binary exists, but is it working?" check, getting daemontools+init to probe that and appropriately react to start timeouts can be fussy. - Services that themselves spawn subprocesses (either forking or running separate child programs). Parent-process crashes are a recipe for orphaned things running and consuming resources/doing who knows what. You can solve this with a cgroup/namespacing/prctls to control orphan reparenting, but that's super hard to get right. Systemd has a one-liner for "on stop, kill this service and any program that was ever spawned in its tree". Having implemented the equivalent code to KillMode=control-group a in a few different "this has to be really reliable and bug-free" contexts now, having to manually manage this when managing services is a recipe for disaster. You'd think you know when your services will/won't have child processes, but you'd be wrong a lot (e.g. oddball JVM tracing sidecars, Pythons that always run a multiprocessing helper even if they don't use multiprocessing, Redis sometimes forking and doing bgsave, Erlang with its DNS-management child procs, literally anything ever written in Perl, Postgres, and so on. You would think that most managed child processes in big, mature software projects will know to kill themselves if their parent crashes for whatever reason. You would be wrong). - Inter-service dependencies. Yes, many init systems take that on, but now you have the daemonization system and the init system--separate tools to configure, with overlap and expectations about each other. - Race conditions around setting up pidfiles/locks when first deploying a service. Sure, once it's installed flock(2) will work fine, but what if you're installing a new distribution of the service and the installer picks a different lock directory from the one in use by the running service? There are a lot more things I could list, but I'd rather not go back there. Having to manage this stuff by hand was a pretty low point for our field--as fully clued-in as sysadmins felt, we made a lot of mistakes, and made an environment that was deeply hostile to non-expert operators who just wanted to run a service and forget about it. Systemd's far from perfect, but the challenges of doing this stuff with daemontools and friends weren't just "this is a worse implementation than systemd"; they were "this is existentially harder than using systemd precisely because it follows the 'unix philosophy' and maximizes control of (and thus responsibility for) an area where simple cases are often ... not".

rpdillon 9mo ago

Are you worried that you're going to become subject to attestation via systemd?

cmxch 9mo ago

Only if you have no issue with the bloat of additional binary parsing of essentially text logs.

direwolf20 9mo ago
Text parsing isn't any better. There are many things wrong with systemd but this isn't a useful thing to get angry about.