
Why I dislike systemd - geoffbp
http://www.steven-mcdonald.id.au/articles/systemd.shtml
======
weland
I'm one of the people who jumped ship to OpenBSD in the last year or so. I
think I first touched a Linux machine in 1997 or 1998. systemd has been part
of the reasons I did that for precisely the same reason.

There is a lot of development in the ecosystem dominated by Freedesktop.org,
Gnome and (to some degree) large commercial players like RedHat and SUSE. It's
more efervescent than it's ever been. Fifteen years ago, I'd have been
ecstatic to see so much development being done.

Yet for all this fierce code churning, there's _absurdly little innovation_.
Even in systemd, there's a lot of focus on non-issues like booting without
needing a shell, while still inventing service startup notification types
because none of the gazillion startup notification types already existent can
actually solve precisely the problem systemd claims it solves -- managing
complex startup chains.

In the last three or four years, my Linux systems have become increasingly
blackboxed, and consequently harder and harder to configure, let along debug
when they stop working. Over the span of six months, a tool you just got to
learn how to work with (mostly because the documentation seems to have been
written by very bored and very verbose monkeys who had only a typewriter to
pass the time with) becomes obsolete or is revamped to be unrecognizable.
Which would be _fine_ if that actually solved any problems. Instead, it
replaces the old set of problems with a new, even more complicated set of
problems that developers claim you shouldn't have, while insisting that the
old problems were simply due to the old architecture and we'll have none of
that now that we have this shiny new thing.

Ironically, systemd is actually one of the better pieces of software to come
out of that ecosystem. No, seriously. It's decently documented and as long as
you don't need anything more complex than "here, start this daemon after this
other daemon started", it does its job.

If you want to peck at something, have a look at Polkit, where someone
brilliantly figured out that the best way to configure policies is to write
basically undebugable JavaScript code in .rules files.

~~~
anon3_
> I'm one of the people who jumped ship to OpenBSD in the last year or so.

Ha. FreeBSD here.

And so long as you get the right hardware, I find BSD to be far simpler than
linux distributions out there.

Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than
configuring rpm/debs.

Getting a package approved in debian? Alioth? No offense, the wiki, all these
pages on the debian website - they have no concept they have of "Handbook", in
the sense FreeBSD has. It's so adhoc, they're healthy, but they're in denial
about how hard they make it for new people. By the time you've taken to time
to learn Debian's dev warts, you're apart of the convent and no longer care
about fixing the onboarding problems.

But to be fair. I have day to day gripes with FreeBSD just because we're short
on the manpower Linux distributions have in excess:

On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox just
clogs up and stops working. No skype (CURRENT will be in a better position to
since epoll support has been added). No Dropbox (as of now, we don't have
inotify, and kqueue may not be able to handle it, don't quote me on that).

I do my 90% of daily routines simpler and better on FreeBSD. If only Google /
Mozilla (with all the resources they have) gave someone who could work to fix
this stuff.

~~~
weland
I've occasionally used {Net|Free|Open}BSD over the past few years (in fact, I
think my Jornada in the back of the closet still runs NetBSD). I kept sticking
to Linux partly because I was using it at $work, partly because it was simple
enough and I'm kindda lazy. But yeah:

> I find BSD to be far simpler than linux distributions out there.

The way OpenBSD handles WiFi configuration is a good example of this. Want to
connect to a wifi network? ifconfig <interface> <ESSID> <passphrase>. If you
need some other fancy flags for those 0.1% of hotspots in the world, you can
do those, too (also through ifconfig) but it's _that_ simple.

In contrast, after everyone agreed that wpa_supplicant is probably what
happened after Stalin's ethereal spirit had mad sex with Hitler's ethereal
spirit and their ethereal baby was incarnated, what did we do to alleviate
things in Linux land? Why, we wrote NetworkManager, of course! Conservatively,
90% of today's deployments of NetworkManager exist because no one can figure
out how to set up wireless without it, and we put up with its crap because
wicd is waiting for us at the other end.

Better yet, this is _all_ nicely documented in the manpage. If you search for
"wireless" in ifconfig's manpage, you find out all you need to know. Just for
fun, compare that to man networkmanager.

> On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox
> just clogs up and stops working. No skype (CURRENT will be in a better
> position to since epoll support has been added). No Dropbox (as of now, we
> don't have inotify, and kqueue may not be able to handle it, don't quote me
> on that).

