This post accentuates how one of the problems of systemd is actually environmental one. Yes, systemd does need to handle a complex chain of daemons dependancies and deal with very frustrating race conditions. But this stems more from the segmented design philosophy found in Linux-based systems like Arch. This is systems like FreeBSD have been able to stick with their init scripts, since the userland startup has been designed to work together.
I don’t think it’s that. Gentoo has done fine with OpenRC, which is heavily inspired by FreeBSD rc.d, and Debian’s SysV init scripts, while unpolished and in serious need of documentation, were totally serviceable.
SystemD is the way it is because FreeDesktop has always been full of people with insane, wrong ideas about software (they just never wrote system software before, so nobody really cared). Fedora got it because of Red Hat. Arch got it because they have a mortal fetish for novelty. Everyone else got it because network effects and desktop environments created overwhelming political pressure.
Yes, systemd does need to handle a complex chain of daemons dependancies and deal with very frustrating race conditions.
Could you elaborate a bit more what you mean here? Does FreeBSD use fewer daemons in general? Are there fewer inter-daemon dependencies? How does this look for FreeBSD + ports? If you set up a server or desktop, aren’t you largely using the same daemons as on an equivalent Linux system?
But how would upstream software ship init scripts for BSD? This would lead to something that’s not designed as you just said. Let’s say I develop some kind of software (maybe a commercial game server to provide you with a nasty example) and I wanted to ship this for BSD, how would I do that so it integrated in the way it was originally designed? Would BSD write and provide initscripts for my commercial software and ship that as part of their distribution?
There's always something.
Last week it was package managers
Yesterday it was sound servers
Today it's init systems
Tomorrow it'll be display servers
It's a symptom of free and open-source software
It's a symptom of choice
The freedom to have multiple components that fulfil the same task
- Mine's better
- No mine is
May the best man win
(or, more accurately, may the various contenders find their own specific niche)
Don't worry about it
It's progress
Sweet, sweet bloody, bare-knuckle progress
The devs of various projects are currently knocking seven-bells of verbal excrement out of each other
All so that you, the user, gets the best possible software on your machines.
This is a…rather generous take on CADT-driven development.
It’s easy to mistake churn for progress when you have no other perspective to judge it by, but comparing, say, OSSv4 to PulseAudio doesn’t have me convinced that the Forever Rewrite brigade is really accomplishing anything useful in the long run.
The drama around systemd is getting pretty pathetic at this point, IMO. People who don’t like it should switch to a distro that doesn’t use it and get over it.
If even Debian and Arch have adopted it, how long will it be before switching is not an option? Even for those who aren’t necessarily tied in by corporate policies (etc) but who just don’t have the time to spend on the relentless ops work that (e.g.) Debian’s packaging system manages for them? And in the face of such aggressive expansionism, how else can those who don’t consider systemd a good route try to ensure that some distros continue not to use it, if not by speaking loudly and frequently about it in places where their opinions will be understood and perhaps even absorbed?
I think people are concerned that gnome is now incapable of functioning unless systemd is there to kill its runaway processes. So it may not be quite so simple as switching distros.
This “just switch if you don’t like it” response seems to be contradicted by “other programs, please add explicit systemd support to yourself” request.
Many programs have optional PAM support, optional NSS support, and in the future optional pledge() support. What is the difference between somebody asking to add pledge() calls for OpenBSD or someone asking to add some systemd support as a compile time option?
It seems that a lot of people have double standards here. When it’s about adding pledge() to some third-party software, the reaction is ‘all hail pledge’, when it’s about adding systemd support to third-party software, the sky is falling.
You say that like it’s a good thing. The situation is a dumpster fire – Every feature is painful. A tangled web of special cases, ifdefs, and platform specific code paths that interact with each other. It’s common for one of the various sets of options to be broken with nobody noticing. Maintaining the optional features is incredibly painful, but can be tolerated if the features bring enough benefits.
However making this change for systemd support would not be motivated by any upsides and new functionality that systemd enables. The change would be because systemd broke my program, and I now need to work around it. Every other thing you listed there was backwards compatible, but the benefits incentivized the work.
Forcing programmers to tread water to keep code working will lead to a less than warm reception.
Many people also won’t “just switch” because they’re either locked in by restrictions of their company, or they don’t have the time or interest in learning how to use an alternative.
That’s a bit of silly argument to make. I use lots of programs that support Pulse Audio explicitly, but I don’t have Pulse Audio installed, and yet, they still make sound. :-)
Fragmentation is a pretty big issue in the free software world and developers' time is better used when we agree on things. It would be better to stick with one init system that people can agree on. I’m not saying the drama helps, but still.
Even though everything’s already fragmented, you still have to weigh the cost/benefits of further fragmentation. I don’t think it’s worth the costs in this case.
Did they? I don’t remember hot-swapping being a significant issue 20 years ago, before USB and Bluetooth. Outputs like monitors used to be unidirectional dependencies, now they’re a complex bidirectional negotiation. Systems are bigger, with many more services - keeping your tweaks to a dozen init scripts on a few servers updated with the new OS every 18 months or so was tractable; now there’s a few hundred and Arch pushes a few updates per week. These three concerns feed positively into one another. It wasn’t too bad to add a sleep 2 for that one slow hard drive to come up before mounting /usr, but getting drivers loaded in the right order while the user adds and removes bargain-basement peripherals that require or notify daemons interfacing with this week’s self-updated browser or Steam client is really hard to make Just Work, to say nothing of the problems that appear when the server room you used to rack boxen in is now a set of virtual machines that are live and die by the auto-scaler.
Slow hard drives are a problem other operating systems deal with too. The usual solution is for the kernel not to announce the presence of the device until the platters are spinning and the data is readable. It doesn’t require a multi daemon message bus in user land to determine when mount can run.
I know that’s just a made up example, but it’s a fine exemplar of the big picture. Solving a problem at the wrong layer means you have another problem which needs a solution at a different wrong layer and now you need another layer to fix that.
In what sense do you mean this? The “Cloud Revolution” has made systems (that most consumers interact with) smaller. Many companies run 1 thing per “server”. Compare this to the era that SMF was created in, where there was one big-honkin machine that had to do everything. And even in the SMF world, SMF wasn’t an amorphis blob that consumed everything in its way, it had clear boundaries and a clear definition of done. I’m not saying SMF is the solution we should have or that it was designed for desktops (it wasn’t) but rather questioning your claim of servers becoming bigger.
Tandems, high-end Suns, Motorola Unix, Apollo, and anything with EIDE or SCSI involved hot swap more than a decade before Bluetooth.
I will grant that the average linux contributor is more likely to paste ‘sleep 2’ in an init shell script than to try to understand shell, or init, but that’s a problem of the linux contributors, not of technology, or shell, or init, in my opinion.
They worked, albeit not well. It’s not like systemd was the first sysvinit replacement, nor was Linux even the first UNIX-like to replace initscripts. I think that honor actually goes to Solaris 10, which introduced SMF 10 years ago (not the case, see ChadSki’s post below mine). SMF solves most of the same problems listed in this reddit post, and predates systemd by quite some time.
init/rc scripts don’t handle depedencies well. Debian had some hacks that do that, which relied on special comments in initscripts. OpenBSD and FreeBSD order the base system’s startup for you, and rely on you to deal with ordering anything from packages or ports. SMF (and later, systemd) keep track of service dependencies, and ensure that those are satisfied before starting services.
init/rc scripts are fairly slow, and that can’t be avoided. Honestly, for traditional uses of UNIXes on traditional servers, this doesn’t matter. For desktops, laptops, and servers that expect frequent reboots for updates (CoreOS’s update strategy comes to mind), this does and that’s one of the places systemd inarguably shines. IME I haven’t seen similar speed from SMF, but it’s honestly so rare that I reboot a solaris box anyway.
init/rc scripts don’t have any mechanism for determining whether or not a service is running. pid files are very racey and unreliable. pgrep can also be suspect, depending on what else happens to be running on the system at the time. SMF and systemd reliably keep track of running processes, rather than leaving it up to chance.
Another point not well made in this article is that writing init scripts can be awful. Package maintainers save you from this pain 99% of the time, but if you ever have to write your own on Debian or Red-Hat, there’s a lot of boilerplate you need to begin with. To be fair, OpenBSD proves that this doesn’t have to be as painful as Linux distros made it.
Saying that it’s not a difficult problem or that it’s all already solved by sysvinit/openrc/rc doesn’t really cut it, because it’s straight up not honest. SMF does solve these problems, and it solves them well and reliably. I used to be a systemd fan, but over time I’ve grown much more skeptical given some of the defaults and the attitude the systemd maintainers have towards the rest of the community at large.
I’d love a tool like SMF for Linux and the BSDs. I’ve used runit before, but man is it awful.
I was very happy with runit when I was using void (but this was only for a laptop and personal server). Can you elaborate at all on what you don’t like about it?
Porting some nontrivial initscripts from Fedora to Debian (or was it other way around, can’t remember) has been the most painful operation I have done in my career so far. Several hundred lines of shell script is never fun, even more so when the script uses crude distro dependent hacks to get everything bootstrapped in right order.
If systemd can lift that maintenance horror/pain from someones shoulders I am happy for it, even if I don’t personally like some decisions that systemd has done.
Just because they work doesn’t mean they are good. Windows always boots just fine for me when I want to play games, does that mean I would want to ever, ever, ever, ever touch anything system level in Windows? Certainly not.
Maybe you have a better idea of the issues here than you’re presenting, but I’m reading your comment as an “I hate systemd and I always will” knee-jerk response. The original post clearly articulates new issues that have cropped up in modern Linux systems, that systemd resolves. Instead you choose to blatantly ignore those issues. Have you actually dealt with lazy-loading hardware issues? Reproducible boots across 10k+ machines in a cluster? Have you actually worked with an init system in a meaningful capacity? Because it’s complete bullshit.
I acknowledge this comment is aggressive, but I’m sick and tired of systemd whining from people who don’t understand how much pain systemd resolves.
In my biased opinion, your post doesn’t actually articulate the problem many people have with systemd. It’s not that making a better init system may not be desirable but it’s that they don’t feel systemd actually does this well.
FreeBSD is not perfect, but for all packages I’ve used that run as a service, all I’ve had to do is pkg install it and add <service>_enable="YES" to /etc/rc.conf. Done. It works. Now, some part of the FreeBSD community are talking about moving to something like launchd but…
systemd has unclear boundaries. This is a point that @bcantrill has made on multiple occasions. Why did logs have to go binary format? What’s that have to do with the init system? Why is cron in there? logind? ntp? What are the boundaries of systemd? How do you know when it is done or even what direction it’s supposed to go in? It’s consuming everything and it’s unclear why or when it will be done. Compare this to something of similar magnitude from the early 2000’s: SMF. I think SMF would put a bad taste in many people’s mouths here, but to its credit, SMF has clear boundaries. It has a clear problem statement and you can ask the question “should this thing I want be part of SMF or not?” That question is very hard to answer with systemd.
I don’t know what your experience is, but your post in no way makes me think “hrm, maybe systemd is a good idea”. Instead it makes me think “what kind of a chop-shop is Linux if you have the problems you listed and systemd is the answer?” It reminds me of the 7-Up commercials[0] where they have a blind taste test, and 7-Up wins, hands down, next to detergent and bile.
Well, you asked, so by way of context, I was a Unix sysadmin dealing with hot-plugged hardware (ranging from SCSI-1 up to entire CPUs and bus subsystems), appearing/disappearing dev entries, “socket activation”, and dependency management in 1988.
The original post is actually a pack of hilarious cockamamie buzzword malarkey, as is “reproducible boots across 10k+ machines in a cluster”. But then, bluster and bravado are the fundamental atom of the red hat/freedesktop playbook, apparently.
I see. The Arch init scripts were particularly useless, so the switch definitely made sense for them. Given your expertise, I’d like to shift my stance and instead ask how you dealt with all these issues? Systemd is a glorified event loop, which deals with the problem nicely, but I don’t see how classic init-script based systems handle this at all. And I didn’t see them handling these issues when I was working on cluster management.
1) the init scripts were written correctly. I will 100% grant you that the Linux sysv init scripts were increasingly written without regard for quality or maintainability. Nevertheless, that is the fault of the maintainers rather than of the init system. If you’d like more of an education in this regard, download OpenBSD or FreeBSD and check out their rc scripts, which are quite clean, fast, effective, extensible, and comprehensible, and even less featureful than sysvinit.
2) hot plug was handled differently by different vendors, but generally the device would appear or disappear in /dev (kernel drivers discovered the device arriving or departing from the (hardware) bus) and a device- or subsystem-specific userland program would get notified by the change, and, e.g., mount/unmount file systems, etc. Also not rocket surgery.
3) we referred to “socket activation” by its original name, “inetd”, and we got rid of it as soon as we could.
4) dependency management was generally resolved with runlevels and sequential scripts. Even loaded down with crap, modern Unix machines boot in a matter of seconds with any init system. Unix machines generally stay up for years, so ‘super fast boot’ and parallel boot were things nobody cared about until the Desktop Linux crowd, who were so incompetent at getting CPU P-states to work properly that they actually rebooted their systems every time they opened their laptop lids. For years.
5) I do “reproducible boots across 10k+ machines in a cluster” with, like, whatever came after BOOTP. Maybe DHCP? In any case, that has nothing at all to do with any init system anywhere.
In the grander scheme of things, this is something that I believe is unfortunately common. My prime example of this is the Hadoop ecosystem. Hadoop is junk. Absolute junk. And every solution to Hadoop is…to add more code to, and around, Hadoop in hopes that somehow adding more will make a piece of junk less junk. In the end you get something that looks like a caricature of the Beverly Hillbillies truck and works twice as bad.
This post accentuates how one of the problems of systemd is actually environmental one. Yes, systemd does need to handle a complex chain of daemons dependancies and deal with very frustrating race conditions. But this stems more from the segmented design philosophy found in Linux-based systems like Arch. This is systems like FreeBSD have been able to stick with their init scripts, since the userland startup has been designed to work together.
I don’t think it’s that. Gentoo has done fine with OpenRC, which is heavily inspired by FreeBSD rc.d, and Debian’s SysV init scripts, while unpolished and in serious need of documentation, were totally serviceable.
SystemD is the way it is because FreeDesktop has always been full of people with insane, wrong ideas about software (they just never wrote system software before, so nobody really cared). Fedora got it because of Red Hat. Arch got it because they have a mortal fetish for novelty. Everyone else got it because network effects and desktop environments created overwhelming political pressure.
Yes, systemd does need to handle a complex chain of daemons dependancies and deal with very frustrating race conditions.
Could you elaborate a bit more what you mean here? Does FreeBSD use fewer daemons in general? Are there fewer inter-daemon dependencies? How does this look for FreeBSD + ports? If you set up a server or desktop, aren’t you largely using the same daemons as on an equivalent Linux system?
But how would upstream software ship init scripts for BSD? This would lead to something that’s not designed as you just said. Let’s say I develop some kind of software (maybe a commercial game server to provide you with a nasty example) and I wanted to ship this for BSD, how would I do that so it integrated in the way it was originally designed? Would BSD write and provide initscripts for my commercial software and ship that as part of their distribution?
– amauk on Reddit
This is a…rather generous take on CADT-driven development.
It’s easy to mistake churn for progress when you have no other perspective to judge it by, but comparing, say, OSSv4 to PulseAudio doesn’t have me convinced that the Forever Rewrite brigade is really accomplishing anything useful in the long run.
So the best bare-knuckle fighter is always right, by definition?
Maybe it’s more like UFC and sometimes an awesome feature-kick in the face will win, and sometimes just choking-the-life-out-of-a-project does?
Upvoted for sheer excellence.
The drama around systemd is getting pretty pathetic at this point, IMO. People who don’t like it should switch to a distro that doesn’t use it and get over it.
If even Debian and Arch have adopted it, how long will it be before switching is not an option? Even for those who aren’t necessarily tied in by corporate policies (etc) but who just don’t have the time to spend on the relentless ops work that (e.g.) Debian’s packaging system manages for them? And in the face of such aggressive expansionism, how else can those who don’t consider systemd a good route try to ensure that some distros continue not to use it, if not by speaking loudly and frequently about it in places where their opinions will be understood and perhaps even absorbed?
I think people are concerned that gnome is now incapable of functioning unless systemd is there to kill its runaway processes. So it may not be quite so simple as switching distros.
This “just switch if you don’t like it” response seems to be contradicted by “other programs, please add explicit systemd support to yourself” request.
Many programs have optional PAM support, optional NSS support, and in the future optional
pledge()support. What is the difference between somebody asking to addpledge()calls for OpenBSD or someone asking to add some systemd support as a compile time option?It seems that a lot of people have double standards here. When it’s about adding
pledge()to some third-party software, the reaction is ‘all hail pledge’, when it’s about adding systemd support to third-party software, the sky is falling.(BTW, I like
pledge().)Rather significant difference: Programs that choose not to incorporate pledge patches don’t stop working.
You say that like it’s a good thing. The situation is a dumpster fire – Every feature is painful. A tangled web of special cases, ifdefs, and platform specific code paths that interact with each other. It’s common for one of the various sets of options to be broken with nobody noticing. Maintaining the optional features is incredibly painful, but can be tolerated if the features bring enough benefits.
However making this change for systemd support would not be motivated by any upsides and new functionality that systemd enables. The change would be because systemd broke my program, and I now need to work around it. Every other thing you listed there was backwards compatible, but the benefits incentivized the work.
Forcing programmers to tread water to keep code working will lead to a less than warm reception.
Many people also won’t “just switch” because they’re either locked in by restrictions of their company, or they don’t have the time or interest in learning how to use an alternative.
That’s a bit of silly argument to make. I use lots of programs that support Pulse Audio explicitly, but I don’t have Pulse Audio installed, and yet, they still make sound. :-)
And? Don’t use Gnome. It’s crap anyway.
Fragmentation is a pretty big issue in the free software world and developers' time is better used when we agree on things. It would be better to stick with one init system that people can agree on. I’m not saying the drama helps, but still.
That’s not convincing because everything else in the free software world is already massively fragmented.
Free software is about user choice, and choice implies alternatives and some level of fragmentation.
Even though everything’s already fragmented, you still have to weigh the cost/benefits of further fragmentation. I don’t think it’s worth the costs in this case.
It’s kind of amazing how many ‘impossible’ things miraculously nevertheless worked for 40 years.
Did they? I don’t remember hot-swapping being a significant issue 20 years ago, before USB and Bluetooth. Outputs like monitors used to be unidirectional dependencies, now they’re a complex bidirectional negotiation. Systems are bigger, with many more services - keeping your tweaks to a dozen init scripts on a few servers updated with the new OS every 18 months or so was tractable; now there’s a few hundred and Arch pushes a few updates per week. These three concerns feed positively into one another. It wasn’t too bad to add a
sleep 2for that one slow hard drive to come up before mounting/usr, but getting drivers loaded in the right order while the user adds and removes bargain-basement peripherals that require or notify daemons interfacing with this week’s self-updated browser or Steam client is really hard to make Just Work, to say nothing of the problems that appear when the server room you used to rack boxen in is now a set of virtual machines that are live and die by the auto-scaler.Slow hard drives are a problem other operating systems deal with too. The usual solution is for the kernel not to announce the presence of the device until the platters are spinning and the data is readable. It doesn’t require a multi daemon message bus in user land to determine when mount can run.
I know that’s just a made up example, but it’s a fine exemplar of the big picture. Solving a problem at the wrong layer means you have another problem which needs a solution at a different wrong layer and now you need another layer to fix that.
In what sense do you mean this? The “Cloud Revolution” has made systems (that most consumers interact with) smaller. Many companies run 1 thing per “server”. Compare this to the era that SMF was created in, where there was one big-honkin machine that had to do everything. And even in the SMF world, SMF wasn’t an amorphis blob that consumed everything in its way, it had clear boundaries and a clear definition of done. I’m not saying SMF is the solution we should have or that it was designed for desktops (it wasn’t) but rather questioning your claim of servers becoming bigger.
Tandems, high-end Suns, Motorola Unix, Apollo, and anything with EIDE or SCSI involved hot swap more than a decade before Bluetooth.
I will grant that the average linux contributor is more likely to paste ‘sleep 2’ in an init shell script than to try to understand shell, or init, but that’s a problem of the linux contributors, not of technology, or shell, or init, in my opinion.
They worked, albeit not well. It’s not like systemd was the first sysvinit replacement, nor was Linux even the first UNIX-like to replace initscripts. I think that honor actually goes to Solaris 10, which introduced SMF 10 years ago (not the case, see ChadSki’s post below mine). SMF solves most of the same problems listed in this reddit post, and predates systemd by quite some time.
init/rc scripts don’t handle depedencies well. Debian had some hacks that do that, which relied on special comments in initscripts. OpenBSD and FreeBSD order the base system’s startup for you, and rely on you to deal with ordering anything from packages or ports. SMF (and later, systemd) keep track of service dependencies, and ensure that those are satisfied before starting services.
init/rc scripts are fairly slow, and that can’t be avoided. Honestly, for traditional uses of UNIXes on traditional servers, this doesn’t matter. For desktops, laptops, and servers that expect frequent reboots for updates (CoreOS’s update strategy comes to mind), this does and that’s one of the places systemd inarguably shines. IME I haven’t seen similar speed from SMF, but it’s honestly so rare that I reboot a solaris box anyway.
init/rc scripts don’t have any mechanism for determining whether or not a service is running. pid files are very racey and unreliable.
pgrepcan also be suspect, depending on what else happens to be running on the system at the time. SMF and systemd reliably keep track of running processes, rather than leaving it up to chance.Another point not well made in this article is that writing init scripts can be awful. Package maintainers save you from this pain 99% of the time, but if you ever have to write your own on Debian or Red-Hat, there’s a lot of boilerplate you need to begin with. To be fair, OpenBSD proves that this doesn’t have to be as painful as Linux distros made it.
Saying that it’s not a difficult problem or that it’s all already solved by sysvinit/openrc/rc doesn’t really cut it, because it’s straight up not honest. SMF does solve these problems, and it solves them well and reliably. I used to be a systemd fan, but over time I’ve grown much more skeptical given some of the defaults and the attitude the systemd maintainers have towards the rest of the community at large.
I’d love a tool like SMF for Linux and the BSDs. I’ve used runit before, but man is it awful.
Related: A history of modern init systems (1992-2015)
Covers the following init systems:
IBM System Resource Controller (1992)
daemontools (1997) + derivatives (1997-2015)
rc.d (2000)
simpleinit, jinit and the need(8) concept (2001-3)
minit (2001-2)
depinit (2002)
daemond (2002-3)
GNU dmd (2003)
pinit (2003)
initng (2005)
launchd (2005)
Service Management Facility (SMF) (2005)
eINIT (2006)
Upstart (2006)
Asus eeePC fastinit + derivatives (2007-2015)
OpenRC (2007)
Android init (2008)
procd (2012)
Epoch (2014)
sinit (2014)
I was very happy with runit when I was using void (but this was only for a laptop and personal server). Can you elaborate at all on what you don’t like about it?
I believe I responded to you before about this :) I can elaborate more on that if you want.
https://lobste.rs/c/8qtwla
I imagine it works “well enough” on a desktop, so in that case it’s fine. But honestly, it’s not what I’m looking in a modern init system.
Porting some nontrivial initscripts from Fedora to Debian (or was it other way around, can’t remember) has been the most painful operation I have done in my career so far. Several hundred lines of shell script is never fun, even more so when the script uses crude distro dependent hacks to get everything bootstrapped in right order.
If systemd can lift that maintenance horror/pain from someones shoulders I am happy for it, even if I don’t personally like some decisions that systemd has done.
Just because they work doesn’t mean they are good. Windows always boots just fine for me when I want to play games, does that mean I would want to ever, ever, ever, ever touch anything system level in Windows? Certainly not.
Maybe you have a better idea of the issues here than you’re presenting, but I’m reading your comment as an “I hate systemd and I always will” knee-jerk response. The original post clearly articulates new issues that have cropped up in modern Linux systems, that systemd resolves. Instead you choose to blatantly ignore those issues. Have you actually dealt with lazy-loading hardware issues? Reproducible boots across 10k+ machines in a cluster? Have you actually worked with an init system in a meaningful capacity? Because it’s complete bullshit.
I acknowledge this comment is aggressive, but I’m sick and tired of systemd whining from people who don’t understand how much pain systemd resolves.
In my biased opinion, your post doesn’t actually articulate the problem many people have with systemd. It’s not that making a better init system may not be desirable but it’s that they don’t feel systemd actually does this well.
pkg installit and add<service>_enable="YES"to/etc/rc.conf. Done. It works. Now, some part of the FreeBSD community are talking about moving to something like launchd but…I don’t know what your experience is, but your post in no way makes me think “hrm, maybe systemd is a good idea”. Instead it makes me think “what kind of a chop-shop is Linux if you have the problems you listed and systemd is the answer?” It reminds me of the 7-Up commercials[0] where they have a blind taste test, and 7-Up wins, hands down, next to detergent and bile.
[0] - https://www.youtube.com/watch?v=vh3p5jFUUW8
[Comment removed by author]
Well, you asked, so by way of context, I was a Unix sysadmin dealing with hot-plugged hardware (ranging from SCSI-1 up to entire CPUs and bus subsystems), appearing/disappearing dev entries, “socket activation”, and dependency management in 1988.
The original post is actually a pack of hilarious cockamamie buzzword malarkey, as is “reproducible boots across 10k+ machines in a cluster”. But then, bluster and bravado are the fundamental atom of the red hat/freedesktop playbook, apparently.
I see. The Arch init scripts were particularly useless, so the switch definitely made sense for them. Given your expertise, I’d like to shift my stance and instead ask how you dealt with all these issues? Systemd is a glorified event loop, which deals with the problem nicely, but I don’t see how classic init-script based systems handle this at all. And I didn’t see them handling these issues when I was working on cluster management.
0) every init system is a glorified event loop (https://github.com/denghuancong/4.4BSD-Lite/blob/c995ba982d79d1ccaa1e8446d042f4c7f0442d5f/usr/src/sbin/init/init.c#L1178).
1) the init scripts were written correctly. I will 100% grant you that the Linux sysv init scripts were increasingly written without regard for quality or maintainability. Nevertheless, that is the fault of the maintainers rather than of the init system. If you’d like more of an education in this regard, download OpenBSD or FreeBSD and check out their rc scripts, which are quite clean, fast, effective, extensible, and comprehensible, and even less featureful than sysvinit.
2) hot plug was handled differently by different vendors, but generally the device would appear or disappear in /dev (kernel drivers discovered the device arriving or departing from the (hardware) bus) and a device- or subsystem-specific userland program would get notified by the change, and, e.g., mount/unmount file systems, etc. Also not rocket surgery.
3) we referred to “socket activation” by its original name, “inetd”, and we got rid of it as soon as we could.
4) dependency management was generally resolved with runlevels and sequential scripts. Even loaded down with crap, modern Unix machines boot in a matter of seconds with any init system. Unix machines generally stay up for years, so ‘super fast boot’ and parallel boot were things nobody cared about until the Desktop Linux crowd, who were so incompetent at getting CPU P-states to work properly that they actually rebooted their systems every time they opened their laptop lids. For years.
5) I do “reproducible boots across 10k+ machines in a cluster” with, like, whatever came after BOOTP. Maybe DHCP? In any case, that has nothing at all to do with any init system anywhere.
The easiest thing is to ask a few more whys. Or instead of how do we solve this problem, why do we have this problem? The best code is no code. :)
In the grander scheme of things, this is something that I believe is unfortunately common. My prime example of this is the Hadoop ecosystem. Hadoop is junk. Absolute junk. And every solution to Hadoop is…to add more code to, and around, Hadoop in hopes that somehow adding more will make a piece of junk less junk. In the end you get something that looks like a caricature of the Beverly Hillbillies truck and works twice as bad.
They didn’t. Like split /usr never actually worked, you were just imagining it.
Wait, what? I remember multiple flavours of Unix running with read-only NFS-mounted /usr, and I’m quite sure I wasn’t hallucinating at the time.
Nah, you’re wrong. https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Freedesktop said it’s broken. Must be true.
Ah, that explains it.
https://8fw.me/hell/aa91333ea724f4eff9b77aa082021386f7eedd5f.png kek
Funny. Stupid and probably not worth posting here, but funny.