Re: possible s6-rc redesign

["Laurent Bercot" <ska-supervision@skarnet.org>]

>1. There is one **huge** disadvantage for the second option. It is not a
>technical one, so it may carry little weight on your final decision.
>There already different implementations of init systems based on s6/s6-rc,
>some of them successfully used on distributions. They will almost certainly
>have to be abandoned or rewritten to function with the redesigned suite.
>The first option will allow these implementations to augment what they offer
>with minimal or no disruption for their users and developers.

  You may have missed the part where I'm saying that the current version
of s6-rc will still be supported for a *long time*. I would also try,
obviously, to make the conversion to the new format as painless as
possible; ideally (but I don't know yet whether it's an attainable 
goal),
the source directories would have the exact same format as long as only
static services are defined - so tools using s6-rc-0.x would still work
with basically no changes.


>2. Which distributions or groups of distributions will find the redesign appealing, so that they will adopt it ?
>IMHO distributions that use systemd are not likely to change in the foreseeable future,

  And they definitely won't, if nothing challenges systemd. But
providing the same level of functionality as systemd (as far as the
init system is concerned, I'm not talking about all the tendrils it 
sends
into various parts of running a Linux machine) with a better design, 
that
is not completely alien to what those distros are used to, is the only
way to - someday - have a chance at challenging systemd.


>  so that leaves the distributions that use something else. Some of them
>already have s6-based solutions (official or not), so adopting the redesigned
>will be akin to adding another init for them.

  No, absolutely not. The idea is to have something similar to s6-rc, but
with more functionality integrated in it. It would not be a different
init by any stretch of the imagination.


>3. Yes, the compiled db of services or the many files in the servicedir can
>discourage people to use s6-rc. But ANY new format will face similar
>criticism and some of the problems can be alleviated with the proper
>frontend. I use 66. Ι never touch servicedirs - it uses ini-based "frontend
>service files"- and I have dabbled with the compiled once, indirectly.

  I agree with that - except that the compiled db is actually a very
small hurdle, that goes away once you explain that OpenRC and systemd
also use a compiled db except that it's hidden and everything is done
dynamically, and s6-rc only makes it cleaner and more upfront.

  Yes, the solution is a user-friendly interface, but that's not
relevant to what I'm talking about. What I'm saying is that 
distributions,
including ones that currently use s6/s6-rc under 66 or any other
interface, *will* need dynamic events integration to the service manager
at some point, and the question is, how to add the functionality to
s6-rc. I think Option 2 is *more* likely to get adopted by
distributions overall. Distros that have already drunk the s6-rc
kool-aid will be fine with either option 1 or option 2 (see above);
normie distros will very probably be repulsed by option 1.


>4.  On the issue of mechanisms vs policy I fully agree that people want
>a turnkey solution. However I do not think that is something that should
>be done in a cetralised manner. There already at least 3 different working
>sets of services created for s6-rc (artix, slew, 66) and someone can inspect,
>use and modify them to fit their needs or policies.

  Yes, people can pick and choose what they want, and as it is now, 
things
are working for power users.
  That is still niche though, and in order to reach more people, a wide
array of distributions is the way to go.
  I'm very happy that distributions such as Obarun and Artix have done
the effort of actually porting services to a new format, be it 66
or raw s6-rc; but it is not something that can be expected from most
distributions, especially the big ones, which I *will* be aiming for at
some point. I don't like the idea of a software author providing policy,
any more than you do, but it is what worked for systemd and OpenRC, and
in case you haven't noticed, I'm trying to be very pragmatic here, and
to make the necessary sacrifices of principles in order to gain wider
adoption.

--
  Laurent