Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
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.
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.
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.
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.