7 ms·

I have to admit, having recently spent some time learning it and updating my Linux skills I really don't understand why systemd seems to have provoked so much h

I have to admit, having recently spent some time learning it and updating my Linux skills I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. So far I really like it. It makes a Linux server feel more like something designed rather than incrementally patched together out of hacky shell scripts written 20 years ago. The unit config files are small and simple. Every line makes sense. Things are coherent - learning how to start a service at bootup means you've partly learned how to configure the new equivalent of cron jobs. The same configuration works at the system and per-user level. You can quickly locate logs. I didn't quite like the command line interface at first e.g. why "systemctl" and not "service", plus I always forget if it's the service name in the second or first position. But the basic functionality is all there. I realise Docker is all the rage at the moment but I've found it kind of flaky and complicated. For my own purposes systemd feels about the right level of abstraction. It's not picky about where software comes from, it just manages it. You can unzip a tarball and make it run isolated, depend on other services, and a whole lot of other neat things. If you've learned it on one distro you learned it for the rest, unlike SysV init. And it seems to constantly get more useful features that are all pretty easy to configure as well.

2OEH8eoCRo0 7y ago
>I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. Because the OSS community is dense with insecure and pedantic neckbeards. Lennart Poettering, Systemd's creator, has received death threats over it ffs. I too find it quite elegant and easy to use.
- benhameen 7y ago
  https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
  - exo762 7y ago
    Oh, the talk that made me learn systemd. Must see.
- yarrel 7y ago
  Lennart should not receive death threats.
traverseda 7y ago
>having recently spent some time learning it and updating my Linux skills It has gotten better over time. If you're just updating it now you're probably not having nearly as rough a time of it as you would back when it was first being pushed. The documentation was pretty terrible and things would break randomly a fair bit. I've had multiple occasions where my networking just stopped working due to systemd components. One thing I still find annoying is how "enterprise-ey" it is. There's no "put all your unit files here" easy to look at folder, you need to first use some systemd specific command to find out exactly which of the many many sub folders the unit file lives in. There's also a tendency to split configuration across many different files, which I guess is how we always did it but somehow seems more annoying when coupled with the whole "you don't get to know where the unit file is" system. Like one service could have 3 or 4 different unit files if it's complicated, if it relies on socket activation or mount points or times or anything like that. One of my biggest (practical) complaints these days is simply that everything is spread out all over the filesystem.
- thu2111 7y ago
  Yeah that's true. I don't really understand yet why timers and sockets are in separate files to services.
HugoDaniel 7y ago
You can read up on https://suckless.org/sucks/systemd/ https://suckless.org/sucks/systemd/ It is a good primer into why systemd provoke(d|s) so much hate and controversy.
- qqssccfftt 7y ago
  > What PID 1 Should Do > When your system boots up the kernel is executing a given binary in its known namespace. To see what are the only tasks the application running as pid 1 has to do, see sinit. Just wait for child process to reap and run some other init scripts. Very objective and balanced article!
  - stonewareslord 7y ago
    Did you read the source of sinit? It's an example of what init can look like. Check out the <90 source code here: https://git.suckless.org/sinit/file/sinit.c.html https://git.suckless.org/sinit/file/sinit.c.html I don’t think they’re trying to push sinit as a replacement, they’re showing just how bloated their init system has gotten.
- Koshkin 7y ago
  sinit looks like another extreme: systemd does (almost) everything, sinit does (almost) nothing. I think a good design is somewhere in between.
  - rleigh 7y ago
    I strongly disagree. PID1 is a single point of failure for the entire system. If it crashes, the kernel will immediately panic. Try it out yourself and see. A good design would move every last bit of complexity out of PID1, leaving PID1 doing the absolute bare minimum required. There is no need for the vast majority of systemd's functionality and complexity to be physically present in the PID1 image. They could fork off another process to do that. I've always found that aspect of its design to be utterly bizarre. Jamming additional complexity into PID1 is fundamentally wrong, it's obviously a poor engineering choice, and there are plenty of better ways of architecting the system.
guenthert 7y ago
You didn't have to debug a system which failed to boot.
- benchaney 7y ago
  This. While systemd has a lot of issues that are obvious from a distance, everyone who hates it has had it break something because of a really stupid design decision it made.
