From scj at yaccman.com Fri Jul 2 11:36:04 2021
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 01 Jul 2021 18:36:04 -0700
Subject: [TUHS] Disassemblers
In-Reply-To: <CAC20D2POxdHJsSvRjSozASUWXQ+YAUaSA+7mAoPx1-JsTYHb1g@mail.gmail.com>
References: <CAEdTPBdbNcsjg64GV4u9_7scP1p3RQGfJniQ+Defbvjr0_cR9w@mail.gmail.com>
<CAC20D2Ny25FuucygeLRfMfm+gxE8DJPSg+vp0n5OEtC11_Z_fA@mail.gmail.com>
<CAEdTPBdha+dNCqypSKNuQf0X31oH=M=3Te4GLHyv5WDKE04YTQ@mail.gmail.com>
<CAC20D2POxdHJsSvRjSozASUWXQ+YAUaSA+7mAoPx1-JsTYHb1g@mail.gmail.com>
Message-ID: <0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com>
I saw this post and it reminded me of a meeting that Dennis and I had
with Bill Wulf. At one point, Dennis decided to write an optimizer but
gave up after a week or two because when he had coded the data
structures he needed he had filled up the PDP-11 memory! It was a very
strong part of the Unix meme that Unix and C would run on small
computers since most of the universities couldn't afford bigger ones at
the time.
When PCC came along and started running on 32-bit machines, I started
thinking about algorithms for optimization. A problem that I had no
good solution for could be illustrated by a simple piece of code:
x = *p;
y = *q;
q gets changed
*q = z;
The question is, do I need to reload x now because q might have been
changed to point to the same place as p? At around this time, Al Aho
was invited to go to CMU and give a talk, and he invited me to come with
him. We spent about an hour and a half one-on-one with Bill Wulf -- I
seem to remember a lot of mutual respect going on. But when I asked him
about my problem, he really didn't have much to say about it. I finally
got him to agree that his compiler had a bug. But he said there was a
flag they could set on the compiler that would turn of optimization and
if your program had mysterious bugs, you should use the flag.
I recall that Al, always in search of better algorithms, was a bit
disappointed -- I was a bit more pragmatic about it. On the whole, it
was a good meeting, and the "Engineering ... Compiler" book was one of
my favorites when it came out.
Steve
---
On 2021-06-19 09:59, Clem Cole wrote:
> On Sat, Jun 19, 2021 at 12:33 PM Henry Bent <henry.r.bent at gmail.com> wrote:
>
>> Wait, so it was easier to write an emulator for a PDP-10 binary than it would have been to port BLISS to the PDP-11? Given the different word sizes I would not have expected that.
>
> BLISS-11 was (way) too big to run in the 64K address of the PDP-11 (even separated I/D). Originally, it was a PDP-10 cross compiler and later moved to the Vax. It generated much better code than the original Ritchie or later Johnson compilers. The code generator/optimizer was famous (literally the book on code optimization was written about it, called of course: "The Design of an Optimizing Compiler" [1] by Wulf and some of his students [ISBN 0444001581] - _a.k.a._ 'The Green Book' worth reading BTW.
>
> Later on, DEC's TLG tried at least twice that I know of to make it self-hosting but gave up. Long story (and definitely a different thread) if DEC has not screwed up the marketing of BLISS, I suspect it might have given C a run for the money. But BLISS _vs_. C is a great example of Cole's law that _Simple Economics always beats Sophisticated Architecture_ [and using Christensen's 'disruptive theory -- it gets better and supplants the incombent].
>
> Anyway, the compiler/code generator/linker for DEC Fortran-IV for RT-11, RSX, and DOS-11 was written in BLISS-11. So for CU to retarget it for V6 they needed a PDP-10, which they did not have. So they wrote a simulator. I remember when they gave a talk about it at Usenix, somebody asked them how well Tenex ran on it.
>
>> Did they have a cover sheet or something equivalent that they came with? I'm having trouble imagining dealing with that much unindexed data on an early system.
>
> Not to my knowledge. Two things that I believe we need to do for the TUHS archives to be even more meaningful is 1.) decode them from tp/ar -- even if you read the tape, they are packed together in v5/v6 ar files which are PDP-11 binary. 2.) Create an index of what is there.
>
> I've thought about both things but have way too much on my plate to do it myself.
>
>> Fascinating. Thank you as always for the insight.
>
> Most welcome.
> Clem
> бђ§
Links:
------
[1]
https://www.amazon.com/Design-Optimizing-Compiler-William-Allan/dp/0444001581
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210701/32e996e1/attachment.htm>
From crossd at gmail.com Fri Jul 2 12:05:42 2021
From: crossd at gmail.com (Dan Cross)
Date: Thu, 1 Jul 2021 22:05:42 -0400
Subject: [TUHS] First machine to run rogue?
Message-ID: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
What was the first machine to run rogue? I understand that it was written
by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
`curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
at least one place that indicates it first ran on 6th Edition, but that
doesn't sound right to me. The first reference I can find in BSD is in 2.79
("rogue.doc"), which also appears to be the first release to ship curses.
Anyone have any info? Thanks!
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210701/b76f4fa2/attachment.htm>
From scj at yaccman.com Fri Jul 2 12:13:05 2021
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 01 Jul 2021 19:13:05 -0700
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
References: <CMM.0.95.0.1621987920.beebe@gamma.math.utah.edu>
<CAKzdPgzJsQKMx5BB3sybzAd2HRUnd6L0K-akVepL+538_UOC2w@mail.gmail.com>
<20210526030341.GD27558@mcvoy.com>
<2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
<CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
Message-ID: <e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
I found Dennis's compiler to be a thing of beauty when compiling
statements, but hell on wheels when doing expressions. One of the
motivations for writing Yacc was that I wanted to add the exclusive or
into the expression syntax and we had agreed on the character (^) and
the precedence. Practically the whole expression grammar needed to be
rewritten, and small typos created un-debuggable chaos. The state of
the art at the time was to write multi-layered grammars for each
precedence level. A paper was published on how to shrink the resulting
parsing tables by eliminating redundant states. I realized that the
same results could be obtained by writing an ambiguous expression
grammar and using a precedence table to resolve the ambiguities. The
initial response in the academic community to programming with ambiguous
grammars was somewhere between skeptical and horrified -- as if I had
shown porn to a Victorian. So Al and I worked out a proof that we would
get the same optimized parser in a much more intuitive way.
I do agree with Rob that some of the languages that Yacc gave birth to
should never have been born. Remember, though, that the dominant
language at the time was FORTRAN, and it had all sorts of strange
implementation issues in their hand-written compilers. Things like
subscript indices had to be single variables in some places, and in
others could have a constant added to the index. One of Yacc's best
features was that it made consistency of usage the path of least
resistance when designing the language, and the grammar was often easier
to understand than the programming manual. At Bell Labs, Barbara Ryder
wrote a program that would read FORTRAN and detect things that would not
work on one or more of the six major FORTRAN's at the time. It was an
inspiration for me, later, do the same thing with Lint.
I do suggest that having languages like C++ that have bloated up to over
1000 pages in the programmer reference doesn't feel like a real advance,
especially since the real language problems of today are how to program
very large numbers of processor-like objects on a single chip. We need
new ways to think, and I doubt that we'll get there by making C++
require a 2000-page manual.
---
On 2021-05-25 23:52, Rob Pike wrote:
> I enjoy writing recursive descent parsers, and I enjoy the grammars that result from such parsers when cleanly done.
>
> I do agree though that if you grammar is being invented as you go, yacc can be a boon. But in a sense, that's also it's biggest failing: it makes it too easy to write bad grammars.
>
> -rob
>
> On Wed, May 26, 2021 at 4:22 PM Bakul Shah <bakul at iitbombay.org> wrote:
>
>> Many existing programming languages do have a simple enough
>> syntax to make it easy to write a recursive descent parser for them
>> but not alll.
>>
>> Handwritten recursive descent parsers are often LL(1) with may be
>> a separate operator-precedence parsing for expressions.
>>
>> If you are defining a new language syntax you can make sure parsing
>> is easy but not all languages are LL(1) (which is a subset of LALR(1),
>> which is a subset of LR(1), which is a subset of GLR). Handwritten
>> parsers for these more general grammars are bound to get more
>> complicated.
>>
>> Even *we* understand parsing, writing a parser for some existing
>> languages which grew "organically" can become tedious, or
>> complicated or adhoc. Often such languages have no well specified
>> grammar (the code is the specification!). A yacc grammar would help.
>>
>> Often one writes a yacc grammar while a new language & its syntax
>> is evolving. Changing a yacc file is more localized & easier than fixing
>> up a handwritten parser. Even Go has such a grammar initially.
>>
>> -- Bakul
>>
>>> On May 25, 2021, at 8:03 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>
>>> You do, I don't. I'm not alone in my lack of understanding.
>>>
>>> I think that all the things that yacc solved, Steve gets some kudos.
>>> I've used it a bunch and I did not need to be as smart as you or
>>> Steve to get the job done.
>>>
>>> You getting past that is cool but it doesn't make his work less.
>>>
>>> On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote:
>>>> And today, we understand parsing so well we don't need yacc.
>>>>
>>>> -rob
>>>>
>>>>
>>>> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe <beebe at math.utah.edu>
>>>> wrote:
>>>>
>>>>> The last article of the latest issue of the Communications of the ACM
>>>>> that appeared electronically earlier today is a brief interview with
>>>>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman.
>>>>>
>>>>> The article is
>>>>>
>>>>> Last byte: Shaping the foundations of programming languages
>>>>> https://doi.org/10.1145/3460442
>>>>> Comm. ACM 64(6), 120, 119, June 2021.
>>>>>
>>>>> and it includes a picture of the two winners sitting on Dennis
>>>>> Ritchie's couch.
>>>>>
>>>>> I liked this snippet from Jeff Ullman, praising fellow list member
>>>>> Steve Johnson's landmark program, yacc:
>>>>>
>>>>>>> ...
>>>>>>> At the time of the first Fortran compiler, it took several
>>>>>>> person-years to write a parser. By the time yacc came around,
>>>>>>> you could do it in an afternoon.
>>>>>>> ...
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------------
>>>>> - 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 at math.utah.edu -
>>>>> - 155 S 1400 E RM 233 beebe at acm.org
>>>>> beebe at computer.org -
>>>>> - Salt Lake City, UT 84112-0090, USA URL:
>>>>> http://www.math.utah.edu/~beebe/ -
>>>>>
>>>>> -------------------------------------------------------------------------------
>>>>>
>>>
>>> --
>>> ---
>>> Larry McVoy lm at mcvoy.com [1] http://www.mcvoy.com/lm
Links:
------
[1] http://mcvoy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210701/b4c2aad0/attachment.htm>
From clemc at ccc.com Fri Jul 2 12:51:22 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Jul 2021 22:51:22 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
Message-ID: <CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
I first got it on V7, as I said on our 11/70 for sure but I don’t remember
if we had it on the 11/60 before that.
On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
> What was the first machine to run rogue? I understand that it was written
> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
> `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
> at least one place that indicates it first ran on 6th Edition, but that
> doesn't sound right to me. The first reference I can find in BSD is in 2.79
> ("rogue.doc"), which also appears to be the first release to ship curses.
>
> Anyone have any info? Thanks!
>
> - Dan C.
>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210701/42013602/attachment.htm>
From robpike at gmail.com Fri Jul 2 14:40:09 2021
From: robpike at gmail.com (Rob Pike)
Date: Fri, 2 Jul 2021 14:40:09 +1000
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <CAKzdPgxGOZLLQzzPKe3kyAq1soAYPHwyeVP2iePiE8zMSk=f7g@mail.gmail.com>
References: <CMM.0.95.0.1621987920.beebe@gamma.math.utah.edu>
<CAKzdPgzJsQKMx5BB3sybzAd2HRUnd6L0K-akVepL+538_UOC2w@mail.gmail.com>
<20210526030341.GD27558@mcvoy.com>
<2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
<CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
<e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
<CAKzdPgw6zkXg9tB8uoPOZBv2C5nV8=N4kuW8-tHCUoby=9ki+Q@mail.gmail.com>
<CAKzdPgxGOZLLQzzPKe3kyAq1soAYPHwyeVP2iePiE8zMSk=f7g@mail.gmail.com>
Message-ID: <CAKzdPgw4PMS1uMLT1gJuz=yPDJ4tfo_9MWkKRiixh57JGtVobQ@mail.gmail.com>
<resending with the program as an attachment, as 100K is considered big
here, and no images hidden in reply. moderator, you can kill the prior
messages. computers are hard.>
To show you what I mean, here is a parser I wrote recently for a simple Go
expression evaluator, in Go. It has all Go's precedence levels and
operators. The one odd detail is that >= etc. can be combined, as in 1 >= 2
> 3, but that doesn't matter in the context of this program and is easily
avoided with a few more lines in cmpList.
I'm using a screen grab because GMail refuses to leave my indentation
alone. I left factor off. It's got all the usual details but it's the leaf
of the grammar and of no interest here.
Note that this could easily have been made a table instead of a bunch of
one-line functions.
Parsers are easy to write. It took us a generation (or more) to understand
that, but it's remarkable nonetheless. The first big step might have been
realizing that recursion was a good idea, even if you weren't writing LISP,
if the data structure is itself recursive.
-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/6ba85e78/attachment.htm>
-------------- next part --------------
// parse implements a production in the expression parse hierarchy. Singles and
// doubles are strings holding the operators that are available at at this precedence
// level, while nextLevel implements the next higher precendence level.
func (p *parser) parse(singles, doubles string, nextLevel func(*parser) *Expr) *Expr {
e := nextLevel(p)
for {
if p.peek(true) == eof {
return e
}
op := p.op(singles, doubles)
if op == "" {
return e
}
e = &Expr{
op: op,
left: e,
right: nextLevel(p),
}
}
}
// orlist = andList | andList '||' orList.
func orList(p *parser) *Expr {
return p.parse("", "||", andList)
}
// andlist = cmpList | cmpList '&&' andList.
func andList(p *parser) *Expr {
return p.parse("", "&&", cmpList)
}
// cmpList = expr | expr ('>' | '<' | '==' | '!=' | '>=' | '<=') expr.
func cmpList(p *parser) *Expr {
return p.parse("+-|^!><", "==!=>=<=", expr)
}
// expr = term | term ('+' | '-' | '|' | '^') term.
func expr(p *parser) *Expr {
return p.parse("+-|^!", "", term)
}
// term = factor | factor ('*' | '/' | '%' | '>>' | '<<' | '&' | '&^') factor
func term(p *parser) *Expr {
return p.parse("*/%&", ">><<&^", factor)
}
// factor = constant | identifier | '+' factor | '-' factor | '^' factor | '!' factor | '(' orList ')'
func factor(p *parser) *Expr {
From ggm at algebras.org Fri Jul 2 16:29:19 2021
From: ggm at algebras.org (George Michaelson)
Date: Fri, 2 Jul 2021 16:29:19 +1000
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <CAKzdPgw4PMS1uMLT1gJuz=yPDJ4tfo_9MWkKRiixh57JGtVobQ@mail.gmail.com>
References: <CMM.0.95.0.1621987920.beebe@gamma.math.utah.edu>
<CAKzdPgzJsQKMx5BB3sybzAd2HRUnd6L0K-akVepL+538_UOC2w@mail.gmail.com>
<20210526030341.GD27558@mcvoy.com>
<2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
<CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
<e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
<CAKzdPgw6zkXg9tB8uoPOZBv2C5nV8=N4kuW8-tHCUoby=9ki+Q@mail.gmail.com>
<CAKzdPgxGOZLLQzzPKe3kyAq1soAYPHwyeVP2iePiE8zMSk=f7g@mail.gmail.com>
<CAKzdPgw4PMS1uMLT1gJuz=yPDJ4tfo_9MWkKRiixh57JGtVobQ@mail.gmail.com>
Message-ID: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
> Note that this could easily have been made a table instead of a bunch of one-line functions.
a table.. hmm. so like.. we could write .. engines to "read" the table
and do things in some kind of (maybe.. finite) way?
I know, lets write a DSL to MAKE THE TABLE...
Is all software "wheel of life" ?
From bakul at iitbombay.org Fri Jul 2 17:00:21 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 2 Jul 2021 00:00:21 -0700
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
References: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
Message-ID: <C728300B-6E54-4C25-A160-C1392BE37469@iitbombay.org>
> On Jul 1, 2021, at 11:30 PM, George Michaelson <ggm at algebras.org> wrote:
>
> п»ї
>>
>> Note that this could easily have been made a table instead of a bunch of one-line functions.
>
> a table.. hmm. so like.. we could write .. engines to "read" the table
> and do things in some kind of (maybe.. finite) way?
>
> I know, lets write a DSL to MAKE THE TABLE...
>
> Is all software "wheel of life" ?
It would be just an operator precedence table and two functions. One to
parse a factor and one for binary expressions. The table might be something
like an array of {singles, doubles, associativity}, where the Nth entry
has precedence N. The binary expr parser uses the table to essentially
group sub expressions based on precedence and associativity. This is an old
idea. I think at least 4-5 decades old.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/b58fc9b7/attachment.htm>
From crossd at gmail.com Fri Jul 2 21:24:16 2021
From: crossd at gmail.com (Dan Cross)
Date: Fri, 2 Jul 2021 07:24:16 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
Message-ID: <CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
Thanks, Clem. I'm curious what other lore is out there: my suspicion is
that rogue never ran on vanilla v6, but it would be great to validate.
On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
> I first got it on V7, as I said on our 11/70 for sure but I don’t remember
> if we had it on the 11/60 before that.
>
> On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
>
>> What was the first machine to run rogue? I understand that it was written
>> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
>> `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
>> at least one place that indicates it first ran on 6th Edition, but that
>> doesn't sound right to me. The first reference I can find in BSD is in 2.79
>> ("rogue.doc"), which also appears to be the first release to ship curses.
>>
>> Anyone have any info? Thanks!
>>
>> - Dan C.
>>
>> --
> Sent from a handheld expect more typos than usual
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/db99fb1a/attachment.htm>
From arnold at skeeve.com Fri Jul 2 21:40:32 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 02 Jul 2021 05:40:32 -0600
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
Message-ID: <202107021140.162BeWZt018129@freefriends.org>
Is the rogue source extant? I remember many people spending many
hours on rogue on the 4.[12] BSD vax at Georgia Tech.
ISTR that rogue only came as a binary, there was no source.
Arnold
Dan Cross <crossd at gmail.com> wrote:
> Thanks, Clem. I'm curious what other lore is out there: my suspicion is
> that rogue never ran on vanilla v6, but it would be great to validate.
>
> On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
>
> > I first got it on V7, as I said on our 11/70 for sure but I don’t remember
> > if we had it on the 11/60 before that.
> >
> > On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
> >
> >> What was the first machine to run rogue? I understand that it was written
> >> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
> >> `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
> >> at least one place that indicates it first ran on 6th Edition, but that
> >> doesn't sound right to me. The first reference I can find in BSD is in 2.79
> >> ("rogue.doc"), which also appears to be the first release to ship curses.
> >>
> >> Anyone have any info? Thanks!
> >>
> >> - Dan C.
> >>
> >> --
> > Sent from a handheld expect more typos than usual
> >
From crossd at gmail.com Fri Jul 2 22:14:59 2021
From: crossd at gmail.com (Dan Cross)
Date: Fri, 2 Jul 2021 08:14:59 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <202107021140.162BeWZt018129@freefriends.org>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
Message-ID: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
On Fri, Jul 2, 2021 at 7:40 AM <arnold at skeeve.com> wrote:
> Is the rogue source extant? I remember many people spending many
> hours on rogue on the 4.[12] BSD vax at Georgia Tech.
>
> ISTR that rogue only came as a binary, there was no source.
>
It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
sources there are listed as "public domain rogue", but I'm not sure about
the provenance of that code.
- Dan C.
Arnold
>
> Dan Cross <crossd at gmail.com> wrote:
>
> > Thanks, Clem. I'm curious what other lore is out there: my suspicion is
> > that rogue never ran on vanilla v6, but it would be great to validate.
> >
> > On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
> >
> > > I first got it on V7, as I said on our 11/70 for sure but I don’t
> remember
> > > if we had it on the 11/60 before that.
> > >
> > > On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
> > >
> > >> What was the first machine to run rogue? I understand that it was
> written
> > >> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
> > >> `curses` library (Ken Arnold's original, not Mary Ann's rewrite).
> I've seen
> > >> at least one place that indicates it first ran on 6th Edition, but
> that
> > >> doesn't sound right to me. The first reference I can find in BSD is
> in 2.79
> > >> ("rogue.doc"), which also appears to be the first release to ship
> curses.
> > >>
> > >> Anyone have any info? Thanks!
> > >>
> > >> - Dan C.
> > >>
> > >> --
> > > Sent from a handheld expect more typos than usual
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/2c1630b8/attachment.htm>
From clemc at ccc.com Fri Jul 2 23:04:47 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 2 Jul 2021 09:04:47 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <202107021140.162BeWZt018129@freefriends.org>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
Message-ID: <CAC20D2PepaO8mtat=J1CPg-nFO4-c4WbjNAK+_Q60a1_y5djEw@mail.gmail.com>
On Fri, Jul 2, 2021 at 7:40 AM <arnold at skeeve.com> wrote:
> Is the rogue source extant?
>
Yes -- but ...
>
> ISTR that rogue only came as a binary, there was no source.
>
That was true at first, certainly the original binary was passed around.
It might have been an early net.noise pass around, but ISTR for Tektronix
on V7 I got the binary from someone at UCB directly -- Mark Bales, maybe,
who was a UCB doing a summer Internship and he may have brought them with
him.
The sources were later released as part of a CSRG release in the post 4.2
timeframe ??reno/tahoe I think??, but by then the binary for the Vax was
pretty popular and the sources had begun to sneak out - as I know I had
them at Masscomp and Sun had them too. Paul Cantrell (of video teco fame)
created a color version of it and IIRC may have added some other graphics
when running on a Masscomp tube.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/b20a2922/attachment.htm>
From clemc at ccc.com Fri Jul 2 23:07:15 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 2 Jul 2021 09:07:15 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
Message-ID: <CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
On Fri, Jul 2, 2021 at 8:15 AM Dan Cross <crossd at gmail.com> wrote:
> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
> sources there are listed as "public domain rogue", but I'm not sure about
> the provenance of that code.
>
That sounds right, you should ask Ken Arnold offline, I bet he had a better
idea. He would have made them available to Keith.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/35a976d1/attachment.htm>
From bakul at iitbombay.org Fri Jul 2 23:11:21 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 2 Jul 2021 06:11:21 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
References: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
Message-ID: <E6590126-A8CA-4BC0-B7F5-D49956BAFBFB@iitbombay.org>
Glenn wrote up a brief history where he says it was first distributed with 4.2bsd.
https://web.archive.org/web/19980625212119/http://www.wichman.org/roguehistory.html
@ Fortune Systems in 1983/83 we had 3-4 college students working for a contract company Santa Cruz Operations(?) doing testing for us. He was one of them and later we hired him full time. I didn’t interact with him much though and once I quit Fortune I lost track of him. I think initially we had only a rogue binary on 4.1 running on VAX780 but I do not recall if he brought it to Fortune. Someone later ported it to the Fortune machine. I used to play Rogue while waiting for kernel compiles to finish. A few years ago I got it on FreeBSD and my muscle memory came back 100%!
> On Jul 2, 2021, at 5:16 AM, Dan Cross <crossd at gmail.com> wrote:
> п»ї
> On Fri, Jul 2, 2021 at 7:40 AM <arnold at skeeve.com> wrote:
>> Is the rogue source extant? I remember many people spending many
>> hours on rogue on the 4.[12] BSD vax at Georgia Tech.
>>
>> ISTR that rogue only came as a binary, there was no source.
>
> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The sources there are listed as "public domain rogue", but I'm not sure about the provenance of that code.
>
> - Dan C.
>
>
>> Arnold
>>
>> Dan Cross <crossd at gmail.com> wrote:
>>
>> > Thanks, Clem. I'm curious what other lore is out there: my suspicion is
>> > that rogue never ran on vanilla v6, but it would be great to validate.
>> >
>> > On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
>> >
>> > > I first got it on V7, as I said on our 11/70 for sure but I don’t remember
>> > > if we had it on the 11/60 before that.
>> > >
>> > > On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
>> > >
>> > >> What was the first machine to run rogue? I understand that it was written
>> > >> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
>> > >> `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
>> > >> at least one place that indicates it first ran on 6th Edition, but that
>> > >> doesn't sound right to me. The first reference I can find in BSD is in 2.79
>> > >> ("rogue.doc"), which also appears to be the first release to ship curses.
>> > >>
>> > >> Anyone have any info? Thanks!
>> > >>
>> > >> - Dan C.
>> > >>
>> > >> --
>> > > Sent from a handheld expect more typos than usual
>> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/3ce4dfb2/attachment.htm>
From rich.salz at gmail.com Fri Jul 2 23:22:13 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Fri, 2 Jul 2021 09:22:13 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <E6590126-A8CA-4BC0-B7F5-D49956BAFBFB@iitbombay.org>
References: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<E6590126-A8CA-4BC0-B7F5-D49956BAFBFB@iitbombay.org>
Message-ID: <CAFH29tq-G1CKjdoC5LngM7joQ=-F0NOhOa2DeygFUG4FoZEP3w@mail.gmail.com>
Ken Arnold posted the original source to
https://sourceforge.net/projects/rogue/ back in 2000.
On Fri, Jul 2, 2021 at 9:12 AM Bakul Shah <bakul at iitbombay.org> wrote:
> Glenn wrote up a brief history where he says it was first distributed with
> 4.2bsd.
>
> https://web.archive.org/web/19980625212119/http://www.wichman.org/roguehistory.html
>
> @ Fortune Systems in 1983/83 we had 3-4 college students working for a
> contract company Santa Cruz Operations(?) doing testing for us. He was one
> of them and later we hired him full time. I didn’t interact with him much
> though and once I quit Fortune I lost track of him. I think initially we
> had only a rogue binary on 4.1 running on VAX780 but I do not recall if he
> brought it to Fortune. Someone later ported it to the Fortune machine. I
> used to play Rogue while waiting for kernel compiles to finish. A few years
> ago I got it on FreeBSD and my muscle memory came back 100%!
>
> On Jul 2, 2021, at 5:16 AM, Dan Cross <crossd at gmail.com> wrote:
>
> п»ї
> On Fri, Jul 2, 2021 at 7:40 AM <arnold at skeeve.com> wrote:
>
>> Is the rogue source extant? I remember many people spending many
>> hours on rogue on the 4.[12] BSD vax at Georgia Tech.
>>
>> ISTR that rogue only came as a binary, there was no source.
>>
>
> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
> sources there are listed as "public domain rogue", but I'm not sure about
> the provenance of that code.
>
> - Dan C.
>
>
> Arnold
>>
>> Dan Cross <crossd at gmail.com> wrote:
>>
>> > Thanks, Clem. I'm curious what other lore is out there: my suspicion is
>> > that rogue never ran on vanilla v6, but it would be great to validate.
>> >
>> > On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
>> >
>> > > I first got it on V7, as I said on our 11/70 for sure but I don’t
>> remember
>> > > if we had it on the 11/60 before that.
>> > >
>> > > On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
>> > >
>> > >> What was the first machine to run rogue? I understand that it was
>> written
>> > >> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
>> > >> `curses` library (Ken Arnold's original, not Mary Ann's rewrite).
>> I've seen
>> > >> at least one place that indicates it first ran on 6th Edition, but
>> that
>> > >> doesn't sound right to me. The first reference I can find in BSD is
>> in 2.79
>> > >> ("rogue.doc"), which also appears to be the first release to ship
>> curses.
>> > >>
>> > >> Anyone have any info? Thanks!
>> > >>
>> > >> - Dan C.
>> > >>
>> > >> --
>> > > Sent from a handheld expect more typos than usual
>> > >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/02f3e1b3/attachment-0001.htm>
From brad at anduin.eldar.org Sat Jul 3 01:24:21 2021
From: brad at anduin.eldar.org (Brad Spencer)
Date: Fri, 02 Jul 2021 11:24:21 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com> (message
from Clem Cole on Fri, 2 Jul 2021 09:07:15 -0400)
Message-ID: <xoneecghh7e.fsf@anduin.eldar.org>
Clem Cole <clemc at ccc.com> writes:
> On Fri, Jul 2, 2021 at 8:15 AM Dan Cross <crossd at gmail.com> wrote:
>
>> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
>> sources there are listed as "public domain rogue", but I'm not sure about
>> the provenance of that code.
>>
> That sounds right, you should ask Ken Arnold offline, I bet he had a better
> idea. He would have made them available to Keith.
> бђ§
I don't know what it was exactly, but in the mid 1980s a version of
rogue existed for OS-9 Level 2 on the 6809 and I ran it on a Radio Shack
Color Computer. By the later part of that decade, I had access to a
PDP11 running 2.something BSD and played rogue there too. The Color
Computer version was either a good clone, or someone had access to the
source code.
This -> http://www.lcurtisboyle.com/nitros9/rogue.html looks like it..
Says 1986 by Epyx
--
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org
From paul.winalski at gmail.com Sat Jul 3 02:04:21 2021
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 2 Jul 2021 12:04:21 -0400
Subject: [TUHS] pointer disambiguation (was Re: Disassemers)
Message-ID: <CABH=_VRmGgyEqMvL-w27M=TYTOk=mvP5AAUktdo69Q_NyWPS5A@mail.gmail.com>
On 7/1/21, scj at yaccman.com <scj at yaccman.com> wrote:
> When PCC came along and started running on 32-bit machines, I started
> thinking about algorithms for optimization. A problem that I had no
> good solution for could be illustrated by a simple piece of code:
>
> x = *p;
>
> y = *q;
>
> q gets changed
>
> *q = z;
>
> The question is, do I need to reload x now because q might have been
> changed to point to the same place as p?
Yes, this is a very well-known problem in scalar optimization in
compiler engineering. It's called pointer disambiguation and is part
of the more general problem of data flow analysis. As you observed,
getting it wrong can lead to very subtle and hard-to-debug correctness
problems. In the worst case, one has to throw out all current data
flow analysis of global and currently active local variables and start
over. In your example, the statement "*q = z" may end up forcing the
compiler to toss out all data flow information on x and z (and maybe p
and q as well). If q could possibly point to x and x is in a
register, the assignment forces x to be reloaded before its next use.
Ambiguous pointers prohibit a lot of important optimizations. This
problem is the source of a lot of bugs in compilers that do aggressive
optimizations.
Fortunately a bit of knowledge of just how "q gets changed" can rescue
the situation. In strongly-typed languages, for example, if x and z
are different data types, we know the assignment of z through q can't
affect x. We also know that the assignment can't affect x if x and z
have disjoint scopes.
The 'restrict' keyword in C pointer declarations was added to help
mitigate this problem.
Some compilers also have a command line option that allows the user to
say, "I solemnly swear that I won't do this sort of thing".
-Paul W.
From athornton at gmail.com Sat Jul 3 02:27:49 2021
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 2 Jul 2021 09:27:49 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <xoneecghh7e.fsf@anduin.eldar.org>
References: <xoneecghh7e.fsf@anduin.eldar.org>
Message-ID: <12E06B2C-E296-4E0E-9EB8-21D1FD9E0647@gmail.com>
>
> This -> http://www.lcurtisboyle.com/nitros9/rogue.html looks like it..
> Says 1986 by Epyx
>
Between https://sourceforge.net/projects/roguelike/ and https://britzl.github.io/roguearchive/ you’ve got a lot to work with.
Adam
From paul.winalski at gmail.com Sat Jul 3 02:56:40 2021
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 2 Jul 2021 12:56:40 -0400
Subject: [TUHS] Disassemblers
In-Reply-To: <0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com>
References: <CAEdTPBdbNcsjg64GV4u9_7scP1p3RQGfJniQ+Defbvjr0_cR9w@mail.gmail.com>
<CAC20D2Ny25FuucygeLRfMfm+gxE8DJPSg+vp0n5OEtC11_Z_fA@mail.gmail.com>
<CAEdTPBdha+dNCqypSKNuQf0X31oH=M=3Te4GLHyv5WDKE04YTQ@mail.gmail.com>
<CAC20D2POxdHJsSvRjSozASUWXQ+YAUaSA+7mAoPx1-JsTYHb1g@mail.gmail.com>
<0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com>
Message-ID: <CABH=_VSNzWW57TuufHnDFsgvCN=WZfr8G9PWDxLz4ddVVnJOcg@mail.gmail.com>
I sent a reply to this message to the TUHS mailing list but gmail may
have rejected it and flagged it as spam.
Please email me privately to let me know if the message made it to the list.
-Paul W..
On 7/1/21, scj at yaccman.com <scj at yaccman.com> wrote:
> I saw this post and it reminded me of a meeting that Dennis and I had
> with Bill Wulf. At one point, Dennis decided to write an optimizer but
> gave up after a week or two because when he had coded the data
> structures he needed he had filled up the PDP-11 memory! It was a very
> strong part of the Unix meme that Unix and C would run on small
> computers since most of the universities couldn't afford bigger ones at
> the time.
>
> When PCC came along and started running on 32-bit machines, I started
> thinking about algorithms for optimization. A problem that I had no
> good solution for could be illustrated by a simple piece of code:
>
> x = *p;
>
> y = *q;
>
> q gets changed
>
> *q = z;
>
> The question is, do I need to reload x now because q might have been
> changed to point to the same place as p? At around this time, Al Aho
> was invited to go to CMU and give a talk, and he invited me to come with
> him. We spent about an hour and a half one-on-one with Bill Wulf -- I
> seem to remember a lot of mutual respect going on. But when I asked him
> about my problem, he really didn't have much to say about it. I finally
> got him to agree that his compiler had a bug. But he said there was a
> flag they could set on the compiler that would turn of optimization and
> if your program had mysterious bugs, you should use the flag.
>
> I recall that Al, always in search of better algorithms, was a bit
> disappointed -- I was a bit more pragmatic about it. On the whole, it
> was a good meeting, and the "Engineering ... Compiler" book was one of
> my favorites when it came out.
>
> Steve
From dot at dotat.at Sat Jul 3 03:17:35 2021
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Jul 2021 18:17:35 +0100
Subject: [TUHS] Dennis Ritchie's couch
In-Reply-To: <C728300B-6E54-4C25-A160-C1392BE37469@iitbombay.org>
References: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
<C728300B-6E54-4C25-A160-C1392BE37469@iitbombay.org>
Message-ID: <424dde98-7a42-57e6-e13a-83c3e6ccc020@dotat.at>
Bakul Shah <bakul at iitbombay.org> wrote:
> > George Michaelson <ggm at algebras.org> wrote:
> >
> > a table.. hmm. so like.. we could write .. engines to "read" the table
> > and do things in some kind of (maybe.. finite) way?
> >
> > I know, lets write a DSL to MAKE THE TABLE...
> >
> > Is all software "wheel of life" ?
>
> It would be just an operator precedence table and two functions. One to
> parse a factor and one for binary expressions. The table might be something
> like an array of {singles, doubles, associativity}, where the Nth entry
> has precedence N. The binary expr parser uses the table to essentially
> group sub expressions based on precedence and associativity. This is an old
> idea. I think at least 4-5 decades old.
Yes, it's a fairly straightforward to write an operator precedence parser
using a pushdown automaton. Knuth wrote about it in 1962 :-) [page 8]
https://archive.org/details/bitsavers_computersA_13990695
I crufted together a #if evaluator for unifdef nearly 20 years ago, but
it's, um, rather messy. (I was hacking on Dave Yost's code from the 1980s)
http://dotat.at/cgi/git/unifdef.git/blob/HEAD:/unifdef.c#l950
More recently I learned how to write a Pratt parser (1973), which is just
a particular style of operator precedence parser, but when it's done
properly it can be really neat.
https://dl.acm.org/doi/10.1145/512927.512931
The driver loop is tiny, if you set up the table mapping tokens to actions
in the right way, so that the state transition functions handle errors as
well as happy-path evaluation. (Blame Pratt for the field names!)
static Value
eval(Parser *p, int rbp) {
Value v = token[p->tok].nud(p);
while(token[p->tok].lbp > rbp)
v = token[p->tok].led(p, v);
return(v);
}
Vaughan Pratt also designed the pretty neat Sun logo.
Tony.
--
f.anthony.n.finch <dot at dotat.at> https://dotat.at/
Channel Islands: Variable or northeasterly 1 to 3, becoming west to
southwest 2 to 4 late evening, backing south to southeast soon after dawn,
veering southwest to west 3 to 5 by noon, locally variable 1 to 3 in the
far south of the area. Smooth or slight, with a low swell developing
later. Mist and fog patches clearing early by early afternoon showers at
first and again later rain and drizzle for a time, overnight and in the
morning. Moderate to good, occasionally poor locally very poor.
From paul.winalski at gmail.com Sat Jul 3 03:45:14 2021
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 2 Jul 2021 13:45:14 -0400
Subject: [TUHS] Disassemblers
In-Reply-To: <CABH=_VSNzWW57TuufHnDFsgvCN=WZfr8G9PWDxLz4ddVVnJOcg@mail.gmail.com>
References: <CAEdTPBdbNcsjg64GV4u9_7scP1p3RQGfJniQ+Defbvjr0_cR9w@mail.gmail.com>
<CAC20D2Ny25FuucygeLRfMfm+gxE8DJPSg+vp0n5OEtC11_Z_fA@mail.gmail.com>
<CAEdTPBdha+dNCqypSKNuQf0X31oH=M=3Te4GLHyv5WDKE04YTQ@mail.gmail.com>
<CAC20D2POxdHJsSvRjSozASUWXQ+YAUaSA+7mAoPx1-JsTYHb1g@mail.gmail.com>
<0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com>
<CABH=_VSNzWW57TuufHnDFsgvCN=WZfr8G9PWDxLz4ddVVnJOcg@mail.gmail.com>
Message-ID: <CABH=_VSRC8VGYyzDF8pfY+iNCM-pxdyATn-K33=83+-qRgv4=Q@mail.gmail.com>
Apparently the email did make it to the TUHS list even though gmail
seemed to have bounced it as spam. Go figure.
Thanks to all who responded.
-Paul W.
On 7/2/21, Paul Winalski <paul.winalski at gmail.com> wrote:
> I sent a reply to this message to the TUHS mailing list but gmail may
> have rejected it and flagged it as spam.
>
> Please email me privately to let me know if the message made it to the
> list.
>
> -Paul W..
From jpl.jpl at gmail.com Sat Jul 3 04:07:27 2021
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Fri, 2 Jul 2021 14:07:27 -0400
Subject: [TUHS] Disassemblers
In-Reply-To: <CABH=_VSNzWW57TuufHnDFsgvCN=WZfr8G9PWDxLz4ddVVnJOcg@mail.gmail.com>
References: <CAEdTPBdbNcsjg64GV4u9_7scP1p3RQGfJniQ+Defbvjr0_cR9w@mail.gmail.com>
<CAC20D2Ny25FuucygeLRfMfm+gxE8DJPSg+vp0n5OEtC11_Z_fA@mail.gmail.com>
<CAEdTPBdha+dNCqypSKNuQf0X31oH=M=3Te4GLHyv5WDKE04YTQ@mail.gmail.com>
<CAC20D2POxdHJsSvRjSozASUWXQ+YAUaSA+7mAoPx1-JsTYHb1g@mail.gmail.com>
<0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com>
<CABH=_VSNzWW57TuufHnDFsgvCN=WZfr8G9PWDxLz4ddVVnJOcg@mail.gmail.com>
Message-ID: <CAC0cEp97xCsK8XKd1pZNp8FU0J2w4eZSWvn9w0rO32mMLfvgtA@mail.gmail.com>
On a related (optimization) theme,
https://research.swtch.com/hwmm
On Fri, Jul 2, 2021 at 12:58 PM Paul Winalski <paul.winalski at gmail.com>
wrote:
> I sent a reply to this message to the TUHS mailing list but gmail may
> have rejected it and flagged it as spam.
>
> Please email me privately to let me know if the message made it to the
> list.
>
> -Paul W..
>
> On 7/1/21, scj at yaccman.com <scj at yaccman.com> wrote:
> > I saw this post and it reminded me of a meeting that Dennis and I had
> > with Bill Wulf. At one point, Dennis decided to write an optimizer but
> > gave up after a week or two because when he had coded the data
> > structures he needed he had filled up the PDP-11 memory! It was a very
> > strong part of the Unix meme that Unix and C would run on small
> > computers since most of the universities couldn't afford bigger ones at
> > the time.
> >
> > When PCC came along and started running on 32-bit machines, I started
> > thinking about algorithms for optimization. A problem that I had no
> > good solution for could be illustrated by a simple piece of code:
> >
> > x = *p;
> >
> > y = *q;
> >
> > q gets changed
> >
> > *q = z;
> >
> > The question is, do I need to reload x now because q might have been
> > changed to point to the same place as p? At around this time, Al Aho
> > was invited to go to CMU and give a talk, and he invited me to come with
> > him. We spent about an hour and a half one-on-one with Bill Wulf -- I
> > seem to remember a lot of mutual respect going on. But when I asked him
> > about my problem, he really didn't have much to say about it. I finally
> > got him to agree that his compiler had a bug. But he said there was a
> > flag they could set on the compiler that would turn of optimization and
> > if your program had mysterious bugs, you should use the flag.
> >
> > I recall that Al, always in search of better algorithms, was a bit
> > disappointed -- I was a bit more pragmatic about it. On the whole, it
> > was a good meeting, and the "Engineering ... Compiler" book was one of
> > my favorites when it came out.
> >
> > Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/393389a7/attachment.htm>
From crossd at gmail.com Sat Jul 3 07:09:42 2021
From: crossd at gmail.com (Dan Cross)
Date: Fri, 2 Jul 2021 17:09:42 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
Message-ID: <CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
On Fri, Jul 2, 2021 at 9:07 AM Clem Cole <clemc at ccc.com> wrote:
> On Fri, Jul 2, 2021 at 8:15 AM Dan Cross <crossd at gmail.com> wrote:
>
>> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
>> sources there are listed as "public domain rogue", but I'm not sure about
>> the provenance of that code.
>>
> That sounds right, you should ask Ken Arnold offline, I bet he had a
> better idea. He would have made them available to Keith.
>
Great idea. I reached out on linked in, but don't have an email address for
Ken. Anyone have his contact information?
I'm curious if e.g. Mary Ann has any thoughts here, since she took over
maintaining curses at some point and might have gotten some of the inside
story?
Thanks for the responses so far, all.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/c0c5a9f9/attachment.htm>
From beebe at math.utah.edu Sat Jul 3 07:24:20 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 2 Jul 2021 15:24:20 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
Message-ID: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From lm at mcvoy.com Sat Jul 3 07:36:48 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 2 Jul 2021 14:36:48 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
Message-ID: <20210702213648.GW817@mcvoy.com>
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 at math.utah.edu -
> - 155 S 1400 E RM 233 beebe at acm.org beebe at 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
From henry.r.bent at gmail.com Sat Jul 3 07:56:24 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Fri, 2 Jul 2021 17:56:24 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210702213648.GW817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
Message-ID: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
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 at 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 at math.utah.edu -
> > - 155 S 1400 E RM 233 beebe at acm.org
> beebe at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/e7d2730a/attachment.htm>
From chet.ramey at case.edu Sat Jul 3 08:27:45 2021
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 2 Jul 2021 18:27:45 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
Message-ID: <231143c0-3168-ee1c-37e2-5c93238432d2@case.edu>
On 7/2/21 5:24 PM, 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
Perhaps, though they do say
"The shell is a useful abstraction deserving of our attention despite its
imperfections (Section 2)."
and
"The Unix shell hits a sweet spot between succinctness, expressive power,
and performance."
I participated in the accompanying panel. Everyone seems to hate the
shell's quoting rules and word splitting, and those two things alone are
sufficient to give the shell a bad rap, yet one thing that became clear
is that people are trying to use the shell (or not) without understanding
the underlying Unix abstractions that we take for granted (such as the file
system). And what's worse: they don't want to and nobody is teaching them.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/
From usotsuki at buric.co Sat Jul 3 09:09:37 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 2 Jul 2021 19:09:37 -0400 (EDT)
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
Message-ID: <alpine.DEB.2.21.2107021906540.15013@sd-119843.dedibox.fr>
On Fri, 2 Jul 2021, Nelson H. F. Beebe wrote:
> 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.
I still use the descendent Korn shell most of the time (often in the form
of bash) on modern systems, and I don't just mean those that are
Unix-like. I've found that a lot of times I can build a quick tool using
bash or ksh93, or use a bash one-liner, and do something that's impossible
with command.com on DOS or cmd.exe on NT and OS/2.
-uso.
From usotsuki at buric.co Sat Jul 3 09:12:53 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 2 Jul 2021 19:12:53 -0400 (EDT)
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
On Fri, 2 Jul 2021, Henry Bent wrote:
> On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm at 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.
>
> 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
>
The Linux distro I use does use systemd but I can ignore it and go on with
my life as if it were still running sysvinit. So it's not that big a deal
to me.
I'd prefer that they kept sysvinit, but eh. What's that saying? "Those
who fail to understand Unix are condemned to recreate it, poorly" ?
-uso.
From steffen at sdaoden.eu Sat Jul 3 09:49:41 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 03 Jul 2021 01:49:41 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
Message-ID: <20210702234941.MjMt0%steffen@sdaoden.eu>
Steve Nickolas wrote in
<alpine.DEB.2.21.2107021910240.15013 at sd-119843.dedibox.fr>:
|On Fri, 2 Jul 2021, Henry Bent wrote:
|> On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm at 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.
|>
|> 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
|>
|
|The Linux distro I use does use systemd but I can ignore it and go on with
|my life as if it were still running sysvinit. So it's not that big a deal
|to me.
|
|I'd prefer that they kept sysvinit, but eh. What's that saying? "Those
|who fail to understand Unix are condemned to recreate it, poorly" ?
Well iwd(8) for example that i happen to have installed as
a replacement for wpa_supplicant just today (because
.. i installed my beloved sysvinit/BSD rc based CRUX-Linux on
a new spare laptop, a 18 month old but totally new IdeaPad S145,
and since i do not have initrd kernels but compile an all-builtin
one i use a generic kernel in order to lsmod(8) in order to be
able to create a custom kernel with a modified "make localyesmod"
that Linux supports, here ArchLinux 2020.12, because AlpineLinux
did not do it, somehow, and whereas i hate that ArchLinux now that
all old developers fled does not even ship install instructions it
actually does come with iwd/iwctl, and it happened that iwctl
looked so much better to me than wpa_cli of wpa_supplicant, that
i took the time and replaced there here, iwctl has at least one
bug though, iwd ditto, and i must say that whereas iwd is much
smaller is has a larger memory footprint than wpa_supplicant, and
.. whatever), and note that iwd neither supports a normal syslog
nor command line parameters to configure paths etc., the latter
have to come in via environment if they shall, and the manual says
these are "normally provided by systemd" (which is not true .. for
me). And no syslog at all! No PID file handling. And bugs even
though Intel.com paid for it. I mean "get up, stand up", they do
a thousand things and not seldom i wonder.
@Tony Finch: wonderful reading of the first two pages, thanks for
this link! It seems Knuth always had "a touch" for writing good,
and for good writing.
P.S.: not that do-one-thing's like sysklogd are bug free, for
example the sysklogd CRUX now uses/offers introduced a new bug
that causes /var/log/kernel to print monotonic clock times or
what, mind you, just now it is "Jun 30 13:13:16" (for "kent").
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From andreww591 at gmail.com Sat Jul 3 10:09:27 2021
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Fri, 2 Jul 2021 18:09:27 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210702213648.GW817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
Message-ID: <CAD-qYGrFUgkipT+1OKZbpvO1G5gO51sJUXJctn404USQEWrzjA@mail.gmail.com>
On 02/07/2021, Larry McVoy <lm at 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.
>
>
I'm definitely not a fan of systemd, but I think legacy init systems
leave a lot to be desired as well. UX/RT, the OS I'm writing, will
have an init system that uses declarative unit files for daemons and
manages them statefully, but unlike systemd will be designed to be
highly extensible.
Basically all policy, including startup and shutdown, will be in
scripts. Startup and shutdown will mostly be implemented with one
script per phase (like on some older SysV and Linux systems). It will
also be possible to add support for new options to unit files by
adding hook scripts.
In addition, instead of having a single daemon managing all unit
types, there will be separate delegated restarters for all unit types
other than one-shots and unconditional daemons (it will be kind of
like SMF minus the databases and XML).
I'm also probably going to write my own shell at some point. Most
likely it will be Bourne-like with some object-oriented features,
including support for piping objects (unlike PowerShell this will work
with external commands and will be implemented by serializing objects
to text-based formats using hook functions). All UI-related features
like history, editing, and completion will be implemented in a
separate listener process that functions as a pseudo-terminal driver.
From crossd at gmail.com Sat Jul 3 11:10:06 2021
From: crossd at gmail.com (Dan Cross)
Date: Fri, 2 Jul 2021 21:10:06 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAFH29tq-G1CKjdoC5LngM7joQ=-F0NOhOa2DeygFUG4FoZEP3w@mail.gmail.com>
References: <CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<E6590126-A8CA-4BC0-B7F5-D49956BAFBFB@iitbombay.org>
<CAFH29tq-G1CKjdoC5LngM7joQ=-F0NOhOa2DeygFUG4FoZEP3w@mail.gmail.com>
Message-ID: <CAEoi9W6+fonRC1+KRdBEKz-uToSUzUDd155-Lve2zdz6mZVAEQ@mail.gmail.com>
Ah thanks, very cool. Btw, Ken Arnold, Michael Toy, and Glenn Wichman were
all on a panel discussing rogue and Ken mentioned that source listing. Some
folks might find it interesting: https://www.youtube.com/watch?v=IaB7iQhts_c
Thanks!
- Dan C.
On Fri, Jul 2, 2021 at 9:22 AM Richard Salz <rich.salz at gmail.com> wrote:
> Ken Arnold posted the original source to
> https://sourceforge.net/projects/rogue/ back in 2000.
>
> On Fri, Jul 2, 2021 at 9:12 AM Bakul Shah <bakul at iitbombay.org> wrote:
>
>> Glenn wrote up a brief history where he says it was first distributed
>> with 4.2bsd.
>>
>> https://web.archive.org/web/19980625212119/http://www.wichman.org/roguehistory.html
>>
>> @ Fortune Systems in 1983/83 we had 3-4 college students working for a
>> contract company Santa Cruz Operations(?) doing testing for us. He was one
>> of them and later we hired him full time. I didn’t interact with him much
>> though and once I quit Fortune I lost track of him. I think initially we
>> had only a rogue binary on 4.1 running on VAX780 but I do not recall if he
>> brought it to Fortune. Someone later ported it to the Fortune machine. I
>> used to play Rogue while waiting for kernel compiles to finish. A few years
>> ago I got it on FreeBSD and my muscle memory came back 100%!
>>
>> On Jul 2, 2021, at 5:16 AM, Dan Cross <crossd at gmail.com> wrote:
>>
>> п»ї
>> On Fri, Jul 2, 2021 at 7:40 AM <arnold at skeeve.com> wrote:
>>
>>> Is the rogue source extant? I remember many people spending many
>>> hours on rogue on the 4.[12] BSD vax at Georgia Tech.
>>>
>>> ISTR that rogue only came as a binary, there was no source.
>>>
>>
>> It is; it looks like it was first distributed with 4.3BSD-Tahoe. The
>> sources there are listed as "public domain rogue", but I'm not sure about
>> the provenance of that code.
>>
>> - Dan C.
>>
>>
>> Arnold
>>>
>>> Dan Cross <crossd at gmail.com> wrote:
>>>
>>> > Thanks, Clem. I'm curious what other lore is out there: my suspicion is
>>> > that rogue never ran on vanilla v6, but it would be great to validate.
>>> >
>>> > On Thu, Jul 1, 2021 at 10:51 PM Clem Cole <clemc at ccc.com> wrote:
>>> >
>>> > > I first got it on V7, as I said on our 11/70 for sure but I don’t
>>> remember
>>> > > if we had it on the 11/60 before that.
>>> > >
>>> > > On Thu, Jul 1, 2021 at 10:07 PM Dan Cross <crossd at gmail.com> wrote:
>>> > >
>>> > >> What was the first machine to run rogue? I understand that it was
>>> written
>>> > >> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using
>>> the
>>> > >> `curses` library (Ken Arnold's original, not Mary Ann's rewrite).
>>> I've seen
>>> > >> at least one place that indicates it first ran on 6th Edition, but
>>> that
>>> > >> doesn't sound right to me. The first reference I can find in BSD is
>>> in 2.79
>>> > >> ("rogue.doc"), which also appears to be the first release to ship
>>> curses.
>>> > >>
>>> > >> Anyone have any info? Thanks!
>>> > >>
>>> > >> - Dan C.
>>> > >>
>>> > >> --
>>> > > Sent from a handheld expect more typos than usual
>>> > >
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/4dfe4a40/attachment-0001.htm>
From fjarlq at gmail.com Sat Jul 3 12:21:07 2021
From: fjarlq at gmail.com (Matt Day)
Date: Fri, 2 Jul 2021 20:21:07 -0600
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
Message-ID: <CAHrGxA2bB31JctWvXxN_46-Y+zo4JcuYXpGZQXd3aHZNB6Y5ng@mail.gmail.com>
Quoting from David Craddock's book, Dungeon Hacks (2015), pages 34-35:
> By the time Toy and Wichman started at UC Santa Cruz, BSD UNIX had entered
> widespread usage across UC campuses and was branching out to other schools.
> Each new version of BSD, released on cassette tape, included handy programs
> written by Joy and other hackers. One program was curses, written by Ken
> Arnold. Arnold had written curses according to the UNIX creed: a simple
> tool fashioned for a specific purpose. Wielding curses like a paintbrush,
> users could place text such as letters, numbers, and symbols at any
> location on the screen.
The moment he used curses, Toy saw its potential. In 1980, he went to
> Wichman and suggested they use curses to create a graphical adventure game
> with a twist. Unlike Colossal Cave Adventure and its derivatives, their
> game would construct brand new environments and challenges every time. An
> avid Dungeons & Dragons player, he invented a fantasy-themed setting and
> premise. Players would assume the identity of an adventurer who entered the
> Dungeons of Doom, a series of levels filled with monsters and treasure.
Wichman loved the idea and dubbed the game Rogue. "I think the name just
> came to me. Names needed to be short because you invoked a program by
> typing its name in a command line. I liked the idea of a rogue. We were
> coming from a Dungeons & Dragons background, but we were creating a
> single-player game. You weren't going down into the dungeon with a party.
> The idea was that this is a person going off on his or her own. It captured
> the theme very succinctly."
Apropos of UNIX, Toy chose to write Rogue in the C language. C produced
> fast code, while BASIC was slower and meant for smaller programs. Wichman,
> still a few steps behind Toy in programming prowess, learned C by watching
> Toy program their game. "The early alpha versions of Rogue were probably
> all my code, but Glenn [Wichman] made lots of contributions in terms of
> design," Toy recalled. "I think it's quite fair to say that the game was a
> pretty straight collaboration between Glenn [Wichman], Ken [Arnold], and me
> by the time it was done. I feel pretty good about that."
Toy and Wichman realized they wouldn't be able to stay at school during all
> hours to write their game. Fortunately, they didn't need to. As employees
> of the computer science division, they had special lab privileges. Setting
> up an ADM-3a terminal in their apartment, they could dial into the VAX
> 11/780 shunted off in a basement somewhere at UC Santa Cruz. The connection
> was established through their 300-baud modem -- a device that would take
> several minutes to transmit the text on an average-length Wikipedia page
> today -- enabling them to write the vast majority of Rogue from the comfort
> of their apartment.
Craddock's notes explain that the quotes of Michael Toy and Glenn Wichman
"come from interviews conducted via phone, Skype, and email over 2012-2014."
I think you must be right about the first machine being something running
BSD UNIX.
Matt
On Thu, Jul 1, 2021 at 8:07 PM Dan Cross <crossd at gmail.com> wrote:
> What was the first machine to run rogue? I understand that it was written
> by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the
> `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen
> at least one place that indicates it first ran on 6th Edition, but that
> doesn't sound right to me. The first reference I can find in BSD is in 2.79
> ("rogue.doc"), which also appears to be the first release to ship curses.
>
> Anyone have any info? Thanks!
>
> - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/66fb7d4c/attachment.htm>
From robpike at gmail.com Fri Jul 2 13:30:17 2021
From: robpike at gmail.com (Rob Pike)
Date: Fri, 2 Jul 2021 13:30:17 +1000
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
References: <CMM.0.95.0.1621987920.beebe@gamma.math.utah.edu>
<CAKzdPgzJsQKMx5BB3sybzAd2HRUnd6L0K-akVepL+538_UOC2w@mail.gmail.com>
<20210526030341.GD27558@mcvoy.com>
<2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
<CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
<e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
Message-ID: <CAKzdPgw6zkXg9tB8uoPOZBv2C5nV8=N4kuW8-tHCUoby=9ki+Q@mail.gmail.com>
To show you what I mean, here is a parser I wrote recently for a simple Go
expression evaluator, in Go. It has all Go's precedence levels and
operators. The one odd detail is that >= etc. can be combined, as in 1 >= 2
> 3, but that doesn't matter in the context of this program and is easily
avoided with a few more lines in cmpList.
I'm using a screen grab because GMail refuses to leave my indentation
alone. I left factor off. It's got all the usual details but it's the leaf
of the grammar and of no interest here.
Note that this could easily have been made a table instead of a bunch of
one-line functions.
Parsers are easy to write. It took us a generation (or more) to understand
that, but it's remarkable nonetheless. The first big step might have been
realizing that recursion was a good idea, even if you weren't writing LISP,
if the data structure is itself recursive.
-rob
[image: image.png]
On Fri, Jul 2, 2021 at 12:13 PM <scj at yaccman.com> wrote:
> I found Dennis's compiler to be a thing of beauty when compiling
> statements, but hell on wheels when doing expressions. One of the
> motivations for writing Yacc was that I wanted to add the exclusive or into
> the expression syntax and we had agreed on the character (^) and the
> precedence. Practically the whole expression grammar needed to be
> rewritten, and small typos created un-debuggable chaos. The state of the
> art at the time was to write multi-layered grammars for each precedence
> level. A paper was published on how to shrink the resulting parsing tables
> by eliminating redundant states. I realized that the same results could
> be obtained by writing an ambiguous expression grammar and using a
> precedence table to resolve the ambiguities. The initial response in the
> academic community to programming with ambiguous grammars was somewhere
> between skeptical and horrified -- as if I had shown porn to a Victorian.
> So Al and I worked out a proof that we would get the same optimized parser
> in a much more intuitive way.
>
> I do agree with Rob that some of the languages that Yacc gave birth to
> should never have been born. Remember, though, that the dominant language
> at the time was FORTRAN, and it had all sorts of strange implementation
> issues in their hand-written compilers. Things like subscript indices had
> to be single variables in some places, and in others could have a constant
> added to the index. One of Yacc's best features was that it made
> consistency of usage the path of least resistance when designing the
> language, and the grammar was often easier to understand than the
> programming manual. At Bell Labs, Barbara Ryder wrote a program that would
> read FORTRAN and detect things that would not work on one or more of the
> six major FORTRAN's at the time. It was an inspiration for me, later, do
> the same thing with Lint.
>
> I do suggest that having languages like C++ that have bloated up to over
> 1000 pages in the programmer reference doesn't feel like a real advance,
> especially since the real language problems of today are how to program
> very large numbers of processor-like objects on a single chip. We need new
> ways to think, and I doubt that we'll get there by making C++ require a
> 2000-page manual.
> ---
>
>
>
> On 2021-05-25 23:52, Rob Pike wrote:
>
> I enjoy writing recursive descent parsers, and I enjoy the grammars that
> result from such parsers when cleanly done.
>
> I do agree though that if you grammar is being invented as you go, yacc
> can be a boon. But in a sense, that's also it's biggest failing: it makes
> it too easy to write bad grammars.
>
> -rob
>
>
> On Wed, May 26, 2021 at 4:22 PM Bakul Shah <bakul at iitbombay.org> wrote:
>
> Many existing programming languages do have a simple enough
> syntax to make it easy to write a recursive descent parser for them
> but not alll.
>
> Handwritten recursive descent parsers are often LL(1) with may be
> a separate operator-precedence parsing for expressions.
>
> If you are defining a new language syntax you can make sure parsing
> is easy but not all languages are LL(1) (which is a subset of LALR(1),
> which is a subset of LR(1), which is a subset of GLR). Handwritten
> parsers for these more general grammars are bound to get more
> complicated.
>
> Even *we* understand parsing, writing a parser for some existing
> languages which grew "organically" can become tedious, or
> complicated or adhoc. Often such languages have no well specified
> grammar (the code is the specification!). A yacc grammar would help.
>
> Often one writes a yacc grammar while a new language & its syntax
> is evolving. Changing a yacc file is more localized & easier than fixing
> up a handwritten parser. Even Go has such a grammar initially.
>
> -- Bakul
>
> > On May 25, 2021, at 8:03 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > You do, I don't. I'm not alone in my lack of understanding.
> >
> > I think that all the things that yacc solved, Steve gets some kudos.
> > I've used it a bunch and I did not need to be as smart as you or
> > Steve to get the job done.
> >
> > You getting past that is cool but it doesn't make his work less.
> >
> > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote:
> >> And today, we understand parsing so well we don't need yacc.
> >>
> >> -rob
> >>
> >>
> >> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe <
> beebe at math.utah.edu>
> >> wrote:
> >>
> >>> The last article of the latest issue of the Communications of the ACM
> >>> that appeared electronically earlier today is a brief interview with
> >>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman.
> >>>
> >>> The article is
> >>>
> >>> Last byte: Shaping the foundations of programming languages
> >>> https://doi.org/10.1145/3460442
> >>> Comm. ACM 64(6), 120, 119, June 2021.
> >>>
> >>> and it includes a picture of the two winners sitting on Dennis
> >>> Ritchie's couch.
> >>>
> >>> I liked this snippet from Jeff Ullman, praising fellow list member
> >>> Steve Johnson's landmark program, yacc:
> >>>
> >>>>> ...
> >>>>> At the time of the first Fortran compiler, it took several
> >>>>> person-years to write a parser. By the time yacc came around,
> >>>>> you could do it in an afternoon.
> >>>>> ...
> >>>
> >>>
> >>>
> -------------------------------------------------------------------------------
> >>> - 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 at math.utah.edu -
> >>> - 155 S 1400 E RM 233 beebe at acm.org
> >>> beebe at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/7254ce43/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 246447 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/7254ce43/attachment-0001.png>
From robpike at gmail.com Fri Jul 2 13:34:27 2021
From: robpike at gmail.com (Rob Pike)
Date: Fri, 2 Jul 2021 13:34:27 +1000
Subject: [TUHS] [tuhs] Dennis Ritchie's couch
In-Reply-To: <CAKzdPgw6zkXg9tB8uoPOZBv2C5nV8=N4kuW8-tHCUoby=9ki+Q@mail.gmail.com>
References: <CMM.0.95.0.1621987920.beebe@gamma.math.utah.edu>
<CAKzdPgzJsQKMx5BB3sybzAd2HRUnd6L0K-akVepL+538_UOC2w@mail.gmail.com>
<20210526030341.GD27558@mcvoy.com>
<2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
<CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com>
<e8ce832d5d6ccdc9e4ccc40f7a1d7aec@yaccman.com>
<CAKzdPgw6zkXg9tB8uoPOZBv2C5nV8=N4kuW8-tHCUoby=9ki+Q@mail.gmail.com>
Message-ID: <CAKzdPgxGOZLLQzzPKe3kyAq1soAYPHwyeVP2iePiE8zMSk=f7g@mail.gmail.com>
<resending with the program as an attachment, as 100K is considered big
here? moderator, you can kill the prior message>
To show you what I mean, here is a parser I wrote recently for a simple Go
expression evaluator, in Go. It has all Go's precedence levels and
operators. The one odd detail is that >= etc. can be combined, as in 1 >= 2
> 3, but that doesn't matter in the context of this program and is easily
avoided with a few more lines in cmpList.
I'm using a screen grab because GMail refuses to leave my indentation
alone. I left factor off. It's got all the usual details but it's the leaf
of the grammar and of no interest here.
Note that this could easily have been made a table instead of a bunch of
one-line functions.
Parsers are easy to write. It took us a generation (or more) to understand
that, but it's remarkable nonetheless. The first big step might have been
realizing that recursion was a good idea, even if you weren't writing LISP,
if the data structure is itself recursive.
-rob
On Fri, Jul 2, 2021 at 1:30 PM Rob Pike <robpike at gmail.com> wrote:
> To show you what I mean, here is a parser I wrote recently for a simple Go
> expression evaluator, in Go. It has all Go's precedence levels and
> operators. The one odd detail is that >= etc. can be combined, as in 1 >= 2
> > 3, but that doesn't matter in the context of this program and is easily
> avoided with a few more lines in cmpList.
>
> I'm using a screen grab because GMail refuses to leave my indentation
> alone. I left factor off. It's got all the usual details but it's the leaf
> of the grammar and of no interest here.
>
> Note that this could easily have been made a table instead of a bunch of
> one-line functions.
>
> Parsers are easy to write. It took us a generation (or more) to understand
> that, but it's remarkable nonetheless. The first big step might have been
> realizing that recursion was a good idea, even if you weren't writing LISP,
> if the data structure is itself recursive.
>
> -rob
>
>
> [image: image.png]
>
>
> On Fri, Jul 2, 2021 at 12:13 PM <scj at yaccman.com> wrote:
>
>> I found Dennis's compiler to be a thing of beauty when compiling
>> statements, but hell on wheels when doing expressions. One of the
>> motivations for writing Yacc was that I wanted to add the exclusive or into
>> the expression syntax and we had agreed on the character (^) and the
>> precedence. Practically the whole expression grammar needed to be
>> rewritten, and small typos created un-debuggable chaos. The state of the
>> art at the time was to write multi-layered grammars for each precedence
>> level. A paper was published on how to shrink the resulting parsing tables
>> by eliminating redundant states. I realized that the same results could
>> be obtained by writing an ambiguous expression grammar and using a
>> precedence table to resolve the ambiguities. The initial response in the
>> academic community to programming with ambiguous grammars was somewhere
>> between skeptical and horrified -- as if I had shown porn to a Victorian.
>> So Al and I worked out a proof that we would get the same optimized parser
>> in a much more intuitive way.
>>
>> I do agree with Rob that some of the languages that Yacc gave birth to
>> should never have been born. Remember, though, that the dominant language
>> at the time was FORTRAN, and it had all sorts of strange implementation
>> issues in their hand-written compilers. Things like subscript indices had
>> to be single variables in some places, and in others could have a constant
>> added to the index. One of Yacc's best features was that it made
>> consistency of usage the path of least resistance when designing the
>> language, and the grammar was often easier to understand than the
>> programming manual. At Bell Labs, Barbara Ryder wrote a program that would
>> read FORTRAN and detect things that would not work on one or more of the
>> six major FORTRAN's at the time. It was an inspiration for me, later, do
>> the same thing with Lint.
>>
>> I do suggest that having languages like C++ that have bloated up to over
>> 1000 pages in the programmer reference doesn't feel like a real advance,
>> especially since the real language problems of today are how to program
>> very large numbers of processor-like objects on a single chip. We need new
>> ways to think, and I doubt that we'll get there by making C++ require a
>> 2000-page manual.
>> ---
>>
>>
>>
>> On 2021-05-25 23:52, Rob Pike wrote:
>>
>> I enjoy writing recursive descent parsers, and I enjoy the grammars that
>> result from such parsers when cleanly done.
>>
>> I do agree though that if you grammar is being invented as you go, yacc
>> can be a boon. But in a sense, that's also it's biggest failing: it makes
>> it too easy to write bad grammars.
>>
>> -rob
>>
>>
>> On Wed, May 26, 2021 at 4:22 PM Bakul Shah <bakul at iitbombay.org> wrote:
>>
>> Many existing programming languages do have a simple enough
>> syntax to make it easy to write a recursive descent parser for them
>> but not alll.
>>
>> Handwritten recursive descent parsers are often LL(1) with may be
>> a separate operator-precedence parsing for expressions.
>>
>> If you are defining a new language syntax you can make sure parsing
>> is easy but not all languages are LL(1) (which is a subset of LALR(1),
>> which is a subset of LR(1), which is a subset of GLR). Handwritten
>> parsers for these more general grammars are bound to get more
>> complicated.
>>
>> Even *we* understand parsing, writing a parser for some existing
>> languages which grew "organically" can become tedious, or
>> complicated or adhoc. Often such languages have no well specified
>> grammar (the code is the specification!). A yacc grammar would help.
>>
>> Often one writes a yacc grammar while a new language & its syntax
>> is evolving. Changing a yacc file is more localized & easier than fixing
>> up a handwritten parser. Even Go has such a grammar initially.
>>
>> -- Bakul
>>
>> > On May 25, 2021, at 8:03 PM, Larry McVoy <lm at mcvoy.com> wrote:
>> >
>> > You do, I don't. I'm not alone in my lack of understanding.
>> >
>> > I think that all the things that yacc solved, Steve gets some kudos.
>> > I've used it a bunch and I did not need to be as smart as you or
>> > Steve to get the job done.
>> >
>> > You getting past that is cool but it doesn't make his work less.
>> >
>> > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote:
>> >> And today, we understand parsing so well we don't need yacc.
>> >>
>> >> -rob
>> >>
>> >>
>> >> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe <
>> beebe at math.utah.edu>
>> >> wrote:
>> >>
>> >>> The last article of the latest issue of the Communications of the ACM
>> >>> that appeared electronically earlier today is a brief interview with
>> >>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman.
>> >>>
>> >>> The article is
>> >>>
>> >>> Last byte: Shaping the foundations of programming languages
>> >>> https://doi.org/10.1145/3460442
>> >>> Comm. ACM 64(6), 120, 119, June 2021.
>> >>>
>> >>> and it includes a picture of the two winners sitting on Dennis
>> >>> Ritchie's couch.
>> >>>
>> >>> I liked this snippet from Jeff Ullman, praising fellow list member
>> >>> Steve Johnson's landmark program, yacc:
>> >>>
>> >>>>> ...
>> >>>>> At the time of the first Fortran compiler, it took several
>> >>>>> person-years to write a parser. By the time yacc came around,
>> >>>>> you could do it in an afternoon.
>> >>>>> ...
>> >>>
>> >>>
>> >>>
>> -------------------------------------------------------------------------------
>> >>> - 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 at math.utah.edu -
>> >>> - 155 S 1400 E RM 233 beebe at acm.org
>> >>> beebe at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/72d4fcd9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 246447 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210702/72d4fcd9/attachment-0001.png>
-------------- next part --------------
// parse implements a production in the expression parse hierarchy. Singles and
// doubles are strings holding the operators that are available at at this precedence
// level, while nextLevel implements the next higher precendence level.
func (p *parser) parse(singles, doubles string, nextLevel func(*parser) *Expr) *Expr {
e := nextLevel(p)
for {
if p.peek(true) == eof {
return e
}
op := p.op(singles, doubles)
if op == "" {
return e
}
e = &Expr{
op: op,
left: e,
right: nextLevel(p),
}
}
}
// orlist = andList | andList '||' orList.
func orList(p *parser) *Expr {
return p.parse("", "||", andList)
}
// andlist = cmpList | cmpList '&&' andList.
func andList(p *parser) *Expr {
return p.parse("", "&&", cmpList)
}
// cmpList = expr | expr ('>' | '<' | '==' | '!=' | '>=' | '<=') expr.
func cmpList(p *parser) *Expr {
return p.parse("+-|^!><", "==!=>=<=", expr)
}
// expr = term | term ('+' | '-' | '|' | '^') term.
func expr(p *parser) *Expr {
return p.parse("+-|^!", "", term)
}
// term = factor | factor ('*' | '/' | '%' | '>>' | '<<' | '&' | '&^') factor
func term(p *parser) *Expr {
return p.parse("*/%&", ">><<&^", factor)
}
// factor = constant | identifier | '+' factor | '-' factor | '^' factor | '!' factor | '(' orList ')'
func factor(p *parser) *Expr {
From thomas.paulsen at firemail.de Sat Jul 3 22:04:23 2021
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Sat, 03 Jul 2021 14:04:23 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
Message-ID: <396911b232bae5938068a14fe0f7181e@firemail.de>
>The Linux distro I use does use systemd but I can ignore it and go on with my life as if it were still running sysvinit. So it's not that big a deal to me.
I'm running red hat fedora which switched 100% to systemd a couple of years ago. It's fine, a good piece of software.
From crossd at gmail.com Sat Jul 3 23:20:57 2021
From: crossd at gmail.com (Dan Cross)
Date: Sat, 3 Jul 2021 09:20:57 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <396911b232bae5938068a14fe0f7181e@firemail.de>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
Message-ID: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
On Sat, Jul 3, 2021 at 8:36 AM Thomas Paulsen <thomas.paulsen at firemail.de>
wrote:
> >The Linux distro I use does use systemd but I can ignore it and go on
> with my life as if it were still running sysvinit. So it's not that big a
> deal to me.
> I'm running red hat fedora which switched 100% to systemd a couple of
> years ago. It's fine, a good piece of software.
>
Systemd is both good and bad.
The good part is that it allows for parallel service startup, which means
that your system gets up and running (and serving useful work) faster. It
understands the service dependency graph and thus the service start order
and what can be done simultaneously. It also, in theory anyway, makes life
a little easier for the authors of what I'll call "service software" (read:
daemons and servers): need a privileged resource? Describe it to systemd,
that will then acquire it for you and hand it to your unprivileged service
software. That's nifty, aids privilege separation, namespace sandboxing a
la containers, etc.
But systemd is also terrible. In an extremely un-Unix-like manner, it
consolidates an enormous number of disparate functions into a single
monolithic piece of software. It uses ersatz data formats that are abjectly
horrible. It uses binary logging, which means that one cannot use the full
complement of Unix text filters to inspect logs. It does all sorts of stuff
behind the scenes (manipulating filesystems, for example) in ways that are
obscured and opaque to system administrators, let alone programmers; this
can have surprising results (ask Ron Minnich about systemd-related data
loss). It has complete disregard, and indeed, contempt for the Unix
philosophy.
What's interesting (to me, anyway), is how few people care about the
deficiencies. This suggests a pretty fundamental shift in how people use
Unix-like systems, and Linux in particular: for _most_ users, it has become
a commoditized vessel for running other interesting software, but not what
we historically think of as "Unix". Sure, a lot of people still live at the
command line, but that's no longer the primary focus of interaction. Our
machines are now either all-singing, all-dancing multimedia workstations
where the sole user is in a web browser most of the time, in which case the
underlying system is just a detail, they're server-class machines that are
running some workload, but not something that's interactive, or embedded
devices that are black boxes.
Much of Unix's early evolution and thus architecture and philosophy, came
from addressing a set of problems that people had in a historical context
that, one could argue, aren't that relevant anymore. A hierarchical
filesystem in a global namespace, pipelines facilitating chaining of
filters for interactive use, a simple but weak permissions model,
unstructured text as a universal interchange format, terminal-oriented text
editors.... All of these were fine on shared multiuser interactive
machines, but do they matter as much now? If the nexus of interaction is a
web browser, who cares whether I can grep a log file? If I just want my
bluetooth headphones and USB camera to work for an online meeting, how that
stuff is put together under the hood isn't that interesting to me. In
short, the Unix philosophy is becoming less and less relevant as a new
generation of users and programmers put different demands on systems. Linux
is _probably_ the most prevalent kernel in the world, but most places its
used it's hidden from view. In that context, something like systemd
actually makes some amount of sense.
Perhaps I've mentioned this story before: a former colleague at Google was
writing a shell script to figure something out. It wasn't working. Really,
what he wanted was basically a `grep -q` and an `if` statement, but he'd
written a complicated mess with shell functions that tried to "return" the
exit status of the processes they ran: his shell script was written more
like a Python program. I rewrote it for him in half-a-dozen or so lines
(down from 30 or 40) and talked about Unix for a minute, the philosophy,
etc. At the end of my monologue extolling the virtues of our style of
computing, he looked at me blankly and said something along the lines of,
"yeah. I think that time has passed and people just don't conceptualize
problems that way anymore." I was sad, but is it any wonder that the kids
reach for Python before a shell script these days? We aren't teaching, yes,
but moreover they don't want to learn because the problems they're trying
to solve are different. We need to accept and internalize that and think
hard about how the tools we use can be brought to bear on the problems that
are relevant _now_, not 30 years ago.
It does beg the question: is a Unix-style kernel still the appropriate
foundation for this style of computing? Why are we still using this system:
is it because of its intrinsic power and versatility, or because of
inertia? Systemd, containers, etc, all suggest that our models are
inadequate.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/b37898c4/attachment.htm>
From steffen at sdaoden.eu Sat Jul 3 23:34:58 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 03 Jul 2021 15:34:58 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210702234941.MjMt0%steffen@sdaoden.eu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<20210702234941.MjMt0%steffen@sdaoden.eu>
Message-ID: <20210703133458.yDV-p%steffen@sdaoden.eu>
Steffen Nurpmeso wrote in
<20210702234941.MjMt0%steffen at sdaoden.eu>:
|Steve Nickolas wrote in
| <alpine.DEB.2.21.2107021910240.15013 at sd-119843.dedibox.fr>:
||On Fri, 2 Jul 2021, Henry Bent wrote:
||> On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm at 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.
...
||The Linux distro I use does use systemd but I can ignore it and go \
||on with
||my life as if it were still running sysvinit. So it's not that big \
||a deal
||to me.
||
||I'd prefer that they kept sysvinit, but eh. What's that saying? "Those
||who fail to understand Unix are condemned to recreate it, poorly" ?
|
|Well iwd(8) for example that i happen to have installed as
...
|.. whatever), and note that iwd neither supports a normal syslog
|nor command line parameters to configure paths etc., the latter
|have to come in via environment if they shall, and the manual says
|these are "normally provided by systemd" (which is not true .. for
|me). And no syslog at all! No PID file handling. And bugs even
|though Intel.com paid for it. I mean "get up, stand up", they do
|a thousand things and not seldom i wonder.
And not to mention that there is a builtin DHCP server, but it
only can be integrated nicely "back" into systemd, or resolvconf.
You know, so much logic, and then not even the possibility to
simply say "hook" to invoke a simply shell script. So i need
dhcpcd in addition, just for that hook that i use, for example, to
setup dnsmasq resolv, and to start a shell-based rdate(8) hook to
contact my ntpd-driving web VM via VPN. I mean, what can happen,
address, gateway, and some more variables. Carrier gained and
carrier lost. Just some environment variables to pass along.
And mind you, it is getting worse it seems. They write their
software more and more integrated specifically for systemd beyond
that iwd thing. They do not generate manual pages when creating
release balls. They require newest compiler additions for some
minor syntax sugar on less that one percent of their codebase. It
seems some new "systems" even require an active internet
connection .. for compiling the software! (Rust?)
I mean, that is not new. Zawinski's complain on completely
rewriting Netscape Navigator in C++ for the rewrites sake can
still be read on the web. In parts it may be normal progression,
it is just the dumb to which it appears as entanglement.
With a "Happy to be stupid",
Ciao from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From rich.salz at gmail.com Sat Jul 3 23:56:36 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Sat, 3 Jul 2021 09:56:36 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210703133458.yDV-p%steffen@sdaoden.eu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<20210702234941.MjMt0%steffen@sdaoden.eu>
<20210703133458.yDV-p%steffen@sdaoden.eu>
Message-ID: <CAFH29tpbwWoGx6vJS7ee7aUJgu3hwsNyYFrSaFHy6Z_4x7z4qw@mail.gmail.com>
I remember at some Usenix panel, Steve Johnson said "what happens to the
Unix model when the primary mode of interaction isn't a set of bytes" This
was 20+ years ago, IIRC. I think Rob Pike's ACME and Squeak tried to
provide an answer to a half-way situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/eda5b74c/attachment.htm>
From clemc at ccc.com Sun Jul 4 00:15:11 2021
From: clemc at ccc.com (Clem Cole)
Date: Sat, 3 Jul 2021 10:15:11 -0400
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAHrGxA2bB31JctWvXxN_46-Y+zo4JcuYXpGZQXd3aHZNB6Y5ng@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAHrGxA2bB31JctWvXxN_46-Y+zo4JcuYXpGZQXd3aHZNB6Y5ng@mail.gmail.com>
Message-ID: <CAC20D2NfhnwoO+j_yfg0Te2XiOKnAJSuGxwX0m45oJuRPZwWuQ@mail.gmail.com>
On Fri, Jul 2, 2021 at 10:22 PM Matt Day <fjarlq at gmail.com> wrote:
> I think you must be right about the first machine being something running
> BSD UNIX.
>
Be careful when you say 'BSD'-- when people say "BSD UNIX" they
*usually mean* a Unix release post-VAX support (*a.k.a.* 3BSD).
We know for a fact that Rogue definitely ran on 16-bit PDP-11's - it's an
open question of it needed the '17th bit' (*a.k.a.* separate I/D of
the 11/45 class). As I said, I had on the TekLab's 11/70 in those days and
I think I got it from Mark Bales, who was a UCB student in the CAD group
which I would later join as a grad student.
Plus Ken Arnold was originally part of the Ingres group, which famously had
the only ArpaNet connection on campus at the time (Ing70 - which I have
forgotten what it's one letter 'Berk-Net' id was -- Mary Ann might remember
- *i.e*. all external email was shipped across the Berknet to Ing70 for
processing).
The original BSD (*a.k.a.* what we call 1BSD on this mailing list) and
2BSD, were already in the wild particularly at other University sites,
since 1BSD had UCB Pascal in it and many schools in those days were using
Pascal as their teaching language. But ... if you look at the tapes, there
are tools and the C-shell, ex, and other tidbits, but the *kernel* running
at UCB in those days is very much V6 and later V7 based - maybe with a few
changes like some performance tweaks for nami and moving the I/O buffers
(but those were from other places).
The system people ran in those days (particularly on PDP-11s) is not nearly
what we now think of as a 'pure-joy.' Truth is, until 4.1BSD, that is
really were 'BSD' starts to take an identity of its own as being distinctly
different from Research and both being loved and loathed by many -- Rob's
'cat -v' paper *et al.*.
>From the timing, it is also quite possible Toy and Wichman had either a
3BSD or very early 4BSD Vax or just as likely V7 with 2BSD loaded.
Just an old f*art who was there chiming in ... :-)
Clem
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/f90d66f0/attachment.htm>
From imp at bsdimp.com Sun Jul 4 01:08:09 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 3 Jul 2021 09:08:09 -0600
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAC20D2NfhnwoO+j_yfg0Te2XiOKnAJSuGxwX0m45oJuRPZwWuQ@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAHrGxA2bB31JctWvXxN_46-Y+zo4JcuYXpGZQXd3aHZNB6Y5ng@mail.gmail.com>
<CAC20D2NfhnwoO+j_yfg0Te2XiOKnAJSuGxwX0m45oJuRPZwWuQ@mail.gmail.com>
Message-ID: <CANCZdfpT_H2zLG_v_SRPhYnDO-ar1w-aDAwWgvFkCdTv2MCZLA@mail.gmail.com>
On Sat, Jul 3, 2021 at 8:16 AM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Fri, Jul 2, 2021 at 10:22 PM Matt Day <fjarlq at gmail.com> wrote:
>
>> I think you must be right about the first machine being something running
>> BSD UNIX.
>>
> Be careful when you say 'BSD'-- when people say "BSD UNIX" they
> *usually mean* a Unix release post-VAX support (*a.k.a.* 3BSD).
>
> We know for a fact that Rogue definitely ran on 16-bit PDP-11's - it's an
> open question of it needed the '17th bit' (*a.k.a.* separate I/D of
> the 11/45 class). As I said, I had on the TekLab's 11/70 in those days and
> I think I got it from Mark Bales, who was a UCB student in the CAD group
> which I would later join as a grad student.
>
> Plus Ken Arnold was originally part of the Ingres group, which famously
> had the only ArpaNet connection on campus at the time (Ing70 - which I have
> forgotten what it's one letter 'Berk-Net' id was -- Mary Ann might remember
> - *i.e*. all external email was shipped across the Berknet to Ing70 for
> processing).
>
> The original BSD (*a.k.a.* what we call 1BSD on this mailing list) and
> 2BSD, were already in the wild particularly at other University sites,
> since 1BSD had UCB Pascal in it and many schools in those days were using
> Pascal as their teaching language. But ... if you look at the tapes, there
> are tools and the C-shell, ex, and other tidbits, but the *kernel* running
> at UCB in those days is very much V6 and later V7 based - maybe with a few
> changes like some performance tweaks for nami and moving the I/O buffers
> (but those were from other places).
>
> The system people ran in those days (particularly on PDP-11s) is not
> nearly what we now think of as a 'pure-joy.' Truth is, until 4.1BSD, that
> is really were 'BSD' starts to take an identity of its own as being
> distinctly different from Research and both being loved and loathed by many
> -- Rob's 'cat -v' paper *et al.*.
>
> From the timing, it is also quite possible Toy and Wichman had either a
> 3BSD or very early 4BSD Vax or just as likely V7 with 2BSD loaded.
>
Rough timeline
V6 mid 75
1BSD mid 77 (pascal, ex, but no vi)
2BSD late 78 (vi, though from a 1979 copy in tuhs no curses yet, but
with termcapish things dated April 79)
V7 early 79
3BSD late 79
2BSD April 80 (the 2.79 in the archives, by this point curses was
added to the tape)
4BSD mid 80 (with curses)
2.8/4.1BSD mid 81 (first unified kernel+userland pdp-11 distro)
So curses library wasn't on the 3bsd tape. It may have been on the 4bsd
tape: all I can find is libtermcap on tuhs, but kirk's archive has a
curses library data October 1980. The late 2BSD tapes (called 2.79BSD in
our archive) is the earliest artifact I can find. It appears curses wasn't
widely available until midish 1980: the 2.79BSD tape has a July 17, 1980
date on the docs (being the earliest artifact I could find) and a Jan 1981
on the sources. The earliest net.sources archive I can find starts in 1982.
The latest 2BSD tape we have in the archive from April 1979 does not have
it.
A binary of rogue is on the 2.8BSD and 4.1BSD tapes. 2.8 has 'version 3.4'
but no sources and 4.1 has vers 4.22 in a 4.0 upgrade directory, but no
sources either:
-r--r--r-- 1 root wheel 70364 May 21 1981 ./2.8/usr/bin.v7/ucb/rogue
-r-xr-xr-x 1 root wheel 96356 Mar 13 1982 ./4.1.snap/usr/games/rogue
-r-xr-xr-x 1 root wheel 96356 Mar 13 1982
./4.1/4.0.upgrade/usr/games/rogue
Even in 4.2 it looks like most of rogue was distributed as a binary .o
file, and needed the updated net.sources version of libcurses, distributed
with 4.2bsd.
So from a tracing the artifacts for libcurses, we get an interesting
diversion, but nothing conclusive.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/e423754e/attachment.htm>
From akosela at andykosela.com Sun Jul 4 01:49:57 2021
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 3 Jul 2021 17:49:57 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210702213648.GW817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
Message-ID: <CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
On 7/2/21, Larry McVoy <lm at 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.
They come from the same "modern" camp of cloud fanatics that claim
"there was no automation before Ansible and no containerization before
Docker". They also think that C is obsolete and your software stack
is useless if you don't include a dozen or so flashy bleeding edge
technologies and programming languages.
This is the kind of techno-cult fashion that Nikolai Bezroukov warned
about. In the last few years we have seen more and more "papers" that
debunk and mock older stable Unix technologies because they want to
forcefully push their agenda and their new marketing terms. We have
seen this with systemd which was forcefully pushed down on us; we have
seen this with Ansible, etc.
This vandalization of Unix already took place and I do not see a clear
way out of this situation.
--Andy
From tytso at mit.edu Sun Jul 4 03:37:06 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 3 Jul 2021 13:37:06 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
Message-ID: <YOCgQkwbz8Xf8ap9@mit.edu>
On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
>
> Systemd is both good and bad.
I agree with most of what you assess as "good" and "bad" with systemd.
However...
> It uses ersatz data formats that are abjectly
> horrible. It uses binary logging, which means that one cannot use the full
> complement of Unix text filters to inspect logs....
To be fair, systemd isn't the first. BSD's sar program uses a binary
log file.
I'm not sure whether it's BSD's fault or only after it was pulled into
the systat package for Linux, but the binary format for the sar file
is (a) not self-describing, (b) not backwards compatible, and (c) not
stable between different versions, such that if you copy /var/log/sa/saNN
the files from one system and try to interpret it on another system, you
need to make sure that other system has the same version of sar installed.
This can be a headache if you are trying to debug an enterprise system
which is using a seven-year-old version of RHEL, and your laptop is
running something a bit more modern.
Things like Ingres also came out of Berkely, and modern databases all
use binary format files. Is anything running a database, whether it
be Ingress, Postgres, Oracle Enterprise Database, DB2, no longer "Unix"?
And then there's AIX, which uses binary config files which are
manipulated using "smit", and mixes per-machine specific configs with
more general configs, all in a single config (or should I say,
"registry") file, so $DEITY help you if you try to copy the smit
database from one system to another if you are trying to do some kind
of large scale administration setup. And granted there are many
people would dispute whether AIX is actually "Unix", it technically
speaking qualified to use the "Unix"(tm) trademark.
Similarly, Digital Equipment Corpartion's Ultrix used a binary log
file which you had to transmogrify using the uerf ("Ultrix Error
Report Formatter"). Like systemd, Ultrix uses a structured logging so
you can pull out specific types of logs, and Ultrix's uerf works much
systemd's journalctl.
So the concept of using binary logs and binary files predates systemd,
and there are more than a few examples that can be found in historical
systems that most people would have no trouble calling "Unix", and
even qualify for the Unix(tm) trademark.
- Ted
P.S. For the most part, Linux systems don't qualify for the Unix(tm)
trademark, although it's not clear most people care about that these
days. (A long time ago distributions paid $$$ to Posix Compliance
labs, probably because the government procurement requirements
required Unix(tm) systems, much like OSI stacks were simlarly required
by government procurement requirements.)
From imp at bsdimp.com Sun Jul 4 03:57:44 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 3 Jul 2021 11:57:44 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOCgQkwbz8Xf8ap9@mit.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<YOCgQkwbz8Xf8ap9@mit.edu>
Message-ID: <CANCZdfoq_kKTzqP=99QrMeZd5SZNLRJH+H8ccFkjKi=f9AFadg@mail.gmail.com>
On Sat, Jul 3, 2021 at 11:45 AM Theodore Ts'o <tytso at mit.edu> wrote:
> On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
> >
> > Systemd is both good and bad.
>
> I agree with most of what you assess as "good" and "bad" with systemd.
> However...
>
> > It uses ersatz data formats that are abjectly
> > horrible. It uses binary logging, which means that one cannot use the
> full
> > complement of Unix text filters to inspect logs....
>
> To be fair, systemd isn't the first. BSD's sar program uses a binary
> log file.
>
You mean System V's sar program? BSD has never had a sar program.
It's not in any of the CSRG releases, nor in any of {Free,Net,Open}BSD
systems that are around today.
It first appeared in System Vr1, and was in each of the following releases
if the listings of files on the net are any indication.
> I'm not sure whether it's BSD's fault or only after it was pulled into
> the systat package for Linux, but the binary format for the sar file
> is (a) not self-describing, (b) not backwards compatible, and (c) not
> stable between different versions, such that if you copy /var/log/sa/saNN
> the files from one system and try to interpret it on another system, you
> need to make sure that other system has the same version of sar installed.
>
Sounds awful...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/c20ce8f4/attachment.htm>
From tytso at mit.edu Sun Jul 4 04:10:24 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 3 Jul 2021 14:10:24 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CANCZdfoq_kKTzqP=99QrMeZd5SZNLRJH+H8ccFkjKi=f9AFadg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<YOCgQkwbz8Xf8ap9@mit.edu>
<CANCZdfoq_kKTzqP=99QrMeZd5SZNLRJH+H8ccFkjKi=f9AFadg@mail.gmail.com>
Message-ID: <YOCoEIUzwrYS9hWf@mit.edu>
On Sat, Jul 03, 2021 at 11:57:44AM -0600, Warner Losh wrote:
>
> You mean System V's sar program? BSD has never had a sar program.
> It's not in any of the CSRG releases, nor in any of {Free,Net,Open}BSD
> systems that are around today.
Ah, I got confused because a web search turned up:
https://www.freebsd.org/cgi/man.cgi?query=sar&sektion=1M&apropos=0&manpath=SunOS+5.8
.... and I got mislead because FreeBSD hosts Solaris man pages.
Although it appears more recently FreeBSD has "bsdsar" in its Ports.
My larger point remains, though; is System V considered "Unix" by Dan
Cross's definition? :-)
- Ted
From crossd at gmail.com Sun Jul 4 06:02:53 2021
From: crossd at gmail.com (Dan Cross)
Date: Sat, 3 Jul 2021 16:02:53 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOCoEIUzwrYS9hWf@mit.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<YOCgQkwbz8Xf8ap9@mit.edu>
<CANCZdfoq_kKTzqP=99QrMeZd5SZNLRJH+H8ccFkjKi=f9AFadg@mail.gmail.com>
<YOCoEIUzwrYS9hWf@mit.edu>
Message-ID: <CAEoi9W7k0Qgc=DqD_kL7mMT9=wCEYzkskcUNeSvQX-MLSvnX5g@mail.gmail.com>
On Sat, Jul 3, 2021 at 2:10 PM Theodore Ts'o <tytso at mit.edu> wrote:
> On Sat, Jul 03, 2021 at 11:57:44AM -0600, Warner Losh wrote:
> >
> > You mean System V's sar program? BSD has never had a sar program.
> > It's not in any of the CSRG releases, nor in any of {Free,Net,Open}BSD
> > systems that are around today.
>
> Ah, I got confused because a web search turned up:
>
>
> https://www.freebsd.org/cgi/man.cgi?query=sar&sektion=1M&apropos=0&manpath=SunOS+5.8
>
> .... and I got mislead because FreeBSD hosts Solaris man pages.
>
> Although it appears more recently FreeBSD has "bsdsar" in its Ports.
>
Huh. I guess 'sa' wasn't good enough, though that also uses a format that
suffers from many of the same deficiencies you point out for 'sar'.
My larger point remains, though; is System V considered "Unix" by Dan
> Cross's definition? :-)
Well, with the caveat that I'm pretty sure Dan Cross's definition of Unix
is of interest to an extremely small set of people (possibly the empty
set...), and that any answer is a bit of a meditation on the existential
philosophy of, "really, what _is_ Unix, anyway?" I'll go out on a limb and
say yes.
I don't think that the pervasive use of text formats for logs in much of
the system was ever meant to be to the exclusion of binary formats for
specific applications where that was warranted (usually for efficiency),
which have existed since the near the beginning. Off the top of my head,
representative examples of logging or logging-adjacent binary formats
common on Unix systems and extending into antiquity include utmp/wtmp,
lastlog, the quota database and acct; perhaps even crash dumps and core
files might fall under this overarching umbrella.
Not to mention all of the other ubiquitous binary file formats that've been
floating around seemingly forever: tar/tp/ar/UFS dump, dbm/ndbm, any number
of compressed file formats, and so on. Not to mention the on-disk data
structures describing filesystems and so on. But historically speaking,
logs, whether generated by explicit print statements in programs or by
something like calling `syslog()`, have been text. I suppose the point
being that, while individual use cases might use some binary format, by and
large most systems opted to use text and for many years that was just the
accepted and anticipated course of action. It was the default.
Systemd turns this on it's head. Text isn't just no longer the default,
it's just not an option. Sure, the aforementioned things are similar, but
this is a step beyond.
And note that I didn't say that Linux wasn't Unix because of systemd (or
perhaps more properly, that the Linux distributions that use systemd
weren't Unix), but rather, that systemd itself wasn't very Unixy. I think
that's accurate. Of course with respect for the other binary things you
mentioned (databases and so on) people write all kinds of whacky things for
systems, but those don't define the system. Systemd is much closer to the
"system" than, say Ingres of Oracle or PostgreSQL.
I do think this shift probably started with System V, but it still largely
follows the model of "Unix". And even AIX has syslog.
It's funny...I have no recollection of the mechanism you describe for
Ultrix, and a DECstation 5000/240 was my main machine for a good while.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/3a6847ae/attachment.htm>
From jon at fourwinds.com Sun Jul 4 06:07:47 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 03 Jul 2021 13:07:47 -0700
Subject: [TUHS] The Unix shell: a 50-year view
Message-ID: <202107032007.163K7lW72490663@darkstar.fourwinds.com>
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
From tuhs at eric.allman.name Sun Jul 4 08:25:24 2021
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 3 Jul 2021 15:25:24 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CANCZdfpT_H2zLG_v_SRPhYnDO-ar1w-aDAwWgvFkCdTv2MCZLA@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAHrGxA2bB31JctWvXxN_46-Y+zo4JcuYXpGZQXd3aHZNB6Y5ng@mail.gmail.com>
<CAC20D2NfhnwoO+j_yfg0Te2XiOKnAJSuGxwX0m45oJuRPZwWuQ@mail.gmail.com>
<CANCZdfpT_H2zLG_v_SRPhYnDO-ar1w-aDAwWgvFkCdTv2MCZLA@mail.gmail.com>
Message-ID: <0c3ba540-0df0-b4e6-bf04-8169e22a5f74@neophilic.com>
> Plus Ken Arnold was originally part of the Ingres group, which
> famously had the only ArpaNet connection on campus at the time (Ing70
> - whichВ I have forgottenВ what it's one letter 'Berk-Net' id was --
> Mary Ann might remember - /i.e/. all external email was shipped across
> the Berknet to Ing70 for processing).
Actually, I don't recall Ken actually working on Ingres, although it's
not impossible — he certainly did work at Britton Lee, which was an
Ingres spin-off. But lots of people in the department had access to our
machine, almost certainly including Ken. But resources were limited and
the entire department had to compete for the two terminal lines
available at the time, which is why I wrote delivermail (later sendmail)
in the first place.
The "one letter berk-net id" of ing70 was "i". At the time of the
ARPAnet it was running a rather customized V6 that (if I recall
correctly) we got from Greg Chesson. It was connected via a VDH (Very
Distant Host) interface to the IMP at LBL — essentially a six-foot-high
9600 baud modem.В ingvax was "j", but the ARPAnet code never ran on that
hardware.
eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210703/14458bb6/attachment.htm>
From rtomek at ceti.pl Sun Jul 4 10:47:57 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Sun, 4 Jul 2021 02:47:57 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
Message-ID: <20210704004757.GB24671@tau1.ceti.pl>
On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
[...]
> Much of Unix's early evolution and thus architecture and philosophy, came
> from addressing a set of problems that people had in a historical context
> that, one could argue, aren't that relevant anymore.
I mostly agree with you, but I think certain things should be
expressed more explicitly, even if I do not want to be picky. So, I
see the claim of Unix not being relevant anymore might be interpreted
in two ways, and both are not (quite) true.
First, if it means "for all people it is not relevant anymore", such
thing never happened IMHO. For this, all those folks would need to
consider Unix as a tool for their problems and decide that it was
obsolete. But, most of humans were never so much interested in
computers to know about "some yooo-neex" and this state of things
lasts to these days. If they use computer (cellphone), it is most
probably because now the devices enable dating and other forms of
entertainment. Some of them even heard about "Leah nukes".
Another way of understanding your statement is "there was a group of
folks for whom Unix was relevant and lost its appeal". This, again,
not true. The group itself may have lost members and gained members,
but I believe it is more or less same size. Maybe even bigger than it
was, and ability to have anything "unix-like" for free (as in
"voluntary donation") plays huge role here.
> A hierarchical filesystem in a global namespace, pipelines
> facilitating chaining of filters for interactive use, a simple but
> weak permissions model, unstructured text as a universal interchange
> format, terminal-oriented text editors.... All of these were fine on
> shared multiuser interactive machines, but do they matter as much
> now?
Depends. In a land of the blind a one-eye should be very careful,
because he would not be a king. I certainly would not like to be
endlessly asked for help with installing Linux. I think majority of
computer users do not care, will not care, that they have some files
on their machines or even that what they have are the machines. So,
they might not appreciate your knowledge about such things. Perhaps it
is a good thing?
[...]
> Perhaps I've mentioned this story before: a former colleague at Google was
> writing a shell script to figure something out. It wasn't working. Really,
> what he wanted was basically a `grep -q` and an `if` statement, but he'd
> written a complicated mess with shell functions that tried to "return" the
> exit status of the processes they ran: his shell script was written more
> like a Python program. I rewrote it for him in half-a-dozen or so lines
> (down from 30 or 40) and talked about Unix for a minute, the philosophy,
> etc. At the end of my monologue extolling the virtues of our style of
> computing, he looked at me blankly and said something along the lines of,
> "yeah. I think that time has passed and people just don't conceptualize
> problems that way anymore."
I think what he really meant (knowlingly or not) was "the money walks
somewhere else". As far as I can say, the kids are just following
money. This kind of behaviour is called a tropism. Since this is how
the world goes, I am not sure it can be described as bad or good. This
is very much like evolution, thanks to which we are living in and are
the result of living in, a huge slaughterhouse. The 30cm long
centipede hunts bats which evolved long after centipede and long after
insects were dominant life forms on a planet. /bin/sh will be used to
solve problems in a future, too. Innumerable Unix servers will be sent
to the landfill. systemd will grow a hairy-sticky ecosystem of its
own, developing pseudo-kernels like pseudo-brains in dinosaur belly.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From lm at mcvoy.com Sun Jul 4 14:36:15 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 3 Jul 2021 21:36:15 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210704004757.GB24671@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
Message-ID: <20210704043615.GE817@mcvoy.com>
On Sun, Jul 04, 2021 at 02:47:57AM +0200, Tomasz Rola wrote:
> On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
> [...]
> > Much of Unix's early evolution and thus architecture and philosophy, came
> > from addressing a set of problems that people had in a historical context
> > that, one could argue, aren't that relevant anymore.
This is a response to Cross. You are sort of right in that we are not on
uniprocessors where we disable interrupts to manage things.
Unix still matters. It has mattered for a very long time, I could argue
it is the most important operating system in the world. Yeah, windows
won, but it didn't win on merits.
In my opinion you couldn't be more wrong. We still have the same problems,
we are still trying to grep an answer out of a bunch of info that has just
gotten bigger.
We still want to do the same things and we are doing them better with faster
CPUs, memory, disks, etc.
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.
If you actually have a clue, if you can do stuff, all of that other stuff
becomes fluff. Yep, some of it is useful but most of it is just there
because it wants to feel important.
Unix matters, the way that you can compose stuff still matters, people
who can do that run circles around the people who say Unix doesn't work.
My first job, they said 6 months, I did it 3 weeks by using what Unix
gave me.
From crossd at gmail.com Sun Jul 4 22:48:23 2021
From: crossd at gmail.com (Dan Cross)
Date: Sun, 4 Jul 2021 08:48:23 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210704004757.GB24671@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
Message-ID: <CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
On Sat, Jul 3, 2021 at 8:57 PM Tomasz Rola <rtomek at ceti.pl> wrote:
> On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
> [...]
> > Much of Unix's early evolution and thus architecture and philosophy, came
> > from addressing a set of problems that people had in a historical context
> > that, one could argue, aren't that relevant anymore.
>
> I mostly agree with you, but I think certain things should be
> expressed more explicitly, even if I do not want to be picky. So, I
> see the claim of Unix not being relevant anymore might be interpreted
> in two ways, and both are not (quite) true.
I didn't say that Unix is no longer relevant. I said that the problems that
were prominent when Unix was built, and that thus shaped its architecture,
are much _less_ relevant now than they were at the time. They still have
some relevance, but are no longer primary for the vast majority of use
cases Unix is used for. Further, the way people approach problems now has
changed, even if they still generically assume "Unix" as the base they
build on.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/092d8599/attachment.htm>
From crossd at gmail.com Mon Jul 5 00:56:48 2021
From: crossd at gmail.com (Dan Cross)
Date: Sun, 4 Jul 2021 10:56:48 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210704043615.GE817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl> <20210704043615.GE817@mcvoy.com>
Message-ID: <CAEoi9W7hjzRcCja6-rEaFx56KhEtfchfgCgUM6u+_bJAdQXkvA@mail.gmail.com>
On Sun, Jul 4, 2021 at 12:37 AM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jul 04, 2021 at 02:47:57AM +0200, Tomasz Rola wrote:
> > On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
> > [...]
> > > Much of Unix's early evolution and thus architecture and philosophy,
> came
> > > from addressing a set of problems that people had in a historical
> context
> > > that, one could argue, aren't that relevant anymore.
>
> This is a response to Cross.
Uh oh. I know I'm in trouble when I'm referred to by my last name only. :-)
You are sort of right in that we are not on
> uniprocessors where we disable interrupts to manage things.
>
> Unix still matters. It has mattered for a very long time, I could argue
> it is the most important operating system in the world. Yeah, windows
> won, but it didn't win on merits.
>
Whoa hold on now. I never said that _Unix_ doesn't still matter. It
emphatically does. I agree with you that it, or perhaps more precisely the
evolutionary tree of systems that fit under it's rather large umbrella, is
indeed the most important operating system family in the world. It runs
everywhere and it runs everything; it's literally out of this world. You
will get no argument from me there.
In my opinion you couldn't be more wrong. We still have the same problems,
> we are still trying to grep an answer out of a bunch of info that has just
gotten bigger.
>
We still want to do the same things and we are doing them better with faster
> CPUs, memory, disks, etc.
>
But this I disagree with. We may still be trying to solve many of the same
problems, but entirely new categories of problems have sprung up since Unix
was invented, those problems have grown to frankly dwarf the size of the
previous problems, and our modes of interaction with the machine have
totally changed. Consider that the median interaction these days is some
RPC-ish call over HTTP between a user using a gesture interface on a phone
or tablet or something, and some service running somewhere "in the cloud".
Both sides of this (and the myriad stages in between) might be running on
machines that are running "Unix", but this emphatically is _not_ grep, at
least no more than extracting data out of IMS in COBOL under OS/360 was
also a glorified form of "grep".
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.
>
Yes, that was kind of my point. But not only do they not get Unix, they
don't want to, either. Why is that? I think that's the interesting question.
> If you actually have a clue, if you can do stuff, all of that other stuff
> becomes fluff. Yep, some of it is useful but most of it is just there
> because it wants to feel important.
I agree with that last statement, but I'm not sure I agree with the former.
I'm not a front-end person; I'll never be a front-end person. Frankly, I
lack the artistic and aesthetic ability to ever be good at that kind of
work. My web site is frankly ugly; I don't care. But I've had the
opportunity to interact with folks who are actually good at front-end
stuff, and they're really sharp. They definitely have a clue. But it's an
entire type of clue that I simply do not nor ever will have.
Many of those people choose to use Linux as their daily driver environment;
bully for them. However, they don't reach for the compliment of tools that
many of us take for granted as being part and parcel of the Unix
environment are not what they reach for first. Most folks aren't using
`sed` to extract something from a typescript program or CouchDB or whatever.
Unix matters, the way that you can compose stuff still matters, people
> who can do that run circles around the people who say Unix doesn't work.
> My first job, they said 6 months, I did it 3 weeks by using what Unix
> gave me.
>
Forgive my saying this, but that was then, this is now. The kinds of
automation that I used to wow folks with when I was starting out by being
moderately facile with Unix tools just don't apply to entire classes of
problems anymore. And if the job is working on one of those problems....
This doesn't mean that Unix isn't still important. It obviously is. But it
means that what people are using it for, and how they're using it has
changed. And that does inevitably raise questions about system evolution.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/1e8c0ad8/attachment.htm>
From tytso at mit.edu Mon Jul 5 02:07:55 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Sun, 4 Jul 2021 12:07:55 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210704043615.GE817@mcvoy.com>
Message-ID: <YOHc29BtJa4c66EI@mit.edu>
On Sat, Jul 03, 2021 at 09:36:15PM -0700, Larry McVoy wrote:
> In my opinion you couldn't be more wrong. We still have the same problems,
> we are still trying to grep an answer out of a bunch of info that has just
> gotten bigger.
>
> We still want to do the same things and we are doing them better with faster
> CPUs, memory, disks, etc.
I'm not sure I agree with you. The same problems still exist, to be
sure. But there are new problems that have also arisen, for which
Unix might not be the best match. For example, Unix didn't have to
deal with devices appearing after the system has booted; or those
devices disappearing afterwards. And of course, with services that
might need to be started or reconfigured or stopped as devices get
attached and detached.
The original Unix systems didn't have the requirement of automatically
detecting failed hardware or software, and taking action to mitigate
those faults without depending on operators in data centers. If we
consider some of the structured logging systems, whether it's
Ultrix/OSF's uerf, or Solaris's SMF, or Tuttle (an internal system I
designed for $WORK), it's at least in part because scraping
/var/log/messages and having cluster management systems parse textual
log entries using an unholy mess of regex's is error prone and not
necessarily reliable or maintainable.
There are also new problems, such as Machine Learning, which has led
to the introduction of coprocessors, which is a great example of
something which is *not* doing the "same things" but with better CPUs,
memory, disks, etc.
You can of course define away some of these new problems as "not
interesting", or "not the true spirit of Unix", but the reality is
there are a good reason why systems have been changing --- it's in
response the pressures of new requirements and new problems being
added, even if the old problems haven't gone away.
> 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.
This is perhaps an unavoidable response to increasing complexity.
When I was an undergraduate we started by building a computer using
TTL chips on a breadboard, and then we went on to learn Scheme and the
Lambda calculus, and then built up from there. But a few years ago,
MIT decided this wasn't sufficiently relevant to how most software
engineers work today, so the intro to computing class was redone to
use Python, and it was a stated goal to give students experience in
how to build on top of a framework which is not sufficiently
documented, and where they need to figure out what the #?$!@? was
going on via experimentation, supplemented with whatever documentation
and sources that students could find/read/understand.
(And if you look at the depth of a stack trace after a typical Java
application crashes due to an unhandled exception, MIT has probably
gotten it right in terms of what most CS students will experience
after they graduate. I remember looking 80-90 Java function names in
a Lotus Notes stack dump after a crash, involving the Eclipse *and*
the Standard Java library frameworks, with awe and horror...)
As a result, I've found that most new college grads don't have much in
the way of Systems training or experience, and for those groups that
need that kind of Systems thinking at $WORK, it's something we need to
train, and not something I can assume new hires will have. (This is
also true for many candidates with significant industry experience
which I've interviewed, alas.)
- Ted
From johnmdow at me.com Mon Jul 5 04:17:55 2021
From: johnmdow at me.com (John Dow)
Date: Sun, 4 Jul 2021 19:17:55 +0100
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
Message-ID: <06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
> On 2 Jul 2021, at 22:58, Henry Bent <henry.r.bent at 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
From clemc at ccc.com Mon Jul 5 05:46:08 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jul 2021 15:46:08 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
Message-ID: <CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
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.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/5b75b713/attachment.htm>
From david at kdbarto.org Mon Jul 5 06:10:14 2021
From: david at kdbarto.org (David Barto)
Date: Sun, 4 Jul 2021 13:10:14 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210704043615.GE817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl> <20210704043615.GE817@mcvoy.com>
Message-ID: <362E120E-AAA9-4888-8592-E506169FF7BE@kdbarto.org>
> On Jul 3, 2021, at 9:36 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Sun, Jul 04, 2021 at 02:47:57AM +0200, Tomasz Rola wrote:
>> On Sat, Jul 03, 2021 at 09:20:57AM -0400, Dan Cross wrote:
>> [...]
>>> Much of Unix's early evolution and thus architecture and philosophy, came
>>> from addressing a set of problems that people had in a historical context
>>> that, one could argue, aren't that relevant anymore.
>
> Unix still matters. It has mattered for a very long time, I could argue
> it is the most important operating system in the world. Yeah, windows
> won, but it didn't win on merits.
>
One thing I’d like to point out is that Linux On Windows is becoming
a thing, to the point that you can execute native Linux applications for
the most part directly in this weird environment.
So even M$ sees that Linux could be a threat in the long term and is
making an attempt to prevent it from harming the M$ universe.
See, you can run your Linux code on Windows, why do you want to
run Linux now? 8^)
David
From dot at dotat.at Mon Jul 5 06:10:49 2021
From: dot at dotat.at (Tony Finch)
Date: Sun, 4 Jul 2021 21:10:49 +0100
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
Message-ID: <e1744742-8751-14cf-9f46-837a28fec688@dotat.at>
Dan Cross <crossd at gmail.com> wrote:
>
> Systemd is both good and bad.
I thought this article was well-informed and informative, but VERY long:
https://blog.darknedgy.net/technology/2020/05/02/0/
"systemd, 10 years later: a historical and technical retrospective"
Tony.
--
f.anthony.n.finch <dot at dotat.at> https://dotat.at/
Humber, Thames: Southeast veering southwest, 3 to 5. Smooth or slight.
Thundery showers. Good, occasionally poor.
From dfawcus+lists-tuhs at employees.org Mon Jul 5 09:24:18 2021
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Mon, 5 Jul 2021 00:24:18 +0100
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
Message-ID: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
> They also think that C is obsolete
I'd not say it is obsolete, but despite it having been my main language for the
last 30 years, these days I would be inclined to restrict the range of new tasks
I'd use it for.
So in thinking of how to solve certain problems, I'd split a subset of the problem
in to something in C, and the rest in to another language - probably Go. That may
simply reflect the nature of the problems I tackle, I can imagine that others
might not merit any use of C.
DF
From ggm at algebras.org Mon Jul 5 09:40:16 2021
From: ggm at algebras.org (George Michaelson)
Date: Mon, 5 Jul 2021 09:40:16 +1000
Subject: [TUHS] Dennis Ritchie's couch
In-Reply-To: <424dde98-7a42-57e6-e13a-83c3e6ccc020@dotat.at>
References: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
<C728300B-6E54-4C25-A160-C1392BE37469@iitbombay.org>
<424dde98-7a42-57e6-e13a-83c3e6ccc020@dotat.at>
Message-ID: <CAKr6gn2jwY+jdn6oH9p2VOWANgW90EVJBbCmG0D8KyAzVqwQhA@mail.gmail.com>
I wasn't very good at making jokes at the best of times, but I thought
the innate tabular nature of a yacc parser and the role of yyparse()
and the syntax yacc is written in would have got us there. It was a
pale attempt at HUMOUR
As reddit says: <whoooosh>
From cym224 at gmail.com Mon Jul 5 09:50:50 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Sun, 4 Jul 2021 19:50:50 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
Message-ID: <6a9bb07f-7d5a-9825-16eb-5d21412b0727@gmail.com>
On 2021-07-04 19:24, Derek Fawcus wrote (in part):
> So in thinking of how to solve certain problems, I'd split a subset of
> the problem
> in to something in C, and the rest in to another language - probably
> Go. That may simply reflect the nature of the problems I tackle, I can
> imagine that others might not merit any use of C.
This would be very much domain specific.В I work with embedded systems,
where one's choice of language is limited.
N.
From drsalists at gmail.com Mon Jul 5 10:15:42 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 4 Jul 2021 17:15:42 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <6a9bb07f-7d5a-9825-16eb-5d21412b0727@gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<6a9bb07f-7d5a-9825-16eb-5d21412b0727@gmail.com>
Message-ID: <CAGGBd_piNb6YVExkVErJ7HiHYU0x0kywBHiLY-8GED71-aQd4g@mail.gmail.com>
On Sun, Jul 4, 2021 at 4:52 PM Nemo Nusquam <cym224 at gmail.com> wrote:
> On 2021-07-04 19:24, Derek Fawcus wrote (in part):
> > So in thinking of how to solve certain problems, I'd split a subset of
> > the problem
> > in to something in C, and the rest in to another language - probably
> > Go. That may simply reflect the nature of the problems I tackle, I can
> > imagine that others might not merit any use of C.
> This would be very much domain specific. I work with embedded systems,
> where one's choice of language is limited.
>
Have you looked at Micropython? It's written in C, and targets embedded
applications.
https://micropython.org/
I recently compared its threading to a couple of other implementations of
Python, and found that Micropython was the best of those compared.
https://stromberg.dnsalias.org/~strombrg/python-thread-comparison/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/0c238fb6/attachment.htm>
From lm at mcvoy.com Mon Jul 5 10:21:19 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 4 Jul 2021 17:21:19 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
Message-ID: <20210705002119.GL817@mcvoy.com>
On Mon, Jul 05, 2021 at 12:24:18AM +0100, Derek Fawcus wrote:
> On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
> > They also think that C is obsolete
>
> I'd not say it is obsolete, but despite it having been my main language for the
> last 30 years, these days I would be inclined to restrict the range of new tasks
> I'd use it for.
>
> So in thinking of how to solve certain problems, I'd split a subset of the problem
> in to something in C, and the rest in to another language - probably Go. That may
> simply reflect the nature of the problems I tackle, I can imagine that others
> might not merit any use of C.
I had a systems people get together at my place maybe a year ago.
Kirk McKusick and Eric Allman came (as well as a bunch of others,
perhaps most notable was Pugs). I had a very pleasant chat with Eric
about programming styles. I came to the conclusion that I'd love working
with Eric, I think I could work for him and it's even possible he could
work for me. We both love C, we are both disciplined enough to write
maintainable/extendable code in C, it works for us. We really clicked
over our love of C.
I've tried to like other languages, Java is a huge tangled mess, C++ is,
well C++, every company that uses C++ has a list of things you are not
supposed to use, I tried to like Go, maybe I haven't given it enough of
a chance but it didn't grab me, lots of people I know have gone to Rust,
I tried to like that but, man, all the reinventing of syntax drove me
nuts, D seemed like it sort of was close but it changed the syntax too
much.
If I had infinite energy and money, I would fund a dialect of C that
made it more useful. The thing I hate about new programming languages
is they all feel the need to invent a new syntax. There are really
two syntaxes, C and Lisp (and that's a tip of a hat to Lisp, I'm not
a fan). Pick one of those and evolve it.
My whole career I've felt that when you add to the set of code that is
in the world, you should build on what people already know. Everyone
knows C syntax, yeah there are some areas that could do with a cleanup
(looking at you function pointer declarations) but for the most part,
most people can look at C code and know what it does. So why invent
a new syntax and invalidate all of that knowledge that everyone has?
For all its faults, C++ is the closest to a modern language that sort
of fits with what I want but it is a kitchen sink language. It really
wanted the Go trio to say "no" to a lot of stuff, it didn't have that
so it has every language feature you can imagine and it's hard to
onboard people to that. Harder yet to write maintainable code.
So, yeah, I like C. A lot. I wish it would evolve in a sensible way
but as a buddy says, we live in an imperfect world.
--lm
From lm at mcvoy.com Mon Jul 5 10:25:06 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 4 Jul 2021 17:25:06 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <362E120E-AAA9-4888-8592-E506169FF7BE@kdbarto.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<20210704043615.GE817@mcvoy.com>
<362E120E-AAA9-4888-8592-E506169FF7BE@kdbarto.org>
Message-ID: <20210705002506.GN817@mcvoy.com>
On Sun, Jul 04, 2021 at 01:10:14PM -0700, David Barto wrote:
> See, you can run your Linux code on Windows, why do you want to
> run Linux now? 8^)
I know that is tongue in cheek, but because I want a real kernel
that has sane semantics. The windows kernel is pretty nuts.
From cowan at ccil.org Mon Jul 5 11:23:27 2021
From: cowan at ccil.org (John Cowan)
Date: Sun, 4 Jul 2021 21:23:27 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <362E120E-AAA9-4888-8592-E506169FF7BE@kdbarto.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl> <20210704043615.GE817@mcvoy.com>
<362E120E-AAA9-4888-8592-E506169FF7BE@kdbarto.org>
Message-ID: <CAD2gp_TbEJER3WMUNgDvGpZ3ev1zDx6pxLQHUwLaxp7D2qazrQ@mail.gmail.com>
On Sun, Jul 4, 2021 at 4:11 PM David Barto <david at kdbarto.org> wrote:
> So even M$ sees that Linux could be a threat in the long term and is
> making an attempt to prevent it from harming the M$ universe.
>
MS is making a mint letting people run Linux on Azure rent-a-boxen, which
now runs on more Azure instances than Windows does. They aren't anti-Linux
any more. Indeed, they are contributing to the Linux kernel now to make it
run better on WSL.
See, you can run your Linux code on Windows, why do you want to
> run Linux now? 8^)s
I think the real motivation is to get developers off Macs. Many people
(including me at my last two jobs) are developing on Mac OS and deploying
on Linux. With WSL, developers can develop on Linux(-on-Windows) and
deploy on Linux (for reals). This also makes corporate IT happy, because
they want all employees to have Windows, Office, etc. etc.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture. And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein. --Gospel of Tux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/0f0b0930/attachment.htm>
From noel.hunt at gmail.com Mon Jul 5 11:33:46 2021
From: noel.hunt at gmail.com (Noel Hunt)
Date: Mon, 5 Jul 2021 11:33:46 +1000
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
Message-ID: <CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
> 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/e2b9c6e5/attachment.htm>
From cowan at ccil.org Mon Jul 5 12:36:46 2021
From: cowan at ccil.org (John Cowan)
Date: Sun, 4 Jul 2021 22:36:46 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <20210705002119.GL817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
Message-ID: <CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
On Sun, Jul 4, 2021 at 8:22 PM Larry McVoy <lm at mcvoy.com> wrote:
> We both love C, we are both disciplined enough to write
> maintainable/extendable code in C, it works for us. We really clicked
> over our love of C.
>
Are you really sure that all the C code the two of you have written in your
careers carefully avoids all 191 kinds of undefined behavior in C99 (the
number has grown since then)? Give me leave to doubt it.
Consider this example from an earlier version of the Linux kernel:
static void __devexit agnx_pci_remove (struct pci_dev *pdev)
{
struct ieee80211_hw *dev = pci_get_drvdata(pdev);
struct agnx_priv *priv = dev->priv;
if (!dev) return;
... do stuff using dev ...
}
The trouble here is that dev is used before it is checked for being a null
pointer. In Java, you'd have a NullPointerException. In C, "gcc -O2" will
make this analysis:
Case 1: dev == NULL. This is undefined behavior and the compiler has no
obligations.
Case 2: dev != NULL. Since dev can't be null (the compiler always assumes
the programmer did not intend to use UB), the check can be removed.
The result is that there is no check for NULL in either case, the compiler
is silent, and since this is the kernel, dereferencing NULL probably pwns
your system. So whereas things that were technically UB used to work more
or less as you'd expect them to, nowadays they work as *nobody* expects
them to.
This is the result of the three values of C programmers: (1) fast
execution, (2) fast compilation, (3) I lied; there is no (3). And as
optimizers get better and better, the number of UB-related disasters
increases. (The same is true for C++ compiler developers, except that they
sometimes prioritize (2) over (1) because benchmarks.)
> If I had infinite energy and money, I would fund a dialect of C that
> made it more useful.
See <https://blog.regehr.org/archives/1287>, about how an attempt to reduce
the amount of UB int C failed because nobody could agree with anybody else
on what changes to make.
> For all its faults, C++ is the closest to a modern language that sort
> of fits with what I want
>
C++, is it? C++2011 has 203 UBs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/b1bc62db/attachment.htm>
From clemc at ccc.com Mon Jul 5 12:38:00 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jul 2021 22:38:00 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
Message-ID: <CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
Noel. Pls check the TUHS archives and I think you will see sed does yet
exist in 6th edition when Joy wrote head in 1977. Certainly not yet at
UCB.
On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt <noel.hunt at gmail.com> wrote:
> > 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).
>
>> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/673a93b2/attachment.htm>
From imp at bsdimp.com Mon Jul 5 12:51:29 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Jul 2021 20:51:29 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
Message-ID: <CANCZdfozCGK8ymnU2j1Xt+TpbpbdRUaCmXoSvwP6sBiqsYzLCA@mail.gmail.com>
On Sun, Jul 4, 2021, 8:39 PM Clem Cole <clemc at ccc.com> wrote:
> Noel. Pls check the TUHS archives and I think you will see sed does yet
> exist in 6th edition when Joy wrote head in 1977. Certainly not yet at
> UCB.
>
V6 doesn't have sed.
Warner
On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt <noel.hunt at gmail.com> wrote:
>
>> > 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).
>>
>>> --
> Sent from a handheld expect more typos than usual
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/66705727/attachment.htm>
From cowan at ccil.org Mon Jul 5 12:53:10 2021
From: cowan at ccil.org (John Cowan)
Date: Sun, 4 Jul 2021 22:53:10 -0400
Subject: [TUHS] Binary log files
Message-ID: <CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg@mail.gmail.com>
As long ago as the 7th Edition, several binary log files were maintained:
the file generated by acct(2) (one record per process) and the utmp and
wtmp files (one record per login). Both of these are defined by structs in
.h files, so they are definitely not portable (int sizes, endianism, etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/9c2fdfc1/attachment.htm>
From rich.salz at gmail.com Mon Jul 5 12:59:22 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Sun, 4 Jul 2021 22:59:22 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
Message-ID: <CAFH29toRC1YRY95AGj0VAGGW0JZ6s_hWB+hh3wuj=xymXv2t-g@mail.gmail.com>
> Are you really sure that all the C code the two of you have written in
> your careers carefully avoids all 191 kinds of undefined behavior in C99
> (the number has grown since then)? Give me leave to doubt it.
>
> Consider this example from an earlier version of the Linux kernel:
>
> static void __devexit agnx_pci_remove (struct pci_dev *pdev)
>
Bogus argument. The Linux kernel is free to rely on specific compiler
behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/d12763e4/attachment.htm>
From clemc at ccc.com Mon Jul 5 13:01:13 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jul 2021 23:01:13 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
Message-ID: <CAC20D2NXUN03POGPBU=R-h4sZnu5D8VbQzfzw=+YyYJyNCW-vA@mail.gmail.com>
Dyslexic typo. Does NOT
On Sun, Jul 4, 2021 at 10:38 PM Clem Cole <clemc at ccc.com> wrote:
> Noel. Pls check the TUHS archives and I think you will see sed does yet
> exist in 6th edition when Joy wrote head in 1977. Certainly not yet at
> UCB.
>
> On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt <noel.hunt at gmail.com> wrote:
>
>> > 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).
>>
>>> --
> Sent from a handheld expect more typos than usual
>
--
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/d4cffd56/attachment.htm>
From clemc at ccc.com Mon Jul 5 13:03:43 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jul 2021 23:03:43 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CANCZdfozCGK8ymnU2j1Xt+TpbpbdRUaCmXoSvwP6sBiqsYzLCA@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
<CANCZdfozCGK8ymnU2j1Xt+TpbpbdRUaCmXoSvwP6sBiqsYzLCA@mail.gmail.com>
Message-ID: <CAC20D2NcYbm-zU0waKbmDv9FmbZ+PQJEif3VJrL7BF63H6Lj5g@mail.gmail.com>
Right. A dyslexic typo sorry doesn’t
That was my point. He needed a tool and didn’t have one so he wrote a
singular tool to solve the problem. We now consider that tool pretty much
standard equipment
On Sun, Jul 4, 2021 at 10:51 PM Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Sun, Jul 4, 2021, 8:39 PM Clem Cole <clemc at ccc.com> wrote:
>
>> Noel. Pls check the TUHS archives and I think you will see sed does yet
>> exist in 6th edition when Joy wrote head in 1977. Certainly not yet at
>> UCB.
>>
>
> V6 doesn't have sed.
>
> Warner
>
> On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt <noel.hunt at gmail.com> wrote:
>>
>>> > 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).
>>>
>>>> --
>> Sent from a handheld expect more typos than usual
>>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/7573482b/attachment.htm>
From bakul at iitbombay.org Mon Jul 5 13:41:45 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Sun, 4 Jul 2021 20:41:45 -0700
Subject: [TUHS] Dennis Ritchie's couch
In-Reply-To: <CAKr6gn2jwY+jdn6oH9p2VOWANgW90EVJBbCmG0D8KyAzVqwQhA@mail.gmail.com>
References: <CAKr6gn04yBeYORTn122=HaDVo1Bjc7U0yVUX55BGy+=BHAnO-Q@mail.gmail.com>
<C728300B-6E54-4C25-A160-C1392BE37469@iitbombay.org>
<424dde98-7a42-57e6-e13a-83c3e6ccc020@dotat.at>
<CAKr6gn2jwY+jdn6oH9p2VOWANgW90EVJBbCmG0D8KyAzVqwQhA@mail.gmail.com>
Message-ID: <1EA570C7-10FB-4E01-8D9C-4789F1F1840E@iitbombay.org>
> On Jul 4, 2021, at 4:40 PM, George Michaelson <ggm at algebras.org> wrote:
>
> I wasn't very good at making jokes at the best of times, but I thought
> the innate tabular nature of a yacc parser and the role of yyparse()
> and the syntax yacc is written in would have got us there.
The difference is that one can incorporate a precedence parser for expressions
in a recursive parser easily, without needing yacc by handcrafting the table.
-- Bakul
From lm at mcvoy.com Mon Jul 5 13:47:51 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 4 Jul 2021 20:47:51 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
Message-ID: <20210705034751.GU817@mcvoy.com>
On Sun, Jul 04, 2021 at 10:36:46PM -0400, John Cowan wrote:
> > We both love C, we are both disciplined enough to write
> > maintainable/extendable code in C, it works for us. We really clicked
> > over our love of C.
>
> Are you really sure that all the C code the two of you have written in your
> careers carefully avoids all 191 kinds of undefined behavior in C99 (the
> number has grown since then)? Give me leave to doubt it.
I'm sure there are all sorts of problems with C. Somehow we both never
encountered them.
My experience is that people come up with this or that, and they are
right, there is a there there, but Eric and I, he more than me, we just
wrote a ton of code in C, like 3-4 decades, all of that code works and
works better than the people who second guess us. Our code works.
I've been through coverity trying to tell us where the problems were,
they found none. I've been through Intel's fancy compiler that would
make things faster, it was a .1-.5%. I don't remember, it was nothing.
I'm good with my understanding of C. I get that you get it at a more
detailed level, go you. I get it at a more basic practical level and
that has served me well.
From bakul at iitbombay.org Mon Jul 5 13:52:11 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Sun, 4 Jul 2021 20:52:11 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
Message-ID: <5E27076F-0D98-4EE1-9484-618FE58B941C@iitbombay.org>
> On Jul 3, 2021, at 6:20 AM, Dan Cross <crossd at gmail.com> wrote:
>
> Systemd is both good and bad.
Independent of systemd, the idea of regularizing service management is quite useful. A single function in a way, & fits the Unix Philosophy [which is really about factoring out common components and making them easily reusable. The fact that the shell allows that sort of composition with minimal syntax is, to me, one of its greatest contributions]
Similarly there are other such new functions where this philosophy can be applied.
> We aren't teaching, yes, but moreover they don't want to learn because the problems they're trying to solve are different. We need to accept and internalize that and think hard about how the tools we use can be brought to bear on the problems that are relevant _now_, not 30 years ago.
>
> It does beg the question: is a Unix-style kernel still the appropriate foundation for this style of computing? Why are we still using this system: is it because of its intrinsic power and versatility, or because of inertia? Systemd, containers, etc, all suggest that our models are inadequate.
Containers, and many other tech. solutions have evolved in response to changing needs. The question that interests me is can we apply the Unix philosophy in this changing environment and if so how.
One thing I like about Apple is their continuous focus & s/w evolution on helping the end-user (we may disagree on specific changes but I bet many people on this list are using Apple devices as their "terminal"). It is a real joy to use some of these programs. And yet it is a real shame to not see open standards for such things.
From tytso at mit.edu Mon Jul 5 13:59:30 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Sun, 4 Jul 2021 23:59:30 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <e1744742-8751-14cf-9f46-837a28fec688@dotat.at>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<e1744742-8751-14cf-9f46-837a28fec688@dotat.at>
Message-ID: <YOKDovR8h8r1yoIP@mit.edu>
On Sun, Jul 04, 2021 at 09:10:49PM +0100, Tony Finch wrote:
> Dan Cross <crossd at gmail.com> wrote:
> >
> > Systemd is both good and bad.
>
> I thought this article was well-informed and informative, but VERY long:
> https://blog.darknedgy.net/technology/2020/05/02/0/
> "systemd, 10 years later: a historical and technical retrospective"
This is also a really good talk, by Benno Rice. Benno is a FreeBSD
developer, and has served on the FreeBSD Core Team. He gave this talk
at Linux.Conf.au 2019, and it was a repeat of a talk he gave at BSDCan
2018, entitled "The Tragedy of Systemd" ("Tragedy" in the title was
used in the Greek drama context):
https://www.youtube.com/watch?v=o_AIw9bGogo
It's a pretty fair talk about the why systemd came up, and what we
might be able to learn from systemd. His closing line was, which I
think is quite good was:
"What I would challenge every one here is to look at systemd, and
try find one thing you like --- and then go try to implement it."
- Ted
From drsalists at gmail.com Mon Jul 5 14:02:47 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 4 Jul 2021 21:02:47 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <20210705034751.GU817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
Message-ID: <CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
On Sun, Jul 4, 2021 at 8:49 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jul 04, 2021 at 10:36:46PM -0400, John Cowan wrote:
> > > We both love C, we are both disciplined enough to write
> > > maintainable/extendable code in C, it works for us. We really clicked
> > > over our love of C.
> >
> > Are you really sure that all the C code the two of you have written in
> your
> > careers carefully avoids all 191 kinds of undefined behavior in C99 (the
> > number has grown since then)? Give me leave to doubt it.
>
> I'm sure there are all sorts of problems with C. Somehow we both never
> encountered them.
>
Actually, haven't there been many security holes discovered in sendmail?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/968d688c/attachment.htm>
From drsalists at gmail.com Mon Jul 5 14:08:52 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 4 Jul 2021 21:08:52 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
Message-ID: <CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
On Sun, Jul 4, 2021 at 4:33 PM Derek Fawcus <
dfawcus+lists-tuhs at employees.org> wrote:
> On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
> > They also think that C is obsolete
>
> I'd not say it is obsolete, but despite it having been my main language
> for the
> last 30 years, these days I would be inclined to restrict the range of new
> tasks
> I'd use it for.
>
Me too - I write far fewer things in C today than I once did. Last time I
used C, it was for something that needed mlockall() and very minimalist OS
dependencies. And the client was in Python - only the server was in C.
I think Rust is probably the better language, even though Go is ahead of it
in the Tiobe language popularity rankings. Go is more like what most
people are accustomed to, but Rust is a genuine advancement in language
design that justifies "fighting the borrow checker".
On the other hand, I did a little comparison of Rust md5 (I know, it's
broken) implementations, and found them surprisingly slow. Slower than
CPython - though CPython is just linking to OpenSSL, and OpenSSL is
probably using hand-coded assembler, or at least highly optimized C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210704/efe7c7c1/attachment.htm>
From ggm at algebras.org Mon Jul 5 14:23:36 2021
From: ggm at algebras.org (George Michaelson)
Date: Mon, 5 Jul 2021 14:23:36 +1000
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
Message-ID: <CAKr6gn2XLDT7tQ80cU2vv72=WSvrwtfj3-0+hg9V+-NDkdgcEQ@mail.gmail.com>
Forgive me a side note, but has it not been shown for some time that
apart from a very gifted few people, hand-crafted machine-code is
usually slower than the best optimising compilers these days? With out
of order instruction stuff, side effects (inter-core locking) cache
coherency &c it isn't hard to wind up using "simpler" machine code
which performs worserer.
Doesn't really alter the language debate, but it does go to "compilers
are pretty smart these days"
From noel.hunt at gmail.com Mon Jul 5 15:22:47 2021
From: noel.hunt at gmail.com (Noel Hunt)
Date: Mon, 5 Jul 2021 15:22:47 +1000
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAC20D2P4f4uzQNR1+1a0oqX6wpVc-FtBeyKq6Qk47QkQeJiDsw@mail.gmail.com>
Message-ID: <CAGfO01yDS5KkgyOzfqYMvYmrb0wMnaoPcf5VKnyc5gVDRKOnqA@mail.gmail.com>
Thank you for the correction. Having only used Unix from Seventh
Edition on, research-editions only, I have never used head(1) and
didn't realize it was written so early.
On Mon, Jul 5, 2021 at 12:38 PM Clem Cole <clemc at ccc.com> wrote:
> Noel. Pls check the TUHS archives and I think you will see sed does yet
> exist in 6th edition when Joy wrote head in 1977. Certainly not yet at
> UCB.
>
> On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt <noel.hunt at gmail.com> wrote:
>
>> > 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).
>>
>>> --
> Sent from a handheld expect more typos than usual
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/bfe3873a/attachment.htm>
From rtomek at ceti.pl Mon Jul 5 17:14:50 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Mon, 5 Jul 2021 09:14:50 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
Message-ID: <20210705071450.GA12885@tau1.ceti.pl>
On Sun, Jul 04, 2021 at 08:48:23AM -0400, Dan Cross wrote:
[...]
> I didn't say that Unix is no longer relevant. I said that the problems that
> were prominent when Unix was built, and that thus shaped its architecture,
> are much _less_ relevant now than they were at the time. They still have
> some relevance, but are no longer primary for the vast majority of use
> cases Unix is used for. Further, the way people approach problems now has
> changed, even if they still generically assume "Unix" as the base they
> build on.
I have misread you then. I suppose the main problem that Unix solved
fifty years ago was the need for OS on a not very big (but cheap!)
machine. There were quite a few such systems and various such 16,
18-bit machines. So Unix was one of many, and what made it successful
was rewriting in C (I think I have read about it somewhere). Various
guys ported C compiler to their machines and to test it, they compiled
Unix sources (I am sure I have read about this). So as C gained
popularity, so did Unix gained popularity and C was the prog lang of
Unix, thus with every new Unix install C gained even more popularity.
So, looking from this perspective, maybe there was nothing
particularly special in Unix as such. It was just a double pump of
C-Unix, mutually pumping each other's success story.
I am not sure. I tried to find some time and install old OS on
simh/pdp11, yet there was always something more pressing to do. Some
alternatives to Unix, judging by their wikipedia descriptions, did not
convince me - like, one OS booted straight into debugger, if memory
serves. I do not think I would like that in everyday use. And after
reading about TECO, plenty of editors seem like better choice for me
:-).
Anyway, my own reasons to stick to Unix(-like) did not change. In
middle 1990-ties, after few years of playing with Amiga, and few years
of playing with SunOS/Solaris, it was clear to me what I wanted next
(Amiga was getting old rather quickly, as Commodore ran aground). The
OS was to be reliable, multitasking and if possible, cheap. If I was
to pay for something, it had to work, so Windows was ruled out. Later
on, as I hooked up to the net, security became important, too. Somehow
Linux on a 486 clone became a nice drop in replacement for Sunstation
and Solaris I used at the uni. I was able to run TeX on it, a
database, a program which abused database, an editor (Emacs, joe, vi)
with which I made the program and a compiler. All of this on eight
megs of ram. With "a bit" of swapping. That was terrific. To do same
thing on Windows, I imagined, at least Pentium and about 3x as much
ram was needed, plus a very expensive NT, because I did not expected
W95 could be relied upon.
If I still stick to Unix, it is because I still need something
dependable and allowing my various experiments or small time
developments. Windows somewhat improved during last twenty five years,
but not enough to pay for it - just MHO.
In other post you ask, why folks do not find Unix interesting
anymore. I still suggest they are following the money. They are the
kind of folk who never would find Unix interesting enough based on
merits only. Asking about their choices leads us nowwhere, because
their choices are not based on technical criteria.
What I would like to ask instead, is how many people had been using
Unix and decided to drop it, because it no longer worked for them. But
not because they had to earn for the living in a World of Windoze,
only because Unix tools stopped doing the job and could not be helped
with some handmade script or program. I guess reading more about such
users could tell something about Unix future or current relevance.
Also, reading about why people keep using Unix. Myself, I like doing
various things with computer. I create my own needs and then I write
small pieces of code to help myself out of the trap. Or something like
this. Nowadays, a lot of those needs revolve around learning and
organising notes. Of course I could not be using specialised note
taking program. Instead, I went with Emacs and org-mode. In the
process I had to learn a bit of Elisp and dot-emacs file. Some
defaults in Emacs are not comfy for my eyes - fonts, colors, it had to
be fine tuned to my liking.
So, I think my case could be summed up so: I need dependable software
and I have some needs which I know how to satisfy using this
software. If the software alone does not suit me, I can make some of
lacking elements myself and Unix allows me to join existing and new
elements easily.
I wonder if other Unix (ab)users share something with me? Like,
specialised single-person needs, or putting together building blocks
of command line tools, or preference for terminal based software
(because it works more often than not)? I guess yes.
What do people indifferent to Unix share with themselves, other than
general lack of interest, unwillingness to learn awk, disregard to
keeping information in text based, line oriented files?
HTH, sorry for long email, I tried to trim it but had to left
something too :-).
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From thomas.paulsen at firemail.de Mon Jul 5 22:11:37 2021
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Mon, 05 Jul 2021 14:11:37 +0200
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a
50-year view)
In-Reply-To: <20210705002119.GL817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<20210705002119.GL817@mcvoy.com>
Message-ID: <98a19c98961772cc5ce3e87f469978c8@firemail.de>
> So why invent a new syntax and invalidate all of that knowledge that everyone has?
I subscribe 100% to your statement!
Well I think it's enough to add new concepts like modules/packages/classes to C, and a jdk a-like all purposes library, as libc isn't enough for the 21ths century.
I still love C because I'm able of writing small and very fast programs. go is cool to, but a memory hunk compared to C. The rust hype is declining since 2 years and java is the new cobol, ie. it's good for business oriented applications, whereas C and go are (beside ASM) the only choices for system oriented people. Has C a future? Yes, it already has just begun.
From steffen at sdaoden.eu Mon Jul 5 23:41:59 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 15:41:59 +0200
Subject: [TUHS] Binary log files
In-Reply-To: <CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg@mail.gmail.com>
References: <CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg@mail.gmail.com>
Message-ID: <20210705134159.jR0uH%steffen@sdaoden.eu>
John Cowan wrote in
<CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg at mail.gmail.com>:
|As long ago as the 7th Edition, several binary log files were maintained:
|the file generated by acct(2) (one record per process) and the utmp and
|wtmp files (one record per login). Both of these are defined by structs in
|.h files, so they are definitely not portable (int sizes, endianism, etc.)
And how did you handle it?
On a very current GNU/Linux system these files grow indefinetely,
and sometimes you find several megabytes that track years of data,
and yourself writing (nonetheless quickshot) truncation code like
#?0|kent:~# less bin/truncate-wutmp.sh
#!/bin/sh -
#@ /root/bin/truncate-wutmp.sh
trap 'rm -f /tmp/.doit-${$}.*' EXIT
cat >/tmp/.doit-${$}.c <<'_EOT'
#include <utmp.h>
#include <stdio.h>
int main(){
printf("%lu\n", sizeof(struct utmp));
return 0;
}
_EOT
cc -o /tmp/.doit-${$}.exe /tmp/.doit-${$}.c || exit 1
i=$(/tmp/.doit-${$}.exe)
echo "struct utmp is ${i} bytes"
cd /var/log
s=$(stat -c '%s' wtmp)
[ ${?} -eq 0 ] || exit 2
echo "wtmp size is ${s} bytes"
ix=$((s / i))
echo "... that makes ${ix} utmp entries"
[ ${ix} -gt 42 ] || exit 3
ix=$((ix - 42))
dd if=wtmp of=wtmp.new bs=${i} skip=${ix} || exit 4
mv wmtp.new wtmp
chmod 0644 wtmp
# s-sh-mode
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From steffen at sdaoden.eu Mon Jul 5 23:45:22 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 15:45:22 +0200
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
Message-ID: <20210705134522.nzyIC%steffen@sdaoden.eu>
Dan Stromberg wrote in
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ at mail.gmail.com>:
|On Sun, Jul 4, 2021 at 8:49 PM Larry McVoy <lm at mcvoy.com> wrote:
|> On Sun, Jul 04, 2021 at 10:36:46PM -0400, John Cowan wrote:
|>>> We both love C, we are both disciplined enough to write
|>>> maintainable/extendable code in C, it works for us. We really clicked
|>>> over our love of C.
|>>
|>> Are you really sure that all the C code the two of you have written in
|> your
|>> careers carefully avoids all 191 kinds of undefined behavior in C99 (the
|>> number has grown since then)? Give me leave to doubt it.
|>
|> I'm sure there are all sorts of problems with C. Somehow we both never
|> encountered them.
|>
|
|Actually, haven't there been many security holes discovered in sendmail?
Even more actually that is a completely unfair statement.
sendmail grew out of other software that is way over 40 years as
of this writing, and to the best of my knowledge. It was not
written to face a vicious and hostile environment at first, even
the protocol it serves evolved over time, as anything else
surrounding it.
And then, what have the holes to do with the programming language?
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From lm at mcvoy.com Tue Jul 6 00:43:14 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Jul 2021 07:43:14 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAKr6gn2XLDT7tQ80cU2vv72=WSvrwtfj3-0+hg9V+-NDkdgcEQ@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
<CAKr6gn2XLDT7tQ80cU2vv72=WSvrwtfj3-0+hg9V+-NDkdgcEQ@mail.gmail.com>
Message-ID: <20210705144314.GV817@mcvoy.com>
On Mon, Jul 05, 2021 at 02:23:36PM +1000, George Michaelson wrote:
> Forgive me a side note, but has it not been shown for some time that
> apart from a very gifted few people, hand-crafted machine-code is
> usually slower than the best optimising compilers these days? With out
> of order instruction stuff, side effects (inter-core locking) cache
> coherency &c it isn't hard to wind up using "simpler" machine code
> which performs worserer.
I dunno where my team sat on the "gifted" scale, I like to think they
were pretty good. We ran our code through Intel's fancy C compiler and
it made less than a 1% difference vs GCC. We cared about performance
and had already done the by hand work to make the critical paths go fast.
From steffen at sdaoden.eu Tue Jul 6 01:08:54 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 17:08:54 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOKDovR8h8r1yoIP@mit.edu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<e1744742-8751-14cf-9f46-837a28fec688@dotat.at> <YOKDovR8h8r1yoIP@mit.edu>
Message-ID: <20210705150854.gtvCp%steffen@sdaoden.eu>
Theodore Ts'o wrote in
<YOKDovR8h8r1yoIP at mit.edu>:
|On Sun, Jul 04, 2021 at 09:10:49PM +0100, Tony Finch wrote:
|> Dan Cross <crossd at gmail.com> wrote:
|>>
|>> Systemd is both good and bad.
|>
|> I thought this article was well-informed and informative, but VERY long:
|> https://blog.darknedgy.net/technology/2020/05/02/0/
|> "systemd, 10 years later: a historical and technical retrospective"
|
|This is also a really good talk, by Benno Rice. Benno is a FreeBSD
|developer, and has served on the FreeBSD Core Team. He gave this talk
|at Linux.Conf.au 2019, and it was a repeat of a talk he gave at BSDCan
|2018, entitled "The Tragedy of Systemd" ("Tragedy" in the title was
|used in the Greek drama context):
|
| https://www.youtube.com/watch?v=o_AIw9bGogo
|
|It's a pretty fair talk about the why systemd came up, and what we
|might be able to learn from systemd. His closing line was, which I
|think is quite good was:
|
| "What I would challenge every one here is to look at systemd, and
| try find one thing you like --- and then go try to implement it."
Disclaimer: i .. have not .. seen this.
Everybody may use systemd until they die, my very personal concern
is only that the infrastructure boils down to be unusable without
it. Also as noone cares, just a few voices here and there, even
more so. Many small tools exist that can do things, but as
systemd grows they do not, they are not extended to follow suit
Linux kernel features.
I mean, i could hack instead of complaining, but as i use
unshare(1) not docker/systemd i find it unpleasant that i have to
use capsh(1) in addition for example instead of simply feeding
unshare(1) also with the capabilities. For systemd users this is
just a single line, and often programs come with readily prepared
unit files, take iwd for example
[Service]
Type=dbus
BusName=net.connman.iwd
ExecStart=@libexecdir@/iwd
[taken from source not installed base as not installed, no
systemd here.]
NotifyAccess=main
LimitNPROC=1
I have cgroups yes, but unshare(1) does not do that by itself.
So my shell script wrapper moves the PID by itself, which it is,
essentially.
Restart=on-failure
I have a cron based watchdog on the server. (Which never had to
trigger in >5 years of operation.) But yes...
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
Not unshare. I am about to add this via capsh(1).
PrivateTmp=true
So private tmp directories only via boxing into overlayfs views,
but not as it is done here.
NoNewPrivileges=true
Capabilities not yet.
Maybe one should go and write an unshare which can this too.
DevicePolicy=closed
DeviceAllow=/dev/rfkill rw
ProtectHome=yes
ProtectSystem=strict
ProtectControlGroups=yes
ProtectKernelModules=yes
You see systemd making touchdowns, and i mean it.
Because only it can. And i played football with my feet.
ConfigurationDirectory=iwd
StateDirectory=iwd
StateDirectoryMode=0700
Granted, all these tortured administrators have a life way easier
by using systemd and just adjusting the unit, if at all needed.
Easier to just browse and copy+paste.
I have to take back my iwd complaint about syslog. It is just
they did not bother at all. This Intel program uses the Intel
"ell" (Embedded Linux library), and whereas that offers
ell/log.c: * l_log_set_ident:
ell/log.c:LIB_EXPORT void l_log_set_ident(const char *ident)
ell/log.c: * l_log_set_handler:
ell/log.c:LIB_EXPORT void l_log_set_handler(l_log_func_t function)
ell/log.c: * l_log_set_null:
ell/log.c:LIB_EXPORT void l_log_set_null(void)
ell/log.c: * l_log_set_stderr:
ell/log.c:LIB_EXPORT void l_log_set_stderr(void)
ell/log.c: * l_log_set_syslog:
ell/log.c:LIB_EXPORT void l_log_set_syslog(void)
ell/log.c: * l_log_set_journal:
ell/log.c:LIB_EXPORT void l_log_set_journal(void)
ell/test.c: l_log_set_stderr();
ell/log.h:void l_log_set_ident(const char *ident);
ell/log.h:void l_log_set_handler(l_log_func_t function);
ell/log.h:void l_log_set_null(void);
ell/log.h:void l_log_set_stderr(void);
ell/log.h:void l_log_set_syslog(void);
ell/log.h:void l_log_set_journal(void);
they use
#?0|kent:iwd-1.15$ grep -r l_log_set
tools/hwsim.c: l_log_set_stderr();
tools/probe-req.c: l_log_set_stderr();
client/main.c: l_log_set_stderr();
src/main.c: l_log_set_stderr();
wired/main.c: l_log_set_stderr();
One could at least be happy they did not fixate "journal", maybe.
Anyhow, the actual error output is for developers only.
Bitrot everywhere. So just jump on the train that delivers and
pass the rest.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From cowan at ccil.org Tue Jul 6 01:12:05 2021
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 Jul 2021 11:12:05 -0400
Subject: [TUHS] Binary log files
In-Reply-To: <20210705134159.jR0uH%steffen@sdaoden.eu>
References: <CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg@mail.gmail.com>
<20210705134159.jR0uH%steffen@sdaoden.eu>
Message-ID: <CAD2gp_RLYVFx8CK6PAiSrPV8BvSrYHGiB2WPxQGJO=Bh-x3nRA@mail.gmail.com>
On Mon, Jul 5, 2021 at 9:42 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
And how did you handle it?
>
The simplest way to truncate the file is with truncate or just ">file",
since writes are small enough to be atomic. The sa utility, which also
goes back to v7, will summarize process accounting data and write it to a
different file; it can then report on either unsummarized data or
summarized data before unsummarized data). Unfortunately Linux has broken
the wtmp/utmp convention of "no logfile, no logging", so a cron job to
truncate wtmp is your only man.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward
one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk
to
lose support instead of finding it when you threat with the charged weapon."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/6b3b7298/attachment.htm>
From steffen at sdaoden.eu Tue Jul 6 01:17:32 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 17:17:32 +0200
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <20210705144314.GV817@mcvoy.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
<CAKr6gn2XLDT7tQ80cU2vv72=WSvrwtfj3-0+hg9V+-NDkdgcEQ@mail.gmail.com>
<20210705144314.GV817@mcvoy.com>
Message-ID: <20210705151732.6PbNl%steffen@sdaoden.eu>
Larry McVoy wrote in
<20210705144314.GV817 at mcvoy.com>:
|On Mon, Jul 05, 2021 at 02:23:36PM +1000, George Michaelson wrote:
|> Forgive me a side note, but has it not been shown for some time that
|> apart from a very gifted few people, hand-crafted machine-code is
|> usually slower than the best optimising compilers these days? With out
Some *BSDs moved from such to plain C code for strlen() for
example, a couple of years back, yes.
|> of order instruction stuff, side effects (inter-core locking) cache
|> coherency &c it isn't hard to wind up using "simpler" machine code
|> which performs worserer.
|
|I dunno where my team sat on the "gifted" scale, I like to think they
|were pretty good. We ran our code through Intel's fancy C compiler and
|it made less than a 1% difference vs GCC. We cared about performance
|and had already done the by hand work to make the critical paths go fast.
Funnily just a couple of months ago at least FreeBSD (but i think
also DragonFly BSD, a tad different) moved back, on at least
x86_64.
(I personally no longer look nor care that much, as (a) i cannot
help it anyway, (b) there are so many CPU etc. models out there.
Why try to go backward because Cyrix is so good there, use code
alignment of X for processor A and Y for processor B? That is
just a tremendous maintenance mess, and that for free and with so
few time. No. Fun fact is that my one NVME disc can read/write
1.3 gigabytes per second doing "btrfs scrub", that is i think at
least four times the speed of the main memory the mentioned Cyrix
had available.)
--End of <20210705144314.GV817 at mcvoy.com>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From steffen at sdaoden.eu Tue Jul 6 01:36:10 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 17:36:10 +0200
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <20210705151732.6PbNl%steffen@sdaoden.eu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<CAGGBd_qkpq9Bt6_zsKmPASunGJd-YJyYeQnPGeTn2vcf6WW9bw@mail.gmail.com>
<CAKr6gn2XLDT7tQ80cU2vv72=WSvrwtfj3-0+hg9V+-NDkdgcEQ@mail.gmail.com>
<20210705144314.GV817@mcvoy.com> <20210705151732.6PbNl%steffen@sdaoden.eu>
Message-ID: <20210705153610.ONXXl%steffen@sdaoden.eu>
Steffen Nurpmeso wrote in
<20210705151732.6PbNl%steffen at sdaoden.eu>:
|Larry McVoy wrote in
| <20210705144314.GV817 at mcvoy.com>:
Just to mention that i did address Larry McVoy, no, as can be seen
in the Mail-Followup-To: header. I do not know why this Python
program removes him from Cc: just because it strips his name from
its actual to-be-send-to list, likely to "avoid duplicates" or
something, what i think what happens here. Very unkind. Not me.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From mike.ab3ap at gmail.com Tue Jul 6 01:53:11 2021
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Mon, 5 Jul 2021 11:53:11 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
Message-ID: <1fcac3f8-174a-9485-3246-f2e3f3701ccf@gmail.com>
On 7/4/21 7:24 PM, Derek Fawcus wrote:
> On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
>> They also think that C is obsolete
>
> I'd not say it is obsolete, but despite it having been my main
> language for the last 30 years, these days I would be inclined to
> restrict the range of new tasks I'd use it for.
Hoping to correctly recall computability theory, a language needs only
statements
S := 0
S := S + 1
if S == 0 goto Label
to be Turing complete. It doesn't mean the language is always pleasant
to use, but is enough - just as an editor with only char ins/del is
technically enough. C has its place, and so do tools for other classes
of problems.
I enjoy python for signal processing work. Matrices, complex numbers,
many libraries are all there. Libraries even parcel out calcs to cpu
cores behind the scenes, letting the DSP guy worry (mostly) only about
math. And then C is speedy for the end product. As comp sci evolves,
we get more blades in our Swiss Army knife.
Mike Markowski
From cowan at ccil.org Tue Jul 6 02:26:04 2021
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 Jul 2021 12:26:04 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210705071450.GA12885@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
Message-ID: <CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
On Mon, Jul 5, 2021 at 3:15 AM Tomasz Rola <rtomek at ceti.pl> wrote:
> So, looking from this perspective, maybe there was nothing
> particularly special in Unix as such. It was just a double pump of
> C-Unix, mutually pumping each other's success story.
>
I think there is more to it than that. See <
http://www.catb.org/~esr/writings/unix-koans/zealot.html>.
I am not sure. I tried to find some time and install old OS on
> simh/pdp11, yet there was always something more pressing to do. Some
> alternatives to Unix, judging by their wikipedia descriptions, did not
> convince me - like, one OS booted straight into debugger, if memory
> serves.
ITS, yes. But the debugger was not just a debugger, it was also a general
command-line interpreter, a shell in modern terms. So while it is possible
to debug an empty memory into doing whatever you want, it is also possible
to run "advent", aka Colossal Cave Adventure.
> And after
> reading about TECO, plenty of editors seem like better choice for me
> :-).
>
I switched from Teco to ex at some point, and never went either forward or
back. (Occasionally I drop into vi mode for things like parenthesis
checking.)
By the way, did anyone else start out on Unix-alikes before using actual
Unix? I read the BSTJ issue and became an instant convert, but only when
$EMPLOYER got a MicroVAX was I able to work like that. Next came the MKS
Toolkit on DOS, and then Cygwin for many years. I suppose it's only my
last two $EMPLOYERs standardizing on the Mac that has left me running,
like, actual Unix.
If I still stick to Unix, it is because I still need something
> dependable and allowing my various experiments or small time
> developments.
>
"Computers are the greatest set of electric trains in the world."
> I still suggest they are following the money. They are the
> kind of folk who never would find Unix interesting enough based on
> merits only. Asking about their choices leads us nowwhere, because
> their choices are not based on technical criteria.
>
True. But then, many of us geeks make our choices not on technical
criteria but on tribal loyalty. Which is *technically* superior, vi or
emacs? (Please don't answer that.)
> Of course I could not be using specialised note
> taking program. Instead, I went with Emacs and org-mode. In the
> process I had to learn a bit of Elisp and dot-emacs file. Some
> defaults in Emacs are not comfy for my eyes - fonts, colors, it had to
> be fine tuned to my liking.
>
Note that Emacs is probably the oldest import into the Unix ecosystem from
outside, and it bears the marks of its origin: monolithic (but
programmable), one tool does it all.
> I wonder if other Unix (ab)users share something with me? Like,
> specialised single-person needs, or putting together building blocks
> of command line tools, or preference for terminal based software
> (because it works more often than not)?
>
Without doubt. I am not loyal to a kernel or a set of utilities, I simply
follow the Way of Unix: <http://vrici.lojban.org/~cowan/upc/> (sadly
incomplete)
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
"Hacking is the true football." --F.W. Campbell (1863) in response to a
successful attempt to ban shin-kicking from soccer. Today, it's biting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/a1691dfe/attachment.htm>
From imp at bsdimp.com Tue Jul 6 02:39:35 2021
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 5 Jul 2021 10:39:35 -0600
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <YOJDIn6Hj01Hnwp3@clarinet.employees.org>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
Message-ID: <CANCZdfoqOzejXFxMz9OLKPTYKBy5TvrToN9zpJKUp0-DA69qqw@mail.gmail.com>
On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
> > They also think that C is obsolete
>
Hammers are not obsolete because we have screws, even though they
are mostly useless with screws. There's plenty of nails out there.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/4494d3f6/attachment.htm>
From clemc at ccc.com Tue Jul 6 05:02:14 2021
From: clemc at ccc.com (Clem Cole)
Date: Mon, 5 Jul 2021 15:02:14 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CANCZdfoqOzejXFxMz9OLKPTYKBy5TvrToN9zpJKUp0-DA69qqw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<CANCZdfoqOzejXFxMz9OLKPTYKBy5TvrToN9zpJKUp0-DA69qqw@mail.gmail.com>
Message-ID: <CAC20D2PpMYopU2Qu+yw=G_XxVgvfexXrQSKLy3tO_YMUN6sTEA@mail.gmail.com>
On Mon, Jul 5, 2021 at 12:40 PM Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Sat, Jul 03, 2021 at 05:49:57PM +0200, Andy Kosela wrote:
>> > They also think that C is obsolete
>>
>
> Hammers are not obsolete because we have screws, even though they
> are mostly useless with screws. There's plenty of nails out there.
>
Amen...
FWIW: I wrote this a few years ago:
https://www.quora.com/Is-Fortran-obsolete/answer/Clem-Cole
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/8217acf9/attachment.htm>
From steffen at sdaoden.eu Tue Jul 6 05:25:37 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 05 Jul 2021 21:25:37 +0200
Subject: [TUHS] Binary log files
In-Reply-To: <CAD2gp_RLYVFx8CK6PAiSrPV8BvSrYHGiB2WPxQGJO=Bh-x3nRA@mail.gmail.com>
References: <CAD2gp_SXHQSauT_VibXPvP6PWrFULiMFYkvfs5=YxjHYbHGPwg@mail.gmail.com>
<20210705134159.jR0uH%steffen@sdaoden.eu>
<CAD2gp_RLYVFx8CK6PAiSrPV8BvSrYHGiB2WPxQGJO=Bh-x3nRA@mail.gmail.com>
Message-ID: <20210705192537.oT7gj%steffen@sdaoden.eu>
John Cowan wrote in
<CAD2gp_RLYVFx8CK6PAiSrPV8BvSrYHGiB2WPxQGJO=Bh-x3nRA at mail.gmail.com>:
|On Mon, Jul 5, 2021 at 9:42 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
|
|And how did you handle it?
|
|The simplest way to truncate the file is with truncate or just ">file",
|since writes are small enough to be atomic. The sa utility, which also
Hm, ok, sure. I thought maybe, you know. Availability of some
weeks or the quarter of a year is a good thing (tm).
|goes back to v7, will summarize process accounting data and write it to a
|different file; it can then report on either unsummarized data or
|summarized data before unsummarized data). Unfortunately Linux has broken
|the wtmp/utmp convention of "no logfile, no logging", so a cron job to
|truncate wtmp is your only man.
Too bad weather to make something out of that.
The fruits of South Africa were so sweet that we hoped for a good
summer. Well 2000 KM more southern it is, but that Island low
pressure area now lies in front of Ireland i think, what a mess.
Yes the script is not atomic, but good enough for very occasional
usage by a logged in administrator.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From drsalists at gmail.com Tue Jul 6 06:15:10 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Mon, 5 Jul 2021 13:15:10 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <20210705134522.nzyIC%steffen@sdaoden.eu>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
Message-ID: <CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
On Mon, Jul 5, 2021 at 6:45 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> And then, what have the holes to do with the programming language?
>
> Really?
A null-terminated array of char is a petri dish. A proper string type is
more like a disinfectant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/7d3d7d93/attachment.htm>
From norman at oclsc.org Tue Jul 6 06:26:12 2021
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 5 Jul 2021 16:26:12 -0400 (EDT)
Subject: [TUHS] Binary log files
Message-ID: <20210705202612.BF641640CC6@lignose.oclsc.org>
Some of us have, literally for decades, been dealing with
wtmp by rolling it weekly or monthly or quarterly or whatever,
letting cron run something like
cd /usr/adm # that's how long I've been doing this!
umask 022
>wtmp.new
ln wtmp wtmp.prev
mv wtmp.new wtmp
# also so long ago there was no seq(1)
nums=`awk 'BEGIN {for (i = 12; i >= 0; i--) print i; exit}'`
for i in $nums; do
inext=`expr $i + 1`
if [ -f wtmp.$i ]; then
mv wtmp.$i wtmp.$inext
fi
done
mv wtmp.prev wtmp.0
This really isn't rocket science. It isn't even particularly
interesting UNIX history. Can we move on to something that IS
interesting?
Here are some things I find more interesting:
1. utmp came before wtmp: utmp(V) appears in the First Edition
manual, wtmp(V) only in the Second. Apparently interest in
who else is logged in right now predated interest in who has
logged in recently.
2. Both files started out in /tmp. wtmp is first said to be
in /usr/adm instead in the Fifth Edition manual, utmp in /etc
in the Sixth.
3. The names /tmp/utmp and /tmp/wtmp appear to have been
issued by the Department of Redundancy Department. I think
it quite likely that Ken and Dennis would have been familiar
with that joke once the recording containing it was issued
in mid-1970, but I don't know whether utmp existed in some
form before that. I see no sign of it in the fragments of
PDP-7 source code we have (in particular init doesn't seem
to use it), but what about later PDP-7 or very early PDP-11
code predating the late-1971 First Edition manual?
Norman Wilson
Toronto ON
Not Insane
From lm at mcvoy.com Tue Jul 6 07:05:23 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Jul 2021 14:05:23 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org>
<20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
Message-ID: <20210705210523.GG26121@mcvoy.com>
On Mon, Jul 05, 2021 at 01:15:10PM -0700, Dan Stromberg wrote:
> On Mon, Jul 5, 2021 at 6:45 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>
> > And then, what have the holes to do with the programming language?
> >
> > Really?
>
> A null-terminated array of char is a petri dish. A proper string type is
> more like a disinfectant.
I'd really like it if C got a proper everything type. Some container
type that lets you have arrays of anything and the run time system does
the realloc when you extend the container. We built such a thing in
BitKeeper but it was awkward, any sort of modification was
thing = modifies(thing, args...);
because the modification might realloc().
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From clemc at ccc.com Tue Jul 6 07:29:02 2021
From: clemc at ccc.com (Clem Cole)
Date: Mon, 5 Jul 2021 17:29:02 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
Message-ID: <CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists at gmail.com> wrote:
> A null-terminated array of char is a petri dish. A proper string type is
> more like a disinfectant.
>
Hrrmpt.... maybe (in theory), but I can say that never seen it really work
in practice -- bwk in Why Pascal is Not My Favorite Programming Language
<http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much of the
practical realities of this sort of choice:
2.1. The size of an array is part of its typeIf one declares
var arr10 : array [1..10] of integer;
arr20 : array [1..20] of integer;
then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose
we want to write a procedure 'sort' to sort an integer array. Because
arr10 and arr20 have different types, it is not possible to write a single
procedure that will sort them both.
The place where this affects Software Tools particularly, and I think
programs in general, is that it makes it difficult indeed to create a
library of routines for doing common, general-purpose operations like
sorting.
The particular data type most often affected is 'array of char', for in
Pascal a string is an array of characters. Consider writing a function
'index(s,c)' that will return the position in the string s where the
character c first occurs, or zero if it does not. The problem is how to
handle the string argument of 'index'. The calls 'index('hello',c)' and '
index('goodbye',c)' cannot both be legal, since the strings have different
lengths. (I pass over the question of how the end of a constant string
like 'hello' can be detected, because it can't.) The next try is
var temp : array [1..10] of char;
temp := 'hello';
n := index(temp,c);
but the assignment to 'temp' is illegal because 'hello' and 'temp' are of
different lengths.
The only escape from this infinite regress is to define a family of
routines with a member for each possible string size, or to make all
strings (including constant strings like 'define' ) of the same length.
The latter approach is the lesser of two great evils. In 'Tools', a type
called 'string' is declared as
type string = array [1..MAXSTR] of char;
where the constant 'MAXSTR' is ``big enough,'' and all strings in all
programs are exactly this size. This is far from ideal, although it made
it possible to get the programs running. It does not solve the problem of
creating true libraries of useful routines.
There are some situations where it is simply not acceptable to use the
fixed-size array representation. For example, the 'Tools' program to sort
lines of text operates by filling up memory with as many lines as will fit;
its running time depends strongly on how full the memory can be packed.
Thus for 'sort', another representation is used, a long array of characters
and a set of indices into this array:
type charbuf = array [1..MAXBUF] of char;
charindex = array [1..MAXINDEX] of 0..MAXBUF;
But the procedures and functions written to process the fixed-length
representation cannot be used with the variable-length form; an entirely
new set of routines is needed to copy and compare strings in this
representation. In Fortran or C the same functions could be used for both.
As suggested above, a constant string is written as
'this is a string'
and has the type 'packed array [1..n] of char', where n is the length. Thus
each string literal of different length has a different type. The only way
to write a routine that will print a message and clean up is to pad all
messages out to the same maximum length:
error('short message ');
error('this is a somewhat longer message');
Many commercial Pascal compilers provide a 'string' data type that
explicitly avoids the problem; 'string's are all taken to be the same type
regardless of size. This solves the problem for this single data type, but
no other. It also fails to solve secondary problems like computing the
length of a constant string; another built-in function is the usual
solution.
Pascal enthusiasts often claim that to cope with the array-size problem one
merely has to copy some library routine and fill in the parameters for the
program at hand, but the defense sounds weak at best:(12
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-12>)
``Since the bounds of an array are part of its type (or, more exactly, of
the type of its indexes), it is impossible to define a procedure or
function which applies to arrays with differing bounds. Although this
restriction may appear to be a severe one, the experiences we have had with
Pascal tend to show that it tends to occur very infrequently. [...]
However, the need to bind the size of parametric arrays is a serious defect
in connection with the use of program libraries.''
This botch is the biggest single problem with Pascal. I believe that if it
could be fixed, the language would be an order of magnitude more usable. The
proposed ISO standard for Pascal(13
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-13>) provides such a
fix (``conformant array schemas''), but the acceptance of this part of the
standard is apparently still in doubt.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/4e320bb2/attachment-0001.htm>
From brantley at coraid.com Tue Jul 6 08:22:00 2021
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 5 Jul 2021 22:22:00 +0000
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
<CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
Message-ID: <833CC07E-EB6C-4385-A4D1-63AFEDDDB69A@coraid.com>
Wirth fixed it in Modula-2 and Oberon.
> On Jul 5, 2021, at 5:29 PM, Clem Cole <clemc at ccc.com> wrote:
>
>
>
> On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists at gmail.com> wrote:
> A null-terminated array of char is a petri dish. A proper string type is more like a disinfectant.
> Hrrmpt.... maybe (in theory), but I can say that never seen it really work in practice -- bwk in Why Pascal is Not My Favorite Programming Language describes much of the practical realities of this sort of choice:
>
> 2.1. The size of an array is part of its type
>
> If one declares
> var arr10 : array [1..10] of integer;
> arr20 : array [1..20] of integer;
>
> then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.
> The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting.
>
> The particular data type most often affected is 'array of char', for in Pascal a string is an array of characters. Consider writing a function 'index(s,c)' that will return the position in the string s where the character c first occurs, or zero if it does not. The problem is how to handle the string argument of 'index'. The calls 'index('hello',c)' and 'index('goodbye',c)' cannot both be legal, since the strings have different lengths. (I pass over the question of how the end of a constant string like 'hello' can be detected, because it can't.) The next try is
>
> var temp : array [1..10] of char;
> temp := 'hello';
>
> n := index(temp,c);
>
> but the assignment to 'temp' is illegal because 'hello' and 'temp' are of different lengths.
> The only escape from this infinite regress is to define a family of routines with a member for each possible string size, or to make all strings (including constant strings like 'define' ) of the same length.
>
> The latter approach is the lesser of two great evils. In 'Tools', a type called 'string' is declared as
>
> type string = array [1..MAXSTR] of char;
>
> where the constant 'MAXSTR' is ``big enough,'' and all strings in all programs are exactly this size. This is far from ideal, although it made it possible to get the programs running. It does not solve the problem of creating true libraries of useful routines.
> There are some situations where it is simply not acceptable to use the fixed-size array representation. For example, the 'Tools' program to sort lines of text operates by filling up memory with as many lines as will fit; its running time depends strongly on how full the memory can be packed.
>
> Thus for 'sort', another representation is used, a long array of characters and a set of indices into this array:
>
> type charbuf = array [1..MAXBUF] of char;
> charindex = array [1..MAXINDEX] of 0..MAXBUF;
>
> But the procedures and functions written to process the fixed-length representation cannot be used with the variable-length form; an entirely new set of routines is needed to copy and compare strings in this representation. In Fortran or C the same functions could be used for both.
> As suggested above, a constant string is written as
>
> 'this is a string'
>
> and has the type 'packed array [1..n] of char', where n is the length. Thus each string literal of different length has a different type. The only way to write a routine that will print a message and clean up is to pad all messages out to the same maximum length:
> error('short message ');
> error('this is a somewhat longer message');
>
> Many commercial Pascal compilers provide a 'string' data type that explicitly avoids the problem; 'string's are all taken to be the same type regardless of size. This solves the problem for this single data type, but no other. It also fails to solve secondary problems like computing the length of a constant string; another built-in function is the usual solution.
> Pascal enthusiasts often claim that to cope with the array-size problem one merely has to copy some library routine and fill in the parameters for the program at hand, but the defense sounds weak at best:(12)
>
> ``Since the bounds of an array are part of its type (or, more exactly, of the type of its indexes), it is impossible to define a procedure or function which applies to arrays with differing bounds. Although this restriction may appear to be a severe one, the experiences we have had with Pascal tend to show that it tends to occur very infrequently. [...] However, the need to bind the size of parametric arrays is a serious defect in connection with the use of program libraries.''
> This botch is the biggest single problem with Pascal. I believe that if it could be fixed, the language would be an order of magnitude more usable. The proposed ISO standard for Pascal(13) provides such a fix (``conformant array schemas''), but the acceptance of this part of the standard is apparently still in doubt.
> бђ§
From drsalists at gmail.com Tue Jul 6 14:35:31 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Mon, 5 Jul 2021 21:35:31 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
<CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
Message-ID: <CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
On Mon, Jul 5, 2021 at 2:29 PM Clem Cole <clemc at ccc.com> wrote:
>
> On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists at gmail.com> wrote:
>
>> A null-terminated array of char is a petri dish. A proper string type is
>> more like a disinfectant.
>>
> Hrrmpt.... maybe (in theory), but I can say that never seen it really work
> in practice -- bwk in Why Pascal is Not My Favorite Programming Language
> <http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much of the
> practical realities of this sort of choice:
>
I think language designers since Pascal have learned from Pascal's mistake
there.
Supposedly even Borland's TurboPascal had better strings than vanilla
Pascal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/1792befe/attachment.htm>
From imp at bsdimp.com Tue Jul 6 14:44:29 2021
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 5 Jul 2021 22:44:29 -0600
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
<CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
<CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
Message-ID: <CANCZdfpAijUCpTegnBwaU69XX+SDf67PVeeM6McJHZkYMjm5Tw@mail.gmail.com>
On Mon, Jul 5, 2021, 10:37 PM Dan Stromberg <drsalists at gmail.com> wrote:
>
> On Mon, Jul 5, 2021 at 2:29 PM Clem Cole <clemc at ccc.com> wrote:
>
>>
>> On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists at gmail.com> wrote:
>>
>>> A null-terminated array of char is a petri dish. A proper string type
>>> is more like a disinfectant.
>>>
>> Hrrmpt.... maybe (in theory), but I can say that never seen it really
>> work in practice -- bwk in Why Pascal is Not My Favorite Programming
>> Language <http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much
>> of the practical realities of this sort of choice:
>>
>
> I think language designers since Pascal have learned from Pascal's mistake
> there.
>
> Supposedly even Borland's TurboPascal had better strings than vanilla
> Pascal.
>
That's true. You could do things in Turbo Pascal you couldn't do in
standard Pascals. It was close enough to C that a lot of system level code
was written in it. A bit verbose, but serviceable.
Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/b42c6591/attachment.htm>
From nevin at eviloverlord.com Tue Jul 6 15:10:56 2021
From: nevin at eviloverlord.com (Nevin Liber)
Date: Tue, 6 Jul 2021 00:10:56 -0500
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
Message-ID: <CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
>
>
> 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 at eviloverlord.com> +1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/a5340db5/attachment.htm>
From rp at servium.ch Tue Jul 6 15:58:27 2021
From: rp at servium.ch (Rico Pajarola)
Date: Mon, 5 Jul 2021 22:58:27 -0700
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
<CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
<CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
Message-ID: <CACwAiQnU8eLHOqmgC=OtVRatZnF9xrn67Bz55dax7xcRfr9oag@mail.gmail.com>
On Mon, Jul 5, 2021 at 9:37 PM Dan Stromberg <drsalists at gmail.com> wrote:
> Supposedly even Borland's TurboPascal had better strings than vanilla
> Pascal.
>
and then they used only 1 byte for the string length, limiting the max
length to 255, which made it completely pointless, because the moment you
had some real world data, you were back in
manage-my-own-pointers-to-arrays-of-chars-land.
(I loved Turbo Pascal, it's the first language I used for "serious"
programming. They got a lot of things right, but strings were emphatically
not among those things).
My other gripe was that Turbo Pascal programs spend half their time on
pointer normalization (every pointer access has a preamble that makes sure
that the offset is < 16). I'd really love to understand why on earth they
decided to do it that way (I'm sure there's a reason, I just fail to see
it). It's not like anyone could do pointer arithmetic behind the compiler's
back... it slows things down, and it's probably the reason why an
equivalent Turbo C program is only half the code size. And it makes it
impossible to do clever things with segment registers (18 year old me
didn't like that).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210705/922ed156/attachment.htm>
From Caipenghui_c at 163.com Tue Jul 6 22:18:56 2021
From: Caipenghui_c at 163.com (Caipenghui)
Date: Tue, 06 Jul 2021 20:18:56 +0800
Subject: [TUHS] Good News:
Message-ID: <9C45EDC5-744F-40B9-88F7-6A49DEEB3FDD@163.com>
UNIX history memoir has been published in China (publish by posts and Telecommunications Press in China) and translated into Chinese. It is also called name "UNIX legend" in China. I'm going to buy now.
If you're in the computer industry, it's exciting just to understand how these buzzwords came into being. Even if you don't have a deep technical background,
You can also benefit a lot from these ides that shine with genius.
I have been looking forward to a Chinese book about the history of Unix development for so many years, and now I can finally see it.
Thanks bwk and other guys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/36aa3902/attachment.htm>
From clemc at ccc.com Tue Jul 6 23:05:19 2021
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jul 2021 09:05:19 -0400
Subject: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year
view)
In-Reply-To: <CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CALMnNGgsfTeTnyFEQoPmRseXJ1URfRhMVr1uSrnbkZZ-V1P3Jw@mail.gmail.com>
<YOJDIn6Hj01Hnwp3@clarinet.employees.org> <20210705002119.GL817@mcvoy.com>
<CAD2gp_TEVk_-W72ZYJARq-WOPe1oR6xGmO9_JOCRsfJwaneLPA@mail.gmail.com>
<20210705034751.GU817@mcvoy.com>
<CAGGBd_o=_LhF8FtxNF+VrC6TTN6mKZMx3Li4-TCA8qiK45BPBQ@mail.gmail.com>
<20210705134522.nzyIC%steffen@sdaoden.eu>
<CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>
<CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com>
<CAGGBd_oZ7xVzRCD9aNzxU4v+tC5Lw2Ze=UmPE4Dv1zHE5nadbg@mail.gmail.com>
Message-ID: <CAC20D2OGnC_wP-aW=3iu7yYhMpQf0XvMy9jyrV-ZOjHM5xwr8A@mail.gmail.com>
Exactly my point - *theory vs practice*. It can be a petri dish, but that
is *not necessarily* a bad thing. Different extended Pascal/Mod-2* et al *all
'fixed' the string data type in some manner (not even saying the
different solutions are good or bad). But it always comes back to what was
(*is*) theory *vs*. practice. As others have pointed out. In the case of
Strings, you either made them more like C strings or you made them
basically useless - because, in practice, the null-terminated string works
pretty darned well for production code and can be made to be secure, but
the programmer can not be lazy.
Hey, I personally look like Pascal for what it is and I still think it's
the best teaching tool, particularly with Clancy and Cooper's book for
beginning programmers. I personally learned both languages around the same
time, but I had already been writing in a number of assemblers, BASIC,
Fortran, Algol-W, SAIL, and BLISS before I saw either. I've more written
way more C code than any other language --- why because it works and as a
professional, I know how to properly use it.
As bwk says in that same document which I pointed to earlier, "comparing C
and Pascal is the same as trying to compare a jetfighter with a Piper
Cub." As my former Marine pilot B-I-L reminds me, he did not start pilot
training in Whidbey Island on jets - he worked his way up and showed he was
competent before the Navy made it easier for him to kill himself (and those
around him). BTW: the Navy does not tend to try to land small prop planes
on the USS Kennedy either. As my B-I-L says for all of his day and night
landings on same, he always somewhat scared the cr*p out him but he was
always careful to remember what he had been taught (and he says he never
had to use the 3 wire).
The bottom line becomes learning to pick and then using the proper tool for
the job and respect what is for and the constraints associated with using
it.
Clem
бђ§
On Tue, Jul 6, 2021 at 12:35 AM Dan Stromberg <drsalists at gmail.com> wrote:
>
> On Mon, Jul 5, 2021 at 2:29 PM Clem Cole <clemc at ccc.com> wrote:
>
>>
>> On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists at gmail.com> wrote:
>>
>>> A null-terminated array of char is a petri dish. A proper string type
>>> is more like a disinfectant.
>>>
>> Hrrmpt.... maybe (in theory), but I can say that never seen it really
>> work in practice -- bwk in Why Pascal is Not My Favorite Programming
>> Language <http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much
>> of the practical realities of this sort of choice:
>>
>
> I think language designers since Pascal have learned from Pascal's mistake
> there.
>
> Supposedly even Borland's TurboPascal had better strings than vanilla
> Pascal.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/a49ad9dc/attachment.htm>
From clemc at ccc.com Tue Jul 6 23:30:31 2021
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jul 2021 09:30:31 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
Message-ID: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
On Tue, Jul 6, 2021 at 1:13 AM Nevin Liber <nevin at 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.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/d7b839a9/attachment.htm>
From cowan at ccil.org Tue Jul 6 23:40:30 2021
From: cowan at ccil.org (John Cowan)
Date: Tue, 6 Jul 2021 09:40:30 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
Message-ID: <CAD2gp_QbQs7etBHBK5Leno8Zpoa_kW+rLgBo-SR9TMxttRi57w@mail.gmail.com>
On Tue, Jul 6, 2021 at 1:12 AM Nevin Liber <nevin at eviloverlord.com> wrote
in summary:
> 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.
>
Hmm, it seems like I must write my own Master Foo koan (this is a first
draft only, improvements welcome):
After Master Foo completed his discourse on the Unix nature <
http://www.catb.org/~esr/writings/unix-koans/unix-nature.html>, a tall,
thin, gray-haired, balding, bespectacled man entered the room.
Master Foo looked up from his lectern.
"Greetings," said Master Foo. "Who are you?"
"I am the Master Planner," said the Master Planner. "Ninth of my dharma
line," he added modestly.
"I am Master Foo," said Master Foo. "What do you plan for?"
"To reach enlightenment by concentration on a single focus," said the
Master Planner. "Therefore I remove all that is unnecessary from my life."
Master Foo said nothing, but began to type fiercely. Those students who
could see what he was doing were astonished that he appeared to be typing
complete gibberish.
When he stopped typing, Master Foo pushed the device to the Master
Planner. "Read me, if you would, the last maxim of the Zen of Python."
The Master Planner appeared as astonished as the students. "But all men
know that the twenty-one maxims of the Zen of Python have been unchanged
since the Master Sorter wrote them down long ago!" he protested.
"Nevertheless," said Master Foo softly.
The Master Planner gave the words of command and then spoke very softly.
"It says -- it says, 'Inclusion is better than exclusion.'"
On hearing these words, all present were enlightened.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/099b2681/attachment.htm>
From chet.ramey at case.edu Wed Jul 7 00:12:25 2021
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 6 Jul 2021 10:12:25 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
Message-ID: <e111cdc6-dacb-17a0-d1ea-b540c0567738@case.edu>
On 7/6/21 1:10 AM, Nevin Liber wrote:
> head isn't needed because we can already do it with the command line
> options for sed.В That's the Unix way.
Except, in this case, `head' came first.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/
From clemc at ccc.com Wed Jul 7 02:05:04 2021
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jul 2021 12:05:04 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210705071450.GA12885@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
Message-ID: <CAC20D2NdVK1zGeACJW8jZfTm85CyWq8CZd6oZAAfRaRZgovNvg@mail.gmail.com>
On Mon, Jul 5, 2021 at 3:16 AM Tomasz Rola <rtomek at ceti.pl> wrote:
> I have misread you then. I suppose the main problem that Unix solved
> fifty years ago was the need for OS on a not very big (but cheap!)
> machine. There were quite a few such systems and various such 16,
> 18-bit machines. So Unix was one of many, and what made it successful
> was rewriting in C (I think I have read about it somewhere). Various
> guys ported C compiler to their machines and to test it, they compiled
> Unix sources (I am sure I have read about this). So as C gained
> popularity, so did Unix gained popularity and C was the prog lang of
> Unix, thus with every new Unix install C gained even more popularity.
Ouch!!! This is so much important that you have missed in this statement,
as this is a great example of not seeing the forest because of all the
trees. You are right that C and UNIX's success was intertwined but I think
you are missing the drivers for that. They were successful because of
other things and because they were successful, we have them today.
So, Tomasz let me try again .. as an old f*rt that lived this era and
played a role in it. Wrote some of the memos that 'justified UNIX instead
of a commercial solution, *etc*.' UNIX was hardly a slam and it could have
easily not been successful, a lot of things had to occur for the result we
see today.
As I have mentioned before much of this topic has been discussed here
before. In fact, I wrote and published a much longer explanation of all of
this is in a paper I published a few years ago for a French group looking
at how computers and UNIX affected society: If can be found at:
http://technique-societe.cnam.fr
/colloque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et-appropriation--945215.kjsp
or send me an e-mail privately I can send you a PDF [note its formatted
for A4 paper, but will print on US letter successfully].
First ignore UNIX, Multics, or anything else. Please concentrate on the
systems that IBM, BUNCH, DG, and DG had in the 1960s and 1970s. An IBM
term was 'access method.' Every program has to use a specifically defined
scheme to read the data: ISAM/VSAM or in DEC's case RMS. One of my
friends once said of RMS, it was not so bad that RMS had 256 to a thousand
optional features on each QIO call, but Culter had to check for each one of
them sequentially. Yecch!!!!!
Unix as a programming system was a real breath of fresh air -- just
treating files as an unstructured bag of bits and the program figure out
how to deal with them was giant and very much against the thought of the
times. And if you used ASCII, not a binary format, it means that humans
might even be able to debug it the system using the data!! Don't write
huge programs to solve every possible problem you encounter with your
system. Instead, write little ones that can be hooked together and reuse
the different smaller programs. Build a library of complete simple
programs.
BTW: UNIX was not the only system in those days exposing these types of
ideas. I believe that it was Bert Sullivan (Ivan's brother) who built a
system at Lincoln labs that using what IIRC was Simula objects, that could
hook up small things together to manipulate something larger - not unlike
Doug's pipe ideas. This stuff gave way to the later OOB programming
movement [and I would suggest much of the C++ we live with today too, but I
digress].
The idea of lots of little programs that cooperate with each other is not
what IBM and the like wanted/was providing. They were selling closed
'solutions' complete SW systems ("walled gardens" controlled by them or
their programming minions) and yes needed the big iron they sold. Note
the IBM 'solutions were not sold to engineers, their products were sold on
the golf course to the 'managers' of what we know call IT shops.
FWIW: DEC was in a strange position. It had come from serving the
engineers, but systems like VMS have slowly become more and more
interesting to the enterprise and that was a much more lucrative market.
Remember what did Charlie Brown (AT&T's CEO) do after they were broken up
-- he wants to go after IBM!!! AT&T's new marketing folks even change the
name of the codebase from the 'Programmers Workbench' to 'System III'
because they are afraid 'programmer' will not play well in enterprise sales.
The point here is that the 'enterprise type of system is really different
than engineers at BTL, Lincoln Labs, much less in the research campuses of
important universities.
The important thing is that the latter group (not enterprise) did not have
as much money but was a completely different population. UNIX is 100% a
'Christiansen style Disruption' ( read his book completely if you have
not, please). It's a 'lessor technology,' running on smaller equipment,
targeting a new and different consumer who does not care that it is 'not as
good' as the established products. If you compare UNIX to IBM's OS or VMS
for that matter, UNIX does not have the 'features' that are valued by the
'enterprise market.'
Ken/Dennis, *et al*, clearly do not care -- they were building something
they (the engineers) needed and wanted (thankfully). And yes it had to run
on modest hardware because that is what they could afford and had access
to. But because since the HW was modest, that forces a mindset of what are
we really doing on the SW? How can we do it effectively. The designers
are asking an important research question? *Maybe some of these other
schemes are not necessary*.
You are correct the C grew because of UNIX, but you kind of have it
backward. I'm a perfect example of what happened. These new
microprocessors from Intel/Zilog/Moto/MOS Tech became available to us
(engineers mind you). Hey, I was at CMU in the mid-1970s, I even had
access to the BLISS sources, but most people did not. A BLISS cross
compiler binary cost $5K per CPU!!! And by the time what would become the
M68K shows up (I had access to the experimental chip that was not numbered)
I was at Tektronix and I then did not have BLISS sources. *But I did have
the UNIX sources and those included a C compiler that dmr had written for
the PDP-11. So I retargeted it.* Same story with Steve Ward's crew in
the RTS at MIT, although they used both dmr and Steve's compilers. I know
that same song played again at Purdue, also in UNSW, as well in the EU in a
couple of places if you look on the USENIX tapes.
It was *not that we tested our compiler by porting UNIX*. We wanted a *C
compiler for whatever* program/project we had for these new devices. Most
of the time we cross-compiled on our local UNIX box, of course. This was
true of the C8086 and Z80 tools I had in 1978/79. But we all ran it on our
PDP-11s or later Vaxen. It takes a few years before 'JAWS' start and we
see all the UNIX ports, but the C *vs.* Pascal wars were well underweight
by that time, and the UNIX vs. VMS vs. TOPS vs. Tenex vs. VM/CMS vs. TSS
vs. MTS, *etc*. wars had already become the stuff of legend.
The key point is that UNIX was inexpensive and worked on modest hardware.
Yes C came with it and that is why I think we use it not BLISS, BCPL, or
some flavor of PLx today.
It's simply a Christiansen style Disruption Technology -- something valued
by a new market that grew faster than the old market. But the problem we
have with UNIX is as it displaced the old market, the old ideas/behaviors
of the other players that survived started to added back into the new
system their old scheme (with new names mind you -- but the same effect).
i.e. those not willing to learn from the errors and why success occurred in
history will repeat the errors of before. Sadly, I have personally lived
this statement multiple times in my professional employment.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/7ce42ec4/attachment-0001.htm>
From tytso at mit.edu Wed Jul 7 02:23:52 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 6 Jul 2021 12:23:52 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
Message-ID: <YOSDmL7dCmy2KYGz@mit.edu>
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
From rtomek at ceti.pl Wed Jul 7 09:17:00 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Wed, 7 Jul 2021 01:17:00 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
Message-ID: <20210706231659.GA13225@tau1.ceti.pl>
On Mon, Jul 05, 2021 at 12:26:04PM -0400, John Cowan wrote:
> On Mon, Jul 5, 2021 at 3:15 AM Tomasz Rola <rtomek at ceti.pl> wrote:
>
[...]
> By the way, did anyone else start out on Unix-alikes before using actual
> Unix? I read the BSTJ issue and became an instant convert, but only when
> $EMPLOYER got a MicroVAX was I able to work like that. Next came the MKS
> Toolkit on DOS, and then Cygwin for many years. I suppose it's only my
> last two $EMPLOYERs standardizing on the Mac that has left me running,
> like, actual Unix.
Not quite a Unix-lookalike, but AmigaDOS was a mix of ideas - named
volumes (a bit) like in CP/M, multitasking (a bit) like in Unix (but
on my model, I only had M68K and no memory protection), command line
tools allowing for batch programming more sophisticated than what
MSDOS had on table (well, I really never got to the point of abusing
this). Also, Aztec C came with a suite of programs resembling what I
could later find on Unix: cc, ld, make, ar and few others I forgot. At
one point my workflow on Amiga looked similar to my workflow on
Solaris and I could help myself with some Amiga programs after reading
matching man pages on big box.
Better Amigas also had memory protection and newer Workbench
(graphical interface and stuff in ROM) and allowed for AREXX (yes,
clone of mainframe REXX, never learned it) and with AREXX one could
manipulate applications which sported so called REXX-port (if memory
serves) and do things very much resembling what one could today do
with COM/DCOM objects on Windows. I.e. your AREXX script could perform
batch process with painting program, with word processor, perhaps with
desktop publishing and so on.
[...]
> True. But then, many of us geeks make our choices not on technical
> criteria but on tribal loyalty. Which is *technically* superior, vi or
> emacs? (Please don't answer that.)
Mu!
[
Mu (negative) / The Mu-kЕЌan :
https://en.wikipedia.org/wiki/Mu_(negative)#The_Mu-k%C5%8Dan
]
> > Of course I could not be using specialised note
> > taking program. Instead, I went with Emacs and org-mode. In the
> > process I had to learn a bit of Elisp and dot-emacs file. Some
> > defaults in Emacs are not comfy for my eyes - fonts, colors, it had to
> > be fine tuned to my liking.
> >
>
> Note that Emacs is probably the oldest import into the Unix ecosystem from
> outside, and it bears the marks of its origin: monolithic (but
> programmable), one tool does it all.
Well, when "everything" was small enough I really liked it. Nowadays
there seems to be a trend of making Emacs into another OS, like with
abomination we call the browser.
https://www.emacswiki.org/emacs/EmacsApplicationFramework
As long as I am able to trim it during compilation, they may put
whatever they want inside, but when I tried to unpack one of the
latest browser source code, it took more than 2.5 gigabytes (I am not
sure, it could have been a nightmare). I hope they will not apply this
crazyness to Emacs. I hope Emacs version 23 will keep compiling for a
while.
[...]
> Without doubt. I am not loyal to a kernel or a set of utilities, I simply
> follow the Way of Unix: <http://vrici.lojban.org/~cowan/upc/> (sadly
> incomplete)
Oh. I think you just need to bath in Tao, sink deep and breathe it
in. After that, words will form themselves out of the void and fall
right into the void opened with editor, all without any effort on your
side.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From usotsuki at buric.co Wed Jul 7 09:47:37 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 6 Jul 2021 19:47:37 -0400 (EDT)
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210706231659.GA13225@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl>
Message-ID: <alpine.DEB.2.21.2107061945460.7326@sd-119843.dedibox.fr>
On Wed, 7 Jul 2021, Tomasz Rola wrote:
> Well, when "everything" was small enough I really liked it. Nowadays
> there seems to be a trend of making Emacs into another OS, like with
> abomination we call the browser.
I don't think that's anything new. "Great OS, where's the editor?" is a
really old joke about EMACS.
-uso.
From cowan at ccil.org Wed Jul 7 09:48:56 2021
From: cowan at ccil.org (John Cowan)
Date: Tue, 6 Jul 2021 19:48:56 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210706231659.GA13225@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl>
Message-ID: <CAD2gp_Qmg85JRf78EBHb+8_eGf9+5q6pL6669pCJRgbWxTWBiQ@mail.gmail.com>
On Tue, Jul 6, 2021 at 7:17 PM Tomasz Rola <rtomek at ceti.pl> wrote:
> Oh. I think you just need to bath in Tao, sink deep and breathe it
> in. After that, words will form themselves out of the void and fall
> right into the void opened with editor, all without any effort on your
> side.
Well, yes. But to achieve that state of effortlessness requires so much
effort!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/efff2542/attachment.htm>
From imp at bsdimp.com Wed Jul 7 09:49:59 2021
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 6 Jul 2021 17:49:59 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <alpine.DEB.2.21.2107061945460.7326@sd-119843.dedibox.fr>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl>
<alpine.DEB.2.21.2107061945460.7326@sd-119843.dedibox.fr>
Message-ID: <CANCZdfrbLD4QNRfj8x+vKfMaXUOP86KWhxijNRVOWaTTqrq_gg@mail.gmail.com>
On Tue, Jul 6, 2021 at 5:48 PM Steve Nickolas <usotsuki at buric.co> wrote:
> On Wed, 7 Jul 2021, Tomasz Rola wrote:
>
> > Well, when "everything" was small enough I really liked it. Nowadays
> > there seems to be a trend of making Emacs into another OS, like with
> > abomination we call the browser.
>
> I don't think that's anything new. "Great OS, where's the editor?" is a
> really old joke about EMACS.
>
There were even april fools day posts about booting vmunix.el...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/45006cc6/attachment.htm>
From tytso at mit.edu Wed Jul 7 10:46:34 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 6 Jul 2021 20:46:34 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210706231659.GA13225@tau1.ceti.pl>
References: <20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl>
Message-ID: <YOT5ajNhoUqyBqvi@mit.edu>
On Wed, Jul 07, 2021 at 01:17:00AM +0200, Tomasz Rola wrote:
>
> Well, when "everything" was small enough I really liked it. Nowadays
> there seems to be a trend of making Emacs into another OS, like with
> abomination we call the browser.
>
> https://www.emacswiki.org/emacs/EmacsApplicationFramework
>
> As long as I am able to trim it during compilation, they may put
> whatever they want inside, but when I tried to unpack one of the
> latest browser source code, it took more than 2.5 gigabytes (I am not
> sure, it could have been a nightmare). I hope they will not apply this
> crazyness to Emacs. I hope Emacs version 23 will keep compiling for a
> while.
Well, the old joke was that emacs stood for "eight megabytes and
constantly swapping". These days, sure, starting a fresh Emacs
version 27 process has a SIZE of 364 megabytes with an RSS of 78
megabytes.
OTOH, starting a fresh copy of Konsole (KDE's current terminal
emulator) has a SIZE 1383 megabytes with an RSS of 114 megabytes, and
the single Konsole process running all of my terminal windows has a
SIZE of 2160 megabytes (or just a touch over 2GB) with an RSS of 189
megabytes.
As a percentage of the 32 GB physical memory in my Desktop machine,
I'm not too worried about the memory consumption of either the
terminal windows or emacs, especially since the browser takes a lot
more memory. These days, I run my browser in a container to limit its
physical memory usage to 12GB; systemd makes setting this up via a
user unit file really easy. :-)
- Ted
# ~/.config/systemd/chrome.service
[Unit]
Description=Chrome Browser
[Service]
ExecStart=/usr/bin/google-chrome
KillMode=process
MemoryAccounting=true
MemoryMax=12G
P.S. On my laptop I constrain the browser to only use 8GB, which just
means that if I keep huge numbers of tabs open, some of them might get
automatically killed and will have to get reloaded when I swtich back
to that tab. Sure, this wouldn't fly on a PDP-11, but as long as I'm
more productive, I don't really worry about it.
From nevin at eviloverlord.com Wed Jul 7 10:53:11 2021
From: nevin at eviloverlord.com (Nevin Liber)
Date: Tue, 6 Jul 2021 19:53:11 -0500
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <e111cdc6-dacb-17a0-d1ea-b540c0567738@case.edu>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<e111cdc6-dacb-17a0-d1ea-b540c0567738@case.edu>
Message-ID: <CAGg_6+PdeZNeN_c44TP5_rWD715v+UuEJjci9ogshsR4JgjNcQ@mail.gmail.com>
On Tue, Jul 6, 2021 at 9:12 AM Chet Ramey <chet.ramey at case.edu> wrote:
> On 7/6/21 1:10 AM, Nevin Liber wrote:
>
> > head isn't needed because we can already do it with the command line
> > options for sed. That's the Unix way.
>
> Except, in this case, `head' came first.
>
While I may be mis-remembering, IIRC that wasn't true in System V Unix from
AT&T (which is where I was first exposed to it).
--
Nevin ":-)" Liber <mailto:nevin at eviloverlord.com> +1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/5dbecff7/attachment.htm>
From ggm at algebras.org Wed Jul 7 10:58:50 2021
From: ggm at algebras.org (George Michaelson)
Date: Wed, 7 Jul 2021 10:58:50 +1000
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOT5ajNhoUqyBqvi@mit.edu>
References: <20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
Message-ID: <CAKr6gn2U_5uPXauFrHuwrH_1O0+Qki_PoWd0kqmJ8wkStZRePw@mail.gmail.com>
The emacs manual *printed, one-sided, bound to the desk with rods of
steel* which I read in the 1980s in leeds was one of the best
explanations of Virtual Memory I saw. I really struggled with the idea
of address segments, maps, the idea of address space being bigger than
physical memory (I think I drove a PhD student doing tutoring close to
tears on this in '79) but the Emacs manual said really clearly
up-front: "look, you can't address 32 bits of memory in "me" I only do
24, but this is how I do them, if you're interested"
The Vax VMS manual along side it (another 2 feet of single-sided
print) was probably as good, but more aimed at real engineers who
could think in RPN and had pocket protectors.
This was in a context where it was probably the go-to basis to try and
play with LISP because nobody really told you about any other REPL to
run in. I think even then I realised I wasn't going to ever want to
code a towers-of-hanoi, nor even really explore 24 bits of (virtual)
address space.
I hate the cult. I decided to re-learn the finger muscle memory, now I
can do bare-minimum in emacs for ORG and I think I'll go back to vi
where I belong. vi suffered from insufficient love. I had to stop
hating vim when it became the only real choice. (hate.. culty word,
that) VScode was interesting, as was Atom, and I suspect more than a
few people who code for a way of life here think this editor-wars
stuff is tedious.
I actually "think" in ed. I can't escape line-based semantic intent. I
carry my own personal koan which basically says "any algorithm which
needs more than 2 sentences or 1 screen of code to implement is
probably beyond you". Its a bit of a flaw.
On Wed, Jul 7, 2021 at 10:47 AM Theodore Ts'o <tytso at mit.edu> wrote:
>
> On Wed, Jul 07, 2021 at 01:17:00AM +0200, Tomasz Rola wrote:
> >
> > Well, when "everything" was small enough I really liked it. Nowadays
> > there seems to be a trend of making Emacs into another OS, like with
> > abomination we call the browser.
> >
> > https://www.emacswiki.org/emacs/EmacsApplicationFramework
> >
> > As long as I am able to trim it during compilation, they may put
> > whatever they want inside, but when I tried to unpack one of the
> > latest browser source code, it took more than 2.5 gigabytes (I am not
> > sure, it could have been a nightmare). I hope they will not apply this
> > crazyness to Emacs. I hope Emacs version 23 will keep compiling for a
> > while.
>
> Well, the old joke was that emacs stood for "eight megabytes and
> constantly swapping". These days, sure, starting a fresh Emacs
> version 27 process has a SIZE of 364 megabytes with an RSS of 78
> megabytes.
>
> OTOH, starting a fresh copy of Konsole (KDE's current terminal
> emulator) has a SIZE 1383 megabytes with an RSS of 114 megabytes, and
> the single Konsole process running all of my terminal windows has a
> SIZE of 2160 megabytes (or just a touch over 2GB) with an RSS of 189
> megabytes.
>
> As a percentage of the 32 GB physical memory in my Desktop machine,
> I'm not too worried about the memory consumption of either the
> terminal windows or emacs, especially since the browser takes a lot
> more memory. These days, I run my browser in a container to limit its
> physical memory usage to 12GB; systemd makes setting this up via a
> user unit file really easy. :-)
>
> - Ted
>
> # ~/.config/systemd/chrome.service
> [Unit]
> Description=Chrome Browser
>
> [Service]
> ExecStart=/usr/bin/google-chrome
> KillMode=process
> MemoryAccounting=true
> MemoryMax=12G
>
> P.S. On my laptop I constrain the browser to only use 8GB, which just
> means that if I keep huge numbers of tabs open, some of them might get
> automatically killed and will have to get reloaded when I swtich back
> to that tab. Sure, this wouldn't fly on a PDP-11, but as long as I'm
> more productive, I don't really worry about it.
From crossd at gmail.com Wed Jul 7 11:57:38 2021
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Jul 2021 21:57:38 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOSDmL7dCmy2KYGz@mit.edu>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
Message-ID: <CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
On Tue, Jul 6, 2021 at 12:25 PM Theodore Ts'o <tytso at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/14334180/attachment.htm>
From lm at mcvoy.com Wed Jul 7 12:48:20 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 6 Jul 2021 19:48:20 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAKr6gn2U_5uPXauFrHuwrH_1O0+Qki_PoWd0kqmJ8wkStZRePw@mail.gmail.com>
References: <alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<CAKr6gn2U_5uPXauFrHuwrH_1O0+Qki_PoWd0kqmJ8wkStZRePw@mail.gmail.com>
Message-ID: <20210707024820.GN10781@mcvoy.com>
On Wed, Jul 07, 2021 at 10:58:50AM +1000, George Michaelson wrote:
> I actually "think" in ed.
I think in pic, I can look at pic code and see what it will draw.
To me, pic is one of the best things that came out of Bell Labs.
Unix is awesome, no doubt. But for the essence of small but you
can see what it will do, pic is greater than ed. No disrespect
to ed, I've spent a pile of time in ed.
From lm at mcvoy.com Wed Jul 7 12:52:44 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 6 Jul 2021 19:52:44 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
Message-ID: <20210707025244.GO10781@mcvoy.com>
On Tue, Jul 06, 2021 at 09:57:38PM -0400, Dan Cross wrote:
> 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.
http://lkml.iu.edu/hypermail/linux/kernel/0106.2/0405.html
I wasn't completely right 20 years ago but I was close. I'm tired,
if you want to know where I'm wrong, ask and I'll tell you how I
tried to get Linus to fix it.
In general, Rob was on point. He usually is.
From andreww591 at gmail.com Wed Jul 7 15:19:37 2021
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Tue, 6 Jul 2021 23:19:37 -0600
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210707025244.GO10781@mcvoy.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<20210707025244.GO10781@mcvoy.com>
Message-ID: <CAD-qYGpHiPuEv3=Ow7NoRCkj6gk3zJ525AZooD4Nd_=dEL5HkA@mail.gmail.com>
On 06/07/2021, Larry McVoy <lm at mcvoy.com> wrote:
>
> http://lkml.iu.edu/hypermail/linux/kernel/0106.2/0405.html
>
> I wasn't completely right 20 years ago but I was close. I'm tired,
> if you want to know where I'm wrong, ask and I'll tell you how I
> tried to get Linus to fix it.
>
> In general, Rob was on point. He usually is.
>
I've never been a fan of clone(). It always strikes me as something
that seems like an elegant simplification at first, but the practical
realization (on Linux that is) requires several rather ugly
library-level hacks to make it work right for typical use cases.
UX/RT will use the "processes are containers for threads" model rather
than rfork()/clone() since that's the model the seL4 kernel basically
uses (in a very generalized form with address spaces , capability
spaces, and threads being separate objects and each thread being
associated with a capability space and address space), and it would
also be slightly easier to create the helper threads that will be
required in certain parts of the IPC transport layer.
The base process creation primitive (efork(), for "empty/eviscerated
fork") will create a completely blank non-runnable child process with
no memory mappings or file descriptors, and return a context FD that
the parent can use to manipulate the state of the child with normal
APIs, including copying FDs and memory mappings. To actually start the
child the parent will perform an exec*() within the child context
(either a regular exec*() to make the child run a different program,
or a new eexec() function that takes an entry point rather than a
command line to run the process with whatever memory mappings were set
up), after which point the parent will no longer be able to manipulate
the child's state.
This will eliminate the overhead of fork() for spawning processes
running other programs, but will still allow for a library-level
fork() implementation that has comparable overhead to traditional
implementations. Also, it will do what Plan 9 never did and make the
process/memory APIs file-oriented (I still don't get why Plan 9 went
with a rather limited anonymous memory API rather than using
memory-mapped files for everything).
Also, we're straying a bit from historical Unix here and should have
probably moved to COFF several messages ago.
From chet.ramey at case.edu Wed Jul 7 23:08:10 2021
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 7 Jul 2021 09:08:10 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAGg_6+PdeZNeN_c44TP5_rWD715v+UuEJjci9ogshsR4JgjNcQ@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<e111cdc6-dacb-17a0-d1ea-b540c0567738@case.edu>
<CAGg_6+PdeZNeN_c44TP5_rWD715v+UuEJjci9ogshsR4JgjNcQ@mail.gmail.com>
Message-ID: <66830aa6-218d-7728-1652-98d765bf06a7@case.edu>
On 7/6/21 8:53 PM, Nevin Liber wrote:
> On Tue, Jul 6, 2021 at 9:12 AM Chet Ramey <chet.ramey at case.edu
> <mailto:chet.ramey at case.edu>> wrote:
>
> On 7/6/21 1:10 AM, Nevin Liber wrote:
>
> > head isn't needed because we can already do it with the command line
> > options for sed.В That's the Unix way.
>
> Except, in this case, `head' came first.
>
>
> While I may be mis-remembering, IIRC that wasn't true in System V Unix from
> AT&T (which is where I was first exposed to it).
This came up on the list last week. Joy wrote `head' while using 6th
Edition systems at Berkeley; `sed' first appeared in the 7th Edition.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/
From dot at dotat.at Wed Jul 7 23:54:42 2021
From: dot at dotat.at (Tony Finch)
Date: Wed, 7 Jul 2021 14:54:42 +0100
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210706231659.GA13225@tau1.ceti.pl>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl>
Message-ID: <ad9ae36b-5548-1174-31f3-5e4a533efa8@dotat.at>
Tomasz Rola <rtomek at ceti.pl> wrote:
>
> Not quite a Unix-lookalike, but AmigaDOS was a mix of ideas - named
> volumes (a bit) like in CP/M, multitasking (a bit) like in Unix (but
> on my model, I only had M68K and no memory protection), command line
> tools allowing for batch programming more sophisticated than what
> MSDOS had on table (well, I really never got to the point of abusing
> this).
The more unixy parts of AmigaDOS came from TRIPOS
https://www.pagetable.com/?p=193
https://en.wikipedia.org/wiki/TRIPOS
TRIPOS was originally developed by a team led by Martin Richards, who had
previously developed BCPL.
> Also, Aztec C came with a suite of programs resembling what I
> could later find on Unix: cc, ld, make, ar and few others I forgot.
Also true for the Acorn / Norcroft ARM C Compiler on the Archimedes, which
was my first contact with unix-like tools :-)
Tony.
--
f.anthony.n.finch <dot at dotat.at> https://dotat.at/
Northwest Fitzroy, Sole: Northwesterly 4 or 5, occasionally 6 at
first, backing westerly or southwesterly 3 or 4 later. Moderate,
occasionally rough at first. Showers. Good, occasionally moderate.
From rich.salz at gmail.com Thu Jul 8 01:15:51 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 7 Jul 2021 11:15:51 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <66830aa6-218d-7728-1652-98d765bf06a7@case.edu>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<e111cdc6-dacb-17a0-d1ea-b540c0567738@case.edu>
<CAGg_6+PdeZNeN_c44TP5_rWD715v+UuEJjci9ogshsR4JgjNcQ@mail.gmail.com>
<66830aa6-218d-7728-1652-98d765bf06a7@case.edu>
Message-ID: <CAFH29trfhEkaZcSHhteuuGDSSWFfGF0BU68crNe-Qw7wpwvEKQ@mail.gmail.com>
> > While I may be mis-remembering, IIRC that wasn't true in System V Unix
> from
> > AT&T (which is where I was first exposed to it).
>
>
According to
http://bitsavers.trailing-edge.com/pdf/att/3b1/999-801-312IS_ATT_UNIX_PC_System_V_Users_Manual_Volume_1.pdf
and
https://archive.org/details/bitsavers_attunixSystemVRelease4ProgrammersReferenceManual19_55505648/page/n13/mode/2up
there is no 'head' command. So Nevin's experience is accurate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210707/3d9fd6f8/attachment.htm>
From jon at fourwinds.com Thu Jul 8 04:28:42 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 07 Jul 2021 11:28:42 -0700
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
Message-ID: <202107071828.167ISgdN2686558@darkstar.fourwinds.com>
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.
From rtomek at ceti.pl Thu Jul 8 04:32:22 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Wed, 7 Jul 2021 20:32:22 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOT5ajNhoUqyBqvi@mit.edu>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
Message-ID: <20210707183222.GA9897@tau1.ceti.pl>
On Tue, Jul 06, 2021 at 08:46:34PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 07, 2021 at 01:17:00AM +0200, Tomasz Rola wrote:
> >
[...]
> > https://www.emacswiki.org/emacs/EmacsApplicationFramework
[...]
> >
>
> Well, the old joke was that emacs stood for "eight megabytes and
> constantly swapping".
Yeah, during my 486 days it was indeed doing stuff with disk. But I
was too happy to have this "workstation lookalike" running "Unix
lookalike" installed from dozens of floppies so I did not complained
about some minor problems.
> These days, sure, starting a fresh Emacs
> version 27 process has a SIZE of 364 megabytes with an RSS of 78
> megabytes.
>
> OTOH, starting a fresh copy of Konsole (KDE's current terminal
> emulator) has a SIZE 1383 megabytes with an RSS of 114 megabytes, and
> the single Konsole process running all of my terminal windows has a
> SIZE of 2160 megabytes (or just a touch over 2GB) with an RSS of 189
> megabytes.
An excerpt from my ps:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
xxxek 576 0.0 0.2 283392 34172 pts/122 SNl Jun29 0:06 emacs
xxxek 23684 0.3 1.7 379624 211872 pts/21 SN Jul03 22:06 emacs /ho
xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr
xxxon 3553 0.0 1.2 218028 150656 pts/67 TN Jun30 0:24 dillo
xxxek 12588 0.0 0.0 38108 752 pts/183 T 2020 0:00 lynx -nocolor -force-html /ho
xxxek 6785 0.0 0.0 310580 10052 pts/22 Sl 2020 41:51 roxterm
xxxek 5321 0.0 0.0 102712 1456 tty2 S 2020 1:56 rxvt -bg Black
xxxek 5322 0.0 0.0 66784 1988 tty2 S 2020 165:48 xterm -bg
xxxek 5596 0.0 0.0 21608 536 pts/121 S+ 2020 1:35 /usr/bin/screen
Emacs ver.23, firefox ver. "very old". I do not trust my browsers too
much, so when I go to sleep they go to STOP freeze. The second emacs
is editing my pathetic########glorious######## wiki with org-mode,
file length about 55 megabytes, with unicodes, so the rss is multiple
of file size. I have long ago replaced konsole with roxterm. As you
can see, it eats nowhere near a gigabyte. And it does not read a whole
disk when starting. It usually goes with three tabs opened, so maybe
in your case memsize would have been bigger. I make a lot of use with
virtual desktops offered by fvwm, and when I need terminal on one of
those desktops (I usually do), I open some rxvt variation; position,
resize and keep it there for further use.
As I have only 12gigs of ram and more than half goes to ramdisk
(always doing something there, including compiling huge piles of code
from the net), so I have to keep an eye on firefox. When it goes above
2.9g of rss I usually start to fret and kill unneeded tabs. I set it
up to use only two or three fonts and completely disregard
author-provided fonts. So far, so good. Ah, and I use noscript,
too. Yet despite of all those precautions, I have to kill -STOP it,
because the mere thought that it will keep eating 50-90% of cpu while
doing nothing, well, this drives me up the wall. Likewise, back in the
past, when I saw how *idle* program (firefox) constantly wrote *gigs*
of bytes to my disk, I simply went mad. Long story short, now it only
can write to temporary place in ramdisk. It still does not stop it
from opening multiple files on disk in /tmp, deleting them and keeping
opened/deleted forever, using up my precious ram. It sometimes closes
those files, but not very often.
I usually open new pages in dillo, w3m or lynx (or curl) and use
firefox when nothing else would do. Not perfect solution - dillo has
some memory problem, so I usually have many of them opened and slash
those who grow too much. Like, 300megs for dillo is enough. Read up
all the tabs in it and kill. And it seems I have (pidof lynx|wc -w)
170 lynx processes, all kill-stopped and awaiting my
attention. Craps. Chances are I did not stopped being mad. At least
Unix command line tools allow me to measure it.
> As a percentage of the 32 GB physical memory in my Desktop machine,
> I'm not too worried about the memory consumption of either the
> terminal windows or emacs, especially since the browser takes a lot
> more memory. These days, I run my browser in a container to limit its
> physical memory usage to 12GB; systemd makes setting this up via a
> user unit file really easy. :-)
>
> - Ted
>
> # ~/.config/systemd/chrome.service
> [Unit]
> Description=Chrome Browser
>
> [Service]
> ExecStart=/usr/bin/google-chrome
> KillMode=process
> MemoryAccounting=true
> MemoryMax=12G
Now I am happy that I do not use systemd. Now I want to find more time
and migrate to OpenBSD. I really do (I know there are some Linux
distros which evaded systemd - for a while, but I consider a whole
Linux land to be lost already, just a matter of time, and I foresee
that OpenBSD will fall as the very last, if ever). I will sleep less
and program more. I will rewrite all my old python2x scripts in r7rs
scheme. Not really so many. Fruits of hard work shall be sweet and
plentiful.
12g for a browser. I am not criticising you, but I could say a bit
about people who made programs and websites contributing to such
sizes.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From michael at kjorling.se Thu Jul 8 06:50:51 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 7 Jul 2021 20:50:51 +0000
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <20210707183222.GA9897@tau1.ceti.pl>
References: <alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
Message-ID: <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
On 7 Jul 2021 20:32 +0200, from rtomek at ceti.pl (Tomasz Rola):
> An excerpt from my ps:
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
>
> xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr
I'm going to stick my neck out here by saying that the VSZ and RSS
values reported by ps, at least for Firefox, are largely meaningless.
I started my usual Firefox instance, which has a handful of plugins,
about a metric gazillion bookmarks, and has been my main web browser
profile for years (so it probably has collected some crud over time).
`ps auxw` reported that process as having a total RSS of a whopping
374 GB.
It is downright _impossible_ that Firefox could actually be using that
amount of volatile memory, because my system has "only" 32 GB RAM + 64
GB swap. The root file system, which on my system also holds the likes
of /usr/{bin,lib}, totals 29701 MB used according to `df -m`, plus ~
totals 22550 MB, so even if Firefox read _all_ of that into memory it
still wouldn't be anywhere _close_ to the reported RSS value, falling
short by about a factor 7x (and Firefox has no reason to even look at
much of what's there, like the 2.5 GB in /usr/share/games/flightgear).
While that Firefox instance was running, I ran `free -m`, which
reported 250 MB swap used (65285 MB free) and 26008 MB "memory
available". Very soon after closing Firefox (and soon enough to try to
ensure that nothing else major changed), I ran `free -m` again, which
then reported the same 250 MB swap used and a slightly larger 26298 MB
memory available; a difference of 290 MB between when Firefox was
running and when it was not.
That's a _factor almost 2300x_ difference between the reported RSS,
and the amount of memory that was actually freed up by closing the
browser.
The same experiment done with a brand-new browser profile gave a total
RSS of 751 GB for Firefox's processes combined, while free reports a
difference of 321 MB between running and not-running. That's within
striking distance of a factor 2400x difference.
Does this mean that software bloat isn't an issue? I would argue that
it does not. Does it mean that Firefox can't have, say, memory leaks,
causing it to over time have more memory allocated than it actually
uses? It does not; and in fact I believe that's something that has
been worked on over the years. But I think it's worth trying to be
honest about all this, and at least _try_ to not compare apples to
stars just because both resemble oblate spheroids and exert
gravitational influence. On modern systems, with everything from
shared libraries to memory-mapped I/O to routine use of memory
overcommitting, the resident set size is clearly a poor indicator of
the actual amount of memory actively used by a complex process.
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
From rtomek at ceti.pl Thu Jul 8 16:46:53 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Thu, 8 Jul 2021 08:46:53 +0200
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
References: <396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
Message-ID: <20210708064652.GA19675@tau1.ceti.pl>
On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
> On 7 Jul 2021 20:32 +0200, from rtomek at ceti.pl (Tomasz Rola):
> > An excerpt from my ps:
> >
> > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> >
> > xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr
>
> I'm going to stick my neck out here by saying that the VSZ and RSS
> values reported by ps, at least for Firefox, are largely meaningless.
>
> I started my usual Firefox instance, which has a handful of plugins,
> about a metric gazillion bookmarks, and has been my main web browser
> profile for years (so it probably has collected some crud over time).
> `ps auxw` reported that process as having a total RSS of a whopping
> 374 GB.
>
> It is downright _impossible_ that Firefox could actually be using that
This is quite strange for me. Without looking at your system I can only
suspect it has something to do with multithreading.
If I do two different commands as root, with firefox pid here
.eq. 12331, as above:
=> (500 15): lsof -p 12331 | wc -l
402
=> (500 17): lsof | awk '$2==12331' | wc -l
22055
The first column gives a name, and in second case it not always is
'firefox'. I am yet to study manpage for lsof and play with it, but it
surely shows interesting things.
On my system, when firefox gets killed, 'free' shows a difference - if
I recall, free mem increases by the size of rss plus all the stuff
which was opened and released from buffers. I did not pay much
attention, I assumed numbers would match and this is what they
probably did :-).
OS on my box used to report to me as Debian, and still does, but some
years ago I have decided to skip the usual system upgrade, and after
some more time I started to upgrade various elements by hand. So it is
more like a tattered patchwork right now. But it does what I expect,
hopefully.
[...]
> That's a _factor almost 2300x_ difference between the reported RSS,
> and the amount of memory that was actually freed up by closing the
> browser.
Yeah, strange.
[...]
> On modern systems, with everything from shared libraries to
> memory-mapped I/O to routine use of memory overcommitting, the
> resident set size is clearly a poor indicator of the actual amount
> of memory actively used by a complex process.
Hard to tell - first I would like to learn where the hundred-giga rss
came from...
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From dfawcus+lists-tuhs at employees.org Thu Jul 8 23:59:57 2021
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Thu, 8 Jul 2021 14:59:57 +0100
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <20210708064652.GA19675@tau1.ceti.pl>
References: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<20210708064652.GA19675@tau1.ceti.pl>
Message-ID: <YOcE3fre5cUTt6Br@clarinet.employees.org>
On Thu, Jul 08, 2021 at 08:46:53AM +0200, Tomasz Rola wrote:
> On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
> > On 7 Jul 2021 20:32 +0200, from rtomek at ceti.pl (Tomasz Rola):
> > > An excerpt from my ps:
> > >
> > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> > >
> > > xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr
> >
> > I'm going to stick my neck out here by saying that the VSZ and RSS
> > values reported by ps, at least for Firefox, are largely meaningless.
Or does it depend upon the OS? From a mac instance:
$ ps -u 502 -o vsz,rss,ucomm,command|fgrep Firefox-78esr.app|awk '$3!="fgrep" {print int($1/1024),int($2/1024),$3}'
10113 189 firefox
5564 73 plugin-container
6051 46 plugin-container
6129 56 plugin-container
5487 55 plugin-container
5619 53 plugin-container
7201 49 plugin-container
6852 60 plugin-container
5876 62 plugin-container
6247 56 plugin-container
6050 13 plugin-container
6055 9 plugin-container
The display from Activity Monitor, which one would assume better presents
the mach VM gives for the 'firefox' process:
Real Memory ~ 171M
Private Memory ~ 80M
Shared Memory ~ 85M
Memory ~ 1.05G
and when inspected a Virtual Memory size of ~ 9.8 G but Real memory size of ~ 170M
Whereas a linux instance (viewing different pages) of 89.0.2 gives:
$ ps -u 100 -o vsx,rss,ucomm,command|fgrep firefox|awk '$3!="grep" {print int($1/1024),int($2/1024),$3}'
3147 356 firefox
2699 200 Web
2522 99 WebExtensions
3271 219 Web
2642 181 Web
2511 105 Web
2489 73 Web
and yeah - it does 'leak' as the main firefox process sitting 'idle' has now become:
3190 346 firefox
So there are defintitly issues in mapping the current use of various types
of memory to a simple display format.
DF
From steffen at sdaoden.eu Fri Jul 9 05:25:38 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 08 Jul 2021 21:25:38 +0200
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <YOcE3fre5cUTt6Br@clarinet.employees.org>
References: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<20210708064652.GA19675@tau1.ceti.pl>
<YOcE3fre5cUTt6Br@clarinet.employees.org>
Message-ID: <20210708192538.jpOvc%steffen@sdaoden.eu>
Derek Fawcus wrote in
<YOcE3fre5cUTt6Br at clarinet.employees.org>:
|On Thu, Jul 08, 2021 at 08:46:53AM +0200, Tomasz Rola wrote:
|> On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
|>> On 7 Jul 2021 20:32 +0200, from rtomek at ceti.pl (Tomasz Rola):
|>>> An excerpt from my ps:
|>>>
|>>> xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 \
|>>> firefox-esr
|>>
|>> I'm going to stick my neck out here by saying that the VSZ and RSS
|>> values reported by ps, at least for Firefox, are largely meaningless.
|
|Or does it depend upon the OS? From a mac instance:
...
|So there are defintitly issues in mapping the current use of various types
|of memory to a simple display format.
Another thing is that, when i used it, Mac command line tools did
not take care about exit status (as in "succeed though they should
not") or know about job signals.
But it is not only Mac, take iwd again, iwctl('s display handling)
definetely is buggy in respect to handling of SIGCONT after
a TSTP. (Ie the screen starts scrolling line-wise but no display
is ever refreshed.)
Regarding the thing, here this seems pretty much fine for RSS.
root 1454 0.0 0.0 7912 2480 ? S 21:03 0:00 /bin/bash /x/pub/box-web.sh browse firefox
root 1456 0.0 0.0 3012 2032 ? S 21:03 0:00 /usr/bin/doas -u steffen /box.firefox
steffen 1457 0.0 0.0 2384 700 ? S 21:03 0:00 /bin/sh - /box.firefox
steffen 1458 31.2 3.7 3029004 299700 ? Sl 21:03 0:04 firefox --no-remote
steffen 1545 4.0 1.3 2421200 108196 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/lib/f
steffen 1583 2.2 1.1 2412124 89636 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 2 -isForBrowser -prefsLen 4909 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/li
steffen 1636 0.6 0.7 2382844 59560 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 3 -isForBrowser -prefsLen 5602 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/li
Yeah i use --no-remote because otherwise firefox will find its
other-box instances via X cookies (i do not have Wayland here).
I deem it a critical error that firefox then starts up even though
the ~/.mozilla/XXX profile is a totally different one, but on the
IRC we just ended like this.
Btw i use
setup_cgroup() {
#return
[ -e /sys/fs/cgroup/cgroup.procs ] || return
[ -d /sys/fs/cgroup/_box_web ] && return
(
umask 0022
mkdir /sys/fs/cgroup/_box_web || return
)
echo 1-3 > /sys/fs/cgroup/_box_web/cpuset.cpus
echo 1 > /sys/fs/cgroup/_box_web/cpu.weight
echo 300 > /sys/fs/cgroup/_box_web/pids.max
echo 1000000000 > /sys/fs/cgroup/_box_web/memory.high
}
on this box for box-web.sh, and i can read all my newspapers and
browse the web, even youtube.
If i open to many tabs, they start crashing. This mostly seems
due to the pids.max, however, i already increased this from 250.
What _i_ find interesting is that for the first time i really get
impressive scheduling feedback. This cpu.weight=1 can indeed
cause the browser to be delayed entirely for minutes, dependent on
the other tasks on the system. I mean really, totally, entirely.
I was impressed by reading the sched manual once i came back to
Linux two years ago, but seeing cpu.weight=1 in action _like
that_, really impressive.
Btw .. happy to be on the other side of the spectrum
steffen 1251 0.0 0.0 11240 6184 tty1 S Jul05 0:06 cwm
steffen 1261 0.0 0.1 19284 9096 ? Ss Jul05 1:11 st -n stgrey
steffen 1262 0.0 0.0 8588 3896 pts/0 Ss+ Jul05 0:00 tmux a
steffen 1334 0.0 1.1 94088 88680 ? Ss Jul05 1:25 tmux a
steffen 5058 0.0 0.1 14672 8712 pts/1 S+ Jul05 0:11 s-nail -Aich
steffen 30448 0.0 0.2 100800 19052 pts/7 Sl+ 20:50 0:00 irssi
steffen 1340 0.0 0.0 11848 6840 pts/6 Ss+ Jul05 0:00 vim -u /home/steffen/.vimrc
It all fits a single Terminal.app (if not taking into account tmux
history), even if online. (Granted st does not have the history
patch, and firefox not running.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From steffen at sdaoden.eu Fri Jul 9 05:37:31 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 08 Jul 2021 21:37:31 +0200
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <20210708192538.jpOvc%steffen@sdaoden.eu>
References: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<20210708064652.GA19675@tau1.ceti.pl>
<YOcE3fre5cUTt6Br@clarinet.employees.org>
<20210708192538.jpOvc%steffen@sdaoden.eu>
Message-ID: <20210708193731.ps4ut%steffen@sdaoden.eu>
Steffen Nurpmeso wrote in
<20210708192538.jpOvc%steffen at sdaoden.eu>:
...
|But it is not only Mac, take iwd again, iwctl('s display handling)
|definetely is buggy in respect to handling of SIGCONT after
|a TSTP. (Ie the screen starts scrolling line-wise but no display
|is ever refreshed.)
..at least if in an active "station X show" or so..
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From steffen at sdaoden.eu Fri Jul 9 06:40:01 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 08 Jul 2021 22:40:01 +0200
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <20210708192538.jpOvc%steffen@sdaoden.eu>
References: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<20210708064652.GA19675@tau1.ceti.pl>
<YOcE3fre5cUTt6Br@clarinet.employees.org>
<20210708192538.jpOvc%steffen@sdaoden.eu>
Message-ID: <20210708204001.n5E-R%steffen@sdaoden.eu>
Steffen Nurpmeso wrote in
<20210708192538.jpOvc%steffen at sdaoden.eu>:
...
| steffen 1458 31.2 3.7 3029004 299700 ? Sl 21:03 0:04 \
| firefox --no-remote
...
|Yeah i use --no-remote because otherwise firefox will find its
|other-box instances via X cookies (i do not have Wayland here).
|I deem it a critical error that firefox then starts up even though
|the ~/.mozilla/XXX profile is a totally different one, but on the
|IRC we just ended like this.
Not to mention that firefox-bin 89.0.1 as compiled mozilla.com
themselves no longer does that right, it will exit the other
instance in another box with another profile directory even if
both instances start with --no-remote.
Heck, software is a complicated beast.
Has to be said, humans produce so many bugs, i am happy that it is
software that controls american warships, nuclear power plants,
the chemical industry, and so many other important things!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From tytso at mit.edu Fri Jul 9 07:47:57 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 8 Jul 2021 17:47:57 -0400
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
References: <396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
Message-ID: <YOdyjcVCL5TS3VBg@mit.edu>
On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
>
> I'm going to stick my neck out here by saying that the VSZ and RSS
> values reported by ps, at least for Firefox, are largely meaningless.
No, VSZ is correct, but it's confusing since it includes things that
you might not expect. VSZ includes *all* virtual memory space
consumed by a process.
For example, consider this simple program:
main(int argc, char **argv)
{
printf("Hello, world\n");
sleep(10);
return 0;
}
It uses shared libraries:
% ldd /tmp/hello
linux-vdso.so.1 (0x00007fff20bff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8caad9000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd8cacca000)
If you run the program the ps listing looks like this:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
tytso 4060239 0.0 0.0 2300 512 pts/2 T 17:01 0:00 /tmp/hello
If you look at /proc/4060239/maps, you'll memory map for the process.
5559e8e7d000-5559e8e7e000 r--p 00000000 00:25 260006 /tmp/hello
5559e8e7e000-5559e8e7f000 r-xp 00001000 00:25 260006 /tmp/hello
5559e8e7f000-5559e8e80000 r--p 00002000 00:25 260006 /tmp/hello
5559e8e80000-5559e8e81000 r--p 00002000 00:25 260006 /tmp/hello
5559e8e81000-5559e8e82000 rw-p 00003000 00:25 260006 /tmp/hello
5559ea383000-5559ea3a4000 rw-p 00000000 00:00 0 [heap]
7f8419a44000-7f8419a69000 r--p 00000000 fc:00 10763398 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8419a69000-7f8419bb4000 r-xp 00025000 fc:00 10763398 /usr/lib/x86_64-linux-gnu/libc-2.31.so
...
If you add the sum total of all of the VM regions, i.e.:
(0x5559e8e7e000 - 0x5559e8e7d000) +
(0x5559e8e7f000 - 0x5559e8e7e000) +
(0x5559e8e80000 - 0x5559e8e7f000) +
...
(ignore the last vsyscall region, since that's a kernel page mapped
into all processes) You'll get the 2300k of the VSZ.
If the process mmap's in a large 2GB file, the VSZ will go up by 2GB,
even if none of the file is paged in. Or if you mmap in 2MB of
anonymous memory backed by the zero page for the heap, the VSZ will go
up by 2MB.
> I started my usual Firefox instance, which has a handful of plugins,
> about a metric gazillion bookmarks, and has been my main web browser
> profile for years (so it probably has collected some crud over time).
> `ps auxw` reported that process as having a total RSS of a whopping
> 374 GB.
I don't think that's right. Are you sure it's not 374MB? I started
firefox-esr on my Debian machine, and the PS output is:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
tytso 4063201 5.8 1.0 3027868 357248 pts/2 Sl 17:38 0:07 firefox-esr
tytso 4063274 0.5 0.3 2446608 105620 pts/2 Sl 17:38 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF
tytso 4063317 0.8 0.3 2457032 124200 pts/2 Sl 17:38 0:01 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF
tytso 4063341 2.9 0.8 2623896 282420 pts/2 Sl 17:38 0:03 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF
357248k is 343MB. Maybe you were adding up the RSS's for all of the
processes? That's misleading because if a physical 4k page is shared
across multiple process, that 4k page will be accounted in each of the
processes's RSS --- even if that process hasn't actually *used* that
particular page. So for example, the hello world program had a 512k RSS:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
tytso 4060239 0.0 0.0 2300 512 pts/2 T 17:01 0:00 /tmp/hello
That's not because the hello world program actually used half a
megabyte worth of the C library; but rather, almost half a megabyte of
the C library has been paged in to support all of the processes
currently running in the system. It also follows that every process
using shared library is going to have an RSS which is at least 512k.
Cheers,
- Ted
From kevin.bowling at kev009.com Fri Jul 9 08:23:25 2021
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 8 Jul 2021 15:23:25 -0700
Subject: [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view)
In-Reply-To: <20210708064652.GA19675@tau1.ceti.pl>
References: <396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<20210708064652.GA19675@tau1.ceti.pl>
Message-ID: <CAK7dMtAdzPNCGV_2oQCuVxOqAxGQc7t2UfFn5xQXYf+OwQjhdg@mail.gmail.com>
Try typing “about:memory” into the address bar and hit measure. You will
see where it is all going.
On Wed, Jul 7, 2021 at 11:48 PM Tomasz Rola <rtomek at ceti.pl> wrote:
> On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
> > On 7 Jul 2021 20:32 +0200, from rtomek at ceti.pl (Tomasz Rola):
> > > An excerpt from my ps:
> > >
> > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
> COMMAND
> > >
> > > xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11
> firefox-esr
> >
> > I'm going to stick my neck out here by saying that the VSZ and RSS
> > values reported by ps, at least for Firefox, are largely meaningless.
> >
> > I started my usual Firefox instance, which has a handful of plugins,
> > about a metric gazillion bookmarks, and has been my main web browser
> > profile for years (so it probably has collected some crud over time).
> > `ps auxw` reported that process as having a total RSS of a whopping
> > 374 GB.
> >
> > It is downright _impossible_ that Firefox could actually be using that
>
> This is quite strange for me. Without looking at your system I can only
> suspect it has something to do with multithreading.
>
> If I do two different commands as root, with firefox pid here
> .eq. 12331, as above:
>
> => (500 15): lsof -p 12331 | wc -l
> 402
>
> => (500 17): lsof | awk '$2==12331' | wc -l
> 22055
>
> The first column gives a name, and in second case it not always is
> 'firefox'. I am yet to study manpage for lsof and play with it, but it
> surely shows interesting things.
>
> On my system, when firefox gets killed, 'free' shows a difference - if
> I recall, free mem increases by the size of rss plus all the stuff
> which was opened and released from buffers. I did not pay much
> attention, I assumed numbers would match and this is what they
> probably did :-).
>
> OS on my box used to report to me as Debian, and still does, but some
> years ago I have decided to skip the usual system upgrade, and after
> some more time I started to upgrade various elements by hand. So it is
> more like a tattered patchwork right now. But it does what I expect,
> hopefully.
>
> [...]
> > That's a _factor almost 2300x_ difference between the reported RSS,
> > and the amount of memory that was actually freed up by closing the
> > browser.
>
> Yeah, strange.
>
> [...]
> > On modern systems, with everything from shared libraries to
> > memory-mapped I/O to routine use of memory overcommitting, the
> > resident set size is clearly a poor indicator of the actual amount
> > of memory actively used by a complex process.
>
> Hard to tell - first I would like to learn where the hundred-giga rss
> came from...
>
> --
> Regards,
> Tomasz Rola
>
> --
> ** A C programmer asked whether computer had Buddha's nature. **
> ** As the answer, master did "rm -rif" on the programmer's home **
> ** directory. And then the C programmer became enlightened... **
> ** **
> ** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210708/12adb572/attachment.htm>
From jon at fourwinds.com Fri Jul 9 14:49:37 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 08 Jul 2021 21:49:37 -0700
Subject: [TUHS] The Unix shell: a 50-year view -- feedback wanted
Message-ID: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
I not only found this paper offensive, but was more offended that
ACM would publish something like this and give it an award to boot.
I'm planning to send the authors and ACM what's below. Would
appreciate any feedback that you could provide to make it better.
Thanks,
Jon
I read your "Unix Shell Programming: The Next 50 Years" expecting
some well thought out wisdom from learned experiences. I was
sorely disappointed.
o The paper never defines what is meant by the term "Unix shell."
I think that you're using to mean a command interpreter as
described in the POSIX 1003.2 documents.
o There is no 50 year old Unix shell. I started using Unix in the
early 1970s, and the command interpreter at the time (Ken Thompson's
shell) was nothing like later shells such as the Bourne shell (sh
since research V7 Unix), Korn shell (ksh), C shell (csh), and the
Bourne again shell (bash). The paper is missing any discussion of
prior art. In practice, shell implementations either predate the
POSIX standard or were built afterwards and include non-standard
extensions.
o The paper repeats a claim that the shell has been largely ignored by
academia and industry. Yet, it does not include any references that
support that claim. My own experience and thus opinion is the
opposite making the veracity of your claim questionable. As a reader,
such unsubstantiated claims make me treat the entire content as suspect.
o The paper applies universal complaints such as "unmaintainable" to the
shell; it doesn't call out any shell-specific problems. It doesn't
explain whether these complaints are against the scripts, the
implementation, or both. One of the reasons for the longevity of the
sh/bash shells is that experienced practicioners have been able to
write easily maintainable code. Scripts written in the 1980s are
still around and working fine.
o The paper seems to complain that the fact that the shell is documented
is a problem. This is an astonishing statement. In my decades as an
acting professional, teacher, and author, proper documentation is a key
component of being a professional.
o The paper is full of non-sequiturs such as discussions about Docker
and systemd that have nothing to to with the shell.
o The paper has many "nop" statements such as "arguably improved" that
don't actually say anything.
o Examples, such as the one on page 105 don't work.
o Proofreading should have caught things like "improve performance
performance" on page 107 among others.
o The references contain many more items than the paper actually
references. Did you plagerize the bibliography and forget to
edit it?
o The single result in Figure 1 is insufficient evidence that the
approach works on a wide variety of problems.
o The paper makes it appear that the authors don't actually understand
the semantics of the original Bourne shell. Not just my opinion; I
received an email from Steve Bourne after he read your paper, and I
consider him to be a subject matter expert.
The paper is lacking the generally accepted form of:
o What problem are you trying to solve?
o What have others done?
o What's our approach?
o How does it do?
Filtering out all of the jargon added for buzzword compliance, I think
that the paper is really trying to say:
o Programmable command interpreters such as those found in Unix-based
systems have been around for a long time. For this paper, we're
focusing on the GNU bash implementation of the POSIX P1003.2 shell.
Other command interpreters predate Unix.
o This implementation is used more often than many other scripting
languages because it is available and often installed as the default
command interpreter on most modern systems (Unix-based or otherwise).
In particular, it is often the default for Linux systems.
o The shell as defined above is being used in ways that are far more
complex than originally contemplated when Bourne created the original
syntax and semantics, much less the new features added by the POSIX
standards committee. The combination of both the POSIX and bash
extensions to the Bourne shell exposes a new set of limitations and
issues such as performance.
o While much work has been done by the bash implementors, it's primarily
been in the area of expanding the functionality, usually in a
backward-compatible manner. Other shells such as the original ksh and
later ash and zsh were implemented with an eye towards the performance
of the internals and user perspectives.
o Performance optimization using modern techniques such as JIT have been
applied to other languages but not to POSIX shell implementations. This
paper looks at doing that. It is unsurprising that techniques that have
worked elsewhere work here too.
o It's hard to imagine that the application of this technique is all that's
required for a 50-year life extension. The title of this paper implies
that it's going to be comprehensive rather than just being a shameless
plus for an author's project.
Of course, this doesn't make much of a paper. Guessing that that's why it
was so "bulked up" with irrelevancies.
It appears that all of you are in academia. I can't imagine that a paper
like this would pass muster in front of any thesis committee, much less
get that far. Not only for content, but for lack of proofreading and
editing. The fact that the ACM would publish such a paper eliminates any
regret that I may have had in dropping my ACM membership.
From noel.hunt at gmail.com Fri Jul 9 17:10:24 2021
From: noel.hunt at gmail.com (Noel Hunt)
Date: Fri, 9 Jul 2021 17:10:24 +1000
Subject: [TUHS] The Unix shell: a 50-year view -- feedback wanted
In-Reply-To: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
References: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
Message-ID: <CAGfO01zo8uFk2HHuOfXTneF461DN1YYw8b_nXKKdJba8p8F0zQ@mail.gmail.com>
Allow me to express my thanks to you for doing this.
Noel Hunt
On Fri, Jul 9, 2021 at 2:51 PM Jon Steinhart <jon at fourwinds.com> wrote:
> I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below. Would
> appreciate any feedback that you could provide to make it better.
>
> Thanks,
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210709/4f0ed2c0/attachment.htm>
From lm at mcvoy.com Fri Jul 9 23:26:46 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 9 Jul 2021 06:26:46 -0700
Subject: [TUHS] The Unix shell: a 50-year view -- feedback wanted
In-Reply-To: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
References: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
Message-ID: <20210709132646.GY10781@mcvoy.com>
I think it is great as it stands (yeah, I read all of it). If there
is a way I can sign it as well, not as an author, just as an "I agree
with everything here", tell me and I'll sign.
I continue to be dismayed at the state of the art these days, seems like
there is no art, but to have the ACM award this crap is depressing.
On Thu, Jul 08, 2021 at 09:49:37PM -0700, Jon Steinhart wrote:
> I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below. Would
> appreciate any feedback that you could provide to make it better.
>
> Thanks,
> Jon
>
>
>
>
> I read your "Unix Shell Programming: The Next 50 Years" expecting
> some well thought out wisdom from learned experiences. I was
> sorely disappointed.
>
> o The paper never defines what is meant by the term "Unix shell."
> I think that you're using to mean a command interpreter as
> described in the POSIX 1003.2 documents.
>
> o There is no 50 year old Unix shell. I started using Unix in the
> early 1970s, and the command interpreter at the time (Ken Thompson's
> shell) was nothing like later shells such as the Bourne shell (sh
> since research V7 Unix), Korn shell (ksh), C shell (csh), and the
> Bourne again shell (bash). The paper is missing any discussion of
> prior art. In practice, shell implementations either predate the
> POSIX standard or were built afterwards and include non-standard
> extensions.
>
> o The paper repeats a claim that the shell has been largely ignored by
> academia and industry. Yet, it does not include any references that
> support that claim. My own experience and thus opinion is the
> opposite making the veracity of your claim questionable. As a reader,
> such unsubstantiated claims make me treat the entire content as suspect.
>
> o The paper applies universal complaints such as "unmaintainable" to the
> shell; it doesn't call out any shell-specific problems. It doesn't
> explain whether these complaints are against the scripts, the
> implementation, or both. One of the reasons for the longevity of the
> sh/bash shells is that experienced practicioners have been able to
> write easily maintainable code. Scripts written in the 1980s are
> still around and working fine.
>
> o The paper seems to complain that the fact that the shell is documented
> is a problem. This is an astonishing statement. In my decades as an
> acting professional, teacher, and author, proper documentation is a key
> component of being a professional.
>
> o The paper is full of non-sequiturs such as discussions about Docker
> and systemd that have nothing to to with the shell.
>
> o The paper has many "nop" statements such as "arguably improved" that
> don't actually say anything.
>
> o Examples, such as the one on page 105 don't work.
>
> o Proofreading should have caught things like "improve performance
> performance" on page 107 among others.
>
> o The references contain many more items than the paper actually
> references. Did you plagerize the bibliography and forget to
> edit it?
>
> o The single result in Figure 1 is insufficient evidence that the
> approach works on a wide variety of problems.
>
> o The paper makes it appear that the authors don't actually understand
> the semantics of the original Bourne shell. Not just my opinion; I
> received an email from Steve Bourne after he read your paper, and I
> consider him to be a subject matter expert.
>
> The paper is lacking the generally accepted form of:
>
> o What problem are you trying to solve?
> o What have others done?
> o What's our approach?
> o How does it do?
>
> Filtering out all of the jargon added for buzzword compliance, I think
> that the paper is really trying to say:
>
> o Programmable command interpreters such as those found in Unix-based
> systems have been around for a long time. For this paper, we're
> focusing on the GNU bash implementation of the POSIX P1003.2 shell.
> Other command interpreters predate Unix.
>
> o This implementation is used more often than many other scripting
> languages because it is available and often installed as the default
> command interpreter on most modern systems (Unix-based or otherwise).
> In particular, it is often the default for Linux systems.
>
> o The shell as defined above is being used in ways that are far more
> complex than originally contemplated when Bourne created the original
> syntax and semantics, much less the new features added by the POSIX
> standards committee. The combination of both the POSIX and bash
> extensions to the Bourne shell exposes a new set of limitations and
> issues such as performance.
>
> o While much work has been done by the bash implementors, it's primarily
> been in the area of expanding the functionality, usually in a
> backward-compatible manner. Other shells such as the original ksh and
> later ash and zsh were implemented with an eye towards the performance
> of the internals and user perspectives.
>
> o Performance optimization using modern techniques such as JIT have been
> applied to other languages but not to POSIX shell implementations. This
> paper looks at doing that. It is unsurprising that techniques that have
> worked elsewhere work here too.
>
> o It's hard to imagine that the application of this technique is all that's
> required for a 50-year life extension. The title of this paper implies
> that it's going to be comprehensive rather than just being a shameless
> plus for an author's project.
>
> Of course, this doesn't make much of a paper. Guessing that that's why it
> was so "bulked up" with irrelevancies.
>
> It appears that all of you are in academia. I can't imagine that a paper
> like this would pass muster in front of any thesis committee, much less
> get that far. Not only for content, but for lack of proofreading and
> editing. The fact that the ACM would publish such a paper eliminates any
> regret that I may have had in dropping my ACM membership.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From jon at fourwinds.com Sat Jul 10 04:04:21 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 09 Jul 2021 11:04:21 -0700
Subject: [TUHS] The Unix shell: a 50-year view -- second pass feedback wanted
Message-ID: <202107091804.169I4L4p2778131@darkstar.fourwinds.com>
Thanks to everyone who provided me feedback on the first pass, especially
those who suggested "shopt -u flame-off". Here's the second version.
Once again, would appreciate feedback.
Thanks,
Jon
I read your "Unix Shell Programming: The Next 50 Years" expecting
some well thought out wisdom. I was sorely disappointed.
The paper is lacking the generally accepted form of:
o What problem are you trying to solve?
o What have others done?
o What's our approach?
o How does it do?
Some particulars:
o The paper never defines what is meant by the term "Unix shell."
I think that you're using it to mean a command interpreter as
described in the POSIX 1003.2 documents.
o There is no 50 year old Unix shell. I started using Unix in the
early 1970s, and the command interpreter at the time (Ken Thompson's
shell) was nothing like later shells such as the Bourne shell (sh
since research V7 Unix), Korn shell (ksh), C shell (csh), and the
Bourne again shell (bash). Unix mainstreamed the notion of a
command interpreter that was not baked into the system. The paper
lacks any discussion of prior art. In practice, shell implementations
either predate the POSIX standard or were built afterwards and
include non-standard extensions.
o The paper repeats a claim that the shell has been largely ignored by
academia and industry. Yet, it does not include any references that
support that claim. In fact, the large body of published work on
shells and ongoing work on shells such as zsh shows that claim to be
incorrect.
o The paper applies universal complaints such as "unmaintainable" to the
shell; it doesn't call out any shell-specific problems. It doesn't
explain whether these complaints are against the scripts, the
implementation, or both. One of the reasons for the longevity of the
family of shells descended from Bourne's sh is that experienced
practicioners have been able to write easily maintainable code.
Scripts written in the 1980s are still around and working fine.
o The paper seems to complain that the fact that the shell is documented
is a problem. This is astonishing. Proper documentation has always
been a key component of being a professional in my decades of experience.
As a matter of fact, my boss telling me that "nobody will give a crap
about your work unless you write a good paper" when I was a teenager
at Bell Labs is what led me to UNIX and nroff.
o The paper includes non-sequiturs such as discussions about Docker
and systemd that have nothing to to with the shell.
o The paper has many "nop" statements such as "arguably improved" that
don't actually say anything.
o Examples, such as the one on page 105 don't work as there is no input
to "cut".
o The single result in Figure 1 is insufficient evidence that the
approach works on a wide variety of problems.
o The paper gives the appearance that the authors don't actually understand
the semantics of the original Bourne shell. Not just my opinion; I
received an email from Steve Bourne after he read your paper, and I
consider him to be a subject matter expert.
o Proofreading should have caught things like "improve performance
performance" on page 107 among others.
I think that the paper is really trying to say:
o Programmable command interpreters such as those found in Unix-based
systems have been around for a long time. For this paper, we're
focusing on the GNU bash implementation of the POSIX P1003.2 shell.
Other command interpreters predate Unix.
o This implementation is used more often than many other scripting
languages because it is available and often installed as the default
command interpreter on most modern systems (Unix-based or otherwise).
In particular, it is often the default for Linux systems.
o The shell as defined above is being used in ways that are far more
complex than originally contemplated when Bourne created the original
syntax and semantics, much less the new features from kash adopted by
the POSIX standards committee. The combination of both the POSIX and
bash extensions to the Bourne shell exposes a new set of limitations
and issues such as performance.
o While much work has been done by the bash implementors, it's primarily
been in the area of expanding the functionality, usually in a
backward-compatible manner. Other shells such as the original ksh and
later ash and zsh were implemented with an eye towards the performance
of the internals and user perspectives.
o Performance optimization using modern techniques such as JIT compilation
have been applied to other languages but not to POSIX shell implementations.
This paper looks at doing that. It is unsurprising that techniques that
have worked elsewhere work here too.
It's hard to imagine that the application of this technique is all that's
required for a 50-year life extension. The title of this paper implies
that it's going to be comprehensive but instead concentrates on a couple
of projects. It ignores other active work on shells such as "fish". While
the issues with the paper remain, they would not have been quite so glaring
had it had a more modest title such as "Applying JIT Compilation to the
POSIX Shell".
From cowan at ccil.org Sat Jul 10 05:23:57 2021
From: cowan at ccil.org (John Cowan)
Date: Fri, 9 Jul 2021 15:23:57 -0400
Subject: [TUHS] The Unix shell: a 50-year view -- feedback wanted
In-Reply-To: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
References: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
Message-ID: <CAD2gp_QZMp2VGQHfOZBcBsABZvJhbBmMXjKSkzV4Yde4VXhuKA@mail.gmail.com>
On Fri, Jul 9, 2021 at 12:50 AM Jon Steinhart <jon at fourwinds.com> wrote:
I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below. Would
> appreciate any feedback that you could provide to make it better.
>
I too would like to (virtually) sign this.
I also point out (not for inclusion in your piece) that the fastest path to
fame and what in academia counts as fortune is to write a paper with a
superficially plausible argument that some well-known fact or
well-established conclusion is wrong. This immediately draws the mantle of
Galileo over the author, but instead of the author being imprisoned for
life by the Papal Inquisition, the paper becomes the subject of raves, the
author becomes a hero, and the discipline may even be said to have taken a
new turn as everyone rushes to follow and compete.
But often the little boy in "The Emperor's New Clothes" is either deluded
or trying to gain glory by daring to annoy the Emperor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210709/04b04d9e/attachment.htm>
From skogtun at gmail.com Sat Jul 10 05:54:47 2021
From: skogtun at gmail.com (Harald Arnesen)
Date: Fri, 9 Jul 2021 21:54:47 +0200
Subject: [TUHS] The Unix shell: a 50-year view -- second pass feedback
wanted
In-Reply-To: <202107091804.169I4L4p2778131@darkstar.fourwinds.com>
References: <202107091804.169I4L4p2778131@darkstar.fourwinds.com>
Message-ID: <e0e2ca00-24b3-ed1e-8949-9f49b631f8ea@gmail.com>
Jon Steinhart [09/07/2021 20.04]:
> o The shell as defined above is being used in ways that are far more
> complex than originally contemplated when Bourne created the original
> syntax and semantics, much less the new features from kash adopted by
^^^^
> the POSIX standards committee. The combination of both the POSIX and
> bash extensions to the Bourne shell exposes a new set of limitations
> and issues such as performance.
From michael at kjorling.se Sat Jul 10 06:14:25 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Fri, 9 Jul 2021 20:14:25 +0000
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <YOdyjcVCL5TS3VBg@mit.edu>
References: <CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAD2gp_TNjzZCT8TCfHm_9ARZqFEaWL=6OdT6DOxY9auWY4=WHA@mail.gmail.com>
<20210706231659.GA13225@tau1.ceti.pl> <YOT5ajNhoUqyBqvi@mit.edu>
<20210707183222.GA9897@tau1.ceti.pl>
<6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>
<YOdyjcVCL5TS3VBg@mit.edu>
Message-ID: <9732faa4-55cf-44c4-9bdc-47c4c9b40c3f@localhost>
On 8 Jul 2021 17:47 -0400, from tytso at mit.edu (Theodore Ts'o):
>> I'm going to stick my neck out here by saying that the VSZ and RSS
>> values reported by ps, at least for Firefox, are largely meaningless.
>
> No, VSZ is correct, but it's confusing since it includes things that
> you might not expect. VSZ includes *all* virtual memory space
> consumed by a process.
You may very well be correct. That would, however, seem to me to make
it _correct_, but still not necessarily _meaningful_ for trying to
determine the amount of memory used by a _specific_ process; and
similarly for the RSS.
>> I started my usual Firefox instance, which has a handful of plugins,
>> about a metric gazillion bookmarks, and has been my main web browser
>> profile for years (so it probably has collected some crud over time).
>> `ps auxw` reported that process as having a total RSS of a whopping
>> 374 GB.
>
> I don't think that's right. Are you sure it's not 374MB? I started
> firefox-esr on my Debian machine, and the PS output is:
On this, I believe I must stand corrected.
For my previous post, I checked the man page for ps, and noted that
RSS and VSZ are both reported in units of 1 KiB. For an attempt just
now, the ps output is similarly:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
michael 29890 51.8 0.7 2728696 255456 tty2 Sl+ 21:46 0:06 firefox-esr
michael 29942 4.7 0.3 2415008 106448 tty2 Sl+ 21:46 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF
michael 29994 38.3 0.7 34043160 240612 tty2 Sl+ 21:46 0:04 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF
michael 30168 3.2 0.2 2400636 72992 tty2 Sl+ 21:46 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF
On my system, unless I need to get a different calculator, 0.7% of
memory is either 229 В± <16 or 688 В± <49 MiB, depending on whether it
counts only RAM or also includes swap space.
The 249 MiB RSS of the main process also much more closely matches the
difference that was reported by `free` in my previous experiment.
Oddly, when trying the same thing again now, the difference as
reported by `free` is 423 MiB, so I'm not quite sure what's going on
there, but at least all of those numbers are considerably more
_plausible_, both in isolation and in relation to other relevant
measurements.
I'm honestly not sure how I went from the `ps` output (which wasn't
particularly dissimilar from the above, though of course I don't know
what the exact numbers were since I didn't record them) and the unit
of measurement being KiB, to going from KiB straight to GiB.
> That's not because the hello world program actually used half a
> megabyte worth of the C library; but rather, almost half a megabyte of
> the C library has been paged in to support all of the processes
> currently running in the system. It also follows that every process
> using shared library is going to have an RSS which is at least 512k.
This is definitely a point on which I agree, and which I tried to
point out with the mention of shared libraries in my previous post.
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
From tytso at mit.edu Sat Jul 10 06:26:11 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Fri, 9 Jul 2021 16:26:11 -0400
Subject: [TUHS] The Unix shell: a 50-year view -- feedback wanted
In-Reply-To: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
References: <202107090449.1694nbum2752949@darkstar.fourwinds.com>
Message-ID: <YOiw41Ddt+rkyV2k@mit.edu>
On Thu, Jul 08, 2021 at 09:49:37PM -0700, Jon Steinhart wrote:
> o It's hard to imagine that the application of this technique is all that's
> required for a 50-year life extension. The title of this paper implies
> that it's going to be comprehensive rather than just being a shameless
> plus for an author's project.
Spelling nit: I believe you meant to say "shameless plug..." (s/plus/plug/)
> It appears that all of you are in academia. I can't imagine that a paper
> like this would pass muster in front of any thesis committee, much less
> get that far. Not only for content, but for lack of proofreading and
> editing. The fact that the ACM would publish such a paper eliminates any
> regret that I may have had in dropping my ACM membership.
It looks like this was originally a position paper for the Workshop on
Hot Topics in Operating Systems (aka HotOS). As a workshop paper, it
would have had a much lower standard of than say, if this was being
presented at say, SOSP or ASPLOS. Workshop papers are supposed to be
provocative and suggest "new directions". Sometimes new directions
turn out to just be dead ends, and while some things presented at
workshops will grow up to be a full paper at a highly respected
conference, other ideas get presented at a workshop and are never
heard from again. :-)
I'd have to think to come up with examples, but I'm pretty sure I've
seen sillier ideas as workshops papers. More impractical ideas, for
certain.
I have observed that the things that will get funding for academic
research, and things which are considered interesting from a industry
or practitioner's perspective, tends to diverge in any field, and the
divergence increases over time.
It might or might not be the case that "the shell is a promising area
of research". Even if it is true, there are plenty of things which
generate research papers, and serve to help education graduate
students, but which ultimately end up being completely useless from
the industry practitioners perspective. I may be overly cynical, but
there are plenty of papers at many a conference, even highly respected
ones by tenture-track committees, which inspires nothing but a yawn
from me, and personally, that doesn't bother me; what consenting
adults do within the confines of academia is their business.
Again, I've seen worse in terms of "my tax dollars at play".
If we're lucky, even if the actual object of the research is useless,
sometimes it can sparc some insight that makes my time spent at such a
conference not a complete waste --- and even if it isn't at least
it's fertile recruiting ground for new college grads for $WORK. :-)
- Ted
From rtomek at ceti.pl Sat Jul 10 08:19:24 2021
From: rtomek at ceti.pl (Tomasz Rola)
Date: Sat, 10 Jul 2021 00:19:24 +0200
Subject: [TUHS] [tuhs] The Unix shell: a 50-year view
In-Reply-To: <CAC20D2NdVK1zGeACJW8jZfTm85CyWq8CZd6oZAAfRaRZgovNvg@mail.gmail.com>
References: <CMM.0.95.0.1625261060.beebe@gamma.math.utah.edu>
<20210702213648.GW817@mcvoy.com>
<CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<alpine.DEB.2.21.2107021910240.15013@sd-119843.dedibox.fr>
<396911b232bae5938068a14fe0f7181e@firemail.de>
<CAEoi9W4NXd-yajWk9bcb1X9eK_Ws17TBJOpDE6M-Qf+uLQ2v6A@mail.gmail.com>
<20210704004757.GB24671@tau1.ceti.pl>
<CAEoi9W7fLGFQMPUcS2E0VAANnPXDVrbxGFs++Nv5W42rxoNxYg@mail.gmail.com>
<20210705071450.GA12885@tau1.ceti.pl>
<CAC20D2NdVK1zGeACJW8jZfTm85CyWq8CZd6oZAAfRaRZgovNvg@mail.gmail.com>
Message-ID: <20210709221924.GA17181@tau1.ceti.pl>
On Tue, Jul 06, 2021 at 12:05:04PM -0400, Clem Cole wrote:
[...]
> Ouch!!! This is so much important that you have missed in this statement,
> as this is a great example of not seeing the forest because of all the
> trees. You are right that C and UNIX's success was intertwined but I think
> you are missing the drivers for that. They were successful because of
> other things and because they were successful, we have them today.
[...]
Clem, thanks a lot for writing this. I think I have connected few dots
now. Like, I was long aware that there were various groups of computer
users, but never before I had the thought about how this "divide"
contributed so much to creation and adoption of Unix.
I suppose I like Unix even more now.
[...]
> The idea of lots of little programs that cooperate with each other is not
> what IBM and the like wanted/was providing. They were selling closed
> 'solutions' complete SW systems ("walled gardens" controlled by them or
> their programming minions) and yes needed the big iron they sold. Note
> the IBM 'solutions were not sold to engineers, their products were sold on
> the golf course to the 'managers' of what we know call IT shops.
Ahem. I do not see myself selling or buying during golf
course... Especially if it has to do with computers...
[...]
> The important thing is that the latter group (not enterprise) did not have
> as much money but was a completely different population. UNIX is 100% a
> 'Christiansen style Disruption' ( read his book completely if you have
> not, please).
I will see if I can have my hand on it.
> It's a 'lessor technology,' running on smaller equipment,
> targeting a new and different consumer who does not care that it is 'not as
> good' as the established products. If you compare UNIX to IBM's OS or VMS
> for that matter, UNIX does not have the 'features' that are valued by the
> 'enterprise market.'
>
> Ken/Dennis, *et al*, clearly do not care -- they were building something
> they (the engineers) needed and wanted (thankfully). And yes it had to run
> on modest hardware because that is what they could afford and had access
> to. But because since the HW was modest, that forces a mindset of what are
> we really doing on the SW? How can we do it effectively. The designers
> are asking an important research question? *Maybe some of these other
> schemes are not necessary*.
I definitely like this attitude.
> You are correct the C grew because of UNIX, but you kind of have it
> backward. I'm a perfect example of what happened. These new
> microprocessors from Intel/Zilog/Moto/MOS Tech became available to us
> (engineers mind you). Hey, I was at CMU in the mid-1970s, I even had
> access to the BLISS sources, but most people did not. A BLISS cross
> compiler binary cost $5K per CPU!!!
Yikes. Five kilodollars, what a deal.
When I learned C, in middle/late 80-ties, it was my third language
after Basic and Pascal. I did not have computer at that time and I
wrote short programs in a notebook. I wonder if I could locate the
notebook and if any of this code would run. But, compared to the first
two, C had something fresh in it. Nowadays, however, this freshness is
a little bit trapped under a ton of supporting libraries. Back at the
time, the fact there was a C compiler on every computer I heard about,
and standard library gave it a bit of unified look, and I could write
C oneliners on less paper, more idiomatic (saves time! all those
begin/end words replaced by mere curly braces, very nice) - all of
this made C very interesting to me.
[...]
> The key point is that UNIX was inexpensive and worked on modest hardware.
> Yes C came with it and that is why I think we use it not BLISS, BCPL, or
> some flavor of PLx today.
I hope C would have been invented even without Unix.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
From mah at mhorton.net Sat Jul 10 13:17:14 2021
From: mah at mhorton.net (Mary Ann Horton)
Date: Fri, 9 Jul 2021 20:17:14 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
<CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
Message-ID: <9d28ce46-f314-bc00-d2db-1f11b353b9f3@mhorton.net>
As I recall, Rogue began to appear in late 1980 or early 81 at Berkeley.
I primarily remember it on the Vax. But I thought Toy et al originally
wrote it at UCSB and then it came to UCB. It was written for the Arnold
curses, and served as the first major application to test it out.
I loved that game. Still do, although I rarely find time to play it
anymore. It's widely available on web emulators these days, just search
for "play rogue online". It will likely be the color DOS version, but it
plays roughly the same.
The source was widely available and widely customized. I think I brought
a copy with me to Bell Labs in 1981 where Bob Flandrena eventually
sprouted the "brogue" variant. Some of the monsters could eat into the
walls between rooms, and when there was a line of several chasing you
down a hallway, one or two of them would pull around to pass... Brogue
worked on my new curses, it was in effect part of the test suite.
Eric, of course, is the authority noting that ing70 was "i" and, as I
recall, ingvax was "j".
В В В Mary Ann
On 7/2/21 2:09 PM, Dan Cross wrote:
> On Fri, Jul 2, 2021 at 9:07 AM Clem Cole <clemc at ccc.com
> <mailto:clemc at ccc.com>> wrote:
>
> On Fri, Jul 2, 2021 at 8:15 AM Dan Cross <crossd at gmail.com
> <mailto:crossd at gmail.com>> wrote:
>
> It is; it looks like it was first distributedВ with
> 4.3BSD-Tahoe. The sources there are listedВ as "public domain
> rogue", but I'm not sure about the provenance of that code.
>
> That sounds right, youВ should ask Ken Arnold offline, I bet he had
> a better idea.He would have made them available to Keith.
>
>
> Great idea. I reached out on linked in, but don't have an email
> address for Ken. Anyone have his contact information?
>
> I'm curious if e.g. Mary Ann has any thoughts here, since she took
> over maintaining curses at some point and might have gotten some of
> the inside story?
>
> Thanks for the responses so far, all.
>
> В В В В - Dan C.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210709/e616e4b8/attachment.htm>
From fair-tuhs at netbsd.org Sat Jul 10 14:00:23 2021
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Fri, 09 Jul 2021 21:00:23 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <9d28ce46-f314-bc00-d2db-1f11b353b9f3@mhorton.net>
References: <CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
Message-ID: <6602.1625889623@cesium.clock.org>
I collected some stuff in from those days; here's a BerkNet map
dated November 1981; mtime on my file is Jan 2 1984:
T H E B E R K E L E Y N E T W O R K
November 30, 1981
{ARPAnet} Ing70 Legend
@ # - or | 1200 Baud
@ # = or # 9600 Baud
C70 IngVAX {UUCPland} Image @ ARPAnet
# # / |
# # / |
Onyx======ARPAvax====CSvax=====UCBCAD=====ESvax-----EECS40
# # |
Novax # A |
# # |
F ======= G ======= C ------ Cory ----MathStat
# #
# #
D E ======== B
|
|
SRC
M A C H I N E G U I D E
Name Char Run By Type Vers. Default Mach. Comments
---- ---- ------ ---- ---- ------------- --------
A a C F & O 11/70 V7 C PhotoTypesetter Machine
B b C F & O 11/70 V7 D School of Business Administration Machine
C c C F & O 11/70 V7 A
D d C F & O 11/70 V7 C
E e C F & O 11/70 V7 C
F f C F & O 11/70 V7 E
G g C F & O VAX V7 E VAX Populi
Ing70 i ERL 11/70 V6 IngVAX
IngVAX j Ingres Group VAX V7 Ing70 Ingres Bergman
Image m EE-Signal Proc. Vax750 V7 ESvax
Kim n Floating Point VAX V7 CSvax Kim NoVAX
ESvax o EECS-CE Res. VAX V7 CSvax VAX Vobiscum (UUCP passive)
UCBCAD p Newton VAX V7 ESvax (UUCP passive)
ARPAvax r ARPA/CSRG VAX V7 CSvax Bert (UUCP passive)
SRC s Survey Res. 11/34 V6 D
MathStat t Math/Stat Dept 11/45 V7 Cory
C70 u ARPA/CSRG BBN C/70 ARPAVAX ARPAnet Server
CSvax v CS Research VAX V7 Cory Ernie CoVAX (UUCP active)
Cory y EECS Dept. 11/70 V7 CSvax EECS Instructional Machine (UUCP passive)
EECS40 z EECS Dept. 11/40 V6 Ing70 EECS Administrative Machine (Soon to be replace with a Vax-11/750)
(the following machines are not connected or do not exist yet)
Virus k MicroBiology 11/40 V7 E Politics Prevent Connection to the BerkNet
VLSI l Brodersen VAX V7 Image On order, exp. June 81
HackOnyx q CSUA Hackers Onyx V7 Cory Existing, exp. March 82
STATVAX w Stat Dept. COMET V7 MathStat On order, exp. Nov 81
Onyx x CSRG (Fabry) Onyx V7 Cory z8000 Micro running v7 UNIX (UUCP passive)
(Letters used: A-Z (total of 26)) (K & L may never happen)
Files 200,000 to 500,000 bytes are only transmitted between midnight and 6AM.
There is a file-length limit of 500,000 bytes, so that larger files must be split up (use the split command).
TeleNet is connected to the Port Selector (all of the Computer Center) {Network Address: 41587}
From nobozo at gmail.com Sat Jul 10 15:04:55 2021
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 9 Jul 2021 22:04:55 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <9d28ce46-f314-bc00-d2db-1f11b353b9f3@mhorton.net>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
<CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
<9d28ce46-f314-bc00-d2db-1f11b353b9f3@mhorton.net>
Message-ID: <909572cb-cdc7-ebfa-d01b-7adbadcfa1c2@gmail.com>
On 7/9/21 8:17 PM, Mary Ann Horton wrote:
> As I recall, Rogue began to appear in late 1980 or early 81 at Berkeley.
> I primarily remember it on the Vax. But I thought Toy et al originally
> wrote it at UCSB and then it came to UCB.
I was at UCSB from the time the first Unix machine arrived until
1985. I'm not aware of any Rogue activity there.
> The source was widely available and widely customized. I think I brought
> a copy with me to Bell Labs in 1981 where Bob Flandrena eventually
> sprouted the "brogue" variant. Some of the monsters could eat into the
> walls between rooms, and when there was a line of several chasing you
> down a hallway, one or two of them would pull around to pass... Brogue
> worked on my new curses, it was in effect part of the test.
I heard there was a version that contained Ed Gould roaming around.
Jon
From ralph at inputplus.co.uk Sat Jul 10 21:51:35 2021
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 10 Jul 2021 12:51:35 +0100
Subject: [TUHS] The Unix shell: a 50-year view
In-Reply-To: <202107071828.167ISgdN2686558@darkstar.fourwinds.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
Message-ID: <20210710115135.22FDC21C4E@orac.inputplus.co.uk>
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.
From henry.r.bent at gmail.com Sat Jul 10 23:54:28 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 10 Jul 2021 09:54:28 -0400
Subject: [TUHS] The Unix shell: a 50-year view
In-Reply-To: <20210710115135.22FDC21C4E@orac.inputplus.co.uk>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
Message-ID: <CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210710/e2f29fd3/attachment.htm>
From ralph at inputplus.co.uk Sun Jul 11 00:12:17 2021
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 10 Jul 2021 15:12:17 +0100
Subject: [TUHS] The Unix shell: a 50-year view
In-Reply-To: <CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
Message-ID: <20210710141217.8795F21CD1@orac.inputplus.co.uk>
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.
From jon at fourwinds.com Sun Jul 11 02:57:18 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 10 Jul 2021 09:57:18 -0700
Subject: [TUHS] Death by bug [formerly The Unix shell: a 50-year view]
In-Reply-To: <20210710141217.8795F21CD1@orac.inputplus.co.uk>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
Message-ID: <202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
Ralph Corderoy writes:
> 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.
C'mon folks, is it really that hard to have a relevant subject line?
Especially you Ralph, as I know that you're an nmh user so it's just
a text editor :-)
So while I agree with your example, I guess that I was contemplating
the sort of example that makes the public take notice. Arguments
about statistical models are lost on 99% of the population.
Jon
From jon at fourwinds.com Sun Jul 11 05:18:04 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 10 Jul 2021 12:18:04 -0700
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review of
letter
Message-ID: <202107101918.16AJI4N02822420@darkstar.fourwinds.com>
Once again, thanks to everybody who as contributed to making this a
better letter. Many of you have asked to be co-signers. Please
let me know if I've included your name by mistake or if you'd like
your name to be added. And, of course, let me know if any more
edits are required.
BTW, except where I'm quoting the paper I use UNIX instead of Unix
as that's what I believe is the correct form. Please let me know
if that's not correct.
Thanks,
Jon
I read the "Unix Shell Programming: The Next 50 Years" paper
expecting some well thought out wisdom. I was sorely disappointed.
The paper is lacking the generally accepted form of:
o What problem are you trying to solve?
o What have others done?
o What's our approach?
o How does it do?
Some particulars:
o The paper never defines what is meant by the term "Unix shell."
I think that you're using it to mean a command interpreter as
described in the POSIX 1003.2 documents.
o The paper makes liberal use of the term "Unix" such as "... in
every Unix distribution." While systems descended from UNIX
abound few actual instances of UNIX exist today.
o There is no 50-year-old UNIX shell. I started using UNIX in the
early 1970s, and the command interpreter at the time (Ken Thompson's
shell) was nothing like later shells such as the Bourne shell (sh
since research V7 UNIX), Korn shell (ksh), C shell (csh), and the
Bourne again shell (bash). UNIX mainstreamed the notion of a
command interpreter that was not baked into the system. The paper
lacks any discussion of prior art. In practice, shell implementations
either predate the POSIX standard or were built afterwards and
include non-standard extensions.
o The paper repeatedly claims that the shell has been largely ignored by
academia and industry. Yet, it does not include any references to
support that claim. In fact, the large body of published work on
shells and ongoing work on shells such as zsh shows that claim to be
incorrect.
o The large number of pejorative statements detract from the academic
value of the paper. And, in my opinion, these statements are provably
false. It reads as if the authors are projecting their personal
opinions onto the rest of the world.
o The paper applies universal complaints such as "unmaintainable" to the
shell; it doesn't call out any shell-specific problems. It doesn't
explain whether these complaints are against scripts, implementations,
or both. One of the reasons for the longevity of the family of shells
descended from Bourne's sh is that experienced practitioners have been
able to write easily maintainable code. Scripts written in the 1980s
are still around and working fine.
o The paper seems to complain about the fact that the shell is documented.
This is astonishing. Proper documentation has always been a key
component of being a professional, at least in my decades of experience.
As a matter of fact, my boss telling me that "nobody will give a crap
about your work unless you write a good paper" when I was a teenager
at Bell Labs is what led me to UNIX and roff.
o The paper includes non-sequiturs such as discussions about Docker
and systemd that have nothing to to with the shell.
o The paper has many "no-op" statements such as "arguably improved" that
provide no useful information.
o The example on page 105 don't work as there is no input to "cut".
o The single result in Figure 1 is insufficient evidence that the
approach works on a wide variety of problems.
o The paper gives the appearance that the authors don't actually understand
the Bourne shell semantics. Not just my opinion; Steve Bourne expressed
that in an email to me after he read your paper, and I consider him to be
a subject matter expert.
o The paper confuses the performance of the shell with the performance of
external commands executed by the shell.
o Proofreading should have caught things like "improve performance
performance" on page 107 among others.
I think that the paper is really trying to say:
o Programmable command interpreters such as those found in UNIX based
systems have been around for a long time. For this paper, we're
focusing on the GNU bash implementation of the POSIX P1003.2 shell.
Other command interpreters predate UNIX.
o This implementation is used more often than many other scripting
languages because it is available and often installed as the default
command interpreter on most modern systems (UNIX-based and otherwise).
In particular, it is often the default for Linux systems.
o The shell as defined above is being used in more complex environments
than existed at the time of its creation. This exposes a new set of
performance issues.
o While much work has been done by the bash implementers, it's primarily
been in the area of expanding the functionality, usually in a
backward-compatible manner. Other shells such as the original ksh and
later ash and zsh were implemented with an eye towards the performance
of the internals and user perspectives.
o Performance optimization using modern techniques such as JIT compilation
have been applied to other languages but not to POSIX shell implementations.
This paper looks at doing that. It is unsurprising that techniques that
have worked elsewhere work here too.
It's hard to imagine that the application of this technique is all that's
required for a 50-year life extension. The title of this paper implies
that it's going to be comprehensive but instead concentrates on a couple
of projects. It ignores other active work on shells such as "fish". While
it wouldn't eliminate the issues with the paper, they would not have been
quite so glaring had it had a more modest title such as "Improving POSIX
Shell Performance with JIT Compilation".
Jon Steinhart plus John Cowan, Warner Losh,
John Dow, Steve Bourne, Larry McVoy, and Clem Cole
From rdm at cfcl.com Sun Jul 11 05:27:21 2021
From: rdm at cfcl.com (Rich Morin)
Date: Sat, 10 Jul 2021 12:27:21 -0700
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
In-Reply-To: <202107101918.16AJI4N02822420@darkstar.fourwinds.com>
References: <202107101918.16AJI4N02822420@darkstar.fourwinds.com>
Message-ID: <3D562A05-3081-4C09-9D36-743FC42530F0@cfcl.com>
> Unix (/Л€juЛђnЙЄks/; trademarked as UNIX) is a family of multitasking, multiuser computer operating systems that derive from the original AT&T Unix, whose development started in the 1970s at the Bell Labs research center by Ken Thompson, Dennis Ritchie, and others. ... -- https://en.wikipedia.org/wiki/Unix
Perhaps UNIX is to Unix as STREAMS is to streams? (:-).
-r
> On Jul 10, 2021, at 12:18, Jon Steinhart <jon at fourwinds.com> wrote:
>
> BTW, except where I'm quoting the paper I use UNIX instead of Unix
> as that's what I believe is the correct form. Please let me know
> if that's not correct.
From jnc at mercury.lcs.mit.edu Sun Jul 11 06:02:37 2021
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 10 Jul 2021 16:02:37 -0400 (EDT)
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
Message-ID: <20210710200237.28FA018C0AB@mercury.lcs.mit.edu>
> From: Jon Steinhart
> I use UNIX instead of Unix as that's what I believe is the correct form.
Well, Bell documentation uses "UNIX" through V6:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/doc/start/start
"Unix" starts to appear with V7:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=V7/usr/doc/setup
As mentioned, the trademark is "UNIX".
I don't really have a fixed position on _the_ way to spell it: when I'm
wiriting about a specific version (e.g. V6) I use the capitalization as of
that version; for general text I'd probably use 'Unix', as that seems to be
general now. But I could easily be convinced otherwise.
Noel
From beebe at math.utah.edu Sun Jul 11 06:09:14 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sat, 10 Jul 2021 14:09:14 -0600
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
In-Reply-To: <20210710200237.28FA018C0AB@mercury.lcs.mit.edu>
Message-ID: <CMM.0.95.0.1625947754.beebe@gamma.math.utah.edu>
Jon Steinhart writes
> I use UNIX instead of Unix as that's what I believe is the correct form.
Brian Kernighan addresses this issue in section 7.3 of his
recent memoir: it has "UNIX A History and a Memoir" on the
cover, but prefers "Unix" in the rest of that book, except
in the noted section. He also refers back to the 1984
book with Rob Pike, "The UNIX Programming Environment",
in which the typography uses small caps for "UNIX".
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From jon at fourwinds.com Sun Jul 11 06:11:36 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 10 Jul 2021 13:11:36 -0700
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
In-Reply-To: <CMM.0.95.0.1625947754.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1625947754.beebe@gamma.math.utah.edu>
Message-ID: <202107102011.16AKBaVh2824331@darkstar.fourwinds.com>
Nelson H. F. Beebe writes:
> Jon Steinhart writes
>
> > I use UNIX instead of Unix as that's what I believe is the correct form.
>
> Brian Kernighan addresses this issue in section 7.3 of his
> recent memoir: it has "UNIX A History and a Memoir" on the
> cover, but prefers "Unix" in the rest of that book, except
> in the noted section. He also refers back to the 1984
> book with Rob Pike, "The UNIX Programming Environment",
> in which the typography uses small caps for "UNIX".
Yeah, small caps was what I always considered correct.
From mah at mhorton.net Sun Jul 11 07:09:08 2021
From: mah at mhorton.net (Mary Ann Horton)
Date: Sat, 10 Jul 2021 14:09:08 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <909572cb-cdc7-ebfa-d01b-7adbadcfa1c2@gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAEoi9W7K7h5sdSnXeRcVjLd-JOuyDq6zYx8QVpwGhXKrO3k5cw@mail.gmail.com>
<CAC20D2Oo62Q-PemN7r5RBxjVS+fsYvKddmu73xBGBnZkFWr+1w@mail.gmail.com>
<CAEoi9W6-HvePqqLe=Yhh=_tRNPego98J3c3nD7oGjkqwgz9=rg@mail.gmail.com>
<9d28ce46-f314-bc00-d2db-1f11b353b9f3@mhorton.net>
<909572cb-cdc7-ebfa-d01b-7adbadcfa1c2@gmail.com>
Message-ID: <9e0384b1-c0be-379f-422c-3c86384c3b96@mhorton.net>
On 7/9/21 10:04 PM, Jon Forrest wrote:
>
>
> On 7/9/21 8:17 PM, Mary Ann Horton wrote:
>> As I recall, Rogue began to appear in late 1980 or early 81 at
>> Berkeley. I primarily remember it on the Vax. But I thought Toy et al
>> originally wrote it at UCSB and then it came to UCB.
>
> I was at UCSB from the time the first Unix machine arrived until
> 1985. I'm not aware of any Rogue activity there.
>
The brain synapses have grown dusty. I meant UC Santa Cruz.
From robpike at gmail.com Sun Jul 11 07:54:26 2021
From: robpike at gmail.com (Rob Pike)
Date: Sun, 11 Jul 2021 07:54:26 +1000
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
In-Reply-To: <202107102011.16AKBaVh2824331@darkstar.fourwinds.com>
References: <CMM.0.95.0.1625947754.beebe@gamma.math.utah.edu>
<202107102011.16AKBaVh2824331@darkstar.fourwinds.com>
Message-ID: <CAKzdPgyOVJk+d-N6H8Gtyy4P4wzczpEP1VpwXORFERV=R=qafw@mail.gmail.com>
Yes, a related issue came up when dmr rebelled when the lawyers made him
rewrite a phrase when reprinting a paper in the BSTJ. For some reason, he
didn't prefer the rewrite: "PDP-11 computer system UNIX system file system".
-rob
On Sun, Jul 11, 2021 at 6:12 AM Jon Steinhart <jon at fourwinds.com> wrote:
> Nelson H. F. Beebe writes:
> > Jon Steinhart writes
> >
> > > I use UNIX instead of Unix as that's what I believe is the correct
> form.
> >
> > Brian Kernighan addresses this issue in section 7.3 of his
> > recent memoir: it has "UNIX A History and a Memoir" on the
> > cover, but prefers "Unix" in the rest of that book, except
> > in the noted section. He also refers back to the 1984
> > book with Rob Pike, "The UNIX Programming Environment",
> > in which the typography uses small caps for "UNIX".
>
> Yeah, small caps was what I always considered correct.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210711/4eee2f23/attachment.htm>
From robpike at gmail.com Sun Jul 11 07:55:12 2021
From: robpike at gmail.com (Rob Pike)
Date: Sun, 11 Jul 2021 07:55:12 +1000
Subject: [TUHS] The Unix shell: a 50-year view - hopefully final review
of letter
In-Reply-To: <CAKzdPgyOVJk+d-N6H8Gtyy4P4wzczpEP1VpwXORFERV=R=qafw@mail.gmail.com>
References: <CMM.0.95.0.1625947754.beebe@gamma.math.utah.edu>
<202107102011.16AKBaVh2824331@darkstar.fourwinds.com>
<CAKzdPgyOVJk+d-N6H8Gtyy4P4wzczpEP1VpwXORFERV=R=qafw@mail.gmail.com>
Message-ID: <CAKzdPgy-eCpPitDM6DBkJFNvCTPMQKrVC-pXVjTFaOoVdbnFTA@mail.gmail.com>
(There were some в„ў's in there too.)
On Sun, Jul 11, 2021 at 7:54 AM Rob Pike <robpike at gmail.com> wrote:
> Yes, a related issue came up when dmr rebelled when the lawyers made him
> rewrite a phrase when reprinting a paper in the BSTJ. For some reason, he
> didn't prefer the rewrite: "PDP-11 computer system UNIX system file system".
>
> -rob
>
>
> On Sun, Jul 11, 2021 at 6:12 AM Jon Steinhart <jon at fourwinds.com> wrote:
>
>> Nelson H. F. Beebe writes:
>> > Jon Steinhart writes
>> >
>> > > I use UNIX instead of Unix as that's what I believe is the correct
>> form.
>> >
>> > Brian Kernighan addresses this issue in section 7.3 of his
>> > recent memoir: it has "UNIX A History and a Memoir" on the
>> > cover, but prefers "Unix" in the rest of that book, except
>> > in the noted section. He also refers back to the 1984
>> > book with Rob Pike, "The UNIX Programming Environment",
>> > in which the typography uses small caps for "UNIX".
>>
>> Yeah, small caps was what I always considered correct.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210711/2b660fd5/attachment.htm>
From ralph at inputplus.co.uk Sun Jul 11 18:53:46 2021
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 11 Jul 2021 09:53:46 +0100
Subject: [TUHS] Death by bug
In-Reply-To: <202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
Message-ID: <20210711085346.1951E21F16@orac.inputplus.co.uk>
Hi Jon,
> So while I agree with your example, I guess that I was contemplating
> the sort of example that makes the public take notice. Arguments
> about statistical models are lost on 99% of the population.
True.
I don't know of any but if I had to pick an area where they might be
occurring it would be medical devices. I've been an external reviewer
of a company's embedded C code for a medical device in the past,
bare-metal, simple pre-emptive round-robin task-switcher, etc., though
my suggestion is nothing to do with their quality of work or products,
just that the level of detail they went to shows how slacker companies
could err.
The Therac-25 gave fatal radiation doses in a few cases. These were
obvious when they occurred. https://en.wikipedia.org/wiki/Therac-25
What if a medical device which sits in the background quietly doing its
continuous, but sometimes vital, thing had the occasional hiccough from
which it recovered? If the blip is only fatal in patients which were
already touch and go and device fault left no obvious sign to suggest
death wasn't caused by the initial ailment then the cause of death would
be, quite reasonably, assumed.
Given some devices are present in large numbers for many years in
hospitals, and there's a lot of hospitals, an unnoticed bug could be
steadily chipping away at its human overlords.
--
Cheers, Ralph.
From arnold at skeeve.com Sun Jul 11 19:04:53 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 11 Jul 2021 03:04:53 -0600
Subject: [TUHS] Death by bug
In-Reply-To: <20210711085346.1951E21F16@orac.inputplus.co.uk>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
Message-ID: <202107110904.16B94rKu012217@freefriends.org>
Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> Given some devices are present in large numbers for many years in
> hospitals, and there's a lot of hospitals, an unnoticed bug could be
> steadily chipping away at its human overlords.
This is why I have purposely stayed away from jobs at companies doing
stuff like this. I know I don't write perfect code; I don't want to
be responsible for devices that can affect human life. This is also
discussed in the new edition of "The Pragmatic Programmer", which I've
just finished reading. (Highly recommended.)
Arnold
From jon at fourwinds.com Mon Jul 12 02:10:57 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 11 Jul 2021 09:10:57 -0700
Subject: [TUHS] Death by bug
In-Reply-To: <20210711085346.1951E21F16@orac.inputplus.co.uk>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
Message-ID: <202107111610.16BGAv5u2851405@darkstar.fourwinds.com>
Ralph Corderoy writes:
> Hi Jon,
>
> > So while I agree with your example, I guess that I was contemplating
> > the sort of example that makes the public take notice. Arguments
> > about statistical models are lost on 99% of the population.
>
> True.
>
> I don't know of any but if I had to pick an area where they might be
> occurring it would be medical devices. I've been an external reviewer
> of a company's embedded C code for a medical device in the past,
> bare-metal, simple pre-emptive round-robin task-switcher, etc., though
> my suggestion is nothing to do with their quality of work or products,
> just that the level of detail they went to shows how slacker companies
> could err.
>
> The Therac-25 gave fatal radiation doses in a few cases. These were
> obvious when they occurred. https://en.wikipedia.org/wiki/Therac-25
>
> What if a medical device which sits in the background quietly doing its
> continuous, but sometimes vital, thing had the occasional hiccough from
> which it recovered? If the blip is only fatal in patients which were
> already touch and go and device fault left no obvious sign to suggest
> death wasn't caused by the initial ailment then the cause of death would
> be, quite reasonably, assumed.
>
> Given some devices are present in large numbers for many years in
> hospitals, and there's a lot of hospitals, an unnoticed bug could be
> steadily chipping away at its human overlords.
>
> --
> Cheers, Ralph.
Well, we agree once again. I have done a lot of work on medical devices,
and was surprised at the lack of diligence on the part of some of the
people with whom I worked. But your example is similar to the way that
people have trouble with COVID - there's too much of a lag between
exposure and symptoms for many folks to make the connection. So I'm kind
of wondering what sort of bug may blow up a refinery or chemical plant and
cause enough loss of life and damage to make people take notice.
Jon
From tytso at mit.edu Mon Jul 12 11:42:58 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 11 Jul 2021 21:42:58 -0400
Subject: [TUHS] Death by bug
In-Reply-To: <202107110904.16B94rKu012217@freefriends.org>
References: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
<202107110904.16B94rKu012217@freefriends.org>
Message-ID: <YOueIvV0QOR8Em8g@mit.edu>
On Sun, Jul 11, 2021 at 03:04:53AM -0600, arnold at skeeve.com wrote:
> Ralph Corderoy <ralph at inputplus.co.uk> wrote:
>
> > Given some devices are present in large numbers for many years in
> > hospitals, and there's a lot of hospitals, an unnoticed bug could be
> > steadily chipping away at its human overlords.
>
> This is why I have purposely stayed away from jobs at companies doing
> stuff like this. I know I don't write perfect code; I don't want to
> be responsible for devices that can affect human life. This is also
> discussed in the new edition of "The Pragmatic Programmer", which I've
> just finished reading. (Highly recommended.)
We should never be depending on a human being able to write "perfect
code". Instead, we need to come up with processes so that imperfect
code doesn't escape into production *despite* the fact that humans are
fallible. Such processes might include requiring unit tests,
integration tests, stress tests, etc., requiring code reivews by a
second pair of eyes, perhaps using formal proofs, having multiple
implementations of critical algorithms, cross-checking the results
from those independent implementations, and so on.
The space shuttle used a number of these techniques. It did *not*
depend on super-human, Гњber-programmers.
- Ted
From jon at fourwinds.com Mon Jul 12 12:57:16 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 11 Jul 2021 19:57:16 -0700
Subject: [TUHS] Death by bug
In-Reply-To: <YOueIvV0QOR8Em8g@mit.edu>
References: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
<202107110904.16B94rKu012217@freefriends.org> <YOueIvV0QOR8Em8g@mit.edu>
Message-ID: <202107120257.16C2vHne2869581@darkstar.fourwinds.com>
Theodore Y. Ts'o writes:
> On Sun, Jul 11, 2021 at 03:04:53AM -0600, arnold at skeeve.com wrote:
> > Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> >
> > > Given some devices are present in large numbers for many years in
> > > hospitals, and there's a lot of hospitals, an unnoticed bug could be
> > > steadily chipping away at its human overlords.
> >
> > This is why I have purposely stayed away from jobs at companies doing
> > stuff like this. I know I don't write perfect code; I don't want to
> > be responsible for devices that can affect human life. This is also
> > discussed in the new edition of "The Pragmatic Programmer", which I've
> > just finished reading. (Highly recommended.)
>
> We should never be depending on a human being able to write "perfect
> code". Instead, we need to come up with processes so that imperfect
> code doesn't escape into production *despite* the fact that humans are
> fallible. Such processes might include requiring unit tests,
> integration tests, stress tests, etc., requiring code reivews by a
> second pair of eyes, perhaps using formal proofs, having multiple
> implementations of critical algorithms, cross-checking the results
> from those independent implementations, and so on.
>
> The space shuttle used a number of these techniques. It did *not*
> depend on super-human, пїЅber-programmers.
>
> - Ted
In general I agree with you. But the "we should never" ignores the fact
that we do. It's a complicated problem. A major component is that
our "legal" system allows companies to externalize their liabilities.
And it's difficult to come up a way to assign liability without severely
harming the open source world. As I've said before, if your car crashed
as often as your Windows you probably wouldn't keep buying from the same
manufacturer.
Part of my preferred process is to have two software review teams. One
has access to the source code, the other doesn't. But of course this is
now often not possible when companies used closed-source components that
they purchase.
As someone who agrees with Feynman's dissent on the Challenger commission,
I think that incremental improvement is a good way to go. But, we live in
an age where many folks would rather come up with something bloated and new
rather than build on what's come before. That's making it more and more
difficult to distinguish between "full stack" and a landfill.
Jon
From arnold at skeeve.com Mon Jul 12 16:39:01 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 12 Jul 2021 00:39:01 -0600
Subject: [TUHS] Death by bug
In-Reply-To: <YOueIvV0QOR8Em8g@mit.edu>
References: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
<202107110904.16B94rKu012217@freefriends.org>
<YOueIvV0QOR8Em8g@mit.edu>
Message-ID: <202107120639.16C6d1R8001426@freefriends.org>
"Theodore Y. Ts'o" <tytso at mit.edu> wrote:
> On Sun, Jul 11, 2021 at 03:04:53AM -0600, arnold at skeeve.com wrote:
> > This is why I have purposely stayed away from jobs at companies doing
> > stuff like this. I know I don't write perfect code; I don't want to
> > be responsible for devices that can affect human life. This is also
> > discussed in the new edition of "The Pragmatic Programmer", which I've
> > just finished reading. (Highly recommended.)
>
> We should never be depending on a human being able to write "perfect
> code". Instead, we need to come up with processes so that imperfect
> code doesn't escape into production *despite* the fact that humans are
> fallible. Such processes might include requiring unit tests,
> integration tests, stress tests, etc., requiring code reivews by a
> second pair of eyes, perhaps using formal proofs, having multiple
> implementations of critical algorithms, cross-checking the results
> from those independent implementations, and so on.
>
> The space shuttle used a number of these techniques. It did *not*
> depend on super-human, Гњber-programmers.
I strongly agree with all that. But given that many places don't use such
practices (especially startups), I prefer not to put myself into
situations where safety of the product depends entirely on the skills
of the programming team.
Arnold
From ralph at inputplus.co.uk Mon Jul 12 19:56:39 2021
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 12 Jul 2021 10:56:39 +0100
Subject: [TUHS] Death by bug
In-Reply-To: <YOueIvV0QOR8Em8g@mit.edu>
References: <CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
<202107110904.16B94rKu012217@freefriends.org> <YOueIvV0QOR8Em8g@mit.edu>
Message-ID: <20210712095639.0BFE121E8F@orac.inputplus.co.uk>
Hi Ted,
> > This is why I have purposely stayed away from jobs at companies
> > doing stuff like this. I know I don't write perfect code; I don't
> > want to be responsible for devices that can affect human life.
>
> We should never be depending on a human being able to write "perfect
> code".
And no one has suggested we do; Arnold just pointed out he knows doesn't
which is a good first step to working on critical software.
> Instead, we need to come up with processes so that imperfect code
> doesn't escape into production *despite* the fact that humans are
> fallible. Such processes might include requiring unit tests,
> integration tests, stress tests, etc., requiring code reivews by a
> second pair of eyes, perhaps using formal proofs, having multiple
> implementations of critical algorithms, cross-checking the results
> from those independent implementations, and so on.
Haven't you just pushed the need for perfection from coding to processes
to achieve вЂimperfect code doesn't escape into production’. Perfection
doesn't exist there either.
--
Cheers, Ralph.
From ralph at inputplus.co.uk Mon Jul 12 20:37:08 2021
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 12 Jul 2021 11:37:08 +0100
Subject: [TUHS] Death by bug
In-Reply-To: <202107111610.16BGAv5u2851405@darkstar.fourwinds.com>
References: <CAEdTPBfs1S91FCKfHGojgaT9edODhWPRs9W2ZGmpN3frsyXCvw@mail.gmail.com>
<06737C14-1122-4832-BCAA-A37B242F69E4@me.com>
<CAC20D2Ps4V1V6hn9s-0Y6W0Qb8eX_MrGMUtoudvk3aKErPuBzg@mail.gmail.com>
<CAGfO01xwG2ahSKSz7qRu-aVpNxPB4b+8C_a3PjdMXhPKEZEnCg@mail.gmail.com>
<CAGg_6+MwmwBkbKHd2L55DV5=JSGd+Fz4Gi6iBaH0cS3i57uSUg@mail.gmail.com>
<CAC20D2N2dmsX21fPO5_nHU7RTC+Kbsr0x_Hqvv2cr9C8Dpdeng@mail.gmail.com>
<YOSDmL7dCmy2KYGz@mit.edu>
<CAEoi9W6oDNmGgMo+cF163KW9AVmj7xvBYBORDwTHmOBGgX68cw@mail.gmail.com>
<202107071828.167ISgdN2686558@darkstar.fourwinds.com>
<20210710115135.22FDC21C4E@orac.inputplus.co.uk>
<CAEdTPBer7fHrdcF6oXnmtFLOjVuwhAfiyc3eLkr__9AM-ORX1w@mail.gmail.com>
<20210710141217.8795F21CD1@orac.inputplus.co.uk>
<202107101657.16AGvIHu2818628@darkstar.fourwinds.com>
<20210711085346.1951E21F16@orac.inputplus.co.uk>
<202107111610.16BGAv5u2851405@darkstar.fourwinds.com>
Message-ID: <20210712103708.ECB1221E8F@orac.inputplus.co.uk>
Hi Jon,
> So I'm kind of wondering what sort of bug may blow up a refinery or
> chemical plant and cause enough loss of life and damage to make people
> take notice.
I see, a вЂbig bang’ disaster, like Bhopal, rather than a gradual
sniping.
There's the Battery Management System software which controls the
charging and discharge of Lithium-ion batteries. I don't mean a burning
laptop causing an airliner to go down, more a shipping container stuffed
full of the things going up.
There is an interesting recent paper on the flaws in вЂBattery Energy
Storage Systems’ and defending against the inevitable lithium metal
dendrites. It assumes the BMS has no flaws but if it did then the same
end effect could occur. Here's some extracts from the вЂExecutive
Summary’.
Safety of Grid Scale Lithium-ion Battery Energy Storage Systems
https://www.researchgate.net/publication/352158070_Safety_of_Grid_Scale_Lithium-ion_Battery_Energy_Storage_Systems
Li-ion batteries are dominant in large, grid-scale, Battery Energy
Storage Systems (BESS) of several MWh and upwards in capacity.
Several proposals for large-scale solar photovoltaic (PV) “energy
farms” are current, incorporating very large capacity BESS.
Despite storing electrochemical energy of many hundreds of tons of
TNT equivalent, and several times the energy released in the August
2020 Beirut explosion, these BESS are regarded as “articles” by the
Health and Safety Executive (HSE), in defiance of the Control of
Major Accident Hazards Regulations (COMAH) 2015, intended to
safeguard public health...
Li-ion batteries can fail by “thermal runaway” where overheating in
a single faulty cell can propagate to neighbours with energy
releases popularly known as “battery fires”. These are not strictly
“fires” at all, requiring no oxygen to propagate. They are
uncontrollable except by extravagant water cooling. They evolve
toxic gases such as Hydrogen Fluoride (HF) and highly inflammable
gases including Hydrogen (H2), Methane (CH4), Ethylene (C2H4) and
Carbon Monoxide (CO). These in turn may cause further explosions or
fires upon ignition. The chemical energy then released can be up to
20 times the stored electrochemical energy.
“Battery fires” in grid scale BESS have occurred in South Korea,
Belgium (2017), Arizona (2019) and in urban Liverpool (Sept 2020)...
A report into the Liverpool “fire” though promised for New Year
2021, has not yet been released...
No existing engineering standards address thermal runaway
adequately, or require measures (such as those already used in EV
batteries) to pre-empt propagation of runaway events.
And BMS's get a few mentions, e.g.:
Li-ion batteries are sensitive to mechanical damage and electrical
surges, both in over-charging and discharging. Most of this can
however be safeguarded by an appropriate Battery Management System
(BMS)...
--
Cheers, Ralph.
From lyndon at orthanc.ca Wed Jul 14 03:48:01 2021
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 13 Jul 2021 10:48:01 -0700
Subject: [TUHS] First machine to run rogue?
In-Reply-To: <CAC20D2PepaO8mtat=J1CPg-nFO4-c4WbjNAK+_Q60a1_y5djEw@mail.gmail.com>
References: <CAEoi9W6Tr=b7O2Bn+GkXYCadCqrDdXiLTkL=eX-RaDZ9a7m+bw@mail.gmail.com>
<CAC20D2OeAuk+FdqU=qe_TZ6wNpenfbOgdnk4UaEPRdEtyvvJ4g@mail.gmail.com>
<CAEoi9W6Bk4qD7MFvA4nBhHg+Hn-8j0CXgkedh2PTObJ+mH2=bA@mail.gmail.com>
<202107021140.162BeWZt018129@freefriends.org>
<CAC20D2PepaO8mtat=J1CPg-nFO4-c4WbjNAK+_Q60a1_y5djEw@mail.gmail.com>
Message-ID: <8f1b79c4058a09bc@orthanc.ca>
You could buy source for a version of rogue from the AT&T Software
Toolchest. We bought a copy and ran it on CTIX and 4.2BSD, among
others. I don't recall any portability issues, and have long forgotten
everything related to licensing, code provenance, etc.
--lyndon
From dave at horsfall.org Wed Jul 14 08:28:43 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 14 Jul 2021 08:28:43 +1000 (EST)
Subject: [TUHS] 386BSD released
Message-ID: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
In 1992, 386BSD is released by Lynne and William Jolitz, starting the open
source operating system movement (Linux didn't come along under later).
-- Dave
From michael at kjorling.se Wed Jul 14 17:54:35 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 14 Jul 2021 07:54:35 +0000
Subject: [TUHS] 386BSD released
In-Reply-To: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
Message-ID: <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
On 14 Jul 2021 08:28 +1000, from dave at horsfall.org (Dave Horsfall):
> In 1992, 386BSD is released by Lynne and William Jolitz, starting the open
> source operating system movement (Linux didn't come along under later).
Are you sure? Wikipedia claims that it happened the other way around;
that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
the 386BSD initial release was 0.0 on 12 March 1992.
It seems that work on 386BSD began earlier than work on Linux, but
that the initial release of Linux was earlier than the initial release
of 386BSD.
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
From angus at fairhaven.za.net Wed Jul 14 18:19:02 2021
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 14 Jul 2021 10:19:02 +0200
Subject: [TUHS] 386BSD released
In-Reply-To: <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
Message-ID: <CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
Looking at a few online sources, Linus actually said when "386BSD came out,
Linux was already in a usable state, that I never really thought about
switching. If 386BSD had been available when I started on Linux, Linux
would probably never had happened".
Although the dates differ, it seems Linux was released in 1991
Kind Regards,
Angus Robinson
On Wed, Jul 14, 2021 at 10:04 AM Michael Kjörling <michael at kjorling.se>
wrote:
> On 14 Jul 2021 08:28 +1000, from dave at horsfall.org (Dave Horsfall):
> > In 1992, 386BSD is released by Lynne and William Jolitz, starting the
> open
> > source operating system movement (Linux didn't come along under later).
>
> Are you sure? Wikipedia claims that it happened the other way around;
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
> the 386BSD initial release was 0.0 on 12 March 1992.
>
> It seems that work on 386BSD began earlier than work on Linux, but
> that the initial release of Linux was earlier than the initial release
> of 386BSD.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/13fb3209/attachment.htm>
From michael at kjorling.se Wed Jul 14 18:32:11 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 14 Jul 2021 08:32:11 +0000
Subject: [TUHS] 386BSD released
In-Reply-To: <CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
Message-ID: <61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
On 14 Jul 2021 10:19 +0200, from angus at fairhaven.za.net (Angus Robinson):
> Looking at a few online sources, Linus actually said when "386BSD came out,
> Linux was already in a usable state, that I never really thought about
> switching. If 386BSD had been available when I started on Linux, Linux
> would probably never had happened".
And all this, of course, ignoring the other issue of what might be
considered a "start to the open source operating system movement",
given that even development of GNU was well underway by the time the
Linux kernel got started (having been worked on since early 1984), and
one might even be able to argue that the early UNIX systems were also,
in a sense, open source.
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
From lars at nocrew.org Wed Jul 14 19:07:19 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 14 Jul 2021 09:07:19 +0000
Subject: [TUHS] 386BSD released
In-Reply-To: <61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost> ("Michael
=?utf-8?Q?Kj=C3=B6rling=22's?= message of "Wed, 14 Jul 2021 08:32:11
+0000")
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
Message-ID: <7wtukxtgag.fsf@junk.nocrew.org>
Michael Kjörling wrote:
> And all this, of course, ignoring the other issue of what might be
> considered a "start to the open source operating system movement",
> given that even development of GNU was well underway by the time the
> Linux kernel got started (having been worked on since early 1984)
GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
I don't know its exact distribution terms, but Wipikedia says "open
source" so it was possibly in that general vicinity.
Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
somewhat "open" and "free", but it's not a clear cut case.
From tih at hamartun.priv.no Wed Jul 14 20:09:49 2021
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Wed, 14 Jul 2021 12:09:49 +0200
Subject: [TUHS] 386BSD released
In-Reply-To: <61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost> ("Michael
=?utf-8?Q?Kj=C3=B6rling=22's?= message of "Wed, 14 Jul 2021 08:32:11
+0000")
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
Message-ID: <m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
Michael Kjörling <michael at kjorling.se> writes:
> [...] one might even be able to argue that the early UNIX systems were
> also, in a sense, open source.
Ditto MINIX, of course, which was released, along with the book, in 1987.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
From arnold at skeeve.com Wed Jul 14 20:39:10 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 14 Jul 2021 04:39:10 -0600
Subject: [TUHS] 386BSD released
In-Reply-To: <m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
Message-ID: <202107141039.16EAdAMK025329@freefriends.org>
Tom Ivar Helbekkmo via TUHS <tuhs at minnie.tuhs.org> wrote:
> Michael Kjörling <michael at kjorling.se> writes:
>
> > [...] one might even be able to argue that the early UNIX systems were
> > also, in a sense, open source.
>
> Ditto MINIX, of course, which was released, along with the book, in 1987.
The original Minix wasn't so open source. It was certainly not GPL'ed
or BSD/MIT licensed. Also, Tannenbaum had no interest in coordinating
distributed development of Minix into a production-worthy system.
I don't want to rehash all of that here, but I certainly would not
have listed the original Minix as Free Software / Open Source.
My two cents,
Arnold
From akosela at andykosela.com Wed Jul 14 21:49:06 2021
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 14 Jul 2021 13:49:06 +0200
Subject: [TUHS] 386BSD released
In-Reply-To: <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
Message-ID: <CALMnNGj64FZrjS5Mgngk9px1zcSHvGkAdOL-=Bob7G9NVq0gyg@mail.gmail.com>
On 7/14/21, Michael Kjörling <michael at kjorling.se> wrote:
> On 14 Jul 2021 08:28 +1000, from dave at horsfall.org (Dave Horsfall):
>> In 1992, 386BSD is released by Lynne and William Jolitz, starting the
>> open
>> source operating system movement (Linux didn't come along under later).
>
> Are you sure? Wikipedia claims that it happened the other way around;
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
> the 386BSD initial release was 0.0 on 12 March 1992.
>
> It seems that work on 386BSD began earlier than work on Linux, but
> that the initial release of Linux was earlier than the initial release
> of 386BSD.
>
I consider the birth of Linux to be August 25th 1991, when Linus
announced it on comp.os.minix. If he had access to 386BSD in 1991
then probably he would never have started the Linux project -- that's
his words.
He was exposed to UNIX at uni in late 1990, and purchased 386DX33 on
January 5th, 1991 -- a turning point in his life. After messing
around with MS-DOS and games like Prince of Persia (still one of the
best computers games ever!) for a few months, he started exploring
programming tools for MS-DOS and wanted to write a UNIX clone for his
home computer. The rest is literally the history...
--Andy
From lm at mcvoy.com Thu Jul 15 00:09:10 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 14 Jul 2021 07:09:10 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <7wtukxtgag.fsf@junk.nocrew.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<7wtukxtgag.fsf@junk.nocrew.org>
Message-ID: <20210714140910.GZ15842@mcvoy.com>
On Wed, Jul 14, 2021 at 09:07:19AM +0000, Lars Brinkhoff wrote:
> Michael Kj??rling wrote:
> > And all this, of course, ignoring the other issue of what might be
> > considered a "start to the open source operating system movement",
> > given that even development of GNU was well underway by the time the
> > Linux kernel got started (having been worked on since early 1984)
>
> GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
> I don't know its exact distribution terms, but Wipikedia says "open
> source" so it was possibly in that general vicinity.
>
> Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> somewhat "open" and "free", but it's not a clear cut case.
X10 and X11 predate all of this and at least X11 is open source.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From imp at bsdimp.com Thu Jul 15 00:54:51 2021
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 14 Jul 2021 08:54:51 -0600
Subject: [TUHS] 386BSD released
In-Reply-To: <20210714140910.GZ15842@mcvoy.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<7wtukxtgag.fsf@junk.nocrew.org> <20210714140910.GZ15842@mcvoy.com>
Message-ID: <CANCZdfp-ZtijojnTk3ORgG=Ko-aGNGQtkxAVozKUZtyqmzhCCw@mail.gmail.com>
On Wed, Jul 14, 2021 at 8:10 AM Larry McVoy <lm at mcvoy.com> wrote:
> On Wed, Jul 14, 2021 at 09:07:19AM +0000, Lars Brinkhoff wrote:
> > Michael Kj??rling wrote:
> > > And all this, of course, ignoring the other issue of what might be
> > > considered a "start to the open source operating system movement",
> > > given that even development of GNU was well underway by the time the
> > > Linux kernel got started (having been worked on since early 1984)
> >
> > GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
> > I don't know its exact distribution terms, but Wipikedia says "open
> > source" so it was possibly in that general vicinity.
> >
> > Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> > somewhat "open" and "free", but it's not a clear cut case.
>
> X10 and X11 predate all of this and at least X11 is open source.
>
The X10R3 license sure looks like a standard MIT license. The other license
statements that were included also read very much like open source, or
at least a strong intention of being open source, absent any drafting flaws.
Copyright 1985 by the Massachusetts Institute of Technology
Permission to use, copy, modify, and distribute this
software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in
advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
M.I.T. makes no representations about the suitability of
this software for any purpose. It is provided "as is"
without express or implied warranty.
This software is not subject to any license of the American
Telephone and Telegraph Company or of the Regents of the
University of California.
Although uwm did have the somewhat longer:
/************************************************************************
* *
* Copyright (c) 1986 by *
* Digital Equipment Corporation, Maynard, MA *
* All Rights Reserved. *
* *
* Permission to use, copy, modify, and distribute this software *
* and its documentation is hereby granted only to licensees of *
* The Regents of the University of California pursuant to their *
* license agreement for the Berkeley Software Distribution *
* provided that the following appears on all copies. *
* *
* "LICENSED FROM DIGITAL EQUIPMENT CORPORATION *
* COPYRIGHT (C) 1986 *
* DIGITAL EQUIPMENT CORPORATION *
* MAYNARD, MA *
* ALL RIGHTS RESERVED. *
* *
* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT *
* NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL *
* EQUIPMENT CORPORATION. DIGITAL MAKES NO REPRESENTATIONS *
* ABOUT SUITABILITY OF THIS SOFTWARE FOR ANY PURPOSE. IT IS *
* SUPPLIED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. *
* *
* IF THE UNIVERSITY OF CALIFORNIA OR ITS LICENSEES MODIFY *
* THE SOFTWARE IN A MANNER CREATING DERIVATIVE COPYRIGHT *
* RIGHTS APPROPRIATE COPYRIGHT LEGENDS MAY BE PLACED ON THE *
* DERIVATIVE WORK IN ADDITION TO THAT SET FORTH ABOVE." *
* *
************************************************************************/
This is the earliest copy of X10 I could find, pegging the date at around
1985, which
predates Linux by half a dozen years.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/11f14a46/attachment.htm>
From clemc at ccc.com Thu Jul 15 01:01:58 2021
From: clemc at ccc.com (Clem Cole)
Date: Wed, 14 Jul 2021 11:01:58 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
Message-ID: <CAC20D2NDPLZQ25GfYq7Yi1XQj9BEJJY0gLQB3nb5Z2bM66wM8A@mail.gmail.com>
Sigh ... Warren I am going to ask for your indulgence once here on TUHS as
I try to get any *new* discussion moved to COFF, but I guess it's time to
renew this history as enough people have joined the list since the last
time this was all discussed ... I'll do this once -- please take any other
discussion off this list. It has been argued too many times. Many of the
actors in this drama are part of the list. Sadly we have lost a few,
sometimes because of the silliness of the argument/trying to give people
credit or not/person preferences, etc.
If you want to comment, please go back and read both the TUHS and COFF
archives and I suspect your point may have already been made. *If you
really do have something new, please move to COFF.*
On Wed, Jul 14, 2021 at 4:21 AM Angus Robinson <angus at fairhaven.za.net>
wrote:
> Looking at a few online sources, Linus actually said when "386BSD came
> out, Linux was already in a usable state, that I never really thought about
> switching. If 386BSD had been available when I started on Linux, Linux
> would probably never had happened".
>
A number of us, such as Larry and I have discussed this a bunch both online
and in person. What would become 386BSD was actually available as early
as 1988, but you needed to know the public FTP address of where to get it
at UCB (which the UCB licensees had access to that FTP server). Bostic was
still working on what would become the 'NET' release, but this tarball
offered a bootable system and did have things in it that later AT&T would
require UCB to remove. In fact, this system would have X10 ported to it
and was a reasonably complete 'distro' in today's terms.
By formal definition, the tarball and the rest of UNIX from Research is and
always has been, '*Open Source*' in the sources were available. *But they
were licensed*. This was fairly typical of much early software BTW. The
binary nature only came about with the minicomputers.
The tarball in question was fairly easy to find in the wild but to use the
sources as a system, you technically needed an AT&T license. An
practically you needed access to a BSD box to rebuild them, which took a
license - although by then SunOS was probably close enough - although I do
not know anyone that tried it.
The sources in the tarball were not '*Free and Open Source*' -- which
becomes the crux of the issue. [Sadly the OSS folks have confused this
over the years and that important detail is lost]. Many people, such as
myself, when the AT&T suite began got worried and started hacking on Linux
at that point as the not nearly as mature but sort of works version without
networking or graphics had appeared [386BSD had both and a real installer -
more in a minute]
FWIW: Linus could have had access to the BSD for a 386 tarball if we had
asked in the right place. But as he has said later in time, he wanted to
write his own OS and did not both ask the right folks at his University, or
try to get permission. Although he has said he access to Sun3 and has
said that was his impetus for his work. This is an important point that
Larry reminds us of, many institutions kept the sources locked away like
his U of Wis. Other places were like liberal about access. IIRC Larry
sometimes refers to it as the "UNIX Club."
In my own case, I was running what would become 386BSD on my Wyse 32:16 box
at home and on an NCR 386 based system in Clemson as I was consulting for
them at the time. I also helped Bill with the PC/AT disk driver[WD1003 and
later WD7000/SCSI controllers], as I had access to the docs from WD which
Bill did not. I think I still have a photocopy of them.
What basically happened is as BSDi forked and that begets a number of
things, from hurt feelings to a famous law suite. A number of us, thought
the latter was about copyright (we were wrong it was about trade secret).
We were worried that the AT&T copyright would cause UNIX for an inexpensive
processor to disappear. We >>thought<< (incorrectly) that the copyright
that Linux was using, the GPL, would save us. Turns out >>legally<< it
would not have, if AT&T had won, at least in the USA and most NATO Allies -
the trade secret applied to all implementations of Ken, Dennis, and the
rest of the BTL folk's ideas. All of the Unix-like systems were in
violation at this point. BSDi/UCB was where AT&T started. The problem is
that while the court found that AT&T did create and own the >>ideas<< (note
ideas are not the source code implementation of the ideas), they could not
call the UNIX 'IP', trade secrets since the AT&T people published them all
both academically in books like Maury Bach's, much less they had been
forced by the 1956 consent decree to make the license available, they had
taught an industry. BTW: It's not just software, the transistor 'gets
out' of AT&T under the same type of rules.
In reality, like PGP, since there was lots of UNIX-based IP in other
places, it hard to see in practice how AT&T could have enforced the trade
secret. But again -- remember Charlie Brown (AT&T CEO) wants to go after
IBM, thinking the big money in computers in the mainframe. So they did
believe that they could exert pressure on UNIX-like systems for the higher
end, and they might have been able to enforce that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/930e9d3b/attachment.htm>
From rich.salz at gmail.com Thu Jul 15 01:06:13 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 14 Jul 2021 11:06:13 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CANCZdfp-ZtijojnTk3ORgG=Ko-aGNGQtkxAVozKUZtyqmzhCCw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<7wtukxtgag.fsf@junk.nocrew.org> <20210714140910.GZ15842@mcvoy.com>
<CANCZdfp-ZtijojnTk3ORgG=Ko-aGNGQtkxAVozKUZtyqmzhCCw@mail.gmail.com>
Message-ID: <CAFH29tqkbhru2dHSFbOmUAO6f8Yg=irV+4GGzROpfrB=0pbHeA@mail.gmail.com>
History of the MIT license first used for PC/IP in 1984 and then for X
Windows (read the link, fascinating "influence" was so important and the
benefits MIT got from that):
https://web.mit.edu/Saltzer/www/publications/MITLicense.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/0a542d80/attachment.htm>
From usotsuki at buric.co Thu Jul 15 01:37:08 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 14 Jul 2021 11:37:08 -0400 (EDT)
Subject: [TUHS] 386BSD released
In-Reply-To: <CANCZdfp-ZtijojnTk3ORgG=Ko-aGNGQtkxAVozKUZtyqmzhCCw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<7wtukxtgag.fsf@junk.nocrew.org> <20210714140910.GZ15842@mcvoy.com>
<CANCZdfp-ZtijojnTk3ORgG=Ko-aGNGQtkxAVozKUZtyqmzhCCw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2107141136250.2430@sd-119843.dedibox.fr>
On Wed, 14 Jul 2021, Warner Losh wrote:
> The X10R3 license sure looks like a standard MIT license. The other license
> statements that were included also read very much like open source, or
> at least a strong intention of being open source, absent any drafting flaws.
>
> Copyright 1985 by the Massachusetts Institute of Technology
>
> Permission to use, copy, modify, and distribute this
> software and its documentation for any purpose and without
> fee is hereby granted, provided that the above copyright
> notice appear in all copies and that both that copyright
> notice and this permission notice appear in supporting
> documentation, and that the name of M.I.T. not be used in
> advertising or publicity pertaining to distribution of the
> software without specific, written prior permission.
> M.I.T. makes no representations about the suitability of
> this software for any purpose. It is provided "as is"
> without express or implied warranty.
>
> This software is not subject to any license of the American
> Telephone and Telegraph Company or of the Regents of the
> University of California.
Ironically...that's closer to a "3-clause BSD" license.
-uso.
From tytso at mit.edu Thu Jul 15 01:48:22 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Wed, 14 Jul 2021 11:48:22 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CALMnNGj64FZrjS5Mgngk9px1zcSHvGkAdOL-=Bob7G9NVq0gyg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CALMnNGj64FZrjS5Mgngk9px1zcSHvGkAdOL-=Bob7G9NVq0gyg@mail.gmail.com>
Message-ID: <YO8HRnhf4c1wdU2q@mit.edu>
On Wed, Jul 14, 2021 at 01:49:06PM +0200, Andy Kosela wrote:
>
> I consider the birth of Linux to be August 25th 1991, when Linus
> announced it on comp.os.minix. If he had access to 386BSD in 1991
> then probably he would never have started the Linux project -- that's
> his words.
I personally got started with Linux in September 1992, with one my
first projects being setting up the first US-based ftp site for Linux
--- tsx-11.mit.edu, which was a Decstation 3100 in my office ---
because at the time Finland was behind a super-slow trans-atlantic
link. One of my other first initial was implementing BSD Job Control
from the POSIX spec, and improving the performance of the serial
driver, since at the time my 40 MHz 386 with 16 megs of memory was at
home, and the connection to the outside world was via modem. (Or
hauling around dozens of 1.44M floppy disks from work. :-)
I have heard stories that 386BSD was being demo'ed at various Usenix
conferences in 1990 and early 1991, but as far as I know it was never
publically released until 1992. The Dr. Dobbs articles documenting
the porting process started in January 1991, so certainly Jolitz was
working on it by then. However, 386BSD was largely developed behind
closed doors, whereas Linus was accepting patches and turning around
new releases every few weeks (and sometimes sooner).
Cheers,
- Ted
From lyndon at orthanc.ca Thu Jul 15 03:21:44 2021
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Wed, 14 Jul 2021 10:21:44 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
Message-ID: <8f1b7be6ac367c79@orthanc.ca>
> Ditto MINIX, of course, which was released, along with the book, in 1987.
IBM was (inadvertantly) giving away the source to a few of its System/360
OSes in the 1960s ...
From rich.salz at gmail.com Thu Jul 15 03:32:47 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 14 Jul 2021 13:32:47 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <8f1b7be6ac367c79@orthanc.ca>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<61a16b78-fa11-49d3-8a62-a840e8b49d3e@localhost>
<m2im1dqk9e.fsf@thuvia.hamartun.priv.no>
<8f1b7be6ac367c79@orthanc.ca>
Message-ID: <CAFH29trrizz36G+YjWOF=J8VL4nHaPURuMLgdh7HAaZ19+AQVg@mail.gmail.com>
> IBM was (inadvertantly) giving away the source to a few of its System/360
> OSes in the 1960s ...
>
It was not inadvertent. It was common practice to give access to the
source since the money was in the hardware. Gates showed otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/811e5014/attachment.htm>
From tytso at mit.edu Thu Jul 15 03:40:53 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Wed, 14 Jul 2021 13:40:53 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <CAC20D2NDPLZQ25GfYq7Yi1XQj9BEJJY0gLQB3nb5Z2bM66wM8A@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<CAC20D2NDPLZQ25GfYq7Yi1XQj9BEJJY0gLQB3nb5Z2bM66wM8A@mail.gmail.com>
Message-ID: <YO8hpZ4VYln+QxNb@mit.edu>
On Wed, Jul 14, 2021 at 11:01:58AM -0400, Clem Cole wrote:
> By formal definition, the tarball and the rest of UNIX from Research is and
> always has been, '*Open Source*' in the sources were available. *But they
> were licensed*. This was fairly typical of much early software BTW. The
> binary nature only came about with the minicomputers.
It may have been "Open Source" by your definition, but there is a very
specific definition of "Open Source(tm)" and it has always been, from
the beginning, defined to mean code licensed under terms which meet
the Open Source Definition[1] (OSD). The AT&T license, for better or
for worse does not mean the terms of the OSD.
[1] https://opensource.org/osd
> The sources in the tarball were not '*Free and Open Source*' -- which
> becomes the crux of the issue. [Sadly the OSS folks have confused this
> over the years and that important detail is lost].
Hardly. "Free and Open Source" (FOSS) is a term which developed
*after* the the term "Open Source" was coined and trademarked. That
term was not created by the "OSS folks", but by people who were trying
the solve a political problem. The GPL meets the definition of the
Open Source Definition, so GPL-licensed software is "Open Source(tm)".
But Stallman objected to that usage, preferring his terminology "Free
Software" on the grounds that it came first. So FOSS was a compromise
to keep the FSF partisan happy.
But to take this back to TUHS, sorry, no code which falls under AT&T
License can be called "Open Source(tm)". If AT&T were still trying to
sell Unix under its original terms including the AT&T Unpublished
Trade Secret "all your student's minds belong to us" license, and
tried to claim that Unix was "Open Source", the Open Source Initiative
could sue AT&T for trademark infringement.
If you must, you could try to claim that AT&T was "Source Available"
--- which is a terminology I've seen some used. But I think your
assumptions of how easily the AT&T License could be obtained, and how
"anyone who wanted it could get it" may be looking at the past with
rose-colored classes.
Cheers,
- Ted
From lm at mcvoy.com Thu Jul 15 03:50:53 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 14 Jul 2021 10:50:53 -0700
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YO8hpZ4VYln+QxNb@mit.edu>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<CAC20D2NDPLZQ25GfYq7Yi1XQj9BEJJY0gLQB3nb5Z2bM66wM8A@mail.gmail.com>
<YO8hpZ4VYln+QxNb@mit.edu>
Message-ID: <20210714175053.GC15842@mcvoy.com>
On Wed, Jul 14, 2021 at 01:40:53PM -0400, Theodore Y. Ts'o wrote:
> If you must, you could try to claim that AT&T was "Source Available"
> --- which is a terminology I've seen some used. But I think your
> assumptions of how easily the AT&T License could be obtained, and how
> "anyone who wanted it could get it" may be looking at the past with
> rose-colored classes.
Clem was in "the club". I do remember those times, barely, I was a
bit too young to have a clear view of things. But it certainly
seemed like some Universities made the source pretty available.
UW Madison was not one of those, I had to beg and plead to get
access to the source.
So Clem's memory is fine, his experience was you could get the source.
But that wasn't the universal experience at all, and I agree with
Ted that just getting access to the source doesn't make it remotely
open source.
From clemc at ccc.com Thu Jul 15 04:28:37 2021
From: clemc at ccc.com (Clem Cole)
Date: Wed, 14 Jul 2021 14:28:37 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YO8hpZ4VYln+QxNb@mit.edu>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com>
<CAC20D2NDPLZQ25GfYq7Yi1XQj9BEJJY0gLQB3nb5Z2bM66wM8A@mail.gmail.com>
<YO8hpZ4VYln+QxNb@mit.edu>
Message-ID: <CAC20D2P12AV0Z2MAMbFL-y1D=x6RC5wPUWCx-_WAML9UJrZPWQ@mail.gmail.com>
On Wed, Jul 14, 2021 at 1:40 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:
> On Wed, Jul 14, 2021 at 11:01:58AM -0400, Clem Cole wrote:
> > By formal definition, the tarball and the rest of UNIX from Research is
> and
> > always has been, '*Open Source*' in the sources were available. *But
> they
> > were licensed*. This was fairly typical of much early software BTW. The
> > binary nature only came about with the minicomputers.
>
Please don't go here (again). Yes, it has been trademarked, but
the official trademarked term is different from reality --> just like the
guy that got a copyright for email and claims to have invented it. People
were 'open sourcing' software before you and I were born. They just did
not have a name for it - thank you.
The real 'father' of Open Source as we think of it today was Prof Don
Pederson and his Industrial Liaison Office (ILO) of the EE Dept of UCB in
the late 1960s -- long before rms, et al. As 'dop' used to say, I give
everything away because then I go in the back door, not the front door like
a salesman. MIT/CMU/Stanford et al we often licensing their work. In
many ways, CMU and Stanford were two of the worst. The ILO gave away all
its products. We would not have the current electronics industry without
the work dop and his students produced. As I have also pointed in
other email tapes like the original, '1BSD' was managed and distributed by
the ILO because dop had set of the infrastructure 10-15 years earlier to
send out mag tapes and other IP to 'interested parties.'
Yes, computer networks changed the distribution and access medium, but
please refrain from trying to rewrite history. The GNU project and FOSS
movement that was created took the idea and advanced it, making use of
better ways of communicating the ideas, removing the academic clubiness as
Larry suggested. Larry is right, if you were a peer organization or maybe
a patron of same, getting source was possible.
As rms noted, at some point the sources to things go harder and harder to
get access. ITS, WAITS, and even CTSS were all written at a time when you
go from IBM and DEC their sources - typically on 7 or 9 track mag-tape and
were usually available on microfiche. You also got the circuit schematics
too. Local modifications to both HW and SW were normal.
But starting with the Minis this began to change and it started to get
harder and harder. SW started being a revenue source for those companies
-- DEC in particular, so they started to be hold back the sources. The
rest is history... Folks like rms objected because the behavior they
were used to had changed and he and people like him, could do nothing about
it. So he created the Gnu project to compete with those commercial
products.
But just like have been getting 'email' since the late 1960s/early 1970s on
my computers, it was not named. Someone body claimed the name later. But
the function was old. The same is for sharing software written and given
away, now we have a name and a way to describe the behavior.
Cheers
Clem
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/8810a103/attachment-0001.htm>
From bakul at iitbombay.org Thu Jul 15 07:37:41 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Wed, 14 Jul 2021 14:37:41 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
Message-ID: <674F1273-7F3F-4ADA-BAF6-448A9403A36D@iitbombay.org>
I believe the following can count as an open source operating system (though this won’t satisfy the latter day purists). From Per Brinch-Hansen’s “Monitors and Concurrent Pascal: a Personal History” (1993):
“At Caltech we prepared a distribution tape with the source text and portable code of the Solo system, including the Concurrent and Sequential Pascal compilers. The system reports were supplemented by implementation notes (Brinch Hansen 1976b).
By the spring of 1976 we had distributed the system to 75 companies and 100 universities in 21 countries: Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Great Britain, Holland, India, Ireland, Italy, Japan, Norway, South Africa, the Soviet Union, Spain, Sweden, Switzerland, and the United States.”
This retrospective paper is worth reading in this age where the quest of higher and higher performance has produced super fast but very complicated and insecure machines where even synchronization has become a tricky affair (see for example the recent three articles by Russ Cox on his research.swtch.com site).
Can’t resist quoting Charles Hayden’s (Solocomment from the paper:
“What was remarkable about [Concurrent Pascal] is that one could write experimental operating systems on a virtual machine without having to resort to machine registers, assembly language, etc. The development environment provided a way to do operating systems in a controlled way, on the “bare hardware” of a much nicer machine than any real computer. . .
I think the significance of the system was . . . that one could provide a protected environment for concurrent programming—a high-level language environment which could maintain the illusion that there was no “machine” level. It was remarkable that through compile time restrictions and virtual machine error checking, that you could understand the program behavior by looking at the Pascal, not at the machine’s registers and memory. It was remarkable that the machine could retain its integrity while programs were being developed, without hardware memory protection.”
Nowadays writing an os kernel is considered quite a major effort. IMHO there has been nothing new in this area from a programming perspective since the вЂ70s and no guidance for h/w design which has become increasingly more complex and “magic” (as per Artur C Clarke’s definition).
http://brinch-hansen.net/papers/1993a.pdf
> On Jul 13, 2021, at 3:35 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
> п»їIn 1992, 386BSD is released by Lynne and William Jolitz, starting the open source operating system movement (Linux didn't come along under later).
>
> -- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/a5d44d52/attachment.htm>
From douglas.mcilroy at dartmouth.edu Thu Jul 15 12:21:30 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Wed, 14 Jul 2021 22:21:30 -0400
Subject: [TUHS] 386BSD released
Message-ID: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
> Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> somewhat "open" and "free", but it's not a clear cut case.
The open source movement was a revival of the old days of SHARE and other
user groups.
SAP, the SHARE assembly program for the IBM 704, was freely available--with
source code--to all members of the SHARE user group. I am not aware of any
restrictions on redistribution.
Other more specialized programs were also freely available through SHARE. In
particular, Fortran formatted IO was adopted directly from a SHARE program
written by Roy Nutt (who also wrote SAP and helped write Fortran I).
Bell Labs freely distributed the BESYS operating system for the IBM 704.
At the time (1958) no operating system was available from IBM.
IBM provided source code for the Fortran II compiler. In the
fashion of the time, I spent a memorable all-night session with
that code at hand, finding and fixing a bizarre bug (a computed GOTO
bombed if the number of branches was 74 mod 75) with a bizarre cause
(the code changed the index-register field in certain instructions on the
fly--inconsistently). And there was no operating system to help, because
BESYS swapped itself out to make room for the compiler.
Doug
From douglas.mcilroy at dartmouth.edu Thu Jul 15 12:38:06 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Wed, 14 Jul 2021 22:38:06 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
This somewhat stale note was sent some time ago, but was ignored
because it was sent from an unregistered email address.
> And if the Unix patriarchs were perhaps mistaken about how useful
> "head" might be and whether or not it should have been considered
> verboten.
Point well taken.
I don't know which of head(1) and sed(1) came first. They appeared in
different places at more or less the same time. We in Research
declined to adopt head because we already knew the idiom "sed 10q".
However one shouldn't have to do related operations in unrelated ways.
We finally admitted head in v10.
Head was independently invented by Mike Lesk. It was Lesk's
program that was deemed superfluous.
Head might not have been written if tail didn't exist. But, unlike head,
tail strayed from the tao of "do one thing well". Tail -r and tail -f are
as cringeworthy as cat -v.
-f is a strange feature that effectively turns a regular file into a pipe
with memory by polling for new data, A clean general alternative
might be to provide an open(2) mode that makes reads at the current
file end block if some process has the file open for writing.
-r is weird because it enables backwards reading, but only as
limited by count. Better would be a program, say revfile, that simply
reads backwards by lines. Then tail p has an elegant implementation:
revfile p | head | revfile
Doug
From athornton at gmail.com Thu Jul 15 12:41:00 2021
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 14 Jul 2021 19:41:00 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
Message-ID: <CAP2nic3OB4Zs=owmmGTYTjw2H5gq=HwFVv53yYxnUS+EU0CAVQ@mail.gmail.com>
"SHARE. It's not an acronym. It's what we do."
*Still* a bad-ass slogan after all these years.
Adam
On Wed, Jul 14, 2021 at 7:22 PM Douglas McIlroy <
douglas.mcilroy at dartmouth.edu> wrote:
> > Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> > somewhat "open" and "free", but it's not a clear cut case.
>
> The open source movement was a revival of the old days of SHARE and other
> user groups.
>
> SAP, the SHARE assembly program for the IBM 704, was freely available--with
> source code--to all members of the SHARE user group. I am not aware of any
> restrictions on redistribution.
>
> Other more specialized programs were also freely available through SHARE.
> In
> particular, Fortran formatted IO was adopted directly from a SHARE program
> written by Roy Nutt (who also wrote SAP and helped write Fortran I).
>
> Bell Labs freely distributed the BESYS operating system for the IBM 704.
> At the time (1958) no operating system was available from IBM.
>
> IBM provided source code for the Fortran II compiler. In the
> fashion of the time, I spent a memorable all-night session with
> that code at hand, finding and fixing a bizarre bug (a computed GOTO
> bombed if the number of branches was 74 mod 75) with a bizarre cause
> (the code changed the index-register field in certain instructions on the
> fly--inconsistently). And there was no operating system to help, because
> BESYS swapped itself out to make room for the compiler.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210714/967c896c/attachment.htm>
From arnold at skeeve.com Thu Jul 15 14:19:39 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 14 Jul 2021 22:19:39 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
References: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
Message-ID: <202107150419.16F4Jdf9024606@freefriends.org>
Douglas McIlroy <douglas.mcilroy at dartmouth.edu> wrote:
> -r is weird because it enables backwards reading, but only as
> limited by count. Better would be a program, say revfile, that simply
> reads backwards by lines. Then tail p has an elegant implementation:
> revfile p | head | revfile
The GNU coreutils provides "tac" (c-a-t backwards) which does that
job. It was adopted from a long-ago posting of same on comp.sources.something.
It should be standard on just about any Linux system.
(It too has too many options, but let's not go there.)
Thanks,
Arnold
From athornton at gmail.com Thu Jul 15 14:25:36 2021
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 14 Jul 2021 21:25:36 -0700
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <202107150419.16F4Jdf9024606@freefriends.org>
References: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
<202107150419.16F4Jdf9024606@freefriends.org>
Message-ID: <A556D586-A6F3-4DEC-B445-C5330FF3E82D@gmail.com>
> On Jul 14, 2021, at 9:19 PM, arnold at skeeve.com wrote:
>
> The GNU coreutils provides "tac" (c-a-t backwards)
...
> (It too has too many options, but let's not go there.)
GNU pretty much anything has too many options.
I do aesthetically appreciate that tail -f is a bit of an abomination, but realistically it’s also 90% or more of my actual use of tail. There obviously needs to be SOMETHING that lets you watch the end of a growing file as it’s growing.
Adam
From thomas.paulsen at firemail.de Thu Jul 15 17:20:52 2021
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Thu, 15 Jul 2021 09:20:52 +0200
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <202107150419.16F4Jdf9024606@freefriends.org>
References: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
<202107150419.16F4Jdf9024606@freefriends.org>
Message-ID: <3804e1f3ceda56278ffba203944149a7@firemail.de>
Arnold: (It too has too many options, but let's not go there.)
beside the usual help and version only 3 options what is not very much for a gnu tool. A emulate cat option is missing ;-)
Thanks,
From tytso at mit.edu Fri Jul 16 00:28:04 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 15 Jul 2021 10:28:04 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
References: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
Message-ID: <YPBF9GUgDw2Qa1nt@mit.edu>
On Wed, Jul 14, 2021 at 10:38:06PM -0400, Douglas McIlroy wrote:
> Head might not have been written if tail didn't exist. But, unlike head,
> tail strayed from the tao of "do one thing well". Tail -r and tail -f are
> as cringeworthy as cat -v.
>
> -f is a strange feature that effectively turns a regular file into a pipe
> with memory by polling for new data, A clean general alternative
> might be to provide an open(2) mode that makes reads at the current
> file end block if some process has the file open for writing.
OTOH, this would mean adding more functionality (read: complexity)
into the kernel, and there has always been a general desire to avoid
pushing <stuff> into the kernel when it can be done in userspace. Do
you really think using a blocking read(2) is somehow more superior
than using select(2) to wait for new data to be appended to the file?
And even if we did this using a new open(2) mode, are you saying we
should have a separate executable in /bin which would then be
identical to cat, except that it uses a different open(2) mode?
> -r is weird because it enables backwards reading, but only as
> limited by count. Better would be a program, say revfile, that simply
> reads backwards by lines. Then tail p has an elegant implementation:
> revfile p | head | revfile
I'll note, with amusement, that -r is one option which is *NOT* in the
GNU version of tail. I see it in FreeBSD, but this looks like a
BSD'ism. So for those like to claim that the GNU utilities have laden
with useless options, this is one which can't be left at the feet of
GNU coreutils.
- Ted
From clemc at ccc.com Fri Jul 16 01:07:10 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Jul 2021 11:07:10 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
Message-ID: <CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
Thank you, Doug.
On Wed, Jul 14, 2021 at 10:22 PM Douglas McIlroy <
douglas.mcilroy at dartmouth.edu> wrote:
> The open source movement was a revival of the old days of SHARE and other
> user groups.
>
Amen, my basic point, although I was also trying to pointing at that these
user groups got started b*ecause the vendors gave the sources to their
products out.* We SHARED patches and features. DECUS started out the same
way. For instance, many/most PDP-10 OS's used the DEC compilers and often
even found a way to run TOPS-10 binaries by emulating the UUOs. The
IBM/360 world worked pretty much the same way. My own experience was that
the compilers (e.g WATFIV-FTNG-ALGOLW-PL/1) and language interpreters
(APL-Snolbol) for the TSS and MTS had been 'ported' from the IBM-supplied
OS [my own first job was doing just that].
The same story was true for the PDP-8 with DOS-8/TSS-8 and the like. By the
time of the PDP-11, while some of the DEC source code was available (such
as the Fortran-IV for RT-11/RSX), since it took at PDP-10/BLISS to support
it, DEC had it its protection - so moving it/stealing it - would have been
harder. By the time of the VAX, DEC was charging a lot of money of SW and
it was actually a revenue stream, so they keep a lot more locked up and
had started to do the same with PDP-10 world.
So, the available/unavailable source issue came when things started to get
closed up, which really started with the rise of the SW industry and making
revenue with the use of your SW. OEMs and IVSs started to be a lot less
willing to reveal what they thought was their 'special sauce.' Some/many
end-users started to balk. RMS just took it to a new level - just look at
how he reacted to Symbolics being closed source :-)
The question that used to come up (and still does not an extent) is how are
the engineers and teams of people that developed the SW going to be
paid/renumerated for their work? The RMS/GNU answer had been service
revenue [and living like a student in a rent-controlled APT in
Central Sq]. What has happened for most of the biggest FOSS projects, the
salaries are paid for firms like my own that pay developers to work on the
SW and most FOSS projects die when the developer/maintainer is unable to
continue (if not just gets bored).
In fact, [I can not say I personally know this - but have read internal
memos that make the claim], Intel pays for more Linux developers and now
LLVM developers than any firm. What's interesting is that Intel does not
really directly sell its HW product to end-users. We sell to others than
use our chips to make their products. We have finally moved to the
support model for the compilers (I've personally been fighting that battle
for 15 years).
So back to my basic point ... while giving the *behavior* a name, the *idea
*of "Open Source" is really not anything new. While it may be new in their
lifetime/experience, it is frankly at minimum a sad, if not outright
disingenuous, statement for the people to try to imply otherwise because
they are unwilling to look back into history and understand, much less
accept it as a fact. Trying to rewrite history is just not pretty to
witness. And I am pleased to see that a few folks (like Larry) that have
lived a little both times have tried to pass the torch with more complete
history.
Clem.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/2b9f4560/attachment.htm>
From norman at oclsc.org Fri Jul 16 01:44:43 2021
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 15 Jul 2021 11:44:43 -0400 (EDT)
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <20210715154443.4158A640CC6@lignose.oclsc.org>
Some comments from someone (me) who tends to be pickier than
most about cramming programs together and endless sets of
options:
I, too, had always thought sed was older than head. I stand
corrected. I have a long-standing habit of typing sed 10q but
don't spend much time fussing about head.
When I arrived at Bell Labs in late summer 1984, tail -f was
in /usr/bin and in the manual, readslow was only in /usr/bin.
readslow was like tail -f, except it either printed the entire
file first or (option -e) started at the end of the file.
I was told readslow had come first, and had been invented in a
hurry because people wanted to watch in real time the moves
logged by one of Belle's chess matches. Vague memory says it
was written by pjw; the name and the code style seem consistent
with that.
Personally I feel like tail -r and tail -f both fit reasonably
well within what tail does, since both have to do with the
bottom of the file, though -r's implementation does make for
a special extra code path in tail so maybe a separate program
is better. What I think is a bigger deal is that I have
frequently missed tail -r on Linux systems, and somehow hadn't
spotted tac; thanks to whoever here (was it Ted?) pointed it
out first!
On the other hand, adding data-processing functions to cat has
never made sense to me. It seems to originate from a mistaken
notion that cat's focus is printing data on terminals, rather
than concatenating data from different places. Here is a test:
if cat -v and cat -n and all that make sense, why shouldn't
cat also subsume tr and pr and even grep? What makes converting
control characters and numbering lines so different from swapping
case and adding page headers? I don't see the distinction, and
so I think vis(1) (in later Research) makes more sense than cat -v
and nl(1) (in Linux for a long time) more sense than cat -n.
(I'd also happily argue that given nl, pr shouldn't number lines.
That a program was in V6 or V7 doesn't make it perfect.)
And all those special options to wc that amounted to doing
arithmetic on the output were always just silly. I'm glad
they were retracted.
On the other other hand, why didn't I know about tac? Because
there are so damn many programs in /usr/bin these days. When
I started with UNIX ca. 1980, the manual (even the BSD version)
was still short enough that one could sit down and read it through,
section by section, and keep track of what one had read, and
remember what all the different tools did. That hasn't been
true for decades. This could be an argument for adding to
existing programs (which many people already know about) rather
than adding new programs (which many people will never notice).
The real problem is that the system is just too damn big. On
an Ubuntu 18.04 system I run, ls /usr/bin | wc -l shows 3242
entries. How much of that is redundant? How much is rarely or
never used? Nobody knows, and I suspect few even try to find
out. And because nobody knows, few are brave enough to throw
things away, or even trim out bits of existing things.
One day in the late 1980s, I helped out with an Introduction
to UNIX talk at a DECUS symposium. One of the attendees noticed
the `total' line in the output of ls, and asked why is that there?
doesn't that contradict the principles of tools' output you've
just been talking about? I thought about it, and said yes,
you're right, that's a bit of old history and shouldn't be
there any more. When I got home to New Jersey, I took the
`total' line out of Research ls.
Good luck doing anything like that today.
Norman Wilson
Toronto ON
From beebe at math.utah.edu Fri Jul 16 02:54:35 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 15 Jul 2021 10:54:35 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CMM.0.96.0.1626368075.beebe@gamma.math.utah.edu>
On the subject of tac (concatenate and print files in reverse), I can
report that the tool was written by my late friend Jay Lepreau in the
Department of Computer Science (now, School of Computing) at the
University of Utah. The GNU coreutils distribution for src/tac.c
contains a copyright for 1988-2020.
I searched my TOPS-20 PDP-10 archives, and found no source code for
tac, but I did find an older TOPS-20 executable in Jay's personal
directory with a file date of 17-Mar-1987. There isn't much else in
that directory, so I suspect that he just copied over a needed tool
from his Department of Computer Science TOPS-20 system to ours in the
College of Science.
----------------------------------------
P.S. Jay was the first to get Steve Johnson's Portable C Compiler,
pcc, to run on the 36-bit PDP-10, and once we had pcc, we began the
move from writing utilities in Pascal and PDP-10 assembly language to
doing them in C. The oldest C file for pcc in our PDP-10 archives is
dated 17-Mar-1981, with other pcc files dated to mid-1983, and final
compiler executables dated 12-May-1986. Four system header files are
dated as late as 4-Oct-1986, presumably patched after the compiler was
built.
Later, Kok Chen and Ken Harrenstien's kcc provided another C compiler
that added support for byte datatypes, where a byte could be anything
from 1 to 36 bits. The oldest distribution of kcc in our archives is
labeled "Fifth formal distribution snapshot" and dated 20-Apr-1988.
My info-kcc mailing list archives date from the list beginning, with
an initial post from Ken dated 27-Jul-1986 announcing the availability
of kcc at sri-nic.arpa.
By mid-1987, we had a dozen Sun workstations and NFS fileserver; they
marked the beginning of our move to a Unix workstation environment,
away from large, expensive, and electricity-gulping PDP-10 and VAX
mainframes.
By the summer of 1991, those mainframes were retired. I recall
speaking to a used-equipment vendor about our VAX 8600, which cost
about US$450K (discounted academic pricing) in 1986, and was told that
its value was depreciating about 20% per month. Although many of us
missed TOPS-20 features, I don't think anyone was sad to say goodbye
to VMS. We always felt that the VMS developers worked in isolation
from the PDP-10 folks, and thus learned nothing from them.
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From norman at oclsc.org Fri Jul 16 05:01:08 2021
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 15 Jul 2021 15:01:08 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <1626375671.1426.for-standards-violators@oclsc.org>
Nelson H. F. Beebe:
P.S. Jay was the first to get Steve Johnson's Portable C Compiler,
pcc, to run on the 36-bit PDP-10, and once we had pcc, we began the
move from writing utilities in Pascal and PDP-10 assembly language to
doing them in C.
======
How did that C implementation handle ASCII text on the DEC-10?
Were it a from-scratch UNIX port it might make sense to store
four eight- or nine-bit bytes to a word, but if (as I sense it
was) it was C running on TOPS-10 or TOPS-20, it would have had
to work comfortably with DEC's convention of five 7-bit characters
(plus a spare bit used by some programs as a flag).
Norman Wilson
Toronto ON
From clemc at ccc.com Fri Jul 16 05:27:36 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Jul 2021 15:27:36 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <1626375671.1426.for-standards-violators@oclsc.org>
References: <1626375671.1426.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target Alan
Synder did for his MIT Thesis.
It was originally targeted to ITS for the PDP-10, but it ran on Tops-20
also.
My >>memory<< is he used a 7-bit Character, ala SAIL, with 5 chars stored
in a word with a bit leftover.
You can check it out: https://github.com/PDP-10/Snyder-C-compiler
I believe that C compiler Nelson is talking about I believe is actually
Synder's that Jay either ported from ITS or WAITS.
We had some form of the Synder compiler on the PDP-10's at CMU in the late
1970s.
It was either Mike Accetta or Fil Aleva that wrote a program to read PDP-10
backup tapes, that I updated to deal with TOPS-20/TENEX 'dumper' format
which was similar/only different.
бђ§
On Thu, Jul 15, 2021 at 3:03 PM Norman Wilson <norman at oclsc.org> wrote:
> Nelson H. F. Beebe:
>
> P.S. Jay was the first to get Steve Johnson's Portable C Compiler,
> pcc, to run on the 36-bit PDP-10, and once we had pcc, we began the
> move from writing utilities in Pascal and PDP-10 assembly language to
> doing them in C.
>
> ======
>
> How did that C implementation handle ASCII text on the DEC-10?
> Were it a from-scratch UNIX port it might make sense to store
> four eight- or nine-bit bytes to a word, but if (as I sense it
> was) it was C running on TOPS-10 or TOPS-20, it would have had
> to work comfortably with DEC's convention of five 7-bit characters
> (plus a spare bit used by some programs as a flag).
>
> Norman Wilson
> Toronto ON
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/5051ca4d/attachment.htm>
From clemc at ccc.com Fri Jul 16 05:28:32 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Jul 2021 15:28:32 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
Message-ID: <CAC20D2PEG82MS9CWQkhfX2Ud7ZegRVDfg-_T2NG4aT9++H3KdQ@mail.gmail.com>
g/Synder/s//Snyder/ -- sigh....
бђ§
On Thu, Jul 15, 2021 at 3:27 PM Clem Cole <clemc at ccc.com> wrote:
> The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target Alan
> Synder did for his MIT Thesis.
> It was originally targeted to ITS for the PDP-10, but it ran on Tops-20
> also.
>
> My >>memory<< is he used a 7-bit Character, ala SAIL, with 5 chars stored
> in a word with a bit leftover.
>
> You can check it out: https://github.com/PDP-10/Snyder-C-compiler
>
> I believe that C compiler Nelson is talking about I believe is actually
> Synder's that Jay either ported from ITS or WAITS.
>
> We had some form of the Synder compiler on the PDP-10's at CMU in the late
> 1970s.
> It was either Mike Accetta or Fil Aleva that wrote a program to read
> PDP-10 backup tapes, that I updated to deal with TOPS-20/TENEX 'dumper'
> format which was similar/only different.
> бђ§
>
> On Thu, Jul 15, 2021 at 3:03 PM Norman Wilson <norman at oclsc.org> wrote:
>
>> Nelson H. F. Beebe:
>>
>> P.S. Jay was the first to get Steve Johnson's Portable C Compiler,
>> pcc, to run on the 36-bit PDP-10, and once we had pcc, we began the
>> move from writing utilities in Pascal and PDP-10 assembly language to
>> doing them in C.
>>
>> ======
>>
>> How did that C implementation handle ASCII text on the DEC-10?
>> Were it a from-scratch UNIX port it might make sense to store
>> four eight- or nine-bit bytes to a word, but if (as I sense it
>> was) it was C running on TOPS-10 or TOPS-20, it would have had
>> to work comfortably with DEC's convention of five 7-bit characters
>> (plus a spare bit used by some programs as a flag).
>>
>> Norman Wilson
>> Toronto ON
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/0ca9c7c3/attachment.htm>
From tytso at mit.edu Fri Jul 16 05:33:48 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 15 Jul 2021 15:33:48 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
Message-ID: <YPCNnL4TLkLWqmFa@mit.edu>
On Thu, Jul 15, 2021 at 11:07:10AM -0400, Clem Cole wrote:
> In fact, [I can not say I personally know this - but have read internal
> memos that make the claim], Intel pays for more Linux developers and now
> LLVM developers than any firm. What's interesting is that Intel does not
> really directly sell its HW product to end-users. We sell to others than
> use our chips to make their products. We have finally moved to the
> support model for the compilers (I've personally been fighting that battle
> for 15 years).
That claim is probably from the data collected from the Linux
Foundation, which publishes these stats every year or two. The most
recent one is here:
https://www.linuxfoundation.org/wp-content/uploads/2020_kernel_history_report_082720.pdf
The top ten organizations responsible for commits from 2007 -- 2019:
(None) 11.95%
Intel 10.01%
Red Hat 8.90%
(Unknown) 4.09%
IBM 3.79%
SuSE 3.49%
Linaro 3.17%
(Consultant) 2.96%
Google 2.79%
Samsung 2.58%
"None" means no organizational affiliation (e.g., hobbyists, students,
etc.) "Unknown" means the organization affiliation couldn't be
determined.
For more recent data, if you look at the commits for the 5.10 release
(end of 2020), the top ten list by organizations looks like this:
Huawei 8.9%
Intel 8.0%
(Unknown) 6.6%
(None) 4.9%
Red Hat 5.7%
Google 5.2%
AMD 4.3%
Linaro 4.1%
Samsung 3.5%
IBM 3.2%
For the full list and more stats, see: https://lwn.net/Articles/839772/
> So back to my basic point ... while giving the *behavior* a name, the *idea
> *of "Open Source" is really not anything new.
I do think there is something which is radically new --- which is that
it's not a single company publishing all of the source code for a
particular OS, whether it's System/360 or the PDP-8 Disk Operating
System, or whatever.
In other words, it's the shared nature of the collaboration, which
partially solves the question of "who pays" --- the answer is, "lots
of companies, and they do so when it makes business sense for them to
do so". Intel may have had the largest number of contributions to
Linux historically --- but that was still 10%, and it was eclipsed by
people with no organizational affliation, and in the 5.10 kernel
Huawei slightly edged out Intel with 8.9% vs 8.0% contributions.
I completely agree with you that one of the key questions is the
business case issue. Not only who pays, but how do they justify the
software investment to the bean counters? Of course, the "Stone Soup"
story predates computers, so this certainly isn't a new business
model. And arguably the X Window Systems and the Open Software
Foundation also had a similar model where multiple companies
contributed to a common codebase, with perhaps mixed levels of
success.
The thing which Linux has managed to achieve, however, is the fact
that there is a large and diverse base of corporate contributions.
That to me is what makes the Linux model so interesting, and has been
a reason for its long-term sustainability.
Other companies may have been making their source code availble, but
the underlying business model behind their "source available" practices
was quite different.
Cheers,
- Ted
From imp at bsdimp.com Fri Jul 16 05:34:57 2021
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 15 Jul 2021 13:34:57 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
Message-ID: <CANCZdfpfzrU0SP5HY=0GVrbNaYPT9FP6pt6fsB+SgNDcCJCL0w@mail.gmail.com>
The C compiler we had at NMT that Greg Titus wrote/rewrote allowed one to
pick a number
of different choices for character size (5, 6, 7 or 8). It defaulted to 7
or 8. I recall that the
defaults produced OK results for student work, but that was a bit slow for
pushing the
envelope without some very careful choices. But it was good enough for me
to write
my OS group project running under 'ZAYEF' a DecSystem-20 emulator running
on the
DecSystem 20 under TOPS-20... My first exposure to virtual machines... It
was a total
trip to have 18 bit pointers and weird interrupt semantics....
I really rather working on the VAX 11/750 in 'C' and later on the Sun3/50s
more, though.
In part because the debugger was better (or at least more approachable by my
poor undergraduate mind).
Warner
On Thu, Jul 15, 2021 at 1:28 PM Clem Cole <clemc at ccc.com> wrote:
> The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target Alan
> Synder did for his MIT Thesis.
> It was originally targeted to ITS for the PDP-10, but it ran on Tops-20
> also.
>
> My >>memory<< is he used a 7-bit Character, ala SAIL, with 5 chars stored
> in a word with a bit leftover.
>
> You can check it out: https://github.com/PDP-10/Snyder-C-compiler
>
> I believe that C compiler Nelson is talking about I believe is actually
> Synder's that Jay either ported from ITS or WAITS.
>
> We had some form of the Synder compiler on the PDP-10's at CMU in the late
> 1970s.
> It was either Mike Accetta or Fil Aleva that wrote a program to read
> PDP-10 backup tapes, that I updated to deal with TOPS-20/TENEX 'dumper'
> format which was similar/only different.
> бђ§
>
> On Thu, Jul 15, 2021 at 3:03 PM Norman Wilson <norman at oclsc.org> wrote:
>
>> Nelson H. F. Beebe:
>>
>> P.S. Jay was the first to get Steve Johnson's Portable C Compiler,
>> pcc, to run on the 36-bit PDP-10, and once we had pcc, we began the
>> move from writing utilities in Pascal and PDP-10 assembly language to
>> doing them in C.
>>
>> ======
>>
>> How did that C implementation handle ASCII text on the DEC-10?
>> Were it a from-scratch UNIX port it might make sense to store
>> four eight- or nine-bit bytes to a word, but if (as I sense it
>> was) it was C running on TOPS-10 or TOPS-20, it would have had
>> to work comfortably with DEC's convention of five 7-bit characters
>> (plus a spare bit used by some programs as a flag).
>>
>> Norman Wilson
>> Toronto ON
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/d56cc596/attachment.htm>
From athornton at gmail.com Fri Jul 16 05:49:07 2021
From: athornton at gmail.com (Adam Thornton)
Date: Thu, 15 Jul 2021 12:49:07 -0700
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YPCNnL4TLkLWqmFa@mit.edu>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
Message-ID: <CAP2nic0qY4HrFTUYj0qwr=eney-re6Gn2O=0S23d6jwvOL_O+g@mail.gmail.com>
The thing which Linux has managed to achieve, however, is the fact
> that there is a large and diverse base of corporate contributions.
> That to me is what makes the Linux model so interesting, and has been
> a reason for its long-term sustainability.
>
>
Although from a somewhat different perspective, it's also why the Linux
kernel syscall interface is so unruly, right?
You've got your...some number in the small dozens of common syscalls, which
are already present for the most part in v6 or v7. These are the ones I,
at least, think of when I think of the Unix manual, section 2.
And then you've got all the other calls added in by (usually) this database
vendor or that storage vendor or the other display adapter vendor to make
their stuff work more efficiently.
And obviously there's a tradeoff there. Elegance departs, and you've
probably introduced some security risk because these syscalls are not
nearly as well-exercised as the common ones, but on the other hand you have
these large companies paying to work on the kernel, and you have them
supporting their product on Linux systems because the system can be bent
into accommodating them more easily, and it will run better there than on
OSes where they don't get to introduce features that benefit their
products, which further drives adoption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/76d88877/attachment.htm>
From akosela at andykosela.com Fri Jul 16 06:29:57 2021
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 15 Jul 2021 22:29:57 +0200
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <CAP2nic0qY4HrFTUYj0qwr=eney-re6Gn2O=0S23d6jwvOL_O+g@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
<CAP2nic0qY4HrFTUYj0qwr=eney-re6Gn2O=0S23d6jwvOL_O+g@mail.gmail.com>
Message-ID: <CALMnNGhkExT1H5JmgDn-4OiYjjDz=P8TQoZidbZ_G1vHNVcD3Q@mail.gmail.com>
On 7/15/21, Adam Thornton <athornton at gmail.com> wrote:
> The thing which Linux has managed to achieve, however, is the fact
>> that there is a large and diverse base of corporate contributions.
>> That to me is what makes the Linux model so interesting, and has been
>> a reason for its long-term sustainability.
>>
>>
> Although from a somewhat different perspective, it's also why the Linux
> kernel syscall interface is so unruly, right?
>
> You've got your...some number in the small dozens of common syscalls, which
> are already present for the most part in v6 or v7. These are the ones I,
> at least, think of when I think of the Unix manual, section 2.
>
> And then you've got all the other calls added in by (usually) this database
> vendor or that storage vendor or the other display adapter vendor to make
> their stuff work more efficiently.
>
> And obviously there's a tradeoff there. Elegance departs, and you've
> probably introduced some security risk because these syscalls are not
> nearly as well-exercised as the common ones, but on the other hand you have
> these large companies paying to work on the kernel, and you have them
> supporting their product on Linux systems because the system can be bent
> into accommodating them more easily, and it will run better there than on
> OSes where they don't get to introduce features that benefit their
> products, which further drives adoption.
The last time I looked it was actually FreeBSD that had the most
system calls (more than 500). Linux had more or less around the same
number as OpenBSD (more than 300).
UNIX V7 had around 50 -- this is still the golden standard, but
obviously a lot has changed since then...
--Andy
From clemc at ccc.com Fri Jul 16 06:30:15 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Jul 2021 16:30:15 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YPCNnL4TLkLWqmFa@mit.edu>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
Message-ID: <CAC20D2Pqu_hnt5A7XLtb6rRmniURmDc7Zzo4o6tzbZBD3pfJKA@mail.gmail.com>
On Thu, Jul 15, 2021 at 3:33 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:
> > So back to my basic point ... while giving the *behavior* a name, the
> *idea
> > *of "Open Source" is really not anything new.
>
> I do think there is something which is radically new --- which is that
> it's not a single company publishing all of the source code for a
> particular OS, whether it's System/360 or the PDP-8 Disk Operating
> System, or whatever.
Ted - that *is what* Doug pointed out!!! They did not create anything that
was new. SHARED / DECUS / USENIX and the like were providing that exact
same function starting in the late 1950s!!! Companies and Universities all
pooled their resources to make things better and to get new and improved
solutions. Sometimes they started with things that come from the
original OEM. Also often they created their own technology and made it
available to everyone. Sometime they combine both. And it was a
'bazaar where everyone had access and you chose to use it to not. Sounds
pretty familiar, BTW.
What >>has<< changed (dramatically) was the *method* and *ability* to
*distribute* your work and/or the manner you *obtained* someone else's
efforts. Today we download via the Web (much less ftp from a public area),
which is much more convenient than becoming a member of an organization and
having to obtain (typically for a small $50-$100 trape copying fee) a
9-track distribution tape. But even the concept of 'free' is really not
new as I said. Things like UCB's ILO used that model for a long time.
MIT, CMU, Stanford, Univerity of Waterloo, Cambridge, et al, just made
their work to any interested parties.
But due to the new way of being *interconnected *and a *much better
distribution scheme* that indeed is a huge feature. But please understand
'open source and collective sharing/working together is not a new thing
that just appeared with the Gnu project and was accelerated and taken to a
new level with the Linux work.
I personally blame esr's book for that beginning of the rewriting of
history/kicking the previous generations in the shins, as readers of it, or
worse readers of summations of it, miss the big picture instead of the
reality of standing on other shoulders.
I do want to give create for the cool and important things that have come.
I just want to make sure we don't forget the success of the modern world is
100% dependent on two important things: moore's law to make things more
economic and the hard work of a lot of people that came before (now and
before me for that matter).
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/9fe936ad/attachment.htm>
From jon at fourwinds.com Fri Jul 16 06:55:39 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 15 Jul 2021 13:55:39 -0700
Subject: [TUHS] Unix Shell Programming: The Next 50 Years - author's
response and my response
Message-ID: <202107152055.16FKteYd3043705@darkstar.fourwinds.com>
Below is a response from two of the authors with my response to it
inline. Not very impressed. Hopefully they'll get a clue and up
their game. In any case, enough time spent on it.
Jon
Michael Greenberg writes:
>
> HotOS isn't exactly a conventional venue---you might notice that many
> if not most HotOS papers don't fit the outline you've given.
I'm aware of that, and have participated in many unconventional venues
myself.В I wasn't saying that papers must fit that outline, but I do
believe that they should contain that information.В There's a big
difference between a discussion transcript and a paper; I believe that
papers, especially those published under the auspices of a prestigious
organization such as the ACM, should adhere to a higher standard.
> I'd definitely appreciate detailed feedback on any semantic errors
> we've made!
Unfortunately I can't help you here; that was feedback from
a reader who doesn't want to spend any more time on this.
> Your summary covers much of what we imagined!
>
> As I understand it, the primary goals of the paper were to (a) help
> other academics think about the shell as a viable area for research, (b)
> highlight some work we're doing on JIT compilation, (c) make the case
> for JIT approaches to the shell in general (as its well adapted to its
> dynamism), and (d) explore various axes on which the shell could be
> improved. It seems like we've done a good job communicating (b) to you,
> but perhaps not the rest. Sorry again to disappoint.
I certainly hope that you understand the primary goals of your own paper.
Point-by-point:
В (a)В While this is a valid point I don't understand why the paper didn't
just state it in a straightforward manner. There are several common
forms. One is to list issues in the introduction while explaining
which one(s) will be addressed in the paper. Another is in the
conclusion where authors list work still to be done.
В (b)В At least for me this goal was not accomplished because there were no
examples. Figure 1 by itself is insufficient given that the code
used to generate the "result" is not shown. It would have been much
more illuminating had the paper not only shown that code but also the
optimized result. Professionals don't blithely accept magic data.
В (c)В The paper failed to make this case to me for several reasons.
В В В As I understand it, the paper is somewhat about applying JIT
В В В compilation techniques to interconnected processes.В While most
В В В shells include syntax to support the construction of such, it's
В В В really independent of the shell.В For completeness, I have a vague
В В В memory of shell implementations for non-multitasking systems that
В В В sequentially ran pipelined programs passing intermediate results
В В В via temporary files.В The single "result" reminds me of something
that I saw at a science fair when my child was in middle school;
I looked a one team's results and asked "What makes you think that
a sample size of one is significant?" The lack of any benchmarks
or other study results that justified the work also undermined the
case. It reads more like the authors had something that they wanted
to play with rather than doing serious research. The paper does not
examine the percentage of shell scripts that actually benefit from
JIT compilation; for all the reader may know it's such a small number
that hand-optimizing just those scripts might be a better solution.
I suppose that the paper fits into the apparently modern philosophy
of expecting tools to fix up poorly written code so that programmers
don't have to understand what they're doing.
В (d)В In my opinion the paper didn't do this at all.В There was no
В В В analysis of "the shell" showing weaknesses and an explanation
В В В of why one particular path was taken.В And there was no discussion
В В В of what was being done with shells to cause whatever problems you
В В В were addressing and possibly ameliorating problems with some up-front
В В В sanity.В Again, being a geezer I'm reminded of past events
В В В that repeat themselves.В I joined a start-up company decades ago
В В В that was going to speed up circuit simulation 100x by plugging
В В В custom-designed floating-point processing boards into a multiprocessor
В В В machine.В I managed to beat that 100x just by cleverly crafting the
database and memory management code.В The fact that the company founder
never verified his idea led to a big waste of resources. But, he did
manage to raise venture capital which is akin to getting DARPA funds.
Nikos Vasilakis writes:
>
> To add to Michael's points, HotOS'В "position" papers are often
> intended as provocative, call-to-arms statements targeting primarily
> the research community (academic and industrial research). Our key
> position, which we possibly failed to communicate, is "Hey researchers
> everywhere, let's do more research on the shell! (and here's why)".
While provocative name-calling and false statements seem to have become
the political norm in America I don't think that they're appropriate in
a professional context.
In my experience a call-to-arms isn't productive unless those called
understand the nature of the call. I'm reminded of something that happened
many decades ago; my partner asked me to proof a paper that she was writing
for her masters degree.В I read it over with a confused look and asked her
what she was trying to say.В She responded, and I told her to write that
down and stop trying to sound like someone else.В Turned her into a much
better writer.В So if the paper wanted to say "Hey researchers ..." it
should have done so instead of being obtuse.
To continue on this point and Michael's (a) above, I don't see a lot of
value in proclaiming that research can be done.В I think that a more
fruitful approach is to cover what has been done, what you're doing,
and what you see but aren't doing.
> For our more conventional research papers related to the shell, which
> might cover your concerns about semantics, correctness, and
> performance please see next. These three papers also provide important
> context around the HotOS paper you read:
> ...
Tracking down your other work was key to understanding this paper.В It's
my opinion that my having to do is illustrative of the problems with the
paper.
> Thank you for taking the time to read our paper and comment on it.
> Could you please share the emails of everyone mentioned at the end of
> your email? We are preparing a longer report on a recent shell
> roundtable, and would love to get everyone's feedback!
While I appreciate the offer to send the longer report, it would only be
of interest if it was substantially more professional. There is no interest
in reviewing work that is not clearly presented, has not been proofread
and edited, includes unsubstantiated, pejorative, or meaningless statements,
includes incorrect examples, or statistically irrelevant results. Likewise,
there is also no interest if the homework hasn't been done to put the
report in context with regards to prior art and other current work.
Jon Steinghart <jsacm at fourwinds.com>
Warner Losh <imp at bsdimp.com>
John Cowan <cowan at ccil.org>
Larry McVoy <lm at mcvoy.com>
John Dow <jmd at nelefa.org>
Andy Kosela <akosela at andykosela.com>
Clem Cole <clemc at ccc.com>
Steve Bourne does not want to give out his address
From pnr at planet.nl Fri Jul 16 07:26:33 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 15 Jul 2021 23:26:33 +0200
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <4FA4AAA0-B3B8-410C-8307-A3ECEDE60E2C@planet.nl>
> Message: 7
> Date: Thu, 15 Jul 2021 10:28:04 -0400
> From: "Theodore Y. Ts'o"
> Subject: Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
>
> On Wed, Jul 14, 2021 at 10:38:06PM -0400, Douglas McIlroy wrote:
>> Head might not have been written if tail didn't exist. But, unlike head,
>> tail strayed from the tao of "do one thing well". Tail -r and tail -f are
>> as cringeworthy as cat -v.
>>
>> -f is a strange feature that effectively turns a regular file into a pipe
>> with memory by polling for new data, A clean general alternative
>> might be to provide an open(2) mode that makes reads at the current
>> file end block if some process has the file open for writing.
>
> OTOH, this would mean adding more functionality (read: complexity)
> into the kernel, and there has always been a general desire to avoid
> pushing <stuff> into the kernel when it can be done in userspace. Do
> you really think using a blocking read(2) is somehow more superior
> than using select(2) to wait for new data to be appended to the file?
>
> And even if we did this using a new open(2) mode, are you saying we
> should have a separate executable in /bin which would then be
> identical to cat, except that it uses a different open(2) mode?
Yes, it would put more complexity into the kernel, but maybe it is conceptually elegant.
Consider a classic pipe or a socket and the behaviour of read(2) for those objects. The behaviour of read(2) that Doug proposes for a file would make it in line with that for a classic pipe or a socket. Hence, maybe it should not be a mode, but the standard behaviour.
I often think that around 1981 the Unix community missed an opportunity to really think through how networking should integrate with the foundations of Unix. It seems to me that at that time there was an opportunity to merge files, pipes and sockets into a coherent, simple framework. If the 8th edition file-system-switch had been introduced already in V6 or V7, maybe this would have happened.
On the other hand, the installed base was probably already too large in 1981 to still make breaking changes to core concepts. V7 may have been the last chance saloon for that.
Paul
From douglas.mcilroy at dartmouth.edu Fri Jul 16 08:00:19 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Thu, 15 Jul 2021 18:00:19 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CAKH6PiVTsSHd625MHW3N3TGULcu=aD0RKxhiJVcAf14fKHUEsA@mail.gmail.com>
>> -f is a strange feature that effectively turns a regular file into a pipe
>> with memory by polling for new data, A clean general alternative
>> might be to provide an open(2) mode that makes reads at the current
>> file end block if some process has the file open for writing.
> OTOH, this would mean adding more functionality (read: complexity)
> into the kernel, and there has always been a general desire to avoid
> pushing <stuff> into the kernel when it can be done in userspace. Do
> you really think using a blocking read(2) is somehow more superior
> than using select(2) to wait for new data to be appended to the file?
I'm showing my age. tail -f antedated select(2) and was implemented
by alternately sleeping and reading. select(2) indeed overcomes that
clumsiness.
> I'll note, with amusement, that -r is one option which is *NOT* in the
> GNU version of tail. I see it in FreeBSD, but this looks like a
> BSD'ism.
-r came from Bell Labs. This reinforces the point that the ancients
had their imperfections.
Doug
From cowan at ccil.org Fri Jul 16 08:12:52 2021
From: cowan at ccil.org (John Cowan)
Date: Thu, 15 Jul 2021 18:12:52 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiVTsSHd625MHW3N3TGULcu=aD0RKxhiJVcAf14fKHUEsA@mail.gmail.com>
References: <CAKH6PiVTsSHd625MHW3N3TGULcu=aD0RKxhiJVcAf14fKHUEsA@mail.gmail.com>
Message-ID: <CAD2gp_SiXyE=-Gw0bzZH2Tyo=4xz_=CzaDecTL9DOrhFzAND-w@mail.gmail.com>
On Thu, Jul 15, 2021 at 6:00 PM Douglas McIlroy <
douglas.mcilroy at dartmouth.edu> wrote:
> I'm showing my age. tail -f antedated select(2) and was implemented
> by alternately sleeping and reading. select(2) indeed overcomes that
> clumsiness.
>
A fd at EOF is considered by select and friends to be ready, as it is
possible to read from it without hanging.
> -r came from Bell Labs. This reinforces the point that the ancients
> had their imperfections.
>
A Unix zealot, having heard that Master Foo was wise in the Great Way, came
to him for instruction. Master Foo said to him:
“When the Patriarch Thompson invented Unix, he did not understand it. Then
he gained in understanding, and no longer invented it.”
“When the Patriarch McIlroy invented the pipe, he knew that it would
transform software, but did not know that it would transform mind.”
“When the Patriarch Ritchie invented C, he condemned programmers to a
thousand hells of buffer overruns, heap corruption, and stale-pointer bugs.”
“Truly, the Patriarchs were blind and foolish!”
The zealot was greatly angered by the Master's words.
“These enlightened ones,” he protested, “gave us the Great Way of Unix.
Surely, if we mock them we will lose merit and be reborn as beasts or
MCSEs.”
“Is your code ever completely without stain and flaw?” demanded Master Foo.
“No,” admitted the zealot, “no man's is.”
“The wisdom of the Patriarchs” said Master Foo, “was that they *knew* they
were fools.”
Upon hearing this, the zealot was enlightened.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/d4c51d16/attachment.htm>
From beebe at math.utah.edu Fri Jul 16 08:26:09 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 15 Jul 2021 16:26:09 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
Clem Cole asks:
>> Did you know that before PCC the 'second' C compiler was a PDP-10
>> target Alan Snyder did for his MIT Thesis?
>> [https://github.com/PDP-10/Snyder-C-compiler]
I was unaware of that compiler until sometime in the 21st Century,
long after our PDP-10 was retired on 31-Oct-1990.
The site
https://github.com/PDP-10/Snyder-C-compiler/tree/master/tops20
supplies a list of some of Snyder's files, but they don't match
anything in our TOPS-20 archives of almost 180,000 files.
I then looked into our 1980s-vintage pcc source tree and compared
it with a snapshot of the current pcc source code taken three
weeks ago. The latter has support for these architectures
aarch64 hppa m16c mips64 pdp11 sparc64
amd64 i386 m68k nova pdp7 superh
arm i86 mips pdp10 powerpc vax
and the pdp10 directory contains these files:
CVS README code.c local.c local2.c macdefs.h order.c table.c
All 5 of those *.c files are present in our TOPS-20 archives. I then
grepped those archives for familiar strings:
% find . -name '*.[ch]' | sort | \
xargs egrep -n -i 'scj|feldman|johnson|snyder|bell|at[&]t|mit|m.i.t.'
./code.c:8: * Based on Steve Johnson's pdp-11 version
./code2.c:19: * Based on Steve Johnson's pdp-11 version
./cpp.c:1678: stsym("TOPS20"); /* for compatibility with Snyder */
./local.c:4: * Based on Steve Johnson's pdp-11 version
./local2.c:4: * Based on Steve Johnson's pdp-11 version
./local2.c:209: case 'A': /* emit a label */
./match.c:2: * match.c - based on Steve Johnson's pdp11 version
./optim.c:318: * Turn 'em into regular PCONV's
./order.c:5: * Based on Steve Johnson's pdp-11 version
./pftn.c:967: * fill out previous word, to permit pointer
./pftn.c:1458: register commflag = 0; /* flag for labelled common declarations */
./pftn2.c:1011: * fill out previous word, to permit pointer
./pftn2.c:1502: register commflag = 0; /* flag for labelled common declarations */
./reader.c:632: p2->op = NOASG p2->op; /* this was omitted in 11 & /6 !! */
./table.c:128: " movei A1,1\nZN", /* ZN = emit branch */
./xdefs.c:13: * symbol table maintainence
Thus, I'm confident that Jay's work was based on Steve Johnson's
compiler, rather than Alan Snyder's.
Norman Wilson asks:
>> ...
>> How did that C implementation handle ASCII text on the DEC-10?
>> Were it a from-scratch UNIX port it might make sense to store
>> four eight- or nine-bit bytes to a word, but if (as I sense it
>> was) it was C running on TOPS-10 or TOPS-20, it would have had
>> to work comfortably with DEC's convention of five 7-bit characters
>> (plus a spare bit used by some programs as a flag).
>> ...
Our pcc compiler treated char* as a pointer to 7-bit ASCII strings,
stored in the top 35 bits of a word, with the low-order bit normally
zero; a 1-bit there meant that the word contained a 5-digit line
number that some compilers and editors would report. Of course, that
low-order non-character bit meant that memset(), memcpy(), and
memmove() had somewhat dicey semantics, but I no longer recall their
specs.
kcc later gave us access to the PDP-10's 1- to 36-bit byte
instructions.
For text processing, 5 x 7b + 1b bits matched the conventions for all
other programming languages on the PDP-10. When it came time to
implement NFS, and exchange files and data with 32-bit-word machines,
we needed the ability to handle files of 4 x 8b + 4b and 9 x 8b (in
two 36-bit words), and kcc provided that.
The one's-complement 36-bit Univac 1108 machines chose instead to
store text in a 4 x 9b format, because that architecture had
quarter-word load/store instructions, but not the general variable
byte instructions of the PDP-10. Our campus had an 1108 at the
University of Utah Computer Center, but I chose to avoid it, because
it was run in batch mode with punched cards, and never got networking.
By contrast, our TOPS-20, BSD, RSX-11, SunOS, and VMS systems all had
interactive serial-line terminals, and there was no punched card
support at all.
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From douglas.mcilroy at dartmouth.edu Fri Jul 16 08:27:25 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Thu, 15 Jul 2021 18:27:25 -0400
Subject: [TUHS] TUHS Digest, Vol 68, Issue 23
Message-ID: <CAKH6PiUHsVXC+ro8jQ+ycXCJ7n+G2x-OfN=n43iBGCrFo4=Bdw@mail.gmail.com>
The topic is intended, not a side effect of hitting reply.
This issue of the digest is a real keeper. So many memories; so illuminating!
Doug
From bakul at iitbombay.org Fri Jul 16 08:29:40 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 15 Jul 2021 15:29:40 -0700
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
References: <CAKH6PiWDnDBEE9vWRU+6kAuEcMNFdpJ9tiv0=9VUr-LMJRRBbw@mail.gmail.com>
Message-ID: <F78F5E0A-0DBF-4739-B13F-48367BBEF358@iitbombay.org>
On Jul 14, 2021, at 7:38 PM, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> wrote:
>
> -r is weird because it enables backwards reading, but only as
> limited by count. Better would be a program, say revfile, that simply
> reads backwards by lines. Then tail p has an elegant implementation:
> revfile p | head | revfile
tail -n can be smarter in that it can simply read the last K bytes
and see if there are n lines. If not, it can read back further.
revfile would have to read the whole file, which could be a lot
more than n lines! tail -n < /dev/tty may never terminate but it
will use a small finite amount of memory.
-- Bakul
From joe at via.net Fri Jul 16 09:02:02 2021
From: joe at via.net (joe mcguckin)
Date: Thu, 15 Jul 2021 16:02:02 -0700
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YPCNnL4TLkLWqmFa@mit.edu>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
Message-ID: <36A1FADC-560D-47D2-9F0C-401A1B4E1655@via.net>
I remember going to one of those cattle-call hiring events. I wanted to speak with the Intel compiler guy and when I got up to him, all he said
was “Ganapathi”.
I actually knew who/what hw was talking about.
So, has Intel killed their own compiler toolset?
Joe McGuckin
ViaNet Communications
joe at via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax
> On Jul 15, 2021, at 12:33 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> On Thu, Jul 15, 2021 at 11:07:10AM -0400, Clem Cole wrote:
>> In fact, [I can not say I personally know this - but have read internal
>> memos that make the claim], Intel pays for more Linux developers and now
>> LLVM developers than any firm. What's interesting is that Intel does not
>> really directly sell its HW product to end-users. We sell to others than
>> use our chips to make their products. We have finally moved to the
>> support model for the compilers (I've personally been fighting that battle
>> for 15 years).
>
> That claim is probably from the data collected from the Linux
> Foundation, which publishes these stats every year or two. The most
> recent one is here:
>
> https://www.linuxfoundation.org/wp-content/uploads/2020_kernel_history_report_082720.pdf
>
> The top ten organizations responsible for commits from 2007 -- 2019:
>
> (None) 11.95%
> Intel 10.01%
> Red Hat 8.90%
> (Unknown) 4.09%
> IBM 3.79%
> SuSE 3.49%
> Linaro 3.17%
> (Consultant) 2.96%
> Google 2.79%
> Samsung 2.58%
>
> "None" means no organizational affiliation (e.g., hobbyists, students,
> etc.) "Unknown" means the organization affiliation couldn't be
> determined.
>
> For more recent data, if you look at the commits for the 5.10 release
> (end of 2020), the top ten list by organizations looks like this:
>
> Huawei 8.9%
> Intel 8.0%
> (Unknown) 6.6%
> (None) 4.9%
> Red Hat 5.7%
> Google 5.2%
> AMD 4.3%
> Linaro 4.1%
> Samsung 3.5%
> IBM 3.2%
>
> For the full list and more stats, see: https://lwn.net/Articles/839772/
>
>> So back to my basic point ... while giving the *behavior* a name, the *idea
>> *of "Open Source" is really not anything new.
>
> I do think there is something which is radically new --- which is that
> it's not a single company publishing all of the source code for a
> particular OS, whether it's System/360 or the PDP-8 Disk Operating
> System, or whatever.
>
> In other words, it's the shared nature of the collaboration, which
> partially solves the question of "who pays" --- the answer is, "lots
> of companies, and they do so when it makes business sense for them to
> do so". Intel may have had the largest number of contributions to
> Linux historically --- but that was still 10%, and it was eclipsed by
> people with no organizational affliation, and in the 5.10 kernel
> Huawei slightly edged out Intel with 8.9% vs 8.0% contributions.
>
> I completely agree with you that one of the key questions is the
> business case issue. Not only who pays, but how do they justify the
> software investment to the bean counters? Of course, the "Stone Soup"
> story predates computers, so this certainly isn't a new business
> model. And arguably the X Window Systems and the Open Software
> Foundation also had a similar model where multiple companies
> contributed to a common codebase, with perhaps mixed levels of
> success.
>
> The thing which Linux has managed to achieve, however, is the fact
> that there is a large and diverse base of corporate contributions.
> That to me is what makes the Linux model so interesting, and has been
> a reason for its long-term sustainability.
>
> Other companies may have been making their source code availble, but
> the underlying business model behind their "source available" practices
> was quite different.
>
> Cheers,
>
> - Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/5d18f6a1/attachment.htm>
From jim.epost at gmail.com Fri Jul 16 09:18:03 2021
From: jim.epost at gmail.com (Jim Davis)
Date: Thu, 15 Jul 2021 16:18:03 -0700
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
Message-ID: <CA+r1Zhgmf8zbBiztO3Ab1H7Hd7HZQZxqTbTRahtXWfowC=A4qQ@mail.gmail.com>
On Thu, Jul 15, 2021 at 3:27 PM Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> Our campus had an 1108 at the
> University of Utah Computer Center, but I chose to avoid it, because
> it was run in batch mode with punched cards, and never got networking.
It was a terrible beast. One place to submit card decks +
undergraduate procrastination was an unhappy combination. Later
there was a crude form a timesharing grafted on to it, with some very
shrill terminals attached. The details are mercifully vague but I
think you basically had a 'session' and whatever files you created in
that session didn't persist once you'd logged out.
I remember trying to use the C compiler on that DEC-20 but never got
very far with it; I thought the SAIL compiler was more interesting.
Shows what foresight I had...
--
Jim (op.davis at science.utah.edu, iirc)
From clemc at ccc.com Fri Jul 16 10:02:41 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Jul 2021 20:02:41 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
Message-ID: <CAC20D2NA4uEdnZupSLR=d-v7UAJ9dstgznUTHTC1kWCN+RHxOQ@mail.gmail.com>
Nelson thanks. Excellent bit of snooping. I wonder why Jay did his
version? Maybe he wanted a more modern C features since the Snyder
compiler would been based on a very early C dialect.
Steve Johnson do you have any insight?
As I understand it, Alan started his work by rewritting your Honeywell B
compiler to be a C compiler when the C language was quite young and many
features we take for granted were not yet created.
Clem
On Thu, Jul 15, 2021 at 6:26 PM Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:
> Clem Cole asks:
>
> >> Did you know that before PCC the 'second' C compiler was a PDP-10
> >> target Alan Snyder did for his MIT Thesis?
> >> [https://github.com/PDP-10/Snyder-C-compiler]
>
> I was unaware of that compiler until sometime in the 21st Century,
> long after our PDP-10 was retired on 31-Oct-1990.
>
> The site
>
> https://github.com/PDP-10/Snyder-C-compiler/tree/master/tops20
>
> supplies a list of some of Snyder's files, but they don't match
> anything in our TOPS-20 archives of almost 180,000 files.
>
> I then looked into our 1980s-vintage pcc source tree and compared
> it with a snapshot of the current pcc source code taken three
> weeks ago. The latter has support for these architectures
>
> aarch64 hppa m16c mips64 pdp11 sparc64
> amd64 i386 m68k nova pdp7 superh
> arm i86 mips pdp10 powerpc vax
>
> and the pdp10 directory contains these files:
>
> CVS README code.c local.c local2.c macdefs.h order.c table.c
>
> All 5 of those *.c files are present in our TOPS-20 archives. I then
> grepped those archives for familiar strings:
>
> % find . -name '*.[ch]' | sort | \
> xargs egrep -n -i
> 'scj|feldman|johnson|snyder|bell|at[&]t|mit|m.i.t.'
> ./code.c:8: * Based on Steve Johnson's pdp-11 version
> ./code2.c:19: * Based on Steve Johnson's pdp-11 version
> ./cpp.c:1678: stsym("TOPS20"); /* for
> compatibility with Snyder */
> ./local.c:4: * Based on Steve Johnson's pdp-11 version
> ./local2.c:4: * Based on Steve Johnson's pdp-11 version
> ./local2.c:209: case 'A': /* emit a label */
> ./match.c:2: * match.c - based on Steve Johnson's pdp11 version
> ./optim.c:318: * Turn
> 'em into regular PCONV's
> ./order.c:5: * Based on Steve Johnson's pdp-11 version
> ./pftn.c:967: * fill out previous word, to
> permit pointer
> ./pftn.c:1458: register commflag = 0; /* flag for
> labelled common declarations */
> ./pftn2.c:1011: * fill out previous word, to
> permit pointer
> ./pftn2.c:1502: register commflag = 0; /* flag for
> labelled common declarations */
> ./reader.c:632: p2->op = NOASG p2->op; /* this was
> omitted in 11 & /6 !! */
> ./table.c:128: " movei A1,1\nZN", /* ZN =
> emit branch */
> ./xdefs.c:13: * symbol table maintainence
>
> Thus, I'm confident that Jay's work was based on Steve Johnson's
> compiler, rather than Alan Snyder's.
>
> Norman Wilson asks:
>
> >> ...
> >> How did that C implementation handle ASCII text on the DEC-10?
> >> Were it a from-scratch UNIX port it might make sense to store
> >> four eight- or nine-bit bytes to a word, but if (as I sense it
> >> was) it was C running on TOPS-10 or TOPS-20, it would have had
> >> to work comfortably with DEC's convention of five 7-bit characters
> >> (plus a spare bit used by some programs as a flag).
> >> ...
>
> Our pcc compiler treated char* as a pointer to 7-bit ASCII strings,
> stored in the top 35 bits of a word, with the low-order bit normally
> zero; a 1-bit there meant that the word contained a 5-digit line
> number that some compilers and editors would report. Of course, that
> low-order non-character bit meant that memset(), memcpy(), and
> memmove() had somewhat dicey semantics, but I no longer recall their
> specs.
>
> kcc later gave us access to the PDP-10's 1- to 36-bit byte
> instructions.
>
> For text processing, 5 x 7b + 1b bits matched the conventions for all
> other programming languages on the PDP-10. When it came time to
> implement NFS, and exchange files and data with 32-bit-word machines,
> we needed the ability to handle files of 4 x 8b + 4b and 9 x 8b (in
> two 36-bit words), and kcc provided that.
>
> The one's-complement 36-bit Univac 1108 machines chose instead to
> store text in a 4 x 9b format, because that architecture had
> quarter-word load/store instructions, but not the general variable
> byte instructions of the PDP-10. Our campus had an 1108 at the
> University of Utah Computer Center, but I chose to avoid it, because
> it was run in batch mode with punched cards, and never got networking.
> By contrast, our TOPS-20, BSD, RSX-11, SunOS, and VMS systems all had
> interactive serial-line terminals, and there was no punched card
> support at all.
>
>
> -------------------------------------------------------------------------------
> - 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 at math.utah.edu -
> - 155 S 1400 E RM 233 beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
>
--
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/98764b2b/attachment.htm>
From john at jfloren.net Fri Jul 16 10:02:21 2021
From: john at jfloren.net (John Floren)
Date: Fri, 16 Jul 2021 00:02:21 +0000
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CA+r1Zhgmf8zbBiztO3Ab1H7Hd7HZQZxqTbTRahtXWfowC=A4qQ@mail.gmail.com>
References: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
<CA+r1Zhgmf8zbBiztO3Ab1H7Hd7HZQZxqTbTRahtXWfowC=A4qQ@mail.gmail.com>
Message-ID: <hnYS2RW60oBvlvcvoqNGbwEJCtOEHmclm_z1B_Od-Kc_vHLWpHYtHvFR5cVoNWdJXxy0h_3P8lFT-gAb2pO8BhHxGUtQ_-QmuFCuc2g9G2k=@jfloren.net>
On Thursday, July 15th, 2021 at 4:18 PM, Jim Davis <jim.epost at gmail.com> wrote:
> I remember trying to use the C compiler on that DEC-20 but never got
>
> very far with it; I thought the SAIL compiler was more interesting.
>
> Shows what foresight I had...
Speaking of SAIL (and I suppose further derailing an already derailed discussion), I've occasionally looked for more information about the environment (typically whenever a book or article briefly mentions SAIL as a place with lots of custom hardware and software) but come up with little. Anyone know of good description of SAIL computer systems?
john
From beebe at math.utah.edu Fri Jul 16 10:25:41 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 15 Jul 2021 18:25:41 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAC20D2NA4uEdnZupSLR=d-v7UAJ9dstgznUTHTC1kWCN+RHxOQ@mail.gmail.com>
Message-ID: <CMM.0.95.0.1626395141.beebe@gamma.math.utah.edu>
Clem Cole asks:
>> I wonder why Jay did his version? Maybe he wanted more modern
>> C features since the Snyder compiler would been based on a very
>> early C dialect.
I never talked to Jay about his motivation for working on pcc for
TOPS-20. I visited Ken Harrenstien at SRI, but regrettably, only
once. I have great admiration for his work on kcc, and later, his
PDP-10 emulator (written in C, of course).
I suspect that the main reason was that in the early 1980s, we could
still see years of use of our PDP-10 systems in Computer Science and
the College of Science, yet, being Node 4 of the original 5 nodes of
the Arpanet, we were in frequent contact with Berkeley people who were
active in the BSD effort.
Besides our PDP-10s, we had several PDP-11s and VAXes that could run
Unix, so we wanted our software to run on all of those systems, and C
would be the obvious common programming language. Also, the PC
revolution that started in roughly 1980 made it clear that computers
were going to get a lot cheaper, and a lot more numerous, so in
academia, we would phase out our Big Iron machines and replace them
with Unix workstations.
To help our users begin to make the transition to Unix, I wrote this
Rosetta Stone document:
Unix for TOPS-20 Users
[24-June-1987]
http://www.math.utah.edu/~beebe/publications/1987/t20unix.pdf
I've not looked at it in years, and I might now cringe at parts, but
most of our users in the College of Science were not computer geeks,
but just scientists and mathematicians trying to do their research and
teaching, so they needed help.
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From beebe at math.utah.edu Fri Jul 16 11:02:03 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 15 Jul 2021 19:02:03 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <hnYS2RW60oBvlvcvoqNGbwEJCtOEHmclm_z1B_Od-Kc_vHLWpHYtHvFR5cVoNWdJXxy0h_3P8lFT-gAb2pO8BhHxGUtQ_-QmuFCuc2g9G2k=@jfloren.net>
Message-ID: <CMM.0.95.0.1626397299.beebe@gamma.math.utah.edu>
John Floren asks
>> Anyone know of good description of SAIL computer systems?
SAIL was both an operating system at Stanford, and a programming
language at the same site, but the SAIL compiler ran on multiple
operating systems on the PDP-10.
The first edition of William M. Newman and Robert F. Sproull's
``Principles of Interactive Computer Graphics'', McGraw-Hill, 1973,
ISBN 0-07-046337-9, had an appendix on the SAIL language, but that
book is in my campus office, and this week, I'm working at home, so I
cannot check how much they had to say about SAIL. The bitsavers
archive should have programming language manuals for the SAIL
language.
When TeX and METAFONT were first written in 1977--1978, Don Knuth
programmed them both in SAIL, because it had the needed data
structures, recursion, and a good debugger. However, by 1982, despite
the MAINSAIL effort to port the SAIL language to other platforms, it
became clear that a different implementation language was called for,
and the only candidate that offered portability to multiple CPU
architectures and operating systems at the time was Pascal.
That language has a number of syntactic aggravations, including
fixed-length character strings, so Don used his tangle preprocessor to
rewrite strings as lists of integers, and otherwise stuck to a strict
subset of Pascal. By the late 1980s, the Pascal code was translated,
first manually, then automatically to C, and that is the language in
which it gets compiled today. Any changes to the source code,
however, are done strictly in the original Pascal subset. This year,
I have built TeX Live 2021 on AMD64, ARM32, ARM64, Alpha, M68K, MIPS,
PowerPC, RISC-V64, S390x, SPARC, and x86 CPUs, under numerous
operating systems, demonstrating that, thanks to C and Unix, TeX and
METAFONT remain widely portable.
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From dave at horsfall.org Fri Jul 16 11:35:57 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 16 Jul 2021 11:35:57 +1000 (EST)
Subject: [TUHS] 386BSD released
In-Reply-To: <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
Message-ID: <alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
On Wed, 14 Jul 2021, Michael Kjörling wrote:
>> In 1992, 386BSD is released by Lynne and William Jolitz, starting the
>> open source operating system movement (Linux didn't come along under
>> later).
>
> Are you sure? Wikipedia claims that it happened the other way around;
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while the
> 386BSD initial release was 0.0 on 12 March 1992.
Could be; I got that news from one of those daily history sites (I don't
always trust Wikipedia).
> It seems that work on 386BSD began earlier than work on Linux, but that
> the initial release of Linux was earlier than the initial release of
> 386BSD.
That could be the source of the confusion.
-- Dave
From tytso at mit.edu Fri Jul 16 11:58:53 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 15 Jul 2021 21:58:53 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <CAC20D2Pqu_hnt5A7XLtb6rRmniURmDc7Zzo4o6tzbZBD3pfJKA@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
<CAC20D2Pqu_hnt5A7XLtb6rRmniURmDc7Zzo4o6tzbZBD3pfJKA@mail.gmail.com>
Message-ID: <YPDn3XRqRQ4a2UKl@mit.edu>
On Thu, Jul 15, 2021 at 04:30:15PM -0400, Clem Cole wrote:
>
> Ted - that *is what* Doug pointed out!!! They did not create anything that
> was new. SHARED / DECUS / USENIX and the like were providing that exact
> same function starting in the late 1950s!!! Companies and Universities all
> pooled their resources to make things better and to get new and improved
> solutions. Sometimes they started with things that come from the
> original OEM. Also often they created their own technology and made it
> available to everyone. Sometime they combine both. And it was a
> 'bazaar where everyone had access and you chose to use it to not. Sounds
> pretty familiar, BTW.
I remember looking at the DECUS program catalog for the PDP-8, and I
seem to recall that for the most part, individuals were sharing their
programs with others. In that way, it wasn't all that different from
say, CPM/UG, and HUG (Heathkit Users Group). But the thing is, for
the most part, it was a single author sharing individual programs, and
often changes were not accepted back.
Consider the history of Bill Jolitz and 386BSD, and the collection of
patches that eventuallya became NetBSD and FreeBSD, which was formed
because they were frustrated that they couldn't get their patch sets
back into Jolitz's code base. Technology plays a part, in that it
enables the change. But it's not just about technology. There is
also a very strong social component. Even when you were richly
interconnected at the network level, this does not guarantee that will
be willing to be richly interconnected in terms of accepting patch
sets from people who you may not know across the Internet, into *your*
program, for which you are the author and high priest.
I don't remember the exact date, but it would have been in the early
90's, when at the time I was already contributing patches to Linux,
and where ftp and e-mail and applying patches via context diffs was
very much available. At that time, we were interested in getting
support for MIT Project Athena's Hesiod extenstions into the BIND
distributions (we had just been carrying patches against BIND for many
years).
In order to get those patches integrated, Paul Vixie invited me to his
house in Redwood City, and so I flew from Boston to San Francisco,
carrying my Linux laptop with the BIND patches, and we got the patches
integrated into master BIND sources. Paul was a gracious host, and it
was lovely that I got to spend some time with him. But it was
interesting that my physical presence was needed, or at least highly
useful, in terms of getting those patches into BIND. Requiring
physical presence to get patches integrated.... doesn't scale.
And so it wasn't a matter of technology, since the technology for
Linus, who didn't know me from Adam in 1991, to accept patches from me
implementing BSD Job Control, was certainly available when I was
working with Paul to get the Hesiod changes integrated into BIND. But
like with Jolitz and 386BSD, it's a mindset thing, not just technology.
I also want to emphasize again, the question of business model is also
something which I think is different, and *important*. It's one thing
for Academics and Researchers to be willing to give changes away to
anyone who wants. It's quite another for a company to give away their
intellectual property in such a way that it can actually be used by
their competitors, either because that's the social convention, or
because it's enforced by the license. Was the practices we use today
for Linux built on the traditions of comp.sources.unix, and BSD, and
AT&T Research, and IBM making sources available for System/360, yadda,
yadda, yadda? Of course! I'm not denying that.
But at the same time, to claim that nothing is new under the Sun, and
*all* of this had been done decades earlier, is also not the whole
story. And to call IBM releasing System/360, when they retained
control of the license, and wasn't accepting any changes back, and
*darned* well would have sued anyone trying to use that code on
non-IBM computers into a smoking crater, as "Open Source" can be
highly misleading, because that is not what most people associate with
the term "Open Source" today.
And if we take a look at what AT&T Lawyers did with the Unix source
code, at some point, it most *defintely* was the antithesis of "Open
Source". Which would lead me to assert that Unix was never really
released under what today we would call, "Open Source".
Cheers,
- Ted
From ggm at algebras.org Fri Jul 16 12:14:43 2021
From: ggm at algebras.org (George Michaelson)
Date: Fri, 16 Jul 2021 12:14:43 +1000
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <YPDn3XRqRQ4a2UKl@mit.edu>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
<CAC20D2Pqu_hnt5A7XLtb6rRmniURmDc7Zzo4o6tzbZBD3pfJKA@mail.gmail.com>
<YPDn3XRqRQ4a2UKl@mit.edu>
Message-ID: <CAKr6gn1UOc5=K+Cghp3qUfjk6SBv1p3LVSF=TZ3=-a6tK6EVwQ@mail.gmail.com>
I was part of a discussion about a bug in the DECUS tape in Leeds uni,
in '82-84 window. I was a very small part I might add, not the
principal. I can't remember the package. It was probably trivia, like
walking a specific SYS$SYSTEM value in a way which was dangerous or
encoded assumptions about device:directory:user models in VMS.
The feedback I got from this process was "thanks, we'll think about
it" was closure, for those days. We'd been pretty specific about a
fix. I got the sense the tape was an annual affair. And the likelihood
of our "patch" being both accepted, and added to the next round of the
tape was low-to-zero because everyone wanted "moar" and so people
focussed on adding things, not fixing things.
The exception here was compilers: people always want bugs fixed in a
compiler. Or the NAG library, but both compilers (language spec) and
NAG (strict maths formalisms about correctness) had policed mechanisms
to accept user input, validate, run through a remorselessly tight
compliance check, and emit, if it survived.
A bug in the implementation of MUD for dec-10? ok, so the word
"potato" is misspelled on one screen. Move on.
On Fri, Jul 16, 2021 at 11:59 AM Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> On Thu, Jul 15, 2021 at 04:30:15PM -0400, Clem Cole wrote:
> >
> > Ted - that *is what* Doug pointed out!!! They did not create anything that
> > was new. SHARED / DECUS / USENIX and the like were providing that exact
> > same function starting in the late 1950s!!! Companies and Universities all
> > pooled their resources to make things better and to get new and improved
> > solutions. Sometimes they started with things that come from the
> > original OEM. Also often they created their own technology and made it
> > available to everyone. Sometime they combine both. And it was a
> > 'bazaar where everyone had access and you chose to use it to not. Sounds
> > pretty familiar, BTW.
>
> I remember looking at the DECUS program catalog for the PDP-8, and I
> seem to recall that for the most part, individuals were sharing their
> programs with others. In that way, it wasn't all that different from
> say, CPM/UG, and HUG (Heathkit Users Group). But the thing is, for
> the most part, it was a single author sharing individual programs, and
> often changes were not accepted back.
>
> Consider the history of Bill Jolitz and 386BSD, and the collection of
> patches that eventuallya became NetBSD and FreeBSD, which was formed
> because they were frustrated that they couldn't get their patch sets
> back into Jolitz's code base. Technology plays a part, in that it
> enables the change. But it's not just about technology. There is
> also a very strong social component. Even when you were richly
> interconnected at the network level, this does not guarantee that will
> be willing to be richly interconnected in terms of accepting patch
> sets from people who you may not know across the Internet, into *your*
> program, for which you are the author and high priest.
>
> I don't remember the exact date, but it would have been in the early
> 90's, when at the time I was already contributing patches to Linux,
> and where ftp and e-mail and applying patches via context diffs was
> very much available. At that time, we were interested in getting
> support for MIT Project Athena's Hesiod extenstions into the BIND
> distributions (we had just been carrying patches against BIND for many
> years).
>
> In order to get those patches integrated, Paul Vixie invited me to his
> house in Redwood City, and so I flew from Boston to San Francisco,
> carrying my Linux laptop with the BIND patches, and we got the patches
> integrated into master BIND sources. Paul was a gracious host, and it
> was lovely that I got to spend some time with him. But it was
> interesting that my physical presence was needed, or at least highly
> useful, in terms of getting those patches into BIND. Requiring
> physical presence to get patches integrated.... doesn't scale.
>
> And so it wasn't a matter of technology, since the technology for
> Linus, who didn't know me from Adam in 1991, to accept patches from me
> implementing BSD Job Control, was certainly available when I was
> working with Paul to get the Hesiod changes integrated into BIND. But
> like with Jolitz and 386BSD, it's a mindset thing, not just technology.
>
> I also want to emphasize again, the question of business model is also
> something which I think is different, and *important*. It's one thing
> for Academics and Researchers to be willing to give changes away to
> anyone who wants. It's quite another for a company to give away their
> intellectual property in such a way that it can actually be used by
> their competitors, either because that's the social convention, or
> because it's enforced by the license. Was the practices we use today
> for Linux built on the traditions of comp.sources.unix, and BSD, and
> AT&T Research, and IBM making sources available for System/360, yadda,
> yadda, yadda? Of course! I'm not denying that.
>
> But at the same time, to claim that nothing is new under the Sun, and
> *all* of this had been done decades earlier, is also not the whole
> story. And to call IBM releasing System/360, when they retained
> control of the license, and wasn't accepting any changes back, and
> *darned* well would have sued anyone trying to use that code on
> non-IBM computers into a smoking crater, as "Open Source" can be
> highly misleading, because that is not what most people associate with
> the term "Open Source" today.
>
> And if we take a look at what AT&T Lawyers did with the Unix source
> code, at some point, it most *defintely* was the antithesis of "Open
> Source". Which would lead me to assert that Unix was never really
> released under what today we would call, "Open Source".
>
> Cheers,
>
> - Ted
From tytso at mit.edu Fri Jul 16 12:22:45 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 15 Jul 2021 22:22:45 -0400
Subject: [TUHS] [COFF] 386BSD released
In-Reply-To: <CAP2nic0qY4HrFTUYj0qwr=eney-re6Gn2O=0S23d6jwvOL_O+g@mail.gmail.com>
References: <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com>
<CAC20D2O=ZAD2mMOD+bDZ=-Rk1O8HRguaCCoMSvnQKQ1FE1-aBw@mail.gmail.com>
<YPCNnL4TLkLWqmFa@mit.edu>
<CAP2nic0qY4HrFTUYj0qwr=eney-re6Gn2O=0S23d6jwvOL_O+g@mail.gmail.com>
Message-ID: <YPDtdWs1BDRnMWJn@mit.edu>
On Thu, Jul 15, 2021 at 12:49:07PM -0700, Adam Thornton wrote:
> Although from a somewhat different perspective, it's also why the Linux
> kernel syscall interface is so unruly, right?
>
> You've got your...some number in the small dozens of common syscalls, which
> are already present for the most part in v6 or v7. These are the ones I,
> at least, think of when I think of the Unix manual, section 2.
Actually, a more reason why we have so many system calls is that there
is a strong belief that backwards compatibility is important. So much
so that a Linux, or even Minix binary, from the early 1990's, will
still run on a modern Linux kernel today. So that means we have
separate system calls for wait, wait3, wait4, etc. Support for
openat(2), linkat(2), etc., which got added to Posix by way of
Solaris, need to be implemented as a separate system calls, since we
need to keep the original open(2) system calls. Etc.
> And obviously there's a tradeoff there. Elegance departs, and you've
> probably introduced some security risk because these syscalls are not
> nearly as well-exercised as the common ones, but on the other hand you have
> these large companies paying to work on the kernel, and you have them
> supporting their product on Linux systems because the system can be bent
> into accommodating them more easily, and it will run better there than on
> OSes where they don't get to introduce features that benefit their
> products, which further drives adoption.
In many cases, inside the kernel, system calls like wait(2) and
wait3(2) will be implemeanted in terms of wait4(2), the implementation
of open(2) and openat(2) share a common codepath, and so on. So
although the *number* of system calls may look big, in many cases
there are shared code paths. This is especially true for the system
calls that implement 64-bit support, where the old legacy 32-bit
system calls are just wrappers that call the 64-bit implementations of
those system calls.
There are also some architectures such as Alpha, where some of Linux's
system calls used the Ultrix system call numbering scheme, and other
Ultrix system calls were emulated, so that the Netscape browser, which
was provided in binary form only for Ultrix on Alpha, would run on
Linux Alpha. Being able to run a subset of Ultrix binaries on Linux
Alpha was certainly a hack, but the ability to run a web browser
(there were no open source web browsers at that time) certainly drove
adoption for at least some users.
Was there perhaps some security risk in doing that? Probably,
although people cared a lot less about that in the early 90's. And
these days Linux support for architectures such as Alpha and HP's
PA-RISC are done only by folks who do for fun. :-)
- Ted
P.S. At one point Linux x86 could also run SCO Unix binaries. Which
led to an amusing situation where MIT had purchased a site license for
a proprietary spreadsheet program that ran on SCO Unix, for use by
students who would be running Linux. I worked with someone at that
company (who eventually became one of the founders of Red Hat) and he
gave me a custom application binary that checked for MIT's IP network
address prefix, which was how the site license enforcement was
implemented.
Turns out his development environment was Linux, cross-compiling to
create a SCO Unix binary, because the Linux development environment
was more developer friendly than SCO's. And so here he was, building
a SCO Unix application on a Linux development machine, and then
handing it to me so that our students could run that SCO Unix
application on Linux systems at MIT. The joys of syscall/OS
emulation. :-)
From risner at stdio.com Fri Jul 16 12:33:52 2021
From: risner at stdio.com (risner at stdio.com)
Date: Thu, 15 Jul 2021 22:33:52 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
Message-ID: <5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
I was running 386BSD 0.0 on a 386 40 mhz machine in April 1992 with 32
mb of ram.
There was much instability in the OS with more than 8 gb of ram and I
mailed 32 mb of extra to the Jolitz late summer to the fall.
I never heard about Linux until much later in 1993.
There used to be a post on usenet news annoucing the relase with the
FTP, but the best I could google was this FAQ confirming release in
1992.
https://groups.google.com/g/comp.os.386bsd.announce/c/PGltboD6rq4
I have repetively seen discussion suggesting Linux was available first,
but having directly worked for a university at the time installing
SunOS, AT&T SVR3, and other old OS’s, we welcomed the concept of
switching from AT&T SVR3 on 386 machines to 386BSD. We’d probably have
welcomed Linux if anyone in the department knew about it.
James Risner
On 15 Jul 2021, at 21:35, Dave Horsfall wrote:
> On Wed, 14 Jul 2021, Michael Kjörling wrote:
>
>>> In 1992, 386BSD is released by Lynne and William Jolitz, starting
>>> the open source operating system movement (Linux didn't come along
>>> under later).
>>
>> Are you sure? Wikipedia claims that it happened the other way around;
>> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
>> the 386BSD initial release was 0.0 on 12 March 1992.
>
> Could be; I got that news from one of those daily history sites (I
> don't always trust Wikipedia).
>
>> It seems that work on 386BSD began earlier than work on Linux, but
>> that the initial release of Linux was earlier than the initial
>> release of 386BSD.
>
> That could be the source of the confusion.
>
> -- Dave
From tytso at mit.edu Fri Jul 16 14:25:45 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 16 Jul 2021 00:25:45 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
Message-ID: <YPEKScdjJCE+KMjj@mit.edu>
On Thu, Jul 15, 2021 at 10:33:52PM -0400, risner at stdio.com wrote:
>
> I have repetively seen discussion suggesting Linux was available first, but
> having directly worked for a university at the time installing SunOS, AT&T
> SVR3, and other old OS’s, we welcomed the concept of switching from AT&T
> SVR3 on 386 machines to 386BSD. We’d probably have welcomed Linux if anyone
> in the department knew about it.
To be fair, Linux in 1991 was a very primitive affair; no TCP/IP, no X
Windows. We had C-Kermit, and we had emacs, and we had basic shell
utilities and a compiler. But not much else. So I doubt it would
have been a good replacement for SVR3.
The big difference was that Linus accepted patches, and turned around
new releases *quickly* while Jolitz apparently sat on patches until
the NetBSD and FreeBSD people finally lost patience and released a
fork with their patch sets in 1993. So while Linux in 1992 was
probably behind 386BSD from a feature perspective, its development
velocity was much faster.
I remember a friendly rivalry that I had with Bruce D. Evans in
Australia, who was working on the serial driver for FreeBSD, where we
would exchange tips and techniques for making the serial driver on our
respective OS's more CPU efficient. (The metric was to see who could
most reduce the system overhead of the serial interrupt and tty layers
when running a C-Kermit file transfer over a pair of RS-232 ports
connected via a loopback cable.) It was a lot of fun, and we both
gained a lot from the exchange of ideas, but finally, I came up with
an idea (flip buffers) that really reduced Linux's serial/tty
overhead, but which Bruce couldn't match in FreeBSD, because the
FreeBSD core team thought that clists were handed down from Mount
Olympus by the Gods of BSD, and making that kind of change in the tty
layer was tantamount to heresy. Heh.
- Ted
From bakul at iitbombay.org Fri Jul 16 15:51:11 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 15 Jul 2021 22:51:11 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <YPEKScdjJCE+KMjj@mit.edu>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
Message-ID: <A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
On Jul 15, 2021, at 9:25 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> I remember a friendly rivalry that I had with Bruce D. Evans in
> Australia, who was working on the serial driver for FreeBSD, where we
> would exchange tips and techniques for making the serial driver on our
> respective OS's more CPU efficient. (The metric was to see who could
> most reduce the system overhead of the serial interrupt and tty layers
> when running a C-Kermit file transfer over a pair of RS-232 ports
> connected via a loopback cable.) It was a lot of fun, and we both
> gained a lot from the exchange of ideas, but finally, I came up with
> an idea (flip buffers) that really reduced Linux's serial/tty
> overhead, but which Bruce couldn't match in FreeBSD, because the
> FreeBSD core team thought that clists were handed down from Mount
> Olympus by the Gods of BSD, and making that kind of change in the tty
> layer was tantamount to heresy. Heh.
Dave Yost wrote the serial driver for our 4 port serial card @ Fortune
(1981-82). Later chips like NS16550 had 16 char on chip buffers but we
back then we used a Moto SIO chip that had only one char buffer. IIRC,
he used two tricks. One was "partially evaluated" xmit/recv handlers so
that each port got its own xmit/recv functions, with hand-crafted
instructions (in hex, no less!) just right for a given port and all the
interry t handler . The do was transfer a char from/to the buffer it
(lready knew about. The other was he increased the cblock size from 8 to 128
(what a clist points to). He says he described this design to dmr who said
why not?! With this design Yost's code was able to handle 4 full-duplex
9600 baud streams at full-speed. Not bad for a 5.6Mhz clock machine!
From arnold at skeeve.com Fri Jul 16 17:38:02 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 16 Jul 2021 01:38:02 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CANCZdfpfzrU0SP5HY=0GVrbNaYPT9FP6pt6fsB+SgNDcCJCL0w@mail.gmail.com>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
<CANCZdfpfzrU0SP5HY=0GVrbNaYPT9FP6pt6fsB+SgNDcCJCL0w@mail.gmail.com>
Message-ID: <202107160738.16G7c2gj008875@freefriends.org>
Warner Losh <imp at bsdimp.com> wrote:
> ... But it was good enough for me to write my OS group project running
> under 'ZAYEF' a DecSystem-20 emulator running ...
Fascinating. That's the Hebrew word used for "forgery" or "fakery".
Appropriate for an emulator. Whoever named it both knew Hebrew and
had a sense of humor. :-)
Arnold
From lars at nocrew.org Fri Jul 16 18:05:43 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 16 Jul 2021 08:05:43 +0000
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
(Clem Cole's message of "Thu, 15 Jul 2021 15:27:36 -0400")
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
Message-ID: <7wczriptt4.fsf@junk.nocrew.org>
Clem Cole wrote:
> The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target
> Alan Synder did for his MIT Thesis. It was originally targeted to ITS
> for the PDP-10, but it ran on Tops-20 also. My >>memory<< is he used
> a 7-bit Character, ala SAIL, with 5 chars stored in a word with a bit
> leftover.
On ITS it only ever stored characters as full 36-bit words! So sizeof
char == 1 == sizeof int. This is allowed per the C standard. (Maybe it
was updated somewhere else, I dunno.)
KCC does support 6/7/8/9 bits per character. I think 9 is the default,
or else things like memcpy doesn't work.
> I believe that C compiler Nelson is talking about I believe is
> actually Synder's that Jay either ported from ITS or WAITS.
I think it's a different compiler based on pcc. But I also think code
was moved between various PDP-10 C compilers and libraries, so it's
sometimes hard to tell one from another.
There was also "Sargasso C", but I don't know much about that one.
Maybe its claim to fame is as the original implementation language for
the VT100 test program vttest still in use today.
There was even an attempt to port GCC, and maybe it's still in use today
somewhere around the Seattle area.
From lars at nocrew.org Fri Jul 16 18:50:04 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 16 Jul 2021 08:50:04 +0000
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CMM.0.95.0.1626395141.beebe@gamma.math.utah.edu> (Nelson
H. F. Beebe's message of "Thu, 15 Jul 2021 18:25:41 -0600")
References: <CMM.0.95.0.1626395141.beebe@gamma.math.utah.edu>
Message-ID: <7w35seprr7.fsf@junk.nocrew.org>
> Clem Cole asks:
>> I wonder why Jay did his version? Maybe he wanted more modern C
>> features since the Snyder compiler would been based on a very early C
>> dialect.
I would guess that was one strong reason. Snyder was at Bell Labs
during the very time B transformed into C, and brought that version back
to MIT. If you think K&R C looks outdated and crufty, you may balk at
this "primeval C". (I find it quite charming myself.)
The compiler is also quite slow and the emitted code is not very good.
Nelson H. F. Beebe wrote:
> Besides our PDP-10s, we had several PDP-11s and VAXes that could run
> Unix, so we wanted our software to run on all of those systems
I think the Snyder compiler wouldn't be the best for moving code around
these computers. I can see pcc would be a much better choice.
From lars at nocrew.org Fri Jul 16 18:27:17 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 16 Jul 2021 08:27:17 +0000
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <hnYS2RW60oBvlvcvoqNGbwEJCtOEHmclm_z1B_Od-Kc_vHLWpHYtHvFR5cVoNWdJXxy0h_3P8lFT-gAb2pO8BhHxGUtQ_-QmuFCuc2g9G2k=@jfloren.net>
(John Floren's message of "Fri, 16 Jul 2021 00:02:21 +0000")
References: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
<CA+r1Zhgmf8zbBiztO3Ab1H7Hd7HZQZxqTbTRahtXWfowC=A4qQ@mail.gmail.com>
<hnYS2RW60oBvlvcvoqNGbwEJCtOEHmclm_z1B_Od-Kc_vHLWpHYtHvFR5cVoNWdJXxy0h_3P8lFT-gAb2pO8BhHxGUtQ_-QmuFCuc2g9G2k=@jfloren.net>
Message-ID: <7w8s26pst6.fsf@junk.nocrew.org>
John Floren wrote:
> Speaking of SAIL (and I suppose further derailing an already derailed
> discussion), I've occasionally looked for more information about the
> environment (typically whenever a book or article briefly mentions
> SAIL as a place with lots of custom hardware and software) but come up
> with little. Anyone know of good description of SAIL computer systems?
I'm risking the Wrath of the Moderator here, but I really want to supply
some information. Sorry, this is very far from Unix. But hey, SUDS was
used to design the Stanford SUN Unix workstation.
What do you mean with "SAIL computer systems"? I think upthread SAIL
was referencing the Algol compiler written at the Stanford AI lab. But
SAIL was also an acronym for the entire lab, AND also used as a name for
the main timesharing computer hardware. The hardware was first a PDP-6,
then adding a PDP-10 (KA10), then a KL10. The operating system was
eventually named WAITS, but was also sometimes called SAIL or just
SYSTEM. WAITS was also run on two Foonlies at other sites, and those
could also be called SAIL computer systems in some sense.
I gather you probably mean the AI lab and its computers. The best place
for information is saildart.org, and Bruce Baumgart is working on a tome
called "SAILDART_Prolegomenon". This work in progress is 116 pages.
https://github.com/PDP-10/waits/blob/master/doc/SAILDART_Prolegomenon_2016.pdf
From douglas.mcilroy at dartmouth.edu Fri Jul 16 22:09:59 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Fri, 16 Jul 2021 08:09:59 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CAKH6PiWVc03DtJ0ujAauFZNJn7cuH7-QTCRYi83_KESsZ2AKOQ@mail.gmail.com>
>> -r is weird because it enables backwards reading, but only as
>> limited by count. Better would be a program, say revfile, that simply
>> reads backwards by lines. Then tail p has an elegant implementation:
>> revfile p | head | revfile
> tail -n can be smarter in that it can simply read the last K bytes
> and see if there are n lines. If not, it can read back further.
> revfile would have to read the whole file, which could be a lot
> more than n lines! tail -n < /dev/tty may never terminate but it
> will use a small finite amount of memory.
Revfile would work the same way. When head has seen enough
and terminates, revfile will get SIGPIPE and stop. I agree that,
depending on scheduling and buffer management, revfile might
read more than tail -n, but it wouldn't read the whole of a
humongous file.
Doug
From tytso at mit.edu Fri Jul 16 23:00:58 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 16 Jul 2021 09:00:58 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
Message-ID: <YPGDCoO4uB1ehBxi@mit.edu>
On Thu, Jul 15, 2021 at 10:51:11PM -0700, Bakul Shah wrote:
>
> Dave Yost wrote the serial driver for our 4 port serial card @ Fortune
> (1981-82). Later chips like NS16550 had 16 char on chip buffers but we
> back then we used a Moto SIO chip that had only one char buffer. IIRC,
> he used two tricks. One was "partially evaluated" xmit/recv handlers so
> that each port got its own xmit/recv functions, with hand-crafted
> instructions (in hex, no less!) just right for a given port and all the
> interry t handler . The do was transfer a char from/to the buffer it
> (lready knew about. The other was he increased the cblock size from 8 to 128
> (what a clist points to). He says he described this design to dmr who said
> why not?! With this design Yost's code was able to handle 4 full-duplex
> 9600 baud streams at full-speed. Not bad for a 5.6Mhz clock machine!
The trick that I used was two have two "flip buffers" which were
dedicated for each serial port. One buffer would be filled by the
interrupt handler, while the other would be buffer would be processed
by the bottom half (read: software interrupt) handler. When the
bottom half handler had emptied one buffer, it would check to see if
there were any characters in the other buffer, and if so, flip the two
and process the characters in that buffer. Exclusion was handled by a
combination of disabling serial interrupts and using a spinlock (which
was held just long enough to flip the pointers to the two flip
buffers).
With this scheme I could handle multiple pairs of 115200 baud streams
at full rates before the 40 MHz CPU was saturated. No memory
allocation is required on the hot paths, and the amount of processing
that is done in the hardware interrupt context is the absolute
minimum.
I also added a bit test against 32-byte bitarray to determine whether
a character could be handled via the fast path or require special
handling (in case it was a ^C, ^U, ^S, etc.) but that was important
only for cooked mode; it wasn't needed for raw mode. I suspect this
hack would become less or even not helpful as Intel processors became
more Spectre- and Meltdown-susceptible, but for the 386, it was a win. :-)
- Ted
From lm at mcvoy.com Fri Jul 16 23:56:39 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 16 Jul 2021 06:56:39 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <YPGDCoO4uB1ehBxi@mit.edu>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu>
Message-ID: <20210716135639.GI12733@mcvoy.com>
On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
> The trick that I used was two have two "flip buffers" which were
> dedicated for each serial port. One buffer would be filled by the
> interrupt handler, while the other would be buffer would be processed
> by the bottom half (read: software interrupt) handler. When the
> bottom half handler had emptied one buffer, it would check to see if
> there were any characters in the other buffer, and if so, flip the two
> and process the characters in that buffer.
I'm pretty sure SGI used a similar approach for networking packets.
From beebe at math.utah.edu Sat Jul 17 00:17:18 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 16 Jul 2021 08:17:18 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiW58PDPb5HRi12aKE+mT+O8AjETr9R51Db6U3KcEp_KkA@mail.gmail.com>
Message-ID: <CMM.0.95.0.1626445038.beebe@gamma.math.utah.edu>
Doug McIlroy asks about the Rosetta Stone table relating TOPS-20
commands to Unix command in my ``Unix for TOPS-20 Users'' document:
>> I was puzzled, though, by the Unix command "leave", which is
>> not in the manuals I edited, nor is it in Linux. What does
>> (or did) it do?
I reread that 1987 document this morning, and found a few small
mistakes, but on the whole, I still agree with what I wrote 34 years
ago, and I'm pleased that almost everything there about Unix still
applies today.
I confess that I had forgotten about the TOPS-20 ALERT command and its
Unix equivalent, leave. As Doug noted, leave is not in Linux systems,
but it still exists in the BSD world, in DragonFlyBSD, FreeBSD,
NetBSD, OpenBSD, and their many derivatives. From a bleeding-edge
FreeBSD 14 system, I find
% man leave
LEAVE(1) FreeBSD General Commands Manual LEAVE(1)
NAME
leave – remind you when you have to leave
SYNOPSIS
leave [[+]hhmm]
DESCRIPTION
The leave utility waits until the specified time, then reminds you that
you have to leave. You are reminded 5 minutes and 1 minute before the
actual time, at the time, and every minute thereafter. When you log off,
leave exits just before it would have printed the next message.
...
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From clemc at ccc.com Sat Jul 17 00:19:15 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Jul 2021 10:19:15 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <7wczriptt4.fsf@junk.nocrew.org>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
<7wczriptt4.fsf@junk.nocrew.org>
Message-ID: <CAC20D2McU80+T+OzTNTQcFZ+_siXr9S-5SXtMd_QPcskhX6v9w@mail.gmail.com>
On Fri, Jul 16, 2021 at 4:05 AM Lars Brinkhoff <lars at nocrew.org> wrote:
> Clem Cole wrote:
> > The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target
> > Alan Synder did for his MIT Thesis. It was originally targeted to ITS
> > for the PDP-10, but it ran on Tops-20 also. My >>memory<< is he used
> > a 7-bit Character, ala SAIL, with 5 chars stored in a word with a bit
> > leftover.
>
> On ITS it only ever stored characters as full 36-bit words! So sizeof
> char == 1 == sizeof int. This is allowed per the C standard. (Maybe it
> was updated somewhere else, I dunno.)
>
Ah - that makes sense. I never programmed the Honeywell in anything but
Dartmouth BASIC (mostly) and any early FORTRAN (very little) and the whole
idea of storage size was somewhat oblivious to me at the point as I was a
youngster when I did that. Any idea did the Honeywell treat chars as
36-bit entities also? Steve, maybe you remember?
Also, please remember that the standard does not yet exist for a good 10
years ;-) At this point, the 'standard' was the Ritchie Compiler for the
PDP-11.
At the time, we to run wanted the program on all of the UNIX/v6 systems and
CMU's version of TOPS-10 and later TOPS-20 as an interchange format. Thus,
I have memories of having to use the "c =& 0177" idiom in the
backup/dumper program in a number of places [remember tar does not yet
exist, and tp/stp was a binary program]. Beyond that, I don't remember
much about the running C on the 10s. I think we started trying to move
Harvard's stp to TOPS-10, but ran into an issue [maybe the directory size]
and stopped. Since backup (dumper) was heavily used, we were trying to get
IUS and SUS to be able to be backed up and handled the same way the
operators did the backup for the 10's. In my own case, I had learned SAIL
(and BLISS) on the 10s before C on the PDP-11, plus this was an early C
program for me, maybe my second or third non-trivial one after I worked
with Ted on fsck, so coming from the PDP-10/SAIL/BLISS *et al *world, 7-bit
chars certainly seemed normal. I also remember having an early 'ah-ha'
moment, when the difference between a 7-bit and 8-bit char started to
become important.
Clem
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/95a49b3a/attachment.htm>
From bakul at iitbombay.org Sat Jul 17 00:32:05 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 16 Jul 2021 07:32:05 -0700
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAKH6PiWVc03DtJ0ujAauFZNJn7cuH7-QTCRYi83_KESsZ2AKOQ@mail.gmail.com>
References: <CAKH6PiWVc03DtJ0ujAauFZNJn7cuH7-QTCRYi83_KESsZ2AKOQ@mail.gmail.com>
Message-ID: <D7429F77-70BB-4675-A11E-5FBE540C94A5@iitbombay.org>
On Jul 16, 2021, at 5:09 AM, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> wrote:
>
>>> -r is weird because it enables backwards reading, but only as
>>> limited by count. Better would be a program, say revfile, that simply
>>> reads backwards by lines. Then tail p has an elegant implementation:
>>> revfile p | head | revfile
>
>> tail -n can be smarter in that it can simply read the last K bytes
>> and see if there are n lines. If not, it can read back further.
>> revfile would have to read the whole file, which could be a lot
>> more than n lines! tail -n < /dev/tty may never terminate but it
>> will use a small finite amount of memory.
>
> Revfile would work the same way. When head has seen enough
> and terminates, revfile will get SIGPIPE and stop. I agree that,
> depending on scheduling and buffer management, revfile might
> read more than tail -n, but it wouldn't read the whole of a
> humongous file.
Good point! But when the input is from a device it would have to
buffer up everything since it doesn't know how much head would
want. No big deal of course but I was just pointing out that tail
can "behave better" in all cases!
-- Bakul
From clemc at ccc.com Sat Jul 17 00:40:56 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Jul 2021 10:40:56 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <20210716135639.GI12733@mcvoy.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
Message-ID: <CAC20D2O=LuFMFdShXidPyJDTZvfbdJb9DN5ouXTBA-ScFtwNJA@mail.gmail.com>
On Fri, Jul 16, 2021 at 9:57 AM Larry McVoy <lm at mcvoy.com> wrote:
> I'm pretty sure SGI used a similar approach for networking packets.
>
Yeah, it was pretty standard for networking interfaces. I think I first
saw it I'm the MIT Chaos driver maybe? In many ways, Gurwitz's whole mbuf
memory scheme for the ethernet controllers and the whole IP stack that
lives on in BSD is based on the idea. Rob used a number of different size
buffers, not just the two, but the idea is the same, never copy anything if
we can avoid it. Play pointer games in the top, bottom, and middle parts
of the driver/stack.
A huge difference, as Ted I'm sure knows, is that you tended to have many
more serial lines than network interfaces. I suspect Rob's scheme
would have sucked trying to support traditional single-byte serial
interfaces or really just use too much memory to be practical.
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/6c275eb6/attachment.htm>
From john at jfloren.net Sat Jul 17 01:28:22 2021
From: john at jfloren.net (John Floren)
Date: Fri, 16 Jul 2021 15:28:22 +0000
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <7w8s26pst6.fsf@junk.nocrew.org>
References: <CMM.0.95.0.1626387969.beebe@gamma.math.utah.edu>
<CA+r1Zhgmf8zbBiztO3Ab1H7Hd7HZQZxqTbTRahtXWfowC=A4qQ@mail.gmail.com>
<hnYS2RW60oBvlvcvoqNGbwEJCtOEHmclm_z1B_Od-Kc_vHLWpHYtHvFR5cVoNWdJXxy0h_3P8lFT-gAb2pO8BhHxGUtQ_-QmuFCuc2g9G2k=@jfloren.net>
<7w8s26pst6.fsf@junk.nocrew.org>
Message-ID: <sJcciGiSe1mW1C4dAjtJVprKlulsY_RuI4ysfNkXOV7-8tlkBy3v_TA9PNdLrSlcgc3H5_cdDcsqOHjusPrl9ouKrEovkZ9eb5O2w4g2uRM=@jfloren.net>
On Friday, July 16th, 2021 at 1:27 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
> John Floren wrote:
>
> > Speaking of SAIL (and I suppose further derailing an already derailed
> >
> > discussion), I've occasionally looked for more information about the
> >
> > environment (typically whenever a book or article briefly mentions
> >
> > SAIL as a place with lots of custom hardware and software) but come up
> >
> > with little. Anyone know of good description of SAIL computer systems?
>
> I'm risking the Wrath of the Moderator here, but I really want to supply
>
> some information. Sorry, this is very far from Unix. But hey, SUDS was
>
> used to design the Stanford SUN Unix workstation.
>
> What do you mean with "SAIL computer systems"? I think upthread SAIL
>
> was referencing the Algol compiler written at the Stanford AI lab. But
>
> SAIL was also an acronym for the entire lab, AND also used as a name for
>
> the main timesharing computer hardware. The hardware was first a PDP-6,
>
> then adding a PDP-10 (KA10), then a KL10. The operating system was
>
> eventually named WAITS, but was also sometimes called SAIL or just
>
> SYSTEM. WAITS was also run on two Foonlies at other sites, and those
>
> could also be called SAIL computer systems in some sense.
>
> I gather you probably mean the AI lab and its computers. The best place
>
> for information is saildart.org, and Bruce Baumgart is working on a tome
>
> called "SAILDART_Prolegomenon". This work in progress is 116 pages.
>
> https://github.com/PDP-10/waits/blob/master/doc/SAILDART_Prolegomenon_2016.pdf
Yes, WAITS is what I was thinking of. As I mentioned in my previous mail,
it feels like the SAIL timesharing systems get mentioned briefly in
a lot of accounts of historical computing, sometimes with mention that
they had some sort of (relatively) advanced video terminals, but no
in-depth descriptions of the actual hardware/software environment.
I will take a look at saildart.org and the Prolegomenon, thanks!
John
From tytso at mit.edu Sat Jul 17 01:44:26 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 16 Jul 2021 11:44:26 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CAC20D2O=LuFMFdShXidPyJDTZvfbdJb9DN5ouXTBA-ScFtwNJA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAC20D2O=LuFMFdShXidPyJDTZvfbdJb9DN5ouXTBA-ScFtwNJA@mail.gmail.com>
Message-ID: <YPGpWh60wFePL1en@mit.edu>
On Fri, Jul 16, 2021 at 10:40:56AM -0400, Clem Cole wrote:
>
> A huge difference, as Ted I'm sure knows, is that you tended to have many
> more serial lines than network interfaces. I suspect Rob's scheme
> would have sucked trying to support traditional single-byte serial
> interfaces or really just use too much memory to be practical.
Network interfaces tend to be much faster than serial lines; at least
an order of magnitude. And with network interfaces you care about the
packet boundaries, and you want to process each packet separately. So
that makes things a lot harder than with serial interfaces.
With serial ports, 8k per serial port is plenty (2 x 2k flip buffers,
plus a 4k tty buffer between the mid-layer and userspace) for the
receive path. On the PDP-11, memory was much more constrained, so the
clist with each cblock storing 6 characters at a time in a linked list
was probably necessary. But even in the early days of the 386, you
could afford to make a different memory/performance tradeoff.
- Ted
From imp at bsdimp.com Sat Jul 17 02:09:17 2021
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 16 Jul 2021 10:09:17 -0600
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <202107160738.16G7c2gj008875@freefriends.org>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
<CANCZdfpfzrU0SP5HY=0GVrbNaYPT9FP6pt6fsB+SgNDcCJCL0w@mail.gmail.com>
<202107160738.16G7c2gj008875@freefriends.org>
Message-ID: <CANCZdfoE5Tf__6jpG4qMsLrpzAF-Fw6KwH9FaQVDG1L6KC2fNw@mail.gmail.com>
On Fri, Jul 16, 2021, 1:38 AM <arnold at skeeve.com> wrote:
> Warner Losh <imp at bsdimp.com> wrote:
>
> > ... But it was good enough for me to write my OS group project running
> > under 'ZAYEF' a DecSystem-20 emulator running ...
>
> Fascinating. That's the Hebrew word used for "forgery" or "fakery".
> Appropriate for an emulator. Whoever named it both knew Hebrew and
> had a sense of humor. :-)
>
It was billed as not really a DECsystem 20, but a really good fake. Clearly
a nod to that meaning.
Warner
Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/a46a0939/attachment.htm>
From bakul at iitbombay.org Sat Jul 17 02:11:16 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 16 Jul 2021 09:11:16 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <20210716135639.GI12733@mcvoy.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
Message-ID: <7DC2359B-93C7-4329-AF61-6078CB4B80EB@iitbombay.org>
On Jul 16, 2021, at 6:56 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
>> The trick that I used was two have two "flip buffers" which were
>> dedicated for each serial port. One buffer would be filled by the
>> interrupt handler, while the other would be buffer would be processed
>> by the bottom half (read: software interrupt) handler. When the
>> bottom half handler had emptied one buffer, it would check to see if
>> there were any characters in the other buffer, and if so, flip the two
>> and process the characters in that buffer.
>
> I'm pretty sure SGI used a similar approach for networking packets.
This is somewhat h/w dependent. Ideally you want the h/w to
do some buffering for streaming at full speed so that you
don't need to take a per char or per packet interrupt. Hence
NS16550 which used a 16 char FIFO. AMD LANCE used a ring of
2^N buffer descriptors. Intel 82586 used a linked list -
don't recall if you had to make it a circular buffer. The
early 3COM controller didn't buffer more than a packet and
you had to copy it. As a contractor I did a couple of network
drivers for 3rd party hardware for SGI in late '80s & early
'90s. I don't recall any details now but in both cases the
h/w did buffer up a bunch. Once things are handed to s/w, you
have a lot more flexibility. Though I never liked the idea of
splitting a packet up in multiple mbufs!
From tytso at mit.edu Sat Jul 17 02:13:02 2021
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 16 Jul 2021 12:13:02 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CMM.0.95.0.1626445038.beebe@gamma.math.utah.edu>
References: <CAKH6PiW58PDPb5HRi12aKE+mT+O8AjETr9R51Db6U3KcEp_KkA@mail.gmail.com>
<CMM.0.95.0.1626445038.beebe@gamma.math.utah.edu>
Message-ID: <YPGwDpG/bJu0Lr4D@mit.edu>
On Fri, Jul 16, 2021 at 08:17:18AM -0600, Nelson H. F. Beebe wrote:
>
> I confess that I had forgotten about the TOPS-20 ALERT command and its
> Unix equivalent, leave. As Doug noted, leave is not in Linux systems,
> but it still exists in the BSD world, in DragonFlyBSD, FreeBSD,
> NetBSD, OpenBSD, and their many derivatives.
The leave program isn't installed by default, but it is available in
many if not most distributions (I checked Debian, Fedora and Ubuntu).
You just have to install it ("apt-get install leave" on Debian and
Ubuntu). The upstream sources at least for the Debian package is from
NetBSD.
- Ted
From bakul at iitbombay.org Sat Jul 17 03:03:09 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 16 Jul 2021 10:03:09 -0700
Subject: [TUHS] Fwd: 386BSD released
References: <B77CD16E-CC26-410F-BBE7-8F206B27620F@yost.com>
Message-ID: <99253357-AF74-422B-A206-82EF5D567298@iitbombay.org>
More from Yost below.
My purpose in relating this was to point out that the original unix
implementation choices were mostly fine; they just had to be tweaked a
bit. Clearly an independent implementation such as in Linux would veer
off in a different direction, done in a different era and with different prior
experience. I was a bit surprised that Bruce didn't make this same
tweak to cblock size but no way of knowing his reasons now.
> Begin forwarded message:
>
> From: Dave Yost
> Subject: Re: [TUHS] 386BSD released
> Date: July 16, 2021 at 9:21:53 AM PDT
> To: Bakul Shah
>
> Plz forward this
> thanks
>
> This was in early 1983 or late 1982.
>
> We got the serial driver to go 19200 out and 9600 in.
>
> I did 2 things in the Fortune Systems 68k serial driver:
> • hand-coded asm pseudo-DMA, suggested by Robert P Warnock III
> • cblock size 128 bytes instead of 8, count ’em, 8.
>
> From Lyons,
> https://cs3210.cc.gatech.edu/r/unix6.pdf <https://cs3210.cc.gatech.edu/r/unix6.pdf>
> the unix v6 serial driver used a clist of cblocks, like this:
>
>
> The pseudo-DMA interrupt handler was a function made up of a few hand-coded 68k instructions, entered into C code as hex data. That code transferred one byte into or out of a cblock, and at the end of the cblock it grabbed the next cblock from a queue and rang the “doorbell” hardware interrupt, which caused a “software interrupt” at lower priority for further processing. Rob put the doorbell into the architecture with a couple of gates on the board because he was well aware of this software interrupt trick, which was already used in bsd. For some reason I didn’t look at the bsd code, probably because Rob’s explanation was lucid and sufficient.
>
> I once had occasion to mention this, and specifically the relaxing of the draconian 8 byte cblock size, to Dennis Ritchie. He said, sure, why not, the 8 byte cblock size was just a neglected holdover from early days.
>
> This approach was just an interrupt version of what I had proposed to Rick Kiessig as a first project at Fortune Systems: to get a 30x speed up when writing to the Fortune Systems memory-mapped character display hardware. I had done the same thing a few years earlier in Z80 in C code in a serial CRT terminal. It’s simple and obvious: make the inner loop do as little as possible. The most primitive operation needs to be a block operation, not a byte-at-a-time operation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/b571525c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Messages Image(2650669068).png
Type: image/png
Size: 21772 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/b571525c/attachment.png>
From beebe at math.utah.edu Sat Jul 17 03:30:06 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 16 Jul 2021 11:30:06 -0600
Subject: [TUHS] 386BSD released
Message-ID: <CMM.0.95.0.1626456606.beebe@gamma.math.utah.edu>
List members under this subject line have contributed reminders of
older efforts in the sharing of software, predating Linux, the Free
Software Foundation, the GNU Project, and the BSD Unix family.
Starting at the string "begin historical remarks" in the preamble
comments of
http://www.math.utah.edu/pub/tex/bib/gnu.bib
http://www.math.utah.edu/pub/tex/bib/gnu.html
I record things that I've encountered over decades in computing, going
back to Charles Babbage in 1830 and Joseph Henry in 1849, jumping to
IBM SHARE in 1955, and onward.
As usual in our bibliography archives, *.html files look similar on
screen to *.bib files, but have live hyperlinks.
Comments, corrections, improvements, etc. on that history are welcome.
Babbage's own works are covered at
http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.bib
http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.html
and those of his collaborator at
http://www.math.utah.edu/pub/bibnet/authors/l/lovelace-ada-augusta.bib
http://www.math.utah.edu/pub/bibnet/authors/l/lovelace-ada-augusta.html
-------------------------------------------------------------------------------
- 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 at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From kevin.bowling at kev009.com Sat Jul 17 05:07:52 2021
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Fri, 16 Jul 2021 12:07:52 -0700
Subject: [TUHS] 386BSD released
In-Reply-To: <20210716135639.GI12733@mcvoy.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
Message-ID: <CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
On Fri, Jul 16, 2021 at 6:57 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
> > The trick that I used was two have two "flip buffers" which were
> > dedicated for each serial port. One buffer would be filled by the
> > interrupt handler, while the other would be buffer would be processed
> > by the bottom half (read: software interrupt) handler. When the
> > bottom half handler had emptied one buffer, it would check to see if
> > there were any characters in the other buffer, and if so, flip the two
> > and process the characters in that buffer.
>
> I'm pretty sure SGI used a similar approach for networking packets.
Yup was just going to say this is standard in the modern BSD network
drivers, looks like Clem says it's older. There are recent
optimizations to help the CPU with prefetch, and some ideas around
vectors of mbufs. What's remarkable is the mbuf design scales to
200gbps in practice, it must feel great to design something like that
so long ago :)
From clemc at ccc.com Sat Jul 17 06:17:31 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Jul 2021 16:17:31 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
Message-ID: <CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
On Fri, Jul 16, 2021 at 3:08 PM Kevin Bowling <kevin.bowling at kev009.com>
wrote:
> Yup was just going to say this is standard in the modern BSD network
> drivers, looks like Clem says it's older.
Absolutely -- I believe it was Rob's undergrad project at Brown that he
brought to BBN.
The first use, if I saw, was the 'portable IP/TCP' stack BBN did for
HP/3000 and a couple of other systems. That code seems to have been lost.
I have asked about it on the Internet history mailing list. I had a copy
of it one time, but sadly I don't think I still do. IIRC The original
PDP-11 IP implementation which ran on a couple of dedicated systems,
whose names/function I frankly do not remember) was also based on a version
of this code. I think it ran something like RT-11 or DOS-11 and then
started the IP code -- basically RTR style today. Later it morphed into
Rob's Vax BSD 4.1 specific stack, which we ran at UCB on a couple of the
systems using 3M Xerox board. This latest until 4.1A and Joy's rewrite and
I want to say we switched in Interlan 10M boards then. We have a couple of
the 3Com boards, but because of the lack of buffering, they were a bear to
use and stopped as soon as we got the Interlan one.
Anyway, all of these IP/TCP stacks used Rob's mbuf code. Which was a
blessing and a curse. By writing his own, he avoids huge
changes/integration into the memory system, but it also helped to make BSD
such a mess under the covers because there were so many private memory
managers between the network, the I/O systems etc... As discussed
previously on the TUHS list, the one thing Risner really did well had a
uniform memory design. Later BSD's moved to Mach and tried to clean this
up a little, but the network code was by then so screwed into Rob's mbuf
scheme, it stayed around a long time. Werner -- what is the state of this
these days in FreeBSD is it still there?
> There are recent optimizations to help the CPU with prefetch, and some
> ideas around vectors of mbufs. What's remarkable is the mbuf design
> scales to
> 200gbps in practice, it must feel great to design something like that so
> long ago :)
>
Well, ask Rob :-) I've lost track of him since Stellar, and I think he I
heard he left high tech but frankly don't know.
Clem
бђ§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/74a0e917/attachment.htm>
From rich.salz at gmail.com Sat Jul 17 06:24:10 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Fri, 16 Jul 2021 16:24:10 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
Message-ID: <CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
Anyone remember the old mtXinu calendar with fake ads?I only remember one
page, "oh no Spot(?) spilled the mbufs, Dad's favorite cereal."
On Fri, Jul 16, 2021, 4:19 PM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Fri, Jul 16, 2021 at 3:08 PM Kevin Bowling <kevin.bowling at kev009.com>
> wrote:
>
>> Yup was just going to say this is standard in the modern BSD network
>> drivers, looks like Clem says it's older.
>
> Absolutely -- I believe it was Rob's undergrad project at Brown that he
> brought to BBN.
>
> The first use, if I saw, was the 'portable IP/TCP' stack BBN did for
> HP/3000 and a couple of other systems. That code seems to have been lost.
> I have asked about it on the Internet history mailing list. I had a copy
> of it one time, but sadly I don't think I still do. IIRC The original
> PDP-11 IP implementation which ran on a couple of dedicated systems,
> whose names/function I frankly do not remember) was also based on a version
> of this code. I think it ran something like RT-11 or DOS-11 and then
> started the IP code -- basically RTR style today. Later it morphed into
> Rob's Vax BSD 4.1 specific stack, which we ran at UCB on a couple of the
> systems using 3M Xerox board. This latest until 4.1A and Joy's rewrite and
> I want to say we switched in Interlan 10M boards then. We have a couple of
> the 3Com boards, but because of the lack of buffering, they were a bear to
> use and stopped as soon as we got the Interlan one.
>
>
> Anyway, all of these IP/TCP stacks used Rob's mbuf code. Which was a
> blessing and a curse. By writing his own, he avoids huge
> changes/integration into the memory system, but it also helped to make BSD
> such a mess under the covers because there were so many private memory
> managers between the network, the I/O systems etc... As discussed
> previously on the TUHS list, the one thing Risner really did well had a
> uniform memory design. Later BSD's moved to Mach and tried to clean this
> up a little, but the network code was by then so screwed into Rob's mbuf
> scheme, it stayed around a long time. Werner -- what is the state of this
> these days in FreeBSD is it still there?
>
>
>
>
>> There are recent optimizations to help the CPU with prefetch, and some
>> ideas around vectors of mbufs. What's remarkable is the mbuf design
>> scales to
>> 200gbps in practice, it must feel great to design something like that so
>> long ago :)
>>
> Well, ask Rob :-) I've lost track of him since Stellar, and I think he I
> heard he left high tech but frankly don't know.
>
> Clem
> бђ§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/9a300c75/attachment.htm>
From dave at horsfall.org Sat Jul 17 07:22:38 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Jul 2021 07:22:38 +1000 (EST)
Subject: [TUHS] 386BSD released
In-Reply-To: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2107170718470.41085@aneurin.horsfall.org>
On Wed, 14 Jul 2021, Dave Horsfall wrote:
> In 1992, 386BSD is released by Lynne and William Jolitz, starting the
> open source operating system movement (Linux didn't come along under
> later).
Seems to have caused a "discussion", so...
https://www.onthisday.com/day/july/14
``1992 386BSD is released by Lynne Jolitz and William Jolitz,
starting the open source operating system revolution. Linus Torvalds
release "Linux" soon afterwards''
If anything thinks this is incorrect then feel free to submit a correction;
I have more important things to do right now.
-- Dave
From charles.unix.pro at gmail.com Sat Jul 17 10:34:17 2021
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Fri, 16 Jul 2021 17:34:17 -0700
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
In-Reply-To: <CAC20D2McU80+T+OzTNTQcFZ+_siXr9S-5SXtMd_QPcskhX6v9w@mail.gmail.com>
References: <1626375671.1426.for-standards-violators@oclsc.org>
<CAC20D2NPMovqkKLahRKopt5y4mPQrmpNi__RrjtRw6cowmwszQ@mail.gmail.com>
<7wczriptt4.fsf@junk.nocrew.org>
<CAC20D2McU80+T+OzTNTQcFZ+_siXr9S-5SXtMd_QPcskhX6v9w@mail.gmail.com>
Message-ID: <CANV78LQsCrPDGW6-BQd1Q=ViDEbDdDBK9Frydso8tc6YE5r8Xg@mail.gmail.com>
On Fri, Jul 16, 2021 at 7:20 AM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Fri, Jul 16, 2021 at 4:05 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>
>> Clem Cole wrote:
>> > The 'second' C compiler was a PDP-10 and Honeywell (36-bit) target
>> > Alan Synder did for his MIT Thesis. It was originally targeted to ITS
>> > for the PDP-10, but it ran on Tops-20 also. My >>memory<< is he used
>> > a 7-bit Character, ala SAIL, with 5 chars stored in a word with a bit
>> > leftover.
>>
>> On ITS it only ever stored characters as full 36-bit words! So sizeof
>> char == 1 == sizeof int. This is allowed per the C standard. (Maybe it
>> was updated somewhere else, I dunno.)
>>
>
> Ah - that makes sense. I never programmed the Honeywell in anything but
> Dartmouth BASIC (mostly) and any early FORTRAN (very little) and the whole
> idea of storage size was somewhat oblivious to me at the point as I was a
> youngster when I did that. Any idea did the Honeywell treat chars as
> 36-bit entities also? Steve, maybe you remember?
>
>
The Honeywell 6000 machines ran GCOS; the system standard was six six-bit
characters per word.
The Honeywell 6100 machines ran Multics; the system standard was four
nine-bit characters per word.
For Multics C, sizeof (*) != sizeof (int) and NULL != 0, so a lot of
"portable" C code wasn't.
-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210716/0df0ddf2/attachment.htm>
From arnold at skeeve.com Sun Jul 18 23:13:28 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 18 Jul 2021 07:13:28 -0600
Subject: [TUHS] 386BSD released
In-Reply-To: <CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
Message-ID: <202107181313.16IDDSn8029320@freefriends.org>
Richard Salz <rich.salz at gmail.com> wrote:
> Anyone remember the old mtXinu calendar with fake ads?I only remember one
> page, "oh no Spot(?) spilled the mbufs, Dad's favorite cereal."
I think it was "my dog Biff..." Wasn't that Heidi Stetner's dog or
something? Apparently he used to bark whenever the mailman showed up,
inspiring the BSD biff(1) command.
I had that calendar, and kept it for many years. There was a lovely
picture of a shepherd boy trying to herd cats. I don't remember the
rest, other than that they were amusing. I think I finally tossed
it though.
Arnold
From rich.salz at gmail.com Sun Jul 18 23:23:04 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Sun, 18 Jul 2021 09:23:04 -0400
Subject: [TUHS] 386BSD released
In-Reply-To: <202107181313.16IDDSn8029320@freefriends.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
Message-ID: <CAFH29tozhv3jcAZ6f-RLkRi1j2PW7JUdFvfmYFgHCZb_4TQ-QQ@mail.gmail.com>
> I think it was "my dog Biff..." Wasn't that Heidi Stetner's dog or
> something? Apparently he used to bark whenever the mailman showed up,
> inspiring the BSD biff(1) command.
>
Yes, that's the dog's name, and that I also now remember hearing that
story!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210718/61a62343/attachment.htm>
From aek at bitsavers.org Sun Jul 18 23:43:38 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 18 Jul 2021 06:43:38 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <202107181313.16IDDSn8029320@freefriends.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
Message-ID: <aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
> Richard Salz <rich.salz at gmail.com> wrote:
>
>> Anyone remember the old mtXinu calendar with fake ads?
I just turned up a copy, it's from 1993
I'll have it on bitsavers under pdf/mtXinu later today
From aek at bitsavers.org Sun Jul 18 23:51:10 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 18 Jul 2021 06:51:10 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
Message-ID: <f0579fca-fe17-dc48-8121-7ae71a9622a8@bitsavers.org>
On 7/18/21 6:43 AM, Al Kossow wrote:
> On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
>> Richard Salz <rich.salz at gmail.com> wrote:
>>
>>> Anyone remember the old mtXinu calendar with fake ads?
>
> I just turned up a copy, it's from 1993
> I'll have it on bitsavers under pdf/mtXinu later today
>
Well this is a weird coincidence, 2021 matches the 1993 calendar
so a retro calendar for this year could be photoshopped together
The year doesn't even appear that many times on the original.
From aek at bitsavers.org Mon Jul 19 02:44:53 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 18 Jul 2021 09:44:53 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
Message-ID: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
On 7/18/21 6:43 AM, Al Kossow wrote:
> On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
>> Richard Salz <rich.salz at gmail.com> wrote:
>>
>>> Anyone remember the old mtXinu calendar with fake ads?
>
> I just turned up a copy, it's from 1993
> I'll have it on bitsavers under pdf/mtXinu later today
>
> Calendars cycle every 28 years
the coincidence was asking about it on exactly that year
it's up now under http://bitsavers.org/pdf/mtXinu
is supposed to be pronouced zee new or zeye new ?
From cowan at ccil.org Mon Jul 19 03:38:08 2021
From: cowan at ccil.org (John Cowan)
Date: Sun, 18 Jul 2021 13:38:08 -0400
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
<a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
Message-ID: <CAD2gp_S-xfQYg9cNTpBaEnazk89ktSW8pdeBfaRCObSSaN4riQ@mail.gmail.com>
On Sun, Jul 18, 2021 at 12:45 PM Al Kossow <aek at bitsavers.org> wrote:
is supposed to be pronouced zee new or zeye new ?
>
Not that I know, but I have always said "zeenew" for the (unrelated)
embedded OS by Comer and "mount zeenew" for the software company.
Armand Hammer, the American businessman and unofficial commercial attache
to the Soviet Union, had nothing to do with Arm and Hammer baking soda,
though he did buy stock in the manufacturer after being asked about it one
too many times. Armand was probably named after the "arm and hammer" logo
of the Socialist Labor Party, an anti-Marxist group who favored the
development of revolutionary industrial labor unions, to which his
father belonged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210718/2a312d48/attachment.htm>
From bakul at iitbombay.org Mon Jul 19 04:35:55 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Sun, 18 Jul 2021 11:35:55 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
References: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
Message-ID: <DDC768AA-D7CE-4CEA-92AD-D2D2AD7E1B3D@iitbombay.org>
On Jul 18, 2021, at 9:45 AM, Al Kossow <aek at bitsavers.org> wrote:
>
> is supposed to be pronouced zee new or zeye new ?
Don't know how it is supposed to be pronounced but I have
always pronounced it as 'zai-noo, with xi the way the greek
letter Оѕ is pronounced in English.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210718/f2d6a2de/attachment.htm>
From arnold at skeeve.com Mon Jul 19 05:00:32 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 18 Jul 2021 13:00:32 -0600
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
<a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
Message-ID: <202107181900.16IJ0Wwn007583@freefriends.org>
Hi.
Al Kossow <aek at bitsavers.org> wrote:
> On 7/18/21 6:43 AM, Al Kossow wrote:
> > On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
> >> Richard Salz <rich.salz at gmail.com> wrote:
> >>
> >>> Anyone remember the old mtXinu calendar with fake ads?
> >
> > I just turned up a copy, it's from 1993
> > I'll have it on bitsavers under pdf/mtXinu later today
> >
>
> > Calendars cycle every 28 years
>
> the coincidence was asking about it on exactly that year
>
> it's up now under http://bitsavers.org/pdf/mtXinu
Thanks! It's not the calendar Rich and I remember, but it's
still worth having. :-)
> is supposed to be pronouced zee new or zeye new ?
I always pronounced it zee new.
Arnold
From douglas.mcilroy at dartmouth.edu Mon Jul 19 06:07:53 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Sun, 18 Jul 2021 16:07:53 -0400
Subject: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Message-ID: <CAKH6PiVmLk0urDrMJW79gjQ_fk-c-JopiN41naRxcnXma7Q1zw@mail.gmail.com>
> For Multics C, ... NULL != 0
I know what you mean, but the formulation is paradoxical,
as the expression NULL==0 is always true in C :)
Doug
From norman at oclsc.org Mon Jul 19 06:44:11 2021
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 18 Jul 2021 16:44:11 -0400
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
Message-ID: <1626641054.6580.for-standards-violators@oclsc.org>
Unlike most here, I always pronounced Mt Xinu with an
eye, not an eee. I don't know where I got that, though.
I did know Ed Gould via USENIX and DECUS, but that doesn't
make my pronunciation correct.
As an aside, anyone know where Ed is these days or how he's
doing? I last saw him at a USENIX conference, probably in
San Jose in 2013 but I'm not sure. He showed up just for the
reception; he'd retired, and had cut away most of his famous
beard because he was spending a lot of time sailing and it
got in the way.
Norman Wilson
Toronto ON
From dscherrer at solar.stanford.edu Mon Jul 19 07:50:27 2021
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Sun, 18 Jul 2021 14:50:27 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <1626641054.6580.for-standards-violators@oclsc.org>
References: <1626641054.6580.for-standards-violators@oclsc.org>
Message-ID: <09cfb9e5-fcce-e554-ddd0-ff0a16e08500@solar.stanford.edu>
It is indeed Mount Z-eye-nu.В В (I used to be its President. ;-)В В )
Ed is living in the Walnut Creek area.В He has indeed retired and he and
his wife do indeed do a lot of sailing.
Deborah
On 7/18/21 1:44 PM, Norman Wilson wrote:
> Unlike most here, I always pronounced Mt Xinu with an
> eye, not an eee. I don't know where I got that, though.
>
> I did know Ed Gould via USENIX and DECUS, but that doesn't
> make my pronunciation correct.
>
> As an aside, anyone know where Ed is these days or how he's
> doing? I last saw him at a USENIX conference, probably in
> San Jose in 2013 but I'm not sure. He showed up just for the
> reception; he'd retired, and had cut away most of his famous
> beard because he was spending a lot of time sailing and it
> got in the way.
>
> Norman Wilson
> Toronto ON
From imp at bsdimp.com Mon Jul 19 08:40:07 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 18 Jul 2021 16:40:07 -0600
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <09cfb9e5-fcce-e554-ddd0-ff0a16e08500@solar.stanford.edu>
References: <1626641054.6580.for-standards-violators@oclsc.org>
<09cfb9e5-fcce-e554-ddd0-ff0a16e08500@solar.stanford.edu>
Message-ID: <CANCZdfoNwEZku5UFBvgdr51HK_WFgOQi_0q-h=8xPH=oDymrdg@mail.gmail.com>
On Sun, Jul 18, 2021 at 4:17 PM Deborah Scherrer <
dscherrer at solar.stanford.edu> wrote:
> It is indeed Mount Z-eye-nu. (I used to be its President. ;-) )
>
Excellent! That's how I'd always heard it. Glad to know it's right.
Ed is living in the Walnut Creek area. He has indeed retired and he and
> his wife do indeed do a lot of sailing.
>
Great!
Thanks for the somewhat authoritative answer :)
Warner
> Deborah
>
> On 7/18/21 1:44 PM, Norman Wilson wrote:
> > Unlike most here, I always pronounced Mt Xinu with an
> > eye, not an eee. I don't know where I got that, though.
> >
> > I did know Ed Gould via USENIX and DECUS, but that doesn't
> > make my pronunciation correct.
> >
> > As an aside, anyone know where Ed is these days or how he's
> > doing? I last saw him at a USENIX conference, probably in
> > San Jose in 2013 but I'm not sure. He showed up just for the
> > reception; he'd retired, and had cut away most of his famous
> > beard because he was spending a lot of time sailing and it
> > got in the way.
> >
> > Norman Wilson
> > Toronto ON
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210718/6303dd5e/attachment.htm>
From dscherrer at solar.stanford.edu Mon Jul 19 07:48:09 2021
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Sun, 18 Jul 2021 14:48:09 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <202107181900.16IJ0Wwn007583@freefriends.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com> <YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
<a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
<202107181900.16IJ0Wwn007583@freefriends.org>
Message-ID: <be0ee181-36b5-e4b3-6149-bd08acbe71db@solar.stanford.edu>
I believe I have all of the calendars.В В Will try to scan them in.
Deborah
On 7/18/21 12:00 PM, arnold at skeeve.com wrote:
> Hi.
>
> Al Kossow <aek at bitsavers.org> wrote:
>
>> On 7/18/21 6:43 AM, Al Kossow wrote:
>>> On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
>>>> Richard Salz <rich.salz at gmail.com> wrote:
>>>>
>>>>> Anyone remember the old mtXinu calendar with fake ads?
>>> I just turned up a copy, it's from 1993
>>> I'll have it on bitsavers under pdf/mtXinu later today
>>>
>> > Calendars cycle every 28 years
>>
>> the coincidence was asking about it on exactly that year
>>
>> it's up now under http://bitsavers.org/pdf/mtXinu
> Thanks! It's not the calendar Rich and I remember, but it's
> still worth having. :-)
>
>> is supposed to be pronouced zee new or zeye new ?
> I always pronounced it zee new.
>
> Arnold
From lbickley at bickleywest.com Mon Jul 19 06:06:58 2021
From: lbickley at bickleywest.com (Lyle Bickley)
Date: Sun, 18 Jul 2021 13:06:58 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
References: <alpine.BSF.2.21.9999.2107140824460.15723@aneurin.horsfall.org>
<213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost>
<alpine.BSF.2.21.9999.2107161127480.32008@aneurin.horsfall.org>
<5777F7E6-062B-4C5A-9C98-36FFE6AC3414@stdio.com>
<YPEKScdjJCE+KMjj@mit.edu>
<A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>
<YPGDCoO4uB1ehBxi@mit.edu> <20210716135639.GI12733@mcvoy.com>
<CAK7dMtBcjeDEcjWjs829pUayq6ZkNf70t_Di4FwRynjVrZmJyg@mail.gmail.com>
<CAC20D2M7ytkKEwTeBvZySJtr2XLNiQjphhJ-66ZTuKfsviJHOw@mail.gmail.com>
<CAFH29trY2ZBcssDawauQWMEKzLc+7ZVeVOcXWc_50et7LcFtHw@mail.gmail.com>
<202107181313.16IDDSn8029320@freefriends.org>
<aa9b0fe5-8d4b-ef72-218a-f82c771cc5d1@bitsavers.org>
<a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
Message-ID: <20210718130658.344b2273@asrock>
On Sun, 18 Jul 2021 09:44:53 -0700
Al Kossow <aek at bitsavers.org> wrote:
> On 7/18/21 6:43 AM, Al Kossow wrote:
> > On 7/18/21 6:13 AM, arnold at skeeve.com wrote:
> >> Richard Salz <rich.salz at gmail.com> wrote:
> >>
> >>> Anyone remember the old mtXinu calendar with fake ads?
> >
> > I just turned up a copy, it's from 1993
> > I'll have it on bitsavers under pdf/mtXinu later today
> >
>
> > Calendars cycle every 28 years
>
> the coincidence was asking about it on exactly that year
>
> it's up now under http://bitsavers.org/pdf/mtXinu
>
> is supposed to be pronouced zee new or zeye new ?
>
Thanks, Al!!!
Lyle
--
73 NM6Y
Bickley Consulting West
https://bickleywest.com
"Black holes are where God is dividing by zero"
From drsalists at gmail.com Mon Jul 19 13:06:33 2021
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 18 Jul 2021 20:06:33 -0700
Subject: [TUHS] MtXinu calendar (was Re: 386BSD released)
In-Reply-To: <DDC768AA-D7CE-4CEA-92AD-D2D2AD7E1B3D@iitbombay.org>
References: <a0f7e2bf-9b39-a353-0a91-58a9dbb9edf6@bitsavers.org>
<DDC768AA-D7CE-4CEA-92AD-D2D2AD7E1B3D@iitbombay.org>
Message-ID: <CAGGBd_oEEJAuzecttgx-nD7giwpzdDwu1P9tgFPSsGBe9Oyx2w@mail.gmail.com>
On Sun, Jul 18, 2021 at 11:36 AM Bakul Shah <bakul at iitbombay.org> wrote:
> On Jul 18, 2021, at 9:45 AM, Al Kossow <aek at bitsavers.org> wrote:
>
>
> is supposed to be pronouced zee new or zeye new ?
>
>
> *Don't know **how it is supposed to be pronounced but **I have*
> *always pronounced it as **'zai-noo, with xi the **way the greek*
> *letter Оѕ is pronounced in English.*
>
We pronounced it as Mownt Zeye New when I was managing a lab of IBM RT's
running Mt Xinu's MSD 2.6 as a grad student.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210718/418cdb8d/attachment.htm>
From coppero1237 at gmail.com Tue Jul 20 03:04:16 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Mon, 19 Jul 2021 20:04:16 +0300
Subject: [TUHS] Unix Shell Programming: The Next 50 Years
Message-ID: <CAEuQd1AdT35zK-x1mTUMYiYtbOKy=PNfdF5mgE=7-F_Zimk5Lw@mail.gmail.com>
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s06-greenberg.pdf
Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210719/11583394/attachment.htm>
From coppero1237 at gmail.com Tue Jul 20 03:12:34 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Mon, 19 Jul 2021 20:12:34 +0300
Subject: [TUHS] Unix Shell Programming: The Next 50 Years
In-Reply-To: <CAEuQd1AdT35zK-x1mTUMYiYtbOKy=PNfdF5mgE=7-F_Zimk5Lw@mail.gmail.com>
References: <CAEuQd1AdT35zK-x1mTUMYiYtbOKy=PNfdF5mgE=7-F_Zimk5Lw@mail.gmail.com>
Message-ID: <CAEuQd1BWRadyM8if34biK9tfBos8tPy8m0ug08iqAMMhov96Bw@mail.gmail.com>
Whoops, sorry for the repost, didn't see the thread ><
Tyler
On Mon, Jul 19, 2021 at 8:04 PM Tyler Adams <coppero1237 at gmail.com> wrote:
>
> https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s06-greenberg.pdf
> Tyler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210719/c1423c55/attachment.htm>
From pnr at planet.nl Sat Jul 24 09:03:34 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 24 Jul 2021 01:03:34 +0200
Subject: [TUHS] Triangulating 32V with paging
Message-ID: <B5BDBDB2-F23B-4C7D-9D04-F5E77B902664@planet.nl>
> Sat Aug 31 06:21:47 AEST 2019
> John Reiser did do his own paging system for UNIX 32/V.
> I heard about it from friends at Bell Labs ca. 1982-83,
> when I was still running systems for physicists at Caltech.
> It sounded very interesting, and I would love to have had
> my hands on it--page cache unified with buffer cache,
> copy-on-write from the start.
>
> [...]
>
> It is in any case a shame that jfr's code never saw the light
> of day. I really hope someone can find it on an old tape
> somewhere and we can get it into the archive, if only because
> I'd love to look at it.
>
> Norman Wilson
> Toronto ON
Norman,
I am getting more optimistic that much of this version of 32V can be вЂtriangulated’ from the surviving sources. For convenience I call this version “32V r3” (with the first swapping version being "32V r1" and the scatter loading version being "32V r2").
I’ve been reading my way through the surviving 32/V r2, SysIII-Vax, SVr1-Vax and SVr2-Vax sources. There seems to be a lot of continuous progression in these versions. From a communication with Keith Kelleman I thought that VM in SVr2 was unrelated, but that appears to have been a misunderstanding. In short, it seems that the basic paging algorithms and data structures in SVr2 (other than the region abstraction) come from 32V r3.
The strongest clue for the source link is in the SVr2 “page.h” file. In it, the union describing a page table entry matches with JFR’s description and is otherwise (partially) unused in SVr2. There are other, similar clues in the other source trees.
To explain more clearly, have a look at this code section: https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/uts/vax/sys/page.h#L61-L106
In this union, the 2nd struct “pgd” is never used, nor is the bit pg_disk in the “pgm” struct ever used. It matches with JFR’s recollection:
<quote>
My internal design strategy was to use the hardware page table entry
(4 bytes per page, with "page not present" being one bit which freed
the other 31 bits for use by software) as the anchor to track everything
about a page. This resulted in a complicated union of bitfield structs,
which became a headache. When other departments took over the work,
the first thing they did was use 8 bytes per page, which meant shuffling
between the software and the hardware descriptors: its own mess.
<unquote>
In the pte as given, a pte can be in two states: (i) the pg_disk bit is reset in which case it is in “pgm” format - this format is recognized by the mmu hardware; (ii) the pg_disk bit is set in which case it is in “pgd” format. When a page is paged in, the disk form of the pte was I think saved in the page frame descriptor (the “pfdat" table) and the pte converted to the memory form. Upon page-out the reverse happened. In the SVr2 version of this code the “pgd” form is abandoned and replaced by the separate disk descriptors (see https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/uts/vax/sys/region.h#L104-L114)
The “pgd” structure is a bit puzzling. There is a 19 bit device block number, which is less than the 24 bits allowed by the filesystem code and also less than the 20 bits that would fit in the pte. Maybe this is because the RP04/RP05 disks of the early 80’s worked with 19 bits. I am not sure what the “pg_iord” field is about. The comment “inode index” may be misleading. My hypothesis that it is a short form of the device code, for instance an index into the mount table; magic values could have been used to identify the swap device, “demand zero”, etc.
It seems probable to me that the paging algorithm in SVr2 was derived from the 32/V r3 algorithm. John's recollection:
<quote>
Our machine started with 512KB of RAM, but within a few months was upgraded
to 4 MB with boards that used a new generation of RAM chips.
The hardware page size was 512 bytes, which is quite small. Strict LRU
on 8,192 pages, plus Copy-On-Write, made the second reference to a page
"blindingly fast".
</unquote>
In a follow up mail conversation with JFR we (I?) arrived at the conclusion that literal “strict LRU” is not likely on VAX hardware, but that an algorithm that maintains a small working set combined with a large second chance list amounts to about the same. It seems to me that this description also applies to the surviving SVr2 implementation: every 4 seconds sweep through the page tables of all processes and pages that were not referenced are moved to the free/2nd chance list.
To implement this it seems likely to me that 32V r3 used a structure similar to this: https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/uts/vax/sys/pfdat.h#L4-L13 Such a structure is also in line with viewing core as a cache for disk, similar to TENEX that JFR had in mind.
The big change from SysIII to SVr1 in kernel page table management is the introduction of the “sptmap” (https://chiselapp.com/user/pnr/repository/paging/file?name=os/machdep.c&ci=fba821c0b38e2e350da927347eba25d5fe53852c&ln=346,378). In 32V r2 and SysIII the user page tables are swapped in and out of kernel space along with the _u area. This makes it impractical to do the working set sweep every few seconds. The “sptmap” innovation effectively creates a global page table space that fits with the needs of the working set sweep. In SVr1 it seems to have no real benefit, and it seems likely to me that it came from 32V r3.
In general it seems plausible to me that SVr1 derives from 32V r3, but was regressed to SysIII code where necessary to keep the code PDP-11 compatible. Another clue for this is in the buffer code of SVr1: https://chiselapp.com/user/pnr/repository/paging/file?name=os/main.c&ci=fba821c0b38e2e350da927347eba25d5fe53852c&ln=205,218
Here, the disk buffers are allocated as virtual memory pages, not as an array. This too is otherwise unused in SVr1, but makes perfect sense in the context of 32V r3.
So, in summary, it would seem to me that the 32V r3 virtual memory system:
- used sptmap code similar to SVr1/r2 to manage page tables in the kernel
- used the pte structure from SVr2 and a pfdat table similar to SVr2 to manage mappings
- used page stealer and fault code similar to SVr2
Phrased the other way around: SVr2-vax seems to use the 32V r3 virtual memory code with the region abstraction added on top, and the unified buffer removed.
At the moment I have not found clear clues for the unified buffer algorithms or mmap implementation. Perhaps careful reading of the IPC shared memory code in SVr1 will yield some.
To be continued …
From pnr at planet.nl Sun Jul 25 04:36:45 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 24 Jul 2021 20:36:45 +0200
Subject: [TUHS] Who designed SysV IPC?
Message-ID: <6F5C0B9D-C7EF-4DED-AAA5-241F55A916E6@planet.nl>
Currently reading through IPC in CB Unix 3.0, Vr1-vax and SVr1-pdp11.
The IPC primitives in CB Unix (maus, event and msg) are quite different from those in SVr1 (although maus survives in SVr1-pdp11).
It made me wonder: is it still known who designed the IPC primitives for SysV?
From clemc at ccc.com Sun Jul 25 05:41:40 2021
From: clemc at ccc.com (Clem Cole)
Date: Sat, 24 Jul 2021 15:41:40 -0400
Subject: [TUHS] Who designed SysV IPC?
In-Reply-To: <6F5C0B9D-C7EF-4DED-AAA5-241F55A916E6@planet.nl>
References: <6F5C0B9D-C7EF-4DED-AAA5-241F55A916E6@planet.nl>
Message-ID: <CAC20D2OpraFXB_1aE+9vtZyreEtgFx=86VmnaHJe6ODV06zM9A@mail.gmail.com>
Yeah - they are different, but I'm pretty sure that Dale's work in CB UNIX
came first. I know I saw the CB/UNIX code as hacks to PWB 1.0 I think
(maybe 2.0) when I was still at CMU in 1978 (Phil Karn had it IIRC). I
was under the impression that folks at Summit (e.g. UNIX Support Group) had
the job of collecting different features that had been done and putting
them into the AT&T 'Standard' for the operating companies. I agree it
would be interesting to learn who did the work. But as I always understood
it, Dale's team gave the CB/UNIX stuff to the USG folks who reimplemented
it, I thought because USG was redoing the memory code and wanted something
that would integrate better. I suspect it is also possible, Dale and his
team redid it in the key of System V at some point and pushed it back.
Clem
бђ§
On Sat, Jul 24, 2021 at 2:38 PM Paul Ruizendaal via TUHS <
tuhs at minnie.tuhs.org> wrote:
> Currently reading through IPC in CB Unix 3.0, Vr1-vax and SVr1-pdp11.
>
> The IPC primitives in CB Unix (maus, event and msg) are quite different
> from those in SVr1 (although maus survives in SVr1-pdp11).
>
> It made me wonder: is it still known who designed the IPC primitives for
> SysV?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210724/a8b021a2/attachment.htm>
From pnr at planet.nl Sun Jul 25 22:54:13 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 25 Jul 2021 14:54:13 +0200
Subject: [TUHS] Wy 32V R3 was fast
Message-ID: <28452B35-1321-4EC2-8F83-07E9D78BEC8B@planet.nl>
> TUHS list (Rob Pike, Aug 2019)
>
> I think it was slightly later. I joined mid-1980 and VAXes to replace the
> 11/70 were being discussed but had not arrived. We needed to convert a lab
> into a VAX machine room and decide between BSD and Reiser, all of which
> happened in the second half of 1980.
>
> Reiser Unix got demand paging a little later, and it was spectacularly
> fast. I remember being gobsmacked when I saw a demo in early 1981.
>
> Dead ends everywhere.
I think I have figured out why 32V R3 was so fast (assuming my current understanding of how 32V R3 must have worked is correct).
Its VM subsystem tags each memory frame with its disk mirror location, be it in swap or in the file system. A page can quickly be found as they are hashed on device and block no. This is true both for pages in the working set and pages on the 2nd chance list. Effectively, most core is a disk cache.
In a unified buffer design, the buffer code would first look for an existing buffer header for the requested disk block, as in V7. If not found, it would check the page frame list for that block and if found it would connect the frame to an empty buffer header, increment its use count and move it to the working set. If not found there either, it would be loaded from disk as per usual. When a buffer is released, the frame use count would be decremented and if zero the page frame would be put back on the 2nd chance list and the buffer header would be marked empty. With this approach, up to 4MB of the disk could be cached in RAM.
Early in 1981 most binaries and files were a few dozen KB in size. All of the shell, editor, compiler tool chain, library files, intermediate files, etc. would have fitted in RAM all at once. In a developer focused demo and once memory was primed, the system would effectively run from RAM, barely hitting the disk, even with tens of concurrent logins. Also something like “ls -l /bin” would have been much faster on its second run.
It puts a comment from JFR in a clearer context:
<quote>
Strict LRU on 8,192 pages, plus Copy-On-Write, made the second reference to a page "blindingly fast".
<unquote>
So far I read this in context of the paging algorithm, and then it is hard to understand (is LRU really that much better than NRU?). In the context of a unified buffer and disk pages, it makes a lot more sense. Even the CoW part: as the (clean) data segment of executables would still be in core, they could start without reloading from disk - CoW would create copies as needed.
===
The interesting question now is: if this buffer unification was so impressive, why was it abandoned in SVr2-vax? I can think of 3 reasons:
1. Maybe there was a subtle bug that was hard to diagnose. “Research" opting for the BSD memory system “as it did not want to do the maintenance” suggests that there may have been lingering issues.
1b. A variation of this: JFR mentioned that his implementation of unified buffers broke conceptual layering. USG do not strike me as purists, but maybe they thought the code was too messy to maintain.
2. Maybe there was an unintended semantic issue (e.g. you can lock a buffer, but not a mmap вЂed page).
3. Maybe it was hard to come up with a good sync() policy, making database work risky (and system crashes more devastating to the file system).
JFR mentioned that he did the design and implementation for 32V R3 in about 3 months, with 3 more months for bug fixing and polishing. That is not a lot of time for such a big and complex kernel mod (for its time).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210725/609fe42e/attachment.htm>
From douglas.mcilroy at dartmouth.edu Wed Jul 28 08:46:43 2021
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Tue, 27 Jul 2021 18:46:43 -0400
Subject: [TUHS] Latex-Style Equations in Troff
Message-ID: <CAKH6PiX-LHqqfgmX+_GqornOvvy+XA2SoiAUMLf2wR03k_j_Pg@mail.gmail.com>
That's a neat tool. It would be nice to have the
inverse tool, too; it's painful to do by hand.
Doug
From msi at malbolge.net Sat Jul 31 22:25:33 2021
From: msi at malbolge.net (Michael Siegel)
Date: Sat, 31 Jul 2021 14:25:33 +0200
Subject: [TUHS] Systematic approach to command-line interfaces
Message-ID: <20210731142533.69caf929@moon>
Hello,
I've recently started to implement a set of helper functions and
procedures for parsing Unix-like command-line interfaces (i.e., POSIX +
GNU-style long options, in this case) in Ada.
While doing that, I learned that there is a better way to approach
this problem – beyond using getopt(s) (which never really made sense to
me) and having to write case statements in loops every time: Define a
grammar, let a pre-built parser do the work, and have the parser
provide the results to the program.
Now, defining such a grammar requires a thoroughly systematic approach
to the design of command-line interfaces. One problem with that is
whether that grammar should allow for sub-commands. And that leads to
the question of how task-specific tool sets should be designed. These
seem to be a relatively new phenomenon in Unix-like systems that POSIX
doesn't say anything about, as far as I can see.
So, I've prepared a bit of a write-up, pondering on the pros and cons
of two different ways of having task-specific tool sets
(non-hierarchical command sets vs. sub-commands) that is available at
https://www.msiism.org/files/doc/unix-like_command-line_interfaces.html
I tend to think the sub-command approach is better. But I'm neither a UI
nor a Unix expert and have no formal training in computer things. So, I
thought this would be a good place to ask for comment (and get some
historical perspective).
This is all just my pro-hobbyist attempt to make some people's lives
easier, especially mine. I mean, currently, the "Unix" command line is
quite a zoo, and not in a positive sense. Also, the number of
well-thought-out command-line interfaces doesn't seem to be a growing
one. But I guess that could be changed by providing truly easy ways to
make good interfaces.
--
Michael
From halbert at halwitz.org Sat Jul 31 23:05:47 2021
From: halbert at halwitz.org (Dan Halbert)
Date: Sat, 31 Jul 2021 09:05:47 -0400
Subject: [TUHS] Systematic approach to command-line interfaces
In-Reply-To: <20210731142533.69caf929@moon>
References: <20210731142533.69caf929@moon>
Message-ID: <146ddec4-af34-dadb-65d0-1f8c309526ae@halwitz.org>
The "click" CLI parser for Python I think would be of interest to you:
https://click.palletsprojects.com/. It has support for sub-commands and
nesting. It's not grammar-based internally, as far as I know.
Also I think PowerShell has some interesting concepts, though I've not
looked at it in detail.
Dan H.
On 7/31/21 8:25 AM, Michael Siegel wrote:
> Hello,
>
> I've recently started to implement a set of helper functions and
> procedures for parsing Unix-like command-line interfaces (i.e., POSIX +
> GNU-style long options, in this case) in Ada.
>
> While doing that, I learned that there is a better way to approach
> this problem – beyond using getopt(s) (which never really made sense to
> me) and having to write case statements in loops every time: Define a
> grammar, let a pre-built parser do the work, and have the parser
> provide the results to the program.
>
> Now, defining such a grammar requires a thoroughly systematic approach
> to the design of command-line interfaces. One problem with that is
> whether that grammar should allow for sub-commands. And that leads to
> the question of how task-specific tool sets should be designed. These
> seem to be a relatively new phenomenon in Unix-like systems that POSIX
> doesn't say anything about, as far as I can see.
>
> So, I've prepared a bit of a write-up, pondering on the pros and cons
> of two different ways of having task-specific tool sets
> (non-hierarchical command sets vs. sub-commands) that is available at
>
> https://www.msiism.org/files/doc/unix-like_command-line_interfaces.html
>
> I tend to think the sub-command approach is better. But I'm neither a UI
> nor a Unix expert and have no formal training in computer things. So, I
> thought this would be a good place to ask for comment (and get some
> historical perspective).
>
> This is all just my pro-hobbyist attempt to make some people's lives
> easier, especially mine. I mean, currently, the "Unix" command line is
> quite a zoo, and not in a positive sense. Also, the number of
> well-thought-out command-line interfaces doesn't seem to be a growing
> one. But I guess that could be changed by providing truly easy ways to
> make good interfaces.
>
>
> --
> Michael