On Tue, Jul 06, 2021 at 09:30:31AM -0400, Clem Cole wrote:
> The basic idea of the original Unix was that was small and simple and in
> Dennis' words, 'ran on modest hardware.' The designers of UNIX also did
> not try to solve any one particular problem but offered a set of tools for
> a >>programmer<< take upon her/himself to do so.
>
> The issue is that the target >>user<< of UNIX had devolved from that of a
> 'programmer' but rather the elusive 'end user' and her/his
> view/requirements tend to be "solve my problem now -- I don't care how -
> just do it I don't want to think about it - make it go away." So over
> time, we hid a lot of the simplicity in features that were built on
> features (often warts) that were built on other features (often other
> warts).
I'd go even farther than that. Hardware is no longer as modest, or as
simple. And even if the target user is still the "programmer" it may
not be the case that worked well wtih the hardware and the problems of
50+ years ago is in fact that best answer today. Including, for
example, the claim that everything should be represented in terms of a
byte stream and/or a file.
I'll refer people to the former FreeBSD core team member and currrent
FreeBSD developer, Benno Rice's presentation from linux.conf.au 2020,
"What UNIX Cost Us":
https://www.youtube.com/watch?v=9-IWMbJXoLM
Interestingly, much of this is kind of the point I was trying to make earlier: many of the problems are different now. Trying to force them into a metaphor that made sense for the problems that were primary 40 years ago can lead to awkward and inefficient solutions. It doesn't always have to, but sometimes it does.
"Everything is a file" and "files are streams of bytes" was great for approaching so many of the sorts of problems that were interesting in the 1970s and 80s. Now days, there are whole new types of problems that don't fit into that model easily; is that the fault of the problem, or a suggestion that we need to expand our model and reexamine the basic structure of our systems? Even, to some extent, the notion of a global hierarchical file namespace has broken down. Now, I want to be able to partition and organize datasets across multiple dimensions and across multiple machines and group things on an ad hoc basis; it's all very dynamic, and by comparison the model of a 7th Edition filesystem is static and downright limited.
Fork is another great example: it went in because a) Ken knew about it, and b) it was easy to implement (22 instructions of PDP-7 assembler or something) and c) it got the job done. After the fact, it turned out to have all kinds of neat properties that let it compose with pipelines, redirection, background jobs, etc. That model for process management served well for a long time. But then people wanted to have multithreaded processes, because it turns out that independent threads of execution inside of a shared address space are an excellent mechanism for representing concurrency. But they discovered that fork composes poorly with threads: the problem space changed and the model broke down.
> I was commenting on the OPs post of the paper picking on UNIX, the UNIX
> Shell, and where we are today *vs.* 50+ years ago. My other point is the
> authors need to get over themselves and recognize that* they are not making
> a really new argument*. Folks were not too happy with many of the BSD
> 'features' either, but now those same features (like head(1) or BSD sockets(3))
> are considered SOP for nay new UNIX and you have to have them - even if
> there are other if not 'better' ways of doing the same thing.
And if the Unix patriaches were perhaps mistaken about how useful
"head" might be and whether or not it should have been considered
verboten, perhaps there is something to the claim that extreme
simplicity and forcing everything to implement in terms of the
smallest, simplest operations, might not make sense. After all, taken
to extreme, if simplicity is the only good, then instead of Intel
CPU's, or PDP-11's, maybe we should be programming everything in terms
of a Turing Computer --- after all, "small is beautiful" and even a
PDP-11 is unnecessary complexity. :-)
Or maybe not.
One of Benno's claims is even the Unix philosophy, when taken to
extremes, can be as much of an ideology as say, Fundamentalist
Christianity. My Episcopalean roots may be showing, but the words of
Scripture (or the writings of the Unix Patriarchs) is not the only
source of truth; and Tradition by itself is also not enough; we also
need to apply our own Reason and Experience.
I don't know that the "Unix Patriarchs" ever suggested or intended that "head" was "verboten" or that programs be forced into their smallest, simplest expression. To continue your sectarian metaphor, that's an extreme interpretation of the early church's teachings regarding its scripture.
I tend to think of these things as schools of art, rather than religious orders. Much of what we think of as "Unix" carries with it an implicit allegiance to a class of aesthetics: file namespaces and byte streams are great examples. We claim our way is better, but if you sort of squint at it right, you can kinda-sorta imagine a Unix system as an image based language environment, where the "image" is the filesystem and running kernel instance, and the REPL is the shell. Is it so different, then, than Smalltalk or a Lisp? In some sense, no, it's not. Instead of CONS cells making lists, I have streams of bytes, but in some regard that's just an aesthetic thing: it's my fundamental building block, but it's just a building block and all systems have building blocks.
But like the art world, is it any wonder that the big arguments are over minutia? The question you asked me earlier, about whether System V is "really Unix" isn't so dissimilar from the questions over whether Common Lisp was "really Lisp". Similarly, discarding "head" for the generality of "seq 10q" is an aesthetic statement, not a matter of engineering principle.
Rob Pike in a black turtleneck espousing the benefits of simplistic minimalism as an end unto itself is an exponent of that school, but there are other schools, as Benno reminds us.
The challenge for the new generation of artists is to absorb what's come before and create something new. If they draw from many schools, that's fine. What perhaps irks so many of us is that the school is changing, and without full appreciation of the aesthetics of existing canon. "It is sad, this state of affairs. Look how ugly is the systemd!" "But Dan...your /etc/rc is so 1970s." "Yes! See the beauty! Perceive it!" "You are old." "I weep for you."
The question I'm asking is if the kids are reaching far enough.
- Dan C.