Troubleshooters.Com®, Linux Library
and Steve Litt's Systemd Subsite Present:

Participating in the Debate

Copyright © 2014 by Steve Litt

Anybody, posting any opinion, anywhere, about systemd, will inevitably draw hostility. That's the nature of the situation. Your job, as a person wanting to eliminate or minimize systemd from your computer, is to phrase your responses succinctly and logically, regardless of the illogic or hostility displayed by others.

One more thing: Before reading this document, you should familiarize yourself with the real meaning of the following logical fallacies:

CONTENTS:

Systemd boots faster.

That may be true, but the benefit doesn't come close to offsetting the costs. If they ask about the costs, or say the costs are minor, they've opened the door for your list of systemd problems.

Counting lines of init scripts, sysvinit is just as bloated.

First, this depends on how many init scripts you have. Second, the main problems with bloat are footprint and complexity. A shellscript leaves behind no footprint once it has terminated, except for any background processes it started (like the daemon itself).

As far as complexity, a shellscript is much more transparent than an equal number of lines of C. You don't need a debugger to troubleshoot it, you don't need to recompile it.

Sysvinit is a twenty year old monstrosity.

Yes it is. And this argument is a false choice ignoring many alternatives. There have been, since before the conception of systemd, other existing init systems that are newer and less problematic than sysvinit. In fact, many consider systemd worse than sysvinit because its promiscuous interactions leading to feedback loops, and its number of package dependencies.

One other thing: Portraying the postponement of a decision as "choosing sysvinit" is a straw man argument, because delaying simply means waiting for something better than either systemd or sysvinit.

Upstart has license problems.

Another false choice fallacy. There are other existing init systems without license baggage. And unlike systemd, several of those init systems have substantially fewer interactions and dependencies.

We need something better RIGHT NOW!

Not supported by the facts. Pre-systemd, the Linux community continued using sysvinit, with at least a modicum of satisfaction, in spite of init/PID alternatives such as upstart, perp, runit.

I'm tired of hearing it.

An ad nausium fallicy. The fact that the poster is (probably legitimately) tired of hearing it doesn't make what you're saying false.

You can't blame the guy for being tired of hearing about it. But systemd represents a complete change in direction for Linux. It's important. It's worth enough debate to give some people listener fatigue.

Post this to offtopic

Offtopic lists of technical groups is where they discuss firearms, cars, and critiques of President Obama. This is clearly not the place to discuss something in the process of changing the very nature of Linux.

You're spamming the list.

This is an ad hominem fallacy and a false definition. Look up the definition of spam. You're not selling male enhancement products or expiring drug store bonus points.

If you don't like it, change distros

This is a Hobson's Choice (take it or leave it). Unless you're using *too, Slackware, or *BSD, you enjoy using a Linux with a binary package manager with dependency tracking, and a reasonably easy install. To my knowledge, every Linux distro like the one just described has, or has committed to, or will commit to systemd, or will commit to systemd if Debian commits to it. Nothing in this "take it or leave it" argument invalidates your assertions about systemd.

If you don't like it, make your own

Red herring. Perhaps one in a thousand people is capable of, and has the time to, make their own distro. I personally know only two who have. The fact that you can't make your own distro in no way invalidates your assertions about systemd.

Be thankful the developers gave you this for free

Grateful to the developers who brought us Linux? Of course! Grateful to the developers voting and working to incorporate systemd into Linux, and do it in such a way that it's incredibly hard to pull back out? Not so much.

Some of these "thank the developers" messages go on to imply that the developers are contributing, but the people asking for the removal of systemd aren't. The fact is, most of us have contributed. The success of Linux on the server, and to a lesser extent on the laptop, was cemented by dedicated people before Lennart Poettering started working on free software projects. The people from the 1990's and early 2000's endured taunts and hardships, both personal and professional, to push Linux to the top. They were the guys who ran Linux when running Linux was hard.

Why blame Debian?

Tragically, they're absolutely on the mark with this assertion (phrased as a question). Red Hat pays the "systemd cabal" to produce a hard to repair Linux. Upstreams create those systemd dependencies. So who gets all the flack on their user mailing list? Debian!

But, unfortunately for Debian, their past fine works have thrust them into the position of being the last clear chance to avoid systemd. If Debian goes systemd, so does every Debian variant: Ubuntu, Mint, Crunchbang, Zorin and the like. If that happens, the only alternatives are compile-every-upgrade distros, Slackware, and *BSD, which supports less programs than Linux.

It's absolutely unfair to the Debian project, and for them it must seem like no good deed goes unpunished. It's an ugly situation, but, unfortunately, right now a necessary one.

Init system x isn't ready for prime time!

This is an opinion without a definition. Just reply that in your opinion, system x is ready for prime time.

You're a conspiracy theorist.

A simple ad hominem attack that says nothing about the truth or falsehood of your assertion, other than the opinion of the accuser. Red Hat, Lennart Poettering and his "systemd cabal" have already demonstrated the means and opportunity to produce a Linux with more promiscuous module interfaces and less parts interchangability.

As far as motive, it's plausible that Red Hat, with their training, support and consulting profit centers, profits from a Linux that's harder to repair and harder to configure for unanticipated use cases. It's plausible that Lennart Poettering gained fame and name recognition by heading up a project that lots of people hated.

Were these their true motives? Except for the mind readers among us and people attending the highest level planning meetings at Red Hat, nobody knows for sure. Yes or no, it's an opinion.

But believing those plausible motives doesn't make you a conspiracy theorist any more than believing they have no truth whatsoever makes you an ostrich with his head in the sand.

It's a matter of opinion: No more, no less.

Systemd is powerful.

PID1 isn't supposed to be powerful: It's supposed to handle some signals, start (with auto restart) a few processes, and get out of the way.

Systemd is modular.

Implicit in this argument is the definition of "modular"; a word with different definitions for different people. Therefore, this is a bad argument to have.

I prefer to say systemd is has too many interactions, and excessive package dependencies. As far as the word "modular, the way I make the call is to ask which of the following two topology extremes the system in question resembles:

Back to the "modularity" debate. Before having this debate, the word must be defined. I define it as a spectrum, with the ends defined by the following two diagrams:

Non-modularity Non-modularity

Both drawings have sixteen small circles (modules), but the difference couldn't be more striking. The first drawing shows all sixteen modules interfacing with all the others. If the number of leaf modules is N, then the number of interactions is (N2+N)/2. System complexity is proportional to the square of the number of leaf modules. The second drawing has four modules, each containing four submodules (leaf modules). Its complexity is proportional to the number of leaf modules (N). Until there's somebody able to draw me a block diagram of systemd, including interaction lines, proving otherwise, my belief is that systemd more closely resembles the non-modular drawing. If it more closely resembled the modular drawing, somebody would have diagrammed it, complete with interaction lines.

When troubleshooting the modular system, you first bisect the system to find narrow the root cause, and once narrowed to the major module, and then do the same inside that module. You keep drilling down until the root cause becomes obvious.

When troubleshooting the non-modular system, you have feedback loops all over the place, so divide and conquer is difficult. In fact, absent the ability to test the parts in isolation, you could go days without finding the root cause.

Debating Lennart Poettering

If you ever find yourself debating Lennart Poettering, be sure you know beforehand about his "debating style", which is knowable as a result of the Internet. Poettering's clever, but once you understand his debating style, you'll be much more able to control the debate.

Observe several timestamps from the video of his interaction with a presenter at a conference:

Now read over this read this email reply from Lennart Poettering. See if you can find patterns.

Basically, he alternates sarcastic, and admit it, funny ad hominems, with long series of facts about the software universe he and Opendesktop have designed, stated as if they're true of all designs. In other words, these facts are both false choices and red herrings.

Be vigilant when debating Poettering. He's quick and he's clever. Here's some reading material:

[ Training | Troubleshooters.Com | Email Steve Litt ]