supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Casper Ti. Vector" <caspervector@gmail.com>
To: supervision@list.skarnet.org
Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework
Date: Fri, 23 Mar 2018 21:20:58 +0800	[thread overview]
Message-ID: <20180323132058.GA21692@CasperVector> (raw)
In-Reply-To: <emf6ba9bba-7e14-43f1-90a6-3923ac5d6d7d@elzian>

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



  parent reply	other threads:[~2018-03-23 13:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180322132334.GA11596@caspervector>
2018-03-22 17:10 ` Laurent Bercot
2018-03-23  4:00   ` Casper Ti. Vector
2018-03-23 10:09     ` slew: renamed from "s6.rc" Casper Ti. Vector
     [not found]   ` <20180323040022.GA1737@caspervector>
2018-03-23 10:51     ` [Announce] s6.rc: a distribution-friendly init/rc framework Laurent Bercot
2018-03-23 13:05       ` Alex Suykov
2018-03-23 13:31         ` Casper Ti. Vector
2018-03-23 14:19         ` Laurent Bercot
2018-03-23 13:20       ` Casper Ti. Vector [this message]
2018-03-25  4:57         ` Casper Ti. Vector
     [not found]       ` <20180323132058.GA21692@caspervector>
     [not found]         ` <20180325045750.GA5868@caspervector>
2018-03-25  6:38           ` Laurent Bercot
2018-03-25  9:31             ` Casper Ti. Vector
2019-06-03  9:30   ` Casper Ti. Vector
     [not found]   ` <20190603093041.GA10891@caspervector>
2019-06-03 16:06     ` Laurent Bercot
2018-03-22 13:23 Casper Ti. Vector
2018-03-22 15:29 ` Casper Ti. Vector

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180323132058.GA21692@CasperVector \
    --to=caspervector@gmail.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).