Re: [Announce] s6.rc: a distribution-friendly init/rc framework

From: Casper Ti. Vector <>
Date: Fri, 23 Mar 2018 21:20:58 +0800

On Fri, Mar 23, 2018 at 10:51:57AM +0000, Laurent Bercot wrote:
> That's all fine with me, but it may have connotations in English
> that you don't want to associate with a project aimed at stability
> and friendliness :)

See also project names like "git", "curses" and "snort"... :)

> Bear in mind that - this is a simplified, but descriptive enough view
> of the political landscape of the current Linux ecosystem - distribution
> maintainers are *lazy*.

Now I understand. What a pity for distro developers / users and us.

> I'm not turning s6 into a monolithic behemoth, don't worry. ;)

I (and probably many others) never worried about this :)

> To provide a reasonably lightweight but immediately usable and
> distro-adoptable init system, there is a golden mean to be found, and I
> think it's important to find it.

Well, slew.rc does not technically require much more than those provided
by what are usually shipped with the base system in common distros,
except for rc(1) and s6/s6-rc/execline. But it requires the user to be
sufficiently familiar with s6/s6-rc and rc(1), so the main problem is
what you called the current political landscape.

> But is it the software's job to determine the format of the
> network configuration file, or is it purely the distribution's?
> Is it an advantage for an init system to come with its own
> network configuration format, or a drawback? Is it possible, and
> worth it, to write hooks that call pre-existing network scripts,
> or should the whole network interface config mess be torn down and
> rebuilt from scratch? Those are the exact kind of questions we need
> to ask ourselves.

Good questions, and I certainly need more time to think about them.
I guess that, for the slew.rc-based netifrc replacement I imagined,
assuming it is sufficiently well-designed, it would not be too
difficult to port it to another daemontools-like init/rc framework
according to the underlying logic.

My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Fri Mar 23 2018 - 13:20:58 UTC

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