Re: The "Unix Philosophy 2020" document

["Casper Ti. Vector" <caspervector@gmail.com>]

(Removed the skaware list from To:, for previously noted reason.)

On Sun, Oct 13, 2019 at 10:21:13AM +0200, Oliver Schad wrote:
> thank you for the effort putting things together. I was asking myself
> some questions. What is the target group? What is the exact purpose of
> that document?

As was hinted in the Foreword, the document is a compendium, but I
attempted to keep reasonable separation of concerns between the parts.
So the first part is about UP2020 (including the systemd rants, which
are the most important reason I can and need to ask for advices here),
the second part about my attempt to more systematically explore the
social values of the Unix philosophy (from the UP2020 perspective),
and the third part about the "Unix/Lisp reconcilliation" proposal.

Different passages are aimed at various groups of people, eg.:
* The document as a whole might be interesting for Unix addicts who
  happen to also appreciate the UP.
* The first part would probably be useful for people entangled in the
  "init wars", particularly for those who have strong opinions.
* The third part might be of some value to Unix developers interested in
  programming languages, as well as certain PL researchers.
* In general, footnotes are less essential contents, and often require
  deeper understanding of the subject matter.

> For systemd I have a more practical approach to discuss:
> 
> 1) how many config statements are there?
> 2) how many cases exist, which you have to work around (practical
> setups, where a config statement is missing or do the wrong thing)
> 3) how many bugs/feature requests are opened over time and how long does
> it take to solve them?
> 4) how big is the memory footprint and for which systems this is too
> much?
> 5) how many lines of code?
> 
> So you would have metrics - especially if you compare them to other
> solutions. If you want to have more food, make more metrics (call graph
> complexity or whatever). But there are simple metrics, which shows the
> result(!) of the design. Talking about the design itself is really a
> personal opinion otherwise and very lengthy and needs a lot of
> knowledge to follow.

I see.  Some of these metrics can be found from citations ([55] for (3),
[132] for (4), both as of v0.1.1) or in an easily verifiable way ((1)
and (5); tarball size of systemd + dependencies vs. tarball size of s6 +
friends + dependencies specific to them might be an easy indicator for
(5)).  Most arguments I made are admittedly qualitative, but they are
(if not, please tell me :) either backed up by citations or self-evident
to people who know a little about systemd.  On the other hand, I find
convincing quantitative evidences for most arguments much harder to
find (which is why statistics is an independent research field :);
nevertheless, the requirement about "know a little about systemd" is
indeed tricky, which is part of why I asked here.

> For the philosophy itself there are some parts missing in my opinion:
> what does that really mean what you're talking about in practical
> solution?
> 
> Is there a practical approach anywhere, interface definition,
> architecture? You describe a few patterns ok - but they are really
> common. I don't get really, which people would help this document.
> 
> Maybe that thing is missing: if somebody would like to build a modern
> UNIX: what are practical steps to achieve it?
> 
> Which tools, which interfaces (kernel, userland) are needed?

Before the publication of the document there was a alpha phase of it
in a subgroup of my local LUG (cf. the Afterword), and somebody asked
something similar.  My current opinion is that the UP2020 summary
(minimising the cognitive complexity of the system while almost
satisfying the requirements) can be used to compare *existing* systems
and *practical/semi-practical* proposals, but does not directly dictate
specific technical routes to a Unix-ish solution.

Metaphorically, UP2020 to practical ways to Unix-ish solutions is like
the principle of least action to the calculus of variations, except that
practical Unix-ish ways cannot be precisely formulated like the calculus
of variations is.  Instead, we have to foster programmers' (imprecise
but productive in another way) creativity, and the ways to foster
creativity were outlined in Section 11-12.

> BTW: I can't really see images inside the PDF

Sorry, but there are currently no figures due to a limited time budget;
I will probably make a plan about adding pictures and then implement it,
perhaps before the end of this year if time permits.  As a further note,
I am far from as good a teacher as V. I. Arnold or Dan Friedman (cf.
the end of Section 16), and soon after actually beginning to write the
document I found it really hard to accommodate for people with varied
levels of backgrounds.  This is quite serious a barrier for newbies, and
what has already been done is surely not quite enough; I will rethink
about this often.

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