[conspire] "The Tragedy of systemd" ... & livingcomputers.org Living Computers Museum+Labs

[Rick Moen]

I wrote:

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
> 
> > Just ran across and watched this:
> > linux.conf.au 2019 — Christchurch, New Zealand
> > "The Tragedy of systemd"
> > https://youtu.be/o_AIw9bGogo
> > It's 47:17 ... but hey, YouTube - can speed it up to 2x,
> > and can also turn on the captions.
> > Anyway, fairly interesting talk/presentation on systemd.
> 
> Been making the rounds for a few weeks, yes.
> 
> Also, a pretty eyeball-rolling puff piece.  I really don't want to go
> through yet another dissection, though.

Well, not a dissection, but a few comments:


Date: Thu, 14 Feb 2019 18:12:29 -0800
From: Rick Moen <rick at linuxmafia.com>
To: tech at golug.org
Subject: Re: [GoLugTech] Look what I found - "The Tragedy of systemd!"

Quoting David Krauser via Tech (tech at golug.org):

> On Sunday, February 10, 2019 at 11:18 AM, Robert Lefebvre wrote:
> > https://www.youtube.com/watch?v=o_AIw9bGogo
>
> This was actually really good - given by a FreeBSD developer and,
> despite the title, is a very positive talk.

I'm sure Benno Rice didn't set out to create a propaganda puff piece,
and many of the details are sound and valuable, such as Poettering
having very closely modeled the project on Apple's launchd -- which,
starting with OS X 10.4 'Tiger' in 2005, replaced NeXTStep's BSD-style
/sbin/mach_init, BSD rc.d and init.d scripts, crond, watchdog daemon,
SystemStarter utility, inetd, xinetd, and atd.

By the way, Rice is incorrect in claiming that launchd is doomed to be
OS X-specific on account of reliance on Mach-specific IPC services from
NeXTStep / OSX's 'xnu' Mach-based kernel:    It's been ported to FreeBSD
several times, the first time being a Google Summer of Code effort when
launchd was brand-new.

Canonical, Ltd. claimed a Linux port of launchd was 'unacceptable' on
account of APSL licensing.  Near as I can tell, this is bullshit.
Although the APSL permissive licence is GPL-incompatible for purposes of
creating derivative works, I am unaware of any reason a port of launchd
to Linux would need to be derivative of any GPLed work.  (It's possible
there's a problem I'm not seeing.)

By contrast, systemd's dependence on Linux-specific kernel features
unlikely to be replicated elsewhere is much more severe -- cgroups, most
obviously, perhaps others.

So, that point of comparison is a little bogus.

But, getting back to the point, I would be slow to accuse Rice of
propaganda.  It suffices to just assume he's a BSD guy who genuinely
admires several abilities and features in systemd, likes to look at the
sunny side of things, and is either blissfully unaware of problems or
elected to omit them.

That having been said, if one _did_ set out to construct a propaganda
puff piece, it would resemble that talk quite a bit.   Specifically,
the best way to write propaganda is primarily by selective _omission_,
and making any distortions be relatively subtle.

I'm not going to plow through the whole 47 minute talk again in order to
go point-by-point, but a couple of items:

1.  He portrays, mostly by (ding!) omission and shades of implication,
the choice as having been between the systemd suite and antique legacy
code (implying but not citing SyssVInit), and critics as unreasoning
conservatives unamenable to change.  This is a really tiresome polemical
trick:  It was insultingly obvious in the 1990s when DJB software fans
deliberatly compared DJB's qmail MTA _only_ with sendmail, and his
djbdns suite _only_ with BIND, pretending as if modern alternatives to
both hadn't been out for many years.  This argument is, in short, an
idiot trap.

I find it just a bit more irritating than most Linux users would,
because, from 1994 onwards, when with misgivings I moved from Slackware
(using BSD init) to Red Hat Linux, I've _always_ considered SysVInit to
be fairly awful AT&T committee-writen corporateware, and rejoiced when
modern replacements emerged and started catching on (OpenRC, s6, runit,
etc.).    So, it's not like I'm just being an unreasoning conservative
unamenable to change when I remove systemd from my Debian systems and
replace it with OpenRC, and I feel like ringing Mr. Rice up and saying
'Who am I, then?  Chopped liver?'

2.  The touting of socket activation omits (ding!) the fact that we
longtime sysadmins have had that plus service supervision at our
disposal at least since invention of xinetd in the 1990s, but don't
generally _want_ that to be the default because of various operational
problems.   A number of best-of-breed service supervisors have long
existed that can be used a la carte by sysadmins wanting to do so.

3.  The touting of the systemd PID1-init's use as a cgroups manager for
purposes of container-software management omits (ding!) the existence of
other, a la carte cgroups manager and the fact that a cgroups manager
doesn't _have_ to run as bloatware in a PID1 init process.

4.  As mentioned, he just mass-omits (ding! ding!) pretty much all of
the characteristic systemd annoyances, like all the times sysadmins have
found themselves, while operating as the root user, told by systemd that
they were currently being disallowed access to single-user maintenance
mode because systemd had consulted with with PolKit (a related codebase
from the Freedesktop.org twinkies) and it said 'Root user?  Nope, don't
let _that_ user have root privilege!'  And one could go on for a while
listing the drawbacks, such as the huge dependency hairball systemd and
and related Freedesktop.org pieces introduces to distros' package
regimes, and the fragility and lack of sysadmin control that results.


And, when one _is_ doing a propaganda puff piece, which I'm assuming
Rice's presentation isn't but merely resembles, one always wants to play
the tone game:  pitching the piece as just constructive and analytics,
and broadly hinting that only hyperemotive ranters view things
differently.

There _are_, naturally, hyperemotive ranters.  They tend to be a lot
louder than those of us who just say 'That's nice, but I'd just rather
use a different modern init system, and my own choice of process
supervisor if any, and my own choice of cgroups manager if any.  Glad
you like that other thing.  Have a great day.'