
Systemd, ten years later: a historical and technical retrospective - vezzy-fnord
https://blog.darknedgy.net/technology/2020/05/02/0/
======
gorgoiler
When writing software, it’s comparatively easy to come up with grand new ideas
and turn them into lines of code and files filled with modules.

What’s much harder is (1) to expand ones code without coupling everything
together (2) present it in a persuasive way that naturally builds a user base.

SystemD feels like the new grad hire who decided the first thing the would do
after joining — the opening power play — is to convince the PHB we should
rewrite everything in Haskell.

At this point the gentler folk start quietly honing their CVs and sneaking
their personal belongings off their desks, one night at a time, in the hope no
one notices they are all about to quit.

It felt like Unix systems administration was a haven from this sort of
politics — I don’t remember tmux, git, or python trying to push behavior
changes on upstream components of the OS[1]. I’m sure it’s why Unix attracted
a certain type of personality for so many years and I’m sad to see that
changing.

[1] If you are thinking “but those are command line utilities, whereas the
init process is a much more specialized case” then I’d encourage you to
revisit the Unix principles of every component being a small and simple
program! Even init, cron, and login! It’s not some grand ideal to be zealously
adhered to: it’s the principles of small components that mean the same OS can
run on a quad core Xeon as runs on a $45 network switch.

~~~
theamk
I think you underestimate how badly the old sysvinit sucked in the world with
many good distribution-provided packages.

It was pretty good in the good, old days, where a sysadmin could list every
daemon the system runs by heart, but it was breaking apart when you had tons
of random packages:

Package X uses "start-stop-daemon" in ini file, so there is no way to get
error messages if config file is incorrect. Package B has no disable switch,
so you get to stick "exit" in /etc/default. Package C has this weird logging
format which cannot be rotated daily, and is not integrated with anything.
Package D likes to die and leave PID file around, and then it fails to restart
because of that. Package E likes to bury its settings in /etc/init.d/ file, so
there are conflicts every time it updates. User A likes to leave their
executables on their machine after logout, so we need a cleanup script.

This was seriously getting old -- after you apply a hack after hack, you start
wanting something better. There were a few candidates -- upstart,
daemontools/runit, systemd. Only two of them actually did the work to add
backward compatibility and integrate with upstream. Upstart sucked even worse
than systemd. This left only one candidate.

Remember, even if you can claim for Fedora that someone "convinced the PHB",
this does not apply to other distros. Debian, Ubuntu, Arch all chose the
systemd voluntarily. This is because sysvinit sucks, and no one came up with a
better option.

~~~
AnthonyMouse
What you are missing is that it is possible for two things to be true at once.
It is possible for sysvinit to suck and for systemd to suck in entirely
different and potentially much worse ways.

It's as though someone is complaining about having to live under the USSR and
how bad things are, and then someone responds that the German rocket program
has been dismantled and the British never really had much of one and the
Americans are doing okay but the fact is that the USSR was the first to put a
man into space. As if that justifies everything else they did.

~~~
BiteCode_dev
I hear that a lot.

It's not my experience.

Setuping services has been a pain for 15 years for me. Then with systemd it
was suddenly easy.

Detractors keep repeating systemd sucks, but that this point, Debian and
Fedora apparently decided it was good enough. And I never heard an end user
complain.

I've stopped to be open to convincing.

~~~
mprovost
The article did a good job articulating that the "end users" of an init system
aren't sysadmins, they're distro maintainers. If most distros have switched
then it must make things better for them.

~~~
AnthonyMouse
The problem, of course, being that for most init systems the "end users" are
the distro maintainers but for systemd, because it spreads itself into so many
other things, it also impacts the sysadmins and the upstream third party
package developers. Who then complain about it and are met with "it was good
enough for Debian and Fedora" even though they aren't the ones complaining.

------
nine_k
My beef with systemd is not its reinventing things. That part may actually be
good.

One problem is that a number of reinventions were poorly made.

E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we
take some ridiculously well-tested, reliable embedded database or
serialization format (like sqlite) and use it as log storage? Alas.

Another problem is the "I know better" attitude.

Are user processes allowed to run after logout? Which DNS to use during
startup? What logging in should look like? In each such case, existing
behavior which was _widely considered as not broken_ was replaced by a
different behavior, often even without an escape hatch. The new behavior(s) in
such cases should be made possible, but the default should be the old
behavior.