castillar76 7y ago
Purely my perspective here, as a 25-year user of Linux and BSD (for context). On the one hand, I very much agree with you that Systemd brings a lot to the table. The files are much easier to work with, the service ordering and integration is logical and works well (to the extent I've beaten on it), and I can't deny that a faster boot sequence is helpful for things that boot often like container images. It's been a lot easier writing systemd config files for my new services than it was to write init.d boot scripts, for sure, and the integration of systemctl is really nice: one command does all the service things from info to disabling. The flip-side for me, the one that continues to get under my skin, is the approach of the systemd project. It's the habit systemd has of simply subsuming all other system functions into itself (DHCP client? Sure! DNS client? Mine now! Logging? We handle that now. Firewall control? ALL SHALL BE ASSIMILATED.). If the systemd versions of those functions were both obvious in presence and easy to replace with more fully functional replacements when I wanted, I'd feel better about it, but I keep running across cases where system functions that have worked that way since Linus was in knee-pants have suddenly been replaced behind the scenes with a systemd module whose configuration files and knobs aren't obvious or well-documented, it's difficult-to-impossible to uninstall, and trying to disable and replace it leads to cascading failures. Worse, I keep seeing security issues brought up to the systemd devs and then tossed aside with "well, just don't do that" or "how is that even a problem". It's not pervasive or constant, but it's steady enough to be worrying. Obviously not every security issue raised will be top priority, but it concerns me how much of my systems are being subsumed by a project that seems to prioritize "do all the things now" over "do things securely". Compare that to the approach taken by, say, OpenBSD, which has also been steadily replacing long-standing system bits with their own custom-developed pieces. Their approach has been "we will provide basic functionality that is iron-clad secure", while leaving you the ability to swap in something else for stuff like OpenSMTPd without breaking your system. And yes, Theo can be just as much an <unprintable> as Poettering, but I'm a lot less worried about the outputs of his work for the above reasons. Ultimately I think systemd is a good way forward, but it needs someone else to take over the project, rein it in, and keep it focused on being good at what it does rather than trying to be all things everywhere. Or, alternately, it needs to just implement its own kernel and go off to be SystemdOS v1, which seems to be the trajectory it's on right now.
- 7y ago
hiram112 7y ago
I don't really mind Systemd as a replacement for init, it's just that other unrelated systems are now requiring it explicitly that probably shouldn't (e.g. Gnome) and also Systemd is creating more and more sub projects that replace even more standard Unix functionality. Let's see: 1. Systemd-network is a whole replacement for Network Manager, which itself was bloated compared to old ifcfg files and other simple tools that manage just single aspects of the network (dhcp, wifi, etc.) 2. Systemd-resolved - replaces everything that deals with DNS. This really bothered me when it was discovered that it was ignoring certain standard configurations such that users using VPNs / encrypted DNS were leaking DNS lookups. That could get someone tossed in prison or worse in countries like Iran or China. * Systemd-logind - replaces various tools used for logging in to both X and the console. Seems like it's a mixed bag, though I know there was a lot of complaints because it broke standard behavior with tools like nohup. * Systemd-boot - replaces Grub and other similar tools. I hate Grub, so this doesn't really bother me. * Systemd-locale, hostname, timedate - these replace traditional tools dealing with the obvious features their names describe. This isn't a big deal to me as it's just replacing one simple tool with another, though I'm sure the dependencies will end up requiring a lot more unrelated systemd libs, which the original tools were completely stand -alone. Seems like more and more are coming out every year - encrypting and exporting home directories, partition managers, Cron, etc. Even if the replacements libs are better than the originals, it seems the developers purposefully make sure that the more of these projects your distro depends on, the more you're locked into all the other Systemd projects. This will be the end of BSDs and any other Linux distros that don't want to use any Systemd, or even a few of the smaller tools, because everything will eventually require the DBus and Systemd / Journald main libs. I'm not a Linux expert at this level, but it certainly reminds me of a few notorious Java libraries - you import a single library to use just a few methods, and all of the sudden your app has grown by 100MB of other dependencies that have no relation to your requirements, and it breaks everything because it adds all sorts of Servlet libraries that override and break things everywhere else. Usually the only way to keep things clean is to NOT use these libs or pull out just the source for the things you want. Interestingly, the libraries that have caused me the most trouble over the years were created by Redhat - you end up with all sorts of JBoss specific modules that, for no apparent good reason, override your logging, validation, web, etc. libs with their own versions.
na85 7y ago
In the early days of systemd it broke systems on the regular, and instead of humility, Lennart Poettering and his homies tended to react with ego and arrogance.
jcranmer 7y ago
> I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world A few major reasons: * It's originally written by the person who also wrote Pulseaudio, so any vitriol people have left over from Pulseaudio's configuration issues gets poured into systemd as well. * The project takes a monolithic approach to the problem of configuring services, and many people think that's wrong. [1] * It's change, and change means work for people who have their old setups. [1] This criticism is usually described as "it breaks the Unix model," a formulation I don't like because it's meaningless and an appeal to authority instead of articulating the issues they have with it. Watch how people try to explain how the similarly monolithic Linux kernel doesn't break the Unix model, it can be funny sometimes.
- kyuudou 7y ago
  > explain how the similarly monolithic Linux kernel doesn't break the Unix model It does one thing and one thing well: talk to hardware.
  - tptacek 7y ago
    Then what, all the other things it does it does poorly?
- thu2111 7y ago
  Right, what does monolithic approach to configuring services even mean? I seem to have hundreds of systemd services on my box, all of which appear to do a tiny part of system startup. That doesn't come across as very monolithic, if anything service overload is one of the things I dislike about systemd (but it wasn't better previously).

