On Tue, Jul 6, 2021 at 12:25 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
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.
Btw, Benno Rice is entertaining to watch, and I enjoy his presentations.
His talk on COBOL is also interesting, and I would argue somewhat relevant:
https://www.youtube.com/watch?v=BCqGjGzWI48
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.