[ale] systemd bad. Very bad.

[Steve Litt]

On Thu, 29 Jun 2017 22:17:54 -0400
Solomon Peachy <pizza at shaftnet.org> wrote:

> On Thu, Jun 29, 2017 at 08:33:15PM -0400, Steve Litt wrote:
> > OK, I'll byte: Why was systemd written?  
> 
> Becasue sysvinit (and the hack-upon-hack-upon-hack heaped on top to 
> compensate for its inadequacies) is a festering pile of swill?

False choice logical fallacy. Sysvinit is one of roughly 10
Linux-compatible init systems. Except for sysvinit and systemd, none of
them can be described as "hack-upon-hack-upon-hack" or "a festering
pile of swill."

Picking systemd because it's better than sysvinit is like appointing
Justin Bieber as CEO of your corporation because he's better than Ted
Bundy.


> But if you're actually serious about that question, here's the (very 
> long) answer direct from the horse's mouth:
> 
>   http://0pointer.de/blog/projects/systemd.html

Good. We have an answer. Now let's examine that answer.

* Notice first that the majority of features listed in this document
  contribute to exactly one benefit: Boot speed. All this new
  construction is done to improve a runit init 6 second boot to a 1
  second boot. Unless your computer is a television set, do you really
  care about boot speed? How often do you boot? Is it really a good
  idea to spin up and down containers every few seconds? Even if it is,
  is that justification for constraining other systems?

* Please note that although in fact I've built a systemd-based Qemu
  guest that booted in 2 seconds, many systemd-afflicted distros take
  30 seconds to boot: Longer than the 10 to 14 seconds for a typical
  Void Linux boot using the runit init system. 

* This "answer" justifies the building of systemd because it's better
  than sysvinit and the now defunct upstart, totally ignoring several
  superior init systems. 

* This "answer" extols the virtues of startup parallelization, all the
  while ignoring the fact that most current inits parallelize the
  startup.

* The "Hardware and Software Change Dynamically" section tries to make
  the case for construction of systemd as the only way to facilitate
  devices coming on and offline, totally ignoring the fact that such a
  mechanism can be constructed as its own process, with only the
  thinnest communication path with init (if any). 

* The "Hardware and Software Change Dynamically" says systemd is
  necessary in the integration of dbus and Ahavi into init, knowing
  full well that dbus is now, and Ahavi has been for years, systemd
  projects. This is a little like buying a $400 bicycle from a kid, for
  $100, by first buying the seat for ten bucks, and then coming back and
  saying "the bike is of no use without a seat, I'll buy the rest of it
  for $90. Both depend on gullibility.

Bottom line, http://0pointer.de/blog/projects/systemd.html is a bunch
of sales pitch fluff long on logical fallacies and short on real
information.

SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key