Those are unmanaged services, if they crash for any reason, they won't be restarted? For embedded use cases this is probably fine, but for desktop it is a problem.
> In that world, the dependencies are easily expressable in the shell script itself [...] It feels very much in line with the Unix philosophy.
This is why I use runit and let the program determine it's own dependencies. If it fails to start, runit will try again in 1 second... forever. This actually works great in practice, but it does present a problem for "on-demand" services.
They can still be built, but I've always avoided them for the problems they present. For typical 'inetd' applications, I find ucspi-tcp to be an ideal solution for everything else I try to find some reasonable compromise which for most of the cases where I need a true managed set of services is very rare.
> and retaining all of the baggage from that when it became a personal OS?
It's worse in my mind, they're pantomiming the competition which seems to be a complete misunderstanding of the platform they're using.
On the other hand, some servers are expected to work, and if they crash, it should be investigated, because it's probably a big deal. In my experience auto-restart goes hand in hand with never investigate why it restarts. Sometimes that's appropriate (for software you basically have to run, but don't control), but more often it's terrible.
Or systemd, which is fine for many use cases.
2) based on the train of horrors for every single network daemon they write, do you trust that their systems level code is somehow good?
3) well their record on systems level code isn't that great either, username parsing really didn't go well
4) is systemd demonstrating engineering excellence of as simple as possible, but no simpler?
5) out of the box, my experience with Debian + systemd + a crashy service (from packages) was that the specific crashes I was getting didn't result in a restart, because it got a segfault instead of simply exiting. --- also, it changed the boot process so I couldn't ctrl-c out of slow things, so that was net negative.
It was simple, but it was also error-prone because you're re-inventing the logic every time. And it made it really difficult to automatically install software because instead of dropping a file into a directory, you had to programmatically edit a common file. Installer scripts would do all kind of horrible things like "cat myscript >> /etc/rc.local". The situation forced software maintainers into doing something (automated editing of code) that they weren't skilled at, with tools (Unix commands) that weren't very well suited for it.
Having a more data-driven, standardized approach split up into multiple files was a huge improvement from a maintainability standpoint. Yes, it's more complicated, but in my opinion the complexity was easily worth it.
And by the way, its predecessor, with insserv and startpar, also supported parallel execution of init scripts.
This is exactly how other init systems work such as s6 which uses chain-loading with execline or arsv minitools init that uses a minimal custom shell call msh.
EDIT: added supervision/restart
In that world, the dependencies are easily expressable in the shell script itself: requirement is &&, want is ;, and ordering is simply... the order in which the commands appear in the file. It feels very much in line with the Unix philosophy. Thus the relative complexity of all the other "init systems", even including the original sysvinit, seems rather excess to me --- was it just a case of Linux/Unix originating with multiuser servers and retaining all of the baggage from that when it became a personal OS?