[conspire] Debian - and NOT systemd! :-)

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Also, Debian (both Buster 10 (stable) and Bullseye 11 (testing))
> have openrc ... but as packaged by Debian, looks to be service manager,
> and not init system itself - as it doesn't provide/configure
> /sbin/init however openrc Suggests: sysvinit-core which provides
> /sbin/init 

When I ran my series of OpenRC conversion experiments starting with
Debian 8 'Jessie' and continuing through Debian 9 'Stretch', I happened
to stumble upon success in that I happened to have left the /sbin/init
from SysVInit in place (not knowing at the time that Debian's OpenRC 
doesn't include a PID1 binary), with the result that my experimental
OpenRC setup booted serendipitously (or, one might
say, via dumb luck).

Docs (e.g., http://blog.darknedgy.net/technology/2015/09/05/0/) say
OpenRC can easily launch from other PID1 init binaries including, of
particular interest for me on servers and other hardware without
extremely dynamic hardware scenarios, Busybox init + mdev.

I'll note in passing that Debian's OpenRC package during the years I was
following this matter closely was pretty lackluster:  It was (last I
checked) a bit of a kludge where, yes, the basic OpenRC binary
infrastructure is there, but it's been mangled to process scripts for
SysvInit rather than OpenRC's own init scripts, and OpenRC's
/etc/conf.d/ tree (that holds default values for the corresponding
/etc/init.d/ scripts, eliminating the need for stability-risking edits
to the latter) is missing.

Devuan's official OpenRC package from package maintainer "Parazyd" is
more of a genuine Gentoo-original-style OpenRC init system with
(optional) service supervision, and is in general much more
satisfactory.

Anyway, _yes_ Debian's OpenRC package is an init system, just (last time
I checked) one with a home in it (not providing a PID1 binary) that you
can, fortunately supply easily.

However, have you checked the current Debian OpenRC packages to see
whether they picked up the openrc-init PID1 binary from upstream (who
bundled that starting around 2017)?  I'll confess, I have not checked,
as there's never been any reasonable objection to SysVInit's PID1 code,
so my attitude has been that I wouldn't turn down something slightly
better, but otherwise I don't care much.

Oh, not a complaint, but I _did_ cover all of the above on my
http://linuxmafia.com/faq/Debian/openrc-conversion.html page.


> Things may be different in Devuan ... or maybe not, in that regard,
> and maybe Devuan just describes it differently in the Devuan
> installer.

OpenRC _is_ definitely better in Devuan (last I checked).  FWIW, I
haven't lately bothered to check the state of the OpenRC package because
it seems like a no-brainer to just use the Devuan implementation, if I
wanted to build up such a system.

Speaking for myself, I've long regarded "Debian" as more usefully
construed to be the name of a style of packaging and administration, 
implemented by an array of mostly-compatible distributions, and I don't
really care whether the system thus-maintained started out being built
by an Official Debian installer ISO or something else.  E.g., for
decades my preferred installer for creating a Debian testing/unstable
desktop system was one of Aptosid's installer ISOs (and, later, its
schism project Siduction's ISOs).  People would sometimes be playing
with my desktop system and see Aptosid desktop images or
/etc/aptosid-release, and say "I thought you said this was a Debian
system?"  I'd reply "It _is_ a Debian system -- one I built starting
with an Aptosid ISO because it sucked less than the Official Debian one
and was a less-hassle way of making a cutting-edge Debian desktop."

So, basically for _me_, I regard the various Devuan-family installer
ISOs and a currently-better way of building a Debian system -- one where 
they've already applies local policy tweaks to override a few dumb
Debian Project policies, such that I'm spared from needing to do that
local-policy work myself.


> As for Devuan,
> looks like it currently offers 3 init systems:
> sysvinit
> openrc
> runit

It does, indeed.  The last of those is a generally decent DJB-style init
system with emphasis on daemontools-style service supervision, written
by Debian's Gerrit Pape

The author of the s6 suite has a page that compares and contrasts a
number of service supervisors / init systems, including runit:
https://www.skarnet.org/software/s6/why.html