[ale] Systemd and cygwin

[Steve Litt]

On Wed, 18 Nov 2015 08:50:12 -0500
James Sumners <james.sumners at gmail.com> wrote:

> > And why is a simple config file harder for you than a turing
> > complete shell script? Do you hate the 1kb reduction per executable
> > to eliminate the double fork tty disassociation hokey pokey, too?
> > Or the consolidation of common functionality in now nearly
> > universal shared objects?
> >
> >
> Nowhere in my response did I say a replacement to SysV wasn't needed.

And it's been here, in some cases for years. Epoch. Runit, s6, s6-rc,
nosh, perp. Suckless-init plus daemontools-encore plus LittKit. OpenRC
if you swing that way. I understand Busybox has a lightweight init.
There are several others. Earlier in this thread the phrase "level of
ignorance" is used. Anyone justifying systemd by saying it's better
than one particular init is either a cynical con man, or has taken
ignorance to a whole new level. Anyone who believes the justifier is,
well, let's be charitable: Uninformed.

About the Turing complete shellscripts. Configuring a daemon with a
Turing complete language means you're better able to accommodate
situations unforeseen by those writing the process supervisor portion of
the init. And don't assume such shellscripts are required to be the
gargantuans fielded by sysvinit or OpenRC. Put Void Linux on a Qemu VM,
install several daemons, look in the /etc/sv tree, and notice the run
scripts, which have the same purpose as sysvinit init scripts or
systemd unit files. Every one is less than 10 lines long, even if you
include the stuff in the conf script in the same directory. My dovecot
daemon is started by a run script with no conf script, it's fairly
typical of all my daemons, and the run script looks like this:

================================================
#!/bin/sh
install -d -m 0755 -o root -g root /var/run/dovecot
exec dovecot -F
================================================

When used correctly, a Turing complete init configuration facility is an
asset, not a liability. We're all sorry about sysvinit/LSB init
scripts, but they don't represent all shellscripts used to launch
daemons. And if one insists on having declarative config of daemons,
there are alternatives to systemd: Epoch is a fine one.

About the 1kb reduction per executable to eliminate the doublefork. I
have no idea whether that's true, and whether systemd's method (or
Runit's method, for that matter) eliminates that 1K, or whether it
really is 1K, but let's say it really is 1K per process. Observe the
following from my fully equipped Void Linux box:

==========================================
[slitt at mydesk ~]$ ps ax | wc
    202    1205    9873
[slitt at mydesk ~]
==========================================

If each process costs 1K, this is 202K. That's 1/3 of the RAM of the
maximum standard memory circa 1985: 640K. It's a little over 1/5 of
1MEG. When's the last time you had a machine with 1MB RAM? It's just
over 1/20000 of 4GB, a RAM size available on the $350 laptops of today.
Let's get our priorities straight.

SUMMARY:

* Systemd will force per-seat billing: Propaganda

* Systemd is better than sysvinit: Propaganda

* Systemd saves the 1K/process doublefork penalty: Propaganda

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

SteveT

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