Init should not be Linux specific. That would be self-defeating for the project. Runit is system agnostic for the most part between BSDs and Linux with only some limitations on Solaris and Darwin/OSX due to them having proprietary init systems. I think Illumos is the only undocumented variable.
Linux is not UNIX but it is a UNIX-like system that runs a lot of UNIX derived software. Linux should in fact be upholding interoperability between different UNIX-like systems with software, not breaking it. Runit, bsdinit, sysvinit, and s6 are UNIX init solutions and should remain non-proprietary at all costs. Sent from my Windows Phone ________________________________ From: Joan Picanyol i Puig<mailto:[email protected]> Sent: 7/26/2014 12:48 PM To: [email protected]<mailto:[email protected]> Subject: Re: initialization vs supervision * Laurent Bercot <[email protected]> [20140723 23:17]: > On 23/07/2014 20:16, Wayne Marshall wrote: > >In the best of un!x traditions, a stronger system may in fact be one > >that recognizes the fundamental differences between the two > >functions, and provides purpose-specific solutions for each of them. > > This is the approach I have with s6. However, since I wanted to keep > s6 system-agnostic and, as you said, initialization is > system-dependent, I did not provide an out-of-the-box /sbin/init - and > it put too much work in the hands of packagers. I intend to work on a > s6-init package, which will unfortunately have to be Linux-specific, > to cover this flaw. The forked one-time initialization process can > safely be left to distribution packagers, just like /etc/runit/1 is; > but the tricky /sbin/init has to be provided in order for an > integrated init+supervision system to be usable. What "tricky" responsabilities are you thinking of for /sbin/init that would make it Linux specific? AFAICT, all that's being refered to as initialization in this thread is only system dependent as in "userland" dependent, not "kernel or (g)libc" dependent. As I see it, /etc/runit/1 or /etc/rc are pretty much the same... qvb -- pica
