It's Saturday, let's bump this thread! 😁

(09-05-2021, 01:17 PM)ckester Wrote: How many reimplementations in Rust or Go of common utilities are there? Hacker culture does seem to have a roll-your-own philosophy, despite this rule, if only because breaking it can provide a learning opportunity.

I personally think re-implementations are good too in a sense. They allow to revisit old problems. But implementation just for the sake of reimplementation, with nothing added, or for political/ethical/moral reasons is also not worth it.

Anyway, into this week's chapters, 3 and 4.

---

Chatper 3 is the last chapter in the philosophy section about contrasts.

I like the way esr describes stuff, it's always like a sort of
questioning, a Socratic-like method the kind of writing that makes you
think about other ways to see things.

In that sense, there's a lot of comparison of different OSs, rotating
around the topic to try to get a clearer idea, describing Unix using
anti-Unix terms, telling what it is by what it is not.

The CLI facilities is definitely a cool sections, it resonates a lot.

Quote:If the CLI facilities of an operating system are weak or nonexistent,
you'll also see the following consequences:

Programs will not be designed to cooperate with each other in unexpected
ways — because they can't be. Outputs aren't usable as inputs.

Remote system administration will be sparsely supported, more difficult
to use, and more network-intensive.

Even simple non-interactive programs will incur the overhead of a GUI or
elaborate scripting interface.

Servers, daemons, and background processes will probably be impossible
or at least rather difficult, to program in any graceful way.

To design the perfect anti-Unix, have no CLI and no capability to script
programs — or, important facilities that the CLI cannot drive.

Apart from this, and even through the previous and next chapter, there's
the overall theme of having users in the driving seat, a user-centric
system that also has a social aspect.

Accordingly, the intended audience of the OS should be
considered. Unix-wise, the barrier to development should especially be
decreased, here again the social aspect: cost and time.

The visit of the different "classic" OS puts a lot of things in
perspective. I'd advise anyone who hasn't read it to give it a go.


NB: On NT webserver in kernel space: We discussed that on IRC in the
past. We had a fun discussion about the pros and cons of things like
kHTTPd, TUX, http.sys, etc..
These days, it makes no sense to have these.

BeOS thinking sort of reminds me of the whole snapshot fs we have today,
like ZFS and others. It's still alive in Haiku as far as I know.

Quote:Indeed, a substantial fraction of the Linux user community is understood
to be wringing usefulness out of hardware as technically obsolete today
as Ken Thompson's PDP-7 was in 1969. As a consequence, Linux applications
are under pressure to stay lean and mean that their counterparts under
proprietary Unix do not experience.

The days have changed. Here again, we have to join tech with the people
making it. Survivability, can be untied from the hardware but it is
still tied to social group, devs, and companies.

Then comes chapter 4 about modularity, the first chapter in the design part.

I really didn't know the Unix early devs were the first to apply
modularity in software, or I had forgotten.

Quote:Dennis Ritchie encouraged modularity by telling all and sundry that
function calls were really, really cheap in C. Everybody started writing
small functions and modularizing. Years later we found out that function
calls were still expensive on the PDP-11, and VAX code was often spending
50% of its time in the CALLS instruction. Dennis had lied to us! But it
was too late; we were all hooked...

-- Steve Johnson

He did well to lie. Wouldn't that be like electronjs devs today saying
we have enough RAM though?

Even in modularity, we have to think of the barrier of entry, the social
aspect, and the human aspect.
The book dives into the idea of creating human-first API, described in
everyday language first, and then thinking about how to apply it.
Similarly, the code-size should appropriately fit the human's cognitive
constraints: not too small and fragmented, and not too big.

Quote:Compactness is the property that a design can fit inside a human being's
head. A good practical test for compactness is this: Does an experienced
user normally need a manual? If not, then the design (or at least the
subset of it that covers normal use) is compact.

This reminds me of The Design of Everyday Things by Donald Norman,
which has a focus on how instinctive and intuitive interfaces are.

Even the pragmatic approach is very human.

Quote:Often, top-down and bottom-up code will be part of the same
project. That's where ‘glue’ enters the picture.

Quote:The thin-glue principle can be viewed as a refinement of the Rule of
Separation. Policy (the application logic) should be cleanly separated
from mechanism (the domain primitives), but if there is a lot of code
that is neither policy nor mechanism, chances are that it is accomplishing
very little besides adding global complexity to the system.

One thing this also reminds me of is Dijkstra 1972 ACM Turing Award
lecture where he describes approaching the task of software development
as humble programmers.

Quote:The competent programmer is fully aware of the strictly limited size
of his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.

I'm not sure I really buy the OO talk because in a lot of cases it does
exactly what is described above and reduces cognitive loads.

The end of chapter 4 reminds me of all the pseudo-discussions people
have about optimizations, and code metrics, static or not.
A new metric that I mentioned recently on IRC and
that is more human is a social coding hotspot metric such as
biomarkers.