[ale] Systemd and cygwin

[Steve Litt]

On Wed, 18 Nov 2015 11:46:56 -0500
Solomon Peachy <pizza at shaftnet.org> wrote:

> On Wed, Nov 18, 2015 at 11:18:15AM -0500, Steve Litt wrote:
> > When used correctly, a Turing complete init configuration facility
> > is an asset, not a liability. We're all sorry about sysvinit/LSB
> > init
> 
> You hit the nail on the head there; "when used correctly."
> 
> Unfortunately, after doing this for twenty years, I'm fairly
> convinced that this is just a rhetorical postulation.


Install Void Linux in a VM, install a few daemons, and look at their
run scripts in the /etc/sv tree. This is a perfect example of "when
done correctly."


> 
> > * Systemd will force per-seat billing: Propaganda
> 
> Yep.
>  
> > * Systemd is better than sysvinit: Propaganda
> 
> No; it is *vastly, vastly* better than sysvinit under just about
> every possible metric.  
> 
> (Let's be honest, sysvinit is so awful that the classic "sysv init 
> scripts" were created to work around sysvinit's deficiencies!)
> 
> Now whether or not one cares about those improvements is another
> matter entirely.

Correct. I should have written this more concisely. What I should have
written is that bragging that systemd is better than one in a multitude
of init systems, where that one is over 30 years old, tired, half
propped up by LSB, is propaganda. It's a little like bragging that
you're smarter than Mike Tyson and tougher than Stephen Hawking.

> 
> > * Systemd saves the 1K/process doublefork penalty: Propaganda
> 
> It's not the code size so much as doing it correctly in one place.

In that case, all of the daemontools-inspired inits and process
supervisors are endowed with the same advantage as Systemd.

> 
> (Personally, I took advantage of systemd's support for such thigs to 
>  enable some daemons written in PHP (seriously) to work.  The 
>  alternative would have been to write a C wrapper myself and exec()
> the PHP interpreter afterwards.  Why reinvent the wheel yet again?)

Here again, all the daemontools-inspired inits and process supervisors
do the same thing. If it runs on the command line, you can rely on your
init or process manager to put it in the background and control it. My
homegrown cron substitute (don't ask) is written in Python. Runit
"daemonizes" it.

> 
> > * The choice of init system is based on use case, and there's no
> >   one-size-fits-all init system that works for everybody: The stone
> >   truth.
> 
> I'd agree with that.

Yes, this is the crucial fact. When my technophobe relatives ask which
distro they should run, I tell them Lubuntu, not Void. My mamma didn't
raise no fool: Lubunu is right for their use case, and systemd won't
interfere one bit with what they want to do with their machine. I don't
want them breaking their Void setup every day and calling me.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques