[mdlug] Completely replacing Windows 98se with Linux!

[Jonathan Billings]

On Mon, Aug 18, 2014 at 12:46:37AM -0400, Aaron Kulkis wrote:
> Distros are choosing it because once one deamon has been written using
> a systemd library call, then ALL of systemD gets pulled in, which then
> makes it EXTREMELY difficult to use any other startup system.
> 
> It's not that it's superior, it's that Poettering has deliberately used
> poor programming practices (such as breaking the principle of
> interchangeability) 
> to lock-in systemd, regardless of whether it is actually wanted or chosen
> on the basis of merit, or not.

That's not a particularly good argument for why distros would choose
it.  If a hypothetical new init system came out that was deliberately
written to be poor programming, do you really think that so many
people would be jumping to use it?  Do you really think this guy has
that much power?  Perhaps there are features that people have been
wanting for a very long time? 

I won't argue that its perfect, just that it fixes a lot of things
that have been problems under SysVinit for a LOOOONG time.

> Did you even bother to read http://ewontfix.com/14/ and
> http://ewontfix.com/15/ ??? 

I read both.  /15/ seems to be a rant against *all* daemon startup
types, and while it's directed at systemd, the problem the author
notes is really in how people are starting daemons.  The fact that
systemd supports all those types (even though the author this they're
done wrong) hardly counts *against* systemd.  Also, the author either
ignores or is ignorant of how systemd uses cgroups to track daemons. 

If anything, the way that systemd attaches the stdout and stderr of
daemons to journald makes it a bit better at handling daemons that
previous init systems.  (I have my share of problems with journald,
but I do like that systemd does a better job of monitoring a daemons
stdout and stderr.)

As for /14/, there are a lot of things addressed there.  

* PID 1 and a perceived increase in attack surface.  The author seems
to have a serious problem with a complex process running as PID 1,
which isn't just the case for systemd but also for Upstart and
other init systems.  I'm not sure what init system the author would
prefer, but the way the post was written, it's what's being used in
any distro I'm aware of.

* reboot to upgrade:  This is just plain wrong.  systemd has long
since supported this (with daemon-reexec), which the author correctly
points out.  Again, the author has some very explicit limits for what
they believes should be handled by the PID 1 process.  Systemd is not
unique in how it handles upgrades.

In all, I think the author has some good points, but mostly on what
the author thinks PID 1 should be doing, not really an argument
against systemd in particular.

-- 
Jonathan Billings <billings at negate.org>