On Sat, Oct 25, 2014 at 12:22 PM, Stephen Satchell <list@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