
Why Did ArchLinux Embrace Systemd? (2016) - kbumsik
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/
======
darkwater
Looking back, I still don't get all the hatred that SystemD got (and sometimes
is still getting). A part from some nice-to-have missing niche features (I'm
looking at you, retries management with one-shots), it Just Works™ for the
vast majority of use cases, just like PulseAudio does. The fact is that the
minority which indeed have problems is very vocal because those problems come
from complex corner-cases that only a a very tech-savvy user could generate in
the first place.

~~~
megous
Until it doesn't.

Until very recently having wrong permission on one of the networkd config
files would result in networkd ignoring the rest of the perfectly readable
network configuration files too, cutting off all network connectivity.
(Systemd also requested the permission change iself.)

Currently there's a bug where if you have a bridge and all interfaces are
disconnected from the bridge (I use hot-pluggable USB network interfaces) when
you re-connect them, networkd will keep the bridge off. If you restart
systemd-networkd it will fix itself.

I can name at least two instances already where I lost networking in my entire
SBC farm, and had to pop out all microSD cards and fix the breakage manually,
just because of systemd-networkd bugs. And I don't do anything crazy, just a
single ethernet interface and two overlay wireguard networks, and mostly
default config.

And fixing it yourself is not easy. I can do C coding perfectly fine, but I
run 3 different CPU archs, so fixing it myself means compiling (3 times) and
distributing my own systemd version to all my machines until upstream fixes
the bug. It's not pleasant, nor easy.

I certainly understand people who miss having an ability to more readily
script the system startup/network config.

~~~
megous
I'd like something like systemd, but with all high-level internals written in
a embedded scripting language.

~~~
bitwize
Might want to look into GNU Shepherd. The whole thing is written in Scheme.

~~~
megous
It seems to have a very limited scope of just managing services. I sort of
like that systemd is more tightly integrated with Linux and for example
listens on netlink for network changes, or device hotplug events, or on input
events for (power) button events, and allows to reconfigure the system based
on changes dynamically, etc.

~~~
michaelmrose
Maybe someone should extend shepherd.

------
bflesch
I wish this kind of opinion would've been spread more widely within the Arch
universe (wiki / IRC) so outsiders can understand what we actually gained from
switching to systemd.

It still feels like many people hate systemd but the reasons that are
presented all sound totally valid from a programmers' perspective.

~~~
aidenn0
These reasons are valid; I think the main reason so many people hate systemd
is how all-encompasing it has become.

Prior to systemd, the lack of a standard init/rc/service monitoring system
meant that you could pick and choose 3 different solutions for those 3
problems. systemd is pushing for unifying not just those 3, but other systems
too (gummiboot, consolekit, udev). As more software becomes designed to work
just with the systemd ecosystem, more people who have love for one of the
systems that has been subsumed will feel forced to switch.

Say you have a favorite fork. You eat lunch with it everyday. Now at your
favorite restaurant for takeout, the manager says "We switched salad
dressings, and the new dressing line isn't compatible with that fork, you'll
need to use this one instead." The fork that the manager hands you may be
perfectly fine (better in some ways, worse in others than your favorite fork),
but it's not _your_ fork. So you sadly stop going to that restaurant. But then
you notice something: more and more restaurants are switching salad dressing
suppliers, so now you have to either give up your favorite fork, or use only
salads you make yourself. You're probably going to be mad at the salad
dressing company.

~~~
cwyers
Yeah, it's two sides talking past each other, with very different conceptions
of what Linux should be. The systemd detractors tend to view Linux as sort of
a grab bag where you can make a nigh infinite number of operating systems, all
loosely compatible with each other. The systemd people view that as way too
much stuff to test and support.

------
valeg
I prefer this approach:

> _Systemd is included by default but not enabled. You can scan your MX system
> and discover files bearing "systemd" names, but those simply provide a
> compatibility hook/entrypoint when needed._

> _MX Linux uses systemd-shim, which emulates the systemd functions that are
> required to run the helpers without actually using the init service. This
> means that SvsVinit remains the default init yet MX Linux can use Debian
> packages that have systemd dependencies such as CUPS. This approach also
> allows the user to retain the ability to choose his /her preferred init._

