[conspire] (forw) Re: In which I document moving easily to OpenRC on Debian Jessie

[Rick Moen]

Steve is an _incredibly_ worthwhile guy, but he's one of those
anti-systemd ranters.  Anyway, this is part of a conversation we had
after I called my new Web page
http://linuxmafia.com/kb/Debian/openrc-conversion.html to his attention
and asked his feedback.

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Sun, 8 May 2016 04:02:45 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Steve Litt <slitt at troubleshooters.com>
Subject: Re: In which I document moving easily to OpenRC on Debian Jessie
Organization: If you lived here, you'd be $HOME already.

Quoting Steve Litt (slitt at troubleshooters.com):

> You really, really, REALLY need to create a link to your document from
> http://without-systemd.org/wiki/index.php/Main_Page#Other_useful_sites .
> This is extremely needed information.

I will do so after I polish it just a little more.

This conversation is a big help in finding the rough spots and refining
my thinking.  More on that, below.

I just realised, in fact, yet another error right near the top:  I refer
to OpenRC as an 'init'.  But that isn't correct, is it?  Because OpenRC
cannot do PID1 duties and needs something else to be that.  So, strictly
speaking, it is not an init, and in fact _needs_ an init.

This whole topic has tragically suffered from lack of clarity.  Your 
articles helped me get past some confusion.  So did the Arch Linux 
wiki articles, as have analysis pieces by the uselessd guy.  I mean no 
disrespect in saying so, but most of those have been too verbose for
quick understanding -- but a clearer picture has sunk in over time.

Most discussion made a conceptual goulash of related but distinct
things:  

o  init process
o  init scripts / infrastructure
o  service manager (optional)

(But see below, where Arch Linux adds a fourth, composite category
called inits - integrated.)

My background is in server computing, where we always knew and valued 
service managers, but equally valued the ability to either place 
services under their control or not, at our will, a la carte.  Sometimes
you want a daemon to get respawned if you die, but often you really
don't -- or the chance of that happening is so remote or the
disadvantage is so small that you'd rather avoid the extra overhead and
complexity of service management.

Reminds me:  I see exchanges between systemd and anti-systemd people
where the first suggest they invented socket activation and the latter 
rejoin 'No, Apple did it first with launchd', and I think:  Guys,
doesn't anyone else remember inetd and xinetd?

Linux has _always_ had socket activation (using inetd and xinetd), all
the way back to 1992.  We didn't put all our services under it, and only 
ran obscure junk like chargen and svnserve there, because socket
activation kinda sucks for any significant service.

https://wiki.archlinux.org/index.php/init further helped clarify my
thinking.  It distinguises:

o  inits (integrated)
o  inits
o  init scripts
o  service managers

Arch Linux classifies OpenRC (as packaged by Arch Linux) as a service
manager, but they also list 'OpenRC Arch Services' under init scripts.
I believe this is correct -- though IIRC the service management aspect
isn't default let alone obligatory.  (I'm unclear on this.  Need to kick
the tires some more, and/or find writings where others have done so.)

I expect that Debian's OpenRC package bundles the functionality of Arch
Linux's two package, and thus is init scripts + (non-default) service
management.

So, my current thinking is that Arch Linux's taxonomy is the right way
to think of this, though my earlier bullet points IMO correctly list the 
underlying basics.

And, anyway, OpenRC isn't actually an init.

It's testimony to the severity of the confusion problem that I still
made that error in May 2016.  My excuse is that an 'init' on the BSD and 
Linux systems traditionally has been a composite of init + init scripts.
One oddball 'init' I used when I couldn't avoid doing so was Solaris's 
SMF, which is init + init scripts + service management.  Nobody with
half a brain _likes_ SMF, so we tend to cast it out of our minds except
when forced to deal with it.


> Such claims *would* be gross exaggerations if we could assume that
> Debian would *always* package a working OpenRC package.

No, see, this is where you start to go off the rails again.

One:  The technique I listed on that page works to enforce against
systemd intrusion _any_ packaged init + initscripts.  Debian's packaged
init with initscripts at present include:

