[TriLUG] Why the hate/dislike for systemd?

[Steve Litt via TriLUG]

On Thu, 16 Jul 2015 08:58:38 -0400
Lee Fickenscher via TriLUG <trilug at trilug.org> wrote:

> The "Recommendations for a systemd-less Linux distribution
> <http://www.trilug.org/pipermail/trilug/Week-of-Mon-20150713/074201.html>"
> thread has me wondering why people don't like systemd. I'm not trying
> to bash anyone in that thread or attack anyone for their stance. This
> is purely for my own edification.

Once up on a time I was an Audio Repair Technician. I noticed that some
units were built for repairability, and some weren't. 


Group A) The ones built for repairability were assembled from major
components connectable by a couple disconnectable wires and a screw or
two. Each of those major components was similarly assembled using minor
components easily disconnected and replaced/simulated. Easy to
understand, easy to repair, and if you wanted to modify them, it
wasn't difficult.

Group B) Then there were the irreparable units. Best way I can describe
those units is it seemed like they started with a tiny inner core, and
screwed (usually with lots of screws) layer upon layer of other stuff
around it. The newly screwed stuff covered screws and connections, so it
was difficult or impossible to to put a voltmeter probe on needed
testpoints without disassembling, and disassembling interferes with the
cause/effect value of measurements and strongarms. And meanwhile,
components of these units typically interfaced with several different
components, perhaps needlessly, and used *a lot* of wires to do so.
These took forever to repair, requiring special toolsets. Modifying
them would have been an exercise in trial and error.

Software also falls into catagories Group A and Group B. For the
longest time, most of Linux (and Unix) was group A. Then came KDE and
others. And now the king of group B's, systemd. It so thoroughly covers
in epoxy the Linux beneath it that it must give you your own set of
diagnostic/modification tools like systemctl, journalctl, etc. But if
there's something wrong with systemd itself or the Linux that's under
the systemd epoxy, you're basically helpless. That oldest of tricks,
init=/bin/bash on the kernel line to periscope up and see what's going
on, fails in systemd-laden Ubuntu 15.04 because you pop up in an
initramfs busybox or something similar, and switch_root fails because
it can't deal with ext4. That's just crazy.

To summarize my preceding four paragraphs: systemd's architecture is
just plain disfunctional, and no matter how much Red Hat pays its
developers to fix problems brought on by that architecture, sooner or
later it will cause major problems for users.


> 
> I read/skimmed http://without-systemd.org/wiki/index.php/Main_Page
> but that came off like a lot of rhetoric and FUD and seemed to have
> little substance that I could find.

Only thing bordering on rhetoric and fud I could find on that web page
was the "Arguments against Systemd" link. The rest was just cookbook
recipes on how to extricate systemd from your computer and lay down an
alt-init, or where to find a sans-systemd distro.

Disclaimer: I'm the author of the "Manjaro Experiments" link on that
page, so I *do* have a dog in the fight.


> I've seen arguments that it isn't *nix-like but that seems incorrect
> as systemd appears to be more of a framework of separate executables
> than a single monolithic application. IMHO, that fits well into the
> toolbox-mentality.

Yes. Lennart Poettering makes that point. Let's go back to the audio
analogy. Group A has easily disconnectable parts that are easily
replaceable with identical parts or upgrade parts. Group A has very
simple interfaces between the parts.

Group B has parts gratuitously linked to each other with complex
interfaces, such that it's difficult to study part of the system in the
absense of another part, and hard to plug in an "adapter" to see what
input a component's getting, or to strongarm a known output.

Yes, systemd is made up of parts, but they're tightly welded with
complex interfaces, they're Group B, and that makes them hard to
troubleshoot, and hard to design. And if something's hard to design,
bugs are more likely to creep through.


> 
> Concerns about stability were mentioned, but I'm running systems that
> use systemd that are rock-solid, so that would imply to me that it
> isn't specifically a systemd issue.

A lot of the stability issues might be edge cases, or cases where
people wrote unit scripts wrong. The systemd-laden distros I've run
(and I did very little modification of the default system, my mama
didn't raise no fool) were likewise stable.


> 
> Some other comments/concerns seemed to be a rally cry against change,
> which seems ironic in the computer field.

You want change, try these on for size:

* s6
* runit
* Epoch
* Suckless Init plus daemontools-encore plus LittKit

Not all change is good, not all change is bad. Of all the changes we
could have made, systemd is in my opinion the worst. In my opinion
systemd is worse than the obvious antiquated sysvinit, but that doesn't
mean we shouldn't change to a better init. Systemd isn't better.

It's not about newer or older: It's about better or worse.


> 
> Does anyone have any concrete reasons why systemd is bad? 

I have three:

1) Architecture
2) Architecture
3) Architecture

SteveT

Steve Litt 
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21