Re: possible s6-rc redesign

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

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

  Yes, that is very true, and a concern I've increasingly had: OSes are
making *zero* coordination efforts for their interfaces, and software
is increasingly relying on OS-specific interfaces. So it's becoming more
and more difficult to write for Unix at large, and market fragmentation
is becoming more obvious by the day.

  For the various engines of an init system, though, I'm not too worried.
  - The early boot is inherently not portable (s6-*linux*-init is called
that way for a reason), but it's not a big or complex piece of code,
and it's easy to adapt it to another OS as soon as one has a working
knowledge of the details of init mechanisms on those OSes.
  - The supervision engine is portable, with a caveat.
  - The service manager is portable, even with dynamic event integration.
What is *not* portable is the various listeners that produce events,
but hooking a s6-rc-event call to them should not be difficult.

  The caveat for the supervision engine is, as you mentioned, cgroups
and namespace management, for the sole reason that the Linux way of
starting a process in a new namespace is contrary to the venerable Unix
pattern of changing your own process state then exec'ing: in some cases
you need involvement from the parent in changing the child's state.
There is a patch that has been submitted to this list that does exactly
that: tell s6-supervise to start the service in a new namespace. I have
not applied this patch because I didn't want to introduce system-
dependent features into s6, but with the way OSes are diverging, I might
soon have to bite the bullet and change my stance on this.

  But apart from that misdesign from the Linux kernel, most OS-specific
stuff can actually be done from inside services, in run scripts for
instance, so engines can be kept portable. If OS-specific tools are
needed to easily write service scripts, then those tools can be provided
as a separate, OS-specific package - like an extension.

  In other words: policy is definitely not portable and needs a lot of
extensions, but mechanism generally is, and I'm always starting with
mechanism - I'll address Linux policy later.


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

  Yes, but do not underestimate the general efforts that are being done
to have functionality outside of systemd. We're not the only bastion of
opposition here :) Alternate mechanisms do exist for most of what 
systemd
does; distributions mostly migrate to the systemd way of doing things
because it's more *convenient* to get the functionality from a single
source than it is to piece it together from various bits. systemd is
thriving on distribution laziness.
  But a distribution that is committed to not using systemd is (still)
very much able to offer a lot of functionality, it just requires
somewhat more effort.

  I don't expect to make it into Ubuntu or Red Hat right away. But if
a lot of other distros out there are running a credible alternative with
equivalent functionality, then at least users will have choice, and it
will be impossible for systemd advocates to pretend that their chosen
init system is inevitable. (insert Avengers: Endgame meme here)


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

  Possibly; that is honestly a packaging problem. It's a balance to find
between flexibility and convenience. systemd and OpenRC have played the
convenience card to the max and it has worked well for them; s6 has
always played the flexibility card instead, and experts love that, but
most people don't, especially when *no* policy is provided. :)

  If a package provides a set of init scripts, distributions will tailor
it anyway. The RedHat /lib/systemd is not exactly the same as the Ubuntu
one. The Alpine OpenRC scripts are not exactly the same as the Gentoo
ones. It does not really matter where the policy is provided, but
distros have made it very clear to me that they prefer having a working
set to start with and to tailor to their needs, rather than having 
nothing
and needing to come up with everything themselves. If it's better for
s6-frontend to be pure mechanism with a s6-frontend-policy package next
to it, why not; I don't think anybody really cares as long as this 
package
exists.

--
  Laurent