[ale] Systemd rants (was bow head)

[Steve Litt]

On Fri, 08 Sep 2017 07:58:13 -0400
Jim Kinney <jim.kinney at gmail.com> wrote:

> UNIX is dead. 

Not unless somehow you can say BSD isn't Linux.

> Linux isn't UNIX. It's only UNIX-like.
> 
> Emacs violates those rules. An editor that can read your email out
> loud is rather crossing domains.
> 
> Apache violates those rules. The proxy capabilities are beyond it's
> initial web server domain.

This is a new fallacy I haven't seen used by systemd defenders before:
Argumentum ad populum. Emacs does it, Apache does it, so it must be the
right way. https://en.wikipedia.org/wiki/Argumentum_ad_populum



> But at least systemd provides a topic other than vi vs emacs to
> squabble over. That was getting old.

Systemd vs sane inits is nothing like vi vs emacs. You can switch
between them any time you want (unless you're using very esoteric
capabilities or addons). But systemd manages to get its tenticles into
every last bit of the software ecosphere, making replacing it a
gruesome task of finding and pulling out all those tenticles, before
finally rebuilding the whole system in a sane way.

> Besides, systemd follows most of the rules that were listed about as
> well as any other PID 1 process responsible for a current system
> startup.

Where'd you pull that statement out of?

If your statement is true then why is it so darn hard to replace
systemd's (kidnapped) udev with another device whateverer, if systemd's
software is simple, with simple parts and clean interfaces? It should
be trivial to bold on a similarly working device whateverer.

Try initting with s6, runit or Epoch and come back to me and tell me
systemd follows most of the rules as well as other init systems.

Here's how simple runit is: I built my own imitation of runit from the
83 line of C Suckless Init program, the daemontools-encore supervisor
suite, and a few shellscripts I wrote (called LittKit) that impose
startup order. 

As far as daemontools-encore, it's very simple: Loop
through the /service (or /var/service or whatever) directory looking
for symlinks to other directories, and if they're not running and
should be running, run the script called "run" in those directories,
and that script sets up environment etc and then just execs the daemon.
State is kept in that directory's ./supervise subdirectory.

Runit, (and my Suckless Init/daemontools-encore/LittKit combo) conform
to the rules. Systemd: Not so much.

SteveT

Steve Litt
September 2017 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr