3 ms·

> Prior init's were actually quite easy to replace and alternatives were often used, but these days most software assumes systemd and this situation gets worse

> Prior init's were actually quite easy to replace and alternatives were often used, but these days most software assumes systemd and this situation gets worse every year. Not really. Sysvinit scripts are... scripts full of sysvinitisms (double forking and PID files, anyone?). Idiomatic systemd daemons are, comparatively speaking, very straightforward. Of course, there are a lot of nice-to-have features, but to get a running system, you should largely be able to get away with parsing Wants=, After=, and ExecStart=.

einpoklum 3y ago
> Not really. Sysvinit scripts are... scripts full of sysvinitisms (double forking and PID files, anyone?). ... well, a bunch of scripts are something that's relatively easy to replace. It's not as though other system components have reliance of these scripts and their sysvinit'isms baked in. From what I've heard (though not verified) - non-systemd distributions seem to manage to work with upstart, or openrc, instead of sysvinit, without much hassle.
- dijit 3y ago
  Previous inits were glorified loop { fork() } programs. There were many scripts, many implementations, but interestingly most were compatible with each other. The largest issue inits had was that the flexibility they provided gave distro maintainers a lot of choice in how those scripts should operate to be consistent with the rest of the system. Things like log locations. The issue to be solved is: how to determine parallelism in boot, how to supervise a process with minimum complexity, and how do we do structured logging. Interestingly: SMF solved all of these a decade before.
  - einpoklum 3y ago
    > Previous inits were glorified loop { fork() } programs. Maybe (I'm not an expert on old init systems), but current inits aren't that. > The issue to be solved is: how to determine parallelism in boot I think you're replying to another comment of mine. At any rate, there were and are alternative solutions rising to meet this challenge - which involve nothing like the behemoth which is systemd. Examples: OpenRC, runit, GNU Shepherd (sort of). https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC

einpoklum 3y ago

> Not really. Sysvinit scripts are... scripts full of sysvinitisms (double forking and PID files, anyone?). ... well, a bunch of scripts are something that's relatively easy to replace. It's not as though other system components have reliance of these scripts and their sysvinit'isms baked in. From what I've heard (though not verified) - non-systemd distributions seem to manage to work with upstart, or openrc, instead of sysvinit, without much hassle.

dijit 3y ago
Previous inits were glorified loop { fork() } programs. There were many scripts, many implementations, but interestingly most were compatible with each other. The largest issue inits had was that the flexibility they provided gave distro maintainers a lot of choice in how those scripts should operate to be consistent with the rest of the system. Things like log locations. The issue to be solved is: how to determine parallelism in boot, how to supervise a process with minimum complexity, and how do we do structured logging. Interestingly: SMF solved all of these a decade before.
- einpoklum 3y ago
  > Previous inits were glorified loop { fork() } programs. Maybe (I'm not an expert on old init systems), but current inits aren't that. > The issue to be solved is: how to determine parallelism in boot I think you're replying to another comment of mine. At any rate, there were and are alternative solutions rising to meet this challenge - which involve nothing like the behemoth which is systemd. Examples: OpenRC, runit, GNU Shepherd (sort of). https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC