

The Systemd Chronicles - stargrave
http://suckless.org/sucks/systemd

======
na85
The need to replace sysvinit was/is valid but systemd is truly a horrible
piece of software. I would argue that systemd has (greatly) increased overall
complexity and simply camouflaged it by moving most of the logic out of init
scripts (unit files) and into program logic. And then added an http server and
binary logs.

The original submission title, while editorialized, was pretty apt in my
opinion. There really does seem to be a core group of people involved with the
GNOME, RedHat, and systemd projects that seem to want to add features just for
the sake of adding features, or perhaps so that they have something to claim
ownership of. Gnome basically decided that text-basd configuration was too
sane and opted for a mix of config files and the Windows Registry (gconf,
dconf) which is a hilariously poor design choice. One-size-fits-all doesn't
work unless you are Apple and your users will happily swallow your marketing
BS and wait in line to buy a new iphone every 2 years.

The startup world is rife with the notions of "out with the old, in with the
new" and "change for change's sake" so it's not surprising to me that a great
deal of HN readers are Poettering apologists.

But to me, it sure seems like systemd is just a chance for Poettering and some
others to pad their resumés, or else perhaps simply an ego trip. I honestly
can't find anything about it that makes me go "hmm, that's a good feature that
outweighs all the other negative parts".

~~~
vezzy-fnord
systemd clicked for me when I started realizing that a lot of its decisions
mapped directly to Red Hat business decisions in cloud computing and
containers, like their backing of Project Atomic. nspawn, the "stateless"
system features through dynamic configuration population, GPT partition
discovery deprecating fstab(5), having a big centralized blob journal, the
embedded network management (which is mostly useful for container deployments
rather than desktops) and NSS extensions, the GNOME system upgrade logic and
so on.

It's theoretically meant to be general-purpose, but it really shines at
virtualized deployments and some desktops because of the multi-seat
integration (though logind these days has some power management features that
is just as relevant for servers).

~~~
davidstrauss
I don't think Red Hat was the driving force behind systemd's container and VM
integration.

systemd-nspawn was created to provide rapid testing of systemd, and it was
(and, for now, still is) marked as an experimental utility that isn't for
production purposes.

If you look at many of the early blog posts mentioning systemd and
containers/VMs, you'll actually see my work and my company (Pantheon)
mentioned more than Red Hat. In more recent posts, you'll see lots of CoreOS
influence. Project Atomic isn't working with systemd in any direct,
significant way; you won't see much coordination other than in some shared
philosophy about a stateless base OS, and even that is more attributable to
CoreOS's influence than Red Hat's.

I think the influence of Red Hat on systemd is overstated. Of the two
perspectives: (1) Red Hat driving everything and (2) Lennart answering mostly
to himself, the latter is way more accurate, for better or worse (depending on
your opinion of him).

~~~
vezzy-fnord
Well, Red Hat were quick to adopt CoreOS' appc, before a lot of companies
ultimately united under the Open Container Project banner.

As for:

 _and it was (and, for now, still is) marked as an experimental utility that
isn 't for production purposes._

rkt used nspawn for a while, and it's still systemd-based.

The fact that Lennart was giving out presentations about nspawn specifically
makes me believe it's very much intended to be used in production, as a
"chroot on steroids".

~~~
davidstrauss
> The fact that Lennart was giving out presentations about nspawn specifically
> makes me believe it's very much intended to be used in production, as a
> "chroot on steroids".

This is a recent development -- and why I put the caveat "for now." systemd-
nspawn is probably going to be marked production-ready quite soon, especially
because it's the foundation for the CoreOS Rocket container tool.

------
witty_username
> 8x ctrl + alt + del > In systemd you press eight times Ctrl+Alt+Del to
> trigger reboot.

Like many of the other points, this one is plain incorrect.

> When the user presses Ctrl-Alt-Del more than 7x within 2s an immediate
> reboot is triggered. This useful if shutdown is hung and is unable to
> complete, to expedite the operation. Note that this kind of reboot will
> still unmount all file systems, and hence should not result in fsck being
> run on next reboot.

Systemd is reboots your system quickly if you press it multiple times. Ctrl-
Alt-Del still reboots your system.

> floppy group removed > Because we know what is right to know about groups.
> This is just one example of the mass of group name dependencies systemd is
> adding. See sinit for how to not need such dependencies.

WTF? systemd is removing an obsolete group, not adding one.

> systemd-pm > Power management is required on boot up.

You're right in this one and it's a GoodThing(tm). Hopefully we might see
better hibernate and sleep support.

> factory reset > Welcome to the Windows OEM world: Factory reset for Linux!
> Of course it is in your init process.

Yes, all features of Windows are BadThings(tm).

~~~
falcolas
> Ctrl-Alt-Del still reboots your system.

Actually, it triggers a script. which should "typically" point at the reboot
script. It might not, though.

So, if you absolutely want to reboot, you have to do the 8x ctl-alt-delete

[http://www.freedesktop.org/software/systemd/man/systemd.spec...](http://www.freedesktop.org/software/systemd/man/systemd.special.html)

ctrl-alt-del.target

    
    
        systemd starts this target whenever Control+Alt+Del is pressed on the console. Usually this should be aliased (symlinked) to reboot.target.
    

[EDIT] To address your new, edited in points:

> WTF? systemd is removing an obsolete group, not adding one.

Deleting groups is a bigger problem than adding groups, since it can cause
subtle errors in Linux. Deleting a long existing group can break software
which depends on it (rightly or not), and if its GID is re-used for another
group, other pieces of software can start quietly doing the wrong thing.

> You're right in this one and it's a GoodThing

The problem is that it's another thing which can break at startup, and is now
in the critical path to system stability. Suckless promotes simplicity, this
is not simple.

> Yes, all features of Windows are BadThings

When in the critical path for system stability? Yes. I like quite a few
different windows functionality points myself, but having those things
suddenly moved from a relatively safe "child of PID 1" to the system critical
"PID 1", they have to work perfectly, every time. Needless to say, they don't.

~~~
yrro
> Deleting groups is a bigger problem than adding groups, since it can cause
> subtle errors in Linux. Deleting a long existing group can break software
> which depends on it (rightly or not), and if its GID is re-used for another
> group, other pieces of software can start quietly doing the wrong thing.

Systemd is not deleting any groups.

------
AceJohnny2
This article is inflammatory, in bad faith, and in many places blatantly
incorrect.

I appreciate a lot of suckless work, but I don't see what this is adding.

~~~
czardoz
Just out of curiosity, can you summarize where exactly it is wrong?

~~~
davidstrauss
As a systemd committer, I certainly can. I don't have time for all of them, so
I'll pull the first couple and a few other egregious ones.

> Systemd was introduced to decrease the boot up time. Now that they do not
> understand all implications and dependencies, let us add some artifical time
> we found out might work for the developers laptops. More on this small world
> hypothesis of the systemd devleopers below.

systemd was not introduced to decrease boot time; it was introduced to
properly manage dependencies and parallelism. Such an approach happens to
massively improve boot times in many cases, but that's a side-effect. The
delay introduced is specifically to account for the slow/unreliable
initialization of certain docking station hardware that has no other known
reliable method for detection. (This is what happens in Linux with certain
reverse-engineered hardware.) Importantly, this delay doesn't impact boot
time, only introduces a delay before allowing the system to sleep, so even the
(made up) point about systemd being about boot times isn't affected here.

> Screen brightness is something that should crash your boot up when it is not
> working.

The TODO item is about avoiding restoration of screen brightness at boot to
such a low level that some laptops consider it to be a "backlight off" state.
Someone may have shut a laptop down (even automatically) with the backlight
off, but we think it should probably turn back on on the next boot. Absolutely
nothing to do with "crashing" bootup.

> Systemd made kdbus non-optional in its release.

Totally made up. systemd's DBus library provides equivalent support for
usermode DBus and kdbus.

> This one is a setback. Why is there no default editor in systemd in case of
> factory reset?

I'm not sure what this is even claiming. Is this some sort of trolling about
complexity the author thinks systemd will eventually add and is some sort of
advance critique?

In general, the piece shows disingenuous portrayal of actual issues to the
level of clickbait and fails to understand that not everything in systemd's
git repository runs as part of PID 1 (like the network management tools, for
example, are a totally separate and optional daemon).

~~~
na85
>The TODO item is about avoiding restoration of screen brightness at boot to
such a low level that some laptops consider it to be a "backlight off" state.
Someone may have shut a laptop down (even automatically) with the backlight
off, but we think it should probably turn back on on the next boot. Absolutely
nothing to do with "crashing" bootup.

Honest question: Why does an init system need to know anything about screen
brightness in the first place?

Shouldn't X11 handle screen brightness?

>I'm not sure what this is even claiming. Is this some sort of trolling about
complexity the author thinks systemd will eventually add and is some sort of
advance critique?

This is, I think, about the fact that _systemctl edit_ is even a thing that
exists. What's the problem with ed, vim, nano, pico, emacs, etc. that
necessitates some kind of built-in systemd editor?

~~~
davidstrauss
> Honest question: Why does an init system need to know anything about screen
> brightness in the first place? Shouldn't X11 handle screen brightness?

I think that's a reasonable question. I am only a regular desktop user of
systemd for anything with a display, so I don't have a strong opinion there.
All of my advanced systemd work is on server systems; I have more opinions
there.

> This is, I think, about the fact that systemctl edit is even a thing that
> exists. What's the problem with ed, vim, nano, pico, emacs, etc. that
> necessitates some kind of built-in systemd editor?

There isn't a built-in systemd editor; that's how disingenuous this piece is.
Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is
configured to be. Totally normal Unix behavior here.

~~~
na85
>There isn't a built-in systemd editor; that's how disingenuous this piece is.
Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is
configured to be. Totally normal Unix behavior here.

Well, okay, but the suckless people are about simplicity. Adding _systemctl
edit_ seems like a completely unnecessary alias. Another feature for the sake
of having another feature.

Why assume the user is too stupid or lazy to manually invoke vim and then
systemctl daemon-reload?

~~~
c_rrodriguez
This is no different from crontab -e, visudo and other programs that invoke
$EDITOR..

------
eeperson
This is a pretty bad list of issues with systemd. A large portion of
criticisms in this list seems to be due to a misunderstanding of the author
about what is actually in the systemd git repo. The git repo contains udev and
other deamons in addition to the init process. As a result, most of the claims
on this page about things going in to the init process are incorrect. If you
look the actual release notes they are usually referencing a completely
different daemon.

For example the line 'pid 1 does DNS' points to a release note about a
separate daemon called 'systemd-resolved'.

edit: grammar

~~~
digi_owl
Well the devs has brought that on themselves by naming the init binary and the
overall project the same, and then dumping more and more into a singular code
repository.

~~~
davidstrauss
The entire BSD kernel and init system are all in one repository. Are those
developers "bringing on" confusion by doing that?

~~~
digi_owl
If you want to make a BSD do so, do not turn the whole of Linux into one.

Gah, i keep using source repository when i should be using source tree...

------
EmanueleAina
> * sysv removed
> [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1...](http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1651)

> We have won. Now remove all remains of our defeated enemy as fast as we can.
> As said in the beginning of the systemd crusade against the UNIX infidels:
> »You can patch it out.« It is no more there.

Are we really complaining that LSB script support has been moved out of PID1
to a separate binary? Wasn't one of the major point for critics that systemd
has too much in PID1?

~~~
c_rrodriguez
Yes..you figured out that you can't win with these people.. whatever you do
they are going to complain. They are not interested in any constructive
criticism.

~~~
digi_owl
[https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU](https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU)

Pot, meet kettle...

~~~
EmanueleAina
Nope, that's not really the same thing.

------
0xFFC
I have theory in my mind , I hope I can find an answer for it in HN.

I always wondered about how companies like Redhat and Samsung driving open
source project . The way they pushed systemd to Linux community . The way
Intel developer designed Gnome 3 for touch screen rather than Desktops .Is it
true ? for example Company X by recruiting most of lead maintainer of project
Y , They almost take control of its direction .

Is this feasible scenario ? Is this is what happened around sysmted
controversy ?

~~~
EmanueleAina
RedHat and Samsung open source contributions aren't really comparable, despite
the latter having got much better lately. Despite me being a long time Debian
user, I've always appreciated how RedHat employees have always been community
members first and RH employees second.

Note that systemd was not pushed to anything: several members of the various
open source communities appreciated their features and considered it worth to
be used and even made the default. Please read the long, technical and
detailed discussion Debian had before choosing systemd as their default init
system while still providing sysvinit as a supported choice:
[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=727708](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=727708)

Also Intel developers didn't design GNOME 3 for touch screens. Sure, Clutter
development was at some point carried on by Intel, but most of the GNOME
design comes from RedHat and volunteers. That said, it's true that GNOME cares
for keyboard, mouse and touch interaction: and I'm very happy that they care
about touch, thanks to them using the touchscreen on my new laptop has been a
pleasure.

To answer your concerns, both systemd and GNOME see a big investment from
RedHat in their development, but the developers are influencing RedHat's
choices more than the opposite. Keep also in mind that a huge number of
contributions still comes from non-RedHat developers for both systemd and
GNOME, at the moment there's no risk that the company will drag these projects
where their maintainers don't want to go.

~~~
pdkl95
> Note that systemd was not pushed to anything

Please stop the revisionist history - it is well documented[1] that Lennart
Poettering himself is the one that pushed GNOME to depend strictly on systemd.
This was used as leverage against Debian, and became a key reason for several
of the votes for systemd in the infamous technical-committee vote.

[1] [https://mail.gnome.org/archives/desktop-devel-
list/2011-May/...](https://mail.gnome.org/archives/desktop-devel-
list/2011-May/msg00427.html)

~~~
EmanueleAina
No revisionism here:

1) in no possible way "I'd like to propose systemd" can be seen as forcefully
"pushing" something

2) please go read (or re-read) the full discussion behind the Debian tech-ctte
decision[1] to understand how little the GNOME dependency mattered

[1] [https://bugs.debian.org/727708](https://bugs.debian.org/727708)

~~~
pdkl95
1) systemd was not pushed at GNOME; the GNOME dependency was the leverage used
to push systemd at _distributions_. This let the systemd cabal look innocent
with GNOME getting the blame for any compatibility issues. This is a very
common political tactic that is popular because it gives plausible deniability
and usually requires more than a sound-bite to refute. Surely you've seen it
before.

2) I read debate on the Debian tech-ctte and surrounding discussion in
realtime when it happened. GNOME compatibility was a key concern, and while
the idea of dropping GNOME was briefly considered, concerns about supporting
GNOME ended up having significant sway and a big reason - though not the
_only_ reason - why systemd won the vote.

This would normally be a purely technical decision, but in this case the
GNOME->systemd dependence _only exists_ because Lennart Poettering created it.

~~~
EmanueleAina
If you talk about cabals, there's no point in having a sensible discussion. Te
existence of secret cabals is a matter of faith, and you cannot really discuss
things of faith with reason alone.

In any case, both GNOME and Debian _willingly_ adopted systemd. Thinking
otherwise implies that GNOME and Debian developers are silly idiots: it that's
the case, why bother. If it's not the case, they know what they want and
nobody forcecully "pushed" anything.

