was promoted as an init system that would speed up, modernise and
simplify booting. However:
It has not simplified it. With systemd things have become more
complicated and obfuscated.
Speeding up is marginal or negative if compared to Upstart or even
"Modernisation" is just a matter of taste for
More importantly, systemd is not an init system. It is a complete
administrative layer that seeks full control of the computer and
includes init tools as well as ever growing lots of other stuff.
summary, they have lied to us and that is why there is so much
they had say from the very beginning "look, we want to unify the
Linux user-land administrative landscape and we are writing massive
chunks of C code for so doing", things would have been very
different. There would have been opposition, obviously, but not so
much bitterness. But they have been cheating from the very beginning
and therefore we cannot trust them.
post one more systemd comment before the week is up on this comment
thread and it is regarding "UNIX Philosophy", wherein I
completely disregard "UNIX Philosophy" and mention "Linux
Linus Torvalds created the Linux kernel
(now with many, many other contributing as well) whereupon it was
promptly mixed with GNU utilities to make computer operating systems.
Although some people think GNU/Linux is some sort of joke, it really
isn't. And each "distribution" of Linux is a separate thing
even though they are all often referred to as "Linux".
upon a time one could find Suse making a united administrative system
with YaST, Mandrake with DrakeX, Red Hat had theirs, Slackware had
So this is nothing new.
What is new is an
administrative system that seeks (entirely on purpose) to make itself
indispensable and necessary by first presenting itself one way and
then co-opting other functions so that it must be included in all
Systemd intends to lock major software into
itself (so that the software will not function on BSD, Minix, or any
other platform) and make itself necessary to any Linux distribution
using those software packages. This is something that, I feel, is not
Are you seriously going to tell me
that systemd could not have been written to do what it does without
trying to make itself as necessary as the Linux kernel in any Linux
distribution? No, this was done completely on purpose.
prefer that "free software" is free to be used in any way
the user wants, not in the way they are directed to use it. I do know
that the is an "all Linux must be the same" group, but I
very much doubt that is really the same as the "systemd group"
that we will never really know about.
systemd and the *NIX philosophy (by G.Wolfe Woodbury on 2015-12-24
20:05:55 GMT from North America)
an early instigator of (pre)SysVInit, I am quite familiar with the
startup process. Systemd does its job and handles lots of "under
the hood" tasks fairly quickly and (not so) easily. I actually
do use systemd on a machine or two that run distros that use it.
main disagreements with systemd and its developers amount two two
philosophical choices. 1) A program should do one task and do it well
-- this is getting a bit harder, and systemd goes way beyond one task
(system startup) and doesn't do it that well. 2) The developers are
egotists and tend to dump scorn on the complainers, without regard to
thinking about the non-expert users; "If you don't like it, why
don't you write your own" was an (almost) direct quote from one
early in the quarrels over systemd.
did write my own, way back in 1981, and at the time the processor
speeds and programming techniques available made it an easy decision
to "punt" certain tasks (such as sequencing the order of
task startups) to the admin and the human mind. These days the
processors are faster and programming techniques are available to
solve the ordering problems with dependency declarations in the
startup scripts. Systemd is not the only solution that does this but
systemd goes way beyond just being a system boot solution and inserts
itself into the daily administration of the system. This "creeping
featurism" was long ago pointed out as a problem, and *NIX
programs were deliberately encouraged to avoid this sprawl.
"desktop environment" phenomenon does demand a greater
amount of integration, but DEs don't have to make a few programs do
all the work, they can, if properly designed, still adhere to the
trait of multiple programs working together, with each program doing
a well defined set of tasks and doing them well.
as designed, systemd seems to be fine, but all of the problems I've
had with systemd have related to three main issues, none of which
have to do with technical design:
systemd requires a massive amount of documentation because it throws
away everything that we've been doing for 40+ years in UNIX with
regards to system initialization. No matter how good your design is,
if you haven't completely documented everything, your design is not
useable. Let me give you one very simple example. Since 1995 (21
years), in order to diagnose kernel problems, people have done tail
-f /var/log/messages. I had a failing USB hard drive two weeks ago.
It was not easy for me to find the equivalent of tail -f
/var/log/messages to watch what new log messages would appear when I
repeatedly plugged and unplugged the device. You can use some tool to
bring up existing logs with less but this is not what I want at all.
I want to see new logs as they appear. This tool appears to have been
written by someone who casually browses through log files with less,
but who hasn't done much of any hardware debugging.
systemd hasn't taken the UNIX approach of carefully doing a little
bit at a time. It tries to be one massive thing that is foisted upon
you. Think of your vehicle. I don't care what type of vehicle you
own. Your steering wheel works the same way. Your cruise control
works the same way. Your windshield wipers work the same way. You
have a gas pedal and brake pedal that have worked the same way for
100 years. You could easily operate a car radio from a 1950's
classic. Basically, you could even operate a Model T with some level
of difficulty. systemd is the equivalent of foisting a space ship
upon us with a different way of controlling everything. The space
ship can take us to other planets, but it sometimes crashes because
it's difficult to control.
All complex systems have bugs. Inexperienced programmers tend to do
rewrites all the time because they're too lazy to learn what was
there and take the time to fix it. Rather, they do what they were
trained to do in school, always write something new from scratch.
Experienced programmers know how to become comfortable with existing
systems and fix them. The attitude of let's rewrite this or let's
rewrite that because we're much smarter than those people
is both the atittude of inexperienced programmers and petulent
teenagers when referring to grown ups. We now have this incredibly
complex system with tons of bugs and the grown ups who've been doing
programming for decades have to step in and figure out just what
these people have done and make it work well.
thing is, SysV was dumb.
All it did was execute a bunch of scripts in order, that's it.
as it turns out, being dumb can also mean being resilient! It was
very hard to break sysV, and even if you did, you only needed it once
- during bootup. Any failure in sysV stopped mattering once the
bootup was complete (switching run levels aside).
where the problem of systemd becomes apparent to me.
systemd for the whole duration of the system. Whereas the stupid sysv
only had to survive for a few minutes at most, systemd needs to be
stable for 300+ days (the mean time between two reboots in our
environment). It's literally a system critical component - any
failure in systemd equals or is even worse than a kernel panic. Once
systemd PID1 fails, you can not recover. You are very, very
Now, the proposed features of systemd make sense.
But in its current implementation, I only find it useful for driving
people away from using Linux in mission critical environments.
- take with salt, second hand.
Most of what I read about
is when SystemD does fail, it fails spectacularly in undefined ways
that are hard to figure out. The rest of the time it's just
What I've gotten out of it is that the makers of
SystemD don't appreciate well defined failure cases. As a system's
designer, most of what I do is defining failure cases, how to quickly
identify them and how to fix them. Anyone can make a highly
horizontally scalable system, kids stuff. The hard part is making a
system that you can fix in a timely manner when things go wrong.
have no first hand experience, I'm just saying this is the primary
pattern that I am seeing in complaints from server admins.
is not a bad idea, just a bad implementation.
48 • @36
systemd (by paoloschi on 2018-07-21 07:46:00 GMT from Italy)
If you prefer the old init system, then just use.
a detail escapes you: you are free to use systemd without any
interference from any other init sw and instead (me) we, who would
like to "just use other init", we find ourselves having to
divincolate from a growing number of packages that still force us to
install unwanted dependencies and various libraries belonging to
we are using a different init sw!
this little detail known to you?
you like to use systemd with the hassle of another sw init that
forces you to install unnecessary sw and therefore "harmful"?
your job was that of System Admin with the freedom to choose to only
administer non-systemd installations (because you find that systemd
complicates your daily tasks ...) ... nowadays you would be
unemployed: systemd has propagated with the logic of the monopolist
do not come and talk to us about freedom of choice or equal