

The systemd fallacy - uggedal
http://monolight.cc/2011/05/the-systemd-fallacy/

======
s_tec
It's obvious that the author of this article has never actually used systemd.
For example, he complains that the startup sequence is "written in C," so the
only way to change it is to recompile systemd itself. This is utter nonsense;
systemd uses tiny config files called units to configure everything, so there
is no reason to recompile. It's hard to take these complaints seriously when
the author clearly hasn't used the thing he's complaining about, or ever read
the man page.

A few months ago, I actually installed systemd on my laptop to see what the
fuss was about. It was one of the best things I've ever done. Before systemd,
system bootup was controlled by a bunch of shell scripts that made no sense to
me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-
looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of
trivial config files like this:

    
    
      [Unit]
      Description=My Daemon
      
      [Service]
      ExecStart=/usr/bin/mydaemon --some --flags
    

So, this idea that systemd somehow makes the system more complicated is
utterly false; systemd is a great simplification from an admin's point of
view. Sure, the systemd daemon might be a bit larger than the classic init
daemon, but RAM is cheap these days and admin's time is not. I think this is a
good tradeoff.

~~~
maratd
> system bootup was controlled by a bunch of shell scripts that made no sense
> to me

And this is the problem. You're guilty of the very thing you're accusing the
author of.

Some of those shell scripts are very simple and can be easily replaced with a
configuration type file. Most are not. They do a ton of stuff, like create
lock files, pid files, check for dependencies, check for existing processes,
etc etc and couldn't be properly replaced by a configuration block.

Using shell script gives you unbelievable flexibility in how you start a
daemon that can never be replaced by a configuration script.

So what happens? All that complex stuff stays in that script you can't
understand and now you've added an additional layer of complexity that wasn't
necessary.

Every additional layer adds a point of failure and in my humble opinion, isn't
worth the additional user-friendliness.

~~~
jeltz
My personal experience with writing sysvinit scripts agrees pretty well with
s_tec's view. Those shell scripts would easily have been replaced by trivial
.ini files and contained several bugs before I managed to figure out how to
use start-stop-daemon correctly and fix some typos.

I have not used systemd myself but it seems trivial in comparison to my
experience writing sysvinit scripts.

------
rwmj
It really matters for servers how long they take to boot, particularly when
you look at virtual machines / clouds, where they are thrown up and torn down
rapidly.

------
count
Switching from shell to C is a problem from DoD users - you aren't allowed to
have a compiler installed on a production machine, so to edit your init
process (I guess they aren't scripts anymore!), you'd have to have a separate
machine to do the compiling.

~~~
4ad
Not installing compilers on production machines is a relic from 1990 that
doesn't impact security in any meaningful way. If I have access to your
machine I can upload a compiler and/or I can upload binaries generated by a
compiler at my end of the pipe.

~~~
binarycrusader
Relic or not, that's the way things are in many businesses and governments.

------
ootachi
I can't take this rant seriously when it dismisses the importance of fast
startup. "You shouldn't care if your system starts up slowly" is just
untenable.

~~~
count
The multi-second difference in software start time, after waiting 5+ minutes
for my RAID to initialize and all the onboard crap to check out is really
negligible.

~~~
binarycrusader
Except if you're using ksplice on Linux to start a new kernel, you won't be
waiting for RAID to initialise, which means those seconds do matter. (Or fast
reboot on Solaris.)

In many SLAs, the amount of time the system is unavailable can count against
the company providing the server. Minimising the amount of downtime is a win
for everyone.

~~~
count
If you're basing downtime avoidance on 'how fast I can boot', you're doing it
wrong.

