💾 Archived View for gemini.ctrl-c.club › ~tjp › gl › 2023-04-06-runit-again.gmi captured on 2023-04-26 at 14:00:08. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I wonder how well runit shortcomings could be patched with a package of additional utilities.
If there is one thing that will get nerds talking, it's Systemd. And with the percentage of geminispace being populated by us nerds, the recent resurgence of the systemd hate train / apologetics has this place buzzing.
My favorite thing about that is how this is spilling over into minimal inits and daemon supervision suites, because I'm a software minimalist. Maybe not as extreme as the suckless folks, but I certainly have a deep-seeded "less is more" sensibility.
JeanG3nie had a super interesting post on 3/29:
Runit vs S6 by JeanG3nie 2023-03-29
I didn't know much about S6 having never used it, but I was at least aware of it as being on the newer and featureful side of the daemontools-inspired process management suites. JeanG3nie points out shortcomings in runit as a result of it perhaps being overly minimal (or maybe just old). It sounds, however, like these shortcomings can all be hacked around (that post includes an example of running a one-shot service with some clever code in the run script). The problem is just that these hacks can be incompatible with one another, or suboptimal in myriad other ways. The best support for service dependencies, one-shot services, etc are when that support is built into the process manager itself.
But is it? Here's where my mind started immediately racing: how many of these shortcomings really need process manager support to overcome, and how bad are the *best possible* solutions given the toolkit offered by runit?
Suppose there were a package which built on top of runit capabilities to offer a single best-in-class approach for the things it's missing relative to s6 and other newer suites? The existence of a single package does a lot to overcome the compatibility problem, and when I look at ./finish, ./down, ./log, and the many other tools already offered by runit, I strongly suspect we could bridge the gap. I'd like to call this package runit_again.
Why even bother when s6 and other, more capable managers already exist though? Because runit has to be the most ubiquitous of these daemontools-like suites. Distros like Void and Alpine linux[1] run it, busybox ships with it. And again, as a software minimalist, I'd actually kind of appreciate that these more advanced features are made optional by a separate package.
Still noodling on this one.
~tjp
---
---
[1] I was mistaken here. Alpine advertises being based on musl libc and busybox. While busybox does include a minimal runit implementation, Alpine also ships with OpenRC which it uses as pid 1 by default.