~~~
pdkl95
I was waiting for someone to reveal their ignorance by calling out "cabal".
Why should anybody trust your other comments about the history of systemd when
you don't know that "cabal" is _Lennart Poettering 's term_ for the systemd
core developers?

[http://0pointer.net/blog/revisiting-how-we-put-together-
linu...](http://0pointer.net/blog/revisiting-how-we-put-together-linux-
systems.html)

    
    
        The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack,
        Tom Gundersen, David Herrmann, and yours truly) ...

~~~
EmanueleAina
You either don't know the meaning of the word "irony" or you have some issues
with cause→effect relations.

------
justizin
It seems like the argument being made here is that perhaps the systemd
developers are afraid / unable to innovate in the kernel, which is in fact the
overall system-wide daemon and parent to all processes.

~~~
EmanueleAina
I'm not sure I understand your comment. Are you proposing to move all the
systemd features in the kernel? Why do you think it would be a good idea.

Note that one of the stated goals for systemd is to make good use of all the
new fancy features are already available in the Linux kernel but not many
people use because they are not portable (eg. control groups). Also note that
some cool features have already been merged in the Linux the kernel after the
systemd developers created them (eg. memfd).

------
grabcocque
Really, is it necessary to have _another_ systemd perma-sulk?

------
jrk_
> Führerbunker

You know that it is these kind of things that makes you look immature and
discreditable no matter how valid your arguments are?

Don't get me wrong, I'm not judging. I understand that this is a certain kind
of humor, but there are many who don't and who will judge you for it.

------
fredsted
Unfortunately it looks like a lot of the links are broken. At least, I don't
see the connection to what the first link about logind has to do with udev.

------
jamiesonbecker
Title is incorrect. Should either be 'sucks - systemd' or 'Systemd is the best
example of Suck.'

