
Linux distros without systemd - telmich
https://ungleich.ch/en-us/cms/blog/2019/05/20/linux-distros-without-systemd/
======
AsyncAwait
I get that not everybody likes systemd, but a lot of the criticisms seem
misguided and looking at sysvinit with role-colored glasses.

For example, people are complaining about logind being included, but forget
that consolekit was unmaintained before that. Yes, there's parts to systemd
that not everyone will use, like container support, but in that case you can
pretty safely ignore that use case.

For me, systemd has provided a much more consistent way of managing services.
There's a tightly defined service definition format that allows one to
comfortably modify any 3rd party service as well, (unlike random, variable-
quality shell scripts), relatively small amount of commands to learn that work
consistently across services, mounts, timers etc. There's also much better
handling of modern hardware, hotplugging & the like.

I can't say I miss sysvinit. Also, stuff like [1] from the anti-systemd camp
doesn't inspire confidence.

1 - [https://lwn.net/Articles/786593](https://lwn.net/Articles/786593)

~~~
brobdingnagians
Most of the problem I have it is with the imperialistic culture that came with
it and with the serious security bugs that they keep sweeping under the rug.

It is easier to configure and is convenient to have one holistic system in a
lot of ways, but...

They pushed for Gnome to have a hard dependency on it so that everyone would
be _forced_ to use it instead of just letting it be accepted by merits.

They have a track record of labeling serious bugs as non-issues, ignoring
them, or just not filing them as CVEs. Serious issues keep coming up.

I don't think the code is high-quality, but even more than that I have a
problem with the people being controlling, dismissive, and deceptive.

~~~
natermer
> Most of the problem I have it is with the imperialistic culture that came
> with it and with the serious security bugs that they keep sweeping under the
> rug.

The 'Imperialistic Culture' you speak of is one of those made-up things that
systemd haters keep repeating, but has no basis in reality.

> They pushed for Gnome to have a hard dependency on it so that everyone would
> be _forced_ to use it instead of just letting it be accepted by merits.

Again, another fairy tail.

> They have a track record of labeling serious bugs as non-issues, ignoring
> them, or just not filing them as CVEs. Serious issues keep coming up.

A) This is par for the course in Linux software. See also: Linux kernel. One
side you have is a bunch of security bros running around trying to fluff up
their resumes and trying to turn themselves into heros. And on the other side
you have devs working hard on various features and bugs and being resentful
that most of their work goes unnoticed while stuff they already fixed is
thrown back in their face.

B) Many of the bugs that make it onto Reddit/Hacker news are going to be ones
that are largely changes in configuration defaults or behaviors that break
things and are meant to be configured by the operating system designers that
use it, not end users.

C) This level of scrutiny never existed before for low-level Linux features.
The multitude of redundent and terrible shell scripts that made up the
majority of functionality that systemd project seeks to replace was always a
swampy mess of broken functionality and bad code. Having each and every major
linux distribution rewriting 90% of it from scratch in a completely un-
portable and estoric way didn't help matters.

Linux advocates actually went so far as to praising the fact that even though
half of the scripts in their OS were completely broken and the OS still worked
fine was a testament to it's robustness.

The fact that now, finally, after decades of this crap people can now track
bugs related to low-level Linux userland 'plumbing' is actually a good thing.

> It is easier to configure and is convenient to have one holistic system in a
> lot of ways, but...

On the sysvinit side you had thousands and thousands of lines bunch of
procedural code of dubious quality that is endlessly rewritten by hundreds of
different teams with vastly differing levels of competency and success using a
general purpose language for configuration. It was so unportable that you
couldn't even use anything but the most basic and trivial (also broken) init
scripts from one distribution to another without herculean levels of effort.

On the other side you have a even driven OS configuration and management
engine that allows people to describe the state they want the OS to be in via
a domain specific configuration language. It has managed to standardize the
low level plumbing for Linux operating systems and allows distributions to
share improvements with one another in a way that was previously impossible.

If people want a alternative to gain in popularity they need learn what
systemd does and understand why Linux distribution makers switched to it. Then
produce something of their own that takes those positive features and improves
on it further.

All the hand waiving about 'Imperialism via releasing open source software to
the public' is infantile.

The upside of all of this is that it's going to be a hell of a lot easier to
make systemd unit files portable then it is to make Linux init shell scripts.
There isn't any reason why a more capable init system wouldn't be able to
parse existing unit files and know then how to start and manage the services
and applications that use them... So the effort to move away from systemd
should be significantly less then the effort to move to systemd.

~~~
boomlinde
_> Many of the bugs that make it onto Reddit/Hacker news are going to be ones
that are largely changes in configuration defaults or behaviors that break
things and are meant to be configured by the operating system designers that
use it, not end users._

Maybe it's not for systemd to decide what I'm meant to do. If changes to
behavior that they only meant for operating system maintainers to rely on
results in angry end-users, they probably made the wrong assumption.

 _> On the sysvinit side you had thousands and thousands of lines bunch of
procedural code of dubious quality that is endlessly rewritten by hundreds of
different teams with vastly differing levels of competency and success using a
general purpose language for configuration._

Meanwhile, I have ~400 LOC of init scripts (including service scripts) on my
daily driver, an init system with <1% the LOC of systemd, and plain text
readable system logs. I agree that hand waving about "imperialism" isn't very
constructive, but on the other hand I don't think that misrepresenting the
alternatives to systemd and exaggerating their faults is particularly useful
either, nor is pretending that sysvinit is the only alternative. A lot of
people have thought "sysvinit sucks" and done something about it.

