[ale] systemd bad. Very bad.

[Solomon Peachy]

On Fri, Jun 30, 2017 at 01:05:13PM -0400, Steve Litt wrote:
> 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."

Um, how many of these were viable seven or so years ago?

> 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?

Just because *you* find no use case for rapid bootups doesn't mean 
nobody else does -- and at the risk of pointing out the obvious, 
containers are a really, really, really important use case for many 
others.

Meanwhile, I don't actually care about the improvements in startup times 
all that much -- at least not on hardware that's stable -- but the same 
under-the-hood stuff that yielded such bootup improvements led to many 
other improvements that benefit me every time my laptop comes out of 
sleep.

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

On the same hardware (Lenovo P700 workstation), systemd-equipped Fedora 
22 booted more than twice as fast on spinning rust than CentOS6 does on 
an SSD (from pressing enter in grub to login prompt). And before you 
say I'm comparing apples to oranges, you just did the same, possibly 
worse as you lacked any specifics at all.

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

Again, what's the timeline of these "superior" alternatives?  Remember 
that "answer" you are mostly ignoring was written seven years ago, and 
time has marched on -- systemd has only grown more capable since then.

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

You're correct, that's an excellent way to construct such a mechanism -- 
And the systemd authors agree, using secondary processes (typically 
udev, invoked by the Linux kernel's various hotplug mechanisms) which in 
turn communicate with systemd via only the "thinnest communication path" 
(ie by creating unit files on the fly with with appropdiate depencies 
listed and then handing it over to systemd to launch everytihng that 
needs launching) to spin everything up in a fully tracked, logged, and 
dependency-handling manner.
 
> * 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.

I note that you're once again attacking use cases rather than design or 
implementation.  So, let's go into specifics of what you're dissing.

avahi is an implemetnation of the multicast DNS spec (RFC6762) that 
predates systemd by several years, and would probably never have been 
written had Apple not used an incompatible license for their 'Bonjour' 
implementation.  It is heavily used by "modern" (ie 10+ year old) 
desktop and smartphone environments for service and network device 
discovery, replacing any manner of proprietary protocols.

dbus also predates systemd by about a year, and was the result of 
literally decades worth of lessons learned about inter-process 
communications.  It is a foundational component to "modern" Linux 
desktop environments, and enables features on par or better than 
propietary competitors, all of whom offer some sort of equivalent 
"system bus" to tie bits together.

*neither* of them is part of systemd, and in no way depend on systemd in 
any form.  That said, systemd relies on dbus, because... why re-invent 
the wheel and create a new IPC mechanism when one already exists?

Neither are part of PID1; indeed there's a push to get dbus (or a 
mechanism that dbus can be implemented on top of) into the linux kernel 
because it has proben to be incredibly useful, and making it a native 
kernel service would yield considerable performance gains, security 
improvements, robustness improvements, and so forth)

So, congratulations on your strawman fallacy.

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

So, in short, you don't care about the original premise, use case, and 
technical rationale behind systemd's creation seven years ago.  That's 
fine, but you don't get to tell others that those use cases are 
incorrect or irrelevant.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20170630/265bb0a0/attachment.sig>