On Sat, 8 Apr 2017 11:07:32 +0200
Nicolas George <george_at_nsup.org> wrote:
> Le nonidi 19 germinal, an CCXXV, tomas_at_tuxteam.de a écrit :
> > Note that I'm a decided systemd opponent, and that might shine
> > through the above. Feel free to correct any misrepresentation.
>
> I would not have guessed. But you forgot a very important information:
> what are you a PROponent of? A lot of people are only opponents, and
> very vocal ones, and discussing with them is usually useless; I have
> seen the symptoms on this very list. Being an opponent is easy,
> everything has flaws that can be attacked; being a proponent is
> harder.
I'll answer your question of proponency by the end of this email, but
first let me say this: The preceding paragraph is an ad-hominem logical
falicy, painting the person who is against something without being for
a specific alternative, as being useless to discuss things with. It's a
falacy: A person arguing against use of chemical weapons can make the
argument quite credibly and logically without naming specific weapons
that are preferable.
What's especially ironic about the question "what are you for?" is that
from the very beginning until the present time, systemd proponents have
characterized the choice as systemd against sysvinit (with a little
upstart thrown in before 2014). Every mention of OpenRC, runit, s6 and
Epoch were met with a quick and flippant "not ready for prime time." If
people are "anti" without being "for", possibly it's because news of
several great alternatives was withheld from them.
I'll answer the "what are you for" in two different ways. The first
way is the actual products I'm for, roughly in order of how much I like
them:
* runit
* s6+s6rc
* Epoch
* sysvinit + daemontools, runit or r6
* sysvinit + OpenRC
I consider all but the fourth to be "ready for prime time", used
extensively by many people. I consider all five to be better than pure
sysvinit, which I consider to be miles better than systemd. I've used
runit for well over a year, managing both other peoples' daemons and my
homegrown daemons, and I can tell you it works like a dream.
The second way I'd answer your question addresses the fact that systemd
isn't an init system: It's a large superset of an init system,
encompassing a significant portion of an entire OS plus user program
APIs, tightly welded together in such a way as to severely cripple the
traditional Unix advantage of interchangeability of parts. Keeping that
in mind, what I'm FOR is:
To the extent possible, implement all computer operations using small
modules that connect through very thin, simple interfaces, and connect
only when there's a verified need to know. Everything systemd brings to
the table could have been done that way, but that's not what happened.
Now of course, there will be voices who call my preceding sentence
false. Some will be fanboiz parroting their team's talking points,
without the slightest idea of what they're talking about. Others will be
Poettering and Poettering like people, who try to win arguments with
the following logic:
===========================================================
1) You're wrong.
2) We need <feature A implemented with architecture B> because <current
implementation of software, without regard to making changes to the
current software>
3) Any suggested solution successfully rebutting #2 is a <ad-hominem>.
===========================================================
Here's a video where Poettering got his butt handed to him when he
tried that logic:
https://www.youtube.com/watch?v=ZTdUmlGxVo0&t=24m32s
View 24:32 to 24:57
Nicolas, on a spare computer or spare VM, fire up a non-systemd Linux
and install runit or s6. Work with it for awhile. Write your own
daemons and deploy them. with runit and s6, a daemon is just a program:
It doesn't have to background itself.
SteveT
Steve Litt
April 2017 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques
Received on Sun Apr 09 2017 - 19:53:21 UTC