Systemd wants to expand to include a sudo replacement
Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
You're viewing a single thread.
When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?
This isn't a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.
SystemD will consume the entirety of Linux, bit by bit.
I think you might want to recheck the ages of some of the people in your timeline, most of them aren't that young anymore.
Yes, because it's easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.
Debian already uses systemd.
Debian in many ways isn't as slow-moving as people think.
For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won't have that until 2025/2026 or beyond.
Sadly they've been dropping archs throughout the years, meaning they're no longer the distro you can use to run on "anything" from a pi to a mainframe...
Doesn't trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.
Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.
And looking through the Wikipedia article for Debian's version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)
If your bar is "modern distribution" stick to Ubuntu.
If you want to maintain older hardware Debian used to be a go-to solution.
What's the go-to solution now?
Most likely LFS or some tailored distro I haven't heard of.
Probably the weirdest joke comment I've ever read.
Thanks for that write up. Made my day! 😄
That comment was brought to you by an AI LLM. No one actually took the time to write that.
Nope, doesn't have any of the hallmarks of an LLM and LLMs aren't yet clever enough to produce original humor like that.
🥴
This is a script of Simpsons episode and Torvalds will actually die in 2058.
Dude if you made a movie or novel about this that would be awesome
One way to notice a person has "systemd derangement syndrome" is by looking at how they write systemd: if they write it SystemD they are already in late stages of SDS and it isn't curable anymore.
Either that, or it's a joke.
When does systemd stop?
"systemd announces a repleacement module for the kernel"
HurD
By this logic the Linux kernel is also a single point of failure and attack vector.
sudo isn't going away, so does doas. run0 is just another alternative to use or not.
There are still distribution out there without systemd and if there ever won't be any systemd-free distributions left and systemd would become a critical part of the Linux ecosystem, then it would get the same treatment as the Linux kernel with many professional maintainers.
plus, it isn't like this isn't exactly like adding another "door" to the "systemd building". It's a modular component of systemd, so more akin to replacing the sudo building with a new, but still separate, systemd sudo building
@Olap
I agree. As someone who uses systemd on daily basis (I use Arch, BTW 😄) I really like it, but I am a bit worried about it being a single point of attack. Maybe just push doas as default instead? I never used doas but I watched few videos about it, so I guess it's fine and probably better than sudo (less bloated).
Just my few cents.
I don't see how something would be inherently easier to attack if it is called systemd-foo instead of just foo. Attack surface and vectors do not depend on which project develops a particular tool.
I'd be willing to bet it's people fearing another xz-like situation
Gentoo, Slackware and Devuan can be used without svchost for linux.
They'll only stop when they rebrand it to systemd OS.
Gentoo, Slackware and Devuan can be used without svchost for linux.
https://nosystemd.org has a list for more choice for readers.
Debian works fine without systemd too, there's a page on the wiki on how to install without it, or remove it after the fact.
A lot of debs add services to systemd, do those just skip that part?
They seem to. Debian explicitly supports multiple init systems, sysvinit being the primary alternative, so packages have to handle systemd-init not being there.
Easy with sudo apt remove --purge --allow-remove-essential --auto-remove systemd:
:-D Time to go outside.
Systemd is a bit of a hassle to be rid off, but thankfully it's not actually that hard, the hardest part I found was converting systemd services to whatever init system I use.
I wonder how many hours you sunk into that practicality-free, weird-philosopy-dependent project
Probably not much time, a lot of packages come with init scripts anyway, and they're pretty trivial to write if not.
You can certainly argue it's a philosophical choice, I'd say it's more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.
Systemd is fine. If it wasn't, most distros wouldn't have switched to it years ago.
Let's agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.
The arguments against systemd are very unconvincing but more importantly, there is zero evidence that they actually matter.
And it works.
Further, in order to represent this as a nearly unilateral decision you failed to mention that arch, centos, and opensuse all opted in independently.
And no offense but angry Internet randos arguing software philosophy will never convince me to disagree with the creator of the Linux kernel.
Linus Torvalds said:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I obviously find the arguments against systemd more persuasive than you do, and that's fine, it's all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don't work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.
Of the distros you mentioned, centos is a RHEL derivative and so wasn't independent, arch packages multiple init systems, but yes, I'd forgotten opensuse, and they seem to be firmly in the systemd camp.
I may be an internet rando, but I'm not actually angry, more just disappointed. I'd agree with Mr Torvald's opinion that some of the design details are insane, but I think they are more fundamental than just 'details' as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he's always tended to be more relaxed about the layers above it.
That the developers of systemd are 'much too cavalier about bugs and compatibility' is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.
That quote carries the opposite connotation of what you seem to take from it. He's saying despite having issues with the devs, he acknowledges those issues probably don't matter.
I admit I don't understand the internals of any of these systems. But I do understand that if the creator of the kernel isn't concerned about systemd, and that if the vast majority of distros use systemd, then it indeed works well enough. The systemd apocalypse never happened and likely never would happen.
I see this argument as software conservatism. The rest of us will be okay with the thousands of knowledgeable developers that seem to think systemd works just fine.
I'm not disputing that he doesn't think the issues are major, as I said, he's usually pretty ambivalent about what runs on the kernel, so they're not issues he cares about. On the flip side, I do care what is running because I have to manage and support it.
I do wonder if we're talking at cross purposes though. You seem to mostly be talking about the systemd init system, I'm mostly talking about all the other bits it, as a sort of umbrella project, tries to encompass. I don't much like the init system, I prefer to be able to explicitly set the ordering of the steps, rather than having them inferred, and I prefer shell script that I can test to unit files, but it mostly works ok. So does every other init system though, so it's not a selling point.
As I said, the big problem is around how they've tried to do everything, much of it less well than what they're replacing. Yes, you can build a system that uses systemd-init and none of the other components, but that still drags in a load of other dependencies, so you might as well use a different init that's smaller and cleaner.
We came close to the 'systemd apocalypse' recently, when distros hooked the systemd library into openssh without understanding just how bloated it is and how many poorly monitored dependencies it brought in. It was just luck that the right person spotted a slight change in timing and investigated.
Ultimately I suppose it comes down to the level you interact with your systems at. If you just want to install your OS, a few packages they directly support and let it get on with it, then you probably neither know nor care that you run systemd, and that's great. On the other hand, in my experience, when you try to push the system past that and do anything more customized you start running into the sharp edges and misfeatures on the various systemd components.
took me about an hour to get started with artix originally, and maybe a couple more to really familiarize myself with the init. As for practicallity, it's been a large improvement for me.