~~~
mediocrejoker
Are your init scripts available for viewing anywhere?

------
markstos
I read everything I could find on systemd to form my own opinion. I used
FreeBSD for a decade and have many years of Ubuntu/upstart experience after
that.

Based on my experience and all the anti-systemd posts online, I expected to
dislike it.

But on it's merits I really like the consistency it brings to the "system
layer" of the OS.

I find it's shame when developers skip over systemd for consideration, adding
extra layers of complexity when systemd alone would have been sufficient: For
example, using Docker when the basic isolation features of systemd would do,
or using "forever.js" to manage Node.js processes, when systemd could could be
saving 15% memory overhead per process, using software already installed in
the base system.

On the other hand, I _do_ support diversity of software and am glad to see
some other options still being promoted and used. The dangers and weaknesses
of monoculture in the physical world apply to software systems as well.

~~~
fabiomaia
Interesting. So what use cases is Docker good for? Why is it so popular if
systemd suffices?

~~~
ajross
Docker is about deployment. The isolation model is built on the same tooling
that systemd uses, but the usage model is all about how to come up with an
easily isolated runtime environment that can be published and extended in a
big development community.

Basically systemd has nothing like a dockerfile, that's not what it's for.

I think there's a good argument though that Docker should be retargetting its
encapsulation work to a lower level OS primitive where possible (which would
be systemd on linux) instead of rolling its own.

~~~
tracker1
See podman[1]

