5 ms·

Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas?

TacticalCoder 1y ago
First before venting I'll say this: thanks to stuff like hypervisors, VMs, non-systemd distros, minimal immutable Linux distro like Talos (made to run Kubernetes with a minimum number of executable) and OCI containers where, by definition, PID 1 is not systemd, there's thankfully a real way out of systemd, even on a Linux stack. And I think more people should look into being, once again, 100% systemd-free. > Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas? Because the goal is to take control of Linux. That's why systemd is PID1. That's why Poettering works for Microsoft. The real question is: why was that ultra-convoluted xz backdoor attempt only working on Linux systems that did have systemd? People shall try to wag the dog saying "but it's because this and that made is so that xz was loaded by OpenSSH, it's got nothing to do with systemd". It's got everything to do with systemd. And the other question is: how many backdoors are operational, today, on systems that have systemd? Systemd is Microsoft-level bloat, running as PID 1, spreading its tentacles everywhere in Linux distros, definitely on purpose. Poettering is moreover an insufferable bully, as can be seen once again. From TFA: > So what do you recommend how to go on from here? Change Debian policy (as asked in #1111839), revert the change in systemd, find a Debian wide solution or let every package maintainer implement their own solution? I suggest Debian just drops systemd once and for all. Debian can still be made systemd-free but it's a hassle. Just make Debian systemd free once again. Meanwhile you'll find me running systemd-less distros on VMs and running containers giving the PID 1 finger to systemd. I can't wait to switch my Proxmox to FreeBSD's bhyve hypervisor (need to find the time to do it). But most of all: I cannot wait for the day a systemd-less hypervisor Linux like Proxmox comes out. It's coming and people who write stuff like: "Don't use Docker, use systemd this and systemd that" are misguided. systemd is to me the antithesis of what Linux stands for. I hope Debian gets pissed enough at some point to fully drop systemd. P.S: one of my machine runs this: https://www.devuan.org/ https://www.devuan.org/ and honestly it's totally fine. So yup: power to all those running systemd-less distros, BSDs, etc.
ho_schi 1y ago
Did you read the same article? * Their is an option for the old behavior. * It is a security issue and better solutions to replace exist. * FHS isn't maintained. I think everyone involved would prefer updates to the applications, which fix the issue. Debian opted - for now - for reliability for its users, which fits in their mission statement. On Arch /run/lock is only writeable for the superusers, which improves security. As user I value reliability and security and that legacy tools remain usable (sometimes by default, sometimes by a switch).
- gwd 1y ago
  > On Arch /run/lock is only writeable for the superusers, which improves security. Does it? That means anyone who needs a lock gets superuser, which seems like overkill. Having a group with write permissions would seem to improve security more?
  - dathinab 1y ago
    no that isn't what it means at all a global /run/lock dir is an outdated mechanism not needed anymore when the standard was written (20 years ago) it standardized a common way programs used to work around not having something like flock. This is also reflected in the specific details of FHS 3.0 which requires lock files to be named as `LCK..{device_name}` and must contain the process id in a specific encoding. Now the funny part. Flock was added to Linux in ~1996, so even when the standard was written it was already on the way of being outdated and it was just a matter of time until most programs start using flock. This brings is to two ways how this being a issues makes IMHO little sense: - a lot of use cases for /var/lock have been replaced with flock - having a global writable dire used across users has a really bad history (including security vulnerabilities) so there have been ongoing affords to create alternatives for anything like that. E.g. /run/user/{uid}, ~/.local/{bin,share,state,etc.}, systemd PrivateTemp etc. - so any program running as user not wanting to use flock should place their lock file in `/run/user/{uid}` like e.g. pipewire, wayland, docker and similar do (specifically $XDG_RUNTIME_DIR which happens to be `/un/user/{uid}`) So the only programs affected by it are programs which: - don't run as root - don't use flock - and don't really follow best practices introduced with the XDG standard either - ignore that it was quite predictable that /var/lock will get limited or outright removed due to long standing efforts to remove global writable dirs everywhere i.e. software stuck in the last century, or in this case more like 2 centuries ago in the 2000th But that is a common theme with Debian Stable, you have to fight even to just remove something which we know since 20 years to be a bad design. If it weren't for Debians reputation I think the systemd devs might have been more surprised by this being an issue then the Debian maintainers about some niche tools using outdated mechanisms breaking.
dsr_ 1y ago
That has been their method since the beginning; why would they change from a tactic which works for them? The central problem with systemd is that they don't want to let you go about your business, they want you to conform to their rule.
- nullpoint420 1y ago
  The central problem with Linux is that it forces you to conform to everything being a files, including device and IO. I’ll stick to MSDOS where I can go about business poking memory myself to control the hardware. /s My point being is that contracts between systems can improve our lives. We take the process, file, and protected memory models for granted today. However, I’m sure people hated the migration to protected systems as well because it “didn’t let them go about their business”
gwd 1y ago
In this case, I think the upstream maintainer's response -- "Upstream systemd will do X, distros who want to are free to do Y" -- is legitimate. Consider the reverse: If systemd requires a writable /run/lock, then distros who want to be more safe won't really be able to (or will have to implement a much more intrusive patch). Looking from the outside, it looks more that this is a failure of the Debian systemd package maintainer to follow Debian's rules. (Though since I'm not a part of that community, I recognize that there may be cultural expectations I'm not aware of.)
- bayindirh 1y ago
  > "Upstream systemd will do X, distros who want to are free to do Y" Yes this is a good response from upstream. I can work with that, but in that case, even this response didn't get reflected to mailing list discussion, or drowned out instantly. My question was more general though, questioning systemd developers' behavior collectively (hence the projects' behavior) through time.
  - bluGill 1y ago
    The systemd developers have a long history of reinventing the wheel and trying to force it on everyone. We only put up with them because they do some difficult work that nobody wants to do.
    - 9dev 1y ago
      Speak for yourself, then. I’ve been using Linux since 2004, and the systemd components finally made system management easy. No more arcane init scripts. Handling of service dependencies. Proper timers. Simple configuration files. Administration knowledge that immediately carries over between all systems equally. As a user, systemd has improved my productivity tremendously. The kind of bad mouthing developers that work on solutions for complex problems, code that runs on billions of machines, reflects more of your own fragile ego than them.
      - gwd 1y ago
Suzuran 1y ago
[flagged]
- bayindirh 1y ago
  Oh, so can we hit people on the nose just because what we say is right? That's a new one. What if they are also right, and we start fighting? Maybe people can discuss instead of bullying each other? Being able to code doesn't give license to being rude.
crest 1y ago
In this case I assume their "fear" is that unprivileged users can exhaust resources (inodes, filesystem space) in an important tmpfs breaking the system. The proper solution for backward compatibility would probably be something like make /run/lock its own mountpoint, but they fixed it in their system (Fedora) so now it's no longer their problem. Just be thankful their software is portable to such strange niche operating systems like Debian. /s
- ishouldbework 1y ago
  Funny part is that it used to be a separate file system, before Luca decided to kill it. https://lwn.net/Articles/1041948/ https://lwn.net/Articles/1041948/
advisedwang 1y ago
Linux is 34 years old, and some of the Unix-ism borrowed are even older. There is genuine cruft that has downsides. Different relative priorities of backwards comparability, maintainability and the various issues the legacy issues cause are reasonable. Systemd basically arose out of a frustration at the legacy issues so the whole project exists as a modernizing effort. No wonder they consider backwards compatibility low priority.
toast0 1y ago
Because that's what they've always done, and it continues to work for them? Systemd doesn't work for me, but it has taken over most Linux distributions, so clearly it's got something people want that I don't understand. That was the case for PulseAudio too.
blibble 1y ago
well the primary author does work for Microsoft a company that considers "consent" to be a dirty word
righthand 1y ago
Probably because everyone lets them keep getting away with it. Any time there's systemd criticism there's always a quick rebuttal "But it was too hard writing anything in any other init system before so stop complaining". So there's enough pass being given from the start to Systemd and the developers because it always has been forced upon us.

TacticalCoder 1y ago

First before venting I'll say this: thanks to stuff like hypervisors, VMs, non-systemd distros, minimal immutable Linux distro like Talos (made to run Kubernetes with a minimum number of executable) and OCI containers where, by definition, PID 1 is not systemd, there's thankfully a real way out of systemd, even on a Linux stack. And I think more people should look into being, once again, 100% systemd-free. > Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas? Because the goal is to take control of Linux. That's why systemd is PID1. That's why Poettering works for Microsoft. The real question is: why was that ultra-convoluted xz backdoor attempt only working on Linux systems that did have systemd? People shall try to wag the dog saying "but it's because this and that made is so that xz was loaded by OpenSSH, it's got nothing to do with systemd". It's got everything to do with systemd. And the other question is: how many backdoors are operational, today, on systems that have systemd? Systemd is Microsoft-level bloat, running as PID 1, spreading its tentacles everywhere in Linux distros, definitely on purpose. Poettering is moreover an insufferable bully, as can be seen once again. From TFA: > So what do you recommend how to go on from here? Change Debian policy (as asked in #1111839), revert the change in systemd, find a Debian wide solution or let every package maintainer implement their own solution? I suggest Debian just drops systemd once and for all. Debian can still be made systemd-free but it's a hassle. Just make Debian systemd free once again. Meanwhile you'll find me running systemd-less distros on VMs and running containers giving the PID 1 finger to systemd. I can't wait to switch my Proxmox to FreeBSD's bhyve hypervisor (need to find the time to do it). But most of all: I cannot wait for the day a systemd-less hypervisor Linux like Proxmox comes out. It's coming and people who write stuff like: "Don't use Docker, use systemd this and systemd that" are misguided. systemd is to me the antithesis of what Linux stands for. I hope Debian gets pissed enough at some point to fully drop systemd. P.S: one of my machine runs this: https://www.devuan.org/ https://www.devuan.org/ and honestly it's totally fine. So yup: power to all those running systemd-less distros, BSDs, etc.

ho_schi 1y ago

Did you read the same article? * Their is an option for the old behavior. * It is a security issue and better solutions to replace exist. * FHS isn't maintained. I think everyone involved would prefer updates to the applications, which fix the issue. Debian opted - for now - for reliability for its users, which fits in their mission statement. On Arch /run/lock is only writeable for the superusers, which improves security. As user I value reliability and security and that legacy tools remain usable (sometimes by default, sometimes by a switch).

gwd 1y ago
> On Arch /run/lock is only writeable for the superusers, which improves security. Does it? That means anyone who needs a lock gets superuser, which seems like overkill. Having a group with write permissions would seem to improve security more?
- dathinab 1y ago
  no that isn't what it means at all a global /run/lock dir is an outdated mechanism not needed anymore when the standard was written (20 years ago) it standardized a common way programs used to work around not having something like flock. This is also reflected in the specific details of FHS 3.0 which requires lock files to be named as `LCK..{device_name}` and must contain the process id in a specific encoding. Now the funny part. Flock was added to Linux in ~1996, so even when the standard was written it was already on the way of being outdated and it was just a matter of time until most programs start using flock. This brings is to two ways how this being a issues makes IMHO little sense: - a lot of use cases for /var/lock have been replaced with flock - having a global writable dire used across users has a really bad history (including security vulnerabilities) so there have been ongoing affords to create alternatives for anything like that. E.g. /run/user/{uid}, ~/.local/{bin,share,state,etc.}, systemd PrivateTemp etc. - so any program running as user not wanting to use flock should place their lock file in `/run/user/{uid}` like e.g. pipewire, wayland, docker and similar do (specifically $XDG_RUNTIME_DIR which happens to be `/un/user/{uid}`) So the only programs affected by it are programs which: - don't run as root - don't use flock - and don't really follow best practices introduced with the XDG standard either - ignore that it was quite predictable that /var/lock will get limited or outright removed due to long standing efforts to remove global writable dirs everywhere i.e. software stuck in the last century, or in this case more like 2 centuries ago in the 2000th But that is a common theme with Debian Stable, you have to fight even to just remove something which we know since 20 years to be a bad design. If it weren't for Debians reputation I think the systemd devs might have been more surprised by this being an issue then the Debian maintainers about some niche tools using outdated mechanisms breaking.

dsr_ 1y ago

That has been their method since the beginning; why would they change from a tactic which works for them? The central problem with systemd is that they don't want to let you go about your business, they want you to conform to their rule.

nullpoint420 1y ago
The central problem with Linux is that it forces you to conform to everything being a files, including device and IO. I’ll stick to MSDOS where I can go about business poking memory myself to control the hardware. /s My point being is that contracts between systems can improve our lives. We take the process, file, and protected memory models for granted today. However, I’m sure people hated the migration to protected systems as well because it “didn’t let them go about their business”

gwd 1y ago

In this case, I think the upstream maintainer's response -- "Upstream systemd will do X, distros who want to are free to do Y" -- is legitimate. Consider the reverse: If systemd requires a writable /run/lock, then distros who want to be more safe won't really be able to (or will have to implement a much more intrusive patch). Looking from the outside, it looks more that this is a failure of the Debian systemd package maintainer to follow Debian's rules. (Though since I'm not a part of that community, I recognize that there may be cultural expectations I'm not aware of.)

bayindirh 1y ago
> "Upstream systemd will do X, distros who want to are free to do Y" Yes this is a good response from upstream. I can work with that, but in that case, even this response didn't get reflected to mailing list discussion, or drowned out instantly. My question was more general though, questioning systemd developers' behavior collectively (hence the projects' behavior) through time.
- bluGill 1y ago
  The systemd developers have a long history of reinventing the wheel and trying to force it on everyone. We only put up with them because they do some difficult work that nobody wants to do.
  - 9dev 1y ago
    Speak for yourself, then. I’ve been using Linux since 2004, and the systemd components finally made system management easy. No more arcane init scripts. Handling of service dependencies. Proper timers. Simple configuration files. Administration knowledge that immediately carries over between all systems equally. As a user, systemd has improved my productivity tremendously. The kind of bad mouthing developers that work on solutions for complex problems, code that runs on billions of machines, reflects more of your own fragile ego than them.
    - gwd 1y ago

Suzuran 1y ago

[flagged]

bayindirh 1y ago
Oh, so can we hit people on the nose just because what we say is right? That's a new one. What if they are also right, and we start fighting? Maybe people can discuss instead of bullying each other? Being able to code doesn't give license to being rude.

crest 1y ago

In this case I assume their "fear" is that unprivileged users can exhaust resources (inodes, filesystem space) in an important tmpfs breaking the system. The proper solution for backward compatibility would probably be something like make /run/lock its own mountpoint, but they fixed it in their system (Fedora) so now it's no longer their problem. Just be thankful their software is portable to such strange niche operating systems like Debian. /s

ishouldbework 1y ago
Funny part is that it used to be a separate file system, before Luca decided to kill it. https://lwn.net/Articles/1041948/ https://lwn.net/Articles/1041948/

advisedwang 1y ago

Linux is 34 years old, and some of the Unix-ism borrowed are even older. There is genuine cruft that has downsides. Different relative priorities of backwards comparability, maintainability and the various issues the legacy issues cause are reasonable. Systemd basically arose out of a frustration at the legacy issues so the whole project exists as a modernizing effort. No wonder they consider backwards compatibility low priority.

toast0 1y ago

Because that's what they've always done, and it continues to work for them? Systemd doesn't work for me, but it has taken over most Linux distributions, so clearly it's got something people want that I don't understand. That was the case for PulseAudio too.

blibble 1y ago

well the primary author does work for Microsoft a company that considers "consent" to be a dirty word

righthand 1y ago

Probably because everyone lets them keep getting away with it. Any time there's systemd criticism there's always a quick rebuttal "But it was too hard writing anything in any other init system before so stop complaining". So there's enough pass being given from the start to Systemd and the developers because it always has been forced upon us.