Re: My next computer and its support

On Mon, 21 Nov 2016 07:47:59 -0800
[email protected] wrote:

>         And the next version of it, RHEL 7, will use systemd instead
> of init.
> 
>               I know almost nothing about systemd except that using
> it will mean I will have to learn a lot of new stuff and that one of
>               its authors is the author of the RHEL 6 sound system,
> which has given me endless grief. For those two reasons, I would like,
>               all other things being equal, to avoid it.

I'll answer your other questions in another email: This one is confined
to systemd.

Systemd is an architectural joke, with massive dependencies
entangling many disparate regions of the software on a "Linux
Computer". This entanglement ruins Linux's former quality of
interchangeability of parts. If you want a machine you control and
specialize to your taste, systemd is to be avoided at all costs.

A computer's Init system is (or was) simply Process ID 1, which zapped
zombies while keeping its eye out for the reboot signal, plus a system
to start up (and often supervise) background programs (commonly called
daemons). That's it. Nothing else. The Init system is (except systemd) a
tiny, well defined, encapsulated part of the OS. Most init systems can
easily be swapped out for other (non-systemd) init systems: Not only as
a gift from the distro's package manager, but via ./configure;make;make
config. When the default init system is systemd, only a package manager
bestowed alternate init can be done without tons of teardown and
remodeling.

Now, in 2016, certain software makers insert systemd dependencies such
that you can't run their software without systemd. For instance, you
can't run Gnome without running systemd. Your graphical user interface
actually cares about the computer's first couple actions after booting,
instead of simply riding on top of the system as an add-on. This is why
those in the know are dumping Gnome and going with encapsulated user
interfaces like LXDE/LXQt. Some people take "the offer you can't
refuse," but others opt for freedom, even if inconvenient.

On systemd afflicted systems, systemd has taken over the logging
system. I've heard it has or soon will take over networking. The
systemd crew is now the development crew of udev, and how long they
graciously allow udev to be used in the absence of systemd is anybody's
guess. I was no fan of mknod, but if the choice write massive scripts
using mknod or worship at the alter of systemd, I'll be a mknod guy.

One systemd selling point is parallel execution. Which implies random
order. When something goes wrong, imagine troubleshooting something
with intermittence built into its very core: Its "operating as
designed" state is intermittence. It's true that lots of init systems
bestow parallel execution, but they are more granular and reliable and
easier to troubleshoot. And if you're really a fan of completely
determinate startups, both sysvinit and the Epoch init system give you
that.

SYSTEMD PROPAGANDA
==================

Here are a few propaganda pieces you'll be hearing when you discuss
whether you want systemd on your computer...


"Init" was 32 years old and needed replacement
----------------------------------------------

First, by "Init" they mean the sysvinit init system, and that's true,
it's 32 years old, and by 2016 standards it's usable but has plenty of
room for improvement. What the propagandist conveniently left out are A)
the systemd cure is worse than the sysvinit disease, and B) There are
many fine init systems out there miles better than either sysvinit or
systemd. These include runit, s6 (with s6-rc), Epoch, OpenRC,
busybox-init, and several others. By calling sysvinit the generic term
"Init", the propagandists hope users won't notice the many great init
systems out there.


Systemd is more efficient
-------------------------

In what circumstances? With respect to what? Turns out most of that
efficiency is at boot time. But how many care whether the computer
boots in 1 second (I've gotten a simple Manjaro systemd system to boot
grub to gui in about 2 seconds), or 10 seconds (almost any sane init
system boots grub to gui in 8-16 seconds). And keep in mind most systemd
installations take 8-20 seconds Grub to GUI, and like any other init
system, when things go wrong, systemd boot can be upwards of a minute.

By the way, Alpine Linux, which Docker has chosen as its preferred
platform because of lightning fast boot and performance, inits with
OpenRC.

When confronted with non-sysvinit alternatives, systemd
propagandists whine about the extra processes run by
daemontools-inspired inits like runit, s6, perp, nosh, and Suckless
Init plus daemontools. Yeah, daemontools runs one tiny supervisor
process for each "daemon", so if you were spawning 500 different daemon
programs this might start to be a problem. I'm not talking about a
daemon that spawns client socket processes for each connection: Those
sockets are controlled by the main process and listener socket, and the
daemontools-inspired init system doesn't mess with them.

