[Tfug] Systemd: the biggest fallacies

Sat Sep 27 12:19:11 MST 2014

Hi John,

Thank you for taking the time to read my article and share your feedback!

My point for writing the article was to accumulate some of the more common
fallacious arguments I've seen for promoting systemd, so I can simply refer
people who make them to sections of the article.  Don't get me
wrong--systemd does a good job for the people who need it, and it has very
real use-cases that other systems do not meet.  I'm just tired of repeating
myself to its well-meaning advocates.

I agree that some fallacies are more fallacious than others.  However, I
was motivated to include them because they are particularly persistent.
I've made all of these counter-arguments at some point, and they were
well-received when they were made (although you wouldn't get that
impression if you see what the /r/linux thinks about it).

Regards,
-Jude

On Fri, Sep 26, 2014 at 11:49 PM, John Gruenenfelder <jetpackjohn at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20140927/06400a94/attachment-0002.html>