* Re: [TUHS] The Unix shell: a 50-year view @ 2021-07-03 20:07 Jon Steinhart 0 siblings, 0 replies; 4+ messages in thread From: Jon Steinhart @ 2021-07-03 20:07 UTC (permalink / raw) To: TUHS main list Wow. This is a terrible paper. It's full of of incorrect, unsubstiantiated, and meaningless statements. It's so bad in my opinion that I'm not sorry that I dropped my ACM membership a while ago. These folks really needed an editor. The paper annoys me so much that I've decided to write a lengthy note to the authors which I'll post here once I'm done. Jon ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view
@ 2021-07-02 21:56 Henry Bent
2021-07-04 18:17 ` John Dow via TUHS
0 siblings, 1 reply; 4+ messages in thread
From: Henry Bent @ 2021-07-02 21:56 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Unix Heritage Society mailing list
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
After rattling around in the back of a train car with nothing but my
thoughts, I emerged and said:
"systemd is a pox on our way of life"
and then promptly rolled over and went back to sleep.
-Henry
On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm@mcvoy.com> wrote:
> As I started reading it I found plenty to disagree with in the first few
> paragraphs but they completely lost me at "After all, moving from System
> V init scripts to systemd has arguably improvedthe Linux boot sequence."
>
> Um, no, just, no.
>
>
> On Fri, Jul 02, 2021 at 03:24:20PM -0600, Nelson H. F. Beebe wrote:
> > In this week's BSDNow.tv podcast, available at
> >
> > https://www.bsdnow.tv/409
> >
> > there is a story about a new conference paper on the Unix shell. The
> > paper is available at
> >
> > Unix shell programming: the next 50 years
> > HotOS '21: Workshop on Hot Topics in Operating Systems, Ann
> > Arbor, Michigan, 1 June, 2021--3 June, 2021
> > https://doi.org/10.1145/3458336.3465294
> >
> > The tone is overall negative, though they do say nice things about
> > Doug McIlroy and Steve Johnson, and they offer ideas about
> > improvements.
> >
> > List readers will have their own views of the paper. My own is that,
> > despite its dark corners, the Bourne shell has served us
> > extraordinarily well, and I have been writing in it daily for decades
> > without being particularly bothered by the many issues raised by the
> > paper's authors. Having dealt with so-called command shells on
> > numerous other operating systems, at least the Unix shells rarely get
> > in my way.
> >
> >
> -------------------------------------------------------------------------------
> > - Nelson H. F. Beebe Tel: +1 801 581 5254
> -
> > - University of Utah FAX: +1 801 581 4148
> -
> > - Department of Mathematics, 110 LCB Internet e-mail:
> beebe@math.utah.edu -
> > - 155 S 1400 E RM 233 beebe@acm.org
> beebe@computer.org -
> > - Salt Lake City, UT 84112-0090, USA URL:
> http://www.math.utah.edu/~beebe/ -
> >
> -------------------------------------------------------------------------------
>
> --
> ---
> Larry McVoy lm at mcvoy.com
> http://www.mcvoy.com/lm
>
[-- Attachment #2: Type: text/html, Size: 3561 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-02 21:56 [TUHS] [tuhs] " Henry Bent @ 2021-07-04 18:17 ` John Dow via TUHS 2021-07-04 19:46 ` Clem Cole 0 siblings, 1 reply; 4+ messages in thread From: John Dow via TUHS @ 2021-07-04 18:17 UTC (permalink / raw) To: Henry Bent; +Cc: The Unix Heritage Society mailing list > On 2 Jul 2021, at 22:58, Henry Bent <henry.r.bent@gmail.com> wrote: > > > After rattling around in the back of a train car with nothing but my thoughts, I emerged and said: > > "systemd is a pox on our way of life" > > and then promptly rolled over and went back to sleep. I prefer to think of it as the answer to a question that no one was asking. J ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-04 18:17 ` John Dow via TUHS @ 2021-07-04 19:46 ` Clem Cole 2021-07-05 1:33 ` Noel Hunt 0 siblings, 1 reply; 4+ messages in thread From: Clem Cole @ 2021-07-04 19:46 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 10161 bytes --] Hmm ... do I want to get in the middle of a fight with my friends and get them all mad at me… but I guess I cann’t just keep quiet on this debate. Basically I think Larry and Dan are having the Dan Akroyd/Gilda Radner “Shimmer” Dessert Topping / Floor Wax <https://www.youtube.com/watch?v=wPO8PqHGWFU> debate. That said, I do think systemd is a giant step backward for most of the same reasons others have already said, so I’ll not pile on and stick to the basic what does it mean to be Unix or not/what is an improvement or not, discussion. Larry observes: “I maybe think the reason you think that things aren't relevant anymore are because young people don't get Unix, they just pile on to this framework and that framework, NONE OF WHICH THEY UNDERSTAND, they just push more stuff onto the stack.” Simply, I could not have said that better. But that is a symptom of the problem. Frankly, with frameworks and the like, we have added so many levels of abstraction, we have completely lost sight of the real issues and many folks really don’t “think like a programmer” any more. Remember, UNIX was a system *by programmers for programmers.* Much work since has been hiding a lot of what made it great IMO - which I think has caused the most damage. What makes a system a flavor UNIX or not is almost personal, based on what you value (or not). But the fact is no matter what you call it, “UNIX” is the core kernel with a small and simple set of operations, plus a set of programs that are all based on the simple ideas, basic concepts and mostly solid mathematics/computer science that a small group of people in NJ came up with at the time, when they suggested there might be a better way to put things together than had been otherwise popular at the time. Their concepts and ideas collectively were different enough that they were encouraged to write a paper about it. That paper was accepted and published in CACM, it got a lot of people in the community interested in those ideas and the rest is history as we say. But a huge difference between then and now is the *economics* and thus the matching equipment they used to explore those new ideas. So some solutions, we take for granted today, would not be practical, much less even possible in those times. Just like some people trying to claim that ‘Linux’ is not UNIX, falls away deftly as well as it did years ago when other ‘progressive’ features were added to 'Research UNIX' and we got systems like BSD 4.1 much less 4.2. Remember smart people from Rob’s “cat -v” paper to Henry Spencer (“BSD is just like UNIX, only different” net.noise comment) in those days railed on the new BSD system as not being ‘UNIX’ either. For good or for bad, many of the things we take for granted today as being required in a UNIX system, go back to UCB features (or features from AUUG, MIT, CMU or similar). I’ve also stated many times, I do so miss the simplicity and cleanliness of V6 and V7, but I would not want to use it for my daily work today. So many of those very features that Henry and Rob pointed out back in the day, have somehow proven in fact to be ‘helpful’ or at least comfortable. While a few of us probably could live with something like ed(1), particularly with a front-end/feature more like Plan9’s sam(1), than absolutely having to have VI/EMACS. Let me offer an example as a thought exercise. I was recently helping a young hacker trying to get V5/V6/V7 going on a PDP-11 simulator so he could play with it to learn more about the 11 and UNIX itself. I gave him some help and without thinking about it in my email I mentioned that he try something, but I had forgotten that the program head(1) was a Bill Joy program wrote in 1977. What UNIX box would not have it today? As it is screwed into the ROM in my fingers when I type (actually the sources to head (1) is less than 200 lines with ¼ that being the BSD copyright, I sent him them and suggested he recompile it - partly as an exercise to see how C changed). But note that when wnj wrote head(1), Joy followed the famous ‘Unix Philosophy’ of doing one (small) job well. Which means he did not add a feature *i.e. *abusing, an old program, like cat(1), and add some new switch to it that that told the program stop outputting after n lines. Instead Joy wrote a simple new tool. This is the problem with what Larry was pointing out, I think frameworks and like are just adding features on features on features to current subsystems. Yeech!!! To me what made Unix ‘great’ was that this small (16-bit) system, with 48k-256K of memory can could practically owned by a department at $150-250K would allow you to do the same sorts of things that took a $1-4M type of system (be it a PDP-10 or IBM or the like). Mashey did his ACM lectures called “Small Is Beautiful”, sometime after they completed PWB 1.0 and this was one of his points. Unix was a small SW system on a small HW system platform, but was clean and did what you (the programmer) needed without a lot of extra cruft. IIRC for PWB 1.0, that was an 11/45 as the recommended system to run it. Not the smallest (11/40), but hardly the 11/70 either. But as the 32-bit systems became available, many of the different constraints of the PDP-11 were removed – first data size and then text size. When the VAX came and 32-bits was infinite (probably still is for text space), performance got better (and cheaper), disks got bigger, *etc*. And because it was less and less of a problem, quickly programmers got a tad lazy or at least stopped paying attention to things they were required to consider in the past. Ex (or for that matter EMACS) in thinking was the first the UCB “explosions” and maybe where UNIX began to be a tad different and look less and less like what had come from the NJ avengers. The resources of the new systems were such that you did not need a new set of small programs, you added features (extensions) to the old – and that was (is) a trap which we seem to follow today. I think other folks like to point out all the new wonder new functionality in the Linux kernel (or FreeBSd or macOS etc...) have brought to the UNIX world besides BSD’s sockets networking (loadable drivers, dynamic devices are super and I would not want to be without either). I like shared libraries, and better memory systems. Although of course on my supercomputer what are two things we turn off (shared libraries and much of the fancy memory stuff - cause they get in the way of real programs ;-). BTW: I also think sockets were (are) a terrible addition to UNIX and we did not really need them. We are stuck with them now, but I would rather have had something more like what ChaosNet and the original UofI Arpanet code, or what UNET did, where much of the network stack was in user space [which in fact was what the Interface BBN originally used]. In other places, over time, we have added window managers GUI’s *et al*. Hey the core C compiler’s code generator is remarkable compared to what it was for the PDP-11, plus we have new languages be they Rust, Go or even C++ and Java. The key point is few people are really asking the question, *if I add this new feature what does it cost, and what do we really get for it?* The truth is many of these features are all comforts and *I do like many of them* and I use them and want many of them. I like kernel support for MxN threading, but that took kernel support – what did we get beyond fork/exec that we really did not have (the answer is probably better performance due to tighter control, but I wonder if we bought much more than that). I’m typing on a Mac, while most of why ‘work’ these days is targeted Linux. But what is common is mostly I can work in the manner I want. I have something that does make some things nice (easier)… Both are ‘UNIX’ in some manner – that core of both are the same core ideas I see in V5/V6/V7 – that’s good. *i.e.* they both work as a floor wax…. But all of those new features have come at a cost, the biggest is complexity/bloat. We have lost a lot in the design because today’s programmers just don’t have to deal with the kind of constraints that some of had to deal with years ago and I think you hear a number of us groaning that when papers like this one come out, they have completely missed the point and really don’t understand what it means to be UNIX. I suspect if VM/TSO or VMS had become the core technology of the future, the papers being written today would be just as damning. If you never lived in the old world, I’m not sure you understand the improvement. I’m going to toss the gauntlet with a slightly even more political statement. When I read that paper, it reminded me of the current round of anti-vaxxers. Those of us that remember polio and other ‘childhood diseases’ have no desire to go back in time and relive it. I really don't want to run VMS/RSX or for that matter TSS/360 which was the first system I really ever knew how to use well. So in the same way, UNIX is the core technology we have today and I’m damned glad it ‘won’ be it called Linux, FreeBSD or macOS. It was not perfect then and it is hardly perfect today. But it was different from what we had at that time, and so much better - *that today we now use those ideas* from UNIX as our core ideas when we build systems. I just wish people would understand what they have and see it for the positive instead of trying to knock it down - ‘standing on the shoulders of the giants’ and showing what they did as a help, but based on solid ideas, instead of stepping on the toes trying to make their new thing/feature more valuable and claim it’s not made from the origin story. Hey Chevy… can I have some “shimmer” for my pudding. ᐧ [-- Attachment #2: Type: text/html, Size: 25136 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-04 19:46 ` Clem Cole @ 2021-07-05 1:33 ` Noel Hunt 2021-07-06 5:10 ` Nevin Liber 0 siblings, 1 reply; 4+ messages in thread From: Noel Hunt @ 2021-07-05 1:33 UTC (permalink / raw) To: Clem Cole; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 561 bytes --] > But note that when wnj wrote head(1), Joy followed the > famous `Unix Philosophy' of doing one (small) job > well. Which means he did not add a feature *i.e.* > abusing, an old program, like cat(1), and add some new > switch to it that that told the program stop outputting > after n lines. Instead Joy wrote a simple new tool. He didn't need to abuse any existing program by adding new flags or the like; unless I am mistaken, `sed Nq', for some number `N', does exactly what `head -N' would do on a single file, obviating the very need for head(1). > [-- Attachment #2: Type: text/html, Size: 1006 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-05 1:33 ` Noel Hunt @ 2021-07-06 5:10 ` Nevin Liber 2021-07-06 13:30 ` Clem Cole 0 siblings, 1 reply; 4+ messages in thread From: Nevin Liber @ 2021-07-06 5:10 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 542 bytes --] > > > He didn't need to abuse any existing program by adding new > flags or the like; unless I am mistaken, `sed Nq', for some > number `N', does exactly what `head -N' would do on a single > file, obviating the very need for head(1). > To summarize this discussion: cat -v should be a separate executable and not a command line option. That's the Unix way. head isn't needed because we can already do it with the command line options for sed. That's the Unix way. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404 [-- Attachment #2: Type: text/html, Size: 1225 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-06 5:10 ` Nevin Liber @ 2021-07-06 13:30 ` Clem Cole 2021-07-06 16:23 ` Theodore Ts'o 0 siblings, 1 reply; 4+ messages in thread From: Clem Cole @ 2021-07-06 13:30 UTC (permalink / raw) To: Nevin Liber; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2152 bytes --] On Tue, Jul 6, 2021 at 1:13 AM Nevin Liber <nevin@eviloverlord.com> wrote: > head isn't needed because we can already do it with the command line >> options for sed. >> > Sigh ... fine except for the fact that sed(1) did not exist when head(1) was written. So you missed the point of my example. FWIW: if you want to pick nits, in this case, the solution with the former is redundant with the latter. IMO, That's ok as it follows in the basic tradition. UNIX has a number of ways to do similar things/solve the same problem, because it offers tools, the system designers do not try to dictate a singular solution. As I fear by the reaction, many of you have missed the point of what I was trying to say. I guess I did not do that clearly. Let me try in a shorter form. 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). Mashey had a great visual in his "small is beautiful" talk using a 'build slide' in PPT terms that demonstrated the problem. 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. ᐧ [-- Attachment #2: Type: text/html, Size: 5126 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-06 13:30 ` Clem Cole @ 2021-07-06 16:23 ` Theodore Ts'o 2021-07-07 1:57 ` Dan Cross 0 siblings, 1 reply; 4+ messages in thread From: Theodore Ts'o @ 2021-07-06 16:23 UTC (permalink / raw) To: Clem Cole; +Cc: The Unix Heritage Society mailing list 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 > 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. - Ted ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-06 16:23 ` Theodore Ts'o @ 2021-07-07 1:57 ` Dan Cross 2021-07-07 18:28 ` Jon Steinhart 0 siblings, 1 reply; 4+ messages in thread From: Dan Cross @ 2021-07-07 1:57 UTC (permalink / raw) To: Theodore Ts'o; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 7141 bytes --] On Tue, Jul 6, 2021 at 12:25 PM Theodore Ts'o <tytso@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. [-- Attachment #2: Type: text/html, Size: 8656 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] [tuhs] The Unix shell: a 50-year view 2021-07-07 1:57 ` Dan Cross @ 2021-07-07 18:28 ` Jon Steinhart 2021-07-10 11:51 ` [TUHS] " Ralph Corderoy 0 siblings, 1 reply; 4+ messages in thread From: Jon Steinhart @ 2021-07-07 18:28 UTC (permalink / raw) To: The Unix Heritage Society mailing list Dan Cross writes: > > 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. Been trying hard to resist but here goes... On the snarky side, yeah, problems are different now, and the shell paper is a great example. Such a bad paper winning a best paper award from the ACM illustrates how the profession just ain't what it used to be. I would claim that a large chunk of "software engineering" today involves trying to build environments that minimize the amount of harm that can be done by under-skilled practitioners. I have difficulty envisioning success as there's a heavy focus on memory management which to me is a great competency test. Just because one is coddled and can't corrupt memory doesn't mean that the the remainder of their code is correct. These things go hand-in-hand. I'm going to stick my neck out and claim that to a large degree we're the victims of our own success. When I was writing my book, Clem pointed out to me that a big assumption that Stallman made was that people who would contribute to open source software would be of his caliber. I don't think that he ever thought that we'd get to the point where every programming class project would be published online and reused by others without much inspection. To me it's analogous to what happened with MIDI when one could make "music" without having suffered for their art like their predecessors. Just decreased the signal-to-noise ratio for me and made it much more cumbersome to find music that I liked. Many of the problems that people seem to be trying to solve today are of our own making. I don't see the benefit of Linux distributions being incompatible in annoying ways. If each distro didn't put things in different places for no discernible reason, we wouldn't need to be putting as much non-productive energy into tools for deployment. Likewise if there was any rhyme or reason for what's in what library and more attention to API design and stability. I kinda have to go back to my 1989 Usenix panel session; given the choice between having a good base and covering up a bad base with a pile of other code I choose the first. Sure, if we make stuff with tons of preventable dependencies then we have to work with that, but I'd rather not have the problem in the first place. Another one - I recall when a lot of work went into making it possible to link C and FORTRAN programs. Instead of continuing along that path, now we have multiple systems (PHP, Python, Perl, Java, ...) that have each written their own libraries for everything. To me, I would have preferred to have a single set of libraries and the ability to link. Aside from the enormous waste of person-hours, there is a huge non-intersecting set of bugs. In theory we'd have fewer bugs if more people were using the same libraries. And better programmer portability too. I'm often surprised when people claim that the UNIX philosophy no longer works. I've been told "pipes only work for ASCII data" and have gotten blank looks when I respond with "ImageMagick seems to work fine". And "you can't do modern web crud" but then along came things like "jq". To me, the UNIX philosophy beats the big monolithic program philosophy every time. Sure, these two don't interact when big monolithic programs are crafted such that they don't play well with others but that's not the fault of the UNIX philosophy, it's the fault of the monolithic program design. Watch Matt Blaze's 2016 congressional testimony if you haven't already done so. He makes a great case that we know that we can't prove program correctness despite trying to do so since the beginning of time, so the best security comes from simplicity which minimizes the number of attack surfaces. So rather than saying that the UNIX philosophy no longer works, how about giving some serious thought to how to do what you want to do in the context of the philosophy? In particular, how to you extend the existing tool set to accomplish your purpose instead of just throwing up your hands and creating more big monolithic non-interoperable packages? Certainly the first is harder, but lasts longer and tastes great too. A question that I asked in my book was why ~0% of the 1200 pages of "Inside Macintosh" from 1985 are used today compared to ~100% of the 323 pages of UNIX V6 from 1975. My answer is "abstractions". I don't see any of the "modern packages" having that level of staying power. There is a lot more to the UNIX philosophy than "Everything is a file" and "files are streams of bytes"; it's a mindset. I have no problem with model expansion and structure reexamination. But piling poorly thought out crap on top of other poorly thought out crap isn't a solution to me. What new problems are you trying to solve and what are the appropriate abstractions (and how much of this was done in Plan 9 and ignored)? Haven't thought about this in forever as it's several lifetimes ago. Once upon a time I was responsible for implementing GKS (the useless ISO Graphical Kernel System) on a workstation project and was participating in the ANSI standardization effort. At the time, there was another standard (PHIGS - Programmer's Hierarchical Interface to GraphicS) in the works; I remember asking why. The answer was that there was no way to add segment hierarchy and editing to GKS in a compatible way. In reality, the folks just wanted to do their own thing; they were furious when I published a paper on how to easily add that functionality to GKS. It's easy to say that something can't be done; harder to put in some serious thought to figure out how it can be done. Bottom line is, just read the news. Is today's software methodology working? Does the fact that Facebook is funding a PR campaign to convince people that privacy breaches are normal tell you anything? There's a lot of similarity between modern software and the Surfside condo; shiny stuff on top of a crumbling foundation is bound to fail. In lectures these days, I'm asking the question "We haven't managed to off more than a thousand or so people at a time with a software bug yet so what's going to be software's Union Carbide Bhopal moment?" Jon Steinhart P.S. On another topic, GUIs were the killer app for threads. Sure, I would much prefer faster process context switching. Still waiting for that. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] The Unix shell: a 50-year view 2021-07-07 18:28 ` Jon Steinhart @ 2021-07-10 11:51 ` Ralph Corderoy 2021-07-10 13:54 ` Henry Bent 0 siblings, 1 reply; 4+ messages in thread From: Ralph Corderoy @ 2021-07-10 11:51 UTC (permalink / raw) To: The Unix Heritage Society mailing list Hi, Jon Steinhart wrote: > In lectures these days, I'm asking the question "We haven't managed to > off more than a thousand or so people at a time with a software bug > yet so what's going to be software's Union Carbide Bhopal moment?" If buggy code rather than a single bug counts then the software model written over fifteen years by Neil Ferguson of Imperial College, London, which has been instrumental in poor UK Government policy decisions on COVID-19 has easily topped more than a thousand deaths in the net tally. It was a single 15,000-line file of C, written by a non-programmer. Eventually, ic.ac.uk released a C++ version which had been worked on by Microsoft and other volunteers for a month so it could face the public. ‘For me the code is not a mess, but it’s all in my head, completely undocumented. Nobody would be able to use it... and I don’t have the bandwidth to support individual users.’ ― Neil Ferguson. Politician Steve Baker MP, a former senior programmer, has been critical of the public version and commissioned a review by Mike Hearn. A path to Hearn's paper starts at https://threadreaderapp.com/thread/1323897771510943745.html And another coder critique is at https://lockdownsceptics.org/code-review-of-fergusons-model/ The numbers from Ferguson's original pre-release C program were presented by him to Number 10 and were instrumental in setting the UK on the path of lockdowns. ‘...lockdowns are the single worst public health mistake in the last 100 years’ ― Jay Bhattacharya, professor of medicine at Stanford University. -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] The Unix shell: a 50-year view 2021-07-10 11:51 ` [TUHS] " Ralph Corderoy @ 2021-07-10 13:54 ` Henry Bent 2021-07-10 14:12 ` Ralph Corderoy 0 siblings, 1 reply; 4+ messages in thread From: Henry Bent @ 2021-07-10 13:54 UTC (permalink / raw) To: Ralph Corderoy; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2471 bytes --] I'm going to come right out ahead of any path to the contrary and say that I'm in favor of the lockdowns that were enacted in the US. I very plainly do not trust the population here to make reasonable decisions, even in the face of clearly presented evidence to the contrary. Furthermore, I have not seen any evidence that US lawmakers acted according to any model whatsoever. The evidence being what it is, I applaud UK lawmakers for acting as they did, and our hindsight evidence can only support increased funding for statistical modeling. It wasn't a widely regarded field before this and I can only hope that its support improves after this. -Henry On Sat, 10 Jul 2021 at 08:02, Ralph Corderoy <ralph@inputplus.co.uk> wrote: > Hi, > > Jon Steinhart wrote: > > In lectures these days, I'm asking the question "We haven't managed to > > off more than a thousand or so people at a time with a software bug > > yet so what's going to be software's Union Carbide Bhopal moment?" > > If buggy code rather than a single bug counts then the software model > written over fifteen years by Neil Ferguson of Imperial College, London, > which has been instrumental in poor UK Government policy decisions on > COVID-19 has easily topped more than a thousand deaths in the net tally. > > It was a single 15,000-line file of C, written by a non-programmer. > Eventually, ic.ac.uk released a C++ version which had been worked on by > Microsoft and other volunteers for a month so it could face the public. > > ‘For me the code is not a mess, but it’s all in my head, completely > undocumented. Nobody would be able to use it... and I don’t have > the bandwidth to support individual users.’ ― Neil Ferguson. > > Politician Steve Baker MP, a former senior programmer, has been critical > of the public version and commissioned a review by Mike Hearn. A path > to Hearn's paper starts at > https://threadreaderapp.com/thread/1323897771510943745.html > > And another coder critique is at > https://lockdownsceptics.org/code-review-of-fergusons-model/ > > The numbers from Ferguson's original pre-release C program were > presented by him to Number 10 and were instrumental in setting the UK on > the path of lockdowns. ‘...lockdowns are the single worst public health > mistake in the last 100 years’ ― Jay Bhattacharya, professor of medicine > at Stanford University. > > -- > Cheers, Ralph. > [-- Attachment #2: Type: text/html, Size: 3223 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [TUHS] The Unix shell: a 50-year view 2021-07-10 13:54 ` Henry Bent @ 2021-07-10 14:12 ` Ralph Corderoy 0 siblings, 0 replies; 4+ messages in thread From: Ralph Corderoy @ 2021-07-10 14:12 UTC (permalink / raw) To: The Unix Heritage Society mailing list Hi Henry, > I'm going to come right out ahead of any path to the contrary and say > that I'm in favor of the lockdowns that were enacted in the US. Death-by-bug is OT enough for TUHS to begin with, though ‘entertaining’. Can we try and keep the thread to that together with any argument for why a bug caused net deaths. -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-10 14:12 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-03 20:07 [TUHS] The Unix shell: a 50-year view Jon Steinhart -- strict thread matches above, loose matches on Subject: below -- 2021-07-02 21:56 [TUHS] [tuhs] " Henry Bent 2021-07-04 18:17 ` John Dow via TUHS 2021-07-04 19:46 ` Clem Cole 2021-07-05 1:33 ` Noel Hunt 2021-07-06 5:10 ` Nevin Liber 2021-07-06 13:30 ` Clem Cole 2021-07-06 16:23 ` Theodore Ts'o 2021-07-07 1:57 ` Dan Cross 2021-07-07 18:28 ` Jon Steinhart 2021-07-10 11:51 ` [TUHS] " Ralph Corderoy 2021-07-10 13:54 ` Henry Bent 2021-07-10 14:12 ` Ralph Corderoy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).