It's not great having something as large and complicated as the Guile interpreter running as PID #1. There's actually a couple of bugs that got wontfix'ed because the issue boils down to "the interpreter's self- initialization process assumes more of the normal runtime environment is available than what the first user space process gets and there's nothing we can do about it" (https://codeberg.org/guix/guix/issues/735 and https://codeberg.org/shepherd/shepherd/issues/53 ). But leaving those aside -- they are largely cosmetic -- it's *dangerous* to put a lot of code in process 1, because more code means more bugs, and if process 1 crashes it takes out the entire system.
So I had an idea: what if we had a couple of tiny programs *not* written in Guile, one of which would do *just* what the kernel needs process 1 to keep doing forever (i.e. call wait() in an endless loop), and the other one to get the first tiny program plus the real Shepherd started? And here they are: https://git.sr.ht/~zackw/rc-shim These are proof-of-concept implementations right now; notably, I do not know whether it is *useful* for "nanoreaper" to forward orphaned process exit notifications to the real Shepherd, and nothing has been tested in "real life" usage. But they should be robust enough to experiment with, at least. I'd like to hear whatever you have to say about them. zw
