From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29673 invoked from network); 7 Jul 2021 01:58:58 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2021 01:58:58 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1DCB39CA56; Wed, 7 Jul 2021 11:58:57 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3E67E9CA35; Wed, 7 Jul 2021 11:58:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="jx0zMjYg"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 54A749CA35; Wed, 7 Jul 2021 11:58:17 +1000 (AEST) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by minnie.tuhs.org (Postfix) with ESMTPS id 7266D9CA24 for ; Wed, 7 Jul 2021 11:58:15 +1000 (AEST) Received: by mail-ot1-f50.google.com with SMTP id d27-20020a05683018fbb02904ae64d1b56bso734042otf.9 for ; Tue, 06 Jul 2021 18:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wzwmpDiWcnvpt4hlvTDIQfuVYWbwJJahqURi8bhMx18=; b=jx0zMjYgSEZuJIC8uWi1dt5llzFBArTkG2l5Yfa65ki3p0+0SROL18NU1N+oNC9xr6 kAWp6g7+SoonTFQy3Jfv4wyXNivhoVzID8IixC/fkSl5QRSpS59IhgRRg11ebmT3cLxY WeqkLycH31T4Oz0j76HJr5EBJmnH3F3eKiYmtjpCy6w7DyAuFKl0V3wn00z+VyR5+TyK WYs5RXLn89LW9ErwPm3Ha31PpFvifN8Udfhr6I/6MMuOO/6WkP3Ntsl0adVHyOXvMBVe Dntp45fxhOGKlQFjf4ZLgU4d00r9vXgUk0LQGQ6ZJYKI6+ML9M3ofD7yWRbq9Or/iExV 16RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wzwmpDiWcnvpt4hlvTDIQfuVYWbwJJahqURi8bhMx18=; b=NUlzuqZLlfTqShAg8EgfFEq5vWks3u9epsAmn80U1B3CeFJ54/2sy6DJ0RXkjxt3Z4 LZxvBP3SoATkjMNTe8KnNfNHGZFwWM2zZonEhyYwNABICbUej8OMxZ1rBtYfyK/l/iSA elQEiUTeD0K3X85rK3HNcW6dARgVwThksFrEYNUJMgV37xCgTcFKYEUKVN44PpOpWOel of5RVdJUXLWJMCSmGg67LQUsGtYbjZ/HidLAYTN+iLb1XB+k+GpoME1Dd7UqlT6JG0wZ jjK8xUZnL1NWqGtFi/llFuTHJIyeYzFQEZZr5wJYGO9WtyYe++NoAkRfa8CsSEWG6/a5 2fCw== X-Gm-Message-State: AOAM532jcty1eQC39jxc8o0nZs5YjEVkp9mpTu0Oop5ErangpiWzJQjy oQNhnt5wlmTEm5f6zRID+t9L/qwtzKqFE4wxkvLCsSzqG8HBog== X-Google-Smtp-Source: ABdhPJwhI9Eg3gD+FeDVQL6VJEozjXwHTbNoxIuo7CpjuWjimBH21LaeWrEhhU0hn4SgwUUh+fHz6au9Jh3aK+p88Q4= X-Received: by 2002:a9d:6285:: with SMTP id x5mr2292232otk.137.1625623094569; Tue, 06 Jul 2021 18:58:14 -0700 (PDT) MIME-Version: 1.0 References: <06737C14-1122-4832-BCAA-A37B242F69E4@me.com> In-Reply-To: From: Dan Cross Date: Tue, 6 Jul 2021 21:57:38 -0400 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="000000000000172ca105c67edf56" Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000172ca105c67edf56 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 6, 2021 at 12:25 PM Theodore Ts'o 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. --000000000000172ca105c67edf56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 6, 2021 at 12:25 PM Theodore = Ts'o <tytso@mit.edu> wrote:<= br>
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.'=C2=A0 =C2=A0 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."= =C2=A0 =C2=A0So 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<= br> > warts).

I'd go even farther than that.=C2=A0 Hardware is no longer as modest, o= r as
simple.=C2=A0 And even if the target user is still the "programmer&quo= t; 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.=C2=A0 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":

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.youtube.com/wat= ch?v=3D9-IWMbJXoLM

Interestingly, much = of this is kind of the point I was trying to make earlier: many of the prob= lems are different now. Trying to force them into a metaphor that made sens= e for the problems that were primary 40 years ago can lead to awkward and i= nefficient 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=C2=A0many of the so= rts 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 o= ur model and reexamine the basic structure of our systems? Even, to some ex= tent, the notion of a global hierarchical file namespace has broken down. N= ow, I want to be able to partition and organize datasets across multiple di= mensions 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 fil= esystem is static and downright limited.

Fork is a= nother great example: it went in because a) Ken knew about it, and b) it wa= s 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 n= eat properties that let it compose with pipelines, redirection, background = jobs, etc. That model for process management served well for a long time. B= ut 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 t= hat fork composes poorly with threads: the problem space changed and the mo= del broke down.

Btw, Benno Rice is entertaini= ng to watch, and I enjoy his presentations. His talk on COBOL is also inter= esting, and I would argue somewhat relevant:=C2=A0https://www.youtube.com/watch?v=3DBCqGjGzW= I48

> I was commenting on the OPs post of the paper pick= ing on UNIX, the UNIX
> Shell, and where we are today *vs.* 50+ years ago.=C2=A0 My other poin= t is the
> authors need to get over themselves and recognize that* they are not m= aking
> a really new argument*.=C2=A0 =C2=A0 Folks were not too happy with man= y of the BSD
> 'features' either, but now those same features (like head(1) o= r BSD sockets(3))
> are considered SOP for nay new UNIX and you have to have them - even i= f
> there are other if not 'better' ways of doing the same thing.<= br>
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.=C2=A0 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 te= rms
of a Turing Computer --- after all, "small is beautiful" and even= a
PDP-11 is unnecessary complexity.=C2=A0 :-)

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.=C2=A0 My Episcopalean roots may be showing, but the words of<= br> 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 secta= rian metaphor, that's an extreme interpretation of the early church'= ;s teachings regarding its scripture.

I tend to th= ink of these things as schools of art, rather than religious orders. Much o= f what we think of as "Unix" carries with it an implicit allegian= ce to a class of aesthetics: file namespaces and byte streams are great exa= mples. We claim our way is better, but if you sort of squint at it right, y= ou can kinda-sorta imagine a Unix system as an image based language environ= ment, where the "image" is the filesystem and running kernel inst= ance, and the REPL is the shell. Is it so different, then, than Smalltalk o= r a Lisp? In some sense, no, it's not. Instead of CONS cells making lis= ts, I have streams of bytes, but in some regard that's just an aestheti= c thing: it's my fundamental building block, but it's just a buildi= ng block and all systems have building blocks.

But= like the art world, is=C2=A0it 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&q= uot; for the generality of "seq 10q" is an aesthetic statement, n= ot a matter of engineering principle.

Rob Pike in = a black turtleneck espousing the benefits of simplistic minimalism as an en= d unto itself is an exponent of that school, but there are other schools, a= s Benno reminds us.

The challenge for the new gene= ration 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 1970= s." "Yes! See the beauty! Perceive it!" "You are old.&q= uot; "I weep for you."

The question I= 9;m asking is if the kids are reaching far enough.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--000000000000172ca105c67edf56--