
Systemd: The Biggest Myths - janerik
http://0pointer.de/blog/projects/the-biggest-myths
======
betterunix
Will they have the same attitude as the ConsoleKit/PolicyKit/_Kit people have
when someone says, "I need to do something different, but this service is
preventing me from doing it?" As an example, I want to set up my system so
that one user can play audio even when a different user is "active," yet after
hours reading through bug reports about that and mailing list archives, all I
could find where these responses:

* "Not our fault, it's that other service."

* "We are never going to support that. You don't want it anyway."

* "Well that will be fixed with systemd"

* "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support."

* "This will be fixed with systemd!"

So, I guess now the question is, when someone comes along and says, "I need to
do X, I used to be able to do X before systemd was in use and now systemd is
stopping me, how can I fixed that?" will systemd maintainers respond with
things like the above? Will there be useful and thorough documentation, so
that users can fix things without having to bug the maintainers?

------
mhurron
> systemd being Linux-only is not nice to the BSDs.

>Completely wrong. The BSD folks are pretty much uninterested in systemd. If
systemd was portable, this would change nothing, they still wouldn't adopt it

systemd is not portable, it wasn't made to be portable, it relies on far too
many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's
don't care about it so we didn't make it portable.'

~~~
diegocg
I disagree, I think that Lennart is right. Nobody really cares if systemd is
not portable. Upstart was not portable to BSDs, and nobody cared. The
traditional sysvinit system was, AFAIK, not portable until the debian/freebsd
people bothered about it. Heck, the init scripts in Linux used to be not
portable even between different Linux distros.

launchd (OS X) and SMF (solaris) weren't portable, either.

By the way, when was the last time a BSD operating system cared about making
their init system portable to Linux?

I'm not sure why systemd not being portable to other operating systems is
suddenly a big deal.

~~~
4ad
You can write software ignoring how it will be started and you (or others) can
write init scripts for various traditional systems. This is way harder if you
use systemd; suddenly you _need_ to care about the init system, and you might
sacrifice init independence for pragmatic reasons (I want to support systemd,
but I don't want to write this yet-another-abstract-wrapper-layer so that
someone else _might_ use it with other type of init system).

~~~
cnvogel
You always had to care about the init-system: There are some differences
between e.g. debian and redhat (start-stop-daemon only on debian, tools for
creating the symlinks to install a service), then there's upstart with a
different shell-script-esque syntax.

To support systemd, the number of configs you provide will go from maybe 4 to
5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the
systemd services look as if they are a lot less boiler-plate than the typical
debian init-script.

<https://wiki.archlinux.org/index.php/Systemd/Services> (e.g. dropbear is very
simple)

~~~
X-Istence
No, generally you didn't have to care about the init-system unless you wanted
to provide an init script. But it didn't matter how your daemon was/is
started. With systemd that is no longer the case, you can use certain systemd
only features thereby locking out people that want to use your service/daemon
without systemd.

------
ElliotH
Benefits to me as a desktop and laptop user of systemd.

1) Speed does matter. Fast boots are good. 2) The new journal is just better.
Finding something in the logs is easier. 3) Service files are easier to write
than init scripts and one can have more confidence they will work as intended
as you need write very little configuration oneself. 4) Knowledge of
dependencies means I never have to worry about starting dbus before gdm. It
just does what is necessary to do the correct thing.

I personally want all of those things. I am really happy they came to Arch and
Fedora. They both feel much more modern for it. Working on systems that use
older init systems now feels archaic.

Let's move with the times. I remember the same set of complaints when we got
NetworkManager. I remember the same complaints with PulseAudio.

Guess what? I now have systems with excellent networking and excellent sound.

~~~
fosap
>I remember the same complaints with PulseAudio.

And this is perfectly the reason number two why i won't switch to systemd
(reason number one is there is no need for it). PulseAudio does not work. It
sucks. The irc channel is full of clueless (but trying to be helpfull) people.
And nobody cares. I want my Alsa back. But now it's too late, i hope systemd
will either be better (doubt it) or never be this popular.

And, I cannot lie, I don't want it because I don't want another dbus.
freedesktop, stop turning my linux into a single user os. Next thing is they
want to abolish x11. Sure it's about time for x12, but wayland? I just don't
understand the community that surrounds Linux anymore.

~~~
bkor
PulseAudio works perfectly fine for me. It did have issues in the beginning,
but for many years I didn't have a problem. You said elsewhere that you had
issues, but that you still have issues I can see. Others, could be, no idea.

But I don't have any issues. I don't have high CPU usage. It just plain works
since various years.

------
zdw
Given the title, I'll allow that most of these points are defensive and
brusque. Unfortunately, this tends to be par for the course for the developer,
and I think that turns people off.