o OpenRC (with, it's believed, any ancillary init)
o SysVInit
o Upstart

Two:  If all three of those dropped out of the current repo, they would
remain as available packages in the archive repo, and IIRC the
dependencies on most of them are so ridiculously modest and tiny that
they'd be unlikely to break over the foreseeable future.

Three:  Even if that were to happen, packaged init + initscripts debs 
would doubtless spontaneously become available in widely known
third-party repos -- as happens with a huge variety of other software
published by Debian users but not at the moment included in the official
repo collection.

Four:  Even if all of those things were to go away, thanks to the
debhelper package and others, making a local package is not exactly
brain surgery:  It's kind of an idiot's delight.  And then, someone
having done so might feel an inclination to share on that person's Web
space as a public repo, in which case see point three.


And this gets back to a larger theme:  Software packaging is great, and
only a fool abandons it, on a package-oriented distro, without considerable 
cause -- but in the end it's only a convenience.  We're Unix users;
there's no reason we should get pushed around by one or two idiot
distro package maintainers like the ones maintaining the lighttpd and
hplip packages.  (lightthpd mentioned below.)

I will get back to this point.


> It's too bad that WindowMaker shutdown applet depends on systemd. That
> would have been a nice touch. Me, I start X with startx, so I'm
> indifferent personally.

You might have overinterpreted:  wmshutdown is just a highly optional
Window Maker 'dock' (or 'wharf' or whatever they call the toolbar -- but
ISTR that 'wharf' is what Afterstep calls it, now that I think about it)
applet.  Shutdown or logout from the Window Maker context menu is
inherent / default in Window Maker, and in no way requires that crappy
little package.

The larger point (implication) of my 'Which Debian 8 Jessie Packages
Depend on Package Systemd' section is:  Don't be afraid of systemd 
dependency hairballs on Debian Jessie unless you're one of three 
types of person:

o  You're addicted to GNOME, in which case God help you.
o  You love NetworkManager (which has GNOME disease) for some reason,
   and are unwilling to use less baroque and problematic network 
   manager software.
o  You need hplip, and are unwilling to recompile it as a local package
   to lose the stupid, pointless policykit-1 -> systemd dependency.

Every other instance of 'Oh no!  I cannot avoid systemd' is some stupid
little piddly package that a Debian Developer brainlessly packaged
badly.

(On reflection, the lighthttpd case bugs me, too, because I really like
that HTTPd and sometimes need it in server computing.  Asshat packager.
Well, I guess either locally compiled package or move sideways to 
nginx, which has the same general merits and focus.)


> What happened in the Debian world in 2014 was about much more than
> systemd. If you read the back and forth, and I recommend you don't
> because there's better use of your time, the "Debian Devs" (DDs) stated
> quite clearly that they had no responsibility to provide support for
> any init except systemd.

I skimmed it.  (I lurk on debian-devel, and on rare occasions check the
Web archives of debian-user.  I observed the gradual stifling of critics 
including you.)

Here's the thing about the DDs.  They're overwhelmingly coders, not
sysadmins.  The problem about coders is that they think they understand 
software architecture, and they don't.  They think they understand 
system administration, but don't.  They think they understand project
management, but don't.

Historically, the people who most influenced Unix software system
architecture have been a distributed cabal of sysadmins.  In the recent
situation, a series of freak circumstances including the unhappy
accident of Debian being captive of a policy making GNOME its official
DE, and then the GNOME devs screwing the pooch on ConsoleKit getting
EOLed, freaking out, and decreeing that everyone will henceforth need
systemd-login instead because of their thrice-damned 'seat' API, 
stampeded the DDs into a software architecture fuck-up.

Preventing that fuck-up would have required to DDs to say 'Wait, we need
to reassess the whole GNOME commitment if their requirements are now 
so brittle that they're dictating init systems.'  That's what _should_
have happened.  But that would be sysadmin thinking, and they were
acting like coders, each stuck in his or her little world.

But that wasn't actually the main thing.  The main thing is what
happened next because of another coder trait:  Coders are lazy, resent 
anyone throwing more work on them, and especially resent anything dumped
on them that resembles the need to write documentation.  (Ordinarily, the
only way to get documentation out of a coder is threat of job
termination.)

And once the DDs made their software architecture fuck-up -- the one
where they allowed a bad decision by GNOME to cascade down and force 
a 'seat'-supporting login binary (systemd-logind) now required by the 
lightdm X Display Manager to dictate their distro policies and entire
global architecture -- all of the other misbehaviour followed.

When people said 'Why don't you commit to supporting more than one init
system?', all they heard was an ongoing commitment to write and maintain
multiple prototype service config files, i.e., what they see as
tantamount to writing documentation -- and coders will do anything to
avoid writing documentation.

So, they said no -- utterly predictably -- and when people kept giving
them a hard time on d-u for their hapless and obviously bad cascade of
decisions, the listadmins started throwing people off the mailing list.


None of this should have been a surprise.  All of it followed from the
original error of failing to revise a basic choice (GNOME being official
desktop) when GNOME presented them with an unacceptable dilemma.  That's 
what coders do, marching in lockstep over the cliff because each step
towards the cliff seems to solve their individual code problems and
impose the least short-term hassle.


And here is where I angle back towards the larger point.  The critics 
_ludicrously_ overstated the practical effect of the DDs saying 'no'
to 'Would you consider continuing to maintain SysVInit scripts?'
Let us consider the actual practical effect.

How many packages on a typical installed SysVInit-driven system require 
init scripts?  On my _very_ full-featured Internet server, /etc/rc3.d/ 
has 24 symlinks in it.  So, in round figures, typical Linux systems have
1-2 dozen installed packages where the question of init scripts are
relevant.

If those SysVinit scripts dropped out of the packages providing them, I
could maintain those in a heartbeat.  Heck, I could rewrite
semi-adequate if half-assed replacements for them all in an afternoon. 
So could anyone with -- not even competence at scripting, only ability
to look at other, similar scripts and ape them is enough.

Therefore:

> Out of the "goodness of their heart", they provided packages for
> Jessie OpenRC and Runit, but there's no promise, and in fact a
> disinclination felt by many DDs, to have the "hassle" of supporting
> multiple inits after Jessie.

Big fscking deal.  If I had to write needed SysVInit scripts myself,
it'd be really not significant work.  And if I _did_ do so, I'd first 
make them publically available as commented tarballs.  Later, I'd
realise that was half-assical, and go back and construct deb files
so they could be offered as part of an unofficial repo.

Unofficial repos are a thing, you see.  Local administration, and 
sharing of that local administration to others as scripts, packages in
unofficial repos, and, y'know Web pages like mine with shell recipes are
a thing.  Nobody running Debian has _ever_ been hostage to what the DDs
were and were not willing to do.  

Running Debian with an 'unsupported' init no longer packaged,
particularly a familiar one like SysVInit, is dead-easy.  You wouldn't
need to be an expert.  Moreover, you could leverage other people's 
having already worked out the steps via publicly available scripts,
packages in unofficial repos, Web pages like mine, etc. -- and thus 
avoid the need to do any work.  This is what the Internet is for -- and
the Internet is very much a thing.

The one thing _not_ needed for solving that problem is a distro fork.  

> THIS is why Devuan continues to exist: It's a guaranteed systemd-free
> distro. I'm pretty sure the only others are Funtoo and Void.

But, as I've shown, removing systemd and replacing it with one of the
five other official, currently available distro packages (SysVinit,
Upstart, OpenRC, runit, and dumb-init -- did I miss any others?)
requires only the world's most obvious two commands:  apt-get install
one init, apt-get remove the other.

Making sure that situation persists requires only a very obvious
appliation of package-pinning, which is the other four package commands.

Which brings me to another point:  I'm profoundly unimpressed by
contention over paths of least resistance.  All those years of screaming
and yelling were primarily over what would be the end-result of running
the Debian 8 Jessie installer, what would be the contents of a system
constructed by performing a 'forehead install' -- the one where you
repeatedly hit the spacebar with your forehead until installation
completes.  The path of least resistance.

As I imply on my Web page, you _aren't done_ when the distro installer
completes.  And frankly, you shouldn't have foreheaded your way through
the installer, either -- because it's your system, and you should take
an active part in deciding how it gets built and what's on it.

It's _always_ been the case that you're not done when your distro
installer completes.  It's mostly the Ubuntu kiddies who've created a 
popular misconception to the contrary among newly arriving technophobes.
If we Unix people had been devoted to the path of least resistance, we 
_wouldn't have become Unix people_.  We'd still be eating what Microsoft
Corporation fed us.

What you said, above, is the worst possible reason for Devuan's
existence.  More reasonable ones include the vdev effort and other
similar things including a functional replacement for ConsoleKit I see
they're creating.  (I didn't write down the name, because I don't give a
damn about GNOME.)  But even all of those worthwhile things could have
been created with less human cost, time spent, and work required
_without_ forking the entire distribution.  Just create packages, and
either get them into the official repos, or make them equivalently
available in third-party repos.