2OEH8eoCRo0 7y ago

>I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. Because the OSS community is dense with insecure and pedantic neckbeards. Lennart Poettering, Systemd's creator, has received death threats over it ffs. I too find it quite elegant and easy to use.

benhameen 7y ago
https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
- exo762 7y ago
  Oh, the talk that made me learn systemd. Must see.
yarrel 7y ago
Lennart should not receive death threats.

traverseda 7y ago

>having recently spent some time learning it and updating my Linux skills It has gotten better over time. If you're just updating it now you're probably not having nearly as rough a time of it as you would back when it was first being pushed. The documentation was pretty terrible and things would break randomly a fair bit. I've had multiple occasions where my networking just stopped working due to systemd components. One thing I still find annoying is how "enterprise-ey" it is. There's no "put all your unit files here" easy to look at folder, you need to first use some systemd specific command to find out exactly which of the many many sub folders the unit file lives in. There's also a tendency to split configuration across many different files, which I guess is how we always did it but somehow seems more annoying when coupled with the whole "you don't get to know where the unit file is" system. Like one service could have 3 or 4 different unit files if it's complicated, if it relies on socket activation or mount points or times or anything like that. One of my biggest (practical) complaints these days is simply that everything is spread out all over the filesystem.

thu2111 7y ago
Yeah that's true. I don't really understand yet why timers and sockets are in separate files to services.

HugoDaniel 7y ago

You can read up on https://suckless.org/sucks/systemd/ https://suckless.org/sucks/systemd/ It is a good primer into why systemd provoke(d|s) so much hate and controversy.

qqssccfftt 7y ago
> What PID 1 Should Do > When your system boots up the kernel is executing a given binary in its known namespace. To see what are the only tasks the application running as pid 1 has to do, see sinit. Just wait for child process to reap and run some other init scripts. Very objective and balanced article!
- stonewareslord 7y ago
  Did you read the source of sinit? It's an example of what init can look like. Check out the <90 source code here: https://git.suckless.org/sinit/file/sinit.c.html https://git.suckless.org/sinit/file/sinit.c.html I don’t think they’re trying to push sinit as a replacement, they’re showing just how bloated their init system has gotten.
Koshkin 7y ago
sinit looks like another extreme: systemd does (almost) everything, sinit does (almost) nothing. I think a good design is somewhere in between.
- rleigh 7y ago
  I strongly disagree. PID1 is a single point of failure for the entire system. If it crashes, the kernel will immediately panic. Try it out yourself and see. A good design would move every last bit of complexity out of PID1, leaving PID1 doing the absolute bare minimum required. There is no need for the vast majority of systemd's functionality and complexity to be physically present in the PID1 image. They could fork off another process to do that. I've always found that aspect of its design to be utterly bizarre. Jamming additional complexity into PID1 is fundamentally wrong, it's obviously a poor engineering choice, and there are plenty of better ways of architecting the system.

guenthert 7y ago

You didn't have to debug a system which failed to boot.

benchaney 7y ago
This. While systemd has a lot of issues that are obvious from a distance, everyone who hates it has had it break something because of a really stupid design decision it made.

castillar76 7y ago

