4 ms·

systemd v SysVinit was a war between developers and admins. admins don't reboot, so the advantage of faster booting, which is the prime reason for systemd devel

systemd v SysVinit was a war between developers and admins. admins don't reboot, so the advantage of faster booting, which is the prime reason for systemd development, is silly and unnecessary from the perspective of professionals that do not reboot their machines. Nor do admins care about laptops, unlike developers who are obsessed with them and can't function without them for more than a minute at a time, give or take, thus their need for their reboots to be as instant as possible. systemd, being complex and not written in Bash, was always the antithesis of UNIX philosophy. It keeps getting more and more complex as it creeps ahead adding features, taking over more and more of the system. systemd won the war because developers held all the cards, and admins, being cautious and overly concerned that systems remain stable and resilient, are slow to react. Inexplicably, admins will not do anything to fix something that was never broken in the first place, while developers, without restraint, are forever changing things to make them "better." Mercifully, there is still some rock solid BSD around which by and large Linux replaced in a way similar to how systemd replaced init, primarily because of making faster-booting a priority, because developers don't want to wait around while they are constantly rebooting their laptops, but also a fanatical verve and the entitlement that it would be more comfortable for developers if the datacenter at their day job ran the hobby OS on their constantly rebooting laptops. It was a very one-sided battle of young developers against sleepy greying UNIX admins and neckbeard engineers that were hardly aware of what was happening and were retiring soon anyway. But as it turns out, systemd only conquered so much territory and was some how stopped before assimilating every single Linux distribution.[1] [1] https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd https://en.wikipedia.org/wiki/Category:Linux_distributions_w...

raggi 4y ago
sysadmins should reboot to update kernels, but even if you want to avoid reboots you still need to correctly and reliably update a tree of dependent services periodically in order to apply security updates.
- Maursault 4y ago
  There is such a thing as live patching a kernel without rebooting. Whatever it is that you think you need to reboot because of, it would always be better if you did not need to, because uptime and constant and consistent availability of services is virtuous.
  - raggi 4y ago
    That's true, but that only reinforces what I'm saying. Lets say you have a working kexec setup so you never need to reboot, that is very likely to increase the need for you to be able to robustly restart trees of dependent services in userspace.
    - Maursault 4y ago
      Stateless systems aren't difficult. The load balancer need not route to nodes with updating services. It is possible to design code that can update without restarts, but few developers are industrious enough to make it a priority. Evidently, the trickier and more difficult a specification is, the less likely a developer is enthusiastic about providing it.[1] [1] https://i.imgflip.com/1rug8x.gif https://i.imgflip.com/1rug8x.gif
theamk 4y ago
A lot of those things don't use plain bash either... Of that bigger things in that list: There is OpenWRT, which uses "procd" (a process management daemon written in C, like systemd but smaller) with its own system bus ubus (like dbus but smaller) There is Android with its own proprietary init system. And many others use OpenRC, which is 65% C and 30% shell (according to github). the init files do use shell syntax, but you are supposed to use their interpreter [0] "if you insist on using #!/bin/sh you're on your own" [0]. In fact, the recommended approach is declarative method when you specify name of main binary and their args.. just like systemd. The world is moving and sysvinit is left behind. [0] https://github.com/OpenRC/openrc/blob/master/service-script-guide.md https://github.com/OpenRC/openrc/blob/master/service-script-...
- Maursault 4y ago
  Post is nearly entirely whataboutism. > The world is moving and sysvinit is left behind. Contrary to the popular belief in your microcosm, the world did not adopt systemd. Android, Knoppix, Slackware, among dozens of other distros, rejected systemd. macOS uses launchd, which inspired systemd, yet launchd is generally more unix-like in that it assumes a daemon knows what's best for itself, and doesn't make decisions for it, nor is launchd aggressively annexing Darwin. Oracle Solaris, Illumos and variants use SMF of which sysvinit is likely a dependency, while NetBSD, FreeBSD and OpenBSD use rc, a BSD-style init also of which sysvinit is likely a dependency. Though Linux replaced a lot of BSD installations in the last decade, like systemd has replaced sysvinit in a lot of distros, the decision to do so was arbitrary and without compelling advantage or reason, and apparently mostly due to fanatical devotion. BSD, fwiw, isn't going away, and in various implementation, neither is init.
  - theamk 4y ago
    Did you notice I haven't mention systemd in my comment at all? And other than this first sentence, I am not going to mention it in this comment at all. The important thing is not who won, but the fact that the idea of writing init scripts in bash/sh has lost. Almost no one wants to maintain yet another incomplete or buggy shell script implementating of "start", "stop" and "status" commands. It is declarative way now - somehow define the command, arguments, user etc.. and let init system handle start/stop. (Yes, there are still ancient systems like Slackware which use plain bash and have no plans to change. But even FreeBSD is pushing toward declarive: look at [0], does this look like a simple shell script which makes it cleat what's going on?) [0] https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daemon https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daem... That's why the people who advocate sysvinit get so little support. Try advocating for runit or daemontools or launchd or openrc or even SMF ( :) ), this will get you further.