No wonder I don't run systemd on my desktops / laptops.

~~~
sneak
It's astounding to me the issues people have with this. systemd's existence
doesn't preclude anyone from using the old, pre-systemd ways of doing things.
There are thousands of linux distributions, and afaik there are at least a
dozen which are _primarily defined_ as never-using-systemd.

Face it: the linux userspace has always sucked. Linus punted on it way-back-
when (to be fair, he was a solo dev working on a kernel, he had his hands
full) and opted for the gnu tools, but those (other than the compiler and libc
and a few other spots like grep) have never been best-in-class. It was always
just sort of "good enough" to avoid swimming upstream (no pun intended) and
trying to swap them out.

Someone decided to make an attempt at making the situation better in one way,
doing things differently. Perhaps it was a mediocre attempt, even. (I'm just
speaking for sake of discussion here; I haven't read the systemd code, just
making a point.). Still, nobody was forced to use it, and indeed many options
for avoiding it exist.

Somehow, this ended in a holy war and corresponding schism. It makes no sense
to me. Are linux users upset that someone dared question their decades of
suffering under a poorly-designed userspace? Agree or disagree with systemd's
decisions, it's hard to fault someone for making and releasing software and
offering it as an alternative, even if it sucks.

I'm all for experimentation in this space. The old way of doing things was
super janky, and I think systemd is an improvement in a lot of ways. I (thanks
to a lot more time stuck in my house) have two recent Gentoo installs, one
with systemd and one without. They both work, but one works better.

"This is the way we've always done it" seems in opposition to the hacker
ethos, to me. Doing things differently to see if there might be a better way
seems like it's always valuable, considering that nobody's deleting
/etc/init.d/* from your system if you don't participate.

Traditions are not always inherently valuable. Try new things. Discard the
ones that don't work for you.

~~~
novok
Linux types I've noticed tend to be more holy war orientated. Where did the
classic vim vs emacs holy war come from also?

~~~
sjwright
And that was one of the sillier holy wars, since text editors have near-zero
network effects and it's trivial for distros to ship both.

(FWIW I use nano.)

~~~
zeveb
> And that was one of the sillier holy wars, since text editors have near-zero
> network effects and it's trivial for distros to ship both.

Text editors like vi may have near-zero network effects, but operating systems
like emacs and vim have plenty of network effects. If I spend months building
an amazing interface to git in Emacs but my colleague uses vim, our
organisation is hurt.

That's (I think) why people care: they want to collaborate.

> (FWIW I use nano.)

 _boggle_

~~~
sjwright
I’m mostly kidding about nano, I only use that when I have to. My main editor
is HomeSite+ 5.5 running on Windows XP in a virtual machine on my Mac. And I’m
_not kidding._

~~~
sjwright
Oh and by the way it starts faster and uses less RAM than Eclipse. That's
fucked up.

------
ttctciyf
As a somewhat dilettante and casual home sysadmin (currently) I was messing
around with screen on a box downstairs and ran into this:

[https://www.reddit.com/r/programming/comments/4ldewx/systemd...](https://www.reddit.com/r/programming/comments/4ldewx/systemd_kills_screen_and_tmux_by_default_on_logout/)

Namely that systemd doesn't allow persistent processes started from the shell
by default, preferring to terminate them when the user logs out.

This would include processes like "screen" whose entire raison d'etre is to
persist after the user logs out. (Well, it has other uses, but this is the
main one IMO.)

The stated workarounds - fiddling with some options like
"KillUserProcesses=no" in logind.conf &co. - have so far failed.

I don't know whether this situation is a problem with systemd or the distro,
but it seems very much a problem with the culture summarised by the top
commenter in the above thread, of (paraphrasing) _glibly breaking existing
workflows then casually brushing away criticism with arguments often boiling
down to: "this is the right way, I don't care about tradition or protecting
'incorrect' usage."_

~~~
gerdesj
Screen still works. I use it all the time.

Do you have decent examples of it failing to work? If so, then that sounds
like a bug against screen. The link you provide is absolutely huge and from
three years ago.

Please give me a simple "stages to reproduce ..." style report. Please keep it
simple and short and I'll fill in the blanks if I can and only trouble you for
stuff I'm too daft to work out.

~~~
ttctciyf
To answer your question:

remote login, start screen, ctl-A d (detach), log out, log back in, screen -r
(resume) - there is no screen session because it was killed by systemd
immediately after log out.

(syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing
process 3290 (screen) with signal SIGTERM. )

But that's hardly the point, the point is the toxic "you're doing it wrong"
mentality that infests the systemd project and its adherents. I've run into
this in so many ways since ceding defeat and allowing it onto my systems. This
is just the latest in a long line of examples.

~~~
cesarb
> remote login, start screen, ctl-A d (detach), log out, log back in, screen
> -r (resume)

I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and
it worked perfectly fine: after logging back in through ssh, `screen -r`
restored the screen session as expected.

From what I have read, that screen session would only be killed if I had set
KillUserProcesses=yes on /etc/systemd/logind.conf, which is not the default.

~~~
tyingq
It is the default.

 _This behavior is controlled by the KillUserProcesses= setting in
logind.conf, and the previous default of "no" is now changed to "yes"._

[https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...](https://github.com/systemd/systemd/blob/2d4f8cf467b6825c91276808250823a29ab461fe/NEWS#L4356)

~~~
frio
This is one of those fun situations where everyone's right.

The upstream default has changed, but CentOS still uses the old default.

~~~
m45t3r
Almost every distro I know turns this option off by default, including Arch,
NixOS and Debian (the last one I am not sure).

~~~
fsh
It defaults to "no" on Debian 10. Maybe Fedora changed the default?

~~~
Conan_Kudo
Fedora does not have this feature on:
[https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516...](https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516c0e0a13da9ed7613cd0cbfba9e9c/f/systemd.spec#_369)

~~~
dTal
That's most interesting, given that both systemd and Fedora are Red Hat
products. If there's one distro that would use the systemd defaults, I would
expect it to be Fedora. Who exactly are these defaults for, then?

~~~
Conan_Kudo
I've mainly seen it switched on for appliances and things that don't really
have a legacy of this behavior.

It's not switched on in RHEL or Fedora. It's likely to never be so.

------
acdha
I think this really sums this article up:

> One thing I’m certain of is that this shift cannot emerge from dilettantes,
> outsiders and proverbial basement hackers. One does not unseat a platform
> without already being part of the patriciate that calls the shots on what
> gets integrated where across the largest nodes in the ecosystem.

It’s a long, turgid “why wasn’t I consulted?” complaint which really just
comes back to the question of how open-source projects work. An init system is
harder than it might seem at first and requires buy-in from an unusually large
number of parties since it affects the OS, everyone shipping daemons, and the
operators. If you’re not going to invest that level of engineering time, I
don’t see how it’s reasonable to expect an equal voting share with those who
do.

~~~
throw0101a
> _An init system is harder than it might seem at first_ […]

systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the
problem.

It's the tight coupling that annoys many people.

Does _udevd_ really need to be in the same repo? While there may be some nice
things about journald, does it _really_ have to be in the same source package?
(And why can't it support remote logging with the industry standard syslog
protocol? Now I have to run journald and rsyslog. And why doesn't it have an
ACID file format that doesn't self-corrupt at times? Why couldn't they just
use SQLite or OpenLDAP's LMDB?)

What does systemd 245's systemd-homed have to do with an init replacement?

* [https://www.techrepublic.com/article/linux-home-directory-ma...](https://www.techrepublic.com/article/linux-home-directory-management-is-about-to-undergo-major-change/)

~~~
blibble
> So, for the simple act of logging in, three mechanisms are required
> (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has
> decided to make a drastic change. That change is homed. With homed, all
> information will be placed in a cryptographically signed JSON record for
> each user.

10 years ago this would have been considered satire

~~~
kuschku
homed is a purely optional, independent tool, for use in situations where
you’d use roaming home directories on windows, or similar technology.

No one is forcing you to change your broken buggy 30-year old shell scripts,
you can always continue using them.

~~~
throw0101a
> _No one is forcing you to change your broken buggy 30-year old shell
> scripts, you can always continue using them._

How about usernames that start with a digit? Am I still allowed to use those?

* [https://ma.ttias.be/giving-perspective-systemds-usernames-st...](https://ma.ttias.be/giving-perspective-systemds-usernames-start-digit-get-root-privileges-bug/)

~~~
kuschku
POSIX says that any tool should always translate usernames into userids at the
earliest possible point, and pass UIDs to children it spawns.

Now assuming I have a user called 1000 with UID 2000, and a user called 2000
with UID 1000.

Now what do you think is gonna happen if multiple POSIX-compliant tools call
each other?

This is clearly broken, and the reason why BSDs don’t actually implement POSIX
cleanly, instead allowing all their tools to take unambiguous identifiers on
the CLI, with the # prefix to mark a UID, and have all their tools call all
their children with this format.

The POSIX standard is clearly suboptimal here, and the set of valid usernames,
and the set of valid UIDs should never have been allowed to overlap.

~~~
throw0101a
The weblog post has an user called '0day', i.e., "zero day". This breaks
systemd as outlined in the post. This is a WONTFIX per the systemd folks.

~~~
kuschku
That’s one of the possible options, the other would be replacing chown, chmod,
ls, etc (as the BSDs do)

------
ratsmack
>systemd still remains poorly understood and understudied from both a
technical and social level despite paradoxically having disproportionate
levels of attention focused on it.

This statement makes no sense. It is well understood and has been studied and
critiqued by many, including me. Also, I don't know what "social level" has to
do with anything here. It was just created for the commercial aspect of Linux
and forced into the relevant distro's by commercial interests... it's just
that simple.

~~~
xani
Pretty much. If it was just some guys project nobody would give a shit until
it was actually well tested and proven.

But it was made by guy hired by Red Hat so instead of maturing and having to
take actual user feedback before being used in anything significant it was
pushed by a guy that vision is limited to "It works fine on my laptop".

Who then decided to reinvent everything along the way like log storage that
still takes over hundred of file opens (and tens of seconds) to get "the last
5 log lines of a command" (
[https://github.com/systemd/systemd/issues/2460](https://github.com/systemd/systemd/issues/2460)
), because why the fuck use say SQLite when you can have fun evening inventing
your own shitty binary journal format.

I do find a lot of stuff behind systemd useful but the ever-present half-
assness of its solutions is annoying. Half-assed logging here, half-assed dhcp
client there, quarter-assed ntp client elsewhere, all while basic
functionality is still riddled with edge cases.

Still a net positive over having to fix yet another fucked up init script...

~~~
Spivak
This has not been my experience at all. The systemd project seems to take
extreme care to adhere to the spec when implementing features. They don’t
adhere to “this is how it used to work” which is where the bulk of the issue
seems to be. The big controversy was when systemd-resolved implemented the
spec to the letter and broke people’s assumption that listing DNS servers in
order means they’ll be queried in that order.

~~~
wtallis
> The systemd project seems to take extreme care to adhere to the spec when
> implementing features. They don’t adhere to “this is how it used to work”
> which is where the bulk of the issue seems to be.

Really, the issue here is that "how it used to work" is mostly unambiguous,
but I have no clue what you mean by "the spec", and I suspect you're actually
referring to a multitude of specs, several of which were only created in the
process of writing the relevant systemd components.

------
zozbot234
Systemd is an amazingly clear example of the second-system effect, as
described in _The Mythical Man Month_. I fully expect it to be replaced down
the line by something dramatically simpler and more intuitive, but that might
take some time. Nonetheless, it does seem to solve some real problems with the
earlier, rc-scripts approach.

~~~
0zymandiass
It's dramatically simpler and more intuitive than what it replaced, so I'm
super excited when someone comes up with something even better!

~~~
rleigh
> It's dramatically simpler and more intuitive than what it replaced

I hope you're being deeply ironic.

It's several orders of magnitude more complex. It's more difficult to
understand and reason about because its internal state is a black box, and the
number of interfaces and file formats to understand is again orders of
magnitude more complex.

sysvinit had a socket interface with a single message type. It had a single
and very simple configuration file (inittab). Everything else was delegated to
higher levels. Simple, flexible, and extensible. But above all, understandable
in its entirety, and completely predictable.

~~~
jcelerier
> It's several orders of magnitude more complex. It's more difficult to
> understand and reason about because its internal state is a black box, and
> the number of interfaces and file formats to understand is again orders of
> magnitude more complex.

As a user I 100% disagree. Before systemd I had to learn a few dozen of
different config formats for various things * various distros, now all my
systems are configured in a reliable & simple way, for init, network, timers,
etc etc

~~~
rleigh
You're not disagreeing with anything I said. You're making a completely
different point.

systemd might be more _convenient_ from the point of view of an end user. And
unit files might seem _superficially simpler_ than a script.

But systemd is not simpler. It provides significantly more complexity, while
also providing a lot of features.

systemd is also not more reliable. The previous system, even with LSB
dependencies, was usually run in a linear mode with scripts run in a strict
sequence. System boot and service startup was deterministic.

If you read the part of the linked article about the sheer quantity and
complexity of the internal state managed by systemd, and how it is not
deterministic, or even fully understandable even by its authors due to the
combinatorial complexity of all the options and how the same settings work
differently in different contexts, I'm afraid that I can't do anything further
to convince you about the significant design problems it has which directly
impact its reliability. Never had it hang irrecoverably at boot, for no
discernible reason?

There is a reason people such as myself are appalled by its design. It doesn't
even have a comprehensive specification for such a critical piece of
functionality. It's defined solely by a single implementation.

The systemd state is a massive hairball. It's effectively a black box, and
understanding why the system exhibits certain behaviours is difficult.

The sysvinit state consists of a current runlevel and the state associated
with inittab tasks, which is pretty trivial. It doesn't attempt to maintain a
mirror image of the state of the whole system, which is largely a constructed
fiction.

~~~
esarbe
Systemd is not only more convenient, it's also more simple.

Proof? sysvinit's surface is anything you can call. It's internal state is
everything on the system.

Systemd's surface is the (well documented) commands in the systemd unit files.
Each unit is pretty much independent, the dependencies are specified and well
defined. Their internal state can be examined and explored.

------
k_bx
Can I just say, from a non-sysadmin perspective, how happy am I that these
days I don't have to install something like Supervisord and just use the
systemd + journald toolchain. Setup script is just one cp and few systemctl
commands (start/stop/enable).

~~~
dijit
Yeah, that's nice.

I think there's a lot of people who get caught up in the merits of systemd and
assume that there's nothing better. Or that the alternative is the old
sysvinit which was in dire need of being replaced- but that's not true.

Process supervision is totally feasible in init (just look at runit, Solaris'
SMF and MacOS's launchd) even Windows has one.

------
dvfjsdhgfv
A key quote:

> As it turns out, there was a little-known Freedesktop-affiliated project
> called xdg-hostname in 2009 which was a start towards creating such D-Bus
> “utility daemons” for use in desktop widgets and others, all as a standalone
> project. Had this been followed through instead of having the utility
> daemons end up being part of the systemd source tree, a good deal of
> political acrimony could have been avoided – though at the cost of reducing
> systemd’s leverage.

That is, if they used xdg-hostname instead, SystemD wouldn't be tightly
coupled with Gnome, so users could choose between SystemD and InitV, and all
this mess could have been avoided.

------
reacharavindh
God I wish more people used VoidLinux and packaged more and more stuff without
needing Systemd. Systemd may be good for some, bad for some. But, it certainly
should not be the only way to get things done. We need alternatives.

It’s as if web developers were told now that there is IE, that is prevalent,
we can write web apps that only work there ;-)

------
keymone
One thing I’m surprised about in the init wars of past decade(s?) is that in
almost half a century of Unix nobody got up and said “why don’t we, instead of
bickering about implementation details, come up with single format to
_declare_ desired system startup behavior, and then users can pick whichever
implementation they like to read and execute that format”?

Can’t be impossible to distill some basics about service startup configuration
and dependencies, can it?

Then make it extensible and cry about differences in extension support like we
do about per-browser css options, but at least converge on some basics.

------
gjvc
If you don't like something, put your energy into implementing it the way you
do. With any luck, the ensuing distraction will be more effective at weakening
the original than simply complaining about it.

~~~
Karunamon
Sadly, systemd has corporate backing, which is a very hard fight to win for a
ragtag bunch of nerds with dayjobs who have the completely unreasonable
expectation of _not having their shit broken_ , regardless of how much energy
we have. Money and full-time devs beats energy every day of the week.

~~~
gjvc
My point was that there is nothing (no competing implementation) to be judged
against, so it rather wins _de facto_.

~~~
dijit
This is like declaring McDonalds burgers the best because small burger joints
can't offer Burgers _and also_ ice creams, salads, chicken and toys for
children.

If we're talking about init; there are actually better inits already available
but you'll never hear about them (runit, for instance) precisely because you
don't just leave systemd.

You leave the systemd ecosystem.

This is the main point of the article: systemd as a "job system" is actually
quite bad, but the ecosystem has some value in some places and you have to buy
the shit with the pig.

------
nyanpasu64
I don't fully understand systemd, but the technical critique looks interesting
and seems to indicate systemd is poorly designed (but I don't understand it
all). Anyone else commenting on that?

~~~
JdeBP
Enjoy
[https://blog.darknedgy.net/technology/2015/10/11/0/](https://blog.darknedgy.net/technology/2015/10/11/0/)
, by the same author.

------
bandrami
10 years ago I never had shutdowns hang with "Stop job waiting for PID 10834:
30 seconds... 90 seconds..."

I do now. Regressions are a bad thing.

------
whereistimbo
vezzy-fnord! I have always enjoyed your commentary and perspective of
operating system, it's nice to see you back again!

~~~
vezzy-fnord
> it's nice to see you back again!

Not for long, probably. I drifted out of this sphere years ago, and came back
specifically for systemd's 10 year anniversary, as I felt obligated to at
least do that.

Judging by the tone of the comments, 10 years later is still too soon to
discuss systemd dispassionately, but when I come back in 10 more years I'll
see if things have changed.

~~~
majewsky
Honest question: Which relevant technology is ever discussed dispassionately?

~~~
vezzy-fnord
If we can't ever perfectly adhere to an ideal, then I guess we ought to go
full on with the connivery and deceit, then.

Regardless, I did have at least some expectation that people would actually
focus on the original post and not brawl in the comment section over tangents
that often aren't even part of it.

Oh, well. And hey, if other people down the road read this and it makes
something click for them, I'll be happy with that.

~~~
btrask
Thank you for the article! It's too bad that your conclusion, that systemd
doesn't/shouldn't matter, wasn't able to be grasped by the community.

------
AndrewStephens
I do really appreciate this type of long form, researched blog post. I have no
strong opinions on systemd, I've made simple service units and it has worked
well enough. Having the history behind the design is a great aid to
understanding.

~~~
JdeBP
Then you will probably enjoy these:

* [https://blog.darknedgy.net/technology/2015/10/11/0/](https://blog.darknedgy.net/technology/2015/10/11/0/)

* [https://blog.darknedgy.net/technology/2015/09/05/0/](https://blog.darknedgy.net/technology/2015/09/05/0/)

* [https://blog.darknedgy.net/technology/2016/01/01/0/](https://blog.darknedgy.net/technology/2016/01/01/0/)

* [https://blog.afoolishmanifesto.com/tags/supervisors/](https://blog.afoolishmanifesto.com/tags/supervisors/)

------
noitpmeder
My worst gripe with systemd is that I cannot find reliable docs for older
versions.

~~~
fsh
Your manpages should match the installed version.

------
Koshkin
My biggest gripe with it is that its name is not ‘sysd.’

------
lidHanteyk
The author sounds distressingly prescient with their prediction that BPF will
be the next venue for this sort of farce.

------
meddlepal
Oh good, the monthly HN systemd 5 minute hate is upon us once again.

~~~
gjvc
It's worth considering why the topic makes such a regular appearance. I
suggest it might be because that so many users of this website find it to be a
remarkable example of not only how something so widely unpopular can become so
widely established, but also being something that they have to contend with
frequently.

~~~
sneak
It would appear from distribution adoption that systemd is a lot more popular
than it is unpopular.

~~~
dralley
One of the reasons distributions appreciate systemd because systemd unit files
are easy to write and can easily be written and maintained upstream and used
with very few if any modifications downstream.

Your average HN user doesn't see or particularly care that it makes things
easier for distro maintainers, so it's much easier to push the corporate
conspiracy angle than to accept that a lot of the hand-wringing takes huge
amounts not-very-fun volunteer labor for granted.

~~~
rleigh
This is one thing which is often claimed, but to my mind is poorly justified.

As a (Debian) package maintainer for over a decade, this used to be a non-
issue. They were write and forget. The average package was just some simple
boilerplate.

~~~
esarbe
I love not having to maintain half a dozen init scripts for three
distributions but just one unit file for a well defined service manager.

------
bepvte
Interesting comparisons of a GNOME volunteer to Stalin. Also found it very
interesting that the author put inclusivity in quotes.

~~~
vezzy-fnord
Oh, but it is a good comparison.

Many people have compared free software to communism. I always used to dismiss
it. But, in a way, they were right. Both are movements with a self-conceited
historicist endeavor to eliminate exploiting classes ('it is inevitable that
the tendency for the rate of profit to fall to produce immiseration as
capitalists can no longer profitably invest, leading to a proletarian seizure
of power' versus 'it is inevitable that proprietary walled garden development
models stagnate as they're overtaken by decentralized communities pooling
their knowledge and labor into the most optimal end' and create a perfectly
equitable free association of producers no longer having their surplus value
be seized by exploiters.

One degenerates into a repressive bureaucratic collectivist (I'm not a
Trotskyist, but it's a good term) mechanism for reproducing surplus through
either direct requisition or coercive planning. The other degenerates into a
way for large-scale cloud providers to appropriate the free labor of
volunteers so as to reinvest it back in their walled gardens.

Stalin represented the Leninist wing against ultra-leftists, anarchists and
other factions who were against tight top-down organization in favor of
'spontaneous' organizing, and the GNOME/Freedesktop/Red Hat nexus is against
the faction in free software that insists on a loosely coordinated and loosely
coupled bazaar without a central vision. But in no sense has systemd abolished
this, it has only reduced a few nodes at best.

EDIT: Actually I should point out that 'free software' per se is a
deontological argument, and it's 'open source' specifically which specifically
uses these historicist arguments to justify itself. But then open source was
unabashedly an effort for corporate sanitization of free software, which most
people forgot after it mostly crowded out 'free software.'

------
Stierlitz
TLDR: down with sYstemd :]

------
nn3
The dependency problems he's describing sound like they could be relatively
easily fixed with some new systemd keywords?

Of course it would take some time to migrate existing unit files.

It doesn't sound like a fundamental critique. Would be nice to turn this into
a constructive proposal to fix systemd.

~~~
kelnos
It feels like a lot of the existing keywords were added in order to paper over
previously-discovered dependency issues. And the result has been a) confusion,
and b) more dependency issues. I don't think adding more is going to help the
matter.

------
arh68
PulseAudio is the _only_ program I've seen really stress my Ryzen. I recommend
fixing the default sampling config if you have similar issues.

This is a really entertaining writeup, given the subject matter.

------
aganame
I wish systemd haters would make a public petition to remove systemd from this
world. I would absolutely use such a list to make sure I never accidentally
hire any one of them for any system administration positions.

~~~
dman
As a person who does not work as a system administrator professionally but
does use self administered linux machines as workstations systemd has not
brought any new productivity gains but it sure has increased the learning
curve.

~~~
aganame
As a person for whom Linux and BSDs have been a hobby since 1996, I have no
idea what you're talking about.

~~~
tux1968
One small example that i've struggled with is logging. It used to be I could
reuse my _editor_ knowledge to search and read log files. Now every time I
want to look at a log I have to re-read the man pages to figure out the proper
incantation.

~~~
aganame
Learning new tricks gets harder when we get older. Is that the software’s
fault?

~~~
dijit
You could make several arguments here, but they're all small until you
aggregate them.

1) Breaking working systems should be dissuaded, especially when it comes to
human interaction. There's a reason that Microsoft still has a start menu and
"File/Edit" menu's

2) There is a certain level of arrogance to the notion that a developer of
core infrastructure for literally millions of users can just change things and
expect everyone to fall in line without giving credible reason for people to
do that.

3) Adding an additional tool to everyones cognitive load should be done with
care and delicacy, as it stood there was one set of tools for _all_ file
accesses, and there is now a new one.

PS; on a personal note, I'm glad I do not work with you, I find your attitude
in the grandparent comment deplorable.

~~~
aganame
Yeah, you’re right. I was exaggerating for some reason I don’t recall anymore,
a bad day perhaps, too much or too little coffee or something. Who knows.

Of course I don’t discriminate at hiring time against people who disagree with
me on such a trivial technical detail. Or hunt for them so I can maintain
secret lists of undesirables. That would be unethical, probably illegal, and
definitely stupid.