Source: [https://mxlinux.org/about-us/](https://mxlinux.org/about-us/)

~~~
znpy
> MX Linux is a cooperative venture between the antiX and former MEPIS
> communities

Ah! SimplyMEPIS (a live version of MEPIS) was the first gnu/linux system I
booted on my (dad's) P3 desktop computer in circa 2003-2004!

------
KingMachiavelli
> What most systemd critics consider "bloat", I consider necessary complexity
> to solve a complex problem generically.

As a distro and philosophy, Archlinux was bound to adopt systemd eventually.
e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom
init file to adapt 90% of software from systemd to another init system is not
KISS.

~~~
djsumdog
Gentoo, Alpine and Void still default to using their own init systems.

~~~
MuffinFlavored
It seems Alpine uses Gentoo's OpenRC init system from a quick Google.

[https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System](https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System)

[https://wiki.gentoo.org/wiki/OpenRC](https://wiki.gentoo.org/wiki/OpenRC)

------
peterwwillis
From the thread, 2brainz, the person maintaining the init scripts, responding
to why systemd:

 _> > I haven't heard a good explanation of why systemd and not a different,
new init system_

 _> There is none. Systemd came along, we thought it was great, some of us
were already involved with systemd and pushed the change. We could have done
many different things, but we didn't._

 _> Runit was suggested by users at some point, and I think there is/was a
runit implementation in AUR. However, runit was never considered in detail._

 _> First, we don't know if the other systems were really alternatives (at
least I don't know). The answer is boring: Systemd solved many problems, it
was there, it worked and we already used many of its tools in our initscripts
at the time. There is no specific reason why we did not use $WHATEVER over
systemd._

 _> About launchd: it was never considered. As I said elsewhere, systemd
seemed to do what we want and we went with it._

------
djsumdog
After listening to the BSD Canada talk on systemd and BSD, I agree Linux does
benefit from a system layer. But I still hate the implementation, and you
can't easily swap out stuff.

I really like logrotate and syslog and not needing journalctl for stdout/err
logs from services. It's one of the things that makes working with Docker
containers so much nicer too, because you have sane commands to get logs for
services; way easier than remember all the weird switches for journalctl.

I like NetworkManager (this still hasn't been replaced in systemd, right?)

I still use OpenRC and Runit on Gentoo/Void respectively. OpenRC does
dependency management but runit not so much. When it comes to building out VMs
and stuff, I see the use of systemd for mount targets, but like I said
earlier, I really hate the implementation in target files. It's so hard to
make drop-in replacements for systemd that can run the same target files
because of just how far it goes into the system.

For VMs at this point, I honestly prefer minimal startup and running
everything in Docker. Alpine or RancherOS seem to fit this bill nicely. If
FreeBSD had a current Docker API implementation, it would be perfect.

For my desktop, I prefer OpenRC or runit. It's just easier to do things and
I'm not fighting with the system layer like I am in Windows. Then again I use
i3 and prefer to have more control over my hardware, so that's just my use
case I suppose.

~~~
kbumsik
> After listening to the BSD Canada talk on systemd and BSD

For someone who don't know, here is the video "The tragedy of systemd". This
is a really good talk.

[https://youtu.be/6AeWu1fZ7bY](https://youtu.be/6AeWu1fZ7bY)

~~~
dijit
All respect to the author of that talk.. but "just get over it" and "embrace
change" is not compelling to those who have very searing issues with systemd.

I do not consider this to be a good talk because it paints dissenters as "not
embracing change" because.. they are stupid?

It also makes the argument that the only thing that exists outside of systemd
is sysvinit.

He also seeks to make Lennart a martyr because of death threats. (which, btw,
seriously it shouldn't even be said that that is unacceptable, some people are
fucked up).

Oh, and systemd definitely didn't invent cgroups, an engineer at google did
and they don't even use systemd to run GCP compute hypervisors.

Benno so thoroughly misrepresents those that have issues with systemd that I
can't help but feel it was intentional.

~~~
djsumdog
I didn't get that from his talk. I think it was more of a, "BSD should have a
system layer. How can we make one that's way better?" .. that doesn't do all
the things people hate systemd for doing.

~~~
dijit
oooooo, the grandparents video is very different in tone than the version I
watched, which is the same talk:
[https://www.youtube.com/watch?v=o_AIw9bGogo](https://www.youtube.com/watch?v=o_AIw9bGogo)

I'm sorry, I had assumed I had seen the exact video, but I had just seen the
talk from another venue.

------
axaxs
I don't particularly care for Systemd, just out of principle, but I don't mind
using it. Personally, I feel Arch Linux went downhill after Judd left. Maybe
I'm naive, but I absolutely loved Arch's 'rc.conf', which was basically an
entire system config in one file. That going away, and the adoption of
Systemd, really made it feel like a different distro. Not better or worse,
mind you, just different.

~~~
DenseComet
Take a look at NixOS, the entire OS is declarativily defined and can be stored
in git.

------
oauea
Meanwhile [http://without-systemd.org/](http://without-systemd.org/) (linked
from the post) throws database errors. Maybe they forgot to 'enable' their
mysql systemd service?

~~~
cipherboy
I don't think so. It has been a while since I've done PHP but that reads like
an inclue-gone-missing (likely with MySQL connection configuration
information) causing the database to fail rather than MySQL breaking the
include.

------
ddevault
I think very few people criticise systemd for its init system, which is pretty
decent as far as init systems go. The main complaint is _everything else_
systemd does. It's trying to swallow the universe and there seems to be no
limits to where its "scope" will end.

------
combatentropy
I would like to know what Arch Linux and the other distros thought of
alternatives like runit, openrc, and BSD-style init.

I can at least sympathize with the arguments for systemd if the only other
choice was SysV init scripts. As Richard Gooch once said, "These boot scripts,
in the tradition of SysV, can do anything. They are flexible. They are
scalable. They can run industrial-strength systems. Unfortunately, they're
bloated and ugly. OK, maybe they're not ugly to everyone (not that I've ever
heard anyone admit they're elegant, only 'it works'), but they sure are
bloated. They are complex and hard to navigate." ([http://www.safe-
mbox.com/~rgooch/linux/boot-scripts/](http://www.safe-
mbox.com/~rgooch/linux/boot-scripts/))

But the choice was never just between SysV init or systemd. Couldn't Linux
have done something like FreeBSD's rc? Or I read about the daemontools family
of init systems, like runit, which is what Void Linux uses. These systems
sound like they solved SysV's problems without adding systemd's. That is, they
are more declarative, easier to maintain, can handle complex dependencies, and
can run things in parallel. But they remained unixy: they are small, file-
oriented, and don't swallow up adjacent software.

------
upofadown
This is a very good point. The reason that you have trouble if you just use a
bunch of scripts to start up a contemporary Linux is that the underlying
system has become quite complex. Now you have to deal with the effects of
stuff like udev and dbus. Systemd can be seen as an attempt to paper over the
underlying complexity problem with another layer on top. That of course if not
likely to work but is depressingly common in the world of OSs. People add
things to a simple system until it is no longer a simple system. Eventually it
becomes unreliable enough that no one dares extend it further.

As a nice counterexample, OpenBSD doesn't have stuff like udev or dbus usage
during boot. The rc.d system they use is literally just a bunch of scripts and
is dead simple and reliable.

------
bitwize
Ah, systemd. It's one of those things where I'm glad it exists, but I hate it.
I'm glad it exists because more open source is good, and diversity of
implementations is good. I hate it because it complicates my machine's startup
process, and my life, unnecessarily, and puts a lot of shit in pid 1 that
shouldn't be there. I don't want it to become a hard dependency of my entire
software stack. (Same with PulseAudio, hence why I am not currently a Firefox
user.)

I left Arch after the systemd transition and didn't look back, but I wish Arch
devs and users well.

~~~
mos_basik
As someone who's been slowly picking their way along the narrow crooked path
towards free software / tinfoilhattery / unixbeardedness for the past several
years, I'm interested to know which browser you use.

I assume given context that Safari and IE are right out. Chromium and variants
are probably out? If Firefox and variants are out (not sure if all of them
have the pulse dependency, because honestly your comment was the first time I
learned about it - probably because I'm using Arch), what's left? Qutebrowser?
Konqueror?

I guess implicit in the above is an assumption of certain (non-basic)
functionality that many people would consider table stakes in a web browser.
Given that choosing to use any software involves making certain compromises
(like "if you don't use Chrome, some Google applications will likely not
perform as well") I guess my underlying desire is to know which compromises
you _are_ willing to make, given that you _aren 't_ willing to compromise your
desire to keep pulseaudio off your machine in order to be able to use Firefox.

On a scale I'm having trouble naming but that goes from about 1 ("my son
bought me this iPad so I can see my grandchildren on Facebook") to 10 ("I wget
webpages to my server then email them to my Trisquel laptop") your
pulse/firefox constraint seems to me to be solidly in the upper half, which I
respect, but which also makes me expect you are willing to accept compromises
that I'm not (yet) in choosing a browser. Maybe I'm wrong, though, because
there's a lot of browsers on this chart:
[https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Ti...](https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Timeline_of_web_browsers.svg/3560px-
Timeline_of_web_browsers.svg.png)

~~~
bitwize
Currently? PaleMoon. It doesn't have a Pulse dependency and it works with
every site I throw at it. We'll see if that holds up.

~~~
michaelmrose
Throwing out pulse after it was pretty much made to work consistently well
seems poorly thought out as does running Palemoon.

[https://www.howtogeek.com/335712/update-why-you-shouldnt-
use...](https://www.howtogeek.com/335712/update-why-you-shouldnt-use-waterfox-
pale-moon-or-basilisk/)

------
dijit
Ah, I'm going to lose karma here because I'm a sysadmin and not a programmer
and programmers seem to really like systemd, and this forum is represented
strongly by programmers.

Regardless, every time these types of threads come about I feel like I _have_
to speak because there's a lot of bitterly divided people regarding this
issue. (or, rather the people who are bitterly opposed and the people who
don't care, think systemd is a net good in the vast majority of cases or those
who think the backlash is very much unwarranted).

I'd like to say first off: SystemD solves real problems that nothing before it
was solving, maybe it doesn't solve those issues in the way I personally like,
but it definitely does and was one of the first to do so- so for this reason
the original maintainers should be warranted respect, it's also a given that
it's not the developers fault that this is so widely adopted or even forced. I
see them as problem solvers first and foremost so any gripes I have with
systemd as a thing which is foisted upon me is definitely not on them.

However, I do consider that systemd as a new -layer- between user land and
kernel space (called "system space" by Poettering) necessitates a lot of
breaking changes. I do not consider this by itself as a bad thing, but having
a poorly defined interface for these things does not enable systemd to be
replaced without some form of "systemd-esque" emulation in future.

Thus while we have improved from where we were, we do not have fertile ground
to improve in the future.

Additionally; SystemD as a "modular" system is, in my opinion, a myth; even if
you take for granted the fact that systemd+journald are the only core
dependencies, you then quickly start to drag in more and more rapidly (udev
and systemd-resolved being famous examples).

Some design paradigms are scary, for instance socket activation leaves PID1
listening for traffic on the network, by default bound to all interfaces. (a
good example is to look at cockpit) this could be a very large footgun if
there exists any form of exploit in systemd.. and since systemd is not written
in a memory safe language, and the overwhelming majority of security bugs are
memory safety bugs... this is mildly concerning.

There are other concerns regarding opacity of the dependency system, the fact
that no-two-boots are the same and thus some race conditions are likely to
never be solved by me. (a lowly sysadmin type who only knows enough C to make
linked lists). The design very much reminds me of Microsoft Windows in many
ways, but perhaps that was a good design to choose from?

FWIW: SystemD is amazing on my laptop, I am really happy with it. But for my
servers I am very unhappy with it, but the major distributions chose to use
systemd and I'm a sysadmin so I'm beholden to what the company considers
stable and developers.

I very much begrudge the fact that I'm not allowed to have a dissenting
opinion on this.

I also hate that when people talk about systemd vs "anything", invariably
people assume I am talking about openRC or sysvinit, but there are much better
init systems available today, such as Runit.

SystemD is not a panacea, it should leave fertile ground for replacement. If
that cannot be done it should not be adopted because that is a scary amount of
lock-in.

~~~
tracker1
I'm mixed on this... as a developer I just want something that works, has
decent interfaces and abstracts away so I can care a lot less about it.
SystemD does most of this for me.

Also, echoed in another comment, I'd just assume use Docker and/or K8s and/or
dokku for most of the services I write anyway. Frankly, I care about writing
the applications and services that solve problems for me, I don't want to
spend as much time on system administration or CI/CD infrastructure as I
already to.

In the end, it does a better job at most of the problem space in most ways
compared to the alternatives. I have to google for it any time I actually
interact with it anyway, which is what I did with older initd systems, so I'm
not really that enthusiastic one way or the other.

~~~
dijit
> as a developer I just want something that works, has decent interfaces and
> abstracts away so I can care a lot less about it.

As a sysadmin, I want something to be debuggable because I'm the one who gets
paged when the failure rates increase.

~~~
geggam
On to microservices with you and give the developer the pager!

Embrace the change :)

~~~
tracker1
I always say, "Give me a platform that works, or the power to fix it, I don't
care which." I'd prefer something that works I don't have to take care of...
but when under the gun and IT has other priorities, it sucks.

------
megous
I agree with an event driven supervisor daemon architecture, and that shell
scripts are inefficient.

But writing everything in C in non-scriptable way may be a bit of over-
reaction to the old ways of having everything scripted in the least efficient
way possible.

I also write my init systems in C (not for generic Linux distro, mostly for
embedded HW/mobile use), but I'm planning to make it so that I have a program
in C that offers some primitives and the core logic will be implemented using
an embedded JS engine, so that it's scriptable and fixable without re-
compilation.

------
Mathnerd314
(2016)