Fundamentally, systemd tried solving too many problems at once, in a ways that
inadvertently annoyed people. It replaced so much of the core infrastructure
that upgrading systems resulted in an admin experience that feels alien.
Giving people new tools to deal with things like binary logging != instantly
changing every admin's CLI muscle memory.

I'm not saying that systemd doesn't solve valid problems (the issues it
addresses are truly quite important) - it just goes about it in a dramatically
jarring way.

~~~
mseepgood
> most of these points are defensive and brusque

I prefer reading "This is wrong, because ..." over "This is right, but ...",
since it's more honest.

~~~
jeltz
The myths are a mix of those that are correct but often misunderstood and
those who just are plain wrong. Those which are plain wrong cannot be
responded to with "This is right, but ...".

------
curlypaul924
I don't want systemd because I don't trust Lennart Poettering to be able to
write reliable code.

~~~
4ad
Downvoting this post is unwarranted. Everything that Lennart Poettering has
ever done was an unreliable clusterfuck[1] astray from the Unix philosphy.
There's nothing that he has ever done that is considered "good" by a majority
of Unix-derivative users.

[1] <http://www.youtube.com/watch?v=ZTdUmlGxVo0>

~~~
mseepgood
> <http://www.youtube.com/watch?v=ZTdUmlGxVo0>

Poettering has clearly the better arguments than this reactionary Draxinger
die-hard.

~~~
chipsy
Poettering gets things wrong more than once, and Draxinger could have stomped
him, if he were a little bit more informed on the details.

~~~
koide
Can you chime in and inform us where is Lennart wrong and how? I (and probably
many others) would LOVE that.

~~~
fosap
I'm not going to watch this cringeworthy thing again, but i can remember than
he insisted that dbus was useful and that we need a gnome session in our login
manager. That would be enough to proof the point.

~~~
koide
And the point is that the arguments he made about why dbus is useful (a
lightweight IPC mechanism with use cases not covered by UNIX sockets or TCP
sockets, doing much more) and why do we need a gnome session on the gdm (to
get i18n, network and accessibility features you need most if not all of the
session) are well reasoned and make sense to us out of the loop.

Could you provide the counterarguments?

~~~
fosap
Yes. dbus effectively breaks network transparency of x11 apps and turns Linux
into a Desktop-Single-User OS. While I'm not regually writing desktop
applications i have never ever missed dbus. And ipc mechanisms have a tendency
to become unpleasant (Corba, SOAP).

I don't have a gnome session in my login manager because I don't need i18n for
the words "login" and "password". (although that would be totally possible
without a whole gnome session). I don't have a braille line so i can't say
anything about accessibility, but that _should_ be (in a ideal unix world) a
single printf to /dev/braille. Also the feedback is audible and visual, this
seems to be no issue to me.

~~~
bkor
Accessibility is actually a requirement in many countries (per law). Obviously
not everyone needs it, but just that you do not need it doesn't negate that
others do.

Edit: Plus saying X breaks Y so X is not needed is not a good argument.
Because you have not addressed if X is needed or not, only said that Y breaks.

~~~
fosap
I have no idear how "accessibility" is defined. I'd say getty is quite
accessible, but well, I don't know, I never relied on it. But yet, that is no
excuse to start a hole desktop. Just like a program can use gtk
(theoretically) without a gnome desktop it should be able to do the same with
for a braille display.

I think I can safely say that if X breaks Y, and I need Y than X sucks.
Especially if it worked before X came. X made things worse.

/edit: I think that's why Poettering is hated so much. There was community on
the Nixes, with their own ecosystem and their own way to do stuff. It's wasn't
always beautiful or nice, but their had their way to solve stuff so it would a
kind of blend in with the rest. And then Poettering wants to turn it into
MacOS X or Windows and adds stuff new users probably appreciate, but the old
users never misses. There is a cultural shock. And then it breaks backwards
compatibility. It shouldn't suprise anybody that this product should rather be
superb and not just medicore to accepted.

------
lucian1900
The intensity of people's hate for this guy is mind-boggling. Most of the
stuff he made is really nice, proven by the fact that it's being used widely
without issues.

Even without such an impressive track-record, people should at least give him
the benefit of the doubt.

Even a cursory look into systemd design debunks most of the "criticism" people
have against it.

~~~
betterunix
"Most of the stuff he made is really nice, proven by the fact that it's being
used widely without issues."

Without issues? PulseAudio is _loaded_ with issues. The only time PA works
correctly is when you are doing things the way Lennart thinks you should do
them -- which is basically the way desktop Windows and Mac OS X users are
expected to do things. Another way to put things is this: Lennart's software
designs _dictate_ how users should use their computer, to the exclusion of all
other use-cases. Doing something cool or unusual with PulseAudio is like
pulling teeth.