mikepurvis 4y ago
As a sometimes-administrator of Linux systems, I have lots of reasons for finding setting up, altering, and reasoning about various daemons to be all much better and less error-prone in a systemd world. It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. I also barely ever reboot my system but still appreciate systemd's approaches to things like logging, service status, and service overridability.
- Maursault 4y ago
  > As a sometimes-administrator of Linux systems, You can have sometimes-availability of services. > It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. It couldn't possibly be a straw man because I didn't disagree with the OP nor did I bother misstating his argument (flagged due to pretentiousness but not his own) in order to attack it. It is simply a fact that fast boot was the prime reason for systemd development. The most fundamental goal of the developers' was to increase efficiency with parallel service startup to achieve fast boot. Everything else may be considered feature creep, and without the feature creep, there would have been less criticism and resistance, as faster boot in and of itself isn't necessarily terrible. What is terrible is complexity and increasing complexity, as it will necessarily introduce fragility the more complex it becomes. For the record, if it wasn't obvious, my post was tongue-in-cheek and supposed to be funny in using false stereotypes to poke fun at developers, whom, of course, I respect immensely, yet by and large they can be a little sensitive sometimes, especially to any criticism of Linux or anything Linux does. There are valid views from all sides, and tribalism is usually not a good thing, yet humility and tolerance are virtues. If developers can't laugh at themselves, I can do it for them in hopes of dragging them along, kicking and screaming if need be.
chungy 4y ago
> the advantage of faster booting, which is the prime reason for systemd development It was more of a side effect, rather than being a primary reason. Good design and utilizing dependency resolution and parallelization led to it also happening to be faster.
- Maursault 4y ago
  Faster boot was most certainly not a side-effect but instead it was the inspiration and drive behind systemd development. The prime goal of the original developers in parallel initializations was more efficient processing so booting would be fast. If anything, the design was a side-effect of the faster boot agenda, not the other way around.
  - chungy 4y ago
    I suggest you reread "Rethinking PID 1": http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Nobody happens across good design as a side-effect of going fast. It's much the other way around.
    - Maursault 4y ago
      > Nobody happens across good design as a side-effect of going fast. Straw man. What I argued, and what is the case, is that the developers wanted faster boot; that was the motivational spark behind systemd, not good design. The design followed in order to achieve the faster boot, thus the design can be seen as a side-effect of the faster boot agenda. The subject of speed is dominant in the document you cited: "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast.... For a fast and efficient boot-up two things are crucial... and hence the overall start-up time minimized." It is obsessed with boot time. As I stated, that is the foundational goal of systemd, reducing the time it takes to reboot.

raggi 4y ago

sysadmins should reboot to update kernels, but even if you want to avoid reboots you still need to correctly and reliably update a tree of dependent services periodically in order to apply security updates.

Maursault 4y ago
There is such a thing as live patching a kernel without rebooting. Whatever it is that you think you need to reboot because of, it would always be better if you did not need to, because uptime and constant and consistent availability of services is virtuous.
- raggi 4y ago
  That's true, but that only reinforces what I'm saying. Lets say you have a working kexec setup so you never need to reboot, that is very likely to increase the need for you to be able to robustly restart trees of dependent services in userspace.
  - Maursault 4y ago
    Stateless systems aren't difficult. The load balancer need not route to nodes with updating services. It is possible to design code that can update without restarts, but few developers are industrious enough to make it a priority. Evidently, the trickier and more difficult a specification is, the less likely a developer is enthusiastic about providing it.[1] [1] https://i.imgflip.com/1rug8x.gif https://i.imgflip.com/1rug8x.gif

theamk 4y ago

A lot of those things don't use plain bash either... Of that bigger things in that list: There is OpenWRT, which uses "procd" (a process management daemon written in C, like systemd but smaller) with its own system bus ubus (like dbus but smaller) There is Android with its own proprietary init system. And many others use OpenRC, which is 65% C and 30% shell (according to github). the init files do use shell syntax, but you are supposed to use their interpreter [0] "if you insist on using #!/bin/sh you're on your own" [0]. In fact, the recommended approach is declarative method when you specify name of main binary and their args.. just like systemd. The world is moving and sysvinit is left behind. [0] https://github.com/OpenRC/openrc/blob/master/service-script-guide.md https://github.com/OpenRC/openrc/blob/master/service-script-...

