Linux: concerns over systemd adoption and Debian's decision to switch [OT]

Thu Oct 23 17:43:03 UTC 2014

On 10/22/2014 03:51 PM, Barry Shein wrote:
> I wish I had a nickel for every time I started to implement something
> in bash/sh, used it a while, and quickly realized I needed something
> like perl and had to rewrite the whole thing.

Barry, you've been around a long time, and these words are pearls of wisdom.

This seems to be the reasoning behind replacing the spaghetti known as 
'initscripts' currently written in sh with something written in a real 
programming language.  Upstart and systemd are both responses to the 
inflexible spaghetti now lurking in the initscript system, of which the 
pile steaming in /etc/init.d is but a part.

> Sure, one can insist on charging forward in sh but at some point it
> becomes, as Ken Thompson so eloquently put it on another topic
> entirely, like kicking a dead whale down the beach.
>
This seems to be the attitude of the systemd developers, although 
they're not as eloquent as Thompson in saying it.  But I remember being 
just as abrasive, just on a smaller scale, myself.......

Now, I've read the arguments, and I am squarely in the 'do one thing and 
do it well' camp.  But, let's turn that on its head, shall we? Why oh 
why do we want every single package to implement its own initscript and 
possibly do it poorly?  Wouldn't it be a case of 'do one thing well' if 
one could do away with executable shell code in each individual package 
that is going to run as root?  Wouldn't it be more 'do one thing well' 
if you had a 'super' inetd setup that can start services in a better way 
than with individually packaged (by different packagers in most cases) 
shell scripts that are going to run as root?  Shouldn't the 
initialization logic, which is 'one thing that needs doing' be in one 
container and not thousands?

Now, I say that having been a packager for a largish RPM package several 
years ago.  I waded the morass of the various packages' initscripts; 
each packager was responsible for their own script, and it was a big 
mess with initscripts doing potentially dangerous things (mine included; 
to clear it up, I maintained the PostgreSQL packages for the PostgreSQL 
upstream project from 1999 to 2004). Ever since 1999 there have been 
issues with distributed initialization logic (that runs as *root* no 
less) under hundreds of different packagers' control.  It was and is a 
kludge of the kludgiest sort.

Having a single executable program interpret a thousand config files 
written by a hundred packagers is orders of magnitude better, 
security-wise, than having thousands of executable (as *root*) scripts 
written by hundreds of different packagers, in my experienced opinion.  
If anything, having all initialization executable code in one monolithic 
package very closely monitored by several developers (and, well, for 
this purpose 'developers with attitudes' might not be the worst thing in 
the world) is more secure.  It *is* a smaller attack surface than the 
feeping creaturism found in the typical /etc/init.d directory.  And 
Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit 
and its cousin /etc/rc.local.

Now, as much as I dislike this magnitude of change, it seems to me that 
systemd actually is more inline with the traditional Unix philosophy 
than the current initialization system is.  But I always reserve the 
right to be wrong.  And I am definitely not fond of the attitudes of the 
various systemd developers; systemd assuredly has its shortcomings.  But 
it *is* here to stay, at least in RHEL-land, for at least the next ten 
years.

Having said that, if you want to use Upstart, by all means use Upstart; 
RHEL6 (and rebuilds) will have Upstart until 2020.  So you're covered 
for quite a while yet, if you use CentOS, Scientific Linux, or another 
RHEL6 rebuild (or actual RHEL6).

And for those who bugle that systemd will be the 'end of unix as we know 
it' I just have one thing to trumpet:

"Death of Internet Predicted.  Film at Eleven."