I hate to be a downer, but this article is crap. It's crap in the same way every article gushing over systemd is crap. It acts like the only alternative to sysv init is systemd and it completely...
I hate to be a downer, but this article is crap. It's crap in the same way every article gushing over systemd is crap. It acts like the only alternative to sysv init is systemd and it completely overlooks systemd's completely obvious flaws (it's absolutely riddled with insane inconsistencies because it's an ill-defined transactional job scheduler masquerading as a process supervision suite) while fawning over things that absolutely do not matter.
I use and advocate openrc. It's reliable and stable. It's easy to write init scripts for - in the simplest case they can be written declaratively, but they can be arbitrarily complex. This means...
I use and advocate openrc. It's reliable and stable. It's easy to write init scripts for - in the simplest case they can be written declaratively, but they can be arbitrarily complex. This means e.g. you can handle complex cleanup requirments. You can write you're own functions (beyond start, stop, restart, which is super handy - consider functions like monitor, logs, cleanup, or other runtime abilities). It's very nicely documented too.
s6 I think is the most interesting of the daemontools line. It has trivial semantics: if you can write a foreground process, you can supervise it. The default is to keep the process up at all...
s6 I think is the most interesting of the daemontools line.
It has trivial semantics: if you can write a foreground process, you can supervise it. The default is to keep the process up at all times. No need to keep tripping up over the 10 different tunables for restart semantics.
Sophisticated behaviour without invasive linking. You want sd_notify like behaviour without needing to link? Just write a newline to a file descriptor of your choice. You want parallel startup? Just use the fd-holding binary. No one needs to know or care about S6's libraries specifically.
Fully async behaviour that relies only on pipes existing. No complex crash-prone dbus required. Equally suited for the server as embedded.
Zero allocations post startup, will function even will a full process table. When shit hits the fan it will keep responding.
Those are my main points, but I could go on and on. Obviously there are things that ootb systemd does better but it's sucked all the air out of the room and positioned itself to block new innovation in the space (i.e. non systems cgroup managers).
This was an entertaining read, thank you! Despite running lots of Linux systems over the years I've never really been a "Linux guy" in the sense that I have philosophies about the different ways...
This was an entertaining read, thank you!
Despite running lots of Linux systems over the years I've never really been a "Linux guy" in the sense that I have philosophies about the different ways things should be done. Sure, I have opinions. When I tactically or operationally go to do something, sometimes that thing seems sane and well structured, and sometimes I feel like the distro was designed by a sociopath. But on the whole my interactions are transactional. I need cheap system to do function A, I quickly review current best practices, do the thing, and get out (sometimes with a new horror story).
I'm not sure what that says about me as a recovering technologist, but I definitely appreciate the people who do have these philosophies and duke it out to help the best practices come to light or go through refinement.
(And for what it's worth, as the author of hundreds of nightmare cron scripts who resisted systemd, it's a good thing.)
I started using Linux after the systemd debate was more or less settled, 2013, and I've grown to like systemd, especially as it's become more stable over time. I do know it's not as easy to...
I started using Linux after the systemd debate was more or less settled, 2013, and I've grown to like systemd, especially as it's become more stable over time. I do know it's not as easy to understand as sysv init which is literally just shell scripts, but on the other hand it's much easier to do things like restart daemons and stuff.
nix-daemon leverages this to great effect by "lazily" running only when you need it: the daemon will stop when you aren't building anything, but as soon as you ask for it, nix-daemon.socket will start nix-daemon.service. That's a great feature!
NIX MENTIONED!!! 🗣️🔥🔥🔥
On the other hand, really, this is part of the ugly side of systemd for me. A lot of software now assumes you're using systemd, which is far too heavy for things like containers. Getting Nix to work outside of systemd is sort of a nightmare (not impossible, mind you…)
I liked SysV init because I already knew shell scripts. I usually don't mess with my init system, but I could understand most of what an rc script did without learning a whole new ecosystem and...
I liked SysV init because I already knew shell scripts. I usually don't mess with my init system, but I could understand most of what an rc script did without learning a whole new ecosystem and its language and paradigms.
This is very different with systemd. The man pages could probably fill a book. Every time I look something up, I find at least three different configuration options that sound identical to me, just worded differently, and I have to carefully read each description (and multiple references mentioned in it) to understand the differences.
I'm not saying this is a bad thing. Init systems are complex and you need a complex language to configure them. I can totally understand why admins like systemd. But I, a mere desktop user, mostly gave up and just hope my distro does what I want. It mostly does, and if it makes the lives of package maintainers easier, I'm all for it.
Systemd supports SysV style rc scripts. You can put them into /etc/rc.d/init.d/ and Systemd will automatically generate services to run them when your system boots up.
Systemd supports SysV style rc scripts. You can put them into /etc/rc.d/init.d/ and Systemd will automatically generate services to run them when your system boots up.
It doesn't "need" to do that. It's pretty modular and you can easily only use the parts of it you want. Even most "pre-made" distros only use specific parts of systemd, and I'm not even talking...
why it need to take over my booting, my ntp, my networking, my resolver
It doesn't "need" to do that. It's pretty modular and you can easily only use the parts of it you want. Even most "pre-made" distros only use specific parts of systemd, and I'm not even talking about things like Arch or Gentoo where you can just pick your own stuff
There's no need of any of that rubbish in an init system replacement
Yeah, it's not an "init system replacement", it's a replacement for a bunch of unrelated components you have to hack together to get a working system
Interesting. But this doesn't really help me if I want to understand and tweak how my computer boots. There might be a Frankendistro that uses systemd with SysV scripts, but before I'd touch that...
Interesting. But this doesn't really help me if I want to understand and tweak how my computer boots. There might be a Frankendistro that uses systemd with SysV scripts, but before I'd touch that with a stick, I'd use something like Void or Devuan.
Sure, in 2022… this feels like a bizarre reason to attack Poerttering. Is the implication that he’s like a sleeper agent Microsoft planted from 2002 or something? Or that all engineers Microsoft...
Sure, in 2022… this feels like a bizarre reason to attack Poerttering.
Is the implication that he’s like a sleeper agent Microsoft planted from 2002 or something? Or that all engineers Microsoft hires are bad?
So do many other people who contribute to the Linux kernel or ecosystem. Working for Microsoft doesn't automatically make you an evil developer trying to destroy open source, especially if you've...
So do many other people who contribute to the Linux kernel or ecosystem. Working for Microsoft doesn't automatically make you an evil developer trying to destroy open source, especially if you've developed said open source projects for many years prior to that. Besides, if systemd's secret goal is to "destroy Linux" or whatever, it's not doing that well, as it seems to have only eased the development and maintainance of Linux distros and systems.
As much as I like to poke fun at systemd for being "Microsoft Linux", this isn't really substantiative, since a lot of people on Microsoft work on Linux, directly or indirectly. For instance, the...
As much as I like to poke fun at systemd for being "Microsoft Linux", this isn't really substantiative, since a lot of people on Microsoft work on Linux, directly or indirectly. For instance, the guy that found the xz backdoor attempt also works for Microsoft.
I hate to be a downer, but this article is crap. It's crap in the same way every article gushing over systemd is crap. It acts like the only alternative to sysv init is systemd and it completely overlooks systemd's completely obvious flaws (it's absolutely riddled with insane inconsistencies because it's an ill-defined transactional job scheduler masquerading as a process supervision suite) while fawning over things that absolutely do not matter.
What other init system would you present as better, and why?
I use and advocate openrc. It's reliable and stable. It's easy to write init scripts for - in the simplest case they can be written declaratively, but they can be arbitrarily complex. This means e.g. you can handle complex cleanup requirments. You can write you're own functions (beyond start, stop, restart, which is super handy - consider functions like monitor, logs, cleanup, or other runtime abilities). It's very nicely documented too.
s6 I think is the most interesting of the daemontools line.
Those are my main points, but I could go on and on. Obviously there are things that ootb systemd does better but it's sucked all the air out of the room and positioned itself to block new innovation in the space (i.e. non systems cgroup managers).
This was an entertaining read, thank you!
Despite running lots of Linux systems over the years I've never really been a "Linux guy" in the sense that I have philosophies about the different ways things should be done. Sure, I have opinions. When I tactically or operationally go to do something, sometimes that thing seems sane and well structured, and sometimes I feel like the distro was designed by a sociopath. But on the whole my interactions are transactional. I need cheap system to do function A, I quickly review current best practices, do the thing, and get out (sometimes with a new horror story).
I'm not sure what that says about me as a recovering technologist, but I definitely appreciate the people who do have these philosophies and duke it out to help the best practices come to light or go through refinement.
(And for what it's worth, as the author of hundreds of nightmare cron scripts who resisted systemd, it's a good thing.)
I started using Linux after the systemd debate was more or less settled, 2013, and I've grown to like systemd, especially as it's become more stable over time. I do know it's not as easy to understand as sysv init which is literally just shell scripts, but on the other hand it's much easier to do things like restart daemons and stuff.
NIX MENTIONED!!! 🗣️🔥🔥🔥On the other hand, really, this is part of the ugly side of systemd for me. A lot of software now assumes you're using systemd, which is far too heavy for things like containers. Getting Nix to work outside of systemd is sort of a nightmare (not impossible, mind you…)
Have you seen this? https://events.ccc.de/congress/2024/hub/en/event/sixos-a-nix-os-without-systemd/
You could not have shared this at a better time. Thank you!
I liked SysV init because I already knew shell scripts. I usually don't mess with my init system, but I could understand most of what an rc script did without learning a whole new ecosystem and its language and paradigms.
This is very different with systemd. The man pages could probably fill a book. Every time I look something up, I find at least three different configuration options that sound identical to me, just worded differently, and I have to carefully read each description (and multiple references mentioned in it) to understand the differences.
I'm not saying this is a bad thing. Init systems are complex and you need a complex language to configure them. I can totally understand why admins like systemd. But I, a mere desktop user, mostly gave up and just hope my distro does what I want. It mostly does, and if it makes the lives of package maintainers easier, I'm all for it.
Systemd supports SysV style rc scripts. You can put them into
/etc/rc.d/init.d/and Systemd will automatically generate services to run them when your system boots up.It doesn't "need" to do that. It's pretty modular and you can easily only use the parts of it you want. Even most "pre-made" distros only use specific parts of systemd, and I'm not even talking about things like Arch or Gentoo where you can just pick your own stuff
Yeah, it's not an "init system replacement", it's a replacement for a bunch of unrelated components you have to hack together to get a working system
Interesting. But this doesn't really help me if I want to understand and tweak how my computer boots. There might be a Frankendistro that uses systemd with SysV scripts, but before I'd touch that with a stick, I'd use something like Void or Devuan.
I must be missing something here; what does Windows have to do with systemd?
systemd is about 15 years old and has not substantially changed in the last three years... if anything it is Red Hat influence rather than Microsoft
Sure, in 2022… this feels like a bizarre reason to attack Poerttering.
Is the implication that he’s like a sleeper agent Microsoft planted from 2002 or something? Or that all engineers Microsoft hires are bad?
So do many other people who contribute to the Linux kernel or ecosystem. Working for Microsoft doesn't automatically make you an evil developer trying to destroy open source, especially if you've developed said open source projects for many years prior to that. Besides, if systemd's secret goal is to "destroy Linux" or whatever, it's not doing that well, as it seems to have only eased the development and maintainance of Linux distros and systems.
As much as I like to poke fun at systemd for being "Microsoft Linux", this isn't really substantiative, since a lot of people on Microsoft work on Linux, directly or indirectly. For instance, the guy that found the xz backdoor attempt also works for Microsoft.