In addition to s6 itself, the author of s6 also wrote a survey <https://skarnet.org/software/s6/why.html> that provides a good large-scale view of the design space.

(My gripe with how systemd does a traditional init’s job is mostly the unit and dependency types, all of which AFAICT are specified in terms of actions on state transitions, not consistency conditions on states, so for all that it has a positive boatload of them I can’t actually figure out how to specify which configurations are permissible for my system.)

I stopped reading when they started attacking bind. Sheer ignorance. Also cathedral is good for him and his elite team but not in general?

Unix has always been worse is better. You may disagree but it is the secret sauce. YAGNI for that potentially ideal system. Sadly. I like mathematically solid systems but the people with good enough systems explore the solution space much quicker.

I’m not sure what you are referring to. Do you mean some other page on that website? There’s a fair bit of design philosophy there, and I vaguely remember reading it and agreeing with some parts while disagreeing with others, but that was years ago. I’ve no interest in defending an arbitrarily chosen subset of the author’s views in this thread.

Indeed I don’t even necessarily agree with everything said on the page I linked to (which I did reread before posting the comment), but regardless of what I think about the particular point in design space (s6) it advocates, I still consider it a good overview of the space itself and prior art in general, and that’s the only thing I claimed to offer. I do have some thoughts about init systems, but I don’t feel they’re ready to put them up for discussion here, so I haven’t.

> Software that does more instead of less is, simply put, badly designed software. Trying to come up with an all-encompassing solution is always a sign of developer hubris and inexperience, and never a sign of good engineering. Ever. Remember sendmail, BIND, INN,

Yeah from the skarnet page above. BIND had many troubles over the years but mostly because we were all learning about secure code practices in C etc. bind was just a name server. Never heard of it reading mail. There was a lot to learn about network exploits, for sure. But attacking bind as doing too much seems disingeneous. And the whole tone reminds me of the same tone as https://suckless.org/ who cares if some browser takes a Gig of RAM or my window manager is ginormous. My laptop is hard pressed to use all the RAM it has and if systemd and the kernel is running sixty daemons but the unit files are easy to write as a here doc in cloud init, then win win win.

(Running postfix and bind on my personal cloud VMs; have run Apache, haproxy, nginx and lighttpd, as well as built in Python web servers).

s6 does it well

https://skarnet.org/software/s6/

Looks quite neat, though perhaps just a little more complex than systemd service files, I guess they essentially boil down to similar things.

Where systemd has one file with a bunch of settings in, this is split into a directory of single-purpose files in s6. I'd hesitate to call it "better", but from a surface reading it seems roughly equivalent from a usability perspective.

According to the author, Laurent Bercot, the code for s6 is much cleaner than the systemd code. For anyone curious I guess the best way to find out is to compare and make a judgment of one’s own.

While I appreciate clean code when I have to work on it, it's somewhat orthogonal to my requirements when we're talking about running systems rather than building them.

I guess it could be preferred as a second-order factor.

In some ways yes, in other ways no. I've looked at both, and there is always a certain amount of "ugliness" that comes with writing low level C software for Unix.

I would rather have complexity in the engine code than in the unit files. A clean implementation is less important than a clean interface.

I'm not familiar with s6 myself. But - the choice between a single file or multiple files in a directory is a relatively minor issue in the overall scheme of things. i.e. if s6 is "better" or "worse", it's not because of this fact.