6 ms·

Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux

by b112 3y ago

Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit. I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. Systemd is a step backwards.

TacticalCoder 3y ago
> Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.
- rahen 3y ago
  Take a look at S6 and dinit. They both embody what systemd was intended to be while keeping the portability, technical simplicity and loose coupling. You might also want to consider Void and Chimera. Void has a unique combination of technical simplicity, functionality, rolling updates and low maintenance along with some beefy repos. It's close to being the perfect desktop Linux to me. Chimera uses dinit, which is closer to systemd's features, whereas Void uses runit, with is more of a minimal viable init + rc.
  - MrDrMcCoy 3y ago
    They are very interesting for sure, but I'm waiting for the S6 successor that's in development before I switch from systemd. There are a number of things systemd offers that are either easier, better, or unavailable in other tools that keep me happy for now. If the successor ends up being good but still missing those features, I'll try my hand at implementing them for the greater good.
    - DEADMINCE 3y ago
      >I'm waiting for the S6 successor that's in development Of what do you speak?
      - MrDrMcCoy 3y ago
        https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
- eropple 3y ago
  > Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. ... We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? systemd was pretty consciously patterned after launchd, not svchost. The goal was, and for good reasons, to make Linux behave like a more integrated Unix-like that already existed: MacOS. Benno Rice has an excellent presentation on systemd that's worth watching through to the end; unlike most of the table-pounding (and "it's just svchost.exe!!" is exactly that), he provides what I think is a pretty fair--and, interestingly to me, a BSD-grounded--view as to where systemd is strong and is weak. https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
  - hedora 3y ago
    The thing is, I own a mac, and I've never had to touch launchd. I've hit severe systemd bugs on 100% of the linux desktop installs I've set up in the last 5-10 years. (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on). The fact that pid 1 can even be involved in those sorts of userspace bugs shows how broken the architecture is.
    - olddustytrail 3y ago
      They aren't. You have no idea how init systems work. I've no idea what kind of broken thinking leads you to believe anything you've written. What exactly do you think is running with pid 1 and what do you think that means?
    - CoolCold 3y ago
      Oh, Linux on desktop year yet to come- hopefully this will save you ton of efforts and time.
    - pelasaco 3y ago
      > (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on). I used to be release manager for a Linux distro. Mostly, such issues were integration problem and not a systemd problem. In some cases that I worked on, the integration wasnt well-thought, or it was done in some amateurish way which needed actually some extra hours of professional software development to make it "production ready". Unfortunately part of the process of working with open source.
- jasomill 3y ago
  Are you referring to svchost.exe, the performance hack that allows multiple Microsoft-supplied services to share a single process, or the Service Control Manager[1], the Windows component responsible for starting and stopping Windows services? If the former, I agree that trading off service process isolation for reduced start time and lower resource usage is an optimization that has probably outlived its usefulness and should not be emulated on systems that aren't severely resource-constrained. While systemd arguably bundles too much functionality into its own process, AFAIK it doesn't include any mechanisms to support svchost.exe-like behavior in services it controls. If the latter, I'd argue that the SCM is actually quite minimalistic, especially in comparison with systemd: it's responsible for starting services in the correct order per a supplied list of dependencies, restarting failed services, notifying services of important lifecycle events — service configuration changes, shutdown requests, network interface status changes, etc. — and that's about it. [1] https://learn.microsoft.com/en-us/windows/win32/services/service-control-manager https://learn.microsoft.com/en-us/windows/win32/services/ser...
anthk 3y ago
I've got ziliions on issues with SystemD. The first one, trying to shut down the machine.
VancouverMan 3y ago
> I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. It's been the same situation for me, too. Every time I get stuck dealing with a new systemd-related problem and search online for solutions, the huge number of bug reports, mailing list posts, forum posts, IRC logs, and other communications I incidentally see describing my problem and/or other troubles involving systemd remind me that I'm not alone. Many other people are consistently having a wide variety of problems with it, too, and this has now been going on for years and years. Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible. Their init systems aren't perfect, but they almost never cause me problems. In the very rare cases when they aren't working for some reason, at least those systems are simple enough that I can usually debug the issue on my own, without having to search for help online.
- fullstop 3y ago
  Can you describe one of your problems? I've had very smooth sailing with systemd and I like not having to play games with pid files and pgrep like I had to in the 90s.
  - foresto 3y ago
    I can't speak for VancouverMan, but my experience has been similar. A few examples of the problems I have with systemd: System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted. Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope -p "Delegate=yes" <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable. At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back. There are more examples, but I'm tired of re-living them and don't really want to write a book.