------
voidz
In this discussion on HN, I hope that people of both sides will permit
everyone to have their own opinion on systemd without becoming as emotional or
angry as the last time. Topics about systemd tend to get out of hand way too
fast and often. In the past I've been blamed for saying I really dislike
systemd but my arguments were not even read. The same thing the other way
around: I've seen people who dislike systemd flame the people who do enjoy it.
Let's just not repeat that kind of discussion; we can do better.

Getting emotional about something is not always a bad thing, IMO. But let's
just respect that different people hold different opinions, especially with
something as controversial as systemd. Let's just aim at being constructive
here.

~~~
rc4algorithm
Some tasteful flaming is healthy in situations like this. Many people consider
systemd to be a hijacking of the projects that they base their careers and
livelihoods on, and many people see hundreds or thousands of hours of work
they've invested being steered in an unsavory direction by a corporation or
three.

~~~
johnny22
and many people have been waiting for something like systemd to appear since
they started using Linux in the 90s :)

~~~
seba_dos1
Why haven't them moved to Windows then?

If you prefer Windows ways of doing stuff then use it, instead of changing a
perfectly fine but different OS into Windows-bis.

~~~
the_why_of_y
Because Windows sucks, since it doesn't have anything like systemd.

------
cjsthompson
The noble knights of UNIX lore and traditions are at it again. Lo and behold!
Armed with the arcane power of ancient spaghetti code shell scripts and
logical fallacies, they grep their way through enemy lines to banish the
dreaded modernity once and for all.

~~~
vezzy-fnord
_ancient spaghetti code shell scripts and logical fallacies_

Sounds like self-projection. Read this:
[http://uselessd.darknedgy.net/ProSystemdAntiSystemd/](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/)

Then again the fact that you're harping on SysV initscripts when alternatives
have been around for ages makes me strongly believe you're trolling.

~~~
cjsthompson
Yes I'm trolling/mocking you anti-systemd retards. That's what Schopenhauer
recommends as a strategy against irrational rhetoric (here of the reactionary
kind). I couldn't care less for irrational people's reading recommendations.

P.S.: "Self-projection" is psychobabble grounded in no science.

~~~
vezzy-fnord
I'm not even anti-systemd, but I can certainly use you as ammunition against
systemd proponents if the time ever comes. Thank you kindly for lacking self-
control and giving me this opportunity.

~~~
cjsthompson
No, you just can't recognize that systemd is objectively and clearly superior
to every other Linux init system by just about every measure. In fact, systemd
is revolutionary in it's own right and that's why it is hated so much. People
who actually design operating systems — as opposed to basement-dwelling
traditionalists — have expressed admiration for it. Haiku are doing their own
systemd inspired init system. And there's been FreeBSD developers talking of
doing their own as well. Supposing you're the idiot who wrote that article you
linked, the whole "I take no sides" thing is called the middle ground fallacy.
Ironic that you should speak of "ape brain" when you either endorse or perhaps
wrote such an article.

[https://en.wikipedia.org/wiki/Argument_to_moderation](https://en.wikipedia.org/wiki/Argument_to_moderation)

Oh, and speaking of self-control, aren't you the idiot who couldn't resist
replying to my obviously satyrical comment in the first place?

~~~
vezzy-fnord
Actually, Haiku's init is more inspired by launchd than anything, which
predates systemd by some 5 years. If you actually read about Haiku's scheme,
you'd see the semantics have little in common. FreeBSD is thinking of
adopting, again, launchd. So far this is only in experimental feature branches
and from my knowledge it will initially be tested on FreeNAS before it makes
it to FreeBSD, specifically.

systemd has plenty of good ideas. None are novel, and it is not
"revolutionary". Making exaggerations like this only furthers the perception
of your incredulity. Preopening sockets is an old idea, having centralized
service management for Unix was first done by IBM AIX in 1993 and everything
else is exploiting kernel subsystems, which again, are not novel. cgroups were
first done as Solaris contracts, for instance. In fact, Solaris SMF and
systemd are quite similar. The former even has sophisticated hardware fault
detection.

No argument to moderation was ever made. Your reading comprehension is not in
good shape. "People who actually design operating systems" are not some
hivemind, and you're far too historically and technically illiterate to make
any value judgment on that front, either way.

 _obviously satyrical comment_

Ah yes, the old "Joke's on you, I was only _pretending_ to be an idiot!"
defense. Always useful for backpedaling.

Satyrical [sic], indeed.

That's all from me. I might quote you in the future as an example of a
cautionary tale.