Purely my perspective here, as a 25-year user of Linux and BSD (for context). On the one hand, I very much agree with you that Systemd brings a lot to the table. The files are much easier to work with, the service ordering and integration is logical and works well (to the extent I've beaten on it), and I can't deny that a faster boot sequence is helpful for things that boot often like container images. It's been a lot easier writing systemd config files for my new services than it was to write init.d boot scripts, for sure, and the integration of systemctl is really nice: one command does all the service things from info to disabling. The flip-side for me, the one that continues to get under my skin, is the approach of the systemd project. It's the habit systemd has of simply subsuming all other system functions into itself (DHCP client? Sure! DNS client? Mine now! Logging? We handle that now. Firewall control? ALL SHALL BE ASSIMILATED.). If the systemd versions of those functions were both obvious in presence and easy to replace with more fully functional replacements when I wanted, I'd feel better about it, but I keep running across cases where system functions that have worked that way since Linus was in knee-pants have suddenly been replaced behind the scenes with a systemd module whose configuration files and knobs aren't obvious or well-documented, it's difficult-to-impossible to uninstall, and trying to disable and replace it leads to cascading failures. Worse, I keep seeing security issues brought up to the systemd devs and then tossed aside with "well, just don't do that" or "how is that even a problem". It's not pervasive or constant, but it's steady enough to be worrying. Obviously not every security issue raised will be top priority, but it concerns me how much of my systems are being subsumed by a project that seems to prioritize "do all the things now" over "do things securely". Compare that to the approach taken by, say, OpenBSD, which has also been steadily replacing long-standing system bits with their own custom-developed pieces. Their approach has been "we will provide basic functionality that is iron-clad secure", while leaving you the ability to swap in something else for stuff like OpenSMTPd without breaking your system. And yes, Theo can be just as much an <unprintable> as Poettering, but I'm a lot less worried about the outputs of his work for the above reasons. Ultimately I think systemd is a good way forward, but it needs someone else to take over the project, rein it in, and keep it focused on being good at what it does rather than trying to be all things everywhere. Or, alternately, it needs to just implement its own kernel and go off to be SystemdOS v1, which seems to be the trajectory it's on right now.

7y ago

hiram112 7y ago

I don't really mind Systemd as a replacement for init, it's just that other unrelated systems are now requiring it explicitly that probably shouldn't (e.g. Gnome) and also Systemd is creating more and more sub projects that replace even more standard Unix functionality. Let's see: 1. Systemd-network is a whole replacement for Network Manager, which itself was bloated compared to old ifcfg files and other simple tools that manage just single aspects of the network (dhcp, wifi, etc.) 2. Systemd-resolved - replaces everything that deals with DNS. This really bothered me when it was discovered that it was ignoring certain standard configurations such that users using VPNs / encrypted DNS were leaking DNS lookups. That could get someone tossed in prison or worse in countries like Iran or China. * Systemd-logind - replaces various tools used for logging in to both X and the console. Seems like it's a mixed bag, though I know there was a lot of complaints because it broke standard behavior with tools like nohup. * Systemd-boot - replaces Grub and other similar tools. I hate Grub, so this doesn't really bother me. * Systemd-locale, hostname, timedate - these replace traditional tools dealing with the obvious features their names describe. This isn't a big deal to me as it's just replacing one simple tool with another, though I'm sure the dependencies will end up requiring a lot more unrelated systemd libs, which the original tools were completely stand -alone. Seems like more and more are coming out every year - encrypting and exporting home directories, partition managers, Cron, etc. Even if the replacements libs are better than the originals, it seems the developers purposefully make sure that the more of these projects your distro depends on, the more you're locked into all the other Systemd projects. This will be the end of BSDs and any other Linux distros that don't want to use any Systemd, or even a few of the smaller tools, because everything will eventually require the DBus and Systemd / Journald main libs. I'm not a Linux expert at this level, but it certainly reminds me of a few notorious Java libraries - you import a single library to use just a few methods, and all of the sudden your app has grown by 100MB of other dependencies that have no relation to your requirements, and it breaks everything because it adds all sorts of Servlet libraries that override and break things everywhere else. Usually the only way to keep things clean is to NOT use these libs or pull out just the source for the things you want. Interestingly, the libraries that have caused me the most trouble over the years were created by Redhat - you end up with all sorts of JBoss specific modules that, for no apparent good reason, override your logging, validation, web, etc. libs with their own versions.

na85 7y ago

In the early days of systemd it broke systems on the regular, and instead of humility, Lennart Poettering and his homies tended to react with ego and arrogance.

jcranmer 7y ago

> I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world A few major reasons: * It's originally written by the person who also wrote Pulseaudio, so any vitriol people have left over from Pulseaudio's configuration issues gets poured into systemd as well. * The project takes a monolithic approach to the problem of configuring services, and many people think that's wrong. [1] * It's change, and change means work for people who have their old setups. [1] This criticism is usually described as "it breaks the Unix model," a formulation I don't like because it's meaningless and an appeal to authority instead of articulating the issues they have with it. Watch how people try to explain how the similarly monolithic Linux kernel doesn't break the Unix model, it can be funny sometimes.

kyuudou 7y ago
> explain how the similarly monolithic Linux kernel doesn't break the Unix model It does one thing and one thing well: talk to hardware.
- tptacek 7y ago
  Then what, all the other things it does it does poorly?
thu2111 7y ago
Right, what does monolithic approach to configuring services even mean? I seem to have hundreds of systemd services on my box, all of which appear to do a tiny part of system startup. That doesn't come across as very monolithic, if anything service overload is one of the things I dislike about systemd (but it wasn't better previously).