~~~
the_mitsuhiko
Pulse Audio is not perfect but what before was. People were bitching about PA
and wanted OSS back. I seriously doubt that many of those actually do anything
reasonable with audio.

~~~
betterunix
The thing is, I am not any better off today than I was when I was using ALSA.
None of the problems I had with ALSA were solved by PA; ConsoleKit/PolicyKit
came closer to solving those problems, and even then, new problems were
introduced. The excruciating transition to PA put a bad taste in everyone's
mouth, and now we are all sitting here asking ourselves, "Why did we even
bother?"

So in a sense, you are right: PA is not perfect, and neither were ALSA, OSS,
and other earlier approaches. That is not the issue; the issue is, is PA
actually better? Are we actually able to do things now that we were having
trouble with before? From where I sit, PA makes it easier to use things like
D-BUS and various "Kit" systems to duplicate the desktop user paradigm you see
in Windows or Mac OS X, and nothing more (and that does nothing for me, but
certainly gets in my way when I try to do things like multiseat setups).

~~~
nona
Yep, we are better off now.

I remember trying to get bluetooth audio working in the alsa-only days. Or
network sound with esd/ssh. Or figuring out how to route audio nicely apps. Or
saving my laptop battery. Or many other features that were simply damn
difficult to pull off.

People don't seem to remember how crappy the audio situation used to be, for
users and for ISVs. I respect Lennart and the current PA maintainers a lot for
tackling the problem head on – even if they didn't or couldn't do it perfectly
– instead of just complaining about the sad state of Linux audio, especially
in the face of all the criticism they got over it.

~~~
curlypaul924
Pulseaudio plus blueman does solve the bluetooth problem quite nicely. It's
the main reason why I use pulseaudio.

In exchange for that I put up with confusing audio dialog boxes, high audio
latency, high cpu usage when playing audio, skips and crackles when playing
games, arcane commands to enable loopback, and the occasional necessary
restart of the pulseaudio daemon when sound stops altogether. I guess that's a
reasonable trade.

------
howeyc
> 13\. Myth: systemd being Linux-only is not nice to the BSDs.

> Completely wrong. The BSD folks are pretty much uninterested in systemd. If
> systemd was portable, this would change nothing, they still wouldn't adopt
> it.

> 15\. Myth: systemd could be ported to other kernels if its maintainers just
> wanted to.

> That is simply not true. Porting systemd to other kernel is not feasible. We
> just use too many Linux-specific interfaces.

So what happens to software written for Linux that can be (and currently is)
ported to BSD when it starts to require systemd?

~~~
nona
If it starts to rely on systemd, the question you should be asking, is: why
does this program want to depend on systemd?

It's to interact with the lower plumbing - ie. set up hostname, locale,
timedate, multi-seat etc.

If these interfaces are missing, the software should still work minus a few
missing features. Applications could still #ifdef all they want to make things
work on BSDs, no change there either.

Or the BSDs could make their own implementation of the plumbing interfaces.
Lennart even provided a handy chart:
[http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...](http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart)

Honestly, it's about time we standardize and stop wasting time on these low-
level things. I'd rather work on software higher up in the stack, than wasting
my time working around trivial differences between the Linux distros (bonus
points if they get adopted on other the BSDs too). But that's just me.

------
thaumaturgy
3\. I don't understand the desire to trim seconds off of boot-up time (even
assuming that systemd does this; it didn't for me). The goal should be to
restart less often, not to restart more quickly.

5\. The systemd documentation is indeed very good, and that's probably one of
the biggest drivers behind its adoption. However, it is _also_ difficult. A
big part of the pushback from people over systemd is that it _also_ replaced
syslog, and did so with its own custom binary log format. To quote from a
forum thread I started shortly after updating my old system to systemd,
"Getting smbd/nmbd to work again was a real adventure. Like other users
reported, it would just silently fail when starting it from systemd. No error
message when issuing the start command, and only a vague "failed" in status. I
ended up having to track down Lennart's blog post on "systemd for
administrators" to figure out how in blazes to extract anything useful from
that cussed binary log system he invented. My first half-dozen or so attempts
to get anything useful out of the log journal got exactly zero results; I
finally got lucky on another approach..." (I ended up abandoning that
distribution altogether after that and a number of other frustrations, and the
response from the forums.)

13\. The problem for BSDs isn't so much that systemd is or isn't portable to
them; it's that some upstream software is beginning to _require_ systemd,
making that software difficult (or impossible) to port to BSD.

14\. It seems weird to me to hear someone else decide for other people what is
or isn't a "negligible" amount of work.

15\. So ... systemd is in fact Linux-only by design. How does that jive with
13 again?

19\. systemd may not "force" you to do anything, up until your distribution
adopts it, pushes it as an update, and then you find yourself spending hours
trying to figure out how to troubleshoot a problem that didn't exist before
the update. Then it certainly _is_ forcing you to do something.

Here's the problem in a nut shell as I see it: if systemd had been the default
in Linux for the last ten years, probably the tool chain around it would be
mature enough to meet everyone's needs, we would all be accustomed to the
specific commands needed to control and interact with and debug systemd stuff,
and if someone came along and proposed replacing everything with a syslog
daemon and a pile of init scripts, there'd be rage and outcry. That is to say,
I don't see anything _inherently_ bad about systemd.

But, what _is_ enormously frustrating is to have something that works, and be
well adapted to it, so that if something breaks I know exactly where to look,
and then have all of that be replaced by a foreign system that breaks old
things in new ways and requires hours spent trying to figure out what the hell
happened.

If the replacement system offers serious benefits over the old system, that
offsets the pain slightly. In this case, I've yet to see what the actual
benefits are; I have no idea what problems systemd is attempting to solve
which are so severe, so immediate, so intractable that they require a jarring
change to some of the fundamental parts of the operating system.

~~~
meaty
Regarding your last point, the main thing that systemd excels at is managing
the mishmash of power events, other ACPI events, service management and
integration with DBus (which everything seems to require these days).

However, I run Linux in three locations and here's where systemd fits for me:

1\. Servers. No use whatsoever. There are two power states: off and on. None
of this is really an improvement over SVR4 init. It's just another damn tool
to learn.

2\. Desktops: No use whatsoever. I run mine like servers simply because if I
need remote access, trusting stuff like WOL and ACPI is just silly on Linux.

3\. Laptops: No use whatsoever. This is simply down to the fact that the power
management on Linux i.e. hibernate/sleep support is a bag of shit. I run mine
as power states off and on, much as 1 and 2.

Regarding boot speed - my laptop boots in about 14 seconds (SSD). Who cares
about making it faster?

I find that a shell script is far more useful i.e. it doesn't enforce
constraints on you which have to then be added as features to systemd. Plus
shell scripts are generic tools i.e. learning how to write them will be of
more use globally than learning systemd guts.

So basically, screw it.

The problem that this outlines is that Linux's power management, event and
ACPI state management is crappy. We don't need another layer of crap over the
top of it to make it work properly.

~~~
jeltz
To me systemd looks mainly useful for servers. Some of the nice server
features:

1\. It is way easier to write a systemd unit for an in house application than
it is to write a correct sysvinit script.

2\. Everything runs in a cgroup making it easier to add resource limits and
see which process is started by which service.

3\. Easy to check which daemons are running and not.

4\. Reduced startup time for containers.

~~~
mfjordvald
> 3\. Easy to check which daemons are running and not.

How? This is one of the things that have really annoyed me as all the systemd
services have gone from service --status-all.

~~~
glogla
htop?

I'm not linux admin anymore, but I when I was, I used various service status
software thingies only to find out whether the system thinks the service is
running, because they tend to be wrong, and just annoy you (not starting
crashed server because it "is already running" or something similar). I think
debian doesn't even track service states, but I'm not sure.

Of course, with systemd it will be even more fun.

~~~
bkor
systemd tracks service status way more reliably than sysvinit. It also stops
services more reliably. This due to the usage of cgroups.

------
delinka

        6. Myth: systemd is not modular.
    
        Not true at all. At compile time you have a number of  ...
    

So it's only modular at compile time. This seems like a negative to me.

~~~
bkor
You can also disable various things during runtime. A->B does not imply B->A.

~~~
delinka
It's not assumption by implication, it's due to omission. I cannot assume a
feature exists in your software, you must tell me it exists. As a contrived
example, why would I expect your To Do List app to manage recipes?

------
mseepgood
Most "arguments" I read are are either ad-hominem or ad-pulseaudionem attacks.

~~~
fosap
I don't see a single ad-hominem.

And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If
your software design sucks and it does not work good enough that you don't
have to care about this you will be told it sucks. And to me it seems that
systemd is written in the spirit of dbus and nm.

------
Niten
This article from last August hits the nail on the head with regard to
systemd:

<http://www.pappp.net/?p=969>

"I’m not sure that this is a bad design, but it is most definitely not UNIX or
anything like it."

~~~
bkor
The blogpost already addresses everything that above article gets wrong.

------
ragenz
Myth 31: "I heard it was written by web developers."

~~~
sparkie
No, that's Gnome-shell.

