> But then all init is doing is launching your process supervisor.
This "all init does/needs to do" notion is oft-repeated, but it is oft-repeated rubbish. It is a notion commonly held by people who have never actually written a process #1 program that functions in production systems; because experience (as I can attest) teaches otherwise. There are, in fact, several things that various operating system kernels and other programs demand of process #1 that one simply cannot escape. People think that fork()ing things and acting as the parent of orphaned processes is the prime function. Ironically, dealing with orphaned processes is (with recent Linux kernels) a part the system that one can largely factor out of process #1 into other processes, whilst the things that people usually forget in their off-the-top-of-the-head designs for init (such as handling SIGINT, SIGPWR, SIGWINCH, and so forth sent from the kernel and enacting the various system state change requests) are the parts that one cannot. To see what one actually has no choice but to do in process #1 programs, look at the overlaps in the operation of Gerrit Pape's runit, Felix von Leitner's minit, and the system-manager program from the nosh package. There are several things for a /system manager/ to do when there's a separate /service manager/.