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

Thu Oct 23 18:02:55 UTC 2014

This is a good point, but it is perfectly possible to have a sysvinit
system not written in shell scripts.  I had rewritten most of the init
system in python at one point for example.  And its only been made easier
to do over time now that #! Interpertation was moved kernelside.  A system
like this could solve all the problems of both sides since it is now a
proper programming language so we can do more config style initscripts
without the blob that is systemd.  And for parallel init, you can do it in
bash, iirc Gentoo does parallel init in bash.
On Oct 23, 2014 1:45 PM, "Lamar Owen" <lowen at pari.edu> wrote:

> 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."
>
>