Re: possible s6-rc redesign

[mobinmob <mobinmob@disroot.org>]

On 2/9/20 1:20 π.μ., Laurent Bercot wrote:
>> 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.
>
If long term support is guaranteed and a smooth transition path is provided
then any concern I have suddenly dissipates :p

>> 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.
>

There are two issues here...

1. In order to provide the -sane- functionality of systemd, a system
needs to use linux-only interfaces. I am absolutely not saying that cgroups,
namespaces etc should be tightly integrated to a service manager/init 
system.
Most of the work can be done on dedicated programs but they are needed
if the goal is feature-parity...
2. Distributions that use systemd are slowly depending more and more on
these tendrils (great analogy btw :P). I do not think they will make the 
effort
to get rid of them or provide alternate mechanisms to facilitate inclusion
of a different init system no matter how much better, cleaner and well-
designed it is. And s6-rc is all three of them IMHO. The only way to create
pressure is a successful set of distributions that use other solutions...


>  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.

Well said :)


>  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.
>

Yes, dynamic events integration is absolutely needed, no argument there.
If that can be done with minimal disruption on the user/integrator side
I have no problems with either option.


>
>> 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
>

I am not saying that policy should not be provided at all. I am saying 
that they are
  advantages if it is provided outside of the main project and 
downstreams tailor it
to their specs. Voidlinux runit configuration
is influenced by ignite and artix runit is influenced by voidlinux. Both 
voidlinux and artix
have pretty different policies expressed in the relevant scripts. They 
also share a lot of
scripts. Building 66 frontend service files for voidlinux (unofficially) 
I have checked
obarun 66 frontends, artix s6-rc services and voidlinux runit scripts. 
but the minimal
policies I strive to implement are those of voidlinux.


My point is... runit has found adoption in the post-systemd era despite 
having
obvious issues. It was not a comprehensive upstream policy that helped it. I
think it is a better model for adoption that that of openRC or systemd.