But fork the distro?  Just over an integrated init package versus 
a different one?  That's taking exaggerated drama to extremes, and IMO 
a waste of time and effort.  (It is, of course, not my time and effort
to waste, and totally their call.)

Anyway, we're Unix people.  We're just not about the path of least
resistance.  Never have been, never will be.  'This is Unix.  Stop 
acting so helpless.' -- D.J. Bernstein.

The people who say they need to fork a distribution just over an init
package don't speak for me.  That's frankly ridiculous.



> Those weren't Unix operations: They were package manager specific
> operations, which IMHO might be simple but are anything but obvious,
> and might change over time as systemd subsumes more of the system and
> more software depends on it.

The package manager is the very first and most important tool in your
distro you should learn (if it has one).  So, the first two of those
four commands were mind-bogglingly obvious.

Nobody thought of trying that?  For shame.

I can think of one reason to not try, and a reason why such thinking is
obsolete because it's 2016.  Many of us have a conditioned fear of
blowing up systems -- and playing with core init files, like playing
with the kernel or bootloader, strikes dread into people because they
envision an entire system getting broken by a single unwise operation.

However, the reason that's obsolete thinking in 2016 is that we have
virtual machines, now.  VirtualBox is an idiot's delight to install and
use, for example, and also zero-cost.  

