3 ms·

> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. Th

> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.

traverseda 2y ago
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
b112 2y 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 2y 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 2y 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 2y 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 2y ago
- anthk 2y ago
  I've got ziliions on issues with SystemD. The first one, trying to shut down the machine.
- VancouverMan 2y 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 2y 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 2y 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 2y ago
  >Systemd is a step backwards. _A_ step backwards?
chillfox 2y ago
I have gone from systemd on RedHat to OpenRC on Alpine (have used both for years). Systemd is much more unstable and frustrating to work with. I do wish something like s6 was the default on Alpine, it’s been quite nice when I have used it in containers.
- CoolCold 2y ago
  Mind sharing couple of examples? I do have bunch of servers on Centos 7, which is quite old and have met just couple of minor issues related to systemd, never had a downtime because of it. I'd say NOC doing some networking maintenance brings me more problems then systemd.
DEADMINCE 2y ago
> but systemd is just the evolution that Linux needed to become what it is today. Not at all. The linux of today doesn't owe anything to systemd, is not radically different from when systemd didn't exist, and arguably we would have a better alternative if systemd had never been adopted.
- pelasaco 2y ago
  > arguably we would have a better alternative if systemd had never been adopted. Not true. We have many alternatives, adopted in some distros. But AFAIK no Enterprise distro. For servers or desktop.. why? because systemd starts as many services as possible in parallel this speeds the overall startup and gets the host system to a login screen or reduce the server downtime dramatically than SystemV. That is for sure a well wanted characteristics today...

traverseda 2y ago

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.

b112 2y 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 2y 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 2y 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 2y 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 2y ago
anthk 2y ago
I've got ziliions on issues with SystemD. The first one, trying to shut down the machine.
VancouverMan 2y 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 2y 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 2y 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 2y ago
>Systemd is a step backwards. _A_ step backwards?

chillfox 2y ago

I have gone from systemd on RedHat to OpenRC on Alpine (have used both for years). Systemd is much more unstable and frustrating to work with. I do wish something like s6 was the default on Alpine, it’s been quite nice when I have used it in containers.

CoolCold 2y ago
Mind sharing couple of examples? I do have bunch of servers on Centos 7, which is quite old and have met just couple of minor issues related to systemd, never had a downtime because of it. I'd say NOC doing some networking maintenance brings me more problems then systemd.

DEADMINCE 2y ago

> but systemd is just the evolution that Linux needed to become what it is today. Not at all. The linux of today doesn't owe anything to systemd, is not radically different from when systemd didn't exist, and arguably we would have a better alternative if systemd had never been adopted.

pelasaco 2y ago
> arguably we would have a better alternative if systemd had never been adopted. Not true. We have many alternatives, adopted in some distros. But AFAIK no Enterprise distro. For servers or desktop.. why? because systemd starts as many services as possible in parallel this speeds the overall startup and gets the host system to a login screen or reduce the server downtime dramatically than SystemV. That is for sure a well wanted characteristics today...