[colug-432] systemd dislike

[Rick Troth]

I propose that it will be more effective long term to focus on what's
good about SysV INIT (or other INIT schemes). This will naturally touch
on things that "we" dislike about SystemD. But if we keep our compass
stayed on "I like thus-and-so" we may actually be able to retain what
remains of thus-and-so. See below.

Try to be practical. If all your thus-and-sos really don't matter, then
join the SystemD crowd and move on.
Otherwise,
be bold! If your thus-and-sos DO matter, then talk about them ... shout
loudly and and preach broadly.

Historically, Solaris, HP-UX, and others (including AIX) used the AT&T
branch of INIT driven by /etc/inittab. Few people wanted to mess with
/etc/inittab. Maybe it was because the syntax is akin to that of
/etc/passwd. (Only certain kinds of doctors really *want* to look at
that many colons on a regular basis.) HP-UX and Solaris and others
adopted an improved method, without breaking /etc/inittab, where scripts
could start and stop services at each run-level. Some Linux distros went
this route. (I never got my head completely wrapped around pre-Upstart
Ubuntu/Debian, nor the BSDs for that matter.) HP-UX went so far as to
support a per-service message, yet without breaking when an HP-UX
"message capable" INIT script is used on Solaris or (eventually) Linux.

I found that I was able to hack FreeBSD to drive SysV INIT scripts. Easy
peazy.

What appealed to me about Linux from the earliest days was that it
provides an unencumbered Unix system, borrowing "the best" from either
AT&T or from Berzerkeley (Left Coast). I like Unix, leaning slightly to
the right (East Coast, so to speak). Mostly, I hate being painted into a
corner, and with "Unix" I can move a program or workload (or my desktop)
from one system to another, pursuing that fit-for-purpose goal. Fond as
I am of Linux, I've never (ever!) suggested that it would be the basket
to hold all my eggs.

Here's my current thus-and-so list, what I like about SysV INIT:

 + Interoperability (among other Unix and Unix-like systems)
 + Non-Breakage (of older /etc/inittab which don't have the break-out
scripts, e.g., AIX)
 + "the Unix way" because INIT does one thing and does it well*
 + Simplicity, in that the scripts can stand on their own**
 + Speed, in that some of us did not experience the delays SystemD
allegedly relieves***
 + Ease of implementation (I know at least one guy who wrote his own set
of INIT scripts ... from scratch)

Anyone have more bullet points they could add? Please do!

* For varying values of "well", since obviously a great number of people
were dissatisfied with SysV INIT. Never the less, SysV INIT is clearly
more attuned to the "do one thing" method than SystemD.

This "do one thing and do it well" mantra has been mentioned many times
already by prominent software luminaries. The assimilation of other
functions into SystemD is probably its most damning feature. It seems
that resistance is futile.

** What little I have been able to comprehend of SystemD takes me to
several directories. (And that's just for the INIT function.)

*** I actually experience more delays, and longer delays since my
distros of choice went with SystemD. Not a scientific sample, but does
lead one man to ask, "why did we do this?". In any case, a well written
SysV INIT script does not inherently mean delays. Most of them simply
fork the associated daemon and return.

There *are* Linux distributions which eschew SystemD. Not sure what the
current story is in Debian land. (Mostly due to lack of time, not that I
don't care.) There was certainly a great hue and cry in that world, Jim.
Debian may be pressed by decisions made by Canonical. And I know of at
least one large company in-house Debian spin which fell to SystemD.

There are other battles. I'm keeping silent about a big one (now several
years older than SystemD) for now.

For what it's worth, I'm in the middle of a discussion with the
Coreutils team over their recent dis-use of /etc/mtab in favor of
/proc/self/mountinfo. The latter has more detailed info than
/proc/mounts. Both /proc/mounts and /proc/self/mountinfo still do not
provide what I enjoyed from /etc/mtab. I'm hoping they'll just make it a
compile-time option. But they put some work into their
/proc/self/mountinfo parsing so they seem to be a little sensitive about
it. (I can relate!)

When most distros started making /etc/mtab a sym-link to /proc/mounts,
the remedy was trivial, so I didn't complain. Whatever "mtab hate" there
was in the community has evidently continued, not satisfied with
/proc/mounts.

Twice over the past year or three, I was surprised by dislike which I
did not share:

Git is terribly unpopular with long time users of Subversion, CVS, and
others. Some of it may be learning curve or muscle memory. But I've seen
arguments stated from (what reads like) practical and objective
objection. (For me, the worst thing about Git is building the cussed
thing, where CVS and SVN are "standard recipe".)

Recently at COLUG, someone mentioned LibreSSL and a number of staunch
OpenSSL aficionados booed the former quite vocally. I use the newcomer
when I can, but follow updates in both camps very closely. (Call me
paranoid. But am I paranoid enough?)

-- R; <><