ThePowerOfFuet 3y ago
>Systemd is a step backwards. _A_ step backwards?

by b112 3y ago

TacticalCoder 3y ago

> Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.

rahen 3y ago
Take a look at S6 and dinit. They both embody what systemd was intended to be while keeping the portability, technical simplicity and loose coupling. You might also want to consider Void and Chimera. Void has a unique combination of technical simplicity, functionality, rolling updates and low maintenance along with some beefy repos. It's close to being the perfect desktop Linux to me. Chimera uses dinit, which is closer to systemd's features, whereas Void uses runit, with is more of a minimal viable init + rc.
- MrDrMcCoy 3y ago
  They are very interesting for sure, but I'm waiting for the S6 successor that's in development before I switch from systemd. There are a number of things systemd offers that are either easier, better, or unavailable in other tools that keep me happy for now. If the successor ends up being good but still missing those features, I'll try my hand at implementing them for the greater good.
  - DEADMINCE 3y ago
    >I'm waiting for the S6 successor that's in development Of what do you speak?
    - MrDrMcCoy 3y ago
      https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
eropple 3y ago
> Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. ... We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? systemd was pretty consciously patterned after launchd, not svchost. The goal was, and for good reasons, to make Linux behave like a more integrated Unix-like that already existed: MacOS. Benno Rice has an excellent presentation on systemd that's worth watching through to the end; unlike most of the table-pounding (and "it's just svchost.exe!!" is exactly that), he provides what I think is a pretty fair--and, interestingly to me, a BSD-grounded--view as to where systemd is strong and is weak. https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
- hedora 3y ago
  The thing is, I own a mac, and I've never had to touch launchd. I've hit severe systemd bugs on 100% of the linux desktop installs I've set up in the last 5-10 years. (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on). The fact that pid 1 can even be involved in those sorts of userspace bugs shows how broken the architecture is.
  - olddustytrail 3y ago
    They aren't. You have no idea how init systems work. I've no idea what kind of broken thinking leads you to believe anything you've written. What exactly do you think is running with pid 1 and what do you think that means?
  - CoolCold 3y ago
    Oh, Linux on desktop year yet to come- hopefully this will save you ton of efforts and time.
  - pelasaco 3y ago
    > (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on). I used to be release manager for a Linux distro. Mostly, such issues were integration problem and not a systemd problem. In some cases that I worked on, the integration wasnt well-thought, or it was done in some amateurish way which needed actually some extra hours of professional software development to make it "production ready". Unfortunately part of the process of working with open source.
jasomill 3y ago
Are you referring to svchost.exe, the performance hack that allows multiple Microsoft-supplied services to share a single process, or the Service Control Manager[1], the Windows component responsible for starting and stopping Windows services? If the former, I agree that trading off service process isolation for reduced start time and lower resource usage is an optimization that has probably outlived its usefulness and should not be emulated on systems that aren't severely resource-constrained. While systemd arguably bundles too much functionality into its own process, AFAIK it doesn't include any mechanisms to support svchost.exe-like behavior in services it controls. If the latter, I'd argue that the SCM is actually quite minimalistic, especially in comparison with systemd: it's responsible for starting services in the correct order per a supplied list of dependencies, restarting failed services, notifying services of important lifecycle events — service configuration changes, shutdown requests, network interface status changes, etc. — and that's about it. [1] https://learn.microsoft.com/en-us/windows/win32/services/service-control-manager https://learn.microsoft.com/en-us/windows/win32/services/ser...

anthk 3y ago

I've got ziliions on issues with SystemD. The first one, trying to shut down the machine.

VancouverMan 3y ago

> I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. It's been the same situation for me, too. Every time I get stuck dealing with a new systemd-related problem and search online for solutions, the huge number of bug reports, mailing list posts, forum posts, IRC logs, and other communications I incidentally see describing my problem and/or other troubles involving systemd remind me that I'm not alone. Many other people are consistently having a wide variety of problems with it, too, and this has now been going on for years and years. Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible. Their init systems aren't perfect, but they almost never cause me problems. In the very rare cases when they aren't working for some reason, at least those systems are simple enough that I can usually debug the issue on my own, without having to search for help online.

fullstop 3y ago
Can you describe one of your problems? I've had very smooth sailing with systemd and I like not having to play games with pid files and pgrep like I had to in the 90s.
- foresto 3y ago
  I can't speak for VancouverMan, but my experience has been similar. A few examples of the problems I have with systemd: System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted. Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope -p "Delegate=yes" <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable. At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back. There are more examples, but I'm tired of re-living them and don't really want to write a book.

ThePowerOfFuet 3y ago

>Systemd is a step backwards. _A_ step backwards?