[Discuss] SysVinit vs. systemd

[smallm at panix.com (Mike Small)]

Tom Metro <tmetro+blu at gmail.com> writes:

> http://www.infoworld.com/print/248950
>
>   Mike Gancarz sums up the Unix philosophy: 1. Small is beautiful. 2.
>   Make each program do one thing well. ... We have built the Internet
>   and all modern Internet services on those principles. Systemd's design
>   and implementation violates nearly all of them.
>
>   Should it be a surprise that so many long-term Unix and Linux
>   developers, architects, and administrators recoil at the thought of
>   something like systemd? It might seem that the design of systemd
>   purposefully dispensed with the wisdom of 45 years of Unix development
>   and struck out in a different direction just to spite the old guard.
> [...]
>
>
> Opinions?

I'm inclined to ignore systemd, but my reasons only partly overlap with
his. The Unix design philosophy can be nice, but my favourite program is
GNU emacs, so I'd be a huge hypocrite to take that line.  The trouble
for me personally is that Redhat and other developers of systemd seem to
have needs and preferences way out of sync with mine. I'm not looking
for a Solaris replacement, I don't run a web server, and I don't have a
smartphone. Basically, I'm a hobbiest so the main thing beyond basic
usability is that the system be understandable when I get around to
looking into how it's written. Point by point...

1. The major advertised advantage seems to be boot time. Well, my way of
starting up involves turning on the computer and then looking for my
glasses. So I could almost boot Windows without getting too annoyed
(until after it starts, that is). OpenBSD and Slackware each boot up
acceptably fast IMO even when I already have the glasses on the nose.

2. Another advantage seems to be the ability to lazy load services. I
find this kind of interesting in a listen to a lecture about how it
works kind of way, but waiting to start, e.g., sshd until I ssh to a box
seems approximately of zero benefit to me given demand loading vm
already exists.  Same with my mail daemon, ntpd is n/a since it's needed
right away, what else is there for a simple home user?  If it can lazy
load policykit and consolekit, as in never load them, that would be
swell (it replaces these, doesn't it? so points for that at least). I
guess it can't lazy load dbus since it's intertwined with that (so much
it so that it wants it in the kernel -- as my son says... what the?).
Btw. anyone know if emacs or firefox will go into a funk if you don't
run dbus? I think those are the only programs I use that depend on
it. I'd like to stop it running cause it starts things I asked not to
start in the init scripts.

3. While shell script seems kryptonite to Lennart Poettering (not to
make this personal -- he seems a likable enough guy), I'm now coming
around, finally, to appreciate sh for scripts. A small C init that hands
off to a bunch of shell script strikes me as almost exactly the right
design for my purposes.  If shell is too slow for you (doubtful for my
needs I would think), you should look at what the inferno people did to
byte compile it or try rc instead of bourne shell, which looks like a
genuine improvement. This is a breakthrough for me, I think, cause for
the longest while, after reading Olin Shivers scsh paper panning shell,
I figured I hated it and wanted a free system with all scripts in Perl,
Common Lisp, or Scheme. So he and I are walking in exactly opposite
directions on that issue.

4. I'm a little curious about the issue brought up about properly
shutting down processes, tracking pids across double forking, etc.  Yet
this is also not a problem I was aware I had.  I don't normally stop
daemons except at shutdown, and I've never noticed a problem with
that. Looking quickly at OpenBSD's /etc/rc script, it looks clean enough
in how it does shutdowns:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc?rev=1.441&content-type=text/x-cvsweb-markup
It meets the test of whether a casual reader can get the gist of it in a
few minutes. Systemd, not so much. With a quick browse of their source
code I did manage to find something shutdown related, but it's not
promising:

   "The scheme is very simple:
   *
   * To schedule a shutdown, simply fill in and send a single
   * AF_UNIX/SOCK_DGRAM datagram with the structure above suffixed with
   * the wall message to the socket /run/systemd/shutdownd (leave an
   * empty wall message for the default shutdown message). To calculate
   * the size of the message, use "offsetof(struct sd_shutdown_command,
   * wall_message) + strlen(command.wall_message)".
   *
   * To cancel a shutdown, do the same, but send a fully zeroed-out
   * structure.
   *
   * To be notified about scheduled shutdowns, create an inotify watch
   * on /run/shutdown/. Whenever a file called "scheduled" appears, a
   * shutdown is scheduled. If it is removed, it is canceled. If it is
   * replaced, the scheduled shutdown has been changed. The file contains
   * a simple, environment-like block that contains information about
   * the scheduled shutdown:..."

https://github.com/systemd/systemd/blob/master/src/systemd/sd-shutdown.h

5. I'm yet to see anyone convincingly defend systemd. Some of the
critiques are quite overheated, but the "myths debunked" always read as
bald face advocacy, more or less translating to, "fuck that argument, I
like how we did it," maybe adjoined to some hand wavy arguments about
being more unixy than unix or some bogus extrapolation from head being
prefered to sed 10q, or some such, to this large scale all C design with
daemons communicating via sockets or dbus being preferable too. (You may
convince me to use sed 10q with this argument.) If they only argued why
it's the right solution for them (for Redhat, for IBM, for Chrysler,
etc.), that would be fine, and possibly quite interesting. But the
arguments I've seen why everyone should want it are pretty damn
weak. I'll keep reading this thread, but so far more of the same.

This means that to fairly judge I'd have to try it. The only time I've
actually run it was to boot an OpenSuSE live cd (I needed to look into
how it looked in terms of /etc/SuSE-release vs. /etc/os-release
vs. lsb_release). Hard to judge from that since it had to boot from a
usb key and started up KDE desktop so any speedup in boot time was sunk
off the bat.  I must say I was thoroughly unimpressed with OpenSUSE,
though I don't know how much systemd was to blame for that. I tried to
set up my network card in a config file under /etc/ and expected to be
able to run ifup or something similar to have the right invocation of
ifconfig and route happen. Doing so gave a message that that's not
allowed because some daemon was managing the network for me. This after
actually finding a man page and template showing how to write the config
file. I threw up my hands and used the gui -- as far as I'm concerned
system setup requiring root should be done in a text
editor... always. Is this a systemd problem or a suse problem?

6. I'm not a huge fan of the C language. At the same time I want to read
the source code of the operating system I use. This means my preference
is that, as computers get faster, Perl, shell, Lisp, maybe Smalltalk, in
a pinch, Python, and maybe ML or Haskell occupy more and more territory
that previously was held by C. Systemd goes exactly the opposite
direction. GNU dmd, on the other hand, interests me, though there seems
not a lot to it so far (which perhaps is a good thing).

7. It's obnoxious to me that OpenBSD people that want to run Gnome
(mtier particularly) have to take time to write shims to substitute for
systemd. This is as much or more a problem with the Gnome project than
systemd, I guess.

I'll give systemd another look only after Patrick Volkerding adopts it
and then only if I don't first figure out a way to run OpenBSD on this
laptop my roommate sold me, the one with the wrong kind of video card
(NVidia) that pushed me to revert to linux (or use a proprietary driver
on FreeBSD) in the first place.

-- 
Mike Small
smallm at panix.com