[1] [https://podman.io/](https://podman.io/)

------
sjwright
One of the better videos on this subject:

[https://www.youtube.com/watch?v=6AeWu1fZ7bY](https://www.youtube.com/watch?v=6AeWu1fZ7bY)

 _BSDCan 2018—Benno Rice: The Tragedy of systemd_

 _" systemd is, to put it mildly, controversial. Depending on who you ask it's
either a complete violation of the UNIX philosophy, a bloated pile of bugs, a
complete violation of the elegant simplicity it replaced or, it most cases,
some or all of the above. So why have so many Linux distributions taken to it?
Is it as bad as people say?_

~~~
psadauskas
I watched this a few weeks ago as well, and it is a very good, even-handed
overview of systemd. He talks about the history and other tools that came
before, like Apple's `launchd` and Ubuntu's `upstart`. He also talks about the
actual problems with it, rather than the FUD hysteria (and also explains why
some of them are FUD).

He's from the BSD world, so his POV is as an (mostly) outsider.

~~~
JdeBP
You might be interested in 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/)

* [http://uselessd.darknedgy.net/ProSystemdAntiSystemd/](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/)

------
danieldk
Guix is missing, which uses GNU Sheperd, which is in Scheme:

[https://www.gnu.org/software/shepherd/](https://www.gnu.org/software/shepherd/)

That said, to me systemd has been a large improvement. Maybe it has its
problems, but at least there is consistency in handling services and logs
between Linux distributions, which is a big improvement over a bunch of
homegrown sysvinit derivatives, Upstart, and homegrown non-sysvinit scripts.

~~~
telmich
Just added as as-good-as-we-could to the website - do you have any experiences
in using it?

~~~
rendaw
I've used it just a bit. AFAICT Shepherd is a fairly minimal dependency graph.

It's not comprehensive - in Guix there are services that exist above and below
Shepherd and you can't define ordering dependencies between these (ex: a
shepherd service can't depend on a mount (above shepherd), or an inetd service
(below shepherd) on a database). I'm not sure that's a huge problem in
practice.

Shepherd process stdout/stderr are sent to syslog. Shepherd automatically
restarts services if they fail but not forever, and the retry behavior isn't
configurable ATM.

~~~
michaelmrose
The last complaint seems feasible to address have you thought of adding an
issue?

------
Mister_Snuggles
I mainly use FreeBSD, but I have a number of Linux VMs that I use where
appropriate.

The big thing, for me, that systemd brings to the table is consistency.
Managing services on CentOS is the same as managing them on Debian which is
the same as managing them on OpenSUSE. This makes it a lot easier to deal with
the various different Linuxes.

Also, it seems to make writing a service a lot easier. Instead of the service
needing to daemonize, write out a PID file, or whatever, it can just be a
program that does its thing without forking, sends its output to stdout/stderr
and systemd takes care of the details. I tried to go through this exercise on
a FreeBSD system and ended up just installing 'pm2' to do it for me. I
subsequently figured out what I did wrong, but pm2 is working and I see no
need to change it.

Obviously systemd isn't suited for every use-case, but it doesn't seem nearly
as bad as some people make it out to be.

~~~
zzzcpan
> Managing services on CentOS is the same as managing them on Debian which is
> the same as managing them on OpenSUSE.

It's not really the same, some systemd-based distros diverge a lot and
anything non-systemd much more so, including FreeBSD. Even something as basic
as network configuration could be completely different on systemd distros,
like Ubuntu with its netplan weirdness and Archlinux going into the opposite
direction and forcing you to choose how to deal with network yourself from the
start.

But still, if you want any sanity in your deployment across different distros
- you simply have to avoid using systemd or other host's init and service
management systems for anything and bring your own service management with
you. It could be as simple as a script starting from root's cron at @reboot
(this particular trick survived for decades for example).

~~~
Spivak
> But still, if you want any sanity in your deployment across different
> distros

This might be true for your in-house app but if you want sanity in packaging
your service for inclusion in various distros you include a .service file.

------
nrclark
I actually really like systemd's service files, and the functionality it
provides. I like the ability to express dependencies clearly, the fine-grained
control over server restart behavior, and a ton of other systemd features. I'm
also very happy to see it replace cron.

What I _do not_ like are:

    
    
      - systemd-resolved
      - systemd-networkd
      - systemd taking over disk mounts
      - systemctl
      - unit files spread out all over the place
      - mandatory journald
      - mandatory dbus
      - only works on Linux
      - pushing the BSDs farther towards being obsolete
    

I'm very glad to see sysv-init on the way out, personally. I think systemd
unit files are a huge improvement, and greatly improve standardization and
init quality. But that doesn't intrinsically mean that the systemd project is
doing the right thing.

~~~
rzzzt
Is there an alternative init implementation that is compatible with systemd
unit files?

~~~
JdeBP
There are certainly automated tools for converting systemd unit files into the
service definitions used by other systems.

* [http://jdebp.uk./Softwares/nosh/worked-example.html](http://jdebp.uk./Softwares/nosh/worked-example.html)

* [http://jdebp.uk./Softwares/nosh/guide/converting-systemd-uni...](http://jdebp.uk./Softwares/nosh/guide/converting-systemd-units.html)

* [http://jdebp.uk./Softwares/nosh/guide/commands/convert-syste...](http://jdebp.uk./Softwares/nosh/guide/commands/convert-systemd-units.xml)

------
beaconfield
It's comical how people get so "jazzed" about something like not liking
systemd and make a whole movement about it (with their t-shirts and
everything). I get people may not love everything about systemd (or maybe they
hate it), but I'm not convinced it's so bad. I've been using it since RHEL 7
and I've really gotten used to all of the benefits of systemd. It also doesn't
hurt that I went to the session on pid 1 by Lennart Poettering at Red Hat
Summit 2014 and he convinced me of the at least not-horribleness of systemd.

~~~
chapium
You either fall into a group that hates systemd or one that could care less
about the problem systemd is solving.

~~~
asveikau
I didn't care much about the problem systemd was solving, I was content to let
the init process go through without touching it.

Then one day several years ago I did an apt-get dist-upgrade and my system
didn't boot after that. I have personally hit _way more_ issues with
unbootable systems or having to drop into single user mode to fix some BS with
systemd. That was enough to make me dislike it, or convert into a hater, and
switch most of my personal usage away from Linux.

I think it's gotten better since then. I still dread updating Linux boxes,
because I know that some percentage of those updates will have a systemd bug
introduced resulting in a non-bootable system or one where I have to manually
fix it up.

~~~
AsyncAwait
Counter-anecdote, I switched to systemd all the way back in 2012 on Arch, even
before it was mandatory and way before it was in a state where other distros
felt comfortable switching and I remember to this day that after I did the
conversion and hit reboot, an absolute panic hit me, I was 110% sure the
system won't boot afterward, just because of how drastic the change was to
perform on a live system, (because simpler upgres than that broke my system
before). Since Arch is rolling is not like a new release came with systemd,
no, you just switched your live system over.

I remember being absolutely _floored_ when after that relatively complex
procedure, not only did the system boot, but it booted _faster_. I think I
became a fan that day.

~~~
asveikau
To be fair to your view, I did observe fewer issues in Arch's systemd
packaging vs. say, Debian. Arch I think is pretty good overall.

------
sjwright
I get no end of bemusement from open source advocates that think it makes any
kind of rational sense to campaign _against_ an open source project. THIS IS
ALL OPEN SOURCE. Freedom and choice is the _whole point,_ isn't it?

If you prefer an alternative or forebear to systemd, that is great. Use it.
Advocate _for_ the system you prefer. Convince people that the choice you have
made is better.

Meanwhile the vast majority of distributions have voluntarily chosen systemd.
Perhaps if its critics reflect on the reality of that shift, they could look
at ways to improve the alternative to address its perceived deficiencies—just
as GCC started doing now that LLVM has taken a bite out of their dominance.

~~~
enriquto
Notice that nobody complains about the _existence_ of systemd, but about the
enormous and shady pressures that distros had (particulary debian) to adopt it
as standard. Nowadays, the complain is mostly about the systemd monoculture.

~~~
bunderbunder
> systemd monoculture

As someone who _really_ wanted the BSDs to get more credit ~20 years back, and
spent a fair amount of time on various commercial Unixes as well, I find that
phrase rather amusing. Historically poor standardization of the userland
aside, GNU/Linux is the poster child for monoculture in Unix, and has left a
whole lot of dead or dying software in its wake.

~~~
JohnFen
I've decided to migrate my Linux boxen to BSD (this is a long-haul project
that will take me a year or more, I estimate). In part because systemD itself
really made me aware of the issue that you're raising.

~~~
snazz
Which BSD, may I ask? I’d personally recommend OpenBSD, for code quality and
“it just works”, but there’s a lot of really interesting BSDs that are even
more obscure (Dragonfly, Debian and Gentoo using BSD kernels, etc) aside from
FreeBSD and NetBSD.

------
kevin_b_er
Most arguments about systemd will devolve into a Motte and Bailey argument.
The problems with systemd are all the stuff tacked on that are mandatory, but
if you criticize them you'll get people switching to try to put words into
your mouth about how the init replacement is good/bad.

The Motte is all the shovelware attached to systemd that is nearly impossible
to detatch and the Bailey is the init replacement.

~~~
mjw1007
There's a lot of truth in what you're saying, but I think you have "Motte" and
"Bailey" backwards.

~~~
kevin_b_er
You are right! Fortunately the sense can be easily obtained.

------
cracauer
I have way too many cases of systemd startup items hanging with their timeout
for no good reason.

Worse, my most complicated high-uptime machine usually does not shut down in a
reasonable time. Systemd says "waiting for session user cracauer" (something
like it) for whatever reason. It also hung on undoing swapspace, when that
swapspace was a custom stack of block layers. I don't need swapspace to be
"shut down". It went into 20 minutes something always stating another timeout
when one expired. I mean, WTF?

The problem here is that I had to do an unclean shutdown on that machine
(reset button) multiple times, and _that_ I really can't have.

This also illustrates a point I have been making about Linux and the BSDs from
day one: When the BSDs boot or shut down the keyboard is connected to the rc
scripts. You can do Control-C for SIGINT and Control-\ for SIGQUIT, The latter
makes everybody in the stack leave a coredump on disk.

Now, compare these two:

1) in BSD when there is a startup or shutdown item taking too long or hanging
I can abort that single item and I can later debug what was going on with the
coredumps.

2) on a Linux system with systemd I cannot "cut through" startup or shutdown
items I don't want to wait for, and there is no way to debug any of that if
the machine doesn't actually come up completely, or if thing happen at
shutdown. The only interaction I can conduct is the reset button.

To add insult to injury, systemd also hides a lot of error messages that would
traditionally be dumped on the console, and instead of giving me that error
message systemd captures it and print on the screen instructions how to get
that error message (which usually are longer than the error message was,
WTF?). Instructions that I cannot follow because somebody detached my
keyboard, and because I will never be in that machine in an up state while
that context is available.

This also invalidates the point that systemd could be one platform that you
learn once and then use on a wide basis. The debugging abilities are nowhere
close to adequate, so you have to learn by try-n-error.

~~~
webstrand
I've struggled with, and am still struggling with, units hanging on shutdown.
It's my biggest complaint with systemD aside from journald eating its own
logs.

I've been using magic SysRq to force hanging units to quit. SysRq + e sends
SIGINT to all processes, and SysRq + i sends SIGKILL.

~~~
cracauer
Sending SIGINT to _all_ processes isn't what is needed here. It needs to go to
the "processes" that are currently going on. With systemd's parallel execution
that can still be narrowed down in a useful way, especially is some tail of
some hanging command is running alone by now.

Obviously what the BSDs are doing, sending SIGQUIT to just the currently
blocking-the-shutdown processes, is far superior. Now the coredumps are
floating around the filesystem and they'll be there after reboot, and you can
see who did what and was hanging in what backtrace.

------
Whatitat90
SystemD definitely spurred some controversies years ago but is it that bad in
2019?

All major distros adopted it and even some that are listed there as "no
systemd" in reality just give you choice (e.g. Gentoo).

I'd gladly hear the opinion of distro maintainers why did they switch to
SystemD if it's as bad as it looks like in people's perception.

~~~
meddlepal
It seems the systemd hate mostly comes from a philosophical position these
days than anything grounded in real user impact. You either agree or disagree
with what systemd does, or do not care because you are not aware of it (which
I would argue is a good thing).

Personally I think it is great. Sysvinit scripts were terrible to write and
frequently had bugs because the scripts were usually afterthoughts "Oh yea...
I guess we need one of those things". The nice integrations between systemd
and journald is well worth it in my mind as well.

~~~
NikkiA
sysvinit was at least a thousand times easier than bsd init scripts, and I
occasionally see people that are opposed to both systemd and sysvinit and
think rc.local was 'it'.

 _shakes head slowly_

~~~
JdeBP
BSD rc scripts haven't worked in the way that you think that they have, for
decades.

Mewburn rc, which reduced many rc scripts to a couple of shell function calls
and a handful of variable declarations, has been used by NetBSD since 2001,
and FreeBSD started using it about a year later. OpenBSD, furthermore,
reinvented Mewburn rc around 8 years ago. Project Trident (formerly TrueOS
formerly PC-BSD) has also since then switched from Mewburn rc to OpenRC.

* [https://news.ycombinator.com/item?id=10357589](https://news.ycombinator.com/item?id=10357589)

* [https://news.ycombinator.com/item?id=11550802](https://news.ycombinator.com/item?id=11550802)

* [https://news.ycombinator.com/item?id=14736175](https://news.ycombinator.com/item?id=14736175)

/etc/rc.local was first declared obsolete in the BSD world and replaced by a
system of drop-in files in a directory _back in 1995_.

* [http://jdebp.info./FGA/rc.local-is-history.html](http://jdebp.info./FGA/rc.local-is-history.html)

~~~
yellowapple
> /etc/rc.local was first declared obsolete in the BSD world and replaced by a
> system of drop-in files in a directory back in 1995.

OpenBSD still documents it as an implicitly-recommended way to start programs
(though if it's possible to start it via e.g. rc.(local.)conf, then that's
obviously preferable).

------
exabrial
My experience with systemd has be extraordinarily positive. I like the unified
syntax of unit files. I know that's like 50% of what systemd does, but it does
it extraordinarily well.

Is systemd-nspawn secure enough now we can forget docker et all? I liked the
idea of a "chroot" being supported by the service manager.

------
enriquto
Love this!

Notice that the text about slackware sounds a bit "pessimistic", as if it was
a somewhat legacy distribution. Nothing further from the truth. We run a small
farm of virtual machines with different up-to-date distributions, and
slackware is typically the one that follows upstream packages more closely.
For example it had gcc 9.1, bash 5, etc. a few days after they were released.

~~~
annadane
Under -current, though.

------
scurvy
I don't like it when my process init and logging system also tries to manage
my volume mounts. If I unmount a device, I don't want systemd going behind my
back and remounting it for me.

It's non standard behavior changes like this that drive systemd hate.

~~~
telmich
From what I observe, the hate from systemd USERS towards non-systemd advocates
is higher than the hate of non-systemd advocates to systemd.

~~~
nona
I've never seen systemd users make t-shirts against the others, send death
threats, hijack any conversation where systemd might come up to advocate their
side… non-systemd advocates on the other hand…

------
zamadatix
Alpine is great. I have nothing against systemd but Alpine stands on it's own
for containers and VMs. I haven't given it a try on baremetal but I imagine it
does just as well there. Not really desktop focused but if you want to run it
with a GUI on a laptop it's technically possible.

~~~
telmich
I've actually tried it on my new notebook a few days ago, it runs quite nice:
[https://www.nico.schottelius.org/blog/alpine-linux-on-the-
hp...](https://www.nico.schottelius.org/blog/alpine-linux-on-the-
hp-x360-1040-g5-notebook/)

~~~
dantondwa
In the benefits of Alpine, you have put that the sound is great. Out of
curiosity, what makes it better than other Linux distros?

~~~
telmich
Simplicity mostly. It just works. It feels so clean, nothing running there
that is not supposed to be there. Installing something takes only sub-seconds,
because packages are small.

Alpine really is a beauty.

~~~
dTal
I believe your questioner was specifically referring to your assertion that
audio on Alpine is unusually good. It is a somewhat odd observation, since
ALSA is entirely a kernel API and Alpine is using the same kernel as everyone
else. The only possible source of audible difference would be not running
Pulseaudio, which resamples audio (some say, badly). However, you can install
Pulseaudio on Alpine, and you can not-install Pulseaudio on most anything
else, so it wouldn't really be fair to call that a feature of Alpine.

------
tssva
The biggest complaint I regularly see about systemd from those that don't like
it is that it violates the UNIX philosophy by combining too many
functionalities into one project.

Based upon this I found the following quote from the article in regards to
Alpine Linux, a distribution based upon BusyBox which implements the
functionality of over 100 usually separate executables into one, quite
amusing.

> It is small and simple, realising the UNIX spirit to the core: doing one
> thing and doing it well.

~~~
hedora
The difference is that with busy box, everything is optional (just replace the
symlink in /bin with another implementation), and designed as a drop-in
replacement for standalone utilities (instead of redesigning them poorly from
scratch).

------
aerique
I have been running Void Linux since Debian switched to SystemD both at work
and at home (including playing Skyrim SSE on Steam using Proton, or StarCraft
2 and Diablo 3 using Lutris) .

It is a very nice distro although I would not recommend it to beginners since
it is a little rough around the edges if you want to do full disk encryption
during installation.

Initially I switched to FreeBSD and then OpenBSD but I missed Linux
conveniences like native cloud sync clients[1], Steam, Docker, support for the
hardware I already had, etc.

[1] this was before I discovered Rclone

~~~
sprash
I use void now on everything, work, home even my Raspberry PIs. Can confirm
that installation is a PITA. If you want something more fancy than the
standard installation like an encrypted boot disk you won't get anything
running without touching chroot a few times.

But once it runs it runs! The most "stable" rolling release distro I have
tried so far. Something that can not be said about Gentoo.

------
peterwwillis
The most recent reason I found to hate systemd was it replaced my system DNS
resolver with its own (thus requiring me to modify /etc/systemd/resolved.conf,
and doing the daemon-reload-service-restart-hokey-pokey, to get a host to
function on a network+VPN like it did before). The only reason systemd has its
own resolver is they wanted extra DNS functionality. Did I ask for these
features? Did I want a new resolver? No. But that's the whole idea behind
systemd. A few devs shoving complex features down everyone's throats, just
because they felt like it. Operating system fascism.

But I don't think we should be angry at systemd developers; they can develop
whatever they want. I'm mostly angry at the distributions who opted in to
their crap. Systemd has not made my life easier, but it has often made it
harder, and the only reason that happened was because a distro allowed it.

~~~
telmich
I don't think being angry at anyone will solve the problem. Using and
advocating non-systemd distributions might help much more.

~~~
enriquto
Being angry does not solve any problem, but it is a legitimate human
experience that the OP considered worth sharing.

------
ww520
I've actually done sysvinit style setup before and had to migrate to systemd
when it came out later. It's not that bad. It's just another way of running
things. It's actually quite simple and consistent. It's a step forward.

------
toyg
Systemd is the worst init system except for all the others that have been
developed from time to time.

Some of the trade-offs it makes, and its expansionist attitudes, are really
grating. But it introduced a higher level of consistency in the Linux world
for userland developers, which is almost invariably a good thing from a
commercial perspective.

~~~
silversconfused
> from a commercial perspective

Nailed it. The hobbyists are revolting. Anyone interested in making their
system do something odd and clever is having problems, and the people running
linux systems 9-5 are busy calling us morons for trying or even caring...

------
DiseasedBadger
I maintain systems with and without. I thought I understood systemd, but I've
given up trying to predict the behavior of systems running systemd.

The tragedy for me, is that I don't really like how the Init systems work,
either. So there's really no one on my side. I seem to always fall into the
trap of the Dreaded Centrist.

------
siffland
One of my biggest concerns about systemd is the ownership. Sure it is open
sourced, however RedHat has a lot of pull on its maintainers (Soon to be IBM).
What is to stop them from dual licensing it or close sourcing it. They have
lots of products like that (jboss/wildfly...spacewalk/satellite). After
everything runs on systemd the ball in in their court. Sure people can say
they are going to fork it, but in reality how often does that work out (I
concede are some examples where it does, X11, nextcloud, etc.).

In my paranoid mind I can see Redhat commercializing it and adding features to
it for only paying customers after they win through attrition the monopoly on
the OS (after systemd incorporates everything, resolvers, cron, ntp, etc...).
They are first and foremost a business with investors and a bottom line.

Again not an attack on system itself, just my untrusting and paranoid nature
(to many years of security scans and cve’s and users, can’t trust users)…

~~~
pas
The moment it stops being free Debian drops/forks it.

Furthermore, if Red Hat can monetize a system manager daemon, well ... I mean,
good for them.

Oracle tried with the JVM (they had some commercial features).

Furthermore, if systemd provides a lot of basic facilities (global/user
services, device management, login sessions, cron, ntp, DNS resolving) someone
ought to maintain and support it, and if a for-profit company does it, I don't
mind if they try to cover those expenses. (As long as it's also GPL2.)

~~~
siffland
Systemd is not GPLv2, according to wikipedia it is LGPLv2.1+.

Of course someone here at work told me i am splitting hairs and they are
pretty much the same thing and compatible.

------
massysett
systemd is pervasive in the GNU/Linux world and I think it’s futile to stay on
GNU/Linux and try to avoid systemd. Just look at the list of distros in the
article: a bunch of obscure forks of prominent systemd distros like Debian and
Arch, a distro (Gentoo) whose main claim to fame is compile it yourself, one
where they say a leading Google search is whether the distro is dead, and one
where they say “oh gee, we haven’t heard of it, let us know if it works.”

Seems to me that if you hate systemd, it’s time to try a BSD. GNU/Linux has
been going down this path of complexity for years. These same arguments
spawned with udev years ago, and Slackware held out then just as it is with
systemd. OpenBSD on the other hand embraces simplicity and the old UNIX way.
Of course it also lacks niceties like Bluetooth, but that’s the price you pay.
Maybe systemd is needed to manage complex systems that support ugly things
like Bluetooth.

------
coot
To be precise: Gentoo allows one to run with or without systemd, and both ways
are supported.

~~~
telmich
What is the default at the moment?

~~~
jakeogh
To be clear, you choose at install time. There is no official installer (on
purpose), so the user either decides to turn to page x for OpenRC or page y
for systemd.

------
peter_d_sherman
I wish there were some way to favorite _discussions_ on HN, not merely the
article that started them -- if that feature existed, then this would be one
of my favorite _discussions_ on HN ever... why? Well, you have a ton of bright
minds, who, for whatever reason(s), can't agree, yet each one adds some
valuable piece of information to the debate.

Basically, where there's controversy (especially with bright minds) then
there's always _something there_.

I hope that future system designers and historians will read and re-read these
systemd controversies we are having in the present day... maybe we'll have
some fundamental key piece of understanding then that we don't now, and based
on it, everyone could agree... of course, then again, perhaps that would never
happen...

Still, a lively, highly informative, interesting and thought-provoking
discussion! A+ as far as discussions on HN go!

------
AaronFriel
systemd is good, but I think it came too soon. A lot of the comments here are
about memory safe languages are spot on. systemd was written with two major
assumptions in mind:

1\. Linux system complexity has exploded and needs a top-to-bottom rewrite

2\. It's safe to do such a rewrite in C

Since the systemd project, I'd say #1 has been largely affirmed. I like the
result of systemd because it provides uniform tooling around complex Linux
systems.

I'd also say the tide has shifted against #2 in a big way, there's much
greater skepticism that anyone on this planet (short of djb or a few others)
can write safe C, let alone safe C with concurrency and side effects.

This is really unfortunate, because it probably means the solution is to
rewrite systemd in a memory safe language, and that's a huge undertaking.

~~~
cesarb
> it probably means the solution is to rewrite systemd in a memory safe
> language, and that's a huge undertaking.

At least with Rust, the rewrite could be done piecemeal, since Rust can easily
interoperate with C (as long as you don't abuse C macros).

------
nnq
What's the recommended way for someone to _learn_ systemd _properly?_ Is there
a readable manual somewhere that documents _everything?_

That's the only thing I find scary about such big systems, the lack of
comprehensive docs and a "starting point for learning them" from 0 to hero.
Like, with Git there's tons of nice tutorials like "learn kit bottom up by
reinventing it in way X" etc. plus a good "default book".

What's the equivalent of [https://git-scm.com/book](https://git-scm.com/book)
for systemd?

~~~
jolmg
The Archlinux Wiki is my go-to for that kind of thing:

[https://wiki.archlinux.org/index.php/Systemd](https://wiki.archlinux.org/index.php/Systemd)

Also, check the related articles on the right sidebar on the top of the
article.

It doesn't document _everything_ , but it quickly gets you to learning the
overview, the basics, and what's most important for general usage of systemd.

If you really want _absolutely_ _everything_ the references are the man-pages.
Excluding those that document C functions, there seems to be 256 systemd man-
pages in total. 36 are regular commands (section 1; like systemctl), 64 are
file formats (section 5; like systemd.service), 139 are system administration
commands (section 8; like daemons like systemd-networkd), and 17 are
miscellaneous topics (section 7; like bootup).

I would consider the manpages of section 1 and 5 to be the important ones, and
just section 1 is enough if you never intend to read or write a service or
other unit file yourself.

Here's an online index of the manpages:

[https://www.freedesktop.org/software/systemd/man/index.html](https://www.freedesktop.org/software/systemd/man/index.html)

------
burfog
SysV init had the ability to restart, allowing upgrades without rebooting. Can
systemd do that?

The mechanism was kind of interesting:

SysV init would create socketpair, then fork. The parent (with PID 1, required
for correct functionality) would then exec the new SysV init binary with an
option specified to make it receive state over the socket. The child would
supply that state, then exit.

~~~
acdha
You’re looking for `daemon-reexec`:

[https://www.freedesktop.org/software/systemd/man/systemctl.h...](https://www.freedesktop.org/software/systemd/man/systemctl.html)

> Reexecute the systemd manager. This will serialize the manager state,
> reexecute the process and deserialize the state again. This command is of
> little use except for debugging and package upgrades. Sometimes, it might be
> helpful as a heavy-weight daemon-reload. While the daemon is being
> reexecuted, all sockets systemd listening on behalf of user configuration
> will stay accessible.

------
pard68
This anti-systemd meme is getting tiring. I generally find it is perpetuated
by people who use Linux at a hobby level. Rarely do I speak with guys in Ops
who dislike systemd. I am not trying to discredit people here, there are hobby
users who are more knowledgeable about Linux related systems than many guys
who are professionals. My point is that Linux and systemd are both meant for
use on servers, in production, where speed and consistency rule.

I manage 3000 Linux servers and 20,000 services running on those servers. When
I log into a machine and am welcomed by a RHEL6 motd I groan, because sysvinit
is not enjoyable to use, it takes longer to reboot those machines, and
tracking down logs is a chore.

When I log into a RHEL7 machine I am not elated, but I am glad to know that
pid 1 isn't trying to make my life harder.

~~~
silversconfused
Being dismissed as a meme is tiring as well. I like hacking on my system at
boot time, and dismissing my use case because of your own is kinda hostile.

~~~
pard68
If you are referring to my comment regarding Linux not being for desktops...

I use Linux on my desktop. The only non-Linux machines in my house are my work
Windows machine and my sister in law's Windows machine. All my personal
machines, my wife's laptop, and my kids' desktop are all Linux flavors. Linux
is a great desktop imho. That said, Linux is not primarily a desktop machine.
It gets some pro-Desktop patches but at the end of the day, Linux is designed
for servers and paid for by people interested in its usage as a server.

------
curt15
Don't Google's servers also run a custom systemd-less Debian derivative?
[https://www.usenix.org/node/177348](https://www.usenix.org/node/177348)

------
Klathmon
This list is missing a linux-ey system which doesn't use Systemd that is
growing in popularity!

WSL!

WSL somewhat annoyingly has a custom/proprietary init system. Partially due to
it's "interesting" integration with windows, and partially because it's not
even really a full linux system yet.

I'm curious if with the switch to WSL2 where they will begin shipping a full
linux kernel if systemd will be included or will they stick with their current
custom solution?

~~~
darkpuma
> _WSL_

I think you mean GNU/Windows, or as I've taken to calling it, GNU Plus
Windows. (Seriously though, the WSL name is deceptive because it doesn't
actually contain any Linux code. There is no Linux in _" Windows Subsystem for
Linux"_)

~~~
alanfranz
WSL 2.0 contains a full Linux kernel.

~~~
darkpuma
Yeah but as far as I can tell that doesn't actually exist yet, and isn't
scheduled to be available until the end of next month. (Existing inside
Microsoft but not publicly is "does not exist" as far as I'm concerned,
because I remember all kinds of legendary stuff Microsoft has apparently made
but never released.)

------
cik
I went on angry binge where I Ubuntu finally pushed me over the edge with it's
latest... och. Between that and systemd, I've starting to dislike Linux,
pretty much for the first time since I started using Linux back in the early
90's.

The second real, functional, genuinely working docker support shows up in *BSD
and is working - I'll be running it on my desktop.

------
tombert
I do find it funny that people crap all over systemd, but don't seem to have a
huge problem with launchd, despite the fact that systemd was almost a direct
port of it.

Personally, while I do think that systemd's scope might have been a bit too
ambitious, I do find it easier than something like Upstart

~~~
JdeBP
systemd _was not_ a port of launchd, direct or otherwise. The problem with
launchd being difficult to port off MacOS is one of the reasons why launchd
never came about for FreeBSD.

* [http://jdebp.uk./FGA/launchd-on-bsd.html](http://jdebp.uk./FGA/launchd-on-bsd.html)

systemd was not a port of anything. And its immediate inspiration was Upstart,
the system that Fedora was using at the time, and whose drawbacks provoked
Lennart Poettering et al. to start working on systemd.

(Interestingly, Upstart itself was inspired by the drawbacks of porting
launchd.)

~~~
loeg
> systemd was not a port of anything. And its immediate inspiration was
> Upstart

Its motivation was perhaps upstart's shortcomings, but systemd was definitely
inspired by the design of launchd and that was repeatedly and explicitly
mentioned in Lennart's very first blog post introducing it:

> But first, let's clear a few things up: is this kind of logic new? No, it
> certainly is not. The most prominent system that works like this is Apple's
> launchd system ...

> For socket activation we support full compatibility with the traditional
> inetd modes, as well as a very simple mode that tries to mimic launchd
> socket activation and is recommended for new services.

> More importantly however, it is also our plan to experiment with systemd …
> to make it the ideal session manager… The problem set of a session manager
> and an init system are very similar… Using the same code for both uses hence
> suggests itself. Apple recognized that and does just that with launchd. And
> so should we…

> Writing Daemons:: … The list above is very similar to what Apple recommends
> for daemons compatible with launchd. It should be easy to extend daemons
> that already support launchd activation to support systemd activation as
> well.

[http://0pointer.de/blog/projects/systemd.html](http://0pointer.de/blog/projects/systemd.html)

~~~
JdeBP
No, that's not explicit. That's a few instances of "like launchd". Where M.
Poettering actually _is_ explicit about inspiration, xe writes the words:

> _we took a lot of inspiration from Upstart 's code-base_

... which they actually did and continued to do, from observation. There were
significant discussions amongst the systemd people involving the way that
things worked with Upstart, including (for just three examples out of the many
over the years) having to work like Upstart with respect to putting the X
server on the first KVT, Upstart's handling of SIGPWR to process #1, and
eliminating /dev/initctl because it was not really utilized in Upstart.

* [https://news.ycombinator.com/item?id=12772915](https://news.ycombinator.com/item?id=12772915)

* [https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...](https://lists.freedesktop.org/archives/systemd-devel/2016-July/037161.html)

* [https://lists.freedesktop.org/archives/systemd-devel/2015-Se...](https://lists.freedesktop.org/archives/systemd-devel/2015-September/034344.html)

In comparison, there was almost _zero_ similar consideration of launchd. The
idea that launchd inspired systemd is a myth, not borne out by _what M.
Poettering explicitly wrote_ was the inspiration nor borne out by the evidence
of what the systemd people did down the years.

~~~
loeg
I think we're going to have to agree to disagree about what "explicit" means,
and possibly also "inspire." (Based on the excerpts quoted verbatim from
Lennart's blog post in my previous comment and general understanding of the
English language.)

------
saghm
See also the search filter on Distrowatch for non-systemd distros:
[https://distrowatch.com/search.php?defaultinit=Not+systemd&s...](https://distrowatch.com/search.php?defaultinit=Not+systemd&status=Active)

------
thedaemon
AntiX Linux is my current favorite which happens to be systemd free and runs
with lighter weight DEs. It takes up only about 500MB of RAM sitting still, so
pretty great for older systems and laptops.

------
andrewstuart
I'm a big fan of systemd.

Comprehensive, well organized, reliable, powerful.

It makes a consistent service from what was an evolutionary hotchpotch of
stuff.

Whatever it is that the haters hate, I don't get.

------
xaduha
NixOS is one of the best distros there is and it uses systemd. Do I interact
much with systemd myself? No, I don't even though I don't mind.

------
Torwald
Is there a Linux distro which I can install on my Mac and where I don't have
to touch the terminal ever?

------
chmielewski
Don’t forget one of my favorite init projects! LinuxBBQ!

------
jakeogh
I'm still waiting for it to eat dbus.

------
godshatter
I think PCLinuxOS is still systemd-free.

------
bhaavan
Where is ChromeOS?!

------
adictator
We absolutely love Alpine, but it's been hard to integrate with other systems
because of it using musl. For instance, our dns resolvers do not work properly
& our monitoring solution is incompatible with musl.

------
holstvoogd
I recommend watching this to give you some perspective on the SystemD hate:
[https://www.youtube.com/watch?v=o_AIw9bGogo](https://www.youtube.com/watch?v=o_AIw9bGogo)

I too was furious about the existence of systemd, but now I realize that was
mostly because I don't want new things and consider many new things to be bad
because they are new and there have been a few 'bad apples' in my personal
experience

------
kissgyorgy
If you are still arguing about systemd, you don't know enough about it, so you
should learn about it and you don't understand the big picture. Users crying
about Linux desktop all the time, but systemd has a huge part making the
situation way better.

~~~
zaro
> Users crying about Linux desktop all the time, but systemd has a huge part
> making the situation way better.

Definitely. Maybe it's not great that GNOME has a hard dependency on systemd (
I personally don't care), but most people don't appreciate how much things
have improved on the desktop with systemd.

~~~
silversconfused
I've been using linux since kernel 2.2. Deployed hundreds if not thousands of
workstations for home users and developers. Trust me, I've seen desktop ups
and downs, and I disagree. Systemd works until it doesn't, and then it's an
unfixable lost cause and you reload it like a naughty 9x box.

~~~
zaro
Yeah, same for me. Since about 2.2. And I remember patching init.d scripts on
Debian, adding sleep 5 In the network script, because you know our service had
to have eth0 up and configured. So it's not like the old init system was
perfect either :)

Or when I was building VM appliance with dB inside, and I was reading the news
about systemd and how it would allow cpu and ram limits per service and
thinking how if I had it it would save me from weeks worth of work (yes IBM
DB2 is total crap when you run it in VM). and so on.

When I look back of all the stupid things I had to take care of and in systemd
are just a config away, I can't help but wonder why people dislike it so much.

~~~
silversconfused
You were able to do those hacks because it was open to you at run time. You
COULD fix it. Now if it breaks and there's no fix, you may as well have used
boxed software because your options are only to wait for a fix or find
something else. Honestly, I'd have very little problem with systemd if it was
not written in a compiled language. Losing that flexibility sucks.

In another comment I noted that this is obviously a divide between the
hobbyists and the 9-5 linux users. I am both, so this is particularly sucky.

