
What “technical” concerns do I have with systemd? - rossj
http://blog.lusis.org/blog/2014/09/23/end-of-linux/
======
andolanra
Something that tends to get lost in these discussions: it's not a question of
systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's
absolutely no question that the vast majority of Linux users would rather
sysvinit disappear entirely.

But that _doesn 't_ mean that there aren't better alternatives. My personal
preference is runit[1], which is based on djb's daemontools[2] and gives you
all the dependency management and speed gains of systemd without the
monolithic architecture and without the complicated shell scripts of sysvinit,
as well as cool features like service management trees for non-root users. (In
fact, runit doesn't need to be run as init—you can run it as a non-root user
and provide service management even if you use another init. It just happens
to make a nice init.)

The tests I've seen show that a minimal system with runit boots roughly as
fast as than a minimal system with systemd. That doesn't mean runit is the
end-all solution to "which init"—it's perfect for my needs, but maybe not
yours—but it _does_ mean that the choice is not a choice between systemd-but-
fast versus sysvinit-but-slow. The field of choices is much, much broader.

[1]: [http://smarden.org/runit/](http://smarden.org/runit/)

[2]: [http://cr.yp.to/daemontools.html](http://cr.yp.to/daemontools.html)

~~~
antientropic
What mystifies me in these systemd discussions is that people constantly seem
to attack a _caricature_ of systemd that has little in common with its actual
implementation. Take for instance the perpetual "monolithic architecture"
argument. _What_ monolithic architecture? Systemd is in fact highly modular.
For instance, PID 1 concerns itself with starting and monitoring units, and
not much more. Other functions are implemented in other programs, such as
journald, udevd, logind and so on. Of course, some of the components sometimes
need to talk to each other, but generally via well-defined (D-Bus) interfaces
- e.g., pam_systemd registers user sessions with logind via a D-Bus call, and
loginctl asks logind about current user sessions, also via a D-Bus call.
What's wrong about that architecture?

Now, systemd the _package_ is getting pretty bloated. For instance, there is
no reason why stuff like networkd couldn't be in a separate package that
depends on systemd. But that's not really an architectural issue, and not much
of a problem for users. (For instance, you can disable networkd just fine.)

~~~
jude-
What mystifies me in these systemd discussions is that systemd proponents
always seem to think that "modular" is somehow the opposite of "monolithic,"
when it is entirely possible for a system to be both.

"Modular" only means that a system is factored into components that address
logically separate concerns. "Monolithic" means that your modules are tightly
coupled.

For example, the Linux kernel and X.org are both modular and monolithic, as is
systemd. Coreutils, by contrast, is modular and NOT monolithic.

~~~
antientropic
The Linux kernel is considered monolithic because all those modules run in the
same kernel space, where they can all walk over each other and bring down the
system. Systemd is not like that: its components run in separate processes.

By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd
servers live in the same source tree and send messages to each other at
runtime.

~~~
vezzy-fnord
systemd's modules are interdependent and all require systemd to be PID1 in
order to function. You cannot, e.g. strip out logind only and use it as a
ConsoleKit replacement. Contrast this with a toolkit based approach like s6,
which can run as init, process supervisor or both, and can have its tools that
operate on process state be used independently.

Another criteria is whether you can swap out one component without breaking
the whole. You can't do this for journald, for example. You're forced to keep
it by reducing it to a sink that redirects to your syslogd of choice. On the
other hand, replacing parts of the GNU coreutils with those of 9base or sbase,
for instance, won't break the rest (though it will break programs that depend
on the GNU coreutils' extended options, of course).

~~~
MertsA
The journal is a bit of a contrived example though, it is pretty much the only
mandatory part of systemd outside of pid 1 and you can still replace it, you
just need something to fill the place of it and no one wants to put forth the
effort to create some journald compatible rsyslog daemon because it would be
mostly pointless. Also, if you really hate it you can still configure it to
not even store run time logs by throwing Storage=None into the config file.

------
IshKebab
So... none?

Unintegrated desktop linux is painful, and the fixes for it so far have mostly
been hacks. Systemd actually attempts to create some kind of modern cohesive
system which is a _good_ thing.

Maybe you don't see the downsides to the lack of integration because you're
just used to putting up with them.

~~~
marcosdumay
Tightly integrated operational systems are painful. The article really says it
all:

> Linux is becoming the thing that we adopted Linux to get away from.

It's just true in many more aspects than the one where this sentence is
placed.

~~~
justincormack
Most people now didn't adopt Linux to get away from something, its just the
default server OS. (And not desktop).

~~~
cwyers
I think mostly people adopted Linux to get away from paying a lot of per-seat
license fees for everything, and to get away from having to buy some vendor's
medium iron hardware rather than just using commodity x86 chips.

~~~
justincormack
Ten years ago yes. Now we have the new people who have never used anything non
x86.

------
RadioactiveMan
As a user of linux on the desktop, I've never felt a moment of concern over
the fact that it takes longer to boot than did Windows. I'm not sure who is
panicked by this and I'm distressed that we would solve all of our problems
with init by embracing systemd.

If Gnome requires systemd, lets drop Gnome.

~~~
hyperpape
As a user of computers, I have never once felt that boot time was adequate for
any device I have owned.

~~~
colanderman
You must be young. Back in the good ol' days computers booted instantly. Apple
][, Commodore 64, I'm looking at you.

~~~
hyperpape
My first computer was a Mac Plus, so it appears I just narrowly missed the
good ole days.

------
pestaa
Integration comes with a huge price.

I'm a beginner sysadmin, and therefore not really knowledgeable about the
recent changes in Linux -- however I've seen FreeBSD in production(ish), and
it was indeed a more pleasent experience. Paths, configuration, the package
system, the documentation (!) all felt nicer.

~~~
drdaeman
I believe it's more about tight vs loose coupling, not integration. The
contrast is, systemd's parts are relatively tightly coupled together (in a way
one can't easily pull, say, journald and use it autonomously, with other
init), while, traditional init systems are bunch of loosely coupled mostly
autonomous modules that happen to reliably work together thanks to standards'
glue (so, they're integrated as well).

I could be wrong on this, though. Just my thoughts.

~~~
keithpeter
I suspect the 'standards glue' is an important aspect of all this. With
loosely coupled modules and _standardised_ glue you can update components
separately on different time scales and be reasonably confident that they will
still integrate with other components.

Tighter coupling with rapid integration in functions and therefore changes in
glue makes it harder to work piecemeal. Distributions have very different time
lines. Pity the packager stuck trying to back port patches to an earlier
version of the system when the upstream project(s) is(are) pushing out
security updates based on the current versions and their current glue/api.

Of course it will _work_ and _work well_. Redhat are betting their major
product on this set of modules. The problem will be the load on other projects
working around this.

------
copper_rose
He's hit the nail on the head - systemd's fundamental design is not
appropriate for the server environment:

"I have to provide a system that runs reliably and can easily be reasoned
about and yet I have to build it on distributions created by people who
consider how long it takes to get to the fucking GDM login screen and if
shutting the laptop lid will cause the system to hibernate properly or not."

~~~
sp332
Why do you "have to" build it on those distros? Why not use a server distro
that doesn't even have X let alone GDM?

~~~
copper_rose
The problem is that in many server environments, particularly at scale, the
speed of the bootstrap processes of the OS doesn't matter. One of the goals of
systemd is to make the bootstrap process faster, which is irrelevant for those
(non-desktop) use cases. So you see, systemd is solving problems, and making
trade-offs to do it, that just don't matter for the non-desktop use case. I
can of course choose not to install gdm, but that doesn't change the fact that
systemd was designed (you might say over-designed) with the desktop use case
in mind. Because of that, I have to live with those trade offs, even though my
use case does not benefit. Since all major Linux distros are deciding to adopt
systemd, it will be very difficult to "roll your own" and use something else,
especially since the rest of the userland will assume that everyone is doing
things the systemd way, this making it even harder to go against the flow.

~~~
cwyers
What tradeoffs is it making for faster boot times that you feel aren't suited
to the server?

------
jessaustin
Why weren't any of these objections heard back before Canonical knuckled
under? Was upstart even worse? I really enjoyed the "impotent rage" piece
linked in TFA's comments.

~~~
lmm
Systemd didn't used to be this invasive.

There have been "better init" options for many years, none of which gained
much traction. So most of us figured the community as a whole wasn't very
bothered. IMO systemd has only achieved "popularity" by using some very
underhanded tactics.

~~~
angersock
Is this a classic Poettering thing?

How'd PulseAudio get stuck in so much stuff? Is this a pattern?

~~~
chronid
It's not really a "Poettering" thing. More like a "Red Hat" thing. They
control (= their employee are mantainers and developers of) most linux core
userspace programs/libraries, starting from Udev and Dbus and Upower,
they/their developers make the choices that matters in that regard. It's how
OSS operates.

------
disordr
Whatever happened to the old unix philosophies of KISS, and if it isn't
broken, don't fix it. Granted, as many other have pointed out, SysVinit
definitely has its pain points and could use improvements, but there are some
other init systems people can use without having systemd shoved down our
throats. It's been a while since I've played with *BSD, but it might be the
time to start seriously looking at it again. Or switch to slack/debian and
keep my old-fashioned init system.

~~~
steanne
debian is switching to systemd. the only big holdout i've heard of besides
slackware is gentoo.

------
lovelearning
Assuming that everything the author says turns out true - such as the "big
one" exploit - in say an year from now, does anybody know any active popular
open source distro that aims to keep systemd away from servers?

~~~
agwa
Debian has only made systemd the _default_ , and getting sysvinit back is as
simple as running `apt-get install sysvinit-core`.

Removing systemd might have consequences for GNOME, but that's not a concern
on servers. There is a significant enough anti-systemd contingent in Debian
(not to mention Debian also supports kfreebsd, where systemd doesn't run) that
I'm confident sysvinit will remain a viable option for servers and non-GNOME
desktops on Debian. Even GNOME desktops may work on Debian without systemd
thanks to the work being done on systemd-shim.

~~~
keithpeter
_"...and getting sysvinit back is as simple as running `apt-get install
sysvinit-core`"_

Well I gather that is the _intention_ but there are a few bugs at present
around that and an ongoing issue about upgrade from Wheezy to Jessie changing
the init system silently. See Debian-devel for gory details.

------
illumen
systemd should really include pulseaudio, and nginx. Oh, it already has a
httpd in there.

~~~
rossj
And it's own database which is mentioned in
[http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69...](http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950)

~~~
metafex
And it supports QR-codes for kernel panics!

~~~
angersock
oh ffs

~~~
justizin
QR codes for kernel panics is actually brilliant, because it encodes the data
which would otherwise just be serialized to screen in a manner that makes it
portable.

~~~
MertsA
That actually might be nice but don't get your hopes up, systemd isn't
actually part of the linux kernel as some conspiracy nuts would have you
believe. The systemd project can't possibly just add random stuff to kernel
panics, all of that code is in the kernel, not userspace.

I think a little while ago there actually was some work done on making kernel
panics display a QR code but I doubt it'll ever be merged in if it's even
done.

~~~
justizin
I think you're right, but if that's so, then apparently all of the features
the OP claims to be bloat in systemd are questionably in systemd at all, and
the entire discussion is moot.