Maursault 4y ago
Post is nearly entirely whataboutism. > The world is moving and sysvinit is left behind. Contrary to the popular belief in your microcosm, the world did not adopt systemd. Android, Knoppix, Slackware, among dozens of other distros, rejected systemd. macOS uses launchd, which inspired systemd, yet launchd is generally more unix-like in that it assumes a daemon knows what's best for itself, and doesn't make decisions for it, nor is launchd aggressively annexing Darwin. Oracle Solaris, Illumos and variants use SMF of which sysvinit is likely a dependency, while NetBSD, FreeBSD and OpenBSD use rc, a BSD-style init also of which sysvinit is likely a dependency. Though Linux replaced a lot of BSD installations in the last decade, like systemd has replaced sysvinit in a lot of distros, the decision to do so was arbitrary and without compelling advantage or reason, and apparently mostly due to fanatical devotion. BSD, fwiw, isn't going away, and in various implementation, neither is init.
- theamk 4y ago
  Did you notice I haven't mention systemd in my comment at all? And other than this first sentence, I am not going to mention it in this comment at all. The important thing is not who won, but the fact that the idea of writing init scripts in bash/sh has lost. Almost no one wants to maintain yet another incomplete or buggy shell script implementating of "start", "stop" and "status" commands. It is declarative way now - somehow define the command, arguments, user etc.. and let init system handle start/stop. (Yes, there are still ancient systems like Slackware which use plain bash and have no plans to change. But even FreeBSD is pushing toward declarive: look at [0], does this look like a simple shell script which makes it cleat what's going on?) [0] https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daemon https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daem... That's why the people who advocate sysvinit get so little support. Try advocating for runit or daemontools or launchd or openrc or even SMF ( :) ), this will get you further.

mikepurvis 4y ago

As a sometimes-administrator of Linux systems, I have lots of reasons for finding setting up, altering, and reasoning about various daemons to be all much better and less error-prone in a systemd world. It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. I also barely ever reboot my system but still appreciate systemd's approaches to things like logging, service status, and service overridability.

Maursault 4y ago
> As a sometimes-administrator of Linux systems, You can have sometimes-availability of services. > It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. It couldn't possibly be a straw man because I didn't disagree with the OP nor did I bother misstating his argument (flagged due to pretentiousness but not his own) in order to attack it. It is simply a fact that fast boot was the prime reason for systemd development. The most fundamental goal of the developers' was to increase efficiency with parallel service startup to achieve fast boot. Everything else may be considered feature creep, and without the feature creep, there would have been less criticism and resistance, as faster boot in and of itself isn't necessarily terrible. What is terrible is complexity and increasing complexity, as it will necessarily introduce fragility the more complex it becomes. For the record, if it wasn't obvious, my post was tongue-in-cheek and supposed to be funny in using false stereotypes to poke fun at developers, whom, of course, I respect immensely, yet by and large they can be a little sensitive sometimes, especially to any criticism of Linux or anything Linux does. There are valid views from all sides, and tribalism is usually not a good thing, yet humility and tolerance are virtues. If developers can't laugh at themselves, I can do it for them in hopes of dragging them along, kicking and screaming if need be.

chungy 4y ago

> the advantage of faster booting, which is the prime reason for systemd development It was more of a side effect, rather than being a primary reason. Good design and utilizing dependency resolution and parallelization led to it also happening to be faster.

Maursault 4y ago
Faster boot was most certainly not a side-effect but instead it was the inspiration and drive behind systemd development. The prime goal of the original developers in parallel initializations was more efficient processing so booting would be fast. If anything, the design was a side-effect of the faster boot agenda, not the other way around.
- chungy 4y ago
  I suggest you reread "Rethinking PID 1": http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Nobody happens across good design as a side-effect of going fast. It's much the other way around.
  - Maursault 4y ago
    > Nobody happens across good design as a side-effect of going fast. Straw man. What I argued, and what is the case, is that the developers wanted faster boot; that was the motivational spark behind systemd, not good design. The design followed in order to achieve the faster boot, thus the design can be seen as a side-effect of the faster boot agenda. The subject of speed is dominant in the document you cited: "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast.... For a fast and efficient boot-up two things are crucial... and hence the overall start-up time minimized." It is obsessed with boot time. As I stated, that is the foundational goal of systemd, reducing the time it takes to reboot.