As much as I am ambivalent about Poettering projects, and as much as I really don’t like the all-encompassing nature of systemd, in my experience, systemd has basically worked.
PulseAudio, his previous thing, was an absolute dumpster fire in terms of breakage when it came out and continued to be for years. I had multiple systems spanning a number of sound devices that had all kinds of issues with it. It also added a lot of complexity to an already-complex sound stack.
I haven’t had systemd cause massive problems. At least from a user level, I haven’t seen it create complexity problems.
It breaks my familiarity with existing tools to some degree. I don’t know how to configure which virtual terminals exist and have a getty process running on them the way I did with traditional init. I don’t know systemd’s runlevel replacement.
But other software packages have done that too. Iproute2 did that with ip replacing route and ifconfig and similar. And my understanding is that there was a legitimate reason for that transition – IIRC multiple routing tables or something. The command-line Unix world is still pretty good about maintaining UI over time – transitions like this are pretty rare, compared to something like Windows.
Traditional init didn’t permit for parallel init, which especially in a world with SSDs and many-core processors, is, I think, desirable. I’m not saying that it had to be systemd – could have been Upstart or something. But I think that the switch to some form of init system that permitted parallel init needed to happen.
There was a real issue that traditionally existed with the concept of a user being locally logged in to the machine and having elevated permissions to physical devices, like sound hardware and CD drives and such, and my vague understanding is that systemd-logind handles some of this. That wasn’t historically handled very well.
Same thing for hotplugging and systemd-udevd.
I generally am not happy about a single software package taking a large role in distros, because IME, part of the way that distros can deal with problematic software packages is to drop them in favor of another, and something that is part of a large project has a lot of inertia.
But…you could say the same thing about GNOME or KDE. They’re both large software projects. They contain things, like a solitaire game, that don’t really need to be part of the larger package. And I don’t see people off trying to break them up. Okay, they aren’t as fundamental to the system, but the same scope creep argument can be made.
I agree with you, being a system admin, systemd has mostly just worked. It tries to be funny sometimes, but because I work on a server I don’t usually deal with some things that a user might have to work with.
Another person mentioned a continued usage of SysVInit on Debian: I’m going to try it myself. See how I like it. If it works for me then I’ll drop SystemD completely and even then I get to stick with Debian!
I haven’t seen any breakage, although you may find documentation assumes SystemD. Debian maintains init freedom, and support for sysVinit was improved in Bullseye, so it’s not being forgotten about.
If you don’t fancy going that route, there are Debian forks that are designed to be SystemD free such as Devuan or MX linux, which defaults to sysVinit. I’ve not tried either, but they seem well regarded, and I’m sure there are others too.
I wish Debian looks towards an alternative init
As much as I am ambivalent about Poettering projects, and as much as I really don’t like the all-encompassing nature of systemd, in my experience, systemd has basically worked.
PulseAudio, his previous thing, was an absolute dumpster fire in terms of breakage when it came out and continued to be for years. I had multiple systems spanning a number of sound devices that had all kinds of issues with it. It also added a lot of complexity to an already-complex sound stack.
I haven’t had systemd cause massive problems. At least from a user level, I haven’t seen it create complexity problems.
It breaks my familiarity with existing tools to some degree. I don’t know how to configure which virtual terminals exist and have a
gettyprocess running on them the way I did with traditional init. I don’t know systemd’s runlevel replacement.But other software packages have done that too. Iproute2 did that with
ipreplacingrouteandifconfigand similar. And my understanding is that there was a legitimate reason for that transition – IIRC multiple routing tables or something. The command-line Unix world is still pretty good about maintaining UI over time – transitions like this are pretty rare, compared to something like Windows.Traditional init didn’t permit for parallel init, which especially in a world with SSDs and many-core processors, is, I think, desirable. I’m not saying that it had to be systemd – could have been Upstart or something. But I think that the switch to some form of init system that permitted parallel init needed to happen.
There was a real issue that traditionally existed with the concept of a user being locally logged in to the machine and having elevated permissions to physical devices, like sound hardware and CD drives and such, and my vague understanding is that
systemd-logindhandles some of this. That wasn’t historically handled very well.Same thing for hotplugging and
systemd-udevd.I generally am not happy about a single software package taking a large role in distros, because IME, part of the way that distros can deal with problematic software packages is to drop them in favor of another, and something that is part of a large project has a lot of inertia.
But…you could say the same thing about GNOME or KDE. They’re both large software projects. They contain things, like a solitaire game, that don’t really need to be part of the larger package. And I don’t see people off trying to break them up. Okay, they aren’t as fundamental to the system, but the same scope creep argument can be made.
I agree with you, being a system admin, systemd has mostly just worked. It tries to be funny sometimes, but because I work on a server I don’t usually deal with some things that a user might have to work with.
Another person mentioned a continued usage of SysVInit on Debian: I’m going to try it myself. See how I like it. If it works for me then I’ll drop SystemD completely and even then I get to stick with Debian!
Debian works fine with SysV init currently, there’s even a page on their wiki on setting it up: https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time
Source: have been happily using Sysv init on Debian for years. Working on SystemD servers feels incredibly painful in comparison.
Maybe I should take a stab at it, I knew it was maintained in some capacity but I thought most of userland would break without Systemd
I haven’t seen any breakage, although you may find documentation assumes SystemD. Debian maintains init freedom, and support for sysVinit was improved in Bullseye, so it’s not being forgotten about.
If you don’t fancy going that route, there are Debian forks that are designed to be SystemD free such as Devuan or MX linux, which defaults to sysVinit. I’ve not tried either, but they seem well regarded, and I’m sure there are others too.