Speaking of daemons that spawn processes...


Only systemd has Socket Activation
----------------------------------

Taking a cue from the car companies, systemd propagandists take an old
idea that already has a useful implementation, make up a new feature
to reimplement that old idea, and givesit a catchy name, Socket
Activation. And now the systemd sheeple proclaim that runit lacks
Socket Activation. True enough, but if, with computers of 2016, you
still want to save tiny resources by waiting for user requests before
starting up a daemon, well, you can still use xinetd. The sheeple wring
their hands "but that's not a part of the init system!" And you say,
"Precisely!"


Systemd doesn't use those huge init scripts
-------------------------------------------

Neither do Epoch, s6, or runit. Epoch has declarative daemon
specification, similar to systemd's unit files. s6 and runit run
scripts, the equivalent to sysvinit/OpenRC init scripts, average less
than ten lines.


No biggy, you can install a different init system on Debian
-----------------------------------------------------------

Yeah. Right now. Debian still has a package-manager-foo recipe by which
you can swap OpenRC for systemd. But they can remove that purposely
or out of neglect any time. During the 2014 init system discussions, the
Debian Developers showed no sign of respecting Debian Users wanting
alternative init systems. So I'm not optimistic about Debian OpenRC
long term survival.

When Debian decides it's too much trouble to deliver OpenRC via
package-manager-foo, the only alternative is ./config;make;make
install. I've done this for s6, runit and Epoch. It works great for
replacing most init systems. But Debian has intertwingled systemd
roots and flowers all through their OS, making replacement, or even
parallel installation, extremely difficult. I know: I managed to get
Centos initting via runit in early 2015, and it was like pulling teeth.

So if you think Debian will continue offering this option, by all means
use Debian. But if you agree with me that Debian's past behavior makes
it likely they'll drop this option, either out of neglect or malice,
then switch.


You're just scared of change (graybeard)
----------------------------------------

How old must one be to realize that new doesn't necessarily imply good,
nor does old necessarily imply bad? How young must one be to close
their eyes to the obvious Rube Goldberg, April Fools Joke architecture
of systemd?

They say you're too lazy to learn a brand new set of software to admin
your computer. With new programming languages and paradigms coming of
age almost daily, I pick and choose what I learn, and I demand a payoff
for my learning: Either financial or business or just personal
fulfillment. A Rube Goldberg architected Linux eater with a
moving-target architecture and no real scope statement doesn't have the
payoff I need. Now if I were a Red Hat Certified whatever, that would
be different. But all I need to admin is Troubleshooters.Com's
computers, and they work just fine without systemd.


Resistance is futile, you will be assimilated
---------------------------------------------

Propagandists lacking the tech chops to give a technical excuse for
systemd assume the pose of the realist: All the major distros have
switched: You have no choice!

First, there are only three major distros: Debian, Redhat, and Ubuntu.
If one restricts ones self to those three, the propagandists are right.
But plenty of distros and OSes are doing an excellent job in resisting
the assimilation into the Rube Goldberg architecture.

If you want Debian without systemd, choose Devuan. Plenty of people are
using it for production work. If you want a light, tight, always works
rolling release distro, Void Linux is what you want. Want "just the
facts" Linux, whose internals are visible to inspection like the organs
in a "visible man" doll: A distro whose package manager doesn't even
calculate dependencies? Then Slackware's the way to go. Gentoo offers
both systemd and OpenRC, and Funtoo is OpenRC with a commitment never to
install systemd. Or install the OpenRC initted, incredibly efficient
Alpine Linux, the favorite of the Docker crew. FreeBSD has no systemd,
but it sure hosts a lot of the applications we need, it's good and
solid, and it has a working Virtual Machine system for those few apps
it just won't run.


BOTTOM LINE
===========

It's the architecture. It's the gratuitous interconnections and
dependencies. It's the promiscuous communication between entities having
no legitimate need to know each others' businesses. The real problem
with systemd is the architecture. Systemd is like that epoxy they used
to surround electronic circuits, to make those circuits a black box,
so you couldn't replace just one transistor or IC. All the rest of the
systemd discussion is just annoyance and propaganda. 

SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz