[Tfug] Systemd: the biggest fallacies

[John Gruenenfelder]

On Fri, Sep 26, 2014 at 12:20:31PM -0400, Jude Nelson wrote:
>Hey everyone,
>
>As you might know, there's been a lot of controversy and drama over systemd
>this past year.  Since the author of systemd (Lennart Poettering) created a
>"Biggest Myths" page on systemd that is meant to be a summary rebuttal of
>anti-systemd concerns, I've taken the liberty of creating a "Biggest
>Fallacies" article that is meant to be summary rebuttal of commonly-used
>(logically incorrect) pro-systemd arguments.
>
>The article is meant to be continuously updated if I find more fallacies.
>Then, if you find yourself in a forum or mailing list and the discussion
>turns to systemd, you can just pass around links to this article instead of
>having to repeat yourself over and over.

Greetings,

I've been meaning to ask TFUG about systemd as well.  Somehow, I managed to
miss all the controversy until very recently.  In fact, I wasn't even aware of
sytemd until Debian switched the init system to a metapackage to choose among
the three available.

So, in my case, I actually *chose* to switch to systemd.  The description of
the package seemed interesting enough.  With some notable exceptions, I am
fairly pleased with it.  I agree with a lot of your blog post, but as I
haven't read much of or been involved in any of the debate, these aren't
arguments that I have personally encountered from others.

That said:

1) Complexity - I really don't see how anybody can reasonably argue that
systemd is not *more* complex of an init system than either sysvinit or
upstart.  It *does* seem to be well documented, but I've had to do an awful
lot of reading to learn how it works and it's split into a zillion pieces,
binaries, and files, and trying to figure out what part does what can take
a while.

2) journald - I completely agree with the anti-journald arguments.  Binary
logs are just plain bad.  In my experience, on my heavily hacked and updated
Debian system, the system either works or fails badly.  And when it fails, I
need to be able to find *some* way to read the logs, and text logs are
unquestionably easier to deal with.  If indicies are that important to you,
there's nothing stopping you from using/writing a tool that indexes the text
logs and stores the index in a separate file.

3) Gnome - Not really the fault of systemd, but I do agree that having Gnome
depend on systemd (by way of logind) is monumentally stupid.  The desktop
environment (any of them) should never have a dependency on the init system
(any of them).  I can't think of a good logical argument for it.


For most of the rest, I don't mind either way.  Systemd just has a different
way of doing init and that's not a bad thing.  And I don't mind having to read
manpages to learn a new system, understanding that part of the reason it seems
so time consuming is just because I've used sysvinit for ages and don't need
to read about it anymore.

I don't personally have a problem with Lennart Poettering, either.  I don't
blame him for the audio issues a few years back.  Rather, I blame distros that
jumped onto PulseAudio way before they should have using the argument that if
we all switch to it now, that will spur development.  It *did*, but also
forced users to put up with broken audio for quite some time.  In the end, I
happen to like PulseAudio a great deal, but the ends don't justify the
original choices made.  Perhaps he had more to do with those choices than I'm
aware of, but many distros made the change I don't see him having *that* much
influence.


Also, on the other hand, some of what I like about systemd:

1) Speed - I wasn't looking for a faster system boot and didn't know that
would be a benefit.  Having an SSD mostly took care of that issue two years
ago.  However, under systemd my laptop now goes from hitting enter in grub to
my X login in under five seconds.  That's a nice bonus.

2) Power management - I wouldn't have expected it to make much of a difference
here, but it did.  I use Gnome 3 (with lots of extensions) and for quite some
time now, simple features like logging out or suspending/hibernating have
continued to be problematic and I haven't had much luck tracing the cause.
After switching to systemd, all of that began to work properly.  In fact, the
only power issue I have remaining is that the machine insists on hibernating
when I close the lid rather than just suspending.  I don't need the kernel
writing gigs of data to my SSD by hibernating unless I really want it to do
that.


And, some issues I'm still having with systemd:

1) Socket clobbering - This started right after I switched so I'm fairly
confident that systemd is the cause.  Right now, it is manifesting itself with
ssh-agent, gpg-agent, and emacs --daemon.  All three put access sockets in
subdirectories of /tmp so that utilities can communicate with the programs.
After I suspend and resume, these connections are almost always broken.  The
programs are still running and the socket files are still present (usually),
but somehow the communication between the two inevitably fails.  My workaround
has been a script I wrote to kill all the agents and then restart them.  Then
I run an alias in each open terminal to set the new environment variables.
It's quick, but still annoying, and I wonder what else that is using /tmp
might be silently breaking.

2) user tmp dirs - I read that systemd provides per-user tmp directories on
its own so I disabled the libpam-tmpdir module.  This PAM module would
automatically create a /tmp/user/<UID>/ directory for each user when they
logged in and then removed it on logout.  As long as programs didn't hardcode
using /tmp, files would go to the right place.  Turning off the module stopped
this from happening, though, and systemd isn't doing it on its own.  It's not
a critical issue, of course, and probably just some config option I need to
turn on.


Any up-and-coming systemd gurus have any suggestions about #1?  I've
investigated it about as much as I can on my own... I suppose it's time to
file a bug report.


Jude, concerning your blog article: it's a good start, but I would be careful
about spending too much time refuting some of the "stupider" arguments.  For
something this technical, I think (or at least hope) you can count on the
users and readers to spot stupid and/or trollish arguments when they appear.
If you throw yourself into refuting them, you might inadvertently come across
as being just as petty as the trolls.  You're not, of course.  :)  You just
don't want random Internet citizens to get that idea, either.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max