Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Sat, Oct 12, 2019 at 02:58:59PM -0400, Steve Litt wrote:
> [...]
> http://troubleshooters.com/linux/systemd/lol_systemd.htm
> [...]

Well, I knew that, and cited your diagrams ([15] and [18] in the
document as of v0.1.1).  I believe those who told me the point about
cohesion and coupling in the systemd architecture may seem unfounded
to *people who have very little prior knowledge about systemd* are
well-intentioned and are not fanboys.  Thank you anyway for the
expressive diagrams and past discussions on related topics!

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

[Steve Litt]

On Sun, 13 Oct 2019 01:37:43 +0800
"Casper Ti. Vector"  wrote:


> However, people told me that the document is not quite accessible to
> those who know really little about systemd: one example is they do not
> even know much about how the modules are organised in systemd, so the
> claim that the systemd architecture has how cohesion and high coupling
> may seem unfounded; 

Hi Casper,

About not knowing how systemd modules are organized: NOBODY knows that
except Poettering et. al. To my knowledge, there has never been
published a systemd block diagram with both the blocks and the
interaction lines between those blocks. Systemd "block diagrams" are
typically a bunch of blocks in layers, which indicates nothing about
how they're organized. So if you defined how the modules were
organized, as a block diagram, you would be the first.

Contrast this situation with sane init or supervision systems. Here's my
block diagram of daemontools:

http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm#daemontools_mental_model

If I were to modify that block diagram for runit, the "system boot" and
"inittab" would be replaced by runit-init, /etc/runit/1, and
/etc/runit/2, with the latter exec'ing (being replaced by) the runit
equivalent of svscanboot.

With my understanding of s6, if I were to modify it for s6, I'd have
the s6 PID1 do some initial stuff, then exec (be replaced by) an
executable that does exactly two things:

1) Listen for and act on appropriate signals
2) Supervise the s6 supervisor, which on my diagram is svscanboot.

So with s6, PID1 becomes a supervisor that supervises one program, the
main supervisor (did I finally get that right, Laurent?)

Look at the situation. For daemontools type stuff, a guy who is a
Troubleshooting Process Trainer, an office automation Programmer, a
tech writer and an author (in other words, NOT an expert on inits) can
draw a complete and reasonably accurate block diagram including
interaction lines, whereas with systemd the millions of dollars Red Hat
spends on the "best and brightest" to produce, maintain, and evangelize
systemd cannot produce such a diagram for systemd. This is telling.

So when the systemd fanboiz tell you that you haven't provided systemd
module interaction,  tell them that information is not available, and
that's excellent evidence of cohesion, high coupling, and gratuitous
complexity.

Here's another diagram I use when speaking to those who claim systemd
is modular because it has modules:

http://troubleshooters.com/linux/systemd/lol_systemd.htm

And when speaking with somebody knowledgeable enough to say that all
that gratuitous crosstalk goes through one channel, namely dbus, tell
them that doesn't matter a bit, because the crosstalk still happens.

SteveT
 
Steve Litt
Author: The Key to Everyday Excellence
http://www.troubleshooters.com/key
Twitter: http://www.twitter.com/stevelitt

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

(I guess discussions about this document is probably destined to be
off-topic on the skaware list, so further public mail in this thread
will only be posted to the supervision list; sorry for the disturbance.)

On Fri, Sep 27, 2019 at 04:38:16PM +0800, Casper Ti. Vector wrote:
> Although the contents of the document are quite related to our mailing
> lists, I do not think Laurent (by the way, I am sorry he might really
> disagree with me on many points in the third part) would like to see too
> much off-topic discussion on these lists.  So please send comments to me
> via private mail or GitLab/GitHub issues if they are unrelated to
> supervision/skaware; I will be especially interested in comments about:

I received comments and suggestions from multiple people, and would like
to express my sincere gratitude to these people.  Most of the issues
involved either are quickly resolvable, or require more time to address
but do not affect the main ideas expressed.  However, there is one issue
that I definitely need to ask for your suggestions on to resolve, and
the issue is about systemd: multiple people told me that they felt
uncomfortable about the recurring (but each time on a different aspect,
obviously) examples about systemd.

Before asking specifically for what I need, please allow me to briefly
explain why the document is in its current shape.  As can be seen from
the Afterword and Footnote 44 (as of v0.1.1), this document originated
from my reaction to the systemd fiasco; and as can be inferred from
Section 11, I find it impossible to discuss UP2020 without major
involvement with systemd.  So I already intended to blame systemd when
the document only existed in my imagination, and this intention is not
unjustified; but once systemd is involved, any argument must be backed
with enough evidences, hence the current shape of the document.

However, people told me that the document is not quite accessible to
those who know really little about systemd: one example is they do not
even know much about how the modules are organised in systemd, so the
claim that the systemd architecture has how cohesion and high coupling
may seem unfounded; because of this, I request your recommendation for
an accessible and not-too-boastful introduction to systemd suitable for
citation in the document.  Additionally, although there do not yet seem
to be other major technical faults in the recurring systemd examples,
they might really appear unpleasant for some readers, so I also request
your advices on how to reduce the "rantiness" of the document (eg. how
certain parts can be rephrased, or certain inessential examples be
removed/replaced) without harming its technical correctness.

A point to note is that I tried to choose a small yet most touted subset
of systemd features, and then to analyse how these features can be done
using s6 and friends, which I find a most efficient way to understand
their nature.  From what I know, there have been few systematic analyses
of systemd from the viewpoint of the daemontools-ish design, so I
believe that these technical arguments, in combination with UP2020, can
be much more convincing than other arguments available in showing why
systemd is bad.  Consequently I think that, with an appropriate amount
of publicity for the document, much more people would be willing
to keep an eye on, migrate to, or even help develop daemontools-ish
systems, potentially creating a mini-avalanche effect or even resulting
in a turning point in the "init wars".  However, the influx of people
into our circle will also result in a lot of noise (especially the noise
from some ill-intentioned systemd proponents) and a lot of additional
technical workload, so I request Laurent for a decision on whether to
publicise the document; and provided he agrees, I request you to help
spread it to appropriate places.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C