[einpoklum]

> 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]

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]

> 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