I haven't had crashing things on OpenBSD, but yeah, a bunch of things don't
work. Fortunately, they're things I don't use. If I ever need them -- OH THE
HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and
purposes is by now about as closed and as hard to wrestle with as Fedora, but
at least it doesn't hopelessly break every six months. There are Linux-only
things that I sometimes need because at some point between 2003 and 2013,
"portable" ended up meaning "we can probably work if you have bash in a non-
standard location but that's about it" (eh, Yocto?) for which a cheap VPS is
more than enough. When it breaks, I don't have to spend days trying to find
out exactly _what_ part of PolicyKit broke or where my devices are mounted
this week -- I just wipe everything and reinstall.

~~~
Hello71
actually, wpa_supplicant isn't that hard to configure as long as you only use
the GUI. just scan for APs, double-click on the network, and type in the PSK.
no documentation-reading required.

~~~
weland
But I don't want to (just) use it through a GUI, I want to be able to script
it. What am I, a connection-making machine :)?

------
ChuckMcM
Steven, if you're reading, you got your history slightly wrong. System V got
its init handling from Sun's SunOS 4.x. It was negotiated as part of the
integration between SunOS and System V which would become the "one UNIX for
everyone". Unfortunately for all of us, AT&T really really loved "run levels"
and Sun really really liked BSD's way of configuring the system. Which got you
the unholy love child you saw in Solaris 2.0 and System V release 2.0.

For the other Sun folks from the systems group who quit rather than submit to
the demands, you were right, I was wrong. We couldn't convince them of the
error of their ways.

~~~
yuhong
This history looks wrong. Eg it was SVR4 that merged SunOS

~~~
ChuckMcM
You are correct it was System V, release 4 that merged with SunOS. It was also
the release that Sun and AT&T "combined" the BSD init/rc system with the
System V init/run-level system.

------
jveld
_It got the job done by making the 99% majority of use cases more difficult in
order to make the 1% minority simpler. This is a design pattern I think is
being repeated in systemd._

I kinda had the opposite impression. I first encountered systemd when I
started messing around with arch for a couple little vps projects. At the time
I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely
found day-to-day tasks easier with systemd (better built in monitoring,
consistent syntax, etc). For simple cases, writing a unit file sucks _a lot
less_ than writing an initscript. The warts in systemd only started to
irritate me when I was first setting up my personal machines (one laptop, one
tower) to run arch [1]. Even then, the bloat in the design irked me more than
actually using it. So, I'm in favor of systemd, but not thrilled (dbus
everywhere is annoying).

Then again, I don't maintain any packages with strange and/or complex daemons.
If anybody's had a really hard time getting their stuff to work with systemd,
I'd be interested to hear stories.

1: Not completely true. I want my damn log files back.

~~~
thaumaturgy
This is why I suspect that most of the divisions in the sysadmin community
regarding systemd are generational. For people (like me!) who have been
writing init scripts forever and can do it in their sleep, they'd prefer the
flexibility and familiarity of init scripts to a new system that at first
glance appears more limited.

For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look
like a horrifying way to manage a startup process, and just about anything --
including Yet Another Config File Format -- looks preferable.

I think this is also why so little progress is being made on resolving
conflicts over systemd. There really isn't a whole lot of room for compromise;
one group simply wants things to stay more or less the same (or evolve
incrementally), the other group simply wants to throw it all out and start
over.

I bet there would've been a lot less argument and vitriol about systemd if
Debian hadn't made the decision to default to it, basically leaving all the
crusty sysadmins homeless. Once Debian switched, there was a near guarantee
that all of Linux was going to move to systemd. That suits one group just
fine, another one not so much.

On the plus side, the BSDs should be seeing a really nice upswell of
installations over the next couple of years, which is great, because they've
been quietly building some pretty great operating systems that deserve more
love.

~~~
chousuke
It's perfectly possible to run scripts with systemd unit files, so there's no
real "flexibility" lost anywhere. The primary improvement is that systemd
handles by default most of what used to be boiler-plate in every script, on
top of calculating dependencies automatically. Then you get integrated process
supervisor capabilities so that the init system actually knows whether
services are running or not.

Speed was certainly a major motivator as well, considering the increasing
popularity of containers and on-demand virtual machines.

To me it seems that "gradual evolution" was exactly what they did, and it
wasn't really going anywhere. Lennart came up with systemd and convinced
enough people that it's worth the pain of migration to get a clean start.

~~~
VLM
The key is the expense vs reward ratio.

I don't know how to write sysvinit scripts any more than I know how to write
fizzbuzz. What I do know is how to program and specifically how to write and
maintain and debug shell scripts. I NEED that for other automation purposes
and cannot get rid of that mandatory requirement so it used to dovetail quite
well with init scripts. There are corner cases and security issues and
tradition, which means copying a known good init script and editing nothing
but the executable names is a great start, but its not really a serious
problem. I don't care if its verbose, as long as its simple and understandable
and most importantly, predictable.

Now instead of applying a language and tradition I know to a simple task like
init, I get to learn a whole new ecosystem and technology to do about the same
thing I always did except vastly more complicated, and I can't even shed the
old knowledge because its needed elsewhere. That makes overall systems harder
to use, slower, buggier, and less reliable. And thats defined as "progress"
because its new so it must be better.

~~~
EmanueleAina
I don't think it's really fair to compare writing unit files to being able to
program in shell.

True, knowing the systemd unit options is not a reusable skill, but it's not a
huge effort either: the syntax is trivial (INI-inspired, the same as .desktop
files) and the options themselves are rather well documented.

And for sure, these options are immensely more reusable when writing a new
unit file than mixing and matching shell snippets taken from different init
script using different styles and conventions.

(Not to mention how subtly tricky programming in shell is even when you're
doing trivial things, see [http://www.dwheeler.com/essays/filenames-in-
shell.html](http://www.dwheeler.com/essays/filenames-in-shell.html) )

~~~
JdeBP
_knowing the systemd unit options is not a reusable skill_

That is, to an extent, not true. There is at least one system that can import
systemd unit files, subject to some fairly obvious limits on Linux
idiosyncrasies.
[http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...](http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-
example.html)

~~~
digi_owl
Heh, i was wondering how long it would take before we would get something like
this.

~~~
JdeBP
It was around before the Debian Technical Committee made its decision. It
wasn't one of the options to choose from, but it was an existence proof, for
those making the decisions, that systemd unit files will not lock them in and
that there's a route for Debian packages that have systemd units on Debian
kFreeBSD and Debian Hurd.

~~~
digi_owl
Too bad it is not the unit files one should worry about, but the continued
scope creep of the systemd project.

by the time one want to move from systemd to nosh, or anything more limited in
scope, one may have face the rebuilding of Linux user space from the ground
up.

~~~
JdeBP
It's not the unit files as a potential lock-in that one need worry about _now_
, because of the nosh project. But it most definitely _was_ one thing that
people thought about then.

------
swhipple
The author mentions that he believes the biggest problem of systemd is
repeating some mistakes of SysV init, but I think it's actually pretty
important that familiarity is preserved to help people upgrade. For example,
the author mentions babysitting the users (systemctl edit) and config/daemon
reloading as things that could be made automatic, I'm assuming with e.g.
inotify change events.

But you often want some confidence that the change you're making to your
system is what you expect, and we've had them all along:

\- visudo(8) sanity checks, for atomicity and syntax, to help prevent you from
bricking your authorization

\- an explicit SIGHUP to reload the configuration file for your daemon, after
you've checked the config, rather than accidentally saving your file while
you're editing it and bringing down your daemon.

You could expect everyone to adopt new practices for editing the
configurations, but the behavior would be very surprising to anyone used to
the old way.

~~~
stormbrew
So I have not yet had to use systemd in any serious way, so I may be
misinterpreting here, but I think this:

> ... and config/daemon reloading as things that could be made automatic, I'm
> assuming with e.g. inotify change events.

is a misinterpretation of the author's complaint. It sounds like with systemd,
if you tell it to restart a service it will continue to use the old definition
until you run a separate command to 'reload' it (and, presumably, all other
configurations). On top of that, it indicates its knowledge that you've
changed the file by telling you to run the aforementioned reload command.

No inotify seems to be involved in what he wants, which is that the reload
command use the new configuration. Hell, be clever and use the old
configuration's stop mechanism and the new one's start mechanism or complain
if the restart mechanism differs or something, but a message telling you you
didn't do something you almost always want to do is a pretty obvious smell for
a UI problem.

I deeply dislike the similar behaviour of upstart, fwiw. In order to reload an
upstart init script you have to stop and start it, restart uses the old one. I
have spent annoying amounts of time wondering why it was doing it wrong.

~~~
XorNot
Because systemd is event-driven, you can't actually be sure the service file
won't be re-used in the running configuration - or that it won't trigger other
service reloads/starts/stops due to its dependency specifications. Ergo
systemd requires an explicit reload to commit the state of the unit files once
you're satisfied they are as intended.

This is very important when you consider that unit files can kill other units
on their conditions - I've used this feature in particular to make sure nginx
goes down if a mountpoint becomes unavailable or the servicing process dies
(and systemd can't restart it). This is extremely useful because it means a
load balancer won't send requests to a webserver in an improper state. But it
also means that while editing those config files, I wouldn't want systemd
auto-reloading everytime I saved.

~~~
digi_owl
And in the end i will gladly trade a few seconds longer boot for a system i
can actually reason about rather than treat as some kind of black box voodoo.
The latter is why i moved away from Windows in the first place.

~~~
XorNot
It's definitely more then a few seconds (systemd boots fast), but more
importantly reasoning about unit files is a lot easier then reasoning about
the init-script ordering.

With a unit file I can just declare the conditions under which it should run
or stop. If the system doesn't achieve those conditions, then I can solve that
problem - rather then having my unit run before the system is ready to do so.

You're not really reasoning about your system because you can say "this runs
after this" if you don't also express all the dependencies and failure
conditions.

------
keypusher
I agree with most of this, especially the fact that complexity has simply been
shifted to other places. It's much easier for me to read a systemd unit file
than it was for me to read a complex set of init scripts. The problem is that
when I have 10 or 20 units with interlocking dependencies, it's an absolute
nightmare to try and untangle because I have to jump between so many different
files. Having to specify After=X and Requires=X seems like a prime example of
optimizing for the 1% usecase. 99% of the time, when A must start after B,
it's _because_ A requires B. Having to specify both is something that is
easily and often missed, and a hard problem to track down if you didn't read
the documentation carefully. There's also the problem that it seems to be
metastasizing and taking other parts of the OS. The longstanding
/var/log/messages is now replaced by journalctl tool, and the logs are
actually in binary. The venerable "hostname" command is now "hostnamectl"
because it must go through systemd. They have also replaced chroot with
systemd-nspawn, and made it so you cannot even use systemd while in a normal
chroot!

~~~
vacri
$0.02: journalctl isn't even tab-completable until you've nearly finished
typing it. :)

~~~
ibotty
depends on what you have in your path.

~~~
yellowapple
I feel like systemd's tools and Emacs are on a race to achieve the title of
"only program(s) necessary in one's path to have a fully-featured operating
system". :)

------
empressplay
I don't "hate" systemd either, I just think it's a bad approach. It flies in
the face of the "open architecture" concept and stifles innovation. It
discourages users from learning about how their operating system works, and it
unnecessarily puts too much control of a fundamental component of the OS in
the hands of a too-small number of people.

None of these reflect the Linux I grew up with. Thus, I am not a fan of
systemd. #notmylinux

~~~
cubancigar11
ossreality you are [dead]

------
ghshephard
There is something epically beautiful about OpenBSD's consistency over the
last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100%
efficient with a circa 2015 OpenBSD system, despite the absolutely massive
number of improvements and changes that have been made with the operating
system.

Once systemd starts to get traction, it's cognitive overhead is going to
become a real problem for sysadmins who want to be able to model the entire
boot process and run-state in their head.

For better or worse (I honestly don't know which, btw), you are going to have
to start to trust the operating system to manage its boot process/run-state
correctly rather than having it be a direct implementation of your mental
model. (I would argue other *nix Operating systems, like OS X, have, to some
degree, been doing that successfully for a while, so it's certainly possible -
just not clear whether you want that type of behavior on your server systems.
I guess time will tell.)

~~~
stephen_g
I'm not a professional sysadmin, but as a developer with a bunch of virtual
servers systemd has only made things far easier.

Writing init scripts used to be a real pain, now I can set up a unit file in
two minutes and it works...

Maybe there's something to be said for "sysadmins who want to be able to model
the entire boot process and run-state in their head" but with correct
information about dependencies and so on, I personally think that's something
computers are a lot better at solving.

~~~
anko
> Writing init scripts used to be a real pain, now I can set up a unit file in
> two minutes and it works...

This.

I'm not saying systemd is the best answer, but I really think sysadmins could
learn a thing or two from developers. Nearly every custom init script I've
ever seen has bugs, and isn't portable between systems. Where are the unit
tests? Code reuse? Focus on maintainability/readability?

Shell scripting used to be amazing, but as a language these days it's behind
the times.

~~~
thaumaturgy
Sysadmins would say that developers could learn a lot from them. Like,
documentation, maintaining backwards compatibility, sane upgrade processes ...

Don't throw stones in glass houses and all that. We all could stand to learn
things from other people.

Sure, sysadmins could stand to be better programmers, but software developers
tend to forget that software is just a tool, and sysadmins use it like a tool.
They just want to get in, get out, and move on to the next problem, so for
them, certain best practices in software development aren't all that
attractive.

~~~
EmanueleAina
> but software developers tend to forget that software is just a tool, and
> sysadmins use it like a tool. They just want to get in, get out, and move on
> to the next problem

Which is exactly why developers don't get to write any documentation other
than the bare minimum: software for the client is just a tool, once it is
running they want developers to move on to the next problem, not wasting time
on any additional documentation (which, arguably, is not strictly a developer
task, more a QA one).

------
stoplight
Am I missing something? The author states:

> Try to find the answer to "which units are going to be started on next
> boot?".

Isn't this just `ls /etc/systemd/{user,system,network}/ __/ *` (bah HN
formatting is messing this up)

Also the other states:

> Speaking of which, why is systemctl daemon-reload even a thing?

Because configuration changes while things are running. Otherwise we wouldn't
need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the
man page:

> After the units have been edited, systemd configuration is reloaded (in a
> way that is equivalent to daemon-reload).

As for systemctl edit, it allows you to add diffs to the unit file. For
example, let's say I am using redis and I want to ensure it always restarts
(for whatever reason). Rather than manually editing the unit file (which will
have issues if an upstream change happens), I can simply use systemctl edit to
add a diff for my change. This way I can still maintain compatibility with the
upstream unit file instead of having to deal with potential conflicts. It's
not so much babysitting the user as it is a potentially better experience.

~~~
ploxiln
> Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN
> formatting is messing this up)

Nope.

There are many virtual units for which there are no files. One example is the
on-demand getty units. There are two for "plymouth" boot-splash stuff (I see
these attempted-and-failed units on archlinux where plymouth never exists).
There's some autofs thing. There's auditd.

I'm actually not booted into linux right now so I'm struggling to remember the
specifics... but if you also count all the simple mounts and devices which
clutter up the output of "systemd --all" as "units which are not files in
/etc/systemd" then the count is around 100.

~~~
INTPenis
Couldn't/Shouldn't this be solved with some script that traces the
dependencies of units?

I'm not familiar enough with systemd to understand how to trace dependencies
and create a complete list of all units that will run at next boot but I
expect this to be doable by someone with that expertise.

~~~
RVuRnvbM2e

      systemd-analyze dot --order | dot -Tsvg > /tmp/system.svg
    

The resulting dependency diagram may look complex, but consider that there is
no equivalent functionality for SysV init scripts despite the fact that _they
have the same level of inter-dependent complexity_.

~~~
dvogel
The complexity of the dependency graph produced by system-analyze is not
present in most sysv init systems. That complexity is mostly a reflection of
the efforts to make system services boot in parallel. Most sysv init scripts
were blocking and executed serially, which is what allowed the simple filename
prefixes to be used for ordering.

What to see your entire sysv init, as it will run every single time?

    
    
        ls -1 /etc/rc3.d/[SK]* /etc/rc.local | xargs -- cat | less
    

Obviously, substitute whichever runlevel you're concerned with.

------
exelius
This is the first anti-systemd article that I've read that focuses exclusively
on the technical issues with it (well, mostly: the last one kind of gets
touchy on the politics). And this article is a good summarization of them.

Linux in the server world is rapidly turning into a thin platform hosting
containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a
lot more sense if you consider it in that context: a container can use systemd
to have the host start a monitoring process whenever any processes are
executed, etc. Sure, this probably could have been grafted on to sysvinit, but
it would have been an ugly hack just like every other thing that's been
grafted on to sysvinit.

Linux everywhere else but the server world is all about low power usage and
tight integration with custom hardware. Embedded devices, mobile phones,
tablets, wearables, etc. All of these use cases demand an init system that is
aware of and able to manage the system power state as a gradient, not a binary
value. Again, this could probably be hacked on to sysvinit or the kernel
itself, but would require big kernel changes and likely a fork for "Mobile
Linux" and "Server Linux" as the market begins to demand power-aware
schedulers, memory mappers, etc.

If the computing world were to remain in a paradigm where we run small
physical or virtual servers dedicated to tasks, then sysvinit would be fine.
But that's not where we are today nor where we will be, and sysvinit simply
isn't flexible enough for a lot of the use cases where Linux is seen today.
The *BSDs exist if you want a rock-solid and simple x86 Unix system for
hosting traditional applications in a client-server setup; but if you want a
flexible platform for building arbitrary products, Linux is the way to go.

~~~
jeffreyrogers
Thanks, I think your perspective on the different use cases for Linux vs *BSD
were helpful and something I hadn't seen all in one place before.

------
davexunit
Some of the complaints resonate with me. In particular, the limited power of
systemd's unit file DSL is why I think it's better to allow services to be
written using a general purpose programming language. GNU dmd, while still not
developed enough to do cool things like socket activation, gives the user the
full power of Scheme to configure their system services as they like. I run it
as PID 1 on two of my machines, and I also run it as an unprivileged user to
manage my gpg agent, emacs daemon, offlineimap, mpd, development web servers,
etc. on all of the computers I use, including at work. I think people that
aren't happy with systemd, that are also interested in rolling up their
sleeves and hacking on an init system, should give dmd some love.

[https://gnu.org/s/dmd](https://gnu.org/s/dmd)

------
devnonymous
One of the more sensible ^rants^ I've read against systemd (it is KISS for
some weirdly convoluted definition of KISS). Too bad these naysayers are
not/will not be taken seriously.

~~~
vacri
The naysayers are taken seriously, but they're in the decision-making
minority. Linux distro maintainers wanted to move on from SysV Init, and
systemd looked promising. Just because the naysayers didn't get their way (and
on some distros, they did) doesn't mean that their criticisms aren't noted.

~~~
thaumaturgy
Which distros? Slackware is the only near-mainstream Linux distro I know of
that is even possibly not moving immediately to systemd, and even then, the
Slackware folks have said that once it becomes too difficult to maintain
upstream packages, they'll switch too. They're just being pragmatic about it.

~~~
cubancigar11
Gentoo by default prefers OpenRC over systemd, though you can chose which one
you want while installing.

~~~
digi_owl
And gentoo had to jump through hoops (to the point of forking udev) to be able
to continue to do so.

The whole systemd vs sysv back and forth is a smokescreen, because while sysv
stops at init systemd continues on to cron, networking, sessions, dhcp, dns,
/dev, and soon to be ttys etc.

And while the kernel is maintained under the rule that change do not break
user space, systemd developers seem to do changes with a permanent "deal with
it" meme.

------
belorn
With System V and Debian, one added some new apache or bind configuration and
then called _invoke-rc.d daemon reload_ to inform the daemon to reread the
configuration files.

With systemd, you do the exact same thing and then call _systemctl reload
daemon_. Is the author making an argument here based some other distributions
way of handling System V?

~~~
JdeBP
No. The author is not getting reloading the daemon's configuration mixed up
with reloading systemd's configuration. You, however, are. The systemctl
manual page warns about this mistake. See what it says under _daemon-reload_.

------
xroche
> nearly everyone (or at least the most vocal crowd) seems to either love it
> or hate it

"At least the most vocal crowd". Which means that most people DO NOT CARE, and
the systemd war is beyond ridiculous.

As Linus said, > "I don't actually have any particularly strong opinions on
systemd itself."

~~~
jfindley
The systemd war is probably the best thing that could have happened to ensure
widespread adoption of systemd. It allowed the supporters to lump anyone with
any concerns or objections in with the frothing-at-the-mouth haters, and
completely ignore them.

I don't hate systemd. I like what it's trying to do, and I don't hate the big-
picture implementation either. But I, and many others, have a bunch of
concerns around some specific details of the system, that got ignored and
swept under the rug in the tide of vitriol between the two sides of the "war".

If the discussion had been more civil, maybe the more rational objections
might have got heard, and we might have been able to pressure Lennart and Kay
into not rolling their own, un-reviewed, crypto for journald[0]. We might have
been able to avoid some of the feature-creep[1] that seems to have grown out
of a NIH-mentality, and a better relationship with the community might have
made the core developers more willing to play nicely with others[2][3].

0: [http://lwn.net/Articles/512895/](http://lwn.net/Articles/512895/) 1:
[http://www.freedesktop.org/software/systemd/man/systemd-
reso...](http://www.freedesktop.org/software/systemd/man/systemd-
resolved.service.html) 2:
[https://bugs.freedesktop.org/show_bug.cgi?id=76935](https://bugs.freedesktop.org/show_bug.cgi?id=76935)
3:
[https://bugzilla.redhat.com/show_bug.cgi?id=1116651](https://bugzilla.redhat.com/show_bug.cgi?id=1116651)

~~~
EmanueleAina
Why is resolved feature-creep? It's rather nice to have working name
resolution out of the box when coupling it with networkd and firing up a
container.

I mean, it's not my standard usecase in this moment of my life, but I see how
it can be useful.

(Also, your last link reports that "This bug is for livecd-tools which has
been fixed", I don't know what's the point you're trying to make.)

------
vezzy-fnord
To all those who complain about unreadable initscripts, please see:
[http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/run-
scripts-and-service-units-side-by-side.html)

------
Tiksi
About a year ago, we started switching over new servers to systemd instead of
openrc at work. I knew sysv/openrc/bsdinit and I liked them so for the first
month or two I utterly despised systemd. (Plus as a sysadmin it seems like I
have to hate it or risk losing my linux card) I just wanted my damn scripts
back instead of dealing with the .ini-inspired config file crap. If I had a
choice at the time, I would've been willing to move to busybox-init just to
get away from systemd. Had I spent less time complaining to my coworkers about
how much it sucked, I probably would've written this post myself. But little
by little it grew on me.

 _Oh, so if an nfs mount fails on boot, it 's not going to just sit there and
hang? I guess that's pretty cool, saves me from having to throw a console on
it while muttering under my breath. And it didn't start nginx either, so it's
not going to serve a half broken site and tell the loadbalancer all is good?
Maybe it's not all that bad. No no, what am I thinking, this is still crap, I
could've written all this in to the init scripts (but I didn't). _

_This client 's service is irritatingly unreliable, maybe I should write a
wrapper to supervise it. Someone must have done something like this for
syst... Restart=OnFailure... well that's nifty._

 _Ugh, monitoring daemon ate up all the memory again, why can 't the vendor
get their shit together or the client switch to something that isn't useless.
Guess I'll google some ideas for a watchdog script. Hmm, looks like I can just
throw MemoryLimit and Restart=onfailure in the unit? No way it's that easy.
(it was)_

After a couple months of this, systemd actually started to seem useful, I even
started having a little bit of dread when hopping on an older server and
having to deal with openrc. All of the complaints here really seem off base to
me now that I've had a chunk of time to figure it out. Init scripts pissed me
off when I didn't have much experience with them too. Now, thats not to say I
like everything about the systemd switch. netctl is utterly worthless for
anything other than a static ipv4 address (and reenable, really?). I still
forward all my logs to syslog, because I prefer text files (and all the
awk/sed/grep/cut/sort/column/etc goodness that comes with them) for anything
more than running `systemctl status <service>` and seeing that I accidentally
the config file for something.

I also don't buy the whole "It should be on desktops, not servers" because I
don't see much of an advantage for desktops, other than maybe the trivially
faster boots. Wifi is a pain in the ass with netctl and netctl doesn't seem
play well with anything else. But for servers, I've found it to be pretty
awesome.

To address a few things straight from the article that I disagree with:

 _> At least one Debian package (memcached) is already invoking a wrapper
script from ExecStart._

This is exactly why I don't understand the whole argument around it being
inflexible. If you need to call a script that does some setup that's
incompatible with systemd, call the script? It's no different from helper
scripts that many packages used with init scripts. If you still want to do
some checks and call start-stop-daemon, go right ahead, nothing is stopping
you. It seems pretty strange to consider it a fault that you can't use a bash
script, and then complain that you'll have to use a bash script.

 _> Here, let me helpfully tell you that you should run systemctl daemon-
reload, but perform the action you requested using the old configuration
anyway. _

This really seems like a trivial complaint. I guess you could always alias
systemctl="systemctl daemon-reload; systemctl" if it's that much of an issue.
Personally it's saved me after an accidental :wq (damn that muscle memory).
"File has changed on disk" _uhhh it shouldn 't have. crap._ I guess it's a
matter of preference. Also I didn't even know systemctl edit was a thing. That
does seem kinda pointless, but it also seems kinda pointless to be bent out of
shape over it. Do you also cat `* * * * * command >>
/var/spool/cron/crontabs/$USER` because crontab -e is babysitting you? (I used
to do that, but because e and r are too close together and reconstructing a
crontab from logs is painful. Now I just alias crontab="crontab -l; crontab")

 _> Now, systemd does rely heavily on D-Bus_

I've never run into issues with it, but I do agree with you on that point from
a philosophical standpoint.

 _> And yes, you can avoid the whole issue just by masking any units you don't
want to start, but that's missing the point. _

The only point I see is that it's different. Of course whatever you're used to
is going to be more effecient to you than something new.

 _> I believe it creates more problems than it solves. Sadly, many of those
problems will take years to become apparent, by which time all the major Linux
distributions will have fully integrated it._

Well it definitely seems to solve more problems for me than it creates, and
saying those problems will only be apparent years down the road is not only
impossible to argue against, it's a hand wavy cop out of "Trust me, its just
bad! Because reasons!" However this does touch on what is probably my biggest
gripe with systemd, and that is that ALL the big distros seem to be switching.
Granted I don't mind from a having-to-use-it angle, since I personally prefer
it and would probably stick with distros that do anyways, but it does give me
a certain unease, it may be my choice but it shouldn't be the only one, and
I'd have the same problem if it was sysv that everyone switched to.

All in all, these complaints really just seem like complaining that it's
different. And it is different, but that doesn't necessarily make it better or
worse, just takes time to get used to.

~~~
digi_owl
You either must have gotten in late, or been exceedingly lucky, as failing NFS
mounts is one of those things systemd downright hates.

People have had whole boxes fail to come up because of a NFS mount that didn't
work, and therefore the unit file didn't come up roses, and so systemd decided
to abandon ship and present the admin with a borked minimal console.

One early fix, a brute force 30 second kill timer on every unit file.

Went over well with one Fedora Alpha (lucky for them) where said timer tripped
on the post distro upgrade house cleaning unit.

------
pjmlp
I don't care about systemd, as I want to use OSes that embrace modern
architectures, unikernels, containers, safer programming languages, improved
UI stacks,....

This rant is a good example how luddite users rather stay stuck in a UNIX
System V world with their green phosphor VT100 terminals.

~~~
digi_owl
Thing is, Linux used to be flexible. This because of some stuff it inherited
from Unix about user space being made out of loosely coupled parts with
solidified interfaces between them.

Meaning that it could accomodate both the latest and "greatest" coming out of
the labs, and the tried and tested stuff that had been sitting in production
for a decade.

systemd instead gloops it all into a lightly coupled shoggoth of a project
that is chasing the future come hell or high water.

------
eleitl
Pretty much the same reason why I'm slowly moving to FreeBSD. OpenBSD is
another possibility.

------
mm_aa
It seems that the author completely disregards the modern tendency to treat
boxes as commodities. While pondering a "what's going to start on this
particular machine" question is interesting in the "old world", it is hardly a
question anyone asks when your fleet starts to be measured in tens of
thousands of cloud instances.

~~~
digi_owl
No, his issue is that because others choose to do so he has to do so because
the fad of the year is tramping all over the alternatives.

------
tfft
I love the valid html/css icons at the bottom while the whole page is just a
yellow text on a black background.

------
jingo
"It babysits its users"

------
monksy
Thats one responsive site!

------
tilt_error
My eyeballs just exploded... Unreadable.

~~~
dredmorbius
Readability's bookmarklets help:
[https://www.readability.com/bookmarklets/](https://www.readability.com/bookmarklets/)

(But, yeah.)

~~~
Reefersleep
The newest version of Firefox has a little icon resembling an open book at the
right side of address field that does something similar. Quite handy :)

~~~
dredmorbius
Nice. I'd prefer that was the _default_ browser view, frankly.

------
stefantalpalaru
Why would you punish yourself with various *BSDs when you can have OpenRC and
more advanced ports on Gentoo? Do people really associate systemd, Gnome and
other nuisances with Linux?

~~~
geggam
Punish ? .... BSD is extremely user friendly. It just seems to be picky at who
it calls friends. They ONLY reason I still use Linux anywhere is because I
have to keep my skills for it fresh since its where I make a living.

The metric I like to use for adopting new processes / services is pretty
simple. I have _____ problem. What tool solves that problem for me.

In my case systemd solves nothing and creates more.

~~~
digi_owl
> Punish ? .... BSD is extremely user friendly. It just seems to be picky at
> who it calls friends.

I seem to recall the same line being used about (GNU/)Linux at one point.

------
octref
This page's horrible readability is a perfect reflection of the kind of folks
that dislike systemd.

Yeah, newcomers to the Linux land without the expertise you guys acquired
through 10 years of using Linux, would apparently appreciate how easy it is to
manage a server by invoking some lengthy commands they learned through reading
the often overly-dense manual instead of `systemctl start/stop x`.

Nowadays some of those so-called "hackers" tend to ignore the part of work
that makes the user experience better. They claim that they want simplicity
and avoid bloat but most of the times they are just being lazy and not
sympathetic to their users.

I'm not saying that things should be dumbed down to clicking GUI buttons on
Linux. But if you want your program to become mainstream you need to think
about providing good and practical docs and making your program easier to use,
even for text-based programs.

Accept that most people would like Bootstrap'ed sites more than yours:

    
    
      body
      {
        background-color: #080808;
        color: #ffff70;
        font-family: sans;
      }
    
    
    

That's why I opt for Ubuntu 15.04 instead of 14.04 LTS on my VPS, since 15.04
has systemd.

~~~
cthalupa
Are we really using website design choices as a valid target to discredit
someone's opinion on the technical merit of an init system?

Can I use Lennart's inability to buy a properly sized polo as a reason why
systemd is bad?

Yeah. The guy has an ugly website. But he has specific points about mistakes
that systemd didn't learn from and is repeating. Did he list 'it's too user
friendly' as one of those mistakes? In fact, one of his core arguments is that
there will actually be an increase in complexity and reduction in user
friendliness due to design choices that have been made.

~~~
octref
I'm saying that, if people keep responding to those less-experienced Linux
users who complain init scripts too complex by saying "Quite. Deal with it."
like this author ([http://www.steven-
mcdonald.id.au/ugly.shtml](http://www.steven-mcdonald.id.au/ugly.shtml)), I
fail to see how systemd is gonna fail.

My comment is not about design choices but attitude and sympathy to users.
This is not intended as an ad-hominem.

The author seems to think systemd "babysits" its users, but as a user I find
systemd "cares" about its users.