The moment I remembered I had VirtualBox on my MacBook Air, the idea of
a test platform was obvious.  I did (IIRC) an LXDE installation of
Debian Jessie, ripped the DE out and put Window Maker in, and at that
point I _could_ have checkpointed the VM so further changes could be
trivially reverted.  Instead, because I had great confidence in what I
was about to attempt (and read about other people already having done
it), I carried out the steps listed in my Web page -- and of course they
worked great.

It being 2016 and we can all have VMs, there is no longer any excuse for 
not experimenting because you're afraid of blowing up the OS.  Just
checkpoint what you have, and try anything at all.  If oops, then just
revert and you lose nothing except 2 minutes.  Simple, always works.


> Devuan, Funtoo and Void have gone on record as no systemd, now or in
> the future. This is a whole 'nother level of init choice (via removal
> of the software most preventing init choice) than simply providing
> alternate init packages for now.

As I mentioned, the _first obligation_ when you're new to a distribution
is to learn its package tool (and surrounding architecture).  When
you're on Debian or any other .deb-based distribution, want to know one
of the things you find when you do that?  Equivs.  

Oh, you never bothered to study the apt-get / dpkg / deb design long
enough to run across equivs?  What a shame.  Here, read this by my
friend Akkana Peck:
http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html

THe 'equivs' system means, among other uses, that a bullshit alleged
dependency can be finessed with trivial effort.  Take, for exampple, the
aformentioned lightttpd and hplip packages in Debian Jessie.  It is
_highly_ unlikely that either one of them _actually_ requires policykit-1
or any other package that drags in systemd.  Very likely, both were
merely declared to have those dependencies in the packager's metadata, 
and use those facilities if present but don't actually need them in any
way.  So, if I guess right, they're essentially false dependencies.

This is Unix.  Stop acting helpless.  All you have to do is use equivs
to declare 'Oh, yeah.  That package is installed.'  Even though the
package isn't.  apt-get is now happy, and the bogus dependency requires
no further action.

This is Unix.  Stop acting helpless.

Anyway, I appreciate this discussion, because it's helped clarify my
thinking _and_ also pointed out a number of fixes required for the new
Web page.  For example, the page purports to start with a recipe to
convert Debian 8 Jessie to OpenRC, expunging systemd.  However, that is
a distortion:  The page actually starts with a recipe usable to convert
to _any_ packaged init + initscripts system in Debian -- to SysVinit, to
Upstart, to runit.  (dumb-init would work but is really only functional
enough to run Docker containers.)

Accordingly, some footnotes and possibly some rewrites are required.
I'll sleep on it, and consider the matter.  Meanwhile, feel welcome to
mention it if you have occasion to.

And thanks again, really.


----- End forwarded message -----