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

Sat Oct 25 22:56:52 UTC 2014

On Sat, Oct 25, 2014 at 12:22 PM, Stephen Satchell <list at satchell.net> wrote:
> The whole rc script thing strikes me as an interim solution that
> required a minimum of code changes (graduate student project?) that went
> viral.  Bad as it was, it worked.  Duct tape and bailing wire....
[snip]
> Systemd is not a re-factoring.  It's a from-scratch do-over.  What it
> does that is good is that it provides dependency capability not
> available in the original inittab.  It makes dependency resolution
[snip]

The trouble is not  that systemd is a re-factoring or that it is a do-over.

The problem is that the scope of the systemd project is way too large
and is ever-expanding!

The next thing you know,  SystemD will add package management, ISO
building, and eliminate the need for  Debian, Ubuntu, SuSE, Redhat,
Etc  to even exist.

In the extreme case, at that point, we can rename GNU/Linux to
GNU/SystemD,    because hey,  the   Linux kernel is really just a
little wrapper around the hardware to support the SystemD userland.

The introduction of dependency support is solving issues with  SysV
init that are problems;  I will give you that, but   copy and paste
init scripts  and  sequence-based dependencies are largely an
aesthetic issue.

SysV Init also has the advantage of  more deterministic system startup
behavior.     What do  you think happens when you have SystemD,  but
one of the critical  packages  has a service dependency incorrectly
defined?

If  the  scope of  SystemD were appropriately constrained, it would
not be  also trying to replace  the standard SYSLOG facilities  with a
  program-specific logging format  for everything.

I'm not saying that  Syslog is great;  perhaps there should be new
binary logging formats,  or    Libc built-in logging to  a RDBMs,
Redis database, or ElasticSearch cluster,    but a distribution's
choice of   INIT program should not be forcing a choice on you   in
itself.

Also....  since there are NTP daemons,  DHCP,  etc, all shipping with
SystemD,     chances are   using something different will be along the
path of greatest resistance.

If history will be any guide;    having  all these extra services
under the same package init,   will likely mean that the  maintenance
will leave much to be desired  ----  and you will be forced to upgrade
other things and probably a reboot just to get a bug fix or security
patch for your NTP client daemon.

It doesn't really matter if they are not all running as PID #1.    The
problem is really  that these services have been lumped into the scope
of the same project.

Proper integration into a software system does not mean  expanding
your scope duplicating other programs' functionality  into your
program,  while introducing your own quirks.

--
-JH