
Systemd: The Biggest Fallacies - zdw
http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html
======
uselessdguy
First of all, thanks for linking to uselessd.

The writeup was quite nice. I was actually in the process of writing my own
notes to respond to Poettering's "The Biggest Myths", but your approach is
better. I'll definitely use it as a reference to link to in discussions.

That said, I have a little caveat for #9. Though systemd violating KISS is
virtually undeniable, you should reword it so as to point it out on systemd's
own merits, not in relation to sysvinit, which systemd explicitly intends to
be more complex than.

~~~
pessimizer
I have absolutely no idea why this comment has been voted to the bottom of the
page. Friendly, innocuous, and thoughtful.

~~~
digi_owl
The systemd promotion brigade has invaded hacker news.

------
dnr
He's missing the point about socket activation. The problem it solves is
different: if you have daemon B that depends on daemon A, you want to express
that dependency in the init system, so that it starts A before B. But just
starting process A isn't enough to ensure that A is actually listening on the
socket that B wants to connect to, since it takes some time to load the binary
and do initialization. There's a race condition there, where B can try to
connect before A binds to the socket. To fix the race, the init system needs
to either monitor for the availability of the socket, or do it systemd-style
where it opens the socket itself.

~~~
jerf
As a bit of a disinterested observer (I'm mostly in the "just make it work"
camp), I can't help but feel that if you pile up the problems that systemd
seems to solve on one side, and pile up the enormous piles of code that are
apparently necessary to solve the problem on the other, that systemd does not
come out looking too good.

(Writing this in C was probably a silly idea.)

~~~
mhogomchungu
what language do you think systemd should have been written in?

------
sciurus
Some of these are arguments I'm glad to see getting more attention, such as
Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic".

Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce
complexity". No, I don't want the least complex init system init system
possible. I think it's obvious to people who have written both system v init
scripts and systemd or upstart configurations that the latter are dramatic
improvements. The chance that I will write a buggy init script is,
unfortunately, high. The chance that I will need to debug systemd when writing
a unit file is very low.

~~~
imanaccount247
>I think it's obvious to people who have written both system v init scripts
and systemd or upstart configurations that the latter are dramatic
improvements

Except that is a false dilemma, which he points out. Sysv init takes more work
because nobody has bothered to fix it. You don't need a massive complex set of
software like systemd to make this easy, see the BSDs init scripts like he
suggests.

~~~
TheCondor
That doesn't really invalidate the argument. Upstart and systemd units are
dramatically easier and less bug prone than the existing sysv alternative. If
it was nontrivial to fix they would have.

The missing beef here is actual bugs and problems with systemd. Post some zero
days... Nobody challenges that businesses with paying customers all
indepdently came up with the need for smf, launchd, upstart, and systemd. Are
they just adding shit to add it or do the see value and need?

~~~
imanaccount247
> If it was nontrivial to fix they would have.

There is no basis for that assertion. It is trivial to fix, again, see BSDs.
Just because nobody bothers (or people bother and their effort is rejected due
to politics) doesn't mean it is nontrivial.

------
RickHull
There is a lot to digest, but so far this this looks like an excellent example
of critical thinking, regardless of one's feelings or intuition regarding
systemd. Both proponents and detractors have much to be thankful for in this
article.

------
jojo3000
Some of his arguments look a little bit botched.

For example: > Fallacy #1: "Systemd is multiple binaries, therefore it is not
monolithic"

Well following Wikipedia
([http://en.wikipedia.org/wiki/Monolithic_application](http://en.wikipedia.org/wiki/Monolithic_application))
means either a non-modular application, or a self-contained application. In
this sense either his counter-argument is simply wrong, or the examples list
he gives at the and is wrong.

> Fallacy #4.1: "Unit files reduce complexity"

Here he compares the ca. 275.000 LoC of systemd with the 10.000 LoC of shell
scripts used as initscripts on Debian. Lets ignore that the 275.000 LoC
contains much more than the unit management in the systemd daemon. But why are
the bugs always in the scripts and never in the shell as he claims? And sorry,
I don't take his word that C is always more error prone than the shell. This
is true when the shell is used for its intended purpose: to start commands,
pipe btw them and having a little bit of flow control. For everything else you
surely want to have a general purpose language.

> Fallacy #7: "Systemd gives you socket activation!"

Well, according to boot charts, socket activation is not only a marketing
gimmick.

EDIT: Add Fallacy 7

~~~
lobster_johnson
I think we need a separate term for "internal modularity" (Linux, Systemd) and
"external modularity" (Unix, the Internet).

The former depends on internal interfaces, where individual modules help
separating concerns but can't be swapped out or reused in other contexts,
whereas the latter relies on formal interfaces, allow components to be
swapped, and promote reusability. (Also, the former can be monolithic or not,
but the latter can never be monolithic.)

"Unixy" is sometimes used, but it's not a great term.

------
jmount
"shell scripts are not inherently buggy" not the week to argue that point.

~~~
felixgallo
It's not shell scripts, it's /bin/bash -- the guy fieri of shells.

~~~
astine
Which also happens to be the default or expected shell in the majority of sysv
installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh'
So it's another example of a distinction without a difference to single out
bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

~~~
bronson
Debian and its many derivatives (including Ubunutu) use Dash, and the BSDs
tend to use some form of Ash. I don't have the statistics but, if it's true
that a majority of distros still use Bash for noninteractive use, it's a tiny
majority.

~~~
astine
Well, a lot of them then... I know that Arch and Gentoo at least use Bash and
I'd be surprised if they were the only ones.

~~~
profsnuggles
Arch is using systemd and openrc comitted to using POSIX sh in their init
scripts some time ago. So you can use dash or whatever posix compatible shell
you want with it.

------
vinkelhake
> Fallacy #2: "Lots of people use systemd, therefore you should too" > This is
> a classic example of the bandwagon fallacy.

On the other hand, network effects are real. You'll have an easier time
finding help if the system you use is used by many others.

~~~
snogglethorpe
... and in this case systemd is popular not because _users_ decided to use it,
but because _distributions_ decided to use it, which means that systemd is
going to have a stronger support network and more developer attention than a
system which is not popular.

Good support and active development are pretty big advantages.

------
astine
"For Internet socket activation, all you have to do is start your daemon the
old way, have it bind on the port, and let it sit there idly. If the kernel
needs the RAM, it will swap the (idle) daemon to disk. If the kernel receives
an incoming connection, it will swap the daemon back into RAM so it can handle
it. Systemd doesn't need to be involved at all here."

So you want me to patch my Postgres instance to implement this? Or should I
just do it in the init script? I guess that's possible, but it requires your
sysadmin also be a programmer.

~~~
wmf
That's how daemons normally work. The author is obliquely pointing out that
socket activation isn't that much of a benefit. Historically, "socket
activation" using inetd was common but as hardware got cheaper people
gradually dropped inetd in favor of just starting all their daemons at
startup.

~~~
astine
I understand the author's point; he's not being oblique at all. I just
disagree. He explicitly claims that the kernel providing socket functionality
is enough. But it's not. The example using mkfifo for example, is terrible for
instance. It provides no lifecycle management and you'll end up launch
multiple versions of a daemon if you accidentally send multiple signals to the
pipe. There is a huge difference between "this is technically possible," and
this is doable in a way that doesn't have many unforeseen pitfalls. Systemd
asks much less of professionals than sysv and that's it's chief selling point.

------
zanny
I am getting so sick of these blogs for or against systemd.

It is free software. If you do not want to use it, use a distro without it.
And vice versa if you want it. And if you don't _like_ that Debian or
Canonical or Arch a few years back or OpenSuse have switched to using it...
too bad, you are not the maintainer of the repos, and if you were an active
member of the community with voting power, you were outvoted. That means a
majority of people with stake in these distros wanted systemd, and it is
_their_ project.

Make your own distro without it if you don't want it. Or use one of the dozens
of distros that don't use systemd, or one of the forks that have been made to
remove systemd already.

~~~
uselessdguy
It's obvious you didn't even read the article.

EDIT: I don't know the motivation for the downvotes. I replied like this
because the commenter posted a canned cookie-cutter reply that is addressed in
the article as Fallacy #6.1.

~~~
linuxydave
>I don't know the motivation for the downvotes

It's pro-systemd brigading. The cancer is spreading.

