RE: initialization vs supervision

From: James Powell <>
Date: Sat, 26 Jul 2014 13:18:18 -0700

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<>
Sent: ‎7/‎26/‎2014 12:48 PM
Subject: Re: initialization vs supervision

* Laurent Bercot <> [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...

Received on Sat Jul 26 2014 - 20:18:18 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC