[sf-lug] systemd 8-O ... ; -) Re: SF-LUG meeting notes + abt some lightweight distros

[Rick Moen]

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

[snippity snippity snip]

> But for a quite reasonable distribution (e.g. Debian :-)) that offers
> lots of choice (Debian sure as heck does!), I'm definitely somewhere in
> the:
> Don't throw the baby out with the bath water!

In fact, I found myself, a couple of years ago, arguing with a bunch of
emotive anti-systemd people who kept claiming that it was outright
impossible to use the then-Testing branch of Debian, 'Jessie', that was
later released as Debian 8, without being 'forced' to rely on systemd.

After some pointless back-and-forth, I switched tactics and proved by
non-polemical data that the other folks were, and to my knowledge remain
(post-Jessie) mistaken, by doing a test installation of 'Jessie' and 
then doing a dirt-simple and extremely obvious conversion to use the
(IMO) very appealing init system 'OpenRC' -- and document that and all
the ramifications on a Web page
(http://linuxmafia.com/faq/Debian/openrc-conversion.html).  

The conversion was exactly thus:

apt-get install openrc
apt-get install sysvinit-core  #precaution, as the page explains
reboot

The page also details a couple of additional commands the admin can take
if he/she wishes to insure that no future package dependencies will ever
drag systemd back in -- a matter to which I'll return.  That would
involve, in part, the 'ramifications' to which I alluded.

> But personally, in choosing between:
> o A friggin' fantastic operating system (Debian) that happens to default to
>   systemd, but that offers one or more other fine alternatives to systemd
>   and highly well and easily supports them

Other init systems packaged by Debian 9 'Stretch' and later:
OpenRC
SysVInit
Upstart
Runit

Third-party compatible packages for Debian of additional init systems:
nosh 
s6
perp

The exact same method my page shows to move to OpenRC is equally usable
to move sideways to any of the others.



But, to address the elephant standing in the room, stomping on the flor
and trumpeting loudly:  This assumes the admin gives a damn about init
systems -- and hardly anyone does, or even can conceive of a reason why
he/she _ought_ to care.

And that, in turn, leads to another obvious consequence:  People
overwhelmingly do not make choices in this area; they just work with
whatever comes by default.  Oddly enough, it also turns out that Linux
distributions have drifted around in this area without a lot of
mindfulness, too.  

_Should_ readers of this thread care?  Maybe not.  They probably have a
lot more important things to think about, and don't see any reason to
even learn what an init system _is_.  And who am I to call that wrong?



This is the part where I talk about ramifications.  If you skim-read my
Web page (http://linuxmafia.com/faq/Debian/openrc-conversion.html), you 
see that expunging the systemd package from Debian 8 'Jessie' or Debian
9 'Stretch' has the effect of making some big, popular metapackages no
longer installable.  I refer to the umbrella metapackages of the GNOME,
MATE, Cinnamon, KDE, and Razor-qt Desktop Environments, the HPLIP
printer/scanner metapackage, and the GNOME network-manager tool in
various forms.

Why?  Because of systemd and related Freedesktop.org 'desktop' packages
(PolKit, PackageKit, udisks2, and a number of others) having such
excessive and far-reaching dependencies in many of the 'desktop'
packages that they form a near-unescapable package 'dependency
hairball'.  Commenters of a conspiratorial bent tend to allege that this
effect is deliberate, that there is a Freedesktop.org / systemd
conspiracy to worm their stuff into as many Linux systems as possible
and make movement sideways to alternatives infeasible.  

I don't agree with these conspiracy theorists.  I think what they
observe is just an emergent effect of some pernicious bad-coding
practices (many, including a crazy rate of EOLing/rearchitecting, poor
separation of modules, abysmal or missing documentation of programming
interfaces, excessive and unwise use of interprocess communication, 
and in general ignoring the lessons of decades of experience) on the
part of Freedesktop.org / systemd developers -- but agree that the
effect is real.

_And_ I agree with them that the 'dependency hairball' trend has been
and continues to be troubling.  A critical advantage of Unix all along
has been _modularity_:  If for some reason Portable OpenSSH becomes a
problem, I can quickly move to Dropbear or any of several functional
equivalents.  If my MTA becomes a problem, there are several other
functional equivalents.  If I don't want to run OpenNTPd for any reason,
there's Chrony or OpenNtpd.  And these options to move sideways go deep
into the system software:  If the Linux kernel proves problematic for
any reason, I can install the package for the kernel from FreeBSD and
boot that, instead.

By contrast, creeping motion towards 'Sorry, you cannot remove and
replace this', whether an intentional conspiracy or not, doesn't sit
well with me.  Not a bit.



> o Some other distribution/derivative, that is free of systemd, but is very
>   highly less common than Debian (or even very large distributions based upon
>   Debian

False dilemma in large part, because you are blithely glossing over the
nature of what Devuan is.

Devuan _is_ Debian, without system but (more important) with as much of
the Freedesktop.org / systemd 'dependency hairball' problem ironed out
as possible.  The Devuan packages are, to my knowledge, still exactly
compatible with the parallel Debian branches.

So, you can, if you wish, run Devuan and get both things you speak of, 
both Debian and freedom from systemd -- the things you say one must
choose between.

_Or_, if you don't mind some of the big DE metapackages remaining
uninstallable as whole big things (which in no way prevents constituent
DE applications remaining installable), you can run Debian.

By the way, the guys who told me it was flat-out impossible to run
Debian 'Jessie' without systemd, when I proved from hard data that they
were mistaken, fell back on first being angry with me and calling me
names & impugning my motives, but when I failed to rise to the bait
adopted the fallback position that it wasn't impossible with _today's_ 
Debian (then Jessie as 'Testing' branch), but would become that way
soon.  I've subsequently prodded them with a reminder that what I said
proved to be _also_ true of Debian 9 'Stretch', and they have continued
to lamely say 'Real Soon Now', or something like that.


> I suppose I could also sit around here and argue the case how (super-)simple
> it is to install and run Debian without (nearly) any systemd at all on it.
> But I won't (quite) do that.

Well, my page details that.  ;->

> Some other points to keep in mind:
> Much as some/many of us may dislike systemd and/or many of it's
> (mis-)"features" and/or components thereof ...


> *Most* things Linux are moving in the direction of systemd. 

Drifting, actually.  And, to a degree, getting _dragged_.

There is not a 'we are choosing to adopt the systemd init system because
it's the best of a number of alternatives'.  It's more like 'Oh, bloody
hell, so the GNOME package for GDM now requires systemd-logind because 
the Freedesktop.org ConsoleKit software is now orphaned and
unmaintained, and the only alternative to ConsoleKit providing the
'mutiseat' functionality the Freedesktop.org/GNOME developers claim is
mandatory is systemd-logind, which in turn drags in PolKit, udisks2, 
PackageKit, and the whole Freedesktop.org marching band as
_dependencies_?  Why the bloody hell do we need multiseat, anyway? 
Isn't this the 21st Century?'

The multiseat thing forces distributions to choose between being able to
control which init system they prefer _or_ being able to offer 
GNOME, MATE, Cinnamon, KDE, Razor-qt, HPLIP, and network-manager without
a great deal of distro-level software engineering they are not prepared
to undertake. 

So, they get dragged.


> Oh, also, Debian does a very good job of pulling systemd apart (and also
> throwing crud out and/or "banishing" it to separate optional packages for
> systemd).

This has mostly been separating out and omitting from Debian's systemd main
package the increasing pile of 'optional' systemd components Poettering
and the other systemd developers keep piling into it, as they decide to 
rewrite (usually badly) other pieces of key Unix system software.  An
example is their NTP add-on for systemd -- which upon creation
immediately was found to suffer from a hilarious architectural error
that totally destroyed the security of systems where it was activated.

What one might laughingly call the 'core' systemd codebase, as packaged
by Debian, is nonetheless hideously bloated in functional scope.  And 
some of that _is_ quite deliberate, e.g., the systemd developers made a
point of merging udev into systemd when they took over that project
_and_ have made clear they will refuse any patches to re-separate them
or provide within the source tree tools to build one without building
the other.  Why?  Presumably because they just want to make it
gratuitously difficult to have udev without also getting systemd.
Because they're monumental, arrogant jerks the likes of whom I prefer to
have no reliance on, speaking for myself.