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.