From clemc at ccc.com  Wed Jan  1 02:40:14 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 31 Dec 2019 11:40:14 -0500
Subject: [TUHS] pic anomalies
In-Reply-To: <201912310424.xBV4O2Cr016640@tahoe.cs.Dartmouth.EDU>
References: <201912310424.xBV4O2Cr016640@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2McHEfH8nibwaX-MjEebdsKpHL1VeAykj3-VHDDYmunXA@mail.gmail.com>

On Mon, Dec 30, 2019 at 11:24 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> The use of %% to designate a literal % in printf is not
> a recent convention. It was defined in K&R, first edition.
>
FWIW, I still have an old (fading) copy of the galley proofs for the first
edition.  Page 147 (*Chapter 7 - Input and Output, Section 7.3 Formatted
Output - Printf*) first full paragraph on the page:

If the character after the % is not a conversion character, that character
is printed: thus % may be printed by %%.



>
> Doug
>
> Ralph Cordery wrote:
>
> Though that may seem odd to our modern C-standardised eyes, it's
> understandable in that if it isn't a valid %f, etc., format specifier
> then it's a literal percent sign.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20191231/3af55a4d/attachment.html>

From doug at cs.dartmouth.edu  Fri Jan  3 07:38:00 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 02 Jan 2020 16:38:00 -0500
Subject: [TUHS] GNUism in groff tests, was: pic anomalies
Message-ID: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU>

I have always marveled at folks who can maintain multiple
versions of software, but Larry's dispatch from the
trenches reveals hurdles I hadn't imagined. Kudos for
keeping groff alive. 

Speaking of which, many thanks to all who pitched in
on the %% nit that I reported. The instant response
compares rather favorably to an open case I've been
following in gcc, which was originally filed in 2002.

Doug

From meillo at marmaro.de  Fri Jan  3 22:45:53 2020
From: meillo at marmaro.de (markus schnalke)
Date: Fri, 03 Jan 2020 13:45:53 +0100
Subject: [TUHS] sh:  cmd | >file
Message-ID: <1inMKv-0Km-00@marmaro.de>

Hoi,

in a computer forum I came across a very long command line,
including `xargs' and `sh -c'. Anyways, throughout the thread
it was modified several times, when accidently a pipe symbol
appeared between the command and the output redirection. The
command line did nothing; it ran successful. I was confused,
because I expected to see a syntax error in case of
``cmd|>file''. This made me wonder ...


With help of Sven Mascheck, I was able to clear my understanding.
The POSIX shell grammer provided the answer:

pipeline         :      pipe_sequence 
                 ... 
 
pipe_sequence    :                             command 
                 | pipe_sequence '|' linebreak command 
                 ; 
command          : simple_command 
                 ... 
 
simple_command   : cmd_prefix cmd_word cmd_suffix 
                 | cmd_prefix cmd_word 
                 | cmd_prefix   <--- HIER! 
                 | cmd_name cmd_suffix 
                 | cmd_name 
                 ; 
 
cmd_prefix       :            io_redirect 
                 ... 
 
io_redirect      :           io_file 
                 ... 
 
io_file          : '<'       filename 
                 | LESSAND   filename 
                 | '>'       filename 
                 ... 
 
A redirection is a (full) simple_command ... and because
``simple_command | simple_command'' is allowed, so is
``io_file | io_file''. This can lead to such strange (but
valid) command lines like:
 
	<a | >b 
	>b | <a 
 
Sven liked this one:

	:|>: 

Here some further fun variants:
 
	:|:>: 

	<:|:>: 

They would provide nice puzzles. ;-)


My understanding was helped most by detaching from the
semantics and focussing on syntax. This one is obviously
valid, no matter it has no effect:
 
	:|:|: 

From there it was easier to grasp:
 
	>a | >a | >a 
 
Which is valid, because ``>a'' is a (complete) simple_command.
 
Thus, no bug but consistent grammer. ;-) 


If one would have liked to forbid such a corner case,
additional special case handling would have been necessary
... which is in contrast to the Unix way.
 

Sven checked the syntax against various shells with these
results:

- Syntax ok in these shells:

SVR2 sh (Ultrix), SVR4 sh (Heirloom)
ksh93
bash-1.05, bash-aktuell
pdksh-5.2.14
ash-0.4.26, dash-0.5.6.1
posh-0.3.7, posh-0.12.3
mksh-R24, mksh-R52b
yash-2.29
zsh-3.0.8, zsh-4.3.17

- Exception to the rule:

7thEd sh:

    # pwd|>>file
    # echo $?
    141

On first sight ok, but with a silent error ... SIGPIPE (128+13).


I'd be interested in any stories and information around this
topic.

What about 7thEd sh?


meillo

From steffen at sdaoden.eu  Fri Jan  3 23:57:15 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 03 Jan 2020 14:57:15 +0100
Subject: [TUHS] GNUism in groff tests, was: pic anomalies
In-Reply-To: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU>
References: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU>
Message-ID: <20200103135715.S1lyA%steffen@sdaoden.eu>

Doug McIlroy wrote in <202001022138.002Lc0Up132858 at tahoe.cs.Dartmouth.EDU>:
 |I have always marveled at folks who can maintain multiple
 |versions of software, but Larry's dispatch from the
 |trenches reveals hurdles I hadn't imagined. Kudos for
 |keeping groff alive. 

I concur.  And as everything in life is a wave, it all comes back
as times go by.  Some even agree to die younger than nature allows
humans ("Er [Der Mensch] lebt wenn's hochkommt Hundert Jahr" [1]),
because they have seen it all in the past, and are getting all too
bored!

  [1] https://www.youtube.com/watch?v=1Ayethw-ouQ

 |Speaking of which, many thanks to all who pitched in
 |on the %% nit that I reported. The instant response
 |compares rather favorably to an open case I've been
 |following in gcc, which was originally filed in 2002.
 |
 |Doug
 --End of <202001022138.002Lc0Up132858 at tahoe.cs.Dartmouth.EDU>

--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  Sat Jan  4 00:00:55 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 03 Jan 2020 15:00:55 +0100
Subject: [TUHS] sh:  cmd | >file
In-Reply-To: <1inMKv-0Km-00@marmaro.de>
References: <1inMKv-0Km-00@marmaro.de>
Message-ID: <20200103140055.XB8iT%steffen@sdaoden.eu>

markus schnalke wrote in <1inMKv-0Km-00 at marmaro.de>:
 |Hoi,

Morsche.

 |in a computer forum I came across a very long command line,
 |including `xargs' and `sh -c'. Anyways, throughout the thread
 |it was modified several times, when accidently a pipe symbol
 |appeared between the command and the output redirection. The
 |command line did nothing; it ran successful. I was confused,
 |because I expected to see a syntax error in case of
 |``cmd|>file''. This made me wonder ...
 |
 |
 |With help of Sven Mascheck, I was able to clear my understanding.
 |The POSIX shell grammer provided the answer:
 ...
 |A redirection is a (full) simple_command ... and because
 |``simple_command | simple_command'' is allowed, so is
 |``io_file | io_file''. This can lead to such strange (but
 |valid) command lines like:
 | 
 | <a | >b 
 |>b | <a 
 | 
 |Sven liked this one:
 |
 |:|>: 
 |
 |Here some further fun variants:
 | 
 |:|:>: 
 |
 | <:|:>: 
 |
 |They would provide nice puzzles. ;-)
 ...
 |- Syntax ok in these shells:
 |
 |SVR2 sh (Ultrix), SVR4 sh (Heirloom)

Be aware of spurious :> errors in Heirloom shell, and maybe its
origin (never had those).  It is why the unit test of my little
web site builder thing has been switched to "printf '' > FILE".

 |ksh93
 |bash-1.05, bash-aktuell
 |pdksh-5.2.14
 |ash-0.4.26, dash-0.5.6.1
 |posh-0.3.7, posh-0.12.3
 |mksh-R24, mksh-R52b
 |yash-2.29
 |zsh-3.0.8, zsh-4.3.17
 |
 |- Exception to the rule:
 |
 |7thEd sh:
 |
 |    # pwd|>>file
 |    # echo $?
 |    141
 |
 |On first sight ok, but with a silent error ... SIGPIPE (128+13).
 |
 |I'd be interested in any stories and information around this
 |topic.
 |
 |What about 7thEd sh?

  Beware of bugs in the above code; I have only proved it correct,
  not tried it.

 |meillo
 --End of <1inMKv-0Km-00 at marmaro.de>

--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 brian at zick.io  Sat Jan  4 03:03:07 2020
From: brian at zick.io (Brian Zick)
Date: Fri, 03 Jan 2020 11:03:07 -0600
Subject: [TUHS] sh:  cmd | >file
In-Reply-To: <20200103140055.XB8iT%steffen@sdaoden.eu>
References: <1inMKv-0Km-00@marmaro.de>
 <20200103140055.XB8iT%steffen@sdaoden.eu>
Message-ID: <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com>

I'm curious to know if you have a script you used to prove these correct?

B

On Fri, Jan 3, 2020, at 8:00 AM, Steffen Nurpmeso wrote:
> markus schnalke wrote in <1inMKv-0Km-00 at marmaro.de>:
>  |Hoi,
> 
> Morsche.
> 
>  |in a computer forum I came across a very long command line,
>  |including `xargs' and `sh -c'. Anyways, throughout the thread
>  |it was modified several times, when accidently a pipe symbol
>  |appeared between the command and the output redirection. The
>  |command line did nothing; it ran successful. I was confused,
>  |because I expected to see a syntax error in case of
>  |``cmd|>file''. This made me wonder ...
>  |
>  |
>  |With help of Sven Mascheck, I was able to clear my understanding.
>  |The POSIX shell grammer provided the answer:
>  ...
>  |A redirection is a (full) simple_command ... and because
>  |``simple_command | simple_command'' is allowed, so is
>  |``io_file | io_file''. This can lead to such strange (but
>  |valid) command lines like:
>  | 
>  | <a | >b 
>  |>b | <a 
>  | 
>  |Sven liked this one:
>  |
>  |:|>: 
>  |
>  |Here some further fun variants:
>  | 
>  |:|:>: 
>  |
>  | <:|:>: 
>  |
>  |They would provide nice puzzles. ;-)
>  ...
>  |- Syntax ok in these shells:
>  |
>  |SVR2 sh (Ultrix), SVR4 sh (Heirloom)
> 
> Be aware of spurious :> errors in Heirloom shell, and maybe its
> origin (never had those).  It is why the unit test of my little
> web site builder thing has been switched to "printf '' > FILE".
> 
>  |ksh93
>  |bash-1.05, bash-aktuell
>  |pdksh-5.2.14
>  |ash-0.4.26, dash-0.5.6.1
>  |posh-0.3.7, posh-0.12.3
>  |mksh-R24, mksh-R52b
>  |yash-2.29
>  |zsh-3.0.8, zsh-4.3.17
>  |
>  |- Exception to the rule:
>  |
>  |7thEd sh:
>  |
>  |    # pwd|>>file
>  |    # echo $?
>  |    141
>  |
>  |On first sight ok, but with a silent error ... SIGPIPE (128+13).
>  |
>  |I'd be interested in any stories and information around this
>  |topic.
>  |
>  |What about 7thEd sh?
> 
>   Beware of bugs in the above code; I have only proved it correct,
>   not tried it.
> 
>  |meillo
>  --End of <1inMKv-0Km-00 at marmaro.de>
> 
> --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 meillo at marmaro.de  Sat Jan  4 03:18:00 2020
From: meillo at marmaro.de (markus schnalke)
Date: Fri, 03 Jan 2020 18:18:00 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com>
References: <1inMKv-0Km-00@marmaro.de>
 <20200103140055.XB8iT%steffen@sdaoden.eu>
 <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com>
Message-ID: <1inQaG-3N3-00@marmaro.de>

Hoi.

[2020-01-03 11:03] "Brian Zick" <brian at zick.io>
>
> I'm curious to know if you have a script you used to prove these correct?

We have to wait for Sven Mascheck to answer this question. He tested
the different shells.


meillo

From meillo at marmaro.de  Sat Jan  4 05:38:14 2020
From: meillo at marmaro.de (markus schnalke)
Date: Fri, 03 Jan 2020 20:38:14 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1inMKv-0Km-00@marmaro.de>
References: <1inMKv-0Km-00@marmaro.de>
Message-ID: <1inSly-4mJ-00@marmaro.de>

Hoi.

[2020-01-03 13:45] markus schnalke <meillo at marmaro.de>
>
> I'd be interested in any stories and information around this
> topic.

Especially I'd like to know since when and why ``>file'' is a
full command? Was it clever design or by accident?


meillo

From imp at bsdimp.com  Sat Jan  4 05:44:36 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 3 Jan 2020 13:44:36 -0600
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1inSly-4mJ-00@marmaro.de>
References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de>
Message-ID: <CANCZdfqcLttTBo9H+W5bFncoeBkAJ20FdNb-VLR3px5=00+BxA@mail.gmail.com>

On Fri, Jan 3, 2020, 1:39 PM markus schnalke <meillo at marmaro.de> wrote:

> Hoi.
>
> [2020-01-03 13:45] markus schnalke <meillo at marmaro.de>
> >
> > I'd be interested in any stories and information around this
> > topic.
>
> Especially I'd like to know since when and why ``>file'' is a
> full command? Was it clever design or by accident?


It's used to open files in shell scripts. Iirc, exec >foo 5>& and the
like...

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200103/20ea3249/attachment.html>

From mparson at bl.org  Sat Jan  4 08:49:26 2020
From: mparson at bl.org (Michael Parson)
Date: Fri, 03 Jan 2020 16:49:26 -0600
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CANCZdfqcLttTBo9H+W5bFncoeBkAJ20FdNb-VLR3px5=00+BxA@mail.gmail.com>
References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de>
 <CANCZdfqcLttTBo9H+W5bFncoeBkAJ20FdNb-VLR3px5=00+BxA@mail.gmail.com>
Message-ID: <c6db37131fdeace7dee01920f53ff85e@bl.org>

On 2020-01-03 13:44, Warner Losh wrote:
> On Fri, Jan 3, 2020, 1:39 PM markus schnalke <meillo at marmaro.de> wrote:
> 
>> Hoi.
>> 
>> [2020-01-03 13:45] markus schnalke <meillo at marmaro.de>
>> >
>> > I'd be interested in any stories and information around this
>> > topic.
>> 
>> Especially I'd like to know since when and why ``>file'' is a
>> full command? Was it clever design or by accident?
> 
> 
> It's used to open files in shell scripts. Iirc, exec >foo 5>& and the
> like...

I've also used it to truncate files:

$ dd if=/dev/zero of=file count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.000686599 s, 7.5 MB/s

$ ls -l file
-rw-rw-r-- 1 mparson mparson 5120 Jan  3 16:45 file

$ >file

$ ls -l file
-rw-rw-r-- 1 mparson mparson 0 Jan  3 16:46 file

A more likely use case is to truncate a log file then HUP syslogd.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From dave at horsfall.org  Sat Jan  4 09:32:15 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 4 Jan 2020 10:32:15 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1inSly-4mJ-00@marmaro.de>
References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de>
Message-ID: <alpine.BSF.2.21.9999.2001041029450.40155@aneurin.horsfall.org>

On Fri, 3 Jan 2020, markus schnalke wrote:

> Especially I'd like to know since when and why ``>file'' is a full 
> command? Was it clever design or by accident?

I/O redirection occurs before command execution (in this case, the null
command).

First, it creates (or truncates) the file, then runs the command; oh, it's 
the null command...

-- Dave

From mascheck at in-ulm.de  Sat Jan  4 10:53:50 2020
From: mascheck at in-ulm.de (Sven Mascheck)
Date: Sat, 4 Jan 2020 01:53:50 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1inQaG-3N3-00@marmaro.de>
References: <1inMKv-0Km-00@marmaro.de>
 <20200103140055.XB8iT%steffen@sdaoden.eu>
 <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com>
 <1inQaG-3N3-00@marmaro.de>
Message-ID: <20200104005350.GA156384@lisa.in-ulm.de>

On Fri, Jan 03, 2020 at 06:18:00PM +0100, markus schnalke wrote:
> [2020-01-03 11:03] "Brian Zick" <brian at zick.io>

> > I'm curious to know if you have a script you used to prove these correct?
> 
> We have to wait for Sven Mascheck to answer this question. He tested
> the different shells.

I guess Brian meant Steffen. I have no idea what Steffen meant with "proved
correct".

(and I believe Gunnar was not motivated to guarantee his heirloom port
to compete in production environments against modern shell variants with
continued maintenance, yet tried hard that time to find and fix as many bugs
as possible; I tried to help him a little bit that time. Just consider how
much still had been fixed by Sun even after their SVR4 sh. more corner case
bugs to be expected...)

BTW, I just typed ":|>file; echo $?" in a running shell and I was
particularly interested in the early Bourne shell variants. Unfortunately,
I was not able yet to check why the 7thEd sh yields SIGPIPE.

And ":|>>" (append) was just motivated by system call tracing (resulting in
less file IO), while I tried to find out what was happening at all, before
you pointed me to the solution "simple command".

Like you I'm interested in the possible motivations for a redirection to be
a simple command. Thus Warner and Michael really have a point about using
plain redirection only, or in connection with exec, respectively.

Sven


From doug at cs.dartmouth.edu  Sat Jan  4 12:58:56 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 03 Jan 2020 21:58:56 -0500
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>

> I'm interested in the possible motivations for a redirection to be
> a simple command.

I use it to truncate a file to zero length.
Or to create (an empty) file.

Doug

From athornton at gmail.com  Sat Jan  4 15:12:21 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 3 Jan 2020 22:12:21 -0700
Subject: [TUHS] Some new text adventure stuff for 2.11BSD
Message-ID: <CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA@mail.gmail.com>

I'm having a party on Saturday January 11 (and if any of you are in Tucson,
or want to come to Tucson for it, you're invited; email me for the address
and time).

Although the party is Elvis-themed, it's really about boardgaming and
classic videogaming.

So I kind of wanted to put a general-purpose Z-machine interpreter on my
PiDP-11, so that people could play Infocom (and community) games on a real
terminal.

Turns out there wasn't really one, so I ported the venerable ZIP (which I
have renamed "zterp" for obvious reasons) to 2.11BSD on the PDP-11, and I
also wrote a little utility I call "tmenu" to take a directory (and an
optional command applying to files in the directory) and make a numbered
menu, so that my guests who are not familiar with Actual Bourne Shell can
play games too.

These things are at:

https://github.com/athornton/pdp11-zterp

and

https://github.com/athornton/pdp11-tmenu/

Both are K&R C, and compile with the 2.11BSD system C compiler.

My biggest disappointment is that the memory map of Trinity, my favorite
Infocom game, is weird and even though it's only a V5 game, I can't
allocate enough memory to start it.  Other than that, V5 and below seem to
work mostly fine; V8 is in theory supported but no game that I've tried has
little enough low memory that I can malloc() it using C on 2.11BSD.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200103/0f856086/attachment.html>

From meillo at marmaro.de  Sat Jan  4 20:07:18 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 04 Jan 2020 11:07:18 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
Message-ID: <1ingL0-5g6-00@marmaro.de>

Hoi.

[2020-01-03 21:58] Doug McIlroy <doug at cs.dartmouth.edu>
>
> > I'm interested in the possible motivations for a redirection to be
> > a simple command.
> 
> I use it to truncate a file to zero length.
> Or to create (an empty) file.

Thanks for the replies.

My question was not about the use cases for ``>file'' but *why*
it was made a simple command. Let me explain:

One creates an empty file or truncates a file with:

	>file

why not with:

	:>file
?

To me it looks to be the more sensible ... more regular way.

IO redirections for the shell itself could be made with:

	exec >file 5>&

no matter if ``>file'' is a simple command or not. Because of
``exec'' the line is valid syntax (although the grammer probably
was retro-fitted), and the manpages (mksh, bash, heirloom sh) all
document exec without a command as a separate case (and the code
probably handles it as a separate case as well), thus nothing is
gained here from making ``>file'' a simple command.

This is what wonder about: Why make ``>file'' a simple command,
when -- as far as I can currently see -- there is no reason to do
so, as all uses could have been achieved in more regular ways as
well?

So, was it rather by accident and it settled or is there something
I don't see yet? Came `:' later in development, for instance, or
was it special in a way that it couldn't be used to create and
truncate files? Or is there even some clever design that I haven't
understood yet? Are there use cases that can only be achieved with
``>file'' but not with ``:>file''?


meillo

From bqt at softjar.se  Sat Jan  4 19:59:44 2020
From: bqt at softjar.se (Johnny Billquist)
Date: Sat, 4 Jan 2020 10:59:44 +0100
Subject: [TUHS] [PiDP-11] Some new text adventure stuff for 2.11BSD
In-Reply-To: <CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA@mail.gmail.com>
References: <CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA@mail.gmail.com>
Message-ID: <092a1ce7-8719-8282-0363-f3da62ea02b7@softjar.se>

Interesting. Trinity works fine under ZEMU.

So ZIP must be rather a hog...

V8 games that I've played under ZEMU:
BALLERINA
DREAMHOLDER
HEROINE
VIOLET

   Johnny

On 2020-01-04 06:12, Adam Thornton wrote:
> I'm having a party on Saturday January 11 (and if any of you are in 
> Tucson, or want to come to Tucson for it, you're invited; email me for 
> the address and time).
> 
> Although the party is Elvis-themed, it's really about boardgaming and 
> classic videogaming.
> 
> So I kind of wanted to put a general-purpose Z-machine interpreter on my 
> PiDP-11, so that people could play Infocom (and community) games on a 
> real terminal.
> 
> Turns out there wasn't really one, so I ported the venerable ZIP (which 
> I have renamed "zterp" for obvious reasons) to 2.11BSD on the PDP-11, 
> and I also wrote a little utility I call "tmenu" to take a directory 
> (and an optional command applying to files in the directory) and make a 
> numbered menu, so that my guests who are not familiar with Actual Bourne 
> Shell can play games too.
> 
> These things are at:
> 
> https://github.com/athornton/pdp11-zterp
> 
> and
> 
> https://github.com/athornton/pdp11-tmenu/
> 
> Both are K&R C, and compile with the 2.11BSD system C compiler.
> 
> My biggest disappointment is that the memory map of Trinity, my favorite 
> Infocom game, is weird and even though it's only a V5 game, I can't 
> allocate enough memory to start it.  Other than that, V5 and below seem 
> to work mostly fine; V8 is in theory supported but no game that I've 
> tried has little enough low memory that I can malloc() it using C on 
> 2.11BSD.
> 
> Adam
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to pidp-11+unsubscribe at googlegroups.com 
> <mailto:pidp-11+unsubscribe at googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pidp-11/CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA%40mail.gmail.com 
> <https://groups.google.com/d/msgid/pidp-11/CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

From fuz at fuz.su  Sat Jan  4 21:47:50 2020
From: fuz at fuz.su (Robert Clausecker)
Date: Sat, 4 Jan 2020 12:47:50 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1ingL0-5g6-00@marmaro.de>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
Message-ID: <20200104114750.GA30769@fuz.su>

Good morning!

On Sat, Jan 04, 2020 at 11:07:18AM +0100, markus schnalke wrote:
> One creates an empty file or truncates a file with:
> 
> 	>file
> 
> why not with:
> 
> 	:>file
> ?
> 
> To me it looks to be the more sensible ... more regular way.
> 
> IO redirections for the shell itself could be made with:
> 
> 	exec >file 5>&
> 
> no matter if ``>file'' is a simple command or not. Because of
> ``exec'' the line is valid syntax (although the grammer probably
> was retro-fitted), and the manpages (mksh, bash, heirloom sh) all
> document exec without a command as a separate case (and the code
> probably handles it as a separate case as well), thus nothing is
> gained here from making ``>file'' a simple command.
> 
> This is what wonder about: Why make ``>file'' a simple command,
> when -- as far as I can currently see -- there is no reason to do
> so, as all uses could have been achieved in more regular ways as
> well?

I think the key reason is that the shell does not build an AST from
the command you type, instead executing the phrases it encounters as it
sees them.  So when the shell sees ">file", it opens "file" for writing
in preparation of the rest of the command.  If no command comes, the
line is handled the same way as an empty one and the redirections are
discarded.  The shell could print an error here, but avoiding the side
effect of opening "file" for lines just consisting of redirects would be
difficult.  But then, why should it print an error?  The behaviour is
not harmful after all and I'd say that nobody really thought about this
being a thing when the shell was originally written.

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From doug at cs.dartmouth.edu  Sun Jan  5 00:23:39 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 04 Jan 2020 09:23:39 -0500
Subject: [TUHS] GNUism in groff tests, was: pic anomalies
Message-ID: <202001041423.004ENd7b004197@tahoe.cs.Dartmouth.EDU>

> I was always sad that the development of C that became Alef never got off
> the ground.

It eventuated in Go, which is definitely aloft, and responds
to Mike Bianchi's specific desires. Go also has a library
ecosystem, which C does not.

With its clean parallelism, Go may be suitable for handling
the complexity of whole-paragraph typsetting in the face
of unexpected traps, line-length changes, etc.

Doug

From steffen at sdaoden.eu  Sun Jan  5 06:41:17 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 04 Jan 2020 21:41:17 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <20200104005350.GA156384@lisa.in-ulm.de>
References: <1inMKv-0Km-00@marmaro.de>
 <20200103140055.XB8iT%steffen@sdaoden.eu>
 <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com>
 <1inQaG-3N3-00@marmaro.de> <20200104005350.GA156384@lisa.in-ulm.de>
Message-ID: <20200104204117.5Oo-9%steffen@sdaoden.eu>

Sven Mascheck via TUHS wrote in <20200104005350.GA156384 at lisa.in-ulm.de>:
 |On Fri, Jan 03, 2020 at 06:18:00PM +0100, markus schnalke wrote:
 |> [2020-01-03 11:03] "Brian Zick" <brian at zick.io>
 |>> I'm curious to know if you have a script you used to prove these \
 |>> correct?
 |> 
 |> We have to wait for Sven Mascheck to answer this question. He tested
 |> the different shells.
 |
 |I guess Brian meant Steffen. I have no idea what Steffen meant with "proved
 |correct".

It was a citation, maybe too sloppy.

 |(and I believe Gunnar was not motivated to guarantee his heirloom port
 |to compete in production environments against modern shell variants with
 |continued maintenance, yet tried hard that time to find and fix as \
 |many bugs
 |as possible; I tried to help him a little bit that time. Just consider how

That is what "is flowing out behind me", overall.

 |much still had been fixed by Sun even after their SVR4 sh. more corner case
 |bugs to be expected...)

I did not throw doubt on this.  I think he achieved a lot in
Heirloom tools and especially roff in only four years i think,
starting in 2004.  The sh has this ": > FILE" bug, which sometimes
shows up.

--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 dave at horsfall.org  Sun Jan  5 07:02:08 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Jan 2020 08:02:08 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1ingL0-5g6-00@marmaro.de>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
Message-ID: <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>

On Sat, 4 Jan 2020, markus schnalke wrote:

> My question was not about the use cases for ``>file'' but *why* it was 
> made a simple command. Let me explain:
>
> One creates an empty file or truncates a file with:
>
> 	>file
>
> why not with:
>
> 	:>file
> ?
>
> To me it looks to be the more sensible ... more regular way.

The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an actual 
internal Shell command) when "" (the null command) will do the job?

I guess only the Bell Labs bods here can answer this.

-- Dave

From dave at horsfall.org  Sun Jan  5 07:11:18 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Jan 2020 08:11:18 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>

On Sun, 5 Jan 2020, Dave Horsfall wrote:

> The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an 
> actual internal Shell command) when "" (the null command) will do the 
> job?

Also, remember that ":" was also used as a comment, before "#" was used.

-- Dave

From imp at bsdimp.com  Sun Jan  5 07:39:12 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 4 Jan 2020 15:39:12 -0600
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
Message-ID: <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>

On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 5 Jan 2020, Dave Horsfall wrote:
>
> > The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an
> > actual internal Shell command) when "" (the null command) will do the
> > job?
>
> Also, remember that ":" was also used as a comment, before "#" was used.
>

I thought it was a null label for a goto target... :)

Warner

-- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200104/8269c0cb/attachment.html>

From jon at fourwinds.com  Sun Jan  5 07:06:09 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 04 Jan 2020 13:06:09 -0800
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
Message-ID: <202001042106.004L69C1448350@darkstar.fourwinds.com>

Dave Horsfall writes:
> On Sat, 4 Jan 2020, markus schnalke wrote:
>
> > My question was not about the use cases for ``>file'' but *why* it was 
> > made a simple command. Let me explain:
> >
> > One creates an empty file or truncates a file with:
> >
> > 	>file
> >
> > why not with:
> >
> > 	:>file
> > ?
> >
> > To me it looks to be the more sensible ... more regular way.
>
> The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an actual 
> internal Shell command) when "" (the null command) will do the job?
>
> I guess only the Bell Labs bods here can answer this.
>
> -- Dave

Don't know if Steve Bourne is on this list, but he's been a great source
of information when I've had questions about why the shell did things the
way it did.

Jon

From terry at jon.es  Sun Jan  5 08:19:07 2020
From: terry at jon.es (Terry Jones)
Date: Sat, 4 Jan 2020 23:19:07 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
Message-ID: <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>

Was : actually designed for commenting?  If so, at what point did it become
a command that always returns zero exit status?  Was it always built-in, or
did it originally have a separate filesystem existence (like "[")? Python
has a useful "pass" command, but : is much nicer because you can "comment"
out a single command in (e.g.) an if/then and it remains syntactically
valid and executable. I find it very elegant.

Terry


On Sat, Jan 4, 2020 at 10:40 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sun, 5 Jan 2020, Dave Horsfall wrote:
>>
>> > The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an
>> > actual internal Shell command) when "" (the null command) will do the
>> > job?
>>
>> Also, remember that ":" was also used as a comment, before "#" was used.
>>
>
> I thought it was a null label for a goto target... :)
>
> Warner
>
> -- Dave
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200104/99413523/attachment.html>

From dave at horsfall.org  Sun Jan  5 08:22:40 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Jan 2020 09:22:40 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2001050919470.40155@aneurin.horsfall.org>

On Sat, 4 Jan 2020, Warner Losh wrote:

>       Also, remember that ":" was also used as a comment, before "#"
>       was used.
> 
> I thought it was a null label for a goto target... :)

Yes, I'd forgotten that...  The Shell, although simple in concept, was
really quite powerful if you knew how to use it.

-- Dave

From chet.ramey at case.edu  Sun Jan  5 08:33:56 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sat, 4 Jan 2020 17:33:56 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
Message-ID: <df91940b-737d-1c7c-635a-207615842a77@case.edu>

On 1/4/20 5:19 PM, Terry Jones wrote:
> Was : actually designed for commenting?  If so, at what point did it become
> a command that always returns zero exit status?  Was it always built-in, or
> did it originally have a separate filesystem existence (like "[")? Python
> has a useful "pass" command, but : is much nicer because you can "comment"
> out a single command in (e.g.) an if/then and it remains syntactically
> valid and executable. I find it very elegant.

It's elegant until you forget that `:' continues to process redirections.

-- 
``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 chet.ramey at case.edu  Sun Jan  5 08:31:31 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sat, 4 Jan 2020 17:31:31 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <20200104114750.GA30769@fuz.su>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de> <20200104114750.GA30769@fuz.su>
Message-ID: <ba1e897d-c474-2425-b5dd-29f4913abe1f@case.edu>

On 1/4/20 6:47 AM, Robert Clausecker wrote:

>> This is what wonder about: Why make ``>file'' a simple command,
>> when -- as far as I can currently see -- there is no reason to do
>> so, as all uses could have been achieved in more regular ways as
>> well?

I'm going to answer in terms of the Bourne shell and its successors.

> I think the key reason is that the shell does not build an AST from
> the command you type, instead executing the phrases it encounters as it
> sees them.  

This is false.

> So when the shell sees ">file", it opens "file" for writing
> in preparation of the rest of the command.  

Also not correct, at least if you mean opening it before completing the
parse.

> If no command comes, the
> line is handled the same way as an empty one and the redirections are
> discarded.  

Not really. The shell parses the line into a list of words. Those words
make up a simple command, since none of the words were identified as a
reserved word, and so are not the first word of a compound command. It's
the default case, basically.

The POSIX standard gives a pretty good summary of what happens next:
the redirections get separated out and the rest of the words are
expanded.

You already have to deal with the expansions returning nothing, since the
words could all be null variable expansions, so the case where there are
no words besides redirections and assignment statements isn't that much
different.

> The shell could print an error here, 

It could, but Bourne chose not to.

> but avoiding the side
> effect of opening "file" for lines just consisting of redirects would be
> difficult.  But then, why should it print an error?  The behaviour is
> not harmful after all 

This is true. There aren't any other cases where the shell makes a null
expansion an error without being directly asked, so it would not have
made sense to make a command consisting entirely of words that expand to
null an error. There's no good reason to treat a null command differently
from that case.

> and I'd say that nobody really thought about this
> being a thing when the shell was originally written.

On the contrary, I think Bourne made a conscious choice to handle
redirections `separately' from simple command expansion and execution, and
a conscious choice to continue to process redirections (in a subshell, as
if the shell had forked to execute a non-builtin) when word expansion
resulted in no words.

It's the `exec' case with redirections that I think was the special case,
since Bourne's (v7) shell didn't allow redirections with builtins at all.

Chet

-- 
``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 meillo at marmaro.de  Sun Jan  5 08:44:35 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 04 Jan 2020 23:44:35 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
Message-ID: <1ins9r-4KA-00@marmaro.de>

Hoi.

[2020-01-04 23:19] Terry Jones <terry at jon.es>
>
> Was : actually designed for commenting?

Hardly, because who would want comments to have side effects:

	: don't do this

Or this:

	: ignored; echo executed

Or this dangerously ``outcommented'' line:

	: test ... && rm file

!

Using : for comments is only possible as the command does nothing
and ignores its arguments ... but the shell parses the arguments
as for every other command ... and executes stuff in the line that
are no arguments to :.

In case of #, the rest of the line is truly ignored, as comments
should be like.


> but : is much nicer because you can "comment" out a
> single command in (e.g.) an if/then and it remains syntactically valid and
> executable. I find it very elegant.

Can you please give an example for me to understand what you mean
by that?


meillo

From terry at jon.es  Sun Jan  5 09:01:42 2020
From: terry at jon.es (Terry Jones)
Date: Sun, 5 Jan 2020 00:01:42 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <1ins9r-4KA-00@marmaro.de>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <1ins9r-4KA-00@marmaro.de>
Message-ID: <CACqnu4V_ExohWSRLrXSyb_jA5_4_U3A7x-jRk5h2zPjz6ic6uw@mail.gmail.com>

On Sat, Jan 4, 2020 at 11:45 PM markus schnalke <meillo at marmaro.de> wrote:

>
> > but : is much nicer because you can "comment" out a
> > single command in (e.g.) an if/then and it remains syntactically valid
> and
> > executable. I find it very elegant.
>
> Can you please give an example for me to understand what you mean
> by that?
>

While developing, I frequently have some code like:

if test -f somefile
then
    cmd1
    cmd2
else
    echo somefile is missing
fi

I have the "else" clause because I initially want to explicitly see some
output in that case. A bit later if I temporarily don't want the output
(but want to keep the else and the echo line around) I can just put a colon
before the echo. You can't do that with a # because you get a syntax error.
And if you wanted to use # you'd then have to put in some other do-nothing
line (maybe a : by itself) to keep valid syntax.  In a situation like this
I will eventually end up deleting the echo line and the preceding else, but
during development I like being able to use : in this way.

Terry


>
> meillo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200105/1df13061/attachment.html>

From dave at horsfall.org  Sun Jan  5 09:53:47 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Jan 2020 10:53:47 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <df91940b-737d-1c7c-635a-207615842a77@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
Message-ID: <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>

On Sat, 4 Jan 2020, Chet Ramey wrote:

> It's elegant until you forget that `:' continues to process redirections.

So just keep remembering that it's an actual command :-)

Which reminds me: which Shell introduced "#" as a true comment?

Hmmm, not quite true; only the C-Shell says "#: Command not found" so it 
only works in a script; odd...

Then again, no-one in their right mind uses "csh" :-)

-- Dave

From andreas.kahari at abc.se  Sun Jan  5 10:04:27 2020
From: andreas.kahari at abc.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Sun, 5 Jan 2020 01:04:27 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
Message-ID: <20200105000427.GA67963@pooh.prefix.duckdns.org>

On Sun, Jan 05, 2020 at 10:53:47AM +1100, Dave Horsfall wrote:
> On Sat, 4 Jan 2020, Chet Ramey wrote:
> 
> > It's elegant until you forget that `:' continues to process redirections.
> 
> So just keep remembering that it's an actual command :-)
> 
> Which reminds me: which Shell introduced "#" as a true comment?
> 
> Hmmm, not quite true; only the C-Shell says "#: Command not found" so it
> only works in a script; odd...
> 
> Then again, no-one in their right mind uses "csh" :-)
> 
> -- Dave

In bash (turning off interactive_comments):

	$ shopt -u interactive_comments
	$ echo hello # world
	hello # world
	$ # oh
	bash: #: command not found


In zsh (by default):

	$ echo hello # world
	hello # world
	$ # oh
	zsh: command not found: #

zsh is the fun one though (allows setting the comment character):

	$ histchars[3]='@'
	$ echo hello @ world
	hello @ world
	$ setopt INTERACTIVE_COMMENTS
	$ echo hello @ world
	hello
	$ @ oh, a comment
	$


-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

From tuhs at eric.allman.name  Sun Jan  5 10:03:26 2020
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 4 Jan 2020 16:03:26 -0800
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001042106.004L69C1448350@darkstar.fourwinds.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <202001042106.004L69C1448350@darkstar.fourwinds.com>
Message-ID: <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>

I contacted Steve --- he is on the list, and says he'll weigh in.

eric


On 2020-01-04 13:06, Jon Steinhart wrote:
> Dave Horsfall writes:
>> On Sat, 4 Jan 2020, markus schnalke wrote:
>>
>>> My question was not about the use cases for ``>file'' but *why* it was
>>> made a simple command. Let me explain:
>>>
>>> One creates an empty file or truncates a file with:
>>>
>>> 	>file
>>>
>>> why not with:
>>>
>>> 	:>file
>>> ?
>>>
>>> To me it looks to be the more sensible ... more regular way.
>>
>> The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an actual
>> internal Shell command) when "" (the null command) will do the job?
>>
>> I guess only the Bell Labs bods here can answer this.
>>
>> -- Dave
> 
> Don't know if Steve Bourne is on this list, but he's been a great source
> of information when I've had questions about why the shell did things the
> way it did.
> 
> Jon
> 

From athornton at gmail.com  Sun Jan  5 11:49:46 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 4 Jan 2020 18:49:46 -0700
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <202001042106.004L69C1448350@darkstar.fourwinds.com>
 <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>
Message-ID: <CAP2nic03vxZ-G=WBPVuakVKikZxa8CqUM=xNHsrBC-_enj+Lpw@mail.gmail.com>

v7 Bourne shell does not appear to treat '#' as a comment.

I've built termlib and curses for v7 and am now trying to find a small
screen editor.  I was trying se, but the version I have ships as a shell
archive, and it doesn't actually unpack on v7, in part because of the
comments.

v7 is a target in Jove's Ovmakefile, so that's what I'm trying now.
Slow-pasting uuencoded files into the terminal is gross, but efficacious....

Adam

On Sat, Jan 4, 2020 at 5:48 PM Eric Allman <tuhs at eric.allman.name> wrote:

> I contacted Steve --- he is on the list, and says he'll weigh in.
>
> eric
>
>
> On 2020-01-04 13:06, Jon Steinhart wrote:
> > Dave Horsfall writes:
> >> On Sat, 4 Jan 2020, markus schnalke wrote:
> >>
> >>> My question was not about the use cases for ``>file'' but *why* it was
> >>> made a simple command. Let me explain:
> >>>
> >>> One creates an empty file or truncates a file with:
> >>>
> >>>     >file
> >>>
> >>> why not with:
> >>>
> >>>     :>file
> >>> ?
> >>>
> >>> To me it looks to be the more sensible ... more regular way.
> >>
> >> The Unix philosophy, perhaps i.e. keep it simple?  Why have ":" (an
> actual
> >> internal Shell command) when "" (the null command) will do the job?
> >>
> >> I guess only the Bell Labs bods here can answer this.
> >>
> >> -- Dave
> >
> > Don't know if Steve Bourne is on this list, but he's been a great source
> > of information when I've had questions about why the shell did things the
> > way it did.
> >
> > Jon
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200104/596b4258/attachment-0001.html>

From chet.ramey at case.edu  Sun Jan  5 12:41:59 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sat, 4 Jan 2020 21:41:59 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
Message-ID: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>

On 1/4/20 6:53 PM, Dave Horsfall wrote:
> On Sat, 4 Jan 2020, Chet Ramey wrote:
> 
>> It's elegant until you forget that `:' continues to process redirections.
> 
> So just keep remembering that it's an actual command :-)
> 
> Which reminds me: which Shell introduced "#" as a true comment?

Define "true comment." The v7 shell had `#' as the comment character, but
it only worked when in non-interactive shells. I think it was the Sys III
shell that made it work when the shell was interactive.

This is, incidentally, why bash has the `interactive_comments' option,
which I saw in another message. BSD, which most of the GNU developers were
using at the (pre-POSIX) time, used the v7 shell and didn't have
interactive comments. When a sufficiently-advanced POSIX draft required
them, we added it.

-- 
``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 chet.ramey at case.edu  Sun Jan  5 12:44:48 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sat, 4 Jan 2020 21:44:48 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CAP2nic03vxZ-G=WBPVuakVKikZxa8CqUM=xNHsrBC-_enj+Lpw@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <202001042106.004L69C1448350@darkstar.fourwinds.com>
 <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>
 <CAP2nic03vxZ-G=WBPVuakVKikZxa8CqUM=xNHsrBC-_enj+Lpw@mail.gmail.com>
Message-ID: <52886e4e-2987-c309-053a-d229e1f33831@case.edu>

On 1/4/20 8:49 PM, Adam Thornton wrote:
> v7 Bourne shell does not appear to treat '#' as a comment.

It does, when the shell is not interactive and reading input from a script,
pipe, or input redirection.

-- 
``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 brantley at coraid.com  Sun Jan  5 18:15:02 2020
From: brantley at coraid.com (Brantley Coile)
Date: Sun, 5 Jan 2020 08:15:02 +0000
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <52886e4e-2987-c309-053a-d229e1f33831@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <202001042106.004L69C1448350@darkstar.fourwinds.com>
 <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>
 <CAP2nic03vxZ-G=WBPVuakVKikZxa8CqUM=xNHsrBC-_enj+Lpw@mail.gmail.com>
 <52886e4e-2987-c309-053a-d229e1f33831@case.edu>
Message-ID: <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com>

V7 indeed did not have "#" as a comment. Programs use the ":" command for that, and was careful of what was in the comment. The ":" command was called SYSNULL in the source. 
    Later versions of Steve's shell had COMCHAR defined to be a "#" and tested for that symbol in word(), eating up all the characters until it got to a newline. The version of Seventh Edition I used to carry around and embed in things had that mod. My original Seventh did not.


> On Jan 4, 2020, at 9:44 PM, Chet Ramey <chet.ramey at case.edu> wrote:
> 
> On 1/4/20 8:49 PM, Adam Thornton wrote:
>> v7 Bourne shell does not appear to treat '#' as a comment.
> 
> It does, when the shell is not interactive and reading input from a script,
> pipe, or input redirection.
> 
> -- 
> ``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 mascheck at in-ulm.de  Sun Jan  5 23:45:23 2020
From: mascheck at in-ulm.de (Sven Mascheck)
Date: Sun, 5 Jan 2020 14:45:23 +0100
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
Message-ID: <20200105134523.GA417916@lisa.in-ulm.de>

On Sat, Jan 04, 2020 at 09:41:59PM -0500, Chet Ramey wrote:
> On 1/4/20 6:53 PM, Dave Horsfall wrote:

> > Which reminds me: which Shell introduced "#" as a true comment?
> 
> Define "true comment." The v7 shell had `#' as the comment character, but
> it only worked when in non-interactive shells. I think it was the Sys III
> shell that made it work when the shell was interactive.
> 
> This is, incidentally, why bash has the `interactive_comments' option,
> which I saw in another message. BSD, which most of the GNU developers were
> using at the (pre-POSIX) time, used the v7 shell and didn't have
> interactive comments. When a sufficiently-advanced POSIX draft required
> them, we added it.

concerning "interactive" I think instead of the V7 sh you rather have
the BSD sh in mind here.

V7 sh didn't know # at all.  At ATT it came with SysIII (both modes).
And keep in mind, stty erase defaulted to # on V7, even until SySV (and 3BSD),
and this character wouldn't have been handy anyway. 4+BSD changed this. 

4.1BSD implemented #, and 4.3 BSD changed it to "non-interactive only".

(And all this is not to be confused with the # hack to exec to csh on 3+BSD,
 only if it's the first character in a script.)


BTW, an academic yet funny example of : side effects is this
: `echo output 1>&2`

Sven


From chet.ramey at case.edu  Mon Jan  6 01:16:44 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 5 Jan 2020 10:16:44 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <202001042106.004L69C1448350@darkstar.fourwinds.com>
 <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com>
 <CAP2nic03vxZ-G=WBPVuakVKikZxa8CqUM=xNHsrBC-_enj+Lpw@mail.gmail.com>
 <52886e4e-2987-c309-053a-d229e1f33831@case.edu>
 <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com>
Message-ID: <f7893585-038e-409a-a9fa-430ea59c0a73@case.edu>

On 1/5/20 3:15 AM, Brantley Coile wrote:
> V7 indeed did not have "#" as a comment. Programs use the ":" command for that, and was careful of what was in the comment. The ":" command was called SYSNULL in the source. 
>     Later versions of Steve's shell had COMCHAR defined to be a "#" and tested for that symbol in word(), eating up all the characters until it got to a newline. The version of Seventh Edition I used to carry around and embed in things had that mod. My original Seventh did not.

I think the 7th edition shell I have must have those changes, since it
definitely understands `#' comments.

-- 
``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 chet.ramey at case.edu  Mon Jan  6 01:18:17 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 5 Jan 2020 10:18:17 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <20200105134523.GA417916@lisa.in-ulm.de>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <20200105134523.GA417916@lisa.in-ulm.de>
Message-ID: <9cc26d26-7dfc-002e-79e3-0fc45e4d9fd6@case.edu>

On 1/5/20 8:45 AM, Sven Mascheck via TUHS wrote:

> 4.1BSD implemented #, and 4.3 BSD changed it to "non-interactive only".

Yes, 4.3 (or SunOS) is what most of us were using at the time.


-- 
``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 dave at horsfall.org  Mon Jan  6 07:21:11 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 6 Jan 2020 08:21:11 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
Message-ID: <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>

On Sat, 4 Jan 2020, Chet Ramey wrote:

>> Which reminds me: which Shell introduced "#" as a true comment?
>
> Define "true comment." The v7 shell had `#' as the comment character, but
> it only worked when in non-interactive shells. I think it was the Sys III
> shell that made it work when the shell was interactive.

Yes, that's what I meant.

> This is, incidentally, why bash has the `interactive_comments' option,
> which I saw in another message. BSD, which most of the GNU developers were
> using at the (pre-POSIX) time, used the v7 shell and didn't have
> interactive comments. When a sufficiently-advanced POSIX draft required
> them, we added it.

I never did catch up with all the options on the various shells; I just
stick with the defaults in general.  Eg:

     aneurin% man bash | wc -l
 	5947

Life's too short...

-- Dave

From tuhs at cuzuco.com  Mon Jan  6 13:24:06 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Sun, 5 Jan 2020 22:24:06 -0500 (EST)
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001060324.0063O6lt010608@cuzuco.com>

More than you ever wanted to know about #
The first shell to use it as a comment was csh(1), Bill Joy did this.
This was also pre #! in the kernel so the shell had to exec scripts,
not the kernel. This had traditionally been done after the exec() failed
then shell ould run "sh argv[0]", but with two shells this was now a problem.
So csh would look at the first line of the script and if it was a #\n
it would exec csh on it if not it would exec sh(1) on it. This was check
was also placed into to BSD's (not v7 nor att's) bourne shell so it could
run csh scripts as well.

However this was not the first use of # as a comment character. That award
goes to Brian Kernighan's ratfor(1) (rational fortran) compiler in 1974-75.
Then Feldman used in make(1) in 1976, followed by Kernighan's m4(1), learn(1)
and most famously awk(1) in 1977

Bourne shell, written around 1976, eventualy picked this up later on but after
the initial v7 release.  And as some noted the : was kind of a comment, it
was a command that did an exit(0) orginally for labels for Thompson's
shell's goto command. The : command was eventually hard linked to the
true(1) command

Remember # was hard to type on teletypes as that was the erase character, so
to enter it, you needed to type \#
(# as erase and @ as line kill came from multics btw)
It was so hard to type that the orignal assember based on DEC PAL-11R,
that addressing syntax changed @ to * and # to $.
In DEC it would be--
MOV @X, R0;
In UNIX asm it became --
mov *x, r0
So this is also why C pointers use * notation.

-Brian

> From: Dave Horsfall dave at horsfall.org
>
>On Sat, 4 Jan 2020, Chet Ramey wrote:
>
>>> Which reminds me: which Shell introduced "#" as a true comment?
>>
>> Define "true comment." The v7 shell had `#' as the comment character, but
>> it only worked when in non-interactive shells. I think it was the Sys III
>> shell that made it work when the shell was interactive.
>
>Yes, that's what I meant.
>
>> This is, incidentally, why bash has the `interactive_comments' option,
>> which I saw in another message. BSD, which most of the GNU developers were
>> using at the (pre-POSIX) time, used the v7 shell and didn't have
>> interactive comments. When a sufficiently-advanced POSIX draft required
>> them, we added it.
>
>I never did catch up with all the options on the various shells; I just
>stick with the defaults in general.  Eg:
>
>     aneurin% man bash | wc -l
>       5947
>
>Life's too short...
>
>-- Dave

From will.senn at gmail.com  Mon Jan  6 16:13:45 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 00:13:45 -0600
Subject: [TUHS] wump.c for v6
Message-ID: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>

Hi,

Does the wump.c source exist for v6? The game's in the distribution and 
so is the man page, but I can't find the source. I see it's in v7, but I 
don't know the provenance of the game source, hence the question.

I find the following interesting... in the v7 source it says:

/*
  *      wumpus
  *      stolen from PCC Vol 2 No 1
  */

But it's actually from PCC Vol 2 No 2 (Nov 1973):
https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-n2-acc.pdf

and the basic source is given in the games issue:
https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-games-acc.pdf

The correct volume is noted in the v6 manpage:

This program is based on one described  in  2  (No-
vember 1973).  It will never replace Space War.

and in the v7 manpage:

This program is based on one described in People's Computer
      Company, 2, 2 (November 1973).

BUGS
      It will never replace Space War.

I'm curious if it was ported to c for v6, or if it was basic?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/42bdea4c/attachment.html>

From tuhs at cuzuco.com  Mon Jan  6 16:30:07 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Mon, 6 Jan 2020 01:30:07 -0500 (EST)
Subject: [TUHS] # (was Re: sh: cmd | >file)
Message-ID: <202001060630.0066U7U7023760@cuzuco.com>

A bit more on this.
csh(1) was wrtten around 1978 and yes # as a comment was only for
scrtipts, think it was why would you need to comment interactively?
And the # as an addition to be a comment in Bourne shell had to be around 1980
as that is when Dennis Ritchie added #! to exec(2) in the kernel. From this
point on this forced all UNIX scripting languages to use # as a comment as
it just exec'd the first string after the #! with the name of the current
file being exec'd as the single argument. So things like perl(1) and python(1)
had to use # if they wanted the #! mechanism to work for them too.

So this worked great for shell scripts, it didn't work for awk(1) nor sed(1)
nor s(1)(that is R(1) now) scripts (all needed a -f for input from file)
nor dc(1) scripts as dc had no comment character.
While Research UNIX got !# in 1980, this was after the 7th Edition release
and the 8th Edition wasn't released until 1985), BSD got it around 1982-83,
and System V didn't implement it until 1988. Eventully #! was extented
so #!/usr/bin/awk -f would work.

Also Bill Joy was the first to use # as a comment character in an /etc config
file for his /etc/ttycap (which became /etc/termcap) for vi(1). Most configs
did not have a comment at all at that time, while /etc/master used a * as a
comment (SCCS used * as a comment too btw)

Also before you say wait! ALGOL uses # as comment and is older than
Kernighan' ratfor(1). This is a later addition. The original used the EBCDIC
cent sign character to start and another cent sign to end the comment
(i.e. programmer's two cents). If you were on an ASCII system this became
"co" (for comment) as the original ASCII does not have a cent sign

-Brian

From chet.ramey at case.edu  Mon Jan  6 23:53:29 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 6 Jan 2020 08:53:29 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
Message-ID: <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>

On 1/5/20 4:21 PM, Dave Horsfall wrote:
> On Sat, 4 Jan 2020, Chet Ramey wrote:
> 
>>> Which reminds me: which Shell introduced "#" as a true comment?
>>
>> Define "true comment." The v7 shell had `#' as the comment character, but
>> it only worked when in non-interactive shells. I think it was the Sys III
>> shell that made it work when the shell was interactive.
> 
> Yes, that's what I meant.

It was the Sys III shell; I have a v7 shell that's apparently not the
original.


> I never did catch up with all the options on the various shells; I just
> stick with the defaults in general.  Eg:
> 
>      aneurin% man bash | wc -l
>      5947

$ wc -l doc/bash.0
     6206 doc/bash.0

I still get reports that things are not documented in sufficient detail.


-- 
``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  Tue Jan  7 01:20:37 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 10:20:37 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
Message-ID: <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>

On Mon, Jan 6, 2020 at 1:14 AM Will Senn <will.senn at gmail.com> wrote:

> Does the wump.c source exist for v6? The game's in the distribution and so
> is the man page, but I can't find the source. I see it's in v7, but I don't
> know the provenance of the game source, hence the question.
>
Interesting question for someone like Doug, Steve or Ken.  I bet it is
pretty close, if not the same.   I notice the V7 version used printf and
getchar, but does not define stdio.h.  It also has a struct in it.  So by
the time of that version, printf existed as did structs both of which were
in the V6 C compiler (V6 did not have stdio, it had Mike Lesk's 'Portable
I/O Library' (iolib in the sources).

I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
if you did and compared it to an nm from V6 I bet they are darned close.


....
> I'm curious if it was ported to c for v6, or if it was basic?
>
I would guess B or C not basic.  The UNIX basic was primitive compared to
Darthmouth (or HP - which would become HP-2000 basic but that's a different
story).   Code from PCC (or later David Ahl's "101 Basic Computer Games"
<https://www.amazon.com/101-BASIC-Computer-Games-David/dp/B000CNZP5U/ref=smi_www_rco2_go_smi_3905707922>
)
would not work without extensive rewriting.  Something that small,
converting to B or C would have been similar effort so I would have
expected that to have been what happened.

Remember Edition X, particularly for the first few, was the status of the
disks in research at the time.  So there are a few cases of binaries in
some of the earlier editions being found in /usr/bin or the like and the
sources not there in the distribution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/ce2e3e5a/attachment.html>

From clemc at ccc.com  Tue Jan  7 01:24:46 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 10:24:46 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
Message-ID: <CAC20D2M5=UsQOBeb_BvSBg=X7s_6yior=DPNSdyyCqEHMJ7q6A@mail.gmail.com>

ah dyslexia....

>
>
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
> if you did and compared it to an nm from *V7* I bet they are darned close.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/5211bd44/attachment.html>

From brantley at coraid.com  Tue Jan  7 01:42:22 2020
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 6 Jan 2020 15:42:22 +0000
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
Message-ID: <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>

Seems the man page for bash is longer than Steve's original source:

ehg% pwd
/sys/editions/unix/7e/usr/src/cmd/sh
ehg% wc -l *.[ch] | tail -1
   4111 total

> On Jan 6, 2020, at 8:53 AM, Chet Ramey <chet.ramey at case.edu> wrote:
> 
> On 1/5/20 4:21 PM, Dave Horsfall wrote:
>> On Sat, 4 Jan 2020, Chet Ramey wrote:
>>>> Which reminds me: which Shell introduced "#" as a true comment?
>>> 
>>> Define "true comment." The v7 shell had `#' as the comment character, but
>>> it only worked when in non-interactive shells. I think it was the Sys III
>>> shell that made it work when the shell was interactive.
>> Yes, that's what I meant.
> 
> It was the Sys III shell; I have a v7 shell that's apparently not the
> original.
> 
> 
>> I never did catch up with all the options on the various shells; I just
>> stick with the defaults in general.  Eg:
>>     aneurin% man bash | wc -l
>>     5947
> 
> $ wc -l doc/bash.0
>    6206 doc/bash.0
> 
> I still get reports that things are not documented in sufficient detail.
> 
> 
> -- 
> ``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 rich.salz at gmail.com  Tue Jan  7 01:42:49 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 6 Jan 2020 10:42:49 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001060324.0063O6lt010608@cuzuco.com>
References: <202001060324.0063O6lt010608@cuzuco.com>
Message-ID: <CAFH29trQ3dEz+-Qnszrg4a_etsuDa_H7KZp-8k6ibu8Z44m9GQ@mail.gmail.com>

On Sun, Jan 5, 2020 at 10:42 PM Brian Walden <tuhs at cuzuco.com> wrote:

> not the kernel. This had traditionally been done after the exec() failed
> then shell ould run "sh argv[0]", but with two shells this was now a
> problem.
>

It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since
argv[-1] was altered.

I read somewhere, can't recall where, that Ken Thompson suggested "#!"
being added to the kernel during his sabbatical there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/d4d5b361/attachment.html>

From arnold at skeeve.com  Tue Jan  7 01:46:06 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 06 Jan 2020 08:46:06 -0700
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
Message-ID: <202001061546.006Fk6Fb012760@freefriends.org>

Brantley Coile <brantley at coraid.com> wrote:

> Seems the man page for bash is longer than Steve's original source:
>
> ehg% pwd
> /sys/editions/unix/7e/usr/src/cmd/sh
> ehg% wc -l *.[ch] | tail -1
>    4111 total

And Bash (40 years later) does correspondingly more than the V7 shell did.

I think these comparisons are a red herring.

Would anyone who uses Bash regularly, both interactively and
for scripting, really want to go back to using the V7 sh
for production work?

I certainly would not.

Arnold

From brantley at coraid.com  Tue Jan  7 01:45:14 2020
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 6 Jan 2020 15:45:14 +0000
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CAFH29trQ3dEz+-Qnszrg4a_etsuDa_H7KZp-8k6ibu8Z44m9GQ@mail.gmail.com>
References: <202001060324.0063O6lt010608@cuzuco.com>
 <CAFH29trQ3dEz+-Qnszrg4a_etsuDa_H7KZp-8k6ibu8Z44m9GQ@mail.gmail.com>
Message-ID: <4C62352C-A946-4ADB-BDE9-13B7C68D3493@coraid.com>

I suspect so he could run the Pascal P-machine. 

> On Jan 6, 2020, at 10:42 AM, Richard Salz <rich.salz at gmail.com> wrote:
> 
> 
> 
> On Sun, Jan 5, 2020 at 10:42 PM Brian Walden <tuhs at cuzuco.com> wrote:
> not the kernel. This had traditionally been done after the exec() failed
> then shell ould run "sh argv[0]", but with two shells this was now a problem.
> 
> It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since argv[-1] was altered.
> 
> I read somewhere, can't recall where, that Ken Thompson suggested "#!" being added to the kernel during his sabbatical there.
> 


From tuhs at cuzuco.com  Tue Jan  7 02:11:53 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Mon, 6 Jan 2020 11:11:53 -0500 (EST)
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001061612.006GBrAb018483@cuzuco.com>

Richard Salz wrote:
>> not the kernel. This had traditionally been done after the exec() failed
>> then shell ould run "sh argv[0]", but with two shells this was now a
>> problem.
>>
>
>It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since
>argv[-1] was altered.

As a user of these systems, the offical 7th Edition kernel most certainly
could not execute a script, only binaries. It happend after the release
1979 and took time to make its way out, which it did via DSB before 8th Ed
was finalized in 1985.

The usenet announcement of this new functionality from Dennis is on
Jan 10, 1980. Is listed here https://en.wikipedia.org/wiki/Shebang_(Unix)

Dennis stated the idea was not his, it came up during csonverastions at
a conference.
-Brian

From clemc at ccc.com  Tue Jan  7 02:13:03 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 11:13:03 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001061546.006Fk6Fb012760@freefriends.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
Message-ID: <CAC20D2NGXiyPML42K4XzQniA0OJ33cJ7X0QCeQbqVRj-ai9-JQ@mail.gmail.com>

On Mon, Jan 6, 2020 at 10:46 AM <arnold at skeeve.com> wrote:

>
> Would anyone who uses Bash regularly, both interactively and for
> scripting, really want to go back to using the V7 sh
> for production work?  I certainly would not.
>
A heretic!!  Believers all know '*Bourne to Program, Type with Joy' *and*
'One true bracing style' *are the two most important commandments of UNIX
programmer!

Seriously, I still write my scripts as v7 and use (t)csh as my login shell
on all my UNIX boxes ;-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/0582a553/attachment.html>

From will.senn at gmail.com  Tue Jan  7 02:25:05 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 10:25:05 -0600
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
Message-ID: <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>



Sent from my iPhone

> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc at ccc.com> wrote: 
> 
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet if you did and compared it to an nm from V6 I bet they are darned close.
> 
nm wump
no name list

Bummer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/5501bc2c/attachment.html>

From clemc at ccc.com  Tue Jan  7 02:33:54 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 11:33:54 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001061612.006GBrAb018483@cuzuco.com>
References: <202001061612.006GBrAb018483@cuzuco.com>
Message-ID: <CAC20D2M74SXjkmRhjhFzOSyoZFrsHbS-e-DxojFZBVihr_2aDw@mail.gmail.com>

On Mon, Jan 6, 2020 at 11:13 AM Brian Walden <tuhs at cuzuco.com> wrote:

> Dennis stated the idea was not his, it came up during csonverastions at a
> conference.
>
Yeah that make sense.   I'm pretty sure Joy had talked about it in the
Summer '79 USENIX when 2BSD was announced.  I remember his talk and a lot
of people being awed (sort like what happens today when Linus comes to a
conference).  As I remember, one of his topics was csh and how it was
different from the shell in the original BSD.  He must have talked about #!
and few other things for kernel (a bunch of speed ups in nami/inode look
up IIRC), but that's about all I remember.  The next winter was Boulder
('The Black Hole' conference) and he did a redux, and I remember being
amazing how people were more interested in what he was saying than some of
the folks from BTL and I remember a lot of Pascal questions at Boulder,
FWIW.  But to be frank, those conferences all sort of mix a little bit in
my mind at this point.

IIRC:  Dennis was there, Bruce Borden and the Rand folks, as were other
folks like Chesson and some of the U of I folks. Thanks to my friendships
with Ted Kowalsji and later Phil Karn, I had visited the labs a few times
and had met Dennis et al in the early mid-70s, but I think that conference was
the first time I personally met some of the other university types that I
had been communication via the ArpaNet.  I might even have an old
conference list somewhere, but there was no proceedings yet for a few years.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/2c4e58f6/attachment.html>

From clemc at ccc.com  Tue Jan  7 02:35:26 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 11:35:26 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
Message-ID: <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>

Ah - sadly not surprising thinking back.  Binaries got stripped to save a
few bytes in those days.

On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn at gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc at ccc.com> wrote:
>
>
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
> if you did and compared it to an nm from V6 I bet they are darned close.
>
> nm wump
> no name list
>
> Bummer.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/f6ebb6d5/attachment.html>

From steve at quintile.net  Tue Jan  7 02:33:21 2020
From: steve at quintile.net (Steve Simon)
Date: Mon, 6 Jan 2020 16:33:21 +0000
Subject: [TUHS] shell comment chars
Message-ID: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net>


i started on the 7th edition on a perkin elmer (ne interdata) - this was v7 with some 2.1bsd sprinkled on top.

i remember the continual annoyance of unpacking shar files starting with hash comments : only on ed7. in the end i wrote a trivial sed to remove them called unshar.

i haven't thought of that for decades...

-Steve



From imp at bsdimp.com  Tue Jan  7 04:29:59 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Jan 2020 11:29:59 -0700
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
Message-ID: <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>

The good news is that disassembly will tell you right away if it was
written in C or not.

On Mon, Jan 6, 2020 at 9:36 AM Clem Cole <clemc at ccc.com> wrote:

> Ah - sadly not surprising thinking back.  Binaries got stripped to save a
> few bytes in those days.
>
> On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn at gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc at ccc.com> wrote:
>>
>>
>> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
>> if you did and compared it to an nm from V6 I bet they are darned close.
>>
>> nm wump
>> no name list
>>
>> Bummer.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/f6c7e19d/attachment.html>

From will.senn at gmail.com  Tue Jan  7 04:38:25 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 12:38:25 -0600
Subject: [TUHS] wump.c for v6
In-Reply-To: <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
Message-ID: <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>

On 1/6/20 12:29 PM, Warner Losh wrote:
> The good news is that disassembly will tell you right away if it was 
> written in C or not.
>
>
OK. I give up. How?

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/627efd3d/attachment.html>

From imp at bsdimp.com  Tue Jan  7 04:48:02 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Jan 2020 11:48:02 -0700
Subject: [TUHS] wump.c for v6
In-Reply-To: <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
Message-ID: <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>

On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:

> On 1/6/20 12:29 PM, Warner Losh wrote:
>
> The good news is that disassembly will tell you right away if it was
> written in C or not.
>
>
> OK. I give up. How?
>

Generally, the C compiler generates code that's quite distinctive (at least
PCC does, not sure about Dennis' compiler). People writing free assembler
tend to do really weird things for function entry / return.

And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/2e118a03/attachment-0001.html>

From bakul at bitblocks.com  Tue Jan  7 05:10:26 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 06 Jan 2020 11:10:26 -0800
Subject: [TUHS] wump.c for v6
In-Reply-To: Your message of "Mon, 06 Jan 2020 12:38:25 -0600."
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
Message-ID: <20200106191033.82856156E42D@mail.bitblocks.com>

On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn at gmail.com> wrote:
>
> On 1/6/20 12:29 PM, Warner Losh wrote:
> > The good news is that disassembly will tell you right away if it was 
> > written in C or not.
> >
> >
> OK. I give up. How?

Running strings on the wump binary in Dennis_v6 and comparing
its output with actual strings in the wump.c source n
Henry_Spencerv7 reveals they are pretty much the same.

From doug at cs.dartmouth.edu  Tue Jan  7 05:47:56 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 06 Jan 2020 14:47:56 -0500
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001061947.006Jlu9X046618@tahoe.cs.Dartmouth.EDU>

Brian Walden's discussion of sh #, etc, is right on.
However, his etymology for unary * in C can be
pushed back at least to 1959. * was used for
indirect addressing in SAP, the assembler for
the IBM 7090.

From will.senn at gmail.com  Tue Jan  7 06:29:22 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 14:29:22 -0600
Subject: [TUHS] wump.c for v6
In-Reply-To: <20200106191033.82856156E42D@mail.bitblocks.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <20200106191033.82856156E42D@mail.bitblocks.com>
Message-ID: <46eb816b-3faa-b12a-a67c-e5aa84983158@gmail.com>

On 1/6/20 1:10 PM, Bakul Shah wrote:
> On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn at gmail.com> wrote:
>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>> The good news is that disassembly will tell you right away if it was
>>> written in C or not.
>>>
>>>
>> OK. I give up. How?
> Running strings on the wump binary in Dennis_v6 and comparing
> its output with actual strings in the wump.c source n
> Henry_Spencerv7 reveals they are pretty much the same.
Oh. That's funny. I tried strings in v6, it wasn't there. It didn't 
occur to me to do it in MacOS...

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/6f3bac78/attachment.html>

From arnold at skeeve.com  Tue Jan  7 06:44:18 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 06 Jan 2020 13:44:18 -0700
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CAC20D2NGXiyPML42K4XzQniA0OJ33cJ7X0QCeQbqVRj-ai9-JQ@mail.gmail.com>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <CAC20D2NGXiyPML42K4XzQniA0OJ33cJ7X0QCeQbqVRj-ai9-JQ@mail.gmail.com>
Message-ID: <202001062044.006KiIPY023871@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> On Mon, Jan 6, 2020 at 10:46 AM <arnold at skeeve.com> wrote:
>
> > Would anyone who uses Bash regularly, both interactively and for
> > scripting, really want to go back to using the V7 sh
> > for production work?  I certainly would not.
>
> A heretic!!  Believers all know '*Bourne to Program, Type with Joy' *and*
> 'One true bracing style' *are the two most important commandments of UNIX
> programmer!
>
> Seriously, I still write my scripts as v7 and use (t)csh as my login shell
> on all my UNIX boxes ;-)

Time to move into the 21st century.  Tcsh has been obsolete for decades.

Myself, when first exposed to the csh, I revolted (and was revolted) and
stuck with the Bourne shell, even though there was no job control or
history.

I later ported Ron Minnich's job control from the BRL S5R2 on top of BSD shell
to the plain BSD shell and also wrote my own !-style history editor for
it. (Both were posted on USENET in the early 80s.)

After that I got ksh86 and later ksh88, with vi-style command line
editing and never looked back. Then, in the early 90s when I no longer
had ksh access, I switched to bash, contributed fixes to readline's vi
mode, and have been with bash since.

(For a while I tried rc + readline, but that just didn't do it for me.
Bash all the way. Zsh is too different in its vi mode.)

And kudos to Chet for dealing with all the POSIX zigzags ("clarifications",
"definitions") for the shell over the decades. I admire him, but I
don't envy him.

My two cents,

Arnold

From usotsuki at buric.co  Tue Jan  7 06:51:03 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 6 Jan 2020 15:51:03 -0500 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001062044.006KiIPY023871@freefriends.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <CAC20D2NGXiyPML42K4XzQniA0OJ33cJ7X0QCeQbqVRj-ai9-JQ@mail.gmail.com>
 <202001062044.006KiIPY023871@freefriends.org>
Message-ID: <alpine.BSF.2.02.2001061547590.88861@frieza.hoshinet.org>

On Mon, 6 Jan 2020, arnold at skeeve.com wrote:

> After that I got ksh86 and later ksh88, with vi-style command line
> editing and never looked back. Then, in the early 90s when I no longer
> had ksh access, I switched to bash, contributed fixes to readline's vi
> mode, and have been with bash since.

I dig ksh93, because it's lighter and faster than bash, but I wish its tab 
completion worked like bash's.

-uso.

From norman at oclsc.org  Tue Jan  7 07:01:04 2020
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 06 Jan 2020 16:01:04 -0500
Subject: [TUHS] Blit source
Message-ID: <1578344467.1239.for-standards-violators@oclsc.org>

Mike Haertel:

  That's amusing, considering that the 5620 stuff was in /usr/jerq on
  Research systems!  Apparently the accident became institutionalized.

=====

I remember the name Jerq being tossed around to mean 5620
when I was at 1127.  That doesn't mean it was historically
accurate, but it is consistent with the directory names, and
the latter are probably where I got my mistaken idea of the
history.

Thanks to Rob, who certainly should know, for clearing it up.

Norman Wilson
Toronto ON

From clemc at ccc.com  Tue Jan  7 07:08:50 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 16:08:50 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
Message-ID: <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>

You got my curiosity up and found the V5 and V6 source code (I did not have
V4 easy to get, where I am today) ;-)

A big clue of it being C will be having crt0.s (below) in the first few
bytes of the disassembled code.  We see the a.out header (i.e. start at
offset 20 for the code) and look what's there.  I'm going to guess that is
at 046 is the address of _main, from the call instruction at address 034.
The Trap 1 is a sys exit @ address 044.
But .. the V6 crt0.s source has a call to _exit, which is lacking in the
binary below.   So it means that the binary was not created with the C
runtime and probably not the v6 C compiler in the sources.  So I took a
peak at the V6 crt0.s and guess what -- it matches!

So, I'm going to guess the binary was compiled and linked with an earlier
compiler.  Ao ... if I had to guess, the programs are similar, but possibly
different.

% more wump.das
;
; pdp11dasm version 0.0.3
; disassembly of wump
;
000000: 000407                  br      20                      ; ..
;
000002: 005334                  dec     @(r4)+                  ; \.
000004: 004524                  jsr     r5,(r4)+                ; T.
000006: 002312                  bge     37777777634             ; J.
000010: 000000                  halt                            ; ..
000012: 000000                  halt                            ; ..
000014: 000000                  halt                            ; ..
;
000016: 000001                  wait                            ; ..
000020: 170011                  setd                            ; .p
000022: 010600                  mov     r6,r0                   ; ..
000024: 011046                  mov     (r0),-(r6)              ; &.
000026: 005720                  tst     (r0)+                   ; P.
000030: 010066 000002           mov     r0,2(r6)                ; 6...
000034: 004767 000006           call    46                      ; w...
000040: 022626                  cmp     (r6)+,(r6)+             ; .%
000042: 005000                  clr     r0                      ; ..
000044: 104401                  trap    1                       ; ..
000046: 004567 005174           jsr     r5,5246                 ; w.|.
000052: 005746                  tst     -(r6)                   ; f.
000054: 012716 011230           mov     #11230,(r6)             ; N...
000060: 004737 002776           call    @#2776                  ; _.~.
000064: 004767 002262           call    2352                    ; w.2.
000070: 022700 000171           cmp     #171,r0                 ; @%y.
000074: 001027                  bne     154                     ; ..
000076: 005004                  clr     r4                      ; ..
000100: 010400                  mov     r4,r0                   ; ..
000102: 006300                  asl     r0                      ; @.
000104: 005760 005334           tst     5334(r0)                ; p.\.
000110: 001421                  beq     154                     ; ..
000112: 032704 000001           bit     #1,r4                   ; D5..
000116: 001403                  beq     126                     ; ..
000120: 012716 000024           mov     #24,(r6)                ; N...
000124: 000402                  br      132                     ; ..
;
000126: 012716 000003           mov     #3,(r6)                 ; N...
000132: 010400                  mov     r4,r0                   ; ..
000134: 006300                  asl     r0                      ; @.
000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
000142: 004737 002776           call    @#2776                  ; _.~.





V6: s4/crt0.s:
/ C runtime startoff

.globl  savr5
.globl  _exit

.globl  _main

start:
        setd
        mov     sp,r0
        mov     (r0),-(sp)
        tst     (r0)+
        mov     r0,2(sp)
        jsr     pc,_main
        mov     r0,(sp)
        jsr     pc,*$_exit
        sys     exit

.bss
savr5:  .=.+2

V5: s4/crt0.s:
/ C runtime startoff

.globl  savr5

.globl  _main

start:
        setd
        mov     sp,r0
        mov     (r0),-(sp)
        tst     (r0)+
        mov     r0,2(sp)
        jsr     pc,_main
        cmp     (sp)+,(sp)+
        clr     r0
        sys     exit

.bss
savr5:  .=.+2

On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:
>
>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>
>> The good news is that disassembly will tell you right away if it was
>> written in C or not.
>>
>>
>> OK. I give up. How?
>>
>
> Generally, the C compiler generates code that's quite distinctive (at
> least PCC does, not sure about Dennis' compiler). People writing free
> assembler tend to do really weird things for function entry / return.
>
> And it will likely tell you if it's some weird wrapper around another
> binary, though that wasn't too common at bell labs.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/788c1b7c/attachment.html>

From dave at horsfall.org  Tue Jan  7 07:29:30 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Jan 2020 08:29:30 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001061546.006Fk6Fb012760@freefriends.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
Message-ID: <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>

On Mon, 6 Jan 2020, arnold at skeeve.com wrote:

> Would anyone who uses Bash regularly, both interactively and
> for scripting, really want to go back to using the V7 sh
> for production work?

I have never used all the fancy stuff in BASH such as the arithmetic
functions; I still use "expr" etc for portability.

My favourite shell is still ZSH (the alternative was CSH, and my views on 
that POS are well known) because I started using it long before BASH, and 
even then I use a fraction of its power.  I did dabble with KSH, though (I 
needed command editing and history).

-- Dave

From clemc at ccc.com  Tue Jan  7 07:32:24 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 16:32:24 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <202001062044.006KiIPY023871@freefriends.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <CAC20D2NGXiyPML42K4XzQniA0OJ33cJ7X0QCeQbqVRj-ai9-JQ@mail.gmail.com>
 <202001062044.006KiIPY023871@freefriends.org>
Message-ID: <CAC20D2OAt+gYcNcwPCLBGdKnL6mwWZbNYyZ_wpW1YguxZx7wFg@mail.gmail.com>

On Mon, Jan 6, 2020 at 3:44 PM <arnold at skeeve.com> wrote

>
> Time to move into the 21st century.  Tcsh has been obsolete for decades.
>
Burned into the ROMs in my fingers :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/e64003c8/attachment.html>

From dave at horsfall.org  Tue Jan  7 07:35:50 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Jan 2020 08:35:50 +1100 (EST)
Subject: [TUHS] shell comment chars
In-Reply-To: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net>
References: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net>
Message-ID: <alpine.BSF.2.21.9999.2001070834140.40155@aneurin.horsfall.org>

On Mon, 6 Jan 2020, Steve Simon wrote:

> i remember the continual annoyance of unpacking shar files starting with 
> hash comments : only on ed7. in the end i wrote a trivial sed to remove 
> them called unshar.

A "safe" version of which was posted to USENET; why would you run 
someone's random script?

-- Dave

From clemc at ccc.com  Tue Jan  7 07:38:23 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Jan 2020 16:38:23 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
 <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>
Message-ID: <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com>

Some day ....   So I took a peak at the V5 crt0.s and guess what -- it
matches!

On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc at ccc.com> wrote:

> You got my curiosity up and found the V5 and V6 source code (I did not
> have V4 easy to get, where I am today) ;-)
>
> A big clue of it being C will be having crt0.s (below) in the first few
> bytes of the disassembled code.  We see the a.out header (i.e. start at
> offset 20 for the code) and look what's there.  I'm going to guess that is
> at 046 is the address of _main, from the call instruction at address 034.
> The Trap 1 is a sys exit @ address 044.
> But .. the V6 crt0.s source has a call to _exit, which is lacking in the
> binary below.   So it means that the binary was not created with the C
> runtime and probably not the v6 C compiler in the sources.  So I took a
> peak at the V6 crt0.s and guess what -- it matches!
>
> So, I'm going to guess the binary was compiled and linked with an earlier
> compiler.  Ao ... if I had to guess, the programs are similar, but possibly
> different.
>
> % more wump.das
> ;
> ; pdp11dasm version 0.0.3
> ; disassembly of wump
> ;
> 000000: 000407                  br      20                      ; ..
> ;
> 000002: 005334                  dec     @(r4)+                  ; \.
> 000004: 004524                  jsr     r5,(r4)+                ; T.
> 000006: 002312                  bge     37777777634             ; J.
> 000010: 000000                  halt                            ; ..
> 000012: 000000                  halt                            ; ..
> 000014: 000000                  halt                            ; ..
> ;
> 000016: 000001                  wait                            ; ..
> 000020: 170011                  setd                            ; .p
> 000022: 010600                  mov     r6,r0                   ; ..
> 000024: 011046                  mov     (r0),-(r6)              ; &.
> 000026: 005720                  tst     (r0)+                   ; P.
> 000030: 010066 000002           mov     r0,2(r6)                ; 6...
> 000034: 004767 000006           call    46                      ; w...
> 000040: 022626                  cmp     (r6)+,(r6)+             ; .%
> 000042: 005000                  clr     r0                      ; ..
> 000044: 104401                  trap    1                       ; ..
> 000046: 004567 005174           jsr     r5,5246                 ; w.|.
> 000052: 005746                  tst     -(r6)                   ; f.
> 000054: 012716 011230           mov     #11230,(r6)             ; N...
> 000060: 004737 002776           call    @#2776                  ; _.~.
> 000064: 004767 002262           call    2352                    ; w.2.
> 000070: 022700 000171           cmp     #171,r0                 ; @%y.
> 000074: 001027                  bne     154                     ; ..
> 000076: 005004                  clr     r4                      ; ..
> 000100: 010400                  mov     r4,r0                   ; ..
> 000102: 006300                  asl     r0                      ; @.
> 000104: 005760 005334           tst     5334(r0)                ; p.\.
> 000110: 001421                  beq     154                     ; ..
> 000112: 032704 000001           bit     #1,r4                   ; D5..
> 000116: 001403                  beq     126                     ; ..
> 000120: 012716 000024           mov     #24,(r6)                ; N...
> 000124: 000402                  br      132                     ; ..
> ;
> 000126: 012716 000003           mov     #3,(r6)                 ; N...
> 000132: 010400                  mov     r4,r0                   ; ..
> 000134: 006300                  asl     r0                      ; @.
> 000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
> 000142: 004737 002776           call    @#2776                  ; _.~.
>
>
>
>
>
> V6: s4/crt0.s:
> / C runtime startoff
>
> .globl  savr5
> .globl  _exit
>
> .globl  _main
>
> start:
>         setd
>         mov     sp,r0
>         mov     (r0),-(sp)
>         tst     (r0)+
>         mov     r0,2(sp)
>         jsr     pc,_main
>         mov     r0,(sp)
>         jsr     pc,*$_exit
>         sys     exit
>
> .bss
> savr5:  .=.+2
>
> V5: s4/crt0.s:
> / C runtime startoff
>
> .globl  savr5
>
> .globl  _main
>
> start:
>         setd
>         mov     sp,r0
>         mov     (r0),-(sp)
>         tst     (r0)+
>         mov     r0,2(sp)
>         jsr     pc,_main
>         cmp     (sp)+,(sp)+
>         clr     r0
>         sys     exit
>
> .bss
> savr5:  .=.+2
>
> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:
>>
>>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>>
>>> The good news is that disassembly will tell you right away if it was
>>> written in C or not.
>>>
>>>
>>> OK. I give up. How?
>>>
>>
>> Generally, the C compiler generates code that's quite distinctive (at
>> least PCC does, not sure about Dennis' compiler). People writing free
>> assembler tend to do really weird things for function entry / return.
>>
>> And it will likely tell you if it's some weird wrapper around another
>> binary, though that wasn't too common at bell labs.
>>
>> Warner
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/eb5c67ba/attachment.html>

From chet.ramey at case.edu  Tue Jan  7 07:55:55 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 6 Jan 2020 16:55:55 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
Message-ID: <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>

On 1/6/20 4:29 PM, Dave Horsfall wrote:
> On Mon, 6 Jan 2020, arnold at skeeve.com wrote:
> 
>> Would anyone who uses Bash regularly, both interactively and
>> for scripting, really want to go back to using the V7 sh
>> for production work?
> 
> I have never used all the fancy stuff in BASH such as the arithmetic
> functions; I still use "expr" etc for portability.

Portability to what? The POSIX $((...)) arithmetic expansion is widely
implemented and near-universally available.

Some of the other things are more esoteric, but you should be able to
increase your expectation to POSIX features and still be sufficiently
portable.

-- 
``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 brad at anduin.eldar.org  Tue Jan  7 07:39:05 2020
From: brad at anduin.eldar.org (Brad Spencer)
Date: Mon, 06 Jan 2020 16:39:05 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <CAC20D2OAt+gYcNcwPCLBGdKnL6mwWZbNYyZ_wpW1YguxZx7wFg@mail.gmail.com> (message
 from Clem Cole on Mon, 6 Jan 2020 16:32:24 -0500)
Message-ID: <xonh8182rk6.fsf@anduin.eldar.org>

Clem Cole <clemc at ccc.com> writes:

> On Mon, Jan 6, 2020 at 3:44 PM <arnold at skeeve.com> wrote
>
>>
>> Time to move into the 21st century.  Tcsh has been obsolete for decades.
>>
> Burned into the ROMs in my fingers :-)


I am glad that I am not alone ...  I tend to write older style sh
scripts and try to use tcsh as an interactive shell when I can.  BTW -
tcsh is still being updated ...



-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org

From imp at bsdimp.com  Tue Jan  7 08:14:50 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Jan 2020 15:14:50 -0700
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
 <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>
 <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com>
Message-ID: <CANCZdfp0R8_UJg0FzFDrGeY9yqtJGEEK=jyX_58xAfQdLrm2+A@mail.gmail.com>

You have V4 sources? The TUHS archive doesn't have them that I've seen...

Warner

On Mon, Jan 6, 2020, 2:38 PM Clem Cole <clemc at ccc.com> wrote:

> Some day ....   So I took a peak at the V5 crt0.s and guess what -- it
> matches!
>
> On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc at ccc.com> wrote:
>
>> You got my curiosity up and found the V5 and V6 source code (I did not
>> have V4 easy to get, where I am today) ;-)
>>
>> A big clue of it being C will be having crt0.s (below) in the first few
>> bytes of the disassembled code.  We see the a.out header (i.e. start at
>> offset 20 for the code) and look what's there.  I'm going to guess that is
>> at 046 is the address of _main, from the call instruction at address 034.
>> The Trap 1 is a sys exit @ address 044.
>> But .. the V6 crt0.s source has a call to _exit, which is lacking in the
>> binary below.   So it means that the binary was not created with the C
>> runtime and probably not the v6 C compiler in the sources.  So I took a
>> peak at the V6 crt0.s and guess what -- it matches!
>>
>> So, I'm going to guess the binary was compiled and linked with an earlier
>> compiler.  Ao ... if I had to guess, the programs are similar, but possibly
>> different.
>>
>> % more wump.das
>> ;
>> ; pdp11dasm version 0.0.3
>> ; disassembly of wump
>> ;
>> 000000: 000407                  br      20                      ; ..
>> ;
>> 000002: 005334                  dec     @(r4)+                  ; \.
>> 000004: 004524                  jsr     r5,(r4)+                ; T.
>> 000006: 002312                  bge     37777777634             ; J.
>> 000010: 000000                  halt                            ; ..
>> 000012: 000000                  halt                            ; ..
>> 000014: 000000                  halt                            ; ..
>> ;
>> 000016: 000001                  wait                            ; ..
>> 000020: 170011                  setd                            ; .p
>> 000022: 010600                  mov     r6,r0                   ; ..
>> 000024: 011046                  mov     (r0),-(r6)              ; &.
>> 000026: 005720                  tst     (r0)+                   ; P.
>> 000030: 010066 000002           mov     r0,2(r6)                ; 6...
>> 000034: 004767 000006           call    46                      ; w...
>> 000040: 022626                  cmp     (r6)+,(r6)+             ; .%
>> 000042: 005000                  clr     r0                      ; ..
>> 000044: 104401                  trap    1                       ; ..
>> 000046: 004567 005174           jsr     r5,5246                 ; w.|.
>> 000052: 005746                  tst     -(r6)                   ; f.
>> 000054: 012716 011230           mov     #11230,(r6)             ; N...
>> 000060: 004737 002776           call    @#2776                  ; _.~.
>> 000064: 004767 002262           call    2352                    ; w.2.
>> 000070: 022700 000171           cmp     #171,r0                 ; @%y.
>> 000074: 001027                  bne     154                     ; ..
>> 000076: 005004                  clr     r4                      ; ..
>> 000100: 010400                  mov     r4,r0                   ; ..
>> 000102: 006300                  asl     r0                      ; @.
>> 000104: 005760 005334           tst     5334(r0)                ; p.\.
>> 000110: 001421                  beq     154                     ; ..
>> 000112: 032704 000001           bit     #1,r4                   ; D5..
>> 000116: 001403                  beq     126                     ; ..
>> 000120: 012716 000024           mov     #24,(r6)                ; N...
>> 000124: 000402                  br      132                     ; ..
>> ;
>> 000126: 012716 000003           mov     #3,(r6)                 ; N...
>> 000132: 010400                  mov     r4,r0                   ; ..
>> 000134: 006300                  asl     r0                      ; @.
>> 000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
>> 000142: 004737 002776           call    @#2776                  ; _.~.
>>
>>
>>
>>
>>
>> V6: s4/crt0.s:
>> / C runtime startoff
>>
>> .globl  savr5
>> .globl  _exit
>>
>> .globl  _main
>>
>> start:
>>         setd
>>         mov     sp,r0
>>         mov     (r0),-(sp)
>>         tst     (r0)+
>>         mov     r0,2(sp)
>>         jsr     pc,_main
>>         mov     r0,(sp)
>>         jsr     pc,*$_exit
>>         sys     exit
>>
>> .bss
>> savr5:  .=.+2
>>
>> V5: s4/crt0.s:
>> / C runtime startoff
>>
>> .globl  savr5
>>
>> .globl  _main
>>
>> start:
>>         setd
>>         mov     sp,r0
>>         mov     (r0),-(sp)
>>         tst     (r0)+
>>         mov     r0,2(sp)
>>         jsr     pc,_main
>>         cmp     (sp)+,(sp)+
>>         clr     r0
>>         sys     exit
>>
>> .bss
>> savr5:  .=.+2
>>
>> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:
>>>
>>>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>>>
>>>> The good news is that disassembly will tell you right away if it was
>>>> written in C or not.
>>>>
>>>>
>>>> OK. I give up. How?
>>>>
>>>
>>> Generally, the C compiler generates code that's quite distinctive (at
>>> least PCC does, not sure about Dennis' compiler). People writing free
>>> assembler tend to do really weird things for function entry / return.
>>>
>>> And it will likely tell you if it's some weird wrapper around another
>>> binary, though that wasn't too common at bell labs.
>>>
>>> Warner
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/8f3be105/attachment-0001.html>

From bakul at bitblocks.com  Tue Jan  7 08:10:35 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 06 Jan 2020 14:10:35 -0800
Subject: [TUHS] sh: cmd | >file
In-Reply-To: Your message of "Tue, 07 Jan 2020 08:29:30 +1100."
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
Message-ID: <20200106221042.DB693156E42D@mail.bitblocks.com>

On Tue, 07 Jan 2020 08:29:30 +1100 Dave Horsfall <dave at horsfall.org> wrote:
> On Mon, 6 Jan 2020, arnold at skeeve.com wrote:
>
> > Would anyone who uses Bash regularly, both interactively and
> > for scripting, really want to go back to using the V7 sh
> > for production work?
>
> I have never used all the fancy stuff in BASH such as the arithmetic
> functions; I still use "expr" etc for portability.
>
> My favourite shell is still ZSH (the alternative was CSH, and my views on 
> that POS are well known) because I started using it long before BASH, and 
> even then I use a fraction of its power.  I did dabble with KSH, though (I 
> needed command editing and history).

csh was more convenient as an interactive shell but it was not
good for writing scripts & I always used /bin/sh for scripts.
I switched from csh to zsh almost since the time it was first
posted to alt.sources - over 29 years ago!

From dave at horsfall.org  Tue Jan  7 08:22:24 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Jan 2020 09:22:24 +1100 (EST)
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
 <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
Message-ID: <alpine.BSF.2.21.9999.2001070916150.40155@aneurin.horsfall.org>

On Mon, 6 Jan 2020, Chet Ramey wrote:

>> I have never used all the fancy stuff in BASH such as the arithmetic 
>> functions; I still use "expr" etc for portability.
>
> Portability to what? The POSIX $((...)) arithmetic expansion is widely 
> implemented and near-universally available.

As I said, I never bothered to learn "$((...))" because "expr" works just 
fine.  And I might come across an old machine at some time; I come from 
the school of "Make it work before making it pretty" and I extend that to 
backwards compatibility.

And "expr" is burned into my brain :-)

> Some of the other things are more esoteric, but you should be able to 
> increase your expectation to POSIX features and still be sufficiently 
> portable.

I might get around to it, but at 67 I may not have much time (or 
incentive)...  Besides, programming is only a hobby for me, as I'm long 
retired.

-- Dave

From dave at horsfall.org  Tue Jan  7 08:50:33 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Jan 2020 09:50:33 +1100 (EST)
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <202001060630.0066U7U7023760@cuzuco.com>
References: <202001060630.0066U7U7023760@cuzuco.com>
Message-ID: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>

On Mon, 6 Jan 2020, Brian Walden wrote:

> csh(1) was wrtten around 1978 and yes # as a comment was only for 
> scrtipts, think it was why would you need to comment interactively?

Why would you *not* want to?  You've just made "#" asymmetric in its 
behaviour; in the meantime the parser just sees an unescaped "#" and 
ignores everything after that, without regard to context.

You might also be using "script" e.g.

     script
     blah blah
     # Now here I do something funky
     *really* funky stuff
     ^D

[...]

> Also before you say wait! ALGOL uses # as comment and is older than 
> Kernighan' ratfor(1). [...]

Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I 
loved using; I wish I still had my ALGOLW book)?

-- Dave

From crossd at gmail.com  Tue Jan  7 08:52:41 2020
From: crossd at gmail.com (Dan Cross)
Date: Mon, 6 Jan 2020 17:52:41 -0500
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
 <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
Message-ID: <CAEoi9W7dM8oeWouw0wt7FL16n_3zkKfn7k7+LXyjw8VYXeC_5w@mail.gmail.com>

On Mon, Jan 6, 2020 at 4:56 PM Chet Ramey <chet.ramey at case.edu> wrote:

> On 1/6/20 4:29 PM, Dave Horsfall wrote:
> > On Mon, 6 Jan 2020, arnold at skeeve.com wrote:
> >
> >> Would anyone who uses Bash regularly, both interactively and
> >> for scripting, really want to go back to using the V7 sh
> >> for production work?
> >
> > I have never used all the fancy stuff in BASH such as the arithmetic
> > functions; I still use "expr" etc for portability.
>
> Portability to what? The POSIX $((...)) arithmetic expansion is widely
> implemented and near-universally available.
>
> Some of the other things are more esoteric, but you should be able to
> increase your expectation to POSIX features and still be sufficiently
> portable.
>

Huh.

I've been in this "use the old stuff for portability" camp for some time,
but now that you mention it....I can't think of any systems I use that
require resorting to old-style shell-isms.

What an interesting epiphany. It reminds me of the time when first I
realized that continuing to write K&R-style C was no longer necessary, as
everything that I used had an ANSI-compatible compiler and supported
function prototypes.

Seeing backticks in the rearview mirror is a welcome change.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/ee8f53d4/attachment.html>

From will.senn at gmail.com  Tue Jan  7 09:46:10 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 17:46:10 -0600
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
 <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>
 <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com>
Message-ID: <DFA8B1F3-C2D6-4FF1-9353-A4429DA54553@gmail.com>



Sent from my iPhone

> On Jan 6, 2020, at 3:38 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Some day ....   So I took a peak at the V5 crt0.s and guess what -- it matches! 

Awesome. Thanks for sharing your approach to the disasm. 

On another note,You said you looked in v5 and v6 source code? I looked at tuhs and didn’t see anything earlier than v7. Where did you find them?

Thanks,

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/e49e82ff/attachment.html>

From imp at bsdimp.com  Tue Jan  7 10:39:39 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Jan 2020 17:39:39 -0700
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
References: <202001060630.0066U7U7023760@cuzuco.com>
 <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
Message-ID: <CANCZdfqsBFwxwjb5kEnE6FTGgAA4ZH_L_AqyB4A1eoUeEoL1Gg@mail.gmail.com>

On Mon, Jan 6, 2020 at 3:51 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Mon, 6 Jan 2020, Brian Walden wrote:
>
> > csh(1) was wrtten around 1978 and yes # as a comment was only for
> > scrtipts, think it was why would you need to comment interactively?
>
> Why would you *not* want to?  You've just made "#" asymmetric in its
> behaviour; in the meantime the parser just sees an unescaped "#" and
> ignores everything after that, without regard to context.
>
> You might also be using "script" e.g.
>
>      script
>      blah blah
>      # Now here I do something funky
>      *really* funky stuff
>      ^D
>

Or you might have cut and paste the commands from a script to test
something, or to redo something by hand that failed for some reason.

Warner


> [...]
>
> > Also before you say wait! ALGOL uses # as comment and is older than
> > Kernighan' ratfor(1). [...]
>
> Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I
> loved using; I wish I still had my ALGOLW book)?
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/a8d399b9/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Jan  7 10:40:26 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  6 Jan 2020 19:40:26 -0500 (EST)
Subject: [TUHS] wump.c for v6
Message-ID: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu>

    > From: Will Senn

    > On another note,You said you looked in v5 and v6 source code? I looked
    > at tuhs and didn't see anything earlier than v7. Where did you find
    > them?

Huh? https://www.tuhs.org/cgi-bin/utree.pl

	Noel


From imp at bsdimp.com  Tue Jan  7 10:44:20 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Jan 2020 17:44:20 -0700
Subject: [TUHS] wump.c for v6
In-Reply-To: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu>
References: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu>
Message-ID: <CANCZdfpxOUSAbiS+wZj11-MWQptE-hQXDDVq4L52vs5r82XmkQ@mail.gmail.com>

On Mon, Jan 6, 2020 at 5:41 PM Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>     > From: Will Senn
>
>     > On another note,You said you looked in v5 and v6 source code? I
> looked
>     > at tuhs and didn't see anything earlier than v7. Where did you find
>     > them?
>
> Huh? https://www.tuhs.org/cgi-bin/utree.pl


There's no wupus source before V7.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200106/d170523b/attachment.html>

From athornton at gmail.com  Tue Jan  7 10:50:18 2020
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 6 Jan 2020 17:50:18 -0700
Subject: [TUHS] sh: cmd | >file
In-Reply-To: <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu>
 <1ingL0-5g6-00@marmaro.de>
 <alpine.BSF.2.21.9999.2001050758110.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001050810160.40155@aneurin.horsfall.org>
 <CANCZdfp6QGqpiRkz-t3y+jwTkfmYCdxCQk+1=rh7qcKyHoSEQw@mail.gmail.com>
 <CACqnu4UAUQmPOfjmz1ZVgNtVRFG=9a=PYtGu4vSKGHv05aNjSg@mail.gmail.com>
 <df91940b-737d-1c7c-635a-207615842a77@case.edu>
 <alpine.BSF.2.21.9999.2001051045580.40155@aneurin.horsfall.org>
 <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu>
 <alpine.BSF.2.21.9999.2001060814050.40155@aneurin.horsfall.org>
 <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu>
 <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com>
 <202001061546.006Fk6Fb012760@freefriends.org>
 <alpine.BSF.2.21.9999.2001070821060.40155@aneurin.horsfall.org>
 <bee504b9-75c9-1c03-e7f4-18d75b31d687@case.edu>
Message-ID: <572C7C41-0B92-461C-88F9-5EC5436A66F5@gmail.com>



> On Jan 6, 2020, at 2:55 PM, Chet Ramey <chet.ramey at case.edu> wrote:
> 
> On 1/6/20 4:29 PM, Dave Horsfall wrote:
>> On Mon, 6 Jan 2020, arnold at skeeve.com wrote:
>>> Would anyone who uses Bash regularly, both interactively and
>>> for scripting, really want to go back to using the V7 sh
>>> for production work?
>> I have never used all the fancy stuff in BASH such as the arithmetic
>> functions; I still use "expr" etc for portability.
> 
> Portability to what? The POSIX $((...)) arithmetic expansion is widely
> implemented and near-universally available.
> 
> Some of the other things are more esoteric, but you should be able to
> increase your expectation to POSIX features and still be sufficiently
> portable.
> 

Portability to v7, of course!

I mean, I’m joking, but also not.

I felt like v7 might be enough of a daily driver that I could port some fun stuff to it, but…damn, even ex/vi 3.x is huge, jove will take a lot of work, and I can’t find a minimalist screen editor in K&R C.  The best I’ve managed is TE but although there is presumably a Unix port, I couldn’t find it.  Porting termcap and curses was easy, but….the whole reason I want them, initially, is so that I don’t have to use ed.  If anyone knows of a small screen editor that will build easily on v7 I want to know about it.

This is in contrast to 2.11BSD, where, yeah, it’s just Unix, and especially with a TCP/IP stack, is completely usable.  The PDP-11’s 64K address space is constraining and (as it turned out) influences the way I write programs—for my menu front end for ZIP, I started with my usual technique of making a struct with all the fields I’d want for my menu structure, and a linked list of those things, but that turned out to be a hog and a simple **char plus some utility functions to index the elements ended up being completely adequate.

Adam

From jnc at mercury.lcs.mit.edu  Tue Jan  7 11:58:48 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  6 Jan 2020 20:58:48 -0500 (EST)
Subject: [TUHS] wump.c for v6
Message-ID: <20200107015848.B269818C07B@mercury.lcs.mit.edu>

    > From: Warner Losh <imp at bsdimp.com>

    > There's no wupus source before V7.

If you look at Clem's original message:

    >> From: Clem Cole <clemc at ccc.com>
    >> Date: Mon, 6 Jan 2020 16:08:50 -0500

    >> You got my curiosity up and found the V5 and V6 source code

(the one Will was replying to), Clem's talking about the source to crt0.s,
etc.

     Noel

From doug at cs.dartmouth.edu  Tue Jan  7 12:31:44 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 06 Jan 2020 21:31:44 -0500
Subject: [TUHS] screen editors
Message-ID: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>

> but…damn, even ex/vi 3.x is huge

It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.

Doug

From brantley at coraid.com  Tue Jan  7 12:37:00 2020
From: brantley at coraid.com (Brantley Coile)
Date: Tue, 7 Jan 2020 02:37:00 +0000
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <65E7E540-0889-4B3C-BAD3-F7A433608577@coraid.com>

Well said. I do as well.

> On Jan 6, 2020, at 9:31 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> but…damn, even ex/vi 3.x is huge
> 
> It was so excesssive right from the start that I refused to use it.
> Sam was the first screen editor that I deemed worthwhile, and I
> still use it today.
> 
> Doug


From lm at mcvoy.com  Tue Jan  7 12:38:34 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 6 Jan 2020 18:38:34 -0800
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <20200107023834.GN20269@mcvoy.com>

On Mon, Jan 06, 2020 at 09:31:44PM -0500, Doug McIlroy wrote:
> > but???damn, even ex/vi 3.x is huge
> 
> It was so excesssive right from the start that I refused to use it.
> Sam was the first screen editor that I deemed worthwhile, and I
> still use it today.

I grew up on 4MB Suns.  Emacs was "8 megs and constantly swapping".
I thought vi was fine though I did do a lot with xvi (I think that was
what it was called) and I hacked it to use mmap to look at the file.
I had to do something about strings to make that work, don't remember,
but it worked and I could vi 4MB log files and search them pretty fast.

I'm a vi guy to this day.  Love it.

From will.senn at gmail.com  Tue Jan  7 13:27:22 2020
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Jan 2020 21:27:22 -0600
Subject: [TUHS] TUHS Digest, Vol 50, Issue 8
In-Reply-To: <mailman.1.1578362401.2769.tuhs@minnie.tuhs.org>
References: <mailman.1.1578362401.2769.tuhs@minnie.tuhs.org>
Message-ID: <15CD334E-AC18-48B1-B762-39D744AB7542@gmail.com>

> 
>> From: Warner Losh <imp at bsdimp.com>
> 
>> There's no wupus source before V7.
> 
> If you look at Clem's original message:
> 
>>> From: Clem Cole <clemc at ccc.com>
>>> Date: Mon, 6 Jan 2020 16:08:50 -0500
> 
>>> You got my curiosity up and found the V5 and V6 source code
> 
> (the one Will was replying to), Clem's talking about the source to crt0.s,
> etc.
> 
>     Noel
> 

Sorry. I could have been clearer. I thought Clem was saying that he found the Wumpus code in v5/v6. Now, I see that he was just talking about the crt files. When I said I couldn’t find the source prior to v7, I meant the wumpus source :).

On another note, porting the v7 code to MacOS is tricky, lots of minor differences, but I’m giving it a go. Prolly easier to just figure out what it’s supposed to do and do it with modern idioms, but it’s a fun puzzle to try to replicate the same functionality with only minor adjustments.

Will

From tuhs at cuzuco.com  Tue Jan  7 14:49:18 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Mon, 6 Jan 2020 23:49:18 -0500 (EST)
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001070449.0074nIn2017611@cuzuco.com>

Doug McIlroy wrote:
>Brian Walden's discussion of sh #, etc, is right on.
>However, his etymology for unary * in C can be
>pushed back at least to 1959. * was used for
>indirect addressing in SAP, the assembler for
>the IBM 7090.

Thank you for both the confirmation and also that history update.
-Brian

From tuhs at cuzuco.com  Tue Jan  7 15:03:39 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Tue, 7 Jan 2020 00:03:39 -0500 (EST)
Subject: [TUHS] sh: cmd | >file
Message-ID: <202001070503.00753dBd029629@cuzuco.com>

Clem Cole wrote:
>A heretic!!  Believers all know '*Bourne to Program, Type with Joy' *and*
>'One true bracing style' *are the two most important commandments of UNIX
>programmer!
>
>Seriously, I still write my scripts as v7 and use (t)csh as my login shell
>on all my UNIX boxes ;-)
>
>Clem

You know what's amazing? that Bill Joy code to launch either
csh or bourne shell based on the first character of teh file is
still in tcsh codebase today. It even has #! support just in case
your kernel does not. However this code never gets run as
who write scripts without #! anymore .. but here's a little test ---

$ tcsh
You have 2 mail messages.
> cat x1.sh
PATH=/bin
echo $SHELL
> ./x1.sh
/bin/sh
> cat x2.csh
#
setenv path /bin
echo $shell
> ./x2.csh
/usr/local/bin/tcsh
> exit

you can see it in https://github.com/tcsh-org/tcsh/blob/master/sh.exec.c

-Brian

From dave at horsfall.org  Tue Jan  7 16:19:27 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Jan 2020 17:19:27 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>

I don't recall the exact details, but there was once an editor called "em" 
(Editor for Mortals).  I remember thinking: what sort of an idiot would 
call it that, with the "e" and "r" keys adjacent to each other?  I wonder 
how many files were lost that way...

-- Dave

From thomas.paulsen at firemail.de  Tue Jan  7 18:24:03 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 07 Jan 2020 09:24:03 +0100
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
Message-ID: <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de>


>I don't recall the exact details, but there was once an editor called "em"
>(Editor for Mortals).  I remember thinking: what sort of an idiot would
>call it that, with the "e" and "r" keys adjacent to each
>other?  I wonder  how many files were lost that way...
you can download, build and use em making immediately clear that em was much easier 
to use than ed. Nevertheless em was only (another) step in between ed and vi.

http://pgas.freeshell.org/C/em/
http://www.tuhs.org/Archive/Applications/Em_Editor/
http://www.coulouris.net/cs_history/em_story/emsource/




From ullbeking at andrewnesbit.org  Tue Jan  7 19:43:49 2020
From: ullbeking at andrewnesbit.org (ullbeking at andrewnesbit.org)
Date: Tue, 7 Jan 2020 09:43:49 +0000 (UTC)
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>


7 Jan 2020 02:32:11 Doug McIlroy :
> Sam was the first screen editor that I deemed worthwhile, and I
> still use it today.

I would like to experiment with Sam and run it on various *nix operating systems. There seems to be many ports.

Do I need to install some kind of Plan 9 emulation layer (in user space), which Sam builds and runs on? Obviously I'm referring to Russ Cox's libraries and user space tools.

Is it necessary to have a p9 environment to gain the most advantage of a tool like Sam? Or, is it possible for it still to function well as a transplant in a new environment such as *nix?

In that second case, what are the well ported versions of Sam that build and run directly on the target environment?

Andrew



From wkt at tuhs.org  Tue Jan  7 20:56:15 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 7 Jan 2020 20:56:15 +1000
Subject: [TUHS] Unix/World Magazines
Message-ID: <20200107105615.GA16081@minnie.tuhs.org>

All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org.
They are at:

https://archive.org/search.php?query=title%3A%28Unix%20World%29

Cheers, Warren

From crossd at gmail.com  Wed Jan  8 00:53:37 2020
From: crossd at gmail.com (Dan Cross)
Date: Tue, 7 Jan 2020 09:53:37 -0500
Subject: [TUHS] screen editors
In-Reply-To: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>
Message-ID: <CAEoi9W4NjAGYLbQD3L4z4tmgpcApjA=Lifgwi83hMRY2_A0s8g@mail.gmail.com>

On Tue, Jan 7, 2020 at 4:50 AM <ullbeking at andrewnesbit.org> wrote:

> 7 Jan 2020 02:32:11 Doug McIlroy :
> > Sam was the first screen editor that I deemed worthwhile, and I
> > still use it today.
>
> I would like to experiment with Sam and run it on various *nix operating
> systems. There seems to be many ports.
>
> Do I need to install some kind of Plan 9 emulation layer (in user space),
> which Sam builds and runs on? Obviously I'm referring to Russ Cox's
> libraries and user space tools.
>
> Is it necessary to have a p9 environment to gain the most advantage of a
> tool like Sam? Or, is it possible for it still to function well as a
> transplant in a new environment such as *nix?
>
> In that second case, what are the well ported versions of Sam that build
> and run directly on the target environment?
>

It is not necessary to have a plan 9 environment to take advantage of Sam,
and there was once a port for Unix that worked outside of the usual Plan 9
world. Indeed, Sam got its start on Unix.

However, I dare say that the best port to use is the one from plan9port:
Sam continued to evolve on plan9, if only gaining incremental improvements
after the early Unix years. By using the plan9port version, you'll pick up
on those changes (though I can't really enumerate them anymore).

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/de4902ed/attachment.html>

From clemc at ccc.com  Wed Jan  8 01:03:57 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 7 Jan 2020 10:03:57 -0500
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2Me2VxTbeX0nLZ74Q9+DSYcTA+oMEsBozS=HdRVWwsLrg@mail.gmail.com>

On Mon, Jan 6, 2020 at 9:32 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > but…damn, even ex/vi 3.x is huge
>
> It was so excesssive right from the start that I refused to use it.
> Sam was the first screen editor that I deemed worthwhile, and I
> still use it today.
>
> Doug
>
Oh so true; although the early version from 2BSD was smaller.   I bet my
fingers are still only using much of that subset ;-)  But I certainly
watched it grow and grow over the years.   I'm really not so sure about
'vim' -- it has become as much of a feature sink as emacs.

FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition
and somewhat pined for a screen editor.   Soon after upgrading to 6th
edition at CMU, we found a visual editor called Fred - the Friendly Editor,
from Cornell IIRC (I think it's on the original USENIX tape but I don't
remember how we got it).  I had to hack in the Perkin-Elmer Fox terminal
support, but it was a superset of V6 ed so a pretty trivial learning curve.

However, since Fred had the terminal support compiled it and when I went to
Tektronix a few years later, I had to add a whole bunch of new terminals
and we quickly started running into the address issues on the 11/40 class
systems.   Mark Bales was working as a summer student and had brought 2BSD
with him (inc. vi and csh).  Poof, thanks to termcap ex/vi could run on
most every terminal we already had (in some manner) which Fred could not.
 And because of termcap not having to keep the code for the other terminals
not being used in memory, even though the editor itself was more complex,
we could just squeeze that version on an 11/40 class system running Seventh
Edition.  That made me take notice.  Again it was ed under the covers so
the transition was easy. I was pretty impressed with termcap, and soon
thereafter I found myself sending Mary Ann a couple of new terminal
definitions for some missing Tek terminals like Tek 4025.

With the VAX, and new ex/vi shows up and it would not run on the PDP-11's,
I was disappointed.   But the old version still worked and I had started to
notice that a *version of **vi *had started to show up on most everything I
used, from VMS to the Cray's and later the PCs, so really I never looked
back.  It became the most portable editor for my fingers as I had long ago
forgotten EMACS (even when we got Vaxen and Gosling EMACS shows up on the
UNIX scene, I never bother to really relearn it - I can use it if I have
too, but not as well as vi these days).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/949b704f/attachment.html>

From clemc at ccc.com  Wed Jan  8 01:24:48 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 7 Jan 2020 10:24:48 -0500
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
References: <202001060630.0066U7U7023760@cuzuco.com>
 <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
Message-ID: <CAC20D2NhDGjGqOEZH0EDGf6cHHOWRvC0tLy40QNEkf9ETxyj7A@mail.gmail.com>

On Mon, Jan 6, 2020 at 5:51 PM Dave Horsfall <dave at horsfall.org> wrote:

> Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I
> loved using; I wish I still had my ALGOLW book)?
>
Algol-W   From, the Sites book, (Page 10, Section 1 'Terminology)  [Dave,
I'll send you the PDF offline].

The symbol *comment* followed by any sequence of characters not -containing
semicolons, followed by a semicolon, is called a *comment*. A comment has
no effect on the meaning of a program, and is ignored during execution of
the program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/86451b08/attachment.html>

From thomas.paulsen at firemail.de  Wed Jan  8 01:50:44 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 07 Jan 2020 16:50:44 +0100
Subject: [TUHS] screen editors
In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
Message-ID: <c450d139ce71b8b89953500d8737b788@firemail.de>

>It was so excesssive right from the start that I refused to use it.
>Sam was the first screen editor that I deemed worthwhile, and I
>still use it today.
my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim.



From arnold at skeeve.com  Wed Jan  8 02:30:53 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 07 Jan 2020 09:30:53 -0700
Subject: [TUHS] screen editors
In-Reply-To: <20200107023834.GN20269@mcvoy.com>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
Message-ID: <202001071630.007GUrBj030452@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> I'm a vi guy to this day.  Love it.

In the summer of '82 I did some contract programming at Southern Bell
on a PDP-11 running USG Unix 4.0.  It had a screen editor called 'se'
that I only ever saw there, written somewhere in the Bell System and
squeezed to run on an -11.  Anyone know anything about it?

Unrelated, Georgia Tech had the 'se' screen editor as part of the
Software Tools Subsystem, based on the 'ed' in the Software Tools book.
This was later ported to Unix. I modified that code to use curses/termlib
and posted it to USENET. It's been updated and is available from
https://github.com/se-editor/se and http://se-editor.org is the home
page. (Thomas Cort IIRC did that work.)

What's funny is that in doing the work to get 'se' running on Georgia
Tech's Vax, I had to learn vi.  By the time I was done, vi had become
my main editor and had burned itself into my finger's ROMs.

Arnold

From rich.salz at gmail.com  Wed Jan  8 02:38:56 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Tue, 7 Jan 2020 11:38:56 -0500
Subject: [TUHS] screen editors
In-Reply-To: <202001071630.007GUrBj030452@freefriends.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
Message-ID: <CAFH29tr7fndrtd8wS=eOvet_4aYh+hvdN+i5x9tNHYrJ8Wf9zQ@mail.gmail.com>

Any fans of the Rand Editor?
https://github.com/blakemcbride/Rand-E-Editor

And do folks here know of the TextEditors wiki at
http://texteditors.org/cgi-bin/wiki.pl?HomePage ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/99d5e07c/attachment.html>

From crossd at gmail.com  Wed Jan  8 04:32:29 2020
From: crossd at gmail.com (Dan Cross)
Date: Tue, 7 Jan 2020 13:32:29 -0500
Subject: [TUHS] screen editors
In-Reply-To: <202001071630.007GUrBj030452@freefriends.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
Message-ID: <CAEoi9W4N86uUuJapQYBB=7s8Gc5=Thg9XMx=rWk5gAf16WZ=kg@mail.gmail.com>

On Tue, Jan 7, 2020 at 11:31 AM <arnold at skeeve.com> wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
>
> > I'm a vi guy to this day.  Love it.
>
> In the summer of '82 I did some contract programming at Southern Bell
> on a PDP-11 running USG Unix 4.0.  It had a screen editor called 'se'
> that I only ever saw there, written somewhere in the Bell System and
> squeezed to run on an -11.  Anyone know anything about it?
>
> Unrelated, Georgia Tech had the 'se' screen editor as part of the
> Software Tools Subsystem, based on the 'ed' in the Software Tools book.
> This was later ported to Unix. I modified that code to use curses/termlib
> and posted it to USENET. It's been updated and is available from
> https://github.com/se-editor/se and http://se-editor.org is the home
> page. (Thomas Cort IIRC did that work.)
>
> What's funny is that in doing the work to get 'se' running on Georgia
> Tech's Vax, I had to learn vi.  By the time I was done, vi had become
> my main editor and had burned itself into my finger's ROMs.
>

Ah, this reminds me of something. I assume you've read, "A Software Tools
Sampler"?

A few months ago, I started looking into screen update algorithms for a
(frivolous) retro-computing time sink, er, I mean project.

Naturally, Gosling's redisplay algorithm figured prominently, as it's
famous and well-known. I looked at the Unix emacs code and it's not that
hard to puzzle through, actually, despite the reputation and the (in)famous
skull and crossbones comment. However, Gosling's code assumes that update
commands all have uniform cost (cost here being proportional to the
command's length) which, on real terminals, just isn't true. Meyers and
Miller came up with several algorithms that take into account editing
command cost, and produce potentially far-better solutions than Gosling's
code, though limited by the inability at the time to quickly build suffix
trees (this was about a decade before Ukkonen's algorithm); it's
interesting that none of these algorithms take into account text
attributes, which on most serial terminals are modal. Anyway, at least one
of these algorithms was implemented in a modified version of `se`, as
described in "A Software Tools Sampler." I guess Webb thought that was
easier to work with than an existing editor? Perhaps these "se"s share a
lineage?

What's interesting to me is that redisplay algorithms were clearly an area
of active research at one time, but  interest seemed to dry up almost over
night. One must presume that this evaporation of research activity had to
do with the en mass migration to graphical workstations where the problems
are different, and possibly with curses being "good enough" in e.g. an
xterm. However, one can see some of the fruits of Miller's research in his
later work in genomics.

        - Dan C.

A few random references:
Gosling, James, "A Redisplay Algorithm."
https://dl.acm.org/doi/10.1145/872730.806463
Meyers, Eugene and Webb Miller, "A Simple Row Replacement Algorithm."
https://dl.acm.org/doi/10.5555/52187.52188
Meyers, Eugene and Webb Miller, "Row Replacement Algorithm for Screen
Editors." https://dl.acm.org/doi/10.1145/59287.59290
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/1fa13a7f/attachment.html>

From thomas.paulsen at firemail.de  Wed Jan  8 05:14:27 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 07 Jan 2020 20:14:27 +0100
Subject: [TUHS] screen editors
In-Reply-To: <202001071630.007GUrBj030452@freefriends.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
Message-ID: <bbe88baca838c50fcae26183e389bd94@firemail.de>

>What's funny is that in doing the work to get 'se' running on Georgia
>Tech's Vax, I had to learn vi.  By the time I was done, vi had become
>my main editor and had burned itself into my finger's ROMs.
I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. 



From rodrigosloop at gmail.com  Wed Jan  8 05:35:36 2020
From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=)
Date: Tue, 7 Jan 2020 20:35:36 +0100
Subject: [TUHS] screen editors
In-Reply-To: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>
Message-ID: <CA+cCjXpDJ5xufnfnjmRDTTcy+OYVCg1SMNouOHrvmxJA9NwPOw@mail.gmail.com>

i like to use it natively as much as possible, especially the 9front
edition with its usability (e.g. mouse chording) improvements. if that is
not possible, i drawterm into some cpu or a local vm where i can get a
little environment to work with whatever is at /mnt/term.

it also has a powerful command language and structural regular expressions,
and you can use your favorite unix tools on any piece of text you please.

it has given me the best text editing and programming experience i've ever
had.


-rodri


On Tue, Jan 7, 2020, 10:50 AM <ullbeking at andrewnesbit.org> wrote:

>
> 7 Jan 2020 02:32:11 Doug McIlroy :
> > Sam was the first screen editor that I deemed worthwhile, and I
> > still use it today.
>
> I would like to experiment with Sam and run it on various *nix operating
> systems. There seems to be many ports.
>
> Do I need to install some kind of Plan 9 emulation layer (in user space),
> which Sam builds and runs on? Obviously I'm referring to Russ Cox's
> libraries and user space tools.
>
> Is it necessary to have a p9 environment to gain the most advantage of a
> tool like Sam? Or, is it possible for it still to function well as a
> transplant in a new environment such as *nix?
>
> In that second case, what are the well ported versions of Sam that build
> and run directly on the target environment?
>
> Andrew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/80375120/attachment.html>

From doug at cs.dartmouth.edu  Wed Jan  8 05:57:40 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 07 Jan 2020 14:57:40 -0500
Subject: [TUHS] screen editors
Message-ID: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>

McIlroy:
> [vi] was so excesssive right from the start that I refused to use it.
> Sam was the first screen editor that I deemed worthwhile, and I
> still use it today.

Paulsen:
> my sam build is more than 2 times bigger than Gunnar Ritter's vi
> (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim.

% wc -c /bin/vi bin/sam bin/samterm
1706152 /bin/vi
 112208 bin/sam
 153624 bin/samterm
These mumbers are from Red Hat Linux.
The 6:1 discrepancy is understated because
vi is stripped and the sam files are not.
All are 64-bit, dynamically linked.

From ewe2 at ewe2.ninja  Wed Jan  8 06:04:47 2020
From: ewe2 at ewe2.ninja (Sean Dwyer)
Date: Tue, 7 Jan 2020 15:04:47 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
Message-ID: <20200107200447.GA3211@mail.ewe2.ninja>

On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote:
> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:
> 
> > On 1/6/20 12:29 PM, Warner Losh wrote:
> >
> > The good news is that disassembly will tell you right away if it was
> > written in C or not.
> >
> >
> > OK. I give up. How?
> >
> 
> Generally, the C compiler generates code that's quite distinctive (at least
> PCC does, not sure about Dennis' compiler). People writing free assembler
> tend to do really weird things for function entry / return.
> 
> And it will likely tell you if it's some weird wrapper around another
> binary, though that wasn't too common at bell labs.
> 
> Warner

A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
another source-less v6 binary, cno. Fortunately, it hadn't been stripped but I
still did some disasembly because of the interesting differences. v6 binaries
have a different crt0 preamble and simpler subroutine setup, and I narrowed
dowh the library code to an intermediate stage of iolib (which IIRC still
exists in the UNSW archive on TUHS). There's a few cribs in that essay to help
you figure out some basic things, pdp11 assembly isn't hard to decode.

-- 
I love deadlines. I love the whooshing noise as they fly by.

From brantley at coraid.com  Wed Jan  8 06:17:22 2020
From: brantley at coraid.com (Brantley Coile)
Date: Tue, 7 Jan 2020 20:17:22 +0000
Subject: [TUHS] screen editors
In-Reply-To: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>
References: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>
Message-ID: <02159ABA-0114-4A30-A30B-F3A5104309DE@coraid.com>

No point here, other than showing the size of sam in its native Plan 9 habitat.

ehg% size /bin/sam /bin/aux/samterm
 95,514t +  8,764d + 75,868b = 180,146	/bin/sam
145,093t + 28,708d + 59,508b = 233,309	/bin/aux/samterm

The size gives me a better idea of the code complexity. For completeness, here's the size of vi on my Mac.

bwc-downtown:~ bwc$ size /usr/bin/vi
__TEXT		__DATA	__OBJC	others		dec		hex
1,585,152	163,840	0	4,295,012,352	4,296,761,344	1001b6000
	
Good thing the Mac has shared libraries? (Commas added for clarity)

Again, no point, other than a data point.

Brantley

> On Jan 7, 2020, at 2:57 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> McIlroy:
>> [vi] was so excesssive right from the start that I refused to use it.
>> Sam was the first screen editor that I deemed worthwhile, and I
>> still use it today.
> 
> Paulsen:
>> my sam build is more than 2 times bigger than Gunnar Ritter's vi
>> (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim.
> 
> % wc -c /bin/vi bin/sam bin/samterm
> 1706152 /bin/vi
> 112208 bin/sam
> 153624 bin/samterm
> These mumbers are from Red Hat Linux.
> The 6:1 discrepancy is understated because
> vi is stripped and the sam files are not.
> All are 64-bit, dynamically linked.


From dave at horsfall.org  Wed Jan  8 06:44:12 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 8 Jan 2020 07:44:12 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
 <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de>
Message-ID: <alpine.BSF.2.21.9999.2001080742350.40155@aneurin.horsfall.org>

On Tue, 7 Jan 2020, Thomas Paulsen wrote:

>> I don't recall the exact details, but there was once an editor called 
>> "em" (Editor for Mortals).  I remember thinking: what sort of an idiot 
>> would call it that, with the "e" and "r" keys adjacent to each other? 
>> I wonder how many files were lost that way...
> 
> you can download, build and use em making immediately clear that em was 
> much easier to use than ed. Nevertheless em was only (another) step in 
> between ed and vi.

I'm sure you're right, but that wasn't the point that I was making...

-- Dave

From chet.ramey at case.edu  Wed Jan  8 06:45:24 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 7 Jan 2020 15:45:24 -0500
Subject: [TUHS] screen editors
In-Reply-To: <c450d139ce71b8b89953500d8737b788@firemail.de>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <c450d139ce71b8b89953500d8737b788@firemail.de>
Message-ID: <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu>

On 1/7/20 10:50 AM, Thomas Paulsen wrote:
>> It was so excesssive right from the start that I refused to use it.
>> Sam was the first screen editor that I deemed worthwhile, and I
>> still use it today.
> my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim.

If we're really doing this editor size contest thing, I'll submit my `ce'
editor. (ftp://ftp.cwru.edu/pub/chet/ce-4.8.tar.gz). It's emacs-like, but
not particularly configurable, and the defaults, strangely enough, are
exactly what I like.

On my Mac OS X machine, it's about ten times smaller than vim

$ size /usr/local/bin/ce
__TEXT	__DATA	__OBJC	others	dec	hex
114688	339968	0	4295024640	4295479296	10007d000
$ size /usr/bin/vim
__TEXT	__DATA	__OBJC	others	dec	hex
1687552	176128	0	4295016448	4296880128	1001d3000

Similar numbers on RHEL 7, but due to the large bss, it's only about
45% smaller than vim.

Chet



-- 
``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 bakul at bitblocks.com  Wed Jan  8 06:47:19 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 07 Jan 2020 12:47:19 -0800
Subject: [TUHS] screen editors
In-Reply-To: Your message of "Tue, 07 Jan 2020 14:57:40 -0500."
 <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>
References: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>
Message-ID: <20200107204726.B0F91156E42E@mail.bitblocks.com>

On Tue, 07 Jan 2020 14:57:40 -0500 Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> McIlroy:
> > [vi] was so excesssive right from the start that I refused to use it.
> > Sam was the first screen editor that I deemed worthwhile, and I
> > still use it today.
>
> Paulsen:
> > my sam build is more than 2 times bigger than Gunnar Ritter's vi
> > (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim.
>
> % wc -c /bin/vi bin/sam bin/samterm
> 1706152 /bin/vi
>  112208 bin/sam
>  153624 bin/samterm
> These mumbers are from Red Hat Linux.
> The 6:1 discrepancy is understated because
> vi is stripped and the sam files are not.
> All are 64-bit, dynamically linked.

A source code comparison
$ cd 2bsd/src/ex		# this is a snapshot of May 9, 1979
$ wc *.c | tail -1
   17176   56138  331865 total

$ cd $PLAN9/src/cmd/		# what works today
$ wc {sam,samterm}/*.[hc] | tail -1
   11366   27236  201666 total

$ cd /usr/src/contrib/nvi	# what works today
$ wc */*.[ch] | tail -1
   51978  202926 1297043 total	# actual count is slightly smaller

I use nvi or acme. Haven't touched sam in ages. Having taught
my fingertips nvi 37 years back, I can edit the fastest in it.
But some things are easier in acme + with its multiple panes
and smaller antialiased fonts it makes much better use of a
retina display. iterm/screen + nvi can't match that.

Until about 95 I used nvi & the Rand Editor (later Dave Yost's
version). The latter was the easiest to use + it did multiple
editing windows much before nvi or vim.

From clemc at ccc.com  Wed Jan  8 07:08:08 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 7 Jan 2020 16:08:08 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <20200107200447.GA3211@mail.ewe2.ninja>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
 <20200107200447.GA3211@mail.ewe2.ninja>
Message-ID: <CAC20D2OjRhR+31QyN8MAuKbKsYDPE1JFX37pgmQQaSE_HLBSMw@mail.gmail.com>

Nice job -- one comment:  You said at the end of your document:

"Both cno and phx were written at what appears to have been what I would
call v6b, version 6 as the standard library was moving from libS to libc,
as Dennis Ritchie formalised the library proper. This can be seen in crt0.s
where the form is not of standard V6 but of the libc V6 before it became
standard in V7 and changed yet again. I was able to track this using the
UNSW archives which have both libraries at the critical point."


I will place a bet it is not your v6b idea...  (which was basically V6 plus
Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
which was based on V6 too -- made it into the wild in a couple of places).
Anyway, I think you are seeing code output from what was called the
'Typesetter C" compiler release which came out before V7 and was needed to
compile troff *et al.*  which actually what conforms with the original
K&R.   Indeed, that compiler used libS as the library.

The other thing, many v6 implementations (like CMU's and I think MIT) had a
preprocessor (it was called /lib/cpp ) before we got Typesetter C.  i.e. a
version of cpp that predated the Riesner cpp rewrite that was in Typesetter
C and later V7.  Steve Johnson probably knows the history of the
preprocessor better than I.   I know when we went through the V5 to V6
upgrade we somehow had a preprocessor.   I remember being curious about it
and then being disappointed it was not as good as the BLISS macro facility.

But ... neither the binary nor the sources for that cpp are in Warner's
Archives for V6 when I just looked.

The Interdata 7/32 stuff Warren has is a V6 port, and has a version of cpp,
but a note in the source says it is based on what looks like the Typesetter
C compiler - which was sometimes called the Level 7 compiler because Dennis
had told us all it was the new compiler for the next releases (TS and V7).

PWB 1.0 has a copy of cpp in the sources, but a quick look its not clear
how close the V7 version it is.

So, unless anyone else can illuminate, I'm not sure where the first cpp
that some of us using v6 had originated.

On Tue, Jan 7, 2020 at 3:14 PM Sean Dwyer via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote:
> > On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn at gmail.com> wrote:
> >
> > > On 1/6/20 12:29 PM, Warner Losh wrote:
> > >
> > > The good news is that disassembly will tell you right away if it was
> > > written in C or not.
> > >
> > >
> > > OK. I give up. How?
> > >
> >
> > Generally, the C compiler generates code that's quite distinctive (at
> least
> > PCC does, not sure about Dennis' compiler). People writing free assembler
> > tend to do really weird things for function entry / return.
> >
> > And it will likely tell you if it's some weird wrapper around another
> > binary, though that wasn't too common at bell labs.
> >
> > Warner
>
> A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
> another source-less v6 binary, cno. Fortunately, it hadn't been stripped
> but I
> still did some disasembly because of the interesting differences. v6
> binaries
> have a different crt0 preamble and simpler subroutine setup, and I narrowed
> dowh the library code to an intermediate stage of iolib (which IIRC still
> exists in the UNSW archive on TUHS). There's a few cribs in that essay to
> help
> you figure out some basic things, pdp11 assembly isn't hard to decode.
>
> --
> I love deadlines. I love the whooshing noise as they fly by.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/7afabdbb/attachment.html>

From dfawcus+lists-tuhs at employees.org  Wed Jan  8 07:20:13 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 7 Jan 2020 21:20:13 +0000
Subject: [TUHS] screen editors
In-Reply-To: <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <c450d139ce71b8b89953500d8737b788@firemail.de>
 <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu>
Message-ID: <20200107212013.GA17953@clarinet.employees.org>

On Tue, Jan 07, 2020 at 03:45:24PM -0500, Chet Ramey wrote:
> On my Mac OS X machine, it's about ten times smaller than vim
> 
> $ size /usr/local/bin/ce
> __TEXT	__DATA	__OBJC	others	dec	hex
> 114688	339968	0	4295024640	4295479296	10007d000
> $ size /usr/bin/vim
> __TEXT	__DATA	__OBJC	others	dec	hex
> 1687552	176128	0	4295016448	4296880128	1001d3000
> 
> Similar numbers on RHEL 7, but due to the large bss, it's only about
> 45% smaller than vim.

So I got curious about those large numbers on the mac, and made use of 'otool -l'.

It would seem that the values for __DATA reported by size correspond to the overall
size of the 'load command' for the __DATA segment, and so includes bss as well.

$ ls -l /usr/bin/vim
-rwxr-xr-x  1 root  wheel  1530064 29 Jun  2018 /usr/bin/vim

So 'size' on the mac is not so useful, but 'size -m /usr/bin/vim' gives
information from which one could derive the normal 'size' output.

$ size -m /usr/bin/vim
Segment __PAGEZERO: 4294967296
Segment __TEXT: 1388544
	Section __text: 1271745
	Section __stubs: 1044
	Section __stub_helper: 1756
	Section __cstring: 85892
	Section __const: 14672
	Section __unwind_info: 8944
	total 1384053
Segment __DATA: 155648
	Section __got: 1056
	Section __nl_symbol_ptr: 16
	Section __la_symbol_ptr: 1392
	Section __const: 38608
	Section __data: 64432
	Section __bss: 42520
	Section __common: 5720
	total 153744
Segment __LINKEDIT: 36864
total 4296548352

DF

From dave at horsfall.org  Wed Jan  8 08:13:39 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 8 Jan 2020 09:13:39 +1100 (EST)
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <CAC20D2NhDGjGqOEZH0EDGf6cHHOWRvC0tLy40QNEkf9ETxyj7A@mail.gmail.com>
References: <202001060630.0066U7U7023760@cuzuco.com>
 <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
 <CAC20D2NhDGjGqOEZH0EDGf6cHHOWRvC0tLy40QNEkf9ETxyj7A@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2001080911390.40155@aneurin.horsfall.org>

On Tue, 7 Jan 2020, Clem Cole wrote:

> Algol-W   From, the Sites book, (Page 10, Section 1 'Terminology)  [Dave,
> I'll send you the PDF offline]. 

For the record, it was received OK; thanks!

>             The symbol comment followed by any sequence of
>             characters not -containing semicolons, followed by a
>             semicolon, is called a comment. A comment has no
>             effect on the meaning of a program, and is ignored
>             during execution of the program. 

For the benefit of the OP, here is no mention of "#" being a comment in 
ALGOL(W).

-- Dave

From bakul at bitblocks.com  Wed Jan  8 08:26:52 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 7 Jan 2020 14:26:52 -0800
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
Message-ID: <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com>

> On Jan 6, 2020, at 2:51 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Mon, 6 Jan 2020, Brian Walden wrote:
> 
>> Also before you say wait! ALGOL uses # as comment and is older than Kernighan' ratfor(1). [...]
> 
> Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I loved using; I wish I still had my ALGOLW book)?

In Algol68  # ... # is one of the forms for block comments!

From reed at reedmedia.net  Wed Jan  8 08:22:41 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Tue, 7 Jan 2020 16:22:41 -0600 (CST)
Subject: [TUHS] What happened with XENIX? (was Re:  Unix/World Magazines)
In-Reply-To: <20200107105615.GA16081@minnie.tuhs.org>
References: <20200107105615.GA16081@minnie.tuhs.org>
Message-ID: <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>

On Tue, 7 Jan 2020, Warren Toomey wrote:

> All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org.

Thanks!

November 1985 issue has an article by Bill Gates.

Gates wrote that they were optimistic to achieve 400,000 XENIX 
installations -- their critical mass -- within 18 months.

"... IBM has announced XENIX as the multi-user operating sysytem for the 
IBM PC-AT."

"Significantly, at the time the XENIX project was started [mid 1980], 
the IBM Personal Computer had not been announced."

What happened with XENIX?  I know it had some success (I used at least 
one retired system with it), but nothing near the other offerings on the 
PC family.

From dave at horsfall.org  Wed Jan  8 08:56:26 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 8 Jan 2020 09:56:26 +1100 (EST)
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com>
References: <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
 <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com>
Message-ID: <alpine.BSF.2.21.9999.2001080945590.40155@aneurin.horsfall.org>

On Tue, 7 Jan 2020, Bakul Shah wrote:

> In Algol68  # ... # is one of the forms for block comments!

Interesting...  All we had at university though was ALGOL W (as far as I 
know; there were several languages that mere students could not use, such 
as FORTRAN H).

-- Dave

From dave at horsfall.org  Wed Jan  8 09:12:23 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 8 Jan 2020 10:12:23 +1100 (EST)
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
Message-ID: <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>

On Tue, 7 Jan 2020, reed at reedmedia.net wrote:

[...]

> What happened with XENIX?  I know it had some success (I used at least 
> one retired system with it), but nothing near the other offerings on the 
> PC family.

I was forced to use Xenix for a contracting job (and hated it, as it was 
almost-but-not-quite-Unix, and the differences annoyed me).  Wouldn't 
Linux have arrived at around that time?

-- Dave

From pete at pski.net  Wed Jan  8 09:21:11 2020
From: pete at pski.net (Peter Cetinski)
Date: Tue, 7 Jan 2020 18:21:11 -0500
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
Message-ID: <EE9711F7-B378-4A5B-8D55-BA6C4F558EC9@pski.net>


> On Jan 7, 2020, at 5:22 PM, reed at reedmedia.net wrote:
> 
> What happened with XENIX?  I know it had some success (I used at least 
> one retired system with it), but nothing near the other offerings on the 
> PC family.

XENIX was staged for greatness until Microsoft decided they did not want to be subject to the AT&T license long term with all the potential issues that could arise by not being in complete control of their operating system.


From imp at bsdimp.com  Wed Jan  8 09:27:30 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 7 Jan 2020 16:27:30 -0700
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
Message-ID: <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>

On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Tue, 7 Jan 2020, reed at reedmedia.net wrote:
>
> [...]
>
> > What happened with XENIX?  I know it had some success (I used at least
> > one retired system with it), but nothing near the other offerings on the
> > PC family.
>
> I was forced to use Xenix for a contracting job (and hated it, as it was
> almost-but-not-quite-Unix, and the differences annoyed me).  Wouldn't
> Linux have arrived at around that time?
>

These mags are from 84 and 85. Linux wasn't really viable until 92 or so.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/a778bb42/attachment.html>

From athornton at gmail.com  Wed Jan  8 09:36:15 2020
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 7 Jan 2020 16:36:15 -0700
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
Message-ID: <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>

Hell, Linux didn't exist at all till '91.

I think Xenix was more just a casualty of the Unix Wars.  The victors there
were SunOS/Solaris, AIX, and HP-UX.  There were a bunch more walking
wounded that never really achieved much market share.

By the time SCO filed suit in 2003, not only were the Unix Wars fairly long
over (SCO had lost), but commercial Unixes had largely been supplanted by
Linux (and BSD enthusiasts had three free options, and OS X was a thing if
you wanted a commercial BSD, but Apple never managed to make much in the
way of inroads into the server market).  Linux's ascendency happened around
the turn of the millennium, as I recall, although I was using AIX at my job
as late as 2010-2011, and I presume the Big Several still exist in some
form or other.

On Tue, Jan 7, 2020 at 4:28 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Tue, 7 Jan 2020, reed at reedmedia.net wrote:
>>
>> [...]
>>
>> > What happened with XENIX?  I know it had some success (I used at least
>> > one retired system with it), but nothing near the other offerings on
>> the
>> > PC family.
>>
>> I was forced to use Xenix for a contracting job (and hated it, as it was
>> almost-but-not-quite-Unix, and the differences annoyed me).  Wouldn't
>> Linux have arrived at around that time?
>>
>
> These mags are from 84 and 85. Linux wasn't really viable until 92 or so.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/d4d282e3/attachment.html>

From jon at fourwinds.com  Wed Jan  8 10:10:25 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 07 Jan 2020 16:10:25 -0800
Subject: [TUHS] screen editors
In-Reply-To: <202001071630.007GUrBj030452@freefriends.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
Message-ID: <202001080010.0080APtC1678972@darkstar.fourwinds.com>

arnold at skeeve.com writes:
> Larry McVoy <lm at mcvoy.com> wrote:
>
> > I'm a vi guy to this day.  Love it.

I'm a vi guy these days.  My first screen editor was something called DTE
for Display Terminal Editor written by Dick Hause that ran on the Glance G
terminals hooked our Honeywell 516 running 516-TSS.  I have some vague
recollection of at least one of these terminals ending up in the attic in
the UNIX room, but I don't think that the editor was ever ported.  It was
painful to have to use ed or the 516-TSS equivalent when a terminal wasn't
available.  Vi was an easy transition because the ed commands could be used
until the fancier stuff was learned.  Also because that great vi trainer
program rogue existed :-)

Jon

From grog at lemis.com  Wed Jan  8 10:50:06 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 8 Jan 2020 11:50:06 +1100
Subject: [TUHS] IBM PC and XENIX (was: What happened with XENIX? (was Re:
 Unix/World Magazines))
In-Reply-To: <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
Message-ID: <20200108005006.GL64020@eureka.lemis.com>

On Tuesday,  7 January 2020 at 16:22:41 -0600, reed at reedmedia.net wrote:
> On Tue, 7 Jan 2020, Warren Toomey wrote:
>
>> All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org.
>
> Thanks!
>
> November 1985 issue has an article by Bill Gates.
>
> Gates wrote that they were optimistic to achieve 400,000 XENIX
> installations -- their critical mass -- within 18 months.
>
> "... IBM has announced XENIX as the multi-user operating sysytem for the
> IBM PC-AT."

XENIX was initially targeted for the PDP-11, for some reason beyond my
understanding.  Looking at the Wikipedia page, it seems that the first
Intel ports were not aimed at the PC-AT.

> "Significantly, at the time the XENIX project was started [mid 1980],
> the IBM Personal Computer had not been announced."

You don't say where this quote comes from.  The use of pluperfect
suggests that it's not from the Unix/World article.  The PC was
announced in August 1981, and the PC-AT was released in August 1984,
so the date of the article fits well.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/cb676790/attachment.sig>

From grog at lemis.com  Wed Jan  8 10:44:34 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 8 Jan 2020 11:44:34 +1100
Subject: [TUHS] XENIX and Linux (was: What happened with XENIX? (was Re:
 Unix/World Magazines))
In-Reply-To: <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
Message-ID: <20200108004434.GK64020@eureka.lemis.com>

On Wednesday,  8 January 2020 at 10:12:23 +1100, Dave Horsfall wrote:
> On Tue, 7 Jan 2020, reed at reedmedia.net wrote:
>
> [...]
>
>> What happened with XENIX?  I know it had some success (I used at least
>> one retired system with it), but nothing near the other offerings on the
>> PC family.
>
> I was forced to use Xenix for a contracting job (and hated it, as it
> was almost-but-not-quite-Unix, and the differences annoyed me).

I did so too in the early 1990s, using (IIRC) "XENIX System V", an
attempt to retrofit some System V features to XENIX.  It was very
limited: it ran in Intel 80386 real mode, so it was limited to 16 MB
of memory.  The toolchain was excruciating.  I think it was based on
Microsoft products, and I soon replaced them with GNU software, which
had its problems on the platform.  The good news: it worked.

> Wouldn't Linux have arrived at around that time?

You don't say your time.  Referring to Jeremy's original message (time
frame mid-1980s), no, Linus would have been about 14 at the time.  He
made the first announcement of what would become Linux on 25 August
1991 (“just a hobby, won't be big and professional like gnu").  So
yes, it was available when I was doing my XENIX work.  So was BSD/386,
which is what I was using at the time.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/3471ee2f/attachment.sig>

From woods at robohack.ca  Wed Jan  8 12:44:47 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 07 Jan 2020 18:44:47 -0800
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <CANCZdfqsBFwxwjb5kEnE6FTGgAA4ZH_L_AqyB4A1eoUeEoL1Gg@mail.gmail.com>
References: <202001060630.0066U7U7023760@cuzuco.com>
 <alpine.BSF.2.21.9999.2001070936580.40155@aneurin.horsfall.org>
 <CANCZdfqsBFwxwjb5kEnE6FTGgAA4ZH_L_AqyB4A1eoUeEoL1Gg@mail.gmail.com>
Message-ID: <m1ip1Ky-0036tPC@more.local>

At Mon, 6 Jan 2020 17:39:39 -0700, Warner Losh <imp at bsdimp.com> wrote:
Subject: Re: [TUHS] # (was Re: sh: cmd | >file)
>
>
> Or you might have cut and paste the commands from a script to test
> something, or to redo something by hand that failed for some reason.

Cut & Paste?

Most of us couldn't do that until the very late 1980's at earliest!

The poor man's cut&paste was to do something like 'sed -n 3,9p script |
sh', but I don't think I ever did that with csh in the days when a '#'
comment was for scripts only, so I don't know if old csh treated a pipe
on stdin as a script or not.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200107/9d5b8b69/attachment.sig>

From reed at reedmedia.net  Wed Jan  8 12:58:04 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Tue, 7 Jan 2020 20:58:04 -0600 (CST)
Subject: [TUHS] IBM PC and XENIX (was: What happened with XENIX? (was
 Re: Unix/World Magazines))
In-Reply-To: <20200108005006.GL64020@eureka.lemis.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <20200108005006.GL64020@eureka.lemis.com>
Message-ID: <alpine.NEB.2.21.2001072056120.50@t1.m.reedmedia.net>

On Wed, 8 Jan 2020, Greg 'groggy' Lehey wrote:

> On Tuesday,  7 January 2020 at 16:22:41 -0600, reed at reedmedia.net wrote:

> > November 1985 issue has an article by Bill Gates.

> > "Significantly, at the time the XENIX project was started [mid 1980],
> > the IBM Personal Computer had not been announced."
> 
> You don't say where this quote comes from.  The use of pluperfect
> suggests that it's not from the Unix/World article.  The PC was
> announced in August 1981, and the PC-AT was released in August 1984,
> so the date of the article fits well.

It was from the magazine. I added the brackets for the date which came 
from an earlier sentence in the article.

From vanattenmark at gmail.com  Wed Jan  8 15:13:52 2020
From: vanattenmark at gmail.com (Mark van Atten)
Date: Wed, 8 Jan 2020 06:13:52 +0100
Subject: [TUHS] screen editors
In-Reply-To: <CA+cCjXpDJ5xufnfnjmRDTTcy+OYVCg1SMNouOHrvmxJA9NwPOw@mail.gmail.com>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <17372ca2-0498-4320-a933-5ac522eabb2b@localhost>
 <CA+cCjXpDJ5xufnfnjmRDTTcy+OYVCg1SMNouOHrvmxJA9NwPOw@mail.gmail.com>
Message-ID: <CALAsyW2g=ChJTvywy6Zp87jM8HDO8uHTyQztAO=gj+OWcgYuEQ@mail.gmail.com>

On Tue, 7 Jan 2020 at 20:36, Rodrigo G. López <rodrigosloop at gmail.com> wrote:
>
> i like to use it natively as much as possible, especially the 9front edition with its usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into some cpu or a local vm where i can get a little environment to work with whatever is at /mnt/term.

In the opposite direction of your preference for a native environment:
A port of 9front sam (with chording) to unix is available at
https://bitbucket.org/iru/sam9f-unix/src/default/

I use it as a drop-in replacement for the plan9port version.

> it has given me the best text editing and programming experience i've ever had.

For most types of editing I have come to prefer it over acme. The one
modification I should, perhaps, like to see is the possibility to
scroll the window while selecting. Rob Pike has made some comments on
the difficulty here; see the quotations and links in the discussion at
https://github.com/deadpixi/sam/issues/85
(incidentally, on the github pages of another fairly recent port of sam.)

A proposal for a (GSOC) project to improve sam scrolling:
http://fqa.9front.org/appendixg.html

Mark.

From tuhs at cuzuco.com  Wed Jan  8 15:20:39 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Wed, 8 Jan 2020 00:20:39 -0500 (EST)
Subject: [TUHS] # (was Re: sh: cmd | >file)
Message-ID: <202001080520.0085KdTi008574@cuzuco.com>

Dave Horsfall wrote:
>On Tue, 7 Jan 2020, Bakul Shah wrote:
>
>> In Algol68  # ... # is one of the forms for block comments!
>
>Interesting...  All we had at university though was ALGOL W (as far as I
>know; there were several languages that mere students could not use, such
>as FORTRAN H).

Yes, but when was it implemented? Kernighan is first ever if it is not
before 1974. So I decided to look and it took me down a rabbit hole of
ALGOL taht leads back to Bourne shell and then right back to # (but in C)

By reading the ALGOL 68 wiki page, the laguange seemed to have had a
character set problem since day one, and it seems if you didn't have the
cent-sign you were to use PR for pragmat for comments. And since it
had problems it was continually extened. I just cant find when # was defined.

I looked at various old implementations (none pre 1974 list #) --

- CDC's ALGOL 68 compiler from 1975 you could only use use PR .. PR
  (both # and CO were not defined)
   http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/Algol_68_version_1_Reference_Manual_RevB.pdf

- The official revised ALGOL86 spec from 1978 lists all these ways to enter
  them (bottom of page 112) in this order --
  brief comment symbol:         cent-sign
  bold comment symbol:          comment
  style 1 comment symbol:       co
  style 2 comment symbol:       #
  bold pragmat symbol:          pragmat
  style 1 pragmat symbol:       pr
  seeing # is "style 2" it looks like a later extention to me
  http://www.softwarepreservation.org/projects/ALGOL/report/Algol68_revised_report-AB.pdf

- ALGOL68/19 from 1975 list these 4 symbols as comments: # % co pr
  http://www.softwarepreservation.org/projects/ALGOL/manual/Gennart_Louis-Algol_         68_19_Reference_Manual.pdf

- DECs ALGOL (1976 printing but first released was 1971) for system10 uses
  a ! for a comment as # means "not equal" --
  http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-LALMA-B-D%20         decsystem10%20ALGOL%20Programmer's%20Reference%20Manual.pdf

- CMU's ALGOL68S from 1978 list all these ways --
  co            comment
  comment       comment
  pr            pragmat
  pragmat       pragmat
  #             (comment symbol) comment
  ::            (pragmat symbol) pragmat
  (its for UNIX v6 or v7 so not surprising # is a comment)
  http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view

- Rutgers ALGOL 68 interprter from 1987 for UNIX does not implement
  PR nor PRAMAT and says comments are # CO or COMMENT
  https://www.renyi.hu/~csirmaz/algol-68/linux/manual

I could not find a freely accessible manual for ALGOL68R (very 1st one) nor
Cambridge's ALGOL68C. What's intresting here is Stephen Bourne was on the
team that made ALGOL68C before he move to Bell Labs. It'd be pretty funny
if he implemented a language that there were 7 or 8 ways to enter a comment
(cent, co, comment, pr, pragmat, #, ::, %) yet there were zero ways
to enter a comment in the Bourne shell.

Also the style of "COMMENT put a note here COMMENT" is very un-ALGOL like
(with DO .. OD, IF .. FI) shouldn't it be like this?
    COMMENT put a note here TNEMMOC
    CO put a note here OC
    PRAGMAT directive here TAMGARP
    PR directive here RP

So then I remembered Bourne used the C preprocssor to make C like ALGOL when
he wrote the shell. If you've never seen it, his C looks like this --

case TSW:
        BEGIN
           REG STRING   r = mactrim(t->swarg);
           t=t->swlst;
           WHILE t
           DO   ARGPTR          rex=t->regptr;
                WHILE rex
                DO      REG STRING      s;
                        IF gmatch(r,s=macro(rex->argval)) ORF (trim(s), eq(r,s))
                        THEN    execute(t->regcom,0);
                                t=0; break;
                        ELSE    rex=rex->argnxt;
                        FI
                OD
                IF t THEN t=t->regnxt FI
           OD
        END
        break;
ENDSW

So I wanted to see if he remapped C comments /* */
I am not even sure you could even do that with the C preprocessor
but took alook anywy and in
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/xec.c
It's first lines are this --

#
/*
 * UNIX shell
 *
 * S. R. Bourne
 * Bell Telephone Laboratories
 *
 */

#include        "defs.h"
#include        "sym.h"

So nope, just regular C comments (which came from PL/I btw which was
what multics was programmed in)

But look! The very first line of that file! It is
a single # sitting all by itself.  Why? you ask. Well this is a hold
over from when the C preprocessor was new. C orginally did not
have it and was added later. PL/I had a %INCLUDE so Ritchie eventaully
made a #include -- but pre 7th Edition the C preprocessor would not be
inkoved unless the very first character of the C source file was an #
Since v7 the preprocessor always run on it. The first C preprocessor
was Ritchie's work with no nested includes and no macros. v7's was by
John Reiser which added those parts.

that 1st line with a single # sitting by itself reminds me of the
csh construct as well.
-Brian

From bakul at bitblocks.com  Wed Jan  8 16:25:39 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 7 Jan 2020 22:25:39 -0800
Subject: [TUHS] # (was Re: sh: cmd | >file)
In-Reply-To: <202001080520.0085KdTi008574@cuzuco.com>
References: <202001080520.0085KdTi008574@cuzuco.com>
Message-ID: <CAE17BA2-C3E4-4EA2-B174-F23624340356@bitblocks.com>

> On Jan 7, 2020, at 9:20 PM, Brian Walden <tuhs at cuzuco.com> wrote:
> 
> Dave Horsfall wrote:
>> On Tue, 7 Jan 2020, Bakul Shah wrote:
>> 
>>> In Algol68  # ... # is one of the forms for block comments!
>> 
>> Interesting...  All we had at university though was ALGOL W (as far as I
>> know; there were several languages that mere students could not use, such
>> as FORTRAN H).
> 
> Yes, but when was it implemented? Kernighan is first ever if it is not
> before 1974. So I decided to look and it took me down a rabbit hole of
> ALGOL taht leads back to Bourne shell and then right back to # (but in C)

Tanenbaum’s “A tutorial on Algol 68” published in Computing Surveys, June 1976
mentions that # is one of the (four) ways a comment may be enclosed.

https://research.vu.nl/ws/portalfiles/portal/74119499/11057

An earlier paper “Algol68 with fewer tears” by C H Lindsey, 1972
also mentions # as an alternate symbol.

https://academic.oup.com/comjnl/article-pdf/15/2/176/1002964/15-2-176.pdf


From ewe2 at ewe2.ninja  Wed Jan  8 16:35:20 2020
From: ewe2 at ewe2.ninja (Sean Dwyer)
Date: Wed, 8 Jan 2020 01:35:20 -0500
Subject: [TUHS] wump.c for v6
In-Reply-To: <CAC20D2OjRhR+31QyN8MAuKbKsYDPE1JFX37pgmQQaSE_HLBSMw@mail.gmail.com>
References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com>
 <CAC20D2MbCHSgfRr4PJWofsx8+_jOaAGuR=80L8qmkTvY1afyNg@mail.gmail.com>
 <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com>
 <CAC20D2PEG6RX0eygd0jAK9+U79DC2yayjNSyi6bquZs=dT5YiA@mail.gmail.com>
 <CANCZdfrryN7iaHsSF0Wpdd6-t55mWia-BReC_chiEVw9GHQ9ng@mail.gmail.com>
 <ca32965e-2b2f-83ce-2403-7c99a03e2eb1@gmail.com>
 <CANCZdfoEhGBzy13mGvw8jJNz0pvYVjBFy3-9BQ0mN8-4HB7bLw@mail.gmail.com>
 <20200107200447.GA3211@mail.ewe2.ninja>
 <CAC20D2OjRhR+31QyN8MAuKbKsYDPE1JFX37pgmQQaSE_HLBSMw@mail.gmail.com>
Message-ID: <20200108063520.GA24350@mail.ewe2.ninja>

On Tue, Jan 07, 2020 at 04:08:08PM -0500, Clem Cole wrote:

> I will place a bet it is not your v6b idea...  (which was basically V6 plus
> Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
> which was based on V6 too -- made it into the wild in a couple of places).
> Anyway, I think you are seeing code output from what was called the
> 'Typesetter C" compiler release which came out before V7 and was needed to
> compile troff *et al.*  which actually what conforms with the original
> K&R.   Indeed, that compiler used libS as the library.
 
Ahh, that adds an extra wrinkle to the proceedings :) I wasn't aware of this
version, I was just going on what I disassembled and what I could dig up from
unix sources, but neither am I too surprised that there were intermediate
steps in between!

> So, unless anyone else can illuminate, I'm not sure where the first cpp
> that some of us using v6 had originated.
> 

It is as you note, a very confused picture where there was a lot of activity
from several different sources. It's pretty amazing to look at the UNSW and
Usenet archives and see the sheer volume of device and library hacks that were
going on during the v5 and v6 period alone.

On a related question, do we know that sources for code such as the ching
binaries was at least around at the time of the 32V port? I'm unsure when the
sources were lost, was that after V7? A reason I ask is that phx basically
remained untouched but the 32V version of cno was definitely changed in the
early BSDs, although it may have been a binary patch.

-- 
I love deadlines. I love the whooshing noise as they fly by.

From thomas.paulsen at firemail.de  Wed Jan  8 17:39:40 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 08 Jan 2020 08:39:40 +0100
Subject: [TUHS] screen editors
Message-ID: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>

>What's funny is that in doing the work to get 'se' running on Georgia
>Tech's Vax, I had to learn vi.  By the time I was done, vi had become
>my main editor and had burned itself into my finger's ROMs.
I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. 



From thomas.paulsen at firemail.de  Wed Jan  8 17:46:22 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 08 Jan 2020 08:46:22 +0100
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
 <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
Message-ID: <81a090b1892b04644c0357805bb75440@firemail.de>

>Hell, Linux didn't exist at all till '91.
>I think Xenix was more just a casualty of the Unix Wars.  The victors there
>were SunOS/Solaris, AIX, and HP-UX.  There were a bunch more walking
>wounded that never really achieved much market share.
'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.'
https://en.wikipedia.org/wiki/Xenix



From thomas.paulsen at firemail.de  Wed Jan  8 17:46:41 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 08 Jan 2020 08:46:41 +0100
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
 <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
Message-ID: <5ce956d171c04ef8c249d3ab7b1ce46b@firemail.de>


--- Ursprüngliche Nachricht ---
Von: Adam Thornton <athornton at gmail.com>
Datum: 08.01.2020 00:36:15
An: Warner Losh <imp at bsdimp.com>,  The Eunuchs Hysterical Society <tuhs at tuhs.org>
Betreff: Re: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)

Hell, Linux didn't exist at all till '91.

I think Xenix was more just a casualty of the Unix Wars.  The victors there

were SunOS/Solaris, AIX, and HP-UX.  There were a bunch more walking
wounded that never really achieved much market share.

By the time SCO filed suit in 2003, not only were the Unix Wars fairly long

over (SCO had lost), but commercial Unixes had largely been supplanted by

Linux (and BSD enthusiasts had three free options, and OS X was a thing if

you wanted a commercial BSD, but Apple never managed to make much in the

way of inroads into the server market).  Linux's ascendency happened around

the turn of the millennium, as I recall, although I was using AIX at my job

as late as 2010-2011, and I presume the Big Several still exist in some
form or other.

On Tue, Jan 7, 2020 at 4:28 PM Warner Losh <imp at bsdimp.com> wrote:


>
>
> On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall <dave at horsfall.org>
wrote:
>
>> On Tue, 7 Jan 2020, reed at reedmedia.net wrote:
>>
>> [...]
>>
>> > What happened with XENIX?  I know it had some success (I used
at least
>> > one retired system with it), but nothing near the other offerings
on
>> the
>> > PC family.
>>
>> I was forced to use Xenix for a contracting job (and hated it, as
it was
>> almost-but-not-quite-Unix, and the differences annoyed me).  Wouldn't

>> Linux have arrived at around that time?
>>
>
> These mags are from 84 and 85. Linux wasn't really viable until 92 or
so.
>
> Warner
>




From pnr at planet.nl  Wed Jan  8 19:18:13 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 8 Jan 2020 10:18:13 +0100
Subject: [TUHS] What happened with XENIX?
Message-ID: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl>

This web page has some details about XENIX prior to 1985:
http://seefigure1.com/2014/04/15/xenixtime.html

In particular this chart is intriguing:
http://seefigure1.com/images/xenix/xenix-timeline.jpg

I’d love to have XENIX from the 1980-1985 era in the TUHS archive, as it documents the tail end of the Unix on 16 bits era. It would have been great if MS had released that as part of the Unix-at-50 events.

Paul


From rudi.j.blom at gmail.com  Wed Jan  8 19:46:59 2020
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Wed, 8 Jan 2020 16:46:59 +0700
Subject: [TUHS] screen editors
Message-ID: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>

>Date: Tue, 07 Jan 2020 14:57:40 -0500.
>From: Doug McIlroy <>
>To: tuhs at tuhs.org, thomas.paulsen at firemail.de
>Subject: Re: [TUHS] screen editors
>Message-ID: <202001071957.007JveQu169574 at coolidge.cs.dartmouth.edu>
>Content-Type: text/plain; charset=us-ascii

.. snip ..

>% wc -c /bin/vi bin/sam bin/samterm
>1706152 /bin/vi
> 112208 bin/sam
> 153624 bin/samterm
>These mumbers are from Red Hat Linux.
>The 6:1 discrepancy is understated because
>vi is stripped and the sam files are not.
>All are 64-bit, dynamically linked.

That's a real big vi in RHL. Looking at a few (commercial) unixes I get

SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
 - /usr/bin/vi: iAPX 386 executable
Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
 - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
sticky executable or object module stripped - version 3.13-14
HP-UX 11.31 748996 Aug 28 2009 /bin/vi
 -- /bin/vi: ELF-32 executable object file - IA64

From michael at kjorling.se  Wed Jan  8 22:18:01 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 8 Jan 2020 12:18:01 +0000
Subject: [TUHS] What happened with XENIX?
In-Reply-To: <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
Message-ID: <7zxjn49rcpnbpgv7zbq4rxgv@localhost>

On 7 Jan 2020 16:22 -0600, from reed at reedmedia.net:
> "Significantly, at the time the XENIX project was started [mid 1980], 
> the IBM Personal Computer had not been announced."

Perhaps even more significantly in this case, but possibly not
publicly known at the time, IBM's Project Chess, which resulted in the
IBM PC, apparently began in July 1980. (The promise was to develop an
initial prototype in 30 days, and a working personal computer in a
year; the initial demo was in August, the first internal demo in
January 1981, and product release was in August 1981.)

https://en.wikipedia.org/wiki/IBM_Personal_Computer#Project_Chess

So by "mid 1980", what would eventually lead up to the IBM PC was at
most _just barely_ getting started.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From mrudge at ubuntu.com  Wed Jan  8 22:40:27 2020
From: mrudge at ubuntu.com (Matt Rudge)
Date: Wed, 8 Jan 2020 12:40:27 +0000
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <81a090b1892b04644c0357805bb75440@firemail.de>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
 <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
 <81a090b1892b04644c0357805bb75440@firemail.de>
Message-ID: <CAErawUOgh8YmPDNW1u02DvpqK3N-oE=ZRhOpCxEYOueswXzE2g@mail.gmail.com>

On Wed, 8 Jan 2020 at 07:48, Thomas Paulsen <thomas.paulsen at firemail.de> wrote:
>
> >Hell, Linux didn't exist at all till '91.
> >I think Xenix was more just a casualty of the Unix Wars.  The victors there
> >were SunOS/Solaris, AIX, and HP-UX.  There were a bunch more walking
> >wounded that never really achieved much market share.
> 'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.'
> https://en.wikipedia.org/wiki/Xenix
>

I do remember supporting a small Xenix userbase in the mid-90's in
southeast Ireland. Mostly in law offices, surprisingly. They were very
resilient, usually running on a Wang PC-02 with greenscreen terminals
(Wyse, I think). Although they worked fine for their intended purpose
(word processing etc.), the allure of Windows was their demise.

From ron at ronnatalie.com  Wed Jan  8 22:46:13 2020
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 8 Jan 2020 07:46:13 -0500
Subject: [TUHS] What happened with XENIX?
In-Reply-To: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl>
References: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl>
Message-ID: <F8C4C1DC-DFE6-4180-BB38-3FAD86E8A033@ronnatalie.com>

One of my first contracts with IBM was to add (get this) a SECOND network interface to secure-XENIX, an MLS version of the software.
I believe it was being used as a “downgrade” audit station to allow data to be moved form one secure network to another.    I believe the
original work was done by Jakob Recktor (probably butchering the spelling of his name).

That contract led to a few follow ons with IBM to port AIX to i860 based machines.    I still have my old IBM badge kicking around somewhere.


From chet.ramey at case.edu  Thu Jan  9 00:15:11 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 8 Jan 2020 09:15:11 -0500
Subject: [TUHS] screen editors
In-Reply-To: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
Message-ID: <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>

On 1/8/20 4:46 AM, Rudi Blom wrote:

> That's a real big vi in RHL. 

It's vim.


-- 
``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 steffen at sdaoden.eu  Thu Jan  9 01:15:47 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 08 Jan 2020 16:15:47 +0100
Subject: [TUHS] screen editors
In-Reply-To: <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
Message-ID: <20200108151547.4uumD%steffen@sdaoden.eu>

Chet Ramey wrote in <bbeafd3f-786c-fe60-cf87-0f7e202025f7 at case.edu>:
 |On 1/8/20 4:46 AM, Rudi Blom wrote:
 |> That's a real big vi in RHL. 
 |
 |It's vim.

It is a tremendous effort of Bram Moolenaar and the vim
contributors to maintain this codebase that can be configured in
uncountable ways, just looking at the pre-configured feature sets
that exist lead to tiny, small, normal, big and huge.
As far as i know it has real support for languages of the world,
which is a different thing than being UTF-8 all through the
engine.  (But i think emacs is better here, i see one markable
emacs developer taking care on the Unicode list, regarding real
BiDi support, for example.)

With all my sympathy for pico at first and for long, then mg / ee
/ nano / jupp etc., and with my repeated tries to switch over to
vile, in the last two decades i always came back home to vim, for
the one thing or the other.  Two endless loops in all this time.
I only use the smallest thinkable subsets of features, though.
(Only lumberjack-style editing here, anyway.)

--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 cym224 at gmail.com  Thu Jan  9 01:11:47 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 8 Jan 2020 10:11:47 -0500
Subject: [TUHS] screen editors
In-Reply-To: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
Message-ID: <c9832fa7-09c0-2c16-bf06-a973094526fe@gmail.com>

On 01/08/20 04:46, Rudi Blom wrote:
> That's a real big vi in RHL. Looking at a few (commercial) unixes I get
> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
>   - /usr/bin/vi: iAPX 386 executable
> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
>   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
> sticky executable or object module stripped - version 3.13-14
> HP-UX 11.31 748996 Aug 28 2009 /bin/vi
>   -- /bin/vi: ELF-32 executable object file - IA64

Solaris 10 on Ultrasparc 239828
   /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1, 
dynamically linked, stripped

Any others?

N.

From steve.mynott at gmail.com  Thu Jan  9 01:29:17 2020
From: steve.mynott at gmail.com (Steve Mynott)
Date: Wed, 8 Jan 2020 15:29:17 +0000
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
Message-ID: <CANuZA8RpBDL=KQsi9eZbaBJd_bOjs=BwBB5HM=zeb-TVQfZA5g@mail.gmail.com>

On 07/01/2020, Dave Horsfall <dave at horsfall.org> wrote:
> I don't recall the exact details, but there was once an editor called "em"
> (Editor for Mortals).  I remember thinking: what sort of an idiot would
> call it that, with the "e" and "r" keys adjacent to each other?  I wonder
> how many files were lost that way...

It was a line editor which resembled ex, came from QMC London and was
used on some VAX BSD systems in UK Universities in the early '80s. The
source is online.

As for "rm" typos I'm sure many discovered netnews the same way!

-- 
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

From henry.r.bent at gmail.com  Thu Jan  9 01:37:19 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 8 Jan 2020 10:37:19 -0500
Subject: [TUHS] screen editors
In-Reply-To: <c9832fa7-09c0-2c16-bf06-a973094526fe@gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <c9832fa7-09c0-2c16-bf06-a973094526fe@gmail.com>
Message-ID: <CAEdTPBd4pRkCByeB76Q73LvH0+rT4eTnFaXn+vmLPEsXEvjiXg@mail.gmail.com>

On Wed, 8 Jan 2020 at 10:20, Nemo Nusquam <cym224 at gmail.com> wrote:

> On 01/08/20 04:46, Rudi Blom wrote:
> > That's a real big vi in RHL. Looking at a few (commercial) unixes I get
> > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
> >   - /usr/bin/vi: iAPX 386 executable
> > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
> >   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
> > sticky executable or object module stripped - version 3.13-14
> > HP-UX 11.31 748996 Aug 28 2009 /bin/vi
> >   -- /bin/vi: ELF-32 executable object file - IA64
>
> Solaris 10 on Ultrasparc 239828
>    /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1,
> dynamically linked, stripped
>
> Any others?
>

I was somewhat surprised by this, on IRIX 4.0.5H:
/usr/bin/vi:    symbolic link to ex
-rwxr-xr-t 1 root sys 229376 2016-04-17 01:07 /usr/bin/ex
/usr/bin/ex:    mipseb demand paged stripped - version 2.10
% what /usr/bin/ex
/usr/bin/ex:
         printf.c:2.2 6/5/79

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/cbd0e024/attachment.html>

From steve.mynott at gmail.com  Thu Jan  9 01:42:07 2020
From: steve.mynott at gmail.com (Steve Mynott)
Date: Wed, 8 Jan 2020 15:42:07 +0000
Subject: [TUHS] screen editors
In-Reply-To: <20200108151547.4uumD%steffen@sdaoden.eu>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <20200108151547.4uumD%steffen@sdaoden.eu>
Message-ID: <CANuZA8QrxSS0poF728+L-sR-mnrsYO4Az6NtYcK6__GV_jg-fw@mail.gmail.com>

On 08/01/2020, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> It is a tremendous effort of Bram Moolenaar and the vim
> contributors to maintain this codebase that can be configured in
> uncountable ways, just looking at the pre-configured feature sets
> that exist lead to tiny, small, normal, big and huge.

Indeed. It's larger because it does a lot more!

Small isn't necessarily beautiful and all those tiny old vendor vi
binaries are probably full of bugs since they were never actively
maintained.

The last time I used Solaris vi it didn't handle long lines properly
and the more recent classic Joy vi open source forks are full of bug
fixes (often for quite serious problems).

If you want a tiny vi compile one of those up or use nvi.  If you want
features use vim.

-- 
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

From usotsuki at buric.co  Thu Jan  9 01:58:55 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 8 Jan 2020 10:58:55 -0500 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
Message-ID: <alpine.BSF.2.02.2001081053450.44347@frieza.hoshinet.org>

On Wed, 8 Jan 2020, Thomas Paulsen wrote:

>> What's funny is that in doing the work to get 'se' running on Georgia
>> Tech's Vax, I had to learn vi.  By the time I was done, vi had become
>> my main editor and had burned itself into my finger's ROMs.
> I do ed/se occasionally for simple tasks, vim frequently , because it 
> loads fast, and emacs for all bigger projects, beside liteide for 
> golang.

For what it's worth, I use nano. (Yeah, I know, not very unixy.)

I think the first fullscreen text editor I used was FrEdWriter (by Paul 
Lutus and Al Rogers) for the Apple ][.  After that it was IBM's E.  I 
haven't really used vi *or* emacs much.

-uso.

From clemc at ccc.com  Thu Jan  9 02:02:41 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Jan 2020 11:02:41 -0500
Subject: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor
Message-ID: <CAC20D2Pd+gEu8AmsAjJ5vxT+GGfU8PyRXRD7Aux0v2-VUN0N8A@mail.gmail.com>

below...  -- warning veering a little from pure UNIX history, but trying to
clarify what I can and then moving to COFF for follow up.

On Wed, Jan 8, 2020 at 12:23 AM Brian Walden <tuhs at cuzuco.com> wrote:

> ....
>
> - CMU's ALGOL68S from 1978 list all these ways --
>   co            comment
>   comment       comment
>   pr            pragmat
>   pragmat       pragmat
>   #             (comment symbol) comment
>   ::            (pragmat symbol) pragmat
>   (its for UNIX v6 or v7 so not surprising # is a comment)
>   http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view

Be careful of overthinking here.   The comment in that note says was it was
for* PDP-11's *and lists V6 and V7 was *a possible target*, but it did not
say it was.  Also, the Speach and Vision PDP-11/40e based systems ran a
very hacked v6 (which a special C compiler that supported CMU's csv/cret
instructions in the microcode), which would have been the target systems.
[1]

To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but
Hydra (and also used custom microcode).  IIRC there was some talk to move
it to *OS (Star OS for CM*)  I've sent a note to dvk to see if he remembers
it otherwise. I also ask Liebensperger what he remembers, he was hacking on
*OS in those days.  Again, IIRC Prof. Peter Hibbard was the mastermind
behind the CMU Algol68 system.  He was a Brit from Cambridge (and taught
the parallel computing course which I took from him at the time).

FWIW: I also don't think the CMU Algol68 compiler was ever completely
self-hosting, and like BLISS, required the PDP-10 to support it.  As to why
it was not moved to the Vax, I was leaving/had left by that time, but I
suspect the students involved graduated and by then the Perq's had become
the hot machine for language types and ADA would start being what the gvt
would give research $s too.


>
>
> ...
>
> But look! The very first line of that file! It is a single # sitting all
> by itself.  Why? you ask. Well this is a hold over from when the C
> preprocessor was new. C orginally did not have it and was added later.
> PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th
> Edition the C preprocessor would not be inkoved unless the very first
> character of the C source file was an #
>
That was true of V7 and Typesetter C too.  It was a separate program (
/lib/cpp) that the cc command called if needed.



> Since v7 the preprocessor always run on it. The first C preprocessor was
> Ritchie's work with no nested includes and no macros. v7's was by John
> Reiser which added those parts.
>
Right, this is what I was referring too last night in reference to Sean
comments.  As I said, the /bin/cc command was a shell script and it peaked
at the first character to see if it was #.   I still find myself starting
all C programs with a # on a line by itself ;-)

Note that the Ritchie cpp was influenced by Brian's Ratfor work, so using #
is not surprising.

This leads to a question/thought for this group, although I think needs to
move to COFF (which I have CC'ed for follow up).

I have often contended, that one of the reasons why C, Fortran, and PL/1
were so popular as commercial production languages were because they could
be preprocessed.  For a commercial place where lots of different targets is
possible, that was hugely important.  Pascal, for instance, has semantics
that makes writing a preprocessor like cpp or Ratfor difficult (which was
one of the things Brian talks about in his "*Why Pascal is not my favorite
Programming Language <http://www.lysator.liu.se/c/bwk-on-pascal.html>*"
paper). [2]

So, if you went to commercial ISV's and looked at what they wrote in.   It
was usually some sort of preprocessed language.   Some used Ratfor like a
number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN.
 I believe it was Morgan-Stanley had a front-end for PL/1, which I can not
recall the name.  But you get the point ... if you had to target different
runtime environments, it was best for your base code to not be specific.

However ... as C became the system programming language, the preprocessor
was important.  In fact, it even gave birth the other tools like autoconfig
to help control them.  Simply, the idiom:
#ifdef SYSTEMX
#define SOME_VAR (1)
... do something specific
#endif /* SYSTEMX */

While loathsome to read, it actually worked well in practice.

That fact is I hate the preprocessor in many ways but love it for what it
for the freedom it actually gave us to move code.  Having programmed since
the 1960s, I remember how hard it was to move things, even if the language
was the same.

Today, modern languages try to forego the preprocessor.   C++'s solution is
to throw the kitchen sink into the language and have 'frameworks', none of
which work together.   Java's and its family tries to control it with the
JVM.  Go is a little too new to see if its going to work (I don't see a lot
of production ISV code in it yet).

Note: A difference between then and now, is 1) we have few target
architectures and 2) we have fewer target operating environments, 3) ISV
don't like multiple different versions of their SW, they much prefer very
few for maintenance reasons so they like # 1 and #2 [i.e. Cole's law of
economics in operation here].

So ... my question, particularly for those like Doug who have programmed
longer and at least as long as I, what do you think?   You lived the same
time I did and know the difficulties we faced.   Is the loss of a
preprocessor good or bad?

Clem

[1] Historical footnote about CMU.   I was the person that brought V7 into
CMU and I never updated the Speach or Vision systems and I don't think
anyone did after I left.  We ran a CMU V7 variant mostly on the 11/34s (and
later on a couple of 11/44s I believe) that had started to pop up.
Although later if it was a DEC system, CS was moving to Vaxen when they
could get the $s (but the Alto's and Perq's had become popular with the CMU
SPICE proposal).  Departments like bio-engineering, mech ee, ran the
cheaper systems on-site and then networked over the Computer Center's Vaxen
and PDP-20's when they needed address space).

[2] Note: Knuth wrote "Web" to handle a number of the issues, Kernighan
talks about - but he had to use an extended Pascal superset and his program
was notable for not being portable (he wrote for it for the PDP-10
Pascal).  [BTW: Ward Cunningham, TW Cook and I once counted over 8
different 'Tek Pascal' variants and 14 different 'HP Basics'].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/8eda3d35/attachment-0001.html>

From heinz at osta.com  Thu Jan  9 02:56:33 2020
From: heinz at osta.com (Heinz Lycklama)
Date: Wed, 8 Jan 2020 08:56:33 -0800
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <81a090b1892b04644c0357805bb75440@firemail.de>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
 <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
 <81a090b1892b04644c0357805bb75440@firemail.de>
Message-ID: <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com>

On 1/7/2020 11:46 PM, Thomas Paulsen wrote:
>> Hell, Linux didn't exist at all till '91.
>> I think Xenix was more just a casualty of the Unix Wars.  The victors there
>> were SunOS/Solaris, AIX, and HP-UX.  There were a bunch more walking
>> wounded that never really achieved much market share.
> 'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.'
> https://en.wikipedia.org/wiki/Xenix
Two other major vendors competing with Xenix were:
     1. _*INTERACTIVE Systems Corp. (ISC)*_ 
<https://en.wikipedia.org/wiki/Interactive_Systems_Corporation> [founded 
in 1977] with PC/IX, and later IS/3, etc.
     2. _*Santa Cruz Operation (SCO)*_ 
<https://en.wikipedia.org/wiki/Santa_Cruz_Operation> [founded in 1979] 
with SCO UNIX, etc.
There were also a number of smaller players in this space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/9fafa808/attachment.html>

From mah at mhorton.net  Thu Jan  9 04:30:43 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 8 Jan 2020 10:30:43 -0800
Subject: [TUHS] screen editors
In-Reply-To: <202001071630.007GUrBj030452@freefriends.org>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
Message-ID: <e31f5e4e-73f5-c68e-b22a-30527f6ddeea@mhorton.net>

It's interesting how much of this has  been lost to history. Curses, in 
particular, is sketchily documented, and se is unknown. Here's how I 
remember it.

Bill Joy made major enhancements to previously enhanced versions of ed, 
creating vi. In 1979, he bumped up against the 64K boundary on the 
PDP-11, and handed it off to me. I made some more smaller enhancements.

vi was huge by the standards of the day, especially compared to ed. 
There were ifdefs to take out several features, such as support for 
upper case only terminals, to make it fit on the PDP-11. I had to split 
it into version 2 (16 bit) and 3 (32 bit) to be able to enhance it and 
still support 2BSD on the PDP-11.

Ken Arnold took the screen updating code from vi (just the "full screen 
update", not the parts that did insert/delete line/char) and turned it 
into the curses library. Rogue was the primary user of curses.

Once I graduated from Berkeley went to Bell Labs, I took vi, termcap, 
and curses with me. I replaced termcap, which was too slow to start up 
(it was quadratic on the size of the entry, which was awful on the 
hardware of the day) with terminfo, a binary version that was faster. It 
included tools like tic and infocmp to translate back and forth to text 
and termcap.

I also rewrote curses with a new algorithm that fully utilized 
insert/delete line/char. I had a paper to publish on the subject, but I 
lost it and never did publish it.

I gave a talk at Usenix Boston in 1982 about the new curses and 
terminfo. But I couldn't release the code, because it was considered 
proprietary. Pavel Curtis offered to clone it, and I coached him on the 
algorithm and specs, and he released a good clone pcurses. Eventually 
that became ncurses.

Nearly everyone at Bell Labs (outside area 11) was using either vi or 
emacs, but System III just had ed. There was a big push to add vi or 
emacs to UNIX 3.0 (System III), but USG instead chose to write se, the 
"screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 
(System V) relented and included vi.

     Mary Ann

On 1/7/20 8:30 AM, arnold at skeeve.com wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>
>> I'm a vi guy to this day.  Love it.
> In the summer of '82 I did some contract programming at Southern Bell
> on a PDP-11 running USG Unix 4.0.  It had a screen editor called 'se'
> that I only ever saw there, written somewhere in the Bell System and
> squeezed to run on an -11.  Anyone know anything about it?
>
> Unrelated, Georgia Tech had the 'se' screen editor as part of the
> Software Tools Subsystem, based on the 'ed' in the Software Tools book.
> This was later ported to Unix. I modified that code to use curses/termlib
> and posted it to USENET. It's been updated and is available from
> https://github.com/se-editor/se and http://se-editor.org is the home
> page. (Thomas Cort IIRC did that work.)
>
> What's funny is that in doing the work to get 'se' running on Georgia
> Tech's Vax, I had to learn vi.  By the time I was done, vi had become
> my main editor and had burned itself into my finger's ROMs.
>
> Arnold

From steffen at sdaoden.eu  Thu Jan  9 06:56:46 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 08 Jan 2020 21:56:46 +0100
Subject: [TUHS] screen editors
In-Reply-To: <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <20200108151547.4uumD%steffen@sdaoden.eu>
 <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org>
Message-ID: <20200108205646.A8FxA%steffen@sdaoden.eu>

U'll Be King of the Stars wrote in <68b3d6df-94f6-625d-39bf-6149b4c177c9\
@andrewnesbit.org>:
 |On 08/01/2020 15:15, Steffen Nurpmeso wrote:
 |> (But i think emacs is better here, i see one markable
 |> emacs developer taking care on the Unicode list, regarding real
 |> BiDi support, for example.)
 |
 |I have been following the emacs-devel mailing list out of interest for 
 |many years.  From this, I think the person you are referring to in your 
 |comment, is Eli Zaretskii.  Is that right?

Yep.  Then again i have to say it was a lot of a mistake, because
the OSS man who i referred to and who is known for questions deep
in the material is indeed Karl Williamson of i think Perl.

--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 woods at robohack.ca  Thu Jan  9 07:43:43 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Wed, 08 Jan 2020 13:43:43 -0800
Subject: [TUHS] screen editors (FRED)
In-Reply-To: <CAC20D2Me2VxTbeX0nLZ74Q9+DSYcTA+oMEsBozS=HdRVWwsLrg@mail.gmail.com>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Me2VxTbeX0nLZ74Q9+DSYcTA+oMEsBozS=HdRVWwsLrg@mail.gmail.com>
Message-ID: <m1ipJ7A-0036tPC@more.local>

At Tue, 7 Jan 2020 10:03:57 -0500, Clem Cole <clemc at ccc.com> wrote:
Subject: Re: [TUHS] screen editors
>
> FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition
> and somewhat pined for a screen editor.   Soon after upgrading to 6th
> edition at CMU, we found a visual editor called Fred - the Friendly Editor,
> from Cornell IIRC (I think it's on the original USENIX tape but I don't
> remember how we got it).  I had to hack in the Perkin-Elmer Fox terminal
> support, but it was a superset of V6 ed so a pretty trivial learning curve.

Ah, yes, Fred.  A name with so many editors!

I used a full-screen version of an ed-like editor on V7, 32B, and 4BSD
at University of Calgary which was called the "FRiendly EDitor".  This
may be the one you mention.

The FRED I know is not to be confused with the version of QED named FRED
(Friendly Editor) that was written at the University of Waterloo for
Honeywell GECOS by Peter Fraser.  It's also not the "FRED - A Friendly
Editor" by Richard J. Botting [1].  There's also apparently an editor
named FRED for VMS, and another for Amstrad PCW systems (for editing
BASIC, and apparently written in BASIC itself).  And then there's the
one from a company called Digitool which was called "FRED:  Fred
Resembles Emacs Deliberately", which was written in Macintosh Common
Lisp.  There's also an old Windows-based "Friendly Right-to-Left Editor
(FRED)" by NSRI.  I also recently found this [2] reference to a "FRED",
but it seems to be yet another completely different kind of editor using
the same name.

[1] http://www.csci.csusb.edu/dick/papers/rjb84a.FRED.mth

[2] https://www.osti.gov/biblio/5141603-fred-program-development-tool

    Abstract:

    The structured, screen-based editor FRED is introduced.  FRED
    provides incremental parsing and semantic analysis.  The parsing is
    based on an LL(1) top-down algorithm which has been modified to
    provide follow-the-cursor parsing and soft templates.  The languages
    accepted by the editor are LL(1) languages with the addition of the
    Unknown and preferred production non-terminal classes.  The semantic
    analysis is based on the incremental update of attribute grammar
    equations.  We briefly describe the interface between FRED and an
    automated reference librarian system that is under development.

    FRED User's Manual
    Shilling, J.
    Illinois University, Urbana
    Department of Computer Science
    Feb. 1984

    FRED, the frinedly editor, is a screen-based structured editor.
    This manual is intended to serve the needs of a wide range of users
    of the FRED text editor.  Most users will find it sufficient to read
    the introductory material in section 2, supplemented with the full
    command set description in section 3.  Advanced users may wish to
    change the keystroke sequences which invoke editor commands.
    Section 4 describes how to change key bindings and how to define
    command macros.  Some users may need to modify a language
    description or create an entirely new language description for use
    with FRED.  Section 5 describes the format of the language
    descriptions used by the editor, and describes how to construct a
    language grammar.  Section 6 describes known portability problems of
    the FRED editor and should concern only system installation
    personnel.  The editor points out syntax errors in the file being
    edited and does automatic pretty printing.


The version of Fred I used had a full-screen line-oriented mode as well
as what was called "open" mode which presented a much more direct
full-screen editing experience (though it was a bit quirky, but it
reminded me a bit of "Electric Pencil II" which I had used on a Sol-20).
Open mode of course generated an interrupt for every key press and so on
a PDP-11/60 with 16 terminals it could cause quite a system load, and
most of us avoided using open mode on the PDPs.  Even the VAX 11/780
running 32V was sometimes slowed by it, but it had at least 24 terminals
as I recall (at the time it was still running 32V), so a room full of
students feverously typing away was quite a lot of input.

I've been unable to find any other reference or mention of this version
of Fred; and to the best of my searches it's not on any Usenix tape I
can find a copy of.

If anyone has any further info about the FRED Clem and/or I seem to
remember, please do post it!

I soon forgot most that I knew about Fred though once Gosling Emacs was
installed on the VAX (after it had been upgraded to 4BSD).  I already
had a strong preference to Emacs having used it extensively on the
Multics system at UofC.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/3bb9bd61/attachment.sig>

From dave at horsfall.org  Thu Jan  9 07:49:58 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 08:49:58 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
Message-ID: <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Thomas Paulsen wrote:

> I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang.

I had a boss once who insisted that all his staff learn "ed", because one 
day it might be the only editor available; he was right...

-- Dave

From grog at lemis.com  Thu Jan  9 07:55:17 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 9 Jan 2020 08:55:17 +1100
Subject: [TUHS] Dating quotes (was: What happened with XENIX?)
In-Reply-To: <7zxjn49rcpnbpgv7zbq4rxgv@localhost>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <7zxjn49rcpnbpgv7zbq4rxgv@localhost>
Message-ID: <20200108215517.GP64020@eureka.lemis.com>

On Wednesday,  8 January 2020 at 12:18:01 +0000, Michael Kjörling wrote:
>
> So by "mid 1980", what would eventually lead up to the IBM PC was at
> most _just barely_ getting started.

Right, but my recollection is that the original quote was "mid 1980s"
(i.e. round 1985), not "mid 1980".

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/ac334e9d/attachment.sig>

From clemc at ccc.com  Thu Jan  9 08:01:35 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Jan 2020 17:01:35 -0500
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
Message-ID: <CAC20D2M2Z6tiLXYPkstaxkF3K5ZaB4p9mLcn0C3aw5FAg9_9vg@mail.gmail.com>

On Wed, Jan 8, 2020 at 4:50 PM Dave Horsfall <dave at horsfall.org> wrote:

> I had a boss once who insisted that all his staff learn "ed", because one
> day it might be the only editor available; he was right...
>
I always suggest it.  It means you can use sed and lot of other tools
pretty quick.
And if you know ed, you can use almost anything close to it.   I hated
DOS's edlin but if I was stuck it was close enough.

Although the famous ? error from the original version was annoying.

Truly, I still suggest that any modern user, take Rob and Brian's book and
until you can do the exercises without think about it, you really are not
yet comfortable with UNIX.  I even recommend at least read and looking at
the chapter on nroff.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/3bd8f188/attachment.html>

From thomas.paulsen at firemail.de  Thu Jan  9 07:41:27 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 08 Jan 2020 22:41:27 +0100
Subject: [TUHS] screen editors
In-Reply-To: <e31f5e4e-73f5-c68e-b22a-30527f6ddeea@mhorton.net>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
 <e31f5e4e-73f5-c68e-b22a-30527f6ddeea@mhorton.net>
Message-ID: <6c0a5ba13bd49788ffa518ebe0afa6c4@firemail.de>

>It's interesting how much of this has  been lost to history. Curses, in
thanks for the deep insider view.
I heard that Bill's ex/vi sources were incomprehensible 'read never' code. Hence it makes no wonder that everybody failed adding real support for cursor keys. beyond automatically switching from insert to visual mode on hitting any cursor key!



From dave at horsfall.org  Thu Jan  9 08:15:14 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 09:15:14 +1100 (EST)
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Dave Horsfall wrote:

> I was forced to use Xenix for a contracting job (and hated it, as it was 
> almost-but-not-quite-Unix, and the differences annoyed me).  Wouldn't 
> Linux have arrived at around that time?

OK, I was out by a few years...  That job was some time in the 70/80s, and 
my memory isn't the best these days.

Similarly, I have a Penguin laptop at home for porting purposes, otherwise 
I never use it.  The cycle goes something like: get it working on both 
FreeBSD and the Mac (fairly easy), try it on the Penguin to see what 
they've broken and make the appropriate changes, then back to the Mac and 
the FreeBSD box again; repeat as necessary.  If worse comes to worst, make 
the code conditional upon the architecture (and I hate doing that, because 
it breaks the logical flow of the code).

For the record, I was porting Unify (an early RDBMS, and quite a nice one) 
to a 386...  Those damned memory models drove me crazy!  I preferred the 
small model because it was fast, but some modules were so big I had to use 
the large model which meant modifying the build script in the appropriate 
directory (no "make" in those days), and there were dozens of them.

ObTrivia: I used to use the Unify demonstration to benchmark a machine, 
and used to joke that sometimes I needed a calendar, not a clock :-)

-- Dave

From iain at csp-partnership.co.uk  Thu Jan  9 08:25:13 2020
From: iain at csp-partnership.co.uk (Dr Iain Maoileoin)
Date: Wed, 8 Jan 2020 22:25:13 +0000
Subject: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor
In-Reply-To: <CAC20D2Pd+gEu8AmsAjJ5vxT+GGfU8PyRXRD7Aux0v2-VUN0N8A@mail.gmail.com>
References: <CAC20D2Pd+gEu8AmsAjJ5vxT+GGfU8PyRXRD7Aux0v2-VUN0N8A@mail.gmail.com>
Message-ID: <5BDC3682-F79F-449F-A815-A0C3F1184A21@csp-partnership.co.uk>


> On 8 Jan 2020, at 16:02, Clem Cole <clemc at ccc.com> wrote:
> 
> below...  -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up.
> 
> On Wed, Jan 8, 2020 at 12:23 AM Brian Walden <tuhs at cuzuco.com <mailto:tuhs at cuzuco.com>> wrote:
> ....
> 
> - CMU's ALGOL68S from 1978 list all these ways --
>   co            comment
>   comment       comment
>   pr            pragmat
>   pragmat       pragmat
I remember that a pragma (at least in Algol68R (ICL 1900 series) and I would need to reread the formal definition to see if it was general) was not a comment.
It was a note to the compiler - which could choose to use it or lose it.
>   #             (comment symbol) comment
>   ::            (pragmat symbol) pragmat
>   (its for UNIX v6 or v7 so not surprising # is a comment)
>   http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view <http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/7042d8cd/attachment.html>

From corky1951 at comcast.net  Thu Jan  9 08:46:08 2020
From: corky1951 at comcast.net (CHARLES KESTER)
Date: Wed, 8 Jan 2020 14:46:08 -0800 (PST)
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <CANCZdfqyCH7WfvhAwiW5TFNmbphpLmihOSGfu1kJvLaZkSaA3g@mail.gmail.com>
 <CAP2nic3u89f0cwF3tNu65fpNVNe=irXQf1EcucEVZVXg1nrt5Q@mail.gmail.com>
 <81a090b1892b04644c0357805bb75440@firemail.de>
 <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com>
Message-ID: <12774577.233803.1578523569116@connect.xfinity.com>

> On January 8, 2020 at 8:56 AM Heinz Lycklama <heinz at osta.com> wrote:
> 
>     Two other major vendors competing with Xenix were:
>         1. INTERACTIVE Systems Corp. (ISC) https://en.wikipedia.org/wiki/Interactive_Systems_Corporation [founded in 1977] with PC/IX, and later IS/3, etc.
>         2. Santa Cruz Operation (SCO) https://en.wikipedia.org/wiki/Santa_Cruz_Operation [founded in 1979] with SCO UNIX, etc.
>     There were also a number of smaller players in this space.
> 
This brings back memories.  My first exposure to Unix (ca. 1985) was Interactive 386/ix.  I think I still have the floppies for it around here somewhere.  I don't know if they're still readable but if anyone wants them, send me a private email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/5358edb8/attachment.html>

From dave at horsfall.org  Thu Jan  9 09:21:37 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 10:21:37 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
Message-ID: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Chet Ramey wrote:

>> That's a real big vi in RHL. 
>
> It's vim.

It's also VIM on the Mac.

-- Dave

From skogtun at gmail.com  Thu Jan  9 09:29:23 2020
From: skogtun at gmail.com (Harald Arnesen)
Date: Thu, 9 Jan 2020 00:29:23 +0100
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
Message-ID: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>

Den 08.01.2020 23:15, skrev Dave Horsfall:

> Similarly, I have a Penguin laptop at home for porting purposes, 
> otherwise I never use it.  The cycle goes something like: get it working 
> on both FreeBSD and the Mac (fairly easy), try it on the Penguin to see 
> what they've broken and make the appropriate changes, then back to the 
> Mac and the FreeBSD box again; repeat as necessary.  If worse comes to 
> worst, make the code conditional upon the architecture (and I hate doing 
> that, because it breaks the logical flow of the code).

In my experience, macOS breaks more things these days.
-- 
Hilsen Harald

From dave at horsfall.org  Thu Jan  9 09:31:10 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 10:31:10 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <CANuZA8RpBDL=KQsi9eZbaBJd_bOjs=BwBB5HM=zeb-TVQfZA5g@mail.gmail.com>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.9999.2001071716380.40155@aneurin.horsfall.org>
 <CANuZA8RpBDL=KQsi9eZbaBJd_bOjs=BwBB5HM=zeb-TVQfZA5g@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2001091028380.40155@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Steve Mynott wrote:

> As for "rm" typos I'm sure many discovered netnews the same way!

OK, I'll admit that I was baffled until I took a closer look at my 
keyboard :-)

-- Dave

From dave at horsfall.org  Thu Jan  9 09:41:16 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 10:41:16 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.02.2001081053450.44347@frieza.hoshinet.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.02.2001081053450.44347@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.21.9999.2001091035440.40155@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Steve Nickolas wrote:

> I think the first fullscreen text editor I used was FrEdWriter (by Paul 
> Lutus and Al Rogers) for the Apple ][.  After that it was IBM's E.  I 
> haven't really used vi *or* emacs much.

First I used was DEC's "EDT" and could never get used to the "gold" key...

Fortunately I was not required to use RSX (or was it VMS?) as I was 
strictly a PDP Unix bod at the time; I was just curious.

-- Dave

From reed at reedmedia.net  Thu Jan  9 09:48:55 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Wed, 8 Jan 2020 17:48:55 -0600 (CST)
Subject: [TUHS] Dating quotes (was: What happened with XENIX?)
In-Reply-To: <20200108215517.GP64020@eureka.lemis.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <7zxjn49rcpnbpgv7zbq4rxgv@localhost>
 <20200108215517.GP64020@eureka.lemis.com>
Message-ID: <alpine.NEB.2.21.2001081743460.50@t1.m.reedmedia.net>

On Thu, 9 Jan 2020, Greg 'groggy' Lehey wrote:

> On Wednesday,  8 January 2020 at 12:18:01 +0000, Michael Kj?rling wrote:
> >
> > So by "mid 1980", what would eventually lead up to the IBM PC was at
> > most _just barely_ getting started.
> 
> Right, but my recollection is that the original quote was "mid 1980s"
> (i.e. round 1985), not "mid 1980".

"mid-1980" (without "s") was from page 31
https://archive.org/details/Unix_World_Vol02_10.pdf/page/n29
(It is in a sidebar; I will still attribute it to Gates.)

(I'd think mid-1980s with "s" wouldn't make sense for an article written 
probably before October 1985.)

From ron at ronnatalie.com  Thu Jan  9 10:01:57 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Wed, 8 Jan 2020 19:01:57 -0500
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
 <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
Message-ID: <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net>

We were Interactive Systems users in 1981 when I worked for Martin
Marietta.   Heinz, you were working there at that point, right?   I
remember my rep was Monica Gallegos.

A few years later I got caught up with a Multibus II port which I think
Interactive Systems was also involved with.   I had three systems on my
desk to get the experimental computer with the experimental SCSI host
adapter and the experimental SCSI tape drive:   A Wyse PC, a Intel
Multibus I 386 system, and an Intel MultibusII system.

I really did end up liking MultibusII for UNIX.


From dave at horsfall.org  Thu Jan  9 10:04:59 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 11:04:59 +1100 (EST)
Subject: [TUHS] screen editors (FRED)
In-Reply-To: <m1ipJ7A-0036tPC@more.local>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Me2VxTbeX0nLZ74Q9+DSYcTA+oMEsBozS=HdRVWwsLrg@mail.gmail.com>
 <m1ipJ7A-0036tPC@more.local>
Message-ID: <alpine.BSF.2.21.9999.2001091103140.40155@aneurin.horsfall.org>

I'm surprised that no-one has mentioned "F*cking Ripper of an EDitor" yet, 
or was it UNSW-only?

-- Dave

From imp at bsdimp.com  Thu Jan  9 10:08:59 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Jan 2020 17:08:59 -0700
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
Message-ID: <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>

On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 8 Jan 2020, Chet Ramey wrote:
>
> >> That's a real big vi in RHL.
> >
> > It's vim.
>
> It's also VIM on the Mac.
>

Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
default for vi.

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/bb287bec/attachment.html>

From heinz at osta.com  Thu Jan  9 10:19:46 2020
From: heinz at osta.com (Heinz Lycklama)
Date: Wed, 8 Jan 2020 16:19:46 -0800
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
 <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
 <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net>
Message-ID: <1a626615-690a-33a3-3a61-8cb6dcd4de1e@osta.com>

Yes, I worked at INTERACTIVE Systems Corp. (ISC) from 1978
to the end of 1991 when Sun Microsystems acquired ISC.
-- Heinz --

On 1/8/2020 4:01 PM, ron at ronnatalie.com wrote:
> We were Interactive Systems users in 1981 when I worked for Martin
> Marietta.   Heinz, you were working there at that point, right?   I
> remember my rep was Monica Gallegos.
>
> A few years later I got caught up with a Multibus II port which I think
> Interactive Systems was also involved with.   I had three systems on my
> desk to get the experimental computer with the experimental SCSI host
> adapter and the experimental SCSI tape drive:   A Wyse PC, a Intel
> Multibus I 386 system, and an Intel MultibusII system.
>
> I really did end up liking MultibusII for UNIX.
>
>


From dave at horsfall.org  Thu Jan  9 10:19:52 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Jan 2020 11:19:52 +1100 (EST)
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
 <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2001091116100.40155@aneurin.horsfall.org>

On Thu, 9 Jan 2020, Harald Arnesen wrote:

> In my experience, macOS breaks more things these days.

Fortunately my Mac never progressed beyond Sierra due to memory 
limitations or something; its other major job is as a client into my 
FreeBSD server.

Slowly getting into COFF territory now, I think...

-- Dave

From lm at mcvoy.com  Thu Jan  9 11:28:30 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Jan 2020 17:28:30 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
Message-ID: <20200109012830.GC16808@mcvoy.com>

On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave at horsfall.org> wrote:
> 
> > On Wed, 8 Jan 2020, Chet Ramey wrote:
> >
> > >> That's a real big vi in RHL.
> > >
> > > It's vim.
> >
> > It's also VIM on the Mac.
> >
> 
> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
> default for vi.

I was gonna stay out of this thread (it has the feel of old folks somehow)
but 2 comments:

Keith did nvi (I can't remember why?  licensing or something) and he did
a pretty faithful bug for bug compatible job.  I've always wondered why.
I like Keith but it seemed like a waste.  There were other people taking
vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap
the file and had a whole string library that treated \n like NULL) and
I think vim was coming along.  So doing a compat vi felt like a step
backward for me.

For all the vim haters, come on.  Vim is awesome, it gave me the one
thing that I wanted from emacs, multiple windows.  I use that all the
time.  It's got piles of stuff that I don't use, probably should, but
it is every bit as good of a vi as the original and then it added more.
I'm super grateful that vim came along.

From bakul at bitblocks.com  Thu Jan  9 11:40:10 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Jan 2020 17:40:10 -0800
Subject: [TUHS] screen editors
In-Reply-To: <20200109012830.GC16808@mcvoy.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
Message-ID: <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>

On Jan 8, 2020, at 5:28 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
>> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave at horsfall.org> wrote:
>> 
>>> On Wed, 8 Jan 2020, Chet Ramey wrote:
>>> 
>>>>> That's a real big vi in RHL.
>>>> 
>>>> It's vim.
>>> 
>>> It's also VIM on the Mac.
>>> 
>> 
>> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
>> default for vi.
> 
> I was gonna stay out of this thread (it has the feel of old folks somehow)
> but 2 comments:
> 
> Keith did nvi (I can't remember why?  licensing or something) and he did
> a pretty faithful bug for bug compatible job.  I've always wondered why.
> I like Keith but it seemed like a waste.  There were other people taking
> vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap
> the file and had a whole string library that treated \n like NULL) and
> I think vim was coming along.  So doing a compat vi felt like a step
> backward for me.
> 
> For all the vim haters, come on.  Vim is awesome, it gave me the one
> thing that I wanted from emacs, multiple windows.  I use that all the
> time.  It's got piles of stuff that I don't use, probably should, but
> it is every bit as good of a vi as the original and then it added more.
> I'm super grateful that vim came along.

The first thing I do on a new machine is to install nvi. Very grateful to
Keith Bostic for implementing it. I do use multiple windows — only
horizontal splits but that is good enough for me as all my terminal
windows are 80 chars wide. Not a vim hater but never saw the need.


From cym224 at gmail.com  Thu Jan  9 11:43:20 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 8 Jan 2020 20:43:20 -0500
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001091035440.40155@aneurin.horsfall.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.02.2001081053450.44347@frieza.hoshinet.org>
 <alpine.BSF.2.21.9999.2001091035440.40155@aneurin.horsfall.org>
Message-ID: <c31fd8e5-3c76-9444-7b4b-ee62c841c851@gmail.com>

On 01/08/20 18:41, Dave Horsfall wrote:
> [...]
> First I used was DEC's "EDT" and could never get used to the "gold" 
> key...
>
> Fortunately I was not required to use RSX (or was it VMS?) as I was 
> strictly a PDP Unix bod at the time; I was just curious.
>
> -- Dave

It was VMS and I had forgotten all about the Gold Key until now.

N.


From clemc at ccc.com  Thu Jan  9 12:04:46 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Jan 2020 21:04:46 -0500
Subject: [TUHS] screen editors
In-Reply-To: <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
Message-ID: <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>

On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:

> The first thing I do on a new machine is to install nvi. Very grateful to
> Keith Bostic for implementing it. I do use multiple windows — only
> horizontal splits but that is good enough for me as all my terminal
> windows are 80 chars wide. Not a vim hater but never saw the need.

I pretty much do the same thing. I think what I hate about vim is that it's
almost, vi but not the same. My fingers screw up when I use it.  For
instance, he 'fixed' undo.   I guess I learned my lesson from my time at
UCB.  Henry Spencer once said, "BSD 4.2 is just like UNIX, only different."  I
rather see something new and completely different than changing behavior
that people rely upon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/caffd7e4/attachment.html>

From lm at mcvoy.com  Thu Jan  9 12:07:20 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Jan 2020 18:07:20 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
Message-ID: <20200109020720.GG16808@mcvoy.com>

On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > The first thing I do on a new machine is to install nvi. Very grateful to
> > Keith Bostic for implementing it. I do use multiple windows ??? only
> > horizontal splits but that is good enough for me as all my terminal
> > windows are 80 chars wide. Not a vim hater but never saw the need.
> 
> I pretty much do the same thing. I think what I hate about vim is that it's
> almost, vi but not the same. My fingers screw up when I use it.  For
> instance, he 'fixed' undo.   

Holy crap Clem, you need to embrace that.  His undo goes back forever.
And you can undo the undo and go forward forever.  

Not liking that puts you in the "get off my lawn" old guy camp.  Which
is fine if that's who you want to be (sometimes I'm that guy).

From clemc at ccc.com  Thu Jan  9 12:12:38 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Jan 2020 21:12:38 -0500
Subject: [TUHS] screen editors
In-Reply-To: <20200109020720.GG16808@mcvoy.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
Message-ID: <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>

make a new command, don't break the old one....  maybe offer a way to map
the new one over the old -- but don't make it the default.
and my lawn was lush and green before the snow came ;-)



On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
> >
> > > The first thing I do on a new machine is to install nvi. Very grateful
> to
> > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > horizontal splits but that is good enough for me as all my terminal
> > > windows are 80 chars wide. Not a vim hater but never saw the need.
> >
> > I pretty much do the same thing. I think what I hate about vim is that
> it's
> > almost, vi but not the same. My fingers screw up when I use it.  For
> > instance, he 'fixed' undo.
>
> Holy crap Clem, you need to embrace that.  His undo goes back forever.
> And you can undo the undo and go forward forever.
>
> Not liking that puts you in the "get off my lawn" old guy camp.  Which
> is fine if that's who you want to be (sometimes I'm that guy).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/eef907ad/attachment.html>

From grog at lemis.com  Thu Jan  9 12:14:03 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 9 Jan 2020 13:14:03 +1100
Subject: [TUHS] screen editors
In-Reply-To: <20200109012830.GC16808@mcvoy.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
Message-ID: <20200109021403.GR64020@eureka.lemis.com>

On Wednesday,  8 January 2020 at 17:28:30 -0800, Larry McVoy wrote:
> On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
>> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
>> default for vi.
>
> I was gonna stay out of this thread (it has the feel of old folks somehow)
> but 2 comments:
>
> Keith did nvi (I can't remember why?  licensing or something)

My vague recollection is that Rob Kolstad paid him to do it for
BSD/386.  As you say, licensing, and that BSD/386 *really* needed a vi
editor.

Does anybody know where Rob is?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/a482f006/attachment.sig>

From chet.ramey at case.edu  Thu Jan  9 12:48:40 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 8 Jan 2020 21:48:40 -0500
Subject: [TUHS] screen editors
In-Reply-To: <20200109021403.GR64020@eureka.lemis.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com> <20200109021403.GR64020@eureka.lemis.com>
Message-ID: <afc4a1fb-01a0-0826-b267-21397a311f9a@case.edu>

On 1/8/20 9:14 PM, Greg 'groggy' Lehey wrote:

> My vague recollection is that Rob Kolstad paid him to do it for
> BSD/386.  As you say, licensing, and that BSD/386 *really* needed a vi
> editor.
> 
> Does anybody know where Rob is?

Colorado Springs, according to Twitter.

-- 
``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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/9a4b49ce/attachment.sig>

From bakul at bitblocks.com  Thu Jan  9 12:59:02 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Jan 2020 18:59:02 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
Message-ID: <E96EAE49-D51D-4C7D-9D2C-D438D74722E7@bitblocks.com>

Early in vim’s life I had emailed Moolenaar asking him if he would be
willing to add an option for nvi like behavior for undo/redo. He wasn’t
interested so I lost interest. nvi’s u & . behavior is not only quite clever
but also  much more intuitive and you don’t have to press the ctl key!

> On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)
> 
> 
> 
> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
> > 
> > > The first thing I do on a new machine is to install nvi. Very grateful to
> > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > horizontal splits but that is good enough for me as all my terminal
> > > windows are 80 chars wide. Not a vim hater but never saw the need.
> > 
> > I pretty much do the same thing. I think what I hate about vim is that it's
> > almost, vi but not the same. My fingers screw up when I use it.  For
> > instance, he 'fixed' undo.   
> 
> Holy crap Clem, you need to embrace that.  His undo goes back forever.
> And you can undo the undo and go forward forever.  
> 
> Not liking that puts you in the "get off my lawn" old guy camp.  Which
> is fine if that's who you want to be (sometimes I'm that guy).


From lm at mcvoy.com  Thu Jan  9 13:08:53 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Jan 2020 19:08:53 -0800
Subject: [TUHS] screen editors
In-Reply-To: <E96EAE49-D51D-4C7D-9D2C-D438D74722E7@bitblocks.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <E96EAE49-D51D-4C7D-9D2C-D438D74722E7@bitblocks.com>
Message-ID: <20200109030853.GH16808@mcvoy.com>

I feel like there is an option to get nvi behaviour now but I dunno
why you want that.  Are you seriously advocating for less?  Because
objectively vim gives you more.

And it is faithful to vi, it has all the buffers so you can put stuff
back that way.

Maybe I'm clueless or I drank the koolaid, but I love vim.  It's vi
but better.

On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote:
> Early in vim???s life I had emailed Moolenaar asking him if he would be
> willing to add an option for nvi like behavior for undo/redo. He wasn???t
> interested so I lost interest. nvi???s u & . behavior is not only quite clever
> but also  much more intuitive and you don???t have to press the ctl key!
> 
> > On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc at ccc.com> wrote:
> > 
> > make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
> > and my lawn was lush and green before the snow came ;-)
> > 
> > 
> > 
> > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
> > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
> > > 
> > > > The first thing I do on a new machine is to install nvi. Very grateful to
> > > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > > horizontal splits but that is good enough for me as all my terminal
> > > > windows are 80 chars wide. Not a vim hater but never saw the need.
> > > 
> > > I pretty much do the same thing. I think what I hate about vim is that it's
> > > almost, vi but not the same. My fingers screw up when I use it.  For
> > > instance, he 'fixed' undo.   
> > 
> > Holy crap Clem, you need to embrace that.  His undo goes back forever.
> > And you can undo the undo and go forward forever.  
> > 
> > Not liking that puts you in the "get off my lawn" old guy camp.  Which
> > is fine if that's who you want to be (sometimes I'm that guy).

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From mah at mhorton.net  Thu Jan  9 13:27:13 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 8 Jan 2020 19:27:13 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
Message-ID: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>

vim has an option to undo the vi way. "set cpoptions=u". There is a full 
set of vi-compatible options if you want them. "set cp" turns on full vi 
compatiblity.

Funny, I see vim as the vi that comes with UNIX, and never learned the 
enhancements, but I just tried it out and I don't have the compatibility 
option set. I don't seem to have noticed. I guess I don't do the "undo 
toggle" all that often.

     Mary Ann

On 1/8/20 6:12 PM, Clem Cole wrote:
> make a new command, don't break the old one....  maybe offer a way to 
> map the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)
>
>
>
> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com 
> <mailto:lm at mcvoy.com>> wrote:
>
>     On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>     > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com
>     <mailto:bakul at bitblocks.com>> wrote:
>     >
>     > > The first thing I do on a new machine is to install nvi. Very
>     grateful to
>     > > Keith Bostic for implementing it. I do use multiple windows
>     ??? only
>     > > horizontal splits but that is good enough for me as all my
>     terminal
>     > > windows are 80 chars wide. Not a vim hater but never saw the need.
>     >
>     > I pretty much do the same thing. I think what I hate about vim
>     is that it's
>     > almost, vi but not the same. My fingers screw up when I use it.  For
>     > instance, he 'fixed' undo.
>
>     Holy crap Clem, you need to embrace that.  His undo goes back forever.
>     And you can undo the undo and go forward forever.
>
>     Not liking that puts you in the "get off my lawn" old guy camp.  Which
>     is fine if that's who you want to be (sometimes I'm that guy).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/1d2de737/attachment.html>

From lm at mcvoy.com  Thu Jan  9 13:34:18 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Jan 2020 19:34:18 -0800
Subject: [TUHS] screen editors
In-Reply-To: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
Message-ID: <20200109033418.GI16808@mcvoy.com>

+1

On Wed, Jan 08, 2020 at 07:27:13PM -0800, Mary Ann Horton wrote:
> vim has an option to undo the vi way. "set cpoptions=u". There is a full set
> of vi-compatible options if you want them. "set cp" turns on full vi
> compatiblity.
> 
> Funny, I see vim as the vi that comes with UNIX, and never learned the
> enhancements, but I just tried it out and I don't have the compatibility
> option set. I don't seem to have noticed. I guess I don't do the "undo
> toggle" all that often.
> 
> ?????? Mary Ann
> 
> On 1/8/20 6:12 PM, Clem Cole wrote:
> >make a new command, don't break the old one....?? maybe offer a way to map
> >the new one over the old -- but don't make it the default.
> >and my lawn was lush and green before the snow came ;-)
> >
> >
> >
> >On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com
> ><mailto:lm at mcvoy.com>> wrote:
> >
> >    On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> >    > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com
> >    <mailto:bakul at bitblocks.com>> wrote:
> >    >
> >    > > The first thing I do on a new machine is to install nvi. Very
> >    grateful to
> >    > > Keith Bostic for implementing it. I do use multiple windows
> >    ??? only
> >    > > horizontal splits but that is good enough for me as all my
> >    terminal
> >    > > windows are 80 chars wide. Not a vim hater but never saw the need.
> >    >
> >    > I pretty much do the same thing. I think what I hate about vim
> >    is that it's
> >    > almost, vi but not the same. My fingers screw up when I use it.?? For
> >    > instance, he 'fixed' undo.
> >
> >    Holy crap Clem, you need to embrace that.?? His undo goes back forever.
> >    And you can undo the undo and go forward forever.
> >
> >    Not liking that puts you in the "get off my lawn" old guy camp.?? Which
> >    is fine if that's who you want to be (sometimes I'm that guy).
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From davida at pobox.com  Thu Jan  9 13:25:18 2020
From: davida at pobox.com (David Arnold)
Date: Thu, 9 Jan 2020 14:25:18 +1100
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
 <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
Message-ID: <AF770512-52FD-4A2C-8E54-6487AA085E87@pobox.com>

> On 9 Jan 2020, at 10:29, Harald Arnesen <skogtun at gmail.com> wrote:
> Den 08.01.2020 23:15, skrev Dave Horsfall:
> 
>> Similarly, I have a Penguin laptop at home for porting purposes, otherwise I never use it.  The cycle goes something like: get it working on both FreeBSD and the Mac (fairly easy), try it on the Penguin to see what they've broken and make the appropriate changes, then back to the Mac and the FreeBSD box again; repeat as necessary.  If worse comes to worst, make the code conditional upon the architecture (and I hate doing that, because it breaks the logical flow of the code).
> 
> In my experience, macOS breaks more things these days.

When I first used “Unix” in the late 80’s, most of the available source code needed some sort of tweaking to work, unless the author happened to have the same system I was using (HP/UX, Minix, and a BSD VAX, iirc).  A rummage through the GNU’s autoconf docs will (re)acquaint you with he multitude of small differences that needed to be accounted for to make most things portable.

Then Sun became the dominant vendor, and most things would work out of the box on SunOS / Solaris, with different degrees of effort required depending on how different your system was.  I was working for a DEC-sponsored lab at the time, and Ultrix was more in the BSD camp than Solaris, but there was usually someone had done some BSD-style tweaks that could be co-opted into mostly working for Ultrix.  Then we got the fancy new DEC3000 Alphas, and to a first approximation, *nothing* worked (although that was mostly 64 bit pointers, rather than OSF/1).

As Linux has become increasingly popular, things now almost universally work out of the box on Linux, with some work required to make macOS, *BSD, and the other commercial Unices work.  Often now, there’s no autoconf (at least for newer projects) or it’s poorly maintained, and I find myself back to the 80s-style patching to get stuff to run on systems other than Linux.

Whenever one system becomes too popular, the definition of “Unix” drifts in that direction …




d


From bakul at bitblocks.com  Thu Jan  9 13:43:50 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Jan 2020 19:43:50 -0800
Subject: [TUHS] screen editors
In-Reply-To: <20200109030853.GH16808@mcvoy.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <E96EAE49-D51D-4C7D-9D2C-D438D74722E7@bitblocks.com>
 <20200109030853.GH16808@mcvoy.com>
Message-ID: <3CF02E3C-1BA4-4982-868C-709677FE2FF1@bitblocks.com>

If this option was added back then (992-94) I might have switched
over. I think I was tempted as it was “programmable”. But as it didn’t
have any other new features that I really wanted plus I was always
messing up undo/redo, probably like Clem, there was not much
point in switching. As it happens, I didn’t use the programmability
feature even when it was added to nvi!

No point in advocating as anyone who is used to the “more” of vim
would be frustrated with nvi!

> On Jan 8, 2020, at 7:08 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> I feel like there is an option to get nvi behaviour now but I dunno
> why you want that.  Are you seriously advocating for less?  Because
> objectively vim gives you more.
> 
> And it is faithful to vi, it has all the buffers so you can put stuff
> back that way.
> 
> Maybe I'm clueless or I drank the koolaid, but I love vim.  It's vi
> but better.
> 
> On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote:
>> Early in vim???s life I had emailed Moolenaar asking him if he would be
>> willing to add an option for nvi like behavior for undo/redo. He wasn???t
>> interested so I lost interest. nvi???s u & . behavior is not only quite clever
>> but also  much more intuitive and you don???t have to press the ctl key!
>> 
>>> On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc at ccc.com> wrote:
>>> 
>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>> and my lawn was lush and green before the snow came ;-)
>>> 
>>> 
>>> 
>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
>>>> 
>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>> 
>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>> instance, he 'fixed' undo.   
>>> 
>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>> And you can undo the undo and go forward forever.  
>>> 
>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>> is fine if that's who you want to be (sometimes I'm that guy).
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From bakul at bitblocks.com  Thu Jan  9 13:49:49 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Jan 2020 19:49:49 -0800
Subject: [TUHS] screen editors
In-Reply-To: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
Message-ID: <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com>

It doesn’t work the same way. I just tried it (vim-8.0.something).
The way it is supposed to work is this:  the first u undoes the last change.
Then you keep hitting . to keep undoing more. Then if you went back too far,
you hit u again, to undo the undo and further . will keep redoing. You can
go back and forth this way as many times as you wish.

> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
> 
>     Mary Ann
> On 1/8/20 6:12 PM, Clem Cole wrote:
>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>> and my lawn was lush and green before the snow came ;-)
>> 
>> 
>> 
>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
>> > 
>> > > The first thing I do on a new machine is to install nvi. Very grateful to
>> > > Keith Bostic for implementing it. I do use multiple windows ??? only
>> > > horizontal splits but that is good enough for me as all my terminal
>> > > windows are 80 chars wide. Not a vim hater but never saw the need.
>> > 
>> > I pretty much do the same thing. I think what I hate about vim is that it's
>> > almost, vi but not the same. My fingers screw up when I use it.  For
>> > instance, he 'fixed' undo.   
>> 
>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>> And you can undo the undo and go forward forever.  
>> 
>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>> is fine if that's who you want to be (sometimes I'm that guy).


From mah at mhorton.net  Thu Jan  9 13:55:59 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 8 Jan 2020 19:55:59 -0800
Subject: [TUHS] screen editors
In-Reply-To: <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
 <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com>
Message-ID: <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net>

Are you referring to the special case where an undo of "p" (put) will 
sucessively re-insert the most recent things you've deleted?

I just tried that in vim and it didn't seem to support the special case 
the way vi did.

     Mary Ann

On 1/8/20 7:49 PM, Bakul Shah wrote:
> It doesn’t work the same way. I just tried it (vim-8.0.something).
> The way it is supposed to work is this:  the first u undoes the last change.
> Then you keep hitting . to keep undoing more. Then if you went back too far,
> you hit u again, to undo the undo and further . will keep redoing. You can
> go back and forth this way as many times as you wish.
>
>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah at mhorton.net> wrote:
>>
>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
>>
>>      Mary Ann
>> On 1/8/20 6:12 PM, Clem Cole wrote:
>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>> and my lawn was lush and green before the snow came ;-)
>>>
>>>
>>>
>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
>>>>
>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>> instance, he 'fixed' undo.
>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>> And you can undo the undo and go forward forever.
>>>
>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>> is fine if that's who you want to be (sometimes I'm that guy).

From jon at fourwinds.com  Thu Jan  9 14:23:50 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 08 Jan 2020 20:23:50 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
Message-ID: <202001090423.0094NooZ379407@darkstar.fourwinds.com>

Clem Cole writes:
>
> make a new command, don't break the old one....  maybe offer a way to map
> the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)

Clem, this seems like an unusual position for you to take.  vim is backwards
compatible with vi (and also ed), so it added to an existing ecosystem.

Jon

From brad.harder at gmail.com  Thu Jan  9 14:33:38 2020
From: brad.harder at gmail.com (bch)
Date: Wed, 8 Jan 2020 20:33:38 -0800
Subject: [TUHS] screen editors (Bakul Shaw)
In-Reply-To: <mailman.3.1578535201.23488.tuhs@minnie.tuhs.org>
References: <mailman.3.1578535201.23488.tuhs@minnie.tuhs.org>
Message-ID: <CABfrOT_J+DD4LLqwqz=Mhr_iKUk_s_q6dyBjsJk_WA30hGu9WA@mail.gmail.com>

Date: Wed, 8 Jan 2020 17:40:10 -0800
> From: Bakul Shah <bakul at bitblocks.com>
> To: Larry McVoy <lm at mcvoy.com>
> Cc: Warner Losh <imp at bsdimp.com>, The Eunuchs Hysterical Society
>         <tuhs at tuhs.org>
> Subject: Re: [TUHS] screen editors
> Message-ID: <D192F5A5-2A67-413C-8F5C-FCF195151E4F at bitblocks.com>
> Content-Type: text/plain;       charset=utf-8
>
> On Jan 8, 2020, at 5:28 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
> >> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave at horsfall.org> wrote:
> >>
> >>> On Wed, 8 Jan 2020, Chet Ramey wrote:
> >>>
> >>>>> That's a real big vi in RHL.
> >>>>
> >>>> It's vim.
> >>>
> >>> It's also VIM on the Mac.
> >>>
> >>
> >> Nvi is also interesting and 1/10th the size of vim. It's also the
> FreeBSD
> >> default for vi.
> >
> > I was gonna stay out of this thread (it has the feel of old folks
> somehow)
> > but 2 comments:
> >
> > Keith did nvi (I can't remember why?  licensing or something) and he did
> > a pretty faithful bug for bug compatible job.  I've always wondered why.
> > I like Keith but it seemed like a waste.  There were other people taking
> > vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap
> > the file and had a whole string library that treated \n like NULL) and
> > I think vim was coming along.  So doing a compat vi felt like a step
> > backward for me.
> >
> > For all the vim haters, come on.  Vim is awesome, it gave me the one
> > thing that I wanted from emacs, multiple windows.  I use that all the
> > time.  It's got piles of stuff that I don't use, probably should, but
> > it is every bit as good of a vi as the original and then it added more.
> > I'm super grateful that vim came along.
>
> The first thing I do on a new machine is to install nvi. Very grateful to
> Keith Bostic for implementing it. I do use multiple windows — only
> horizontal splits but that is good enough for me as all my terminal
> windows are 80 chars wide. Not a vim hater but never saw the need.
>

Not sure if you’re saying horizontal splits are all you need, or all you’re
aware of, but nvi “:E somefile” will split to a top/bottom arrangement and
“:vsplit somefile” will do a left/right arrangement, as well as being able
to “:fg”, “:bg” screens. I too am a (NetBSD) nvi appreciator.

-bch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/41f48dcf/attachment.html>

From athornton at gmail.com  Thu Jan  9 14:56:51 2020
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 8 Jan 2020 21:56:51 -0700
Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines)
In-Reply-To: <AF770512-52FD-4A2C-8E54-6487AA085E87@pobox.com>
References: <20200107105615.GA16081@minnie.tuhs.org>
 <alpine.NEB.2.21.2001071617230.50@t1.m.reedmedia.net>
 <alpine.BSF.2.21.9999.2001081009090.40155@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.2001090854000.40155@aneurin.horsfall.org>
 <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com>
 <AF770512-52FD-4A2C-8E54-6487AA085E87@pobox.com>
Message-ID: <D0A5742C-05C8-43B3-8CDD-EE3B2A446A64@gmail.com>


On Jan 8, 2020, at 8:25 PM, David Arnold <davida at pobox.com> wrote:
> Whenever one system becomes too popular, the definition of “Unix” drifts in that direction …

“All the world’s a VAX” became “All the world’s a Linux/x86 box” about 1996, and then in 2010 or so, “all the world’s a Linux/amd64 box.”

At least ARM saved us from another total processor monoculture.

Adam

From jon at fourwinds.com  Thu Jan  9 14:33:28 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 08 Jan 2020 20:33:28 -0800
Subject: [TUHS] new topic - some C and filesystem history
Message-ID: <202001090433.0094XTO9381250@darkstar.fourwinds.com>

Working on a new project that's unfortunately going to require some changes
to the linux kernel.  Lived a lot of my life in the embedded world, haven't
touched a *NIX kernel since 4.3BSD.  Am writing a travelogue as I find my way
around the code.  Wasn't planning another book but this might end up being
one.  Anyway, a few questions...

Was looking at the filesystem super_block structure.  A large number of the
members of the structure (but not all) begin with a s_ prefix, and some of
the member names are in the 20 character long range.  I recall that using
prefixes was necessary before structures and unions had their own independent
namespaces.  But I also seem to recall that that was fixed before long
identifier names happened.  Does anybody remember the ordering for these two
events?

Also, anybody know where the term superblock originated?  With what filesystem?

Jon

From gtaylor at tnetconsulting.net  Thu Jan  9 15:01:04 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 8 Jan 2020 22:01:04 -0700
Subject: [TUHS] screen editors
In-Reply-To: <bbe88baca838c50fcae26183e389bd94@firemail.de>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
 <bbe88baca838c50fcae26183e389bd94@firemail.de>
Message-ID: <bddcdc90-5388-36bd-c9a1-3f7833835d67@spamtrap.tnetconsulting.net>

On 1/7/20 12:14 PM, Thomas Paulsen wrote:
> I do ed/se occasionally for simple tasks

Was that supposed to be "sed"?  Or is "se" something that I'm not 
familiar with?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200108/c94b7435/attachment-0001.bin>

From bakul at bitblocks.com  Thu Jan  9 15:27:02 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Jan 2020 21:27:02 -0800
Subject: [TUHS] screen editors
In-Reply-To: <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net>
 <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com>
 <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net>
Message-ID: <70DD8BD7-DF59-4C8D-9611-815B83A18106@bitblocks.com>

Short answer: there is no special case in nvi.
P or p put back the contents of the last delete.
u undoes whatever was the last change (including the last undo or redo).
. repeats whatever was the last modifying command.

A detailed answer would merely confuse you. At least my attempt at it!
Suggest you try out various combinations in nvi and compare with vim.

> On Jan 8, 2020, at 7:55 PM, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted?
> 
> I just tried that in vim and it didn't seem to support the special case the way vi did.
> 
>     Mary Ann
> 
> On 1/8/20 7:49 PM, Bakul Shah wrote:
>> It doesn’t work the same way. I just tried it (vim-8.0.something).
>> The way it is supposed to work is this:  the first u undoes the last change.
>> Then you keep hitting . to keep undoing more. Then if you went back too far,
>> you hit u again, to undo the undo and further . will keep redoing. You can
>> go back and forth this way as many times as you wish.
>> 
>>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah at mhorton.net> wrote:
>>> 
>>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
>>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
>>> 
>>>     Mary Ann
>>> On 1/8/20 6:12 PM, Clem Cole wrote:
>>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>>> and my lawn was lush and green before the snow came ;-)
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm at mcvoy.com> wrote:
>>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul at bitblocks.com> wrote:
>>>>> 
>>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>>> instance, he 'fixed' undo.
>>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>>> And you can undo the undo and go forward forever.
>>>> 
>>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>>> is fine if that's who you want to be (sometimes I'm that guy).


From arnold at skeeve.com  Thu Jan  9 18:30:02 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 09 Jan 2020 01:30:02 -0700
Subject: [TUHS] screen editors
In-Reply-To: <e31f5e4e-73f5-c68e-b22a-30527f6ddeea@mhorton.net>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
 <e31f5e4e-73f5-c68e-b22a-30527f6ddeea@mhorton.net>
Message-ID: <202001090830.0098U2nq019546@freefriends.org>

Mary Ann Horton <mah at mhorton.net> wrote:

> Nearly everyone at Bell Labs (outside area 11) was using either vi or 
> emacs, but System III just had ed. There was a big push to add vi or 
> emacs to UNIX 3.0 (System III), but USG instead chose to write se, the 
> "screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 
> (System V) relented and included vi.

Thanks for confirming that se existed in Unix 4.0, as I remember it.
I used it some; the only thing I remember about it was that the command
line was at the top of the screen.

I must have been disappointed with it, because I ended up doing most
of my contract programming work in ed. :-)

It'd be interesting to see the source for this 'se', but it's probably
lost forever.

Arnold

From thomas.paulsen at firemail.de  Thu Jan  9 19:05:48 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Thu, 09 Jan 2020 10:05:48 +0100
Subject: [TUHS] screen editors
In-Reply-To: <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
Message-ID: <474f81dd98f8143b5875fda2bf10345d@firemail.de>

> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi.


check out elvis https://github.com/mbert/elvis 
vi + syntax highlighting + clean help subsystem = ~ 25% of size of vim 



From clemc at ccc.com  Fri Jan 10 01:54:44 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 9 Jan 2020 10:54:44 -0500
Subject: [TUHS] screen editors
In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
Message-ID: <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>

Answering, but  CCing COFF if folks want to continue.  This is less about
UNIX and more about how we all got to where we are.

On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Clem, this seems like an unusual position for you to take.  vim is
> backwards
> compatible with vi (and also ed), so it added to an existing ecosystem.
>
No, really unusually when you think about it.  vim is backward compatible
except when it's not (as Bakul points out) - which is my complaint.  It's
*almost* compatible and those small differences are really annoying when
you expect one thing and get something else (*i.e.* the least astonishment
principle).

The key point here is for *some people*, those few differences are not an
issue and are not astonished by them.  But for *some of the rest of us*
(probably people like me that have used the program since PDP-11 days) that
only really care about the original parts, the new stuff is of little value
and so the small differences are astonishing.  Which comes back to the
question of good and best.   It all depends on one what you value/where you
put the high order bit.  I'm not willing to "pay" for the it; as it gives
me little value.

Doug started this thread with his observation that ex/vi was huge compared
to other editors. * i.e.* value: small simple easy to understand (Rob's old
"*cat -v considered harmful*" argument if you will).  The BSD argument had
always been: "the new stuff is handy." The emacs crew tends to take a
similar stand.  I probably don't go quite as far as Rob, but I certainly
lean in that direction.  I generally would rather something small and new
that solves a different (set of) problem(s), then adding yet another wart
on to an older program, *particularly when you change the base
functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial
credit' does not cut it].

To me, another good example is 'more', 'less' and 'pg'.  Eric Schienbrood
wrote the original more(ucb) to try to duplicate the ITS functionality (he
wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and
4.1BSD was a few years in the future - so small an simple of a huge
value).  It went out in the BSD tapes, people loved it and were happy.  It
solved a problem as we had it.  Life was good.  Frankly, other than NIH,
I'm not sure why the folks at AT&T decided to create pg a few years later
since more was already in the wild, but at least it was a different program
(Mary Ann's story of vi *vs*. se if probably in the same vein).   But
because of that behavior, if someone like me came to an AT&T based system
with only pg installed, so those of us that liked/were used to more(ucb)
could install it and life was good.   Note pg was/is different in
functionality, it's similar, but not finger compatible.

But other folks seem to have thought neither was 'good enough' -- thus
later less(gnu) was created adding a ton of new functionality to Eric's
program.  The facts are clear, some (ney many) people >>love<< that new
functionality, like going backward.  I >>personally<< rarely care/need for
it, Eric's program was (is) good enough for me.   Like Doug's observation
of ed *vs.* ex/vi; less is huge compared to the original more (or pg for
that matter).   But if you value the new features, I suspect you might
think that's not an issue.  Thanks to Moore's law, the size in this case
probably does not matter too much (other than introducing new bugs).    At
least, when folks wrote did Gnu's less, the basic more(ucb) behavior was
left along and if you set PAGER=more less(gnu) pretty much works as I
expect it too.  So I now don't bring Eric's program with me, the same way
Bakul describes installing nvi on new systems (an activiity I also do).

Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do
>>occaisonally<< use split screens, but frankly, I can get most of the same
from having a window manager, different iterm2 windows and cut/paste.   So
even that extension to nvi, is of limited value to me.  vim just keeps
adding more and more cruft and its even bigger.   I personally don't care
for the new functionality, and the size of it all is worrisome.  What am I
buying?  That said, if the new features do not hurt me, then I don't really
care.  I might even use some of the new functionality - hey I run mac OS
not v7 or BSD 4.x for my day to day work and I do use the mac window
manager, the browser *et al*, but as I type this message I have 6 other
iterm2 windows open with work I am doing in other areas.

Let me take a look at this issue in a different way.   I have long been a
'car guy' and like many of those times in my youth spent time and money
playing/racing etc. I've always thought electric was a great idea/but there
has been nothing for me. Note: As many of you know my work in computers has
been in HPC, and I've been lucky to spend a lot of time with my customers,
in the auto and aerospace industry (*i.e.* the current Audi A6 was designed
on one of my supercomputer systems).  The key point is have tended to
follow technology in their area and tend to "in-tune" with a lot of
developments.  The result, except for my wife's minivan (that she preferred
in the years when our kids were small), I've always been a
die-hard German-engineered/performance car person.  But when Elon announced
the Model 3 (like 1/2 the techie world), I put down a deposit and waited.

Well why I was waiting, my techie daughter (who also loves cars), got a
chance to drive one.   She predicted I would hate it!!! So when my ticket
finally came up, I went to drive them.  She was right!!!  With the Model 3,
you get a cool car, but it's about the size of a Corrolla.  Coming from
Germans cars for the last 35 years, the concept of spending $60K US in
practice for a Corrolla just did not do it for me.   I ended up ordering the
current Unixmobile, my beloved Tesla Model S/P100D.

The truth is, I paid a lot of money for it but I *value *what I got for my
money. A number of people don't think it's worth it.  I get that, but I'm
still happy with what I have.   Will there someday be a $20K electric car
like my Model S?  While I think electric cars will get there (I point out
the same price curve on technology such microwave ovens from the 1970so
today), but I actually doubt that there will be a $20K electric vehicle
like my Model S.

The reason is that to sell this car because it as to be expensive for
technology-based reasons, so Tesla had to add a lot of 'luxury' features
like other cars in the class, other sports cars, Mercedes,  *et al*.  As
they removed them (*i.e.* the Model 3) you still get a cool car, but it's
not at all the same as the Model S.   So the point is, if I wanted an
electric car, I had to choose between a performance/luxury *vs*.
size/functionality.  I realized I valued the former (and still do), but I
understand not everyone does or will.

Coming back to our topic, I really don't think this is a 'get my lawn'
issue as much, as asking someone what they really value/what they really
need.   If you place a high-value you something, you will argue that its
best; if it has little value you will not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/6847239f/attachment.html>

From jon at fourwinds.com  Fri Jan 10 03:21:40 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 09 Jan 2020 09:21:40 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
Message-ID: <202001091721.009HLf2V503811@darkstar.fourwinds.com>

Clem Cole writes:
>
> Answering, but  CCing COFF if folks want to continue.  This is less about
> UNIX and more about how we all got to where we are.
>
> On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Clem, this seems like an unusual position for you to take.  vim is
> > backwards
> > compatible with vi (and also ed), so it added to an existing ecosystem.
> >
> No, really unusually when you think about it.  vim is backward compatible
> except when it's not (as Bakul points out) - which is my complaint.  It's
> *almost* compatible and those small differences are really annoying when
> you expect one thing and get something else (*i.e.* the least astonishment
> principle).
>
> ...

OK, ok, the point that it's not 100% compatible wins the day.  Couple more
points and then it's time to move on.

While I spend a lot of time railing against bad programming, the fact that
vim is huge doesn't bother me too much because my machine has more memory
that the machine on which I started using vi had disk.  And just because it
still blows my mind, my machine (on just one of the drives) has more disk
than was available in the world when I started using vi.  Good chance that
my CPU has more cache memory than the PDP-11/70 on which I started using vi
had main memory.  So the size doesn't matter too much for me.

One of the reasons that I chose vi over emacs was architectural.  At a certain
level, vi was a text editor and emacs was an operating system, and since I was
running UNIX and was a UNIX philosophy person I just didn't want to be running
an operating system on top of an operating system just to do text editing.

It's for that reason that I hate the addition of multiple windows to vi.  I
already have a windowing system on my machine, and that's what I use for windows.
To me, the correct thing to do is to open a new desktop window to edit a new file
and start a new instance of vi, not to use vi to open another internal window.

I guess that what I'm saying is that I think that rather than following the
UNIX philosophy of having distinct tools and composing, much modern software tries
to do too much stuff that's not unique to its domain.  A strained analogy would be
if every "little language" felt that it had to re-implement a big language too.

Jon

From imp at bsdimp.com  Fri Jan 10 03:30:07 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 9 Jan 2020 10:30:07 -0700
Subject: [TUHS] screen editors
In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
Message-ID: <CANCZdfqDSQanoCT9f3RFR7mCC0bk0hJkqe=jt=ncgwFu__UUGA@mail.gmail.com>

On Thu, Jan 9, 2020 at 10:22 AM Jon Steinhart <jon at fourwinds.com> wrote:

> One of the reasons that I chose vi over emacs was architectural.  At a
> certain
> level, vi was a text editor and emacs was an operating system, and since I
> was
> running UNIX and was a UNIX philosophy person I just didn't want to be
> running
> an operating system on top of an operating system just to do text editing.
>

I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines
at school had emacs as the default editor) and also because it lets me
program better. I didn't let the fact it accomplished that by trying to be
an OS or LISP-M or whatever get in the way of using the best tool for the
job. In the 90s this meant that I had to be careful about the machines I
used it on. These days, it just doesn't matter. Mostly, though, it was
finger muscle memory :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/6071e7d0/attachment.html>

From jon at fourwinds.com  Fri Jan 10 03:45:26 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 09 Jan 2020 09:45:26 -0800
Subject: [TUHS] screen editors and beyond
In-Reply-To: <CANCZdfqDSQanoCT9f3RFR7mCC0bk0hJkqe=jt=ncgwFu__UUGA@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
 <CANCZdfqDSQanoCT9f3RFR7mCC0bk0hJkqe=jt=ncgwFu__UUGA@mail.gmail.com>
Message-ID: <202001091745.009HjQ3L507739@darkstar.fourwinds.com>

Warner Losh writes:
>
> I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines
> at school had emacs as the default editor) and also because it lets me
> program better. I didn't let the fact it accomplished that by trying to be
> an OS or LISP-M or whatever get in the way of using the best tool for the
> job. In the 90s this meant that I had to be careful about the machines I
> used it on. These days, it just doesn't matter. Mostly, though, it was
> finger muscle memory :)
>
> Warner

That's a great reason.  I never did any bodybuilding with emacs so I have
different muscle memory.

There is another reason why I stayed away from emacs which is that I was
running projects at the time - I had graduated from being an individual
contributor.  The multiple versions of emacs got in the way.  We had too
many instances where one person would ask another person for help or to
review something, but people using different tools interfered with the
ability of people to walk over to another terminal and get stuff done.

Because of this, I made and enforced a rule that said that one could only 
use shell aliases if they didn't redefine any existing commands.  It was
important for people to be able to work together.  Things were getting
so flexible that it was as if everybody had their own custom power outlets at
their desks preventing any other group member from coming over and plugging
something in.

Taking this in a different direction, one of the other rules that I enforced
was "don't redefine the programming language."  This is in my mind right now
as I try to navigate the linux kernel.  Someone obviously didn't like C and
made a bunch of overly complicated constructs via macros to change it to
something else generating bad code in the process.  It reminded me of the
first time that I ran across this, which was the Bourne shell in C redefined
as Algol.  I recently asked Steve about why he did this and he did give me
an answer which he said I couldn't share until he refined it.  He probably
forgot over the holidays but since I think he's on this list maybe he'll
weigh in.

One amusing thing that Steve told me which I think I can share is why the
symmetry of case-esac, if-fi was broken with with do-done; it was because
the od command existed so do-od wouldn't work!

Jon

From bakul at bitblocks.com  Fri Jan 10 03:56:07 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 9 Jan 2020 09:56:07 -0800
Subject: [TUHS] screen editors
In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
Message-ID: <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com>

On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> It's for that reason that I hate the addition of multiple windows to vi.  I
> already have a windowing system on my machine, and that's what I use for windows.
> To me, the correct thing to do is to open a new desktop window to edit a new file
> and start a new instance of vi, not to use vi to open another internal window.

The Rand editor made good use of multiple windows. You could set things up so
that two windows would scroll *in sync*. This is handy e.g. when you are looking
at two columns or rows that far apart in the same file or in different files and
too large so you need to scroll.

Acme makes even better use of multiple windows. Right click on a compile error
message in one window and the cursor moves the error causing line in the source
file in another window etc. You can repeat as many times as you want.

So I tend to think combining multiple windows and editing can be effective.

> I guess that what I'm saying is that I think that rather than following the
> UNIX philosophy of having distinct tools and composing, much modern software tries
> to do too much stuff that's not unique to its domain.  A strained analogy would be
> if every "little language" felt that it had to re-implement a big language too.

Finding the "right cut" of functionality is not easy. Scheme or Common Lisp?
Editors and a set of tools or an all singing all dancing IDE? Can one implement
something like Photoshop as a set of separate tools that can be combined any way?

What old style Unix tools give you is isolation and (one way) controlled
communication. Can this model be generalized to a set of Lego blocks out of
which one can compose even complex tools such as Photoshop as easily is an open
question. 



From lm at mcvoy.com  Fri Jan 10 04:53:27 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 9 Jan 2020 10:53:27 -0800
Subject: [TUHS] screen editors
In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
Message-ID: <20200109185327.GJ16808@mcvoy.com>

On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote:
> It's for that reason that I hate the addition of multiple windows to vi.  

That's just silly.  I frequently open two panes on the same file.  Lets
compare:

Your way:
	- click to open a new terminal
	- click on it because it's not where I want, move it
	- cd to where ever I am
	- vi whatever

My way:
	:sp

You are welcome to your opinion but to argue that multiple panes in
vi aren't useful, fine, maybe not to you.  Don't use them.  Other
people love that feature, that feature is why I tried emacs many
years ago.

From jon at fourwinds.com  Fri Jan 10 05:01:28 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 09 Jan 2020 11:01:28 -0800
Subject: [TUHS] screen editors
In-Reply-To: <20200109185327.GJ16808@mcvoy.com>
References: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
 <20200109185327.GJ16808@mcvoy.com>
Message-ID: <202001091901.009J1StW520950@darkstar.fourwinds.com>

Larry McVoy writes:
> On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote:
> > It's for that reason that I hate the addition of multiple windows to vi.  
>
> That's just silly.  I frequently open two panes on the same file.  Lets
> compare:
>
> Your way:
> 	- click to open a new terminal
> 	- click on it because it's not where I want, move it
> 	- cd to where ever I am
> 	- vi whatever
>
> My way:
> 	:sp
>
> You are welcome to your opinion but to argue that multiple panes in
> vi aren't useful, fine, maybe not to you.  Don't use them.  Other
> people love that feature, that feature is why I tried emacs many
> years ago.

Yes, that is my opinion and clearly yours is different.

Being as I have a huge hi-res screen, I often have other windows
open and ready to do, so all I have to do is move the mouse.

But really to me you're opening yet another can of worms, which is what
I call the "string theory school of design" where every new program
creates its own universe instead of functioning in the existing one.
I'm working on a demonstration project to illuminate a different path,
but it's gonna be a while before I have something to show.

Jon

From steffen at sdaoden.eu  Fri Jan 10 05:02:19 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 09 Jan 2020 20:02:19 +0100
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
Message-ID: <20200109190219.bdHOi%steffen@sdaoden.eu>

Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\
mail.gmail.com>:
 |Answering, but  CCing COFF if folks want to continue.  This is less \
 |about UNIX and more about how we all got to where we are.
 ...

To me endless undo of vim is great, and i am used to it.  I think
i could compile a version from ~20 years ago, supposed to be much
smaller, and i would be ok with it.  You have other windows open,
ok, but you have typed this in a browser that consumes more memory
than all the programs running here altogether have (real), within
a codebase that consists of millions and millions lines of code.
I mean hey, even though decades of development and tens of
thousands of eyes passed, i see super simple compiler errors in
gcc and clang, and except for optimization maybe not that much
improvement in useful diagnostics, even though the executables
are 150 times and more greater than that.

For example i have a netrc parser which uses a fixed size target
buffer, in a 90 lines function, with comments, empty lines, and
a static structure of token types to test-iterate against, and
with a possibly *off++=by;*off='\0'; one, but it took
a Coverity.com run to detect it.  (Actually it is worse, because
this code is from 2014, and it seems only the combination of gcc
8.3.0 and the current cov-analysis-linux64-2019.03 could find it;
not in August, when i checked for the second to last, but only for
the last check.)

 |Let me take a look at this issue in a different way.   I have long \
 |been a 'car guy' and like many of those times in my youth spent time \
 |and money playing/racing etc. I've always thought electric was a 
 |great idea/but there has been nothing for me. Note: As many of you \
 |know my work in computers has been in HPC, and I've been lucky to spend \
 |a lot of time with my customers, in the auto and aerospace 
 |industry (i.e. the current Audi A6 was designed on one of my supercomputer \
 |systems).  The key point is have tended to follow technology in their \
 |area and tend to "in-tune" with a lot of developments.  
 |The result, except for my wife's minivan (that she preferred in the \
 |years when our kids were small), I've always been a die-hard German-eng\
 |ineered/performance car person.  But when Elon announced 
 |the Model 3 (like 1/2 the techie world), I put down a deposit and waited.
 |
 |Well why I was waiting, my techie daughter (who also loves cars), got \
 |a chance to drive one.   She predicted I would hate it!!! So when my \
 |ticket finally came up, I went to drive them.  She was right!!!  
 |With the Model 3, you get a cool car, but it's about the size of a \
 |Corrolla.  Coming from Germans cars for the last 35 years, the concept \
 |of spending $60K US in practice for a Corrolla just did not do it 
 |for me.   I ended up ordering the current Unixmobile, my beloved Tesla \
 |Model S/P100D. 

Corolla is not $60K. So you want 500 horse power, maybe.

 |The truth is, I paid a lot of money for it but I value what I got for \
 |my money. A number of people don't think it's worth it.  I get that, \
 |but I'm still happy with what I have.   Will there someday be a 
 |$20K electric car like my Model S?  While I think electric cars will \
 |get there (I point out the same price curve on technology such microwave \
 |ovens from the 1970so today), but I actually doubt that there 
 |will be a $20K electric vehicle like my Model S.

Well, lucky you that you can and want to spend that much money for
a, hm, car.

 |The reason is that to sell this car because it as to be expensive for \
 |technology-based reasons, so Tesla had to add a lot of 'luxury' features \
 |like other cars in the class, other sports cars, Mercedes,
 |  et al.  As they removed them (i.e. the Model 3) you still get a cool \
 |car, but it's not at all the same as the Model S.   So the point is, \
 |if I wanted an electric car, I had to choose between a 
 |performance/luxury vs. size/functionality.  I realized I valued the \
 |former (and still do), but I understand not everyone does or will.

So i for one _totally_ - totally! - disagree.  It really drives me
up the wall.  You drive around with a 600 kilogramm or even
heavier battery.  You car is about 2000 kilogram.  That is a lot
of resource that needs to be digged, transported, assembled
.. recycled, as far as that is possible.  It increases the load on
the streets, you know, trucks have a factor of an impact higher
than cars.  I mean, in America the difference is maybe not that
big since the average car is very big on its own, i think a pick
up is the most-selled car there for many years, with each instance
being worth at least 2 of the German and Austrian etc. top seller.
You can add to that entire Europe, including England.

The entire car community did know at the end of the 80s
/ beginning of the 90s what is necessary for better Otto and
Diesel engines, and as of today, thirty years later!, not all
engines are actually using these technologies.  There is nothing
new at all regarding technology, nothing!, except of course
materials engineering and robotics.  That is a political
declaration of bankruptcy.  And i hate BMW top managers starting
over with "the problem is not the SUV driver, the problem is the
15 year old family shooting brake".  That is antisocial, ignorant,
reckless and homicidal.

And it was clear what the future after those combustion engines
will be, and that is hydrogen.  That is fuell cell and tank in
sandwich floor, with wheel hub motors.  The latter has always been
my favourite, even though it could increase moved mass, but i do
not know.  So 120 years after wheel hub we choose two on-axe to
reduce production cost.  That is composite material.  Luckily even
some market-based industries have shown the fertility and will to
develop further beyond what was there about 120 years ago,
unfortunately we the Germans not, except for rare military
developments, also decades ago.  I said 26 years ago the best
would be if each and every citizen would gain such a chassis, and
the body would be up to each and everyone, [why not] with some
"Trabant 601 based default".

Even Tesla was interesting, fifteen or so years ago.  Because they
used the Lotus Elite chassis, which is about <800 Kilogramm.
I personally am and always have been a total fan of Chapman's
Philosophy, the lighter, the more beautiful.   And if you want
comfort and industrial mass production, take the Mazda MX-5, it is
1000 Kilogramm, and has 160 horse power.  Your Tesla is still more
powerful, because it has more than 320 horse power, but it is much
heavier around the corners, and much much less swift.  Of course,
i see here in Germany in practice all men above 50 need their SUV
now (thanks America for this future relevant trend), and they look
relaxed, meaningful, potent.  Yet they are not.  See above.  And
they are not, beyond that.  They reflect reckless degeneration.
Yes, the white men's sperm production has halved, their allergies
and woewoes have increased, their abuse of substances is enormous,
and different to normal native human beings, entirely senseless
and not embedded into any cultural surroundings.

I mean, the heck.  This wave has started, we now already explore
digging much more of the necessary resources in the Atacama and
maybe already in some Portuguese nature resource.  We have
interesting things which are maybe ok, like the Honda e.  In the
ever growing mega cities with the necessary infrastructure "i
allow you to" use such city cars.  It may make sense.  What does
not make sense is installing thousands of kilometers of copper
cable to build up an infrastructure for high voltage battery
filling.  Really.  That is copper.  You know how much resources
are required to produce copper?  And in third countries our
industry does not even give the minimum shit and uses the cheap
most poisening elements to do its dirty work.  No!

Yes, just this week i think the German "Die Zeit" had an article
on trash, trash everywhere, the trash island in the pacific is now
as large as Texas they said, i know i have read about this island
of trash in an early 80s book on open sea (sailing) accidents at
the friend of my father, about 35 years ago, i blindly assume it
was smaller by then.  So only the one copper factory in Germany he
was writing about produces more Trash than all European households
altogether.  That is just one.  No!

But there you go along with batteries.  I mean they (Tesla) seem
to have made their homework regarding crash safety, though i also
disliked the crash test standards 26 years ago, and still back
crashs are not tested, and they bang a solid cube regardless of
the misalignment of at least the major masses that happens in
practice if an Escalade hits an AMC Pacer.  They seem to have
created a new user experience that is also much cheaper to build
(i do not like it), the cars have a tremendous power, and
California has a nifty Energy Mix and infrastructure to satisfy
full throttle fun.  (Maybe.)

I admit i was happy once a german car manager said dismissive
words about Tesla (yesyesyes!), but again, just to find out they
were doing and heading out for exactly the same.  Except battery
technology, maybe.  Yes, i think the Porsche Taycan has an
interesting design, i like especially the profile, i could maybe
even like the interieur, for that one, but it is too heavy and
uses the wrong technology.  And no wood.

I for one would not spend that much money for a car anyway, but
if, definitely not like that.  If i buy a CRV Hybrid, or a Suzuki
Vitara, then i can buy a Caterham, a Lotus Elise, and almost
a Morgan 3-Wheeler all in addition to end up at that price.  See,
the latter three are almost hand-built by human beings which
perform craftsmanship, they do real jobs, and can go home prowd or
at least somewhat fullfilled.  Small companies.  Buying and
refining mass production engines (here Ford, Toyota, and S&S).
And the CRV technology will at later times simply replace the
combustion engine with a fuell cell.  And it has some natural
thing in it, a wooden strip.

I personally like the Vitara, because it is only 1300 kilogramm,
can tow enough for me, has a glass roof that can be opened, has
LED lamps, does not contain any leather (no more), and if they
will use the cylinder deactivation that i demanded almost thirty
years ago, and maybe bring in the little Hybrid system they now
introduce to their Ignis and Swift, i would go for it.  The new
Subaru Forester has a 16.7 horsepower electrical add-on.  Enough
for city traffic jam stop and go!  Fiat has the wonderful
two-cylindre engine in Panda and 500, 85 to 105 horsepower.
A wonderful engine!  Ford also, it has a wonderful three-cylindre
engine.  (I am talking Europe here, mind you.)  And next year --
and here it comes!  -- next year Toyota will come over with the
new Mirai, real fuel-cell, refined, and not as a SUV!, and i think
i will buy myself that one.

 |Coming back to our topic, I really don't think this is a 'get my lawn' \
 |issue as much, as asking someone what they really value/what they really \
 |need.   If you place a high-value you something, you will 
 |argue that its best; if it has little value you will not.   

In the end all that is industrial shit.  If you are a lucky man
you are science or worked at Bell Labs.  The rest is all
industrial shit, may it be pharmacy or medicine or whatever else.
With all the little ones trying to get their place at the sun,
recklessly.  It is up to everyone to work on its own reflection
and awareness, and to bring that work into all the many which are
incapable to or uninterested in doing that.  And unfortunately
most do not.  They are never shown, too, which makes me sad.

I will now listen to the Westminster Abbey chorus singing Miserere
mei Deus, just to let you know.  And think how it must have been
by then, with simplemost illnesses and wounds killing everyone
from poor to rich, and with bad weather or other pest causing
starvation and death, with regional food only, if you were lucky,
not kilos of meat with cost backlog every day, when in early
morning hours in a dark church the first sunlight would fall
through handcrafted art- and passionful windows.

 --End of <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg at mail.gmail\
 .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  Fri Jan 10 05:19:02 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 09 Jan 2020 20:19:02 +0100
Subject: [TUHS] screen editors
In-Reply-To: <20200109190219.bdHOi%steffen@sdaoden.eu>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <20200109190219.bdHOi%steffen@sdaoden.eu>
Message-ID: <20200109191902.kbJqz%steffen@sdaoden.eu>

Steffen Nurpmeso wrote in <20200109190219.bdHOi%steffen at sdaoden.eu>:
 |Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\
 |mail.gmail.com>:
 ...
 ||Let me take a look at this issue in a different way.   I have long \
 ||been a 'car guy' and like many of those times in my youth spent time \
 ||and money playing/racing etc. I've always thought electric was a 
 ||great idea/but there has been nothing for me. Note: As many of you \
 ..
 ||Coming back to our topic, I really don't think this is a 'get my lawn' \
 ||issue as much, as asking someone what they really value/what they really \
 ||need.   If you place a high-value you something, you will 
 ||argue that its best; if it has little value you will not.   

What else.  All the many, many reports and expert assessments
which suddenly appear and point out to the last cent that and why
battery cars are better for the environment than anything else,
including fuell cell driven cars.  Heck, how i hate those.

--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 mah at mhorton.net  Fri Jan 10 06:20:20 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 9 Jan 2020 12:20:20 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
Message-ID: <52523c5b-ef07-65c8-86d9-2af6b6af20e4@mhorton.net>

Yes, I totally agree. NIH was rampant at Bell Labs in the 1980s. 
Management pushed us to use the internal tools rather than external 
tools we liked better. 3B vs Sun comes to mind. Datakit vs TCP/IP.

     Mary Ann

On 1/9/20 7:54 AM, Clem Cole wrote:
> Frankly, other than NIH, I'm not sure why the folks at AT&T decided to 
> create pg a few years later since more was already in the wild, but at 
> least it was a different program (Mary Ann's story of vi /vs/. se if 
> probably in the same vein). 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/4954db7f/attachment.html>

From norman at oclsc.org  Fri Jan 10 07:46:44 2020
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 09 Jan 2020 16:46:44 -0500
Subject: [TUHS] screen editors
Message-ID: <1578606407.15159.for-standards-violators@oclsc.org>

Do we really need another boring old editor war?  The topic
is not specific to UNIX in the least; nor, alas, is it historic.

Norman Wilson
Toronto ON
(typing this in qed)

From norman at oclsc.org  Fri Jan 10 07:53:25 2020
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 09 Jan 2020 16:53:25 -0500
Subject: [TUHS] screen editors and beyond
Message-ID: <1578606809.15476.for-standards-violators@oclsc.org>

Jon Steinhart:

  One amusing thing that Steve told me which I think I can share is why the
  symmetry of case-esac, if-fi was broken with with do-done; it was because
  the od command existed so do-od wouldn't work!

=====

As I heard the story in the UNIX room decades ago (and at least five
years after the event), Steve tried and tried to convince Ken to
rename od so that he could have the symmetry he wanted.  Ken was
unmoved.

Norman Wilson
Toronto ON

From rich.salz at gmail.com  Fri Jan 10 07:55:51 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Thu, 9 Jan 2020 16:55:51 -0500
Subject: [TUHS] screen editors and beyond
In-Reply-To: <1578606809.15476.for-standards-violators@oclsc.org>
References: <1578606809.15476.for-standards-violators@oclsc.org>
Message-ID: <CAFH29trkdoF3gOHOJPB-vi4+8Q2th1G2saRM=ZC-9jVVO3-Q5g@mail.gmail.com>

At first I wanted to know why having an "od" command interfered with the
shell's source code of #define, but then I realized y-all meant the control
structures for scripting :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/3756c5a8/attachment.html>

From clemc at ccc.com  Fri Jan 10 08:01:19 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 9 Jan 2020 17:01:19 -0500
Subject: [TUHS] screen editors and beyond
In-Reply-To: <1578606809.15476.for-standards-violators@oclsc.org>
References: <1578606809.15476.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>

On Thu, Jan 9, 2020 at 4:54 PM Norman Wilson <norman at oclsc.org> wrote:

> As I heard the story in the UNIX room decades ago (and at least five
> years after the event), Steve tried and tried to convince Ken to
> rename od so that he could have the symmetry he wanted.  Ken was
> unmoved.


I admit I'm not sure which solution is 'least astonishing.'  Just think if
DEC had used hex for years, instead of octal ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200109/0568cb95/attachment-0001.html>

From brantley at coraid.com  Fri Jan 10 08:10:39 2020
From: brantley at coraid.com (Brantley Coile)
Date: Thu, 9 Jan 2020 22:10:39 +0000
Subject: [TUHS] screen editors
In-Reply-To: <1578606407.15159.for-standards-violators@oclsc.org>
References: <1578606407.15159.for-standards-violators@oclsc.org>
Message-ID: <99522F07-91F6-4D0C-AD04-97A05817931A@coraid.com>

Why not? It's kind of nostalgic. I got to watch my first editor war back in 1983 on my newly installed netnews. The reasoning seems to be the same, only the names have changed. 

But then again, your reasoning makes sense. 

And besides, it's been all down hill since qed.

> On Jan 9, 2020, at 4:46 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> Do we really need another boring old editor war?  The topic
> is not specific to UNIX in the least; nor, alas, is it historic.
> 
> Norman Wilson
> Toronto ON
> (typing this in qed)


From wkt at tuhs.org  Fri Jan 10 09:04:27 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 10 Jan 2020 09:04:27 +1000
Subject: [TUHS] Editors -> COFF
Message-ID: <20200109230427.GB21654@minnie.tuhs.org>

All, I think the editor thread needs to move to COFF now :-)

Thanks, Warren

From robpike at gmail.com  Fri Jan 10 11:52:53 2020
From: robpike at gmail.com (Rob Pike)
Date: Fri, 10 Jan 2020 12:52:53 +1100
Subject: [TUHS] screen editors and beyond
In-Reply-To: <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>
References: <1578606809.15476.for-standards-violators@oclsc.org>
 <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>
Message-ID: <CAKzdPgybKz5j+98m8=39GhXxnX73iWLM56meH-qe+QKvvF208A@mail.gmail.com>

I wrote xd for a reason.

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/187ca915/attachment.html>

From meillo at marmaro.de  Fri Jan 10 18:13:04 2020
From: meillo at marmaro.de (markus schnalke)
Date: Fri, 10 Jan 2020 09:13:04 +0100
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
Message-ID: <1ippPk-8PE-00@marmaro.de>

Hoi.

[2020-01-09 08:49] Dave Horsfall <dave at horsfall.org>
> On Wed, 8 Jan 2020, Thomas Paulsen wrote:
> 
> > I do ed/se occasionally for simple tasks, vim frequently ,
> > because it loads fast, and emacs for all bigger projects,
> > beside liteide for golang.
> 
> I had a boss once who insisted that all his staff learn "ed",
> because one day it might be the only editor available; he was
> right...

On a modern Linux system, ed isn't even installed ... 8-O

I was quite shocked when I first realized that I had to do
`apt-get install ed' to have it available ... on a Unix-like
system. But on the other hand, who of today's users is even
capable of exiting it?!


On my own systems I like to install Heirlomm ed, which I have
outfactored from the Heirloom tools package. If you want to
actually use it every now and then, Gunnar's ed is much more
usable than GNU ed ... which seems to be more a demonstration
object than actually a programmer's editor.


Anyways, I'm having a great pleasure reading those historic
spotlights on editors these days. :-)


meillo

From ricercar at lycos.com  Fri Jan 10 18:16:49 2020
From: ricercar at lycos.com (ricercar at lycos.com)
Date: Fri, 10 Jan 2020 08:16:49 +0000
Subject: [TUHS] screen editors
In-Reply-To: <bddcdc90-5388-36bd-c9a1-3f7833835d67@spamtrap.tnetconsulting.net>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
 <bbe88baca838c50fcae26183e389bd94@firemail.de>
 <bddcdc90-5388-36bd-c9a1-3f7833835d67@spamtrap.tnetconsulting.net>
Message-ID: <accadf04-fdf6-cea6-26b0-031313f9d52d@lycos.com>

On 1/9/20 5:01 AM, Grant Taylor via TUHS wrote:

> On 1/7/20 12:14 PM, Thomas Paulsen wrote:
>> I do ed/se occasionally for simple tasks
> Was that supposed to be "sed"?  Or is "se" something that I'm not
> familiar with?
>
I think he is referring to http://se-editor.org/, mentioned earlier in the
thread.

vks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/ba03fc07/attachment.html>

From ullbeking at andrewnesbit.org  Fri Jan 10 18:17:46 2020
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Fri, 10 Jan 2020 08:17:46 +0000
Subject: [TUHS] screen editors
In-Reply-To: <1ippPk-8PE-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
Message-ID: <c2480aae-cb54-c43b-0273-2abd5edae3e7@andrewnesbit.org>

On 10/01/2020 08:13, markus schnalke wrote:
> GNU ed [...] seems to be more a demonstration
> object than actually a programmer's editor.

Hi Markus, in what way is GNU ed a "demonstration object"?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From ullbeking at andrewnesbit.org  Fri Jan 10 22:26:24 2020
From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit)
Date: Fri, 10 Jan 2020 12:26:24 +0000
Subject: [TUHS] screen editors and beyond
In-Reply-To: <CAKzdPgybKz5j+98m8=39GhXxnX73iWLM56meH-qe+QKvvF208A@mail.gmail.com>
References: <1578606809.15476.for-standards-violators@oclsc.org>
 <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>
 <CAKzdPgybKz5j+98m8=39GhXxnX73iWLM56meH-qe+QKvvF208A@mail.gmail.com>
Message-ID: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org>

On 10/01/2020 01:52, Rob Pike wrote:
> I wrote xd for a reason.

What is xd?  Please could you send a link to it?  Thank you!!

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From vanattenmark at gmail.com  Fri Jan 10 23:15:43 2020
From: vanattenmark at gmail.com (Mark van Atten)
Date: Fri, 10 Jan 2020 14:15:43 +0100
Subject: [TUHS] screen editors and beyond
In-Reply-To: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org>
References: <1578606809.15476.for-standards-violators@oclsc.org>
 <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>
 <CAKzdPgybKz5j+98m8=39GhXxnX73iWLM56meH-qe+QKvvF208A@mail.gmail.com>
 <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org>
Message-ID: <CALAsyW09EmRr7Rcd=_L-pHFxcBNudbLkn04bwacxG8GFJhjYig@mail.gmail.com>

On Fri, 10 Jan 2020 at 13:27, Andrew Luke Nesbit
<ullbeking at andrewnesbit.org> wrote:
>
> On 10/01/2020 01:52, Rob Pike wrote:
> > I wrote xd for a reason.
>
> What is xd?  Please could you send a link to it?  Thank you!!

I'm obviously not Rob Pike, but here is a link to the man page of (the
plan9port incarnation of) xd:
https://9fans.github.io/plan9port/man/man1/xd.html

Mark.

From mike.ab3ap at gmail.com  Fri Jan 10 23:41:53 2020
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Fri, 10 Jan 2020 08:41:53 -0500
Subject: [TUHS] screen editors / machine load
In-Reply-To: <1ippPk-8PE-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
Message-ID: <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>

[2020-01-09 08:49] Dave Horsfall <dave at horsfall.org>
> > I had a boss once who insisted that all his staff learn "ed",
> > because one day it might be the only editor available; he was
> > right...
>

I first used Unix on a pdp-11/70 in 1981, first year at university.  My
professor stopped by the computing center to see how his students were
doing - super nice of him and a perk to pre-PC times! - and was showing me
something or other regarding Unix.  I had only used ed to that point and
seeing him fire up vi was practically sci-fi to me.  He showed me a few
commands and vowed me to secrecy for fear if all students started using it,
it would bring the 11/70 to its knees.  Were multiple vi sessions really
such a potential burden to the machine?  I wouldn't think so with the slow
nature of human i/o, yet there certainly were times when the pdp-11/70
crashed as project due dates loomed closer and closer!

Also, I very much enjoy this list.  As an EE I use Unix-like OSes as a tool
rather being a builder of the tool like many here.  So I don't have the
deep background to contribute to the collective history, but I'm on the
sidelines enjoying the show.  As a brief tie-in to the editor comparisons,
I do a lot of DSP work for RF systems these days.  Python makes it quick
and easy to try new math, but has a maddening requirement that indentation
be strictly tabs or strictly spaces.  Text window pasting into a tab
indented python file wreaks havoc.  vim yank/put between split windows
retains the type of white space and lets me use my vi muscle memory.

Happy 2020,
Mike Markowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/c560ba77/attachment.html>

From otto at drijf.net  Fri Jan 10 23:56:45 2020
From: otto at drijf.net (Otto Moerbeek)
Date: Fri, 10 Jan 2020 14:56:45 +0100
Subject: [TUHS] screen editors / machine load
In-Reply-To: <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
Message-ID: <20200110135645.GA47971@clue.drijf.net>

On Fri, Jan 10, 2020 at 08:41:53AM -0500, Mike Markowski wrote:

> [2020-01-09 08:49] Dave Horsfall <dave at horsfall.org>
> > > I had a boss once who insisted that all his staff learn "ed",
> > > because one day it might be the only editor available; he was
> > > right...
> >
> 
> I first used Unix on a pdp-11/70 in 1981, first year at university.  My
> professor stopped by the computing center to see how his students were
> doing - super nice of him and a perk to pre-PC times! - and was showing me
> something or other regarding Unix.  I had only used ed to that point and
> seeing him fire up vi was practically sci-fi to me.  He showed me a few
> commands and vowed me to secrecy for fear if all students started using it,
> it would bring the 11/70 to its knees.  Were multiple vi sessions really
> such a potential burden to the machine?  I wouldn't think so with the slow
> nature of human i/o, yet there certainly were times when the pdp-11/70
> crashed as project due dates loomed closer and closer!
> 
> Also, I very much enjoy this list.  As an EE I use Unix-like OSes as a tool
> rather being a builder of the tool like many here.  So I don't have the
> deep background to contribute to the collective history, but I'm on the
> sidelines enjoying the show.  As a brief tie-in to the editor comparisons,
> I do a lot of DSP work for RF systems these days.  Python makes it quick
> and easy to try new math, but has a maddening requirement that indentation
> be strictly tabs or strictly spaces.  Text window pasting into a tab
> indented python file wreaks havoc.  vim yank/put between split windows
> retains the type of white space and lets me use my vi muscle memory.
> 
> Happy 2020,
> Mike Markowski

In my first year at university (1984) we had a VAX-11/750 running
4.1BSD with too many students. We had to switch to ex once in a while
to get any editing done. I believe it was not only vi itself that was
causing the load, it was also running many terminals in raw mode that
killed performance.

	-Otto


From jnc at mercury.lcs.mit.edu  Sat Jan 11 00:27:40 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Jan 2020 09:27:40 -0500 (EST)
Subject: [TUHS] wump.c for v6
Message-ID: <20200110142740.8642618C09C@mercury.lcs.mit.edu>

    > From: Clem Cole <clemc at ccc.com>

    > So, unless anyone else can illuminate, I'm not sure where the first cpp
    > that some of us using v6 had originated.

I recall a prior extensive discussion about 'cpp'. I looked, and found it
(March 30, 2017) but it was a private discussion, not on TUHS (although you
were part of it :-). Here are clips of what I wrote (I don't want to re-post
what others wrote) from what I wrote, which tell most of the story:


There were a series of changes to C before V7 came out, resulting in the
so-called 'phototypsetter C compiler' (previously discussed on TUHS), and they
included the preprocessor. There's that series of short notes describing
changes to C (and the compiler), and they include mention of the preprocessor.

[Available here: http://gunkies.org/wiki/Typesetter_C for those who want to see
them.]

The MIT 'V6' Unix (which was, AFAICT, an augmented version of an early version
of PWB Unix) had that C compiler; and if you look at the PWB1 tree online, it
does have the C with 'cpp':

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c

I did a diff of that 'cpp' with the MIT one, and they are basically identical.

----

I went looking for the C manual in the V6 distro, to see if it mentioned the
pre-processor. And it does:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/c/c5

(Section 12, "Compiler control lines", about half way down.) So, I'm like,
'WTF? I just looked at cc.c and no mention of cpp!'

So I looked a little harder, and if you look at the cc.c in the distro (URL
above), you see this:

	insym(&defloc, "define");
	insym(&incloc, "include");
	insym(&eifloc, "endif");
	insym(&ifdloc, "ifdef");
	insym(&ifnloc, "ifndef");
	insym(&unxloc, "unix");

The pre-processor is integrated into 'cc' in the initial V6. So we do have a very
early version of it, after all...

----

So, 'cc' in V5 also included pre-processor support (just #define and #include,
though):

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c

Although we don't have the source to 'cc' to show it, V4 also appears to have
had it, per the man page:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/cc.1

"If the -p flag is used, only the macro prepass is run on all files whose name
ends in .c"; and the V4 system source:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys

also has .h files.

No sign of it in the man page for cc.1 in V3, though.


This all makes sense. .h files aren't any use with[out] #include, and without
#include, you have to have the structure definition, etc in multiple source
files. So #include would have gotten added very early on.

In V3, the system was apparently still in assembler, so no need.

-----


Also, there's an error in:

    https://ewe2.ninja/computers/cno/

when it says "V6 was a very different beast for programming to V7. No c
preprocessor. The practical upshot of this is no #includes." that's
clearly incorrect (see above). Also, if you look at Lions (which is pure
early V6), in the source section, all the .c files have #include's.

      Noel

From jnc at mercury.lcs.mit.edu  Sat Jan 11 00:35:39 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Jan 2020 09:35:39 -0500 (EST)
Subject: [TUHS] screen editors / machine load
Message-ID: <20200110143539.94B6218C09C@mercury.lcs.mit.edu>

    > From: Otto Moerbeek <otto at drijf.net>

    > I believe it was not only vi itself that was causing the load, it was
    > also running many terminals in raw mode that killed performance.

I'm not familiar with the tty driver in late versions of Unix like 4.1 (sic),
but I'm very familiar with the one in V6, and it's not the raw mode _itself_
that caused the load (the code paths in the kernel for cooked and raw aren't
that different), but rather the need to wake up and run a process on every
character that was the real load.

When Bernie Greenberg did EMACS for Multics, he had a similar issue. I recall
reading a document with an extensive discussion of how they dealt with this,
especially when using the system over the ARPANET. IIRC, normal printing
characters were echoed without waking up the process; remotely, when using
the network. If anyone's really interested in this, and can't find it themselves,
I can try looking for it.

	Noel


From mah at mhorton.net  Sat Jan 11 01:00:08 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Fri, 10 Jan 2020 07:00:08 -0800
Subject: [TUHS] screen editors / machine load
In-Reply-To: <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
Message-ID: <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net>

Yes, it was a real concern. Physical memory on the shared PDP-11 was 
limited, and if everyone had a separate copy of vi running the machine 
would swap itself silly.

This only mattered if everyone had their own separate copy of vi 
installed. The fix was to put vi in a single system directory, such as 
/usr/ucb or /exptools. The instruction part of its memory would be 
shared among all the users, resulting in much less swapping.

In the early days, people tended to have their own personal copy because 
the Berkeley tools did not come standard with UNIX, especially at Bell 
Labs. That was one of the main motivations for Exptools (the 
"experimental tools"), which were basically 2BSD's applications and some 
other tools like Warren Montgomery's emacs. Disk space and people's time 
spend installing were also good reasons.

     Mary Ann

On 1/10/20 5:41 AM, Mike Markowski wrote:
> seeing him fire up vi was practically sci-fi to me.  He showed me a 
> few commands and vowed me to secrecy for fear if all students started 
> using it, it would bring the 11/70 to its knees.  Were multiple vi 
> sessions really such a potential burden to the machine?  I wouldn't 
> think so with the slow nature of human i/o, yet there certainly were 
> times when the pdp-11/70 crashed as project due dates loomed closer 
> and closer!

From jnc at mercury.lcs.mit.edu  Sat Jan 11 01:35:26 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Jan 2020 10:35:26 -0500 (EST)
Subject: [TUHS] screen editors / machine load
Message-ID: <20200110153526.5D0CF18C09C@mercury.lcs.mit.edu>

    > When Bernie Greenberg did EMACS for Multics, he had a similar issue. I
    > recall reading a document with an extensive discussion of how they dealt
    > with this ... If anyone's really interested in this, and can't find it
    > themselves, I can try looking for it.

I got a request for this; a Web search turned up:

  https://www.multicians.org/mepap.html

which covers the points I mentioned (and more besides, such as why LISP was
chosen). I don't think this is the thing I remembered (which was, IIRC, an
informal note), but it does seem to be a later version of that.

	 Noel

From cym224 at gmail.com  Sat Jan 11 01:31:11 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Fri, 10 Jan 2020 10:31:11 -0500
Subject: [TUHS] screen editors
In-Reply-To: <1ippPk-8PE-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
Message-ID: <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>

On 01/10/20 03:13, markus schnalke wrote (in part):
> Hoi.
[...]
> Anyways, I'm having a great pleasure reading those historic
> spotlights on editors these days. :-)
In earlier days, my wife was given email by telnetting to an SGI system 
and using elm.  One day, I visited her office as she was composing a 
message.  Intrigued, I asked her what the editor was. She did not know 
and pointed to her cheat-sheet listing editor commands.  One was ^X^C to 
exit-and-send.  She is not a programmer and I was a bit surprised at 
their choice.

N.

>
>
> meillo


From clemc at ccc.com  Sat Jan 11 01:48:09 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 10 Jan 2020 10:48:09 -0500
Subject: [TUHS] screen editors / machine load
In-Reply-To: <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
 <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net>
Message-ID: <CAC20D2N_=tt4_eyEZ+N1BghditKKEh4LVOeuTi-Cr7rcnyAaug@mail.gmail.com>

On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton <mah at mhorton.net> wrote:

> Yes, it was a real concern. Physical memory on the shared PDP-11 was
> limited, and if everyone had a separate copy of vi running the machine
> would swap itself silly.
>
> This only mattered if everyone had their own separate copy of vi
> installed. The fix was to put vi in a single system directory, such as
> /usr/ucb or /exptools. The instruction part of its memory would be
> shared among all the users, resulting in much less swapping.
>
Actually it was much worse than that...

What Mary Ann points out was mostly true of your PDP-11 had DH11's
installed; which had deeper hardware buffering and 16 character DMA on
output.   But these were expensive from DEC and also took up a 'full system
unit' in the CPU for 16 lines.   Until Able (much later) released the
DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many
university sites did not use them; but used multiple DL-11/KL-11's instead.

If your system was configured with DL/KL11s or similar (CMU had it's own
called 'ASLIs' - a synchronous line interfaces) each character took one
interrupt for each either input or output.  Moreover, the UARTS that DEC
used which were made by Western Digital had 2 >>or less<< characters of
input buffering, so they could drop chars[1].  The ASLI's used a later chip
with a slightly better buffer IIRC but I admit I've forgotten the details
(Jim Tetter probably remembers them).

So if you had a single line, the interrupt load was huge on a PDP-11.  For
this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800
baud, not the full 9600.

DEC later released the DZ-11 which worked on units of 8 ports per board.
Unfortunately, it was not DMA and the buffering was still pretty shallow.
 Joy did a lot of work on 4.1BSD in the DZ driver to cut down the
interrupts because 9600 baud DZ lines could swamp a vax and when running
the BerkNet between systems (before UCB had ethernet), 9600 baud serial
lines were standard.


[1]  Two things
 A) The original WD UART chip had very limited buffering.   The timing was
such that as high rates it could not empty accept a second character
without the first being overwritten.  This was a long-standing issue for
many UARTs long in the 1990s.  The original chip NS built and IBM used on
the PC (the NS8250) was notorious for the same problem.  By the time of
Motorola's 6881, it had 8 characters of buffering IIRC.

B) As I understand the history, Gordon developed the original idea of the
UART at DEC for the PDP-1. But I'm not sure of the patent details. He does
not list the UART patent on his web site although he does mention inventing
it.   I have been under the impression CMU was somehow mixed up in the
patent and licensing of it, *i.e.* WD got the license from CMU to make them
not DEC; which was part of why we had the ASLI's.  Again, IIRC, we got the
UART chips from WD at cost and could make the ALSI's locally much cheaper
than DL-11s.  >>I think<< the story was that one of Gordon's student's
designed a chip, which WD fabbed and licensed.  Before that DEC had built
UARTs on boards from transistors and later logic gates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/68af0e45/attachment.html>

From clemc at ccc.com  Sat Jan 11 02:04:41 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 10 Jan 2020 11:04:41 -0500
Subject: [TUHS] screen editors
In-Reply-To: <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de> <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
Message-ID: <CAC20D2MzC9aeW2RSpS2_OHvMqASM67kDmcUta-2mf5-DmePgXg@mail.gmail.com>

On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224 at gmail.com> wrote:

> Intrigued, I asked her what the editor was. She did not know
> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
> exit-and-send.  She is not a programmer and I was a bit surprised at
> their choice.
>
Similar fun Unix/ITS emacs story.

In the mid/later 1970s, my least techie sister Cynthia was/is a concert
harpist with a degree from Oberlin's conservatory.  She can type extremely
fast as she has super manual dexterity.  But playing the harp is not
something that paid a great deal or offered her 'regular' gigs, so to make
the monthly rent she got a job working at MIT as Ron Rivest's admin .  She
typed all the RSA papers in emacs and tex on one of the MIT systems.  She
did not know any better, that's what they gave her/taught her.   When she
later would look for a job at other places and they would ask her, 'do you
know how to use a Wang System' and she would say: "No, I know emacs" [for
the younger set, longer before MS-Word, "Wang" was synonymous with "word
processor" and many/most commercial offices had a 'Wang unit" for the folks
doing the typing.].

 [As a side note when she found out the elevators were hacked and
controlled by the student's different computers, she stopped using them and
would take the stairs in Tech Sq].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/0934f10c/attachment.html>

From tytso at mit.edu  Sat Jan 11 01:58:22 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 10 Jan 2020 10:58:22 -0500
Subject: [TUHS] screen editors
In-Reply-To: <1ippPk-8PE-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
Message-ID: <20200110155822.GA298569@mit.edu>

On Fri, Jan 10, 2020 at 09:13:04AM +0100, markus schnalke wrote:
> 
> I was quite shocked when I first realized that I had to do
> `apt-get install ed' to have it available ... on a Unix-like
> system. But on the other hand, who of today's users is even
> capable of exiting it?!

For what it's worth, I regularly edit configuration files and shell
scripts using /bin/ed in environments where I can't use (due to
terminal limitations) or can't fit a more sophisticated editors.
These days this is typically in small appliance VM's.

I've also been known to do things like this in shell scripts[1]:

ed /etc/lighttpd/lighttpd.conf <<EOF
/^server.document-root/s/^/#/p
/^index-file.names/s/^/#/p
/^include_shell.*create-mime/s/^/#/p
w
q
EOF

[1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/gce-xfstests-bld.sh

And for years, I knew how to exit ed and emacs, but had trouble
exiting vi.  :-)

					- Ted
					




> 
> 
> On my own systems I like to install Heirlomm ed, which I have
> outfactored from the Heirloom tools package. If you want to
> actually use it every now and then, Gunnar's ed is much more
> usable than GNU ed ... which seems to be more a demonstration
> object than actually a programmer's editor.
> 
> 
> Anyways, I'm having a great pleasure reading those historic
> spotlights on editors these days. :-)
> 
> 
> meillo

From crossd at gmail.com  Sat Jan 11 03:10:47 2020
From: crossd at gmail.com (Dan Cross)
Date: Fri, 10 Jan 2020 12:10:47 -0500
Subject: [TUHS] screen editors
In-Reply-To: <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de> <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
Message-ID: <CAEoi9W4jG8w7CziNnj-6oRnA=7U5s9V1epoH5HsH2igpUd+zfQ@mail.gmail.com>

On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224 at gmail.com> wrote:

> In earlier days, my wife was given email by telnetting to an SGI system
> and using elm.  One day, I visited her office as she was composing a
> message.  Intrigued, I asked her what the editor was. She did not know
> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
> exit-and-send.  She is not a programmer and I was a bit surprised at
> their choice.
>

Hmm, I'm actually kind of not. Starting users off with a modal editor (that
starts in command mode, no less!) can be surprising for novices; with
emacs, at least you can start typing text and, well, see text.

I think that one of the smartest things Marc Crispin ever did was write
`pico` to go with `pine`. A simple editor targeted at the novice was really
useful for casual and/or new users, particularly as the Internet spread and
an account on a Unix system was the default introduction to email etc for
so many.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/4dcab1b9/attachment.html>

From usotsuki at buric.co  Sat Jan 11 03:18:09 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 10 Jan 2020 12:18:09 -0500 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <CAEoi9W4jG8w7CziNnj-6oRnA=7U5s9V1epoH5HsH2igpUd+zfQ@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de> <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
 <CAEoi9W4jG8w7CziNnj-6oRnA=7U5s9V1epoH5HsH2igpUd+zfQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.2001101214150.19787@frieza.hoshinet.org>

On Fri, 10 Jan 2020, Dan Cross wrote:

> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224 at gmail.com> wrote:
>
>> In earlier days, my wife was given email by telnetting to an SGI system
>> and using elm.  One day, I visited her office as she was composing a
>> message.  Intrigued, I asked her what the editor was. She did not know
>> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
>> exit-and-send.  She is not a programmer and I was a bit surprised at
>> their choice.
>>
>
> Hmm, I'm actually kind of not. Starting users off with a modal editor (that
> starts in command mode, no less!) can be surprising for novices; with
> emacs, at least you can start typing text and, well, see text.

This is one of the reasons I liked E when I first used it: it was modal, 
but it started in edit mode.  (Also you KNEW what mode you were in, which 
I understand isn't always the case with vi, although it usually is in the 
clones iirc?)

> I think that one of the smartest things Marc Crispin ever did was write
> `pico` to go with `pine`. A simple editor targeted at the novice was really
> useful for casual and/or new users, particularly as the Internet spread and
> an account on a Unix system was the default introduction to email etc for
> so many.

And I still use nano - which is a rewrite of pico.

pico Just Works(R)(TM)(C), and it's not enormous.  nano adds a few things 
I like, but the UI is the same.  Heck...I still use PINE and am sending 
this message from it ;)

-uso.

From jnc at mercury.lcs.mit.edu  Sat Jan 11 03:27:47 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Jan 2020 12:27:47 -0500 (EST)
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
Message-ID: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu>

    > From: Clem Cole

    > when she found out the elevators were hacked and controlled by the
    > student's different computers, she stopped using them and would take
    > the stairs 

It wasn't quite as major as this makes it sound! A couple of inconspicuous
wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
the Knight displays) into the elevator controller, and run onto the terminals
where the wires from the 'down' call buttons on the 8th and 9th floors went.

So it wasn't anything major, and there was really no need for her to take the
stair (especially 8 flights up :-).

The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
Knight TV keyboards; typing 'ESC E' called the elevator to the floor
that keyboard was on (there's a table, 'ELETAB', which gives the physical
floor for each keyboard).

The machine could also open the locked 9th floor door to the machine room
(with an 'ESC D'), and there some other less major things, e.g. print screen
hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
out of the 'keyboard multiplexor'); it may have been something the AI Lab
built from scratch.

      Noel

From lars at nocrew.org  Sat Jan 11 03:45:51 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 10 Jan 2020 17:45:51 +0000
Subject: [TUHS] Tech Sq elevator
In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Fri, 10 Jan 2020 12:27:47 -0500 (EST)")
References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu>
Message-ID: <7wd0brmchc.fsf@junk.nocrew.org>

Noel Chiappa writes:
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think)
> from Knight TV keyboards

(This isn't TUHS material, but I can't resist.  CC to COFF.)

There is also a Chaosnet service to call for the elevator or open the
door, so it can be used remotely.  The ITS program ESCE uses this
service.  I suppose there must have been something for the Lisp machines
too, maybe even a Super-Hyper-Cokebottle keyboard command.

From crossd at gmail.com  Sat Jan 11 05:07:53 2020
From: crossd at gmail.com (Dan Cross)
Date: Fri, 10 Jan 2020 14:07:53 -0500
Subject: [TUHS] Question about early C behavior.
Message-ID: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>

This question comes from a colleague, who works on compilers.

Given the definition `int x;` (without an initializer) in a source file the
corresponding object contains `x` in a "common" section. What this means is
that, at link time, if some object file explicitly allocates an 'x' (e.g.,
by specifying an initializer, so that 'x' appears in the data section for
that object file), use that; otherwise, allocate space for it at link time,
possibly in the BSS. If several source files contain such a declaration,
the linker allocates exactly one 'x' (or whatever identifier) as
appropriate. We've verified that this behavior was present as early as 6th
edition.

The question is, what is the origin of this concept and nomenclature?
FORTRAN, of course, has "common blocks": was that an inspiration for the
name? Where did the idea for the implicit behavior come from (FORTRAN
common blocks are explicit).

My colleague was particularly surprised that this seemed required: even at
this early stage, the `extern` keyword was present, so why bother with this
behavior? Why not, instead, make it a link-time error? Please note that if
two source files have initializers for these variables, then one gets a
multiple-definition link error. The 1988 ANSI standard made this an error
(or at least undefined behavior) but the functionality persists; GCC is
changing its default to prohibit it (my colleague works on clang).

Doug? Ken? Steve?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/af285640/attachment.html>

From paul.winalski at gmail.com  Sat Jan 11 06:24:30 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 10 Jan 2020 15:24:30 -0500
Subject: [TUHS] Question about early C behavior.
In-Reply-To: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
References: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
Message-ID: <CABH=_VRjeENbmsQNntrue8r3omewE43JJj38mM+x+cTNZTUE7A@mail.gmail.com>

On 1/10/20, Dan Cross <crossd at gmail.com> wrote:
>
> Given the definition `int x;` (without an initializer) in a source file the
> corresponding object contains `x` in a "common" section. What this means is
> that, at link time, if some object file explicitly allocates an 'x' (e.g.,
> by specifying an initializer, so that 'x' appears in the data section for
> that object file), use that; otherwise, allocate space for it at link time,
> possibly in the BSS. If several source files contain such a declaration,
> the linker allocates exactly one 'x' (or whatever identifier) as
> appropriate. We've verified that this behavior was present as early as 6th
> edition.

I think the situation you describe (common sections) is how this is
done in ELF.  a.out and COFF, as used on Unix, don't have common
sections.  Instead 'int x;' (without an initializer) becomes symbol
'x' in the object file's symbol table, with both the "external" and
"undefined" attribute bits set, and with the symbol's value being the
size of 'x' (typically 4 bites, in your example).  It is the non-zero
symbol value that distinguishes common symbols from ordinary external
references, e.g., 'extern int x;' (without an initializer).

At link time, common symbols are handled differently from ordinary
external references:

[1] When the linker is searching libraries, an ordinary external
reference to 'x' will cause the linker to load an object that contains
an external definition for 'x'.  Common symbols do not trigger the
loading of an object from a library.

[2] After the linker has processed all of the files and libraries on
the command line, if there is an external definition for 'x', all
common symbol references to 'x' are treated as ordinary external
references to 'x' and resolved against the definition.  If no external
definition is found, the linker allocates 'x' in BSS, using the
maximum allocation size seen in any common symbol references to 'x'.
All common symbol references and ordinary external references to 'x'
are resolved to the newly-allocated space.

> The question is, what is the origin of this concept and nomenclature?
> FORTRAN, of course, has "common blocks": was that an inspiration for the
> name? Where did the idea for the implicit behavior come from (FORTRAN
> common blocks are explicit).

Yes, the concept, nomenclature, and semantics come from FORTRAN, and
they were included in a.out and COFF to support FORTRAN and other
languages (such as PL/I) that have COMMON block-type semantics.  I
don't know why 'int x;' (without an initializer) in C was implemented
as a common symbol.  I suspect it was done to allow C and FORTRAN
object modules linked together in the same executable to share
external data.

-Paul W.

From aap at papnet.eu  Sat Jan 11 06:18:19 2020
From: aap at papnet.eu (Angelo Papenhoff)
Date: Fri, 10 Jan 2020 21:18:19 +0100
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu>
References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu>
Message-ID: <20200110201819.GA19832@indra.papnet.eu>

On 10/01/20, Noel Chiappa wrote:
>     > From: Clem Cole
> 
>     > when she found out the elevators were hacked and controlled by the
>     > student's different computers, she stopped using them and would take
>     > the stairs 
> 
> It wasn't quite as major as this makes it sound! A couple of inconspicuous
> wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
> the Knight displays) into the elevator controller, and run onto the terminals
> where the wires from the 'down' call buttons on the 8th and 9th floors went.
> 
> So it wasn't anything major, and there was really no need for her to take the
> stair (especially 8 flights up :-).
> 
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
> Knight TV keyboards; typing 'ESC E' called the elevator to the floor
> that keyboard was on (there's a table, 'ELETAB', which gives the physical
> floor for each keyboard).
> 
> The machine could also open the locked 9th floor door to the machine room
> (with an 'ESC D'), and there some other less major things, e.g. print screen
> hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
> out of the 'keyboard multiplexor'); it may have been something the AI Lab
> built from scratch.

For those not aware: we have the TV-11 running again under emulation and
it is once again the preferred way to use ITS.
Unfortunately I'm not quite sure how to emulate all the elevator
behaviour...any ideas? :D


aap

From robpike at gmail.com  Sat Jan 11 06:32:04 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 11 Jan 2020 07:32:04 +1100
Subject: [TUHS] screen editors and beyond
In-Reply-To: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org>
References: <1578606809.15476.for-standards-violators@oclsc.org>
 <CAC20D2M4XzJYoN6QTUct=67jSOqQk4=TSpZ5QzDC-eRJCvkYhg@mail.gmail.com>
 <CAKzdPgybKz5j+98m8=39GhXxnX73iWLM56meH-qe+QKvvF208A@mail.gmail.com>
 <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org>
Message-ID: <CAKzdPgwp_4e-JRjg2x55DDwia_pESLZnGFdVxkNSdTvVYA-K2w@mail.gmail.com>

http://man.cat-v.org/plan_9/1/xd

There's a copy of the source in plan9port.

-rob


On Fri, Jan 10, 2020 at 11:26 PM Andrew Luke Nesbit <
ullbeking at andrewnesbit.org> wrote:

> On 10/01/2020 01:52, Rob Pike wrote:
> > I wrote xd for a reason.
>
> What is xd?  Please could you send a link to it?  Thank you!!
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200111/bb4da7ce/attachment.html>

From dfawcus+lists-tuhs at employees.org  Sat Jan 11 06:55:25 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Fri, 10 Jan 2020 20:55:25 +0000
Subject: [TUHS] Question about early C behavior.
In-Reply-To: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
References: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
Message-ID: <20200110205525.GA1766@clarinet.employees.org>

On Fri, Jan 10, 2020 at 02:07:53PM -0500, Dan Cross wrote:
> 
> My colleague was particularly surprised that this seemed required: even at
> this early stage, the `extern` keyword was present, so why bother with this
> behavior? Why not, instead, make it a link-time error? Please note that if
> two source files have initializers for these variables, then one gets a
> multiple-definition link error. The 1988 ANSI standard made this an error
> (or at least undefined behavior) but the functionality persists; GCC is
> changing its default to prohibit it (my colleague works on clang).

This behaviour differed between platforms, unix using the common approach,
and some other platforms simplying making it a (non common) symbol in the bss.

Having learnt C in its pre-ANSI form on unix, I then ran in to this behaviour
on DOS C compilers.  None of which (that I came across) providing the 'common'
behaviour.

DF

From imp at bsdimp.com  Sat Jan 11 07:02:33 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 10 Jan 2020 14:02:33 -0700
Subject: [TUHS] Question about early C behavior.
In-Reply-To: <20200110205525.GA1766@clarinet.employees.org>
References: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
 <20200110205525.GA1766@clarinet.employees.org>
Message-ID: <CANCZdfo407L-Fwf7W1HVaPPekq5d-Yxr03zUqMrUEkoErwx42w@mail.gmail.com>

On Fri, Jan 10, 2020, 1:55 PM Derek Fawcus <dfawcus+lists-tuhs at employees.org>
wrote:

> On Fri, Jan 10, 2020 at 02:07:53PM -0500, Dan Cross wrote:
> >
> > My colleague was particularly surprised that this seemed required: even
> at
> > this early stage, the `extern` keyword was present, so why bother with
> this
> > behavior? Why not, instead, make it a link-time error? Please note that
> if
> > two source files have initializers for these variables, then one gets a
> > multiple-definition link error. The 1988 ANSI standard made this an error
> > (or at least undefined behavior) but the functionality persists; GCC is
> > changing its default to prohibit it (my colleague works on clang).
>
> This behaviour differed between platforms, unix using the common approach,
> and some other platforms simplying making it a (non common) symbol in the
> bss.
>
> Having learnt C in its pre-ANSI form on unix, I then ran in to this
> behaviour
> on DOS C compilers.  None of which (that I came across) providing the
> 'common'
> behaviour.
>

Gcc offered warnings for this behavior in the early 90s, iirc. I went
through a bunch of code in that time frame to remove the assumption...

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/fb11ba39/attachment.html>

From clemc at ccc.com  Sat Jan 11 07:05:02 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 10 Jan 2020 16:05:02 -0500
Subject: [TUHS] Question about early C behavior.
In-Reply-To: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
References: <CAEoi9W4pONAu4QRKnvQ79pRip5LkqQMq=rXgw4YB5bqYL3XNqQ@mail.gmail.com>
Message-ID: <CAC20D2M=9o+oMkuz6vFLDJE6WCAddaztGAd5wX7t3GXaHxVpMw@mail.gmail.com>

On Fri, Jan 10, 2020 at 2:09 PM Dan Cross <crossd at gmail.com> wrote:

> The 1988 ANSI standard made this an error (or at least undefined behavior)
> but the functionality persists; GCC is changing its default to prohibit it
> (my colleague works on clang).
>
Lovely - let's break code because we can.

To quote our late friend and colleague dmr:

“I can't recall any difficulty in making the C language definition
completely open - any discussion on the matter tended to mention languages
whose inventors tried to keep tight control, and consequent ill fate”
<https://www.inspiringquotes.us/quotes/TkCZ_JSNjCihu>

“When I read commentary about suggestions for where C should go, I often
think back and give thanks that it wasn't developed under the advice of a
worldwide crowd.” <https://www.inspiringquotes.us/quotes/eDQR_hqwtHAC9>

“C is peculiar in a lot of ways, but it, like many other successful things,
has a certain unity of approach that stems from development in a small
group” <https://www.inspiringquotes.us/quotes/zjSl_37Fc1onj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/4639666b/attachment.html>

From athornton at gmail.com  Sat Jan 11 08:18:17 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 10 Jan 2020 15:18:17 -0700
Subject: [TUHS] screen editors / machine load
In-Reply-To: <CAC20D2N_=tt4_eyEZ+N1BghditKKEh4LVOeuTi-Cr7rcnyAaug@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
 <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net>
 <CAC20D2N_=tt4_eyEZ+N1BghditKKEh4LVOeuTi-Cr7rcnyAaug@mail.gmail.com>
Message-ID: <CAP2nic2upndsPWaONuLOvRQbJs6ivF+W7jVs+XdiaGR1wEx4WQ@mail.gmail.com>

A) The original WD UART chip had very limited buffering.   The timing was
such that as high rates it could not empty accept a second character
without the first being overwritten.  This was a long-standing issue for
many UARTs long in the 1990s.  The original chip NS built and IBM used on
the PC (the NS8250) was notorious for the same problem.  By the time of
Motorola's 6881, it had 8 characters of buffering IIRC.

Great, now I'm having flashbacks to upgrading my 4-port serial card with
16450s and then 16550s in the early 90s.


On Fri, Jan 10, 2020 at 8:49 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton <mah at mhorton.net> wrote:
>
>> Yes, it was a real concern. Physical memory on the shared PDP-11 was
>> limited, and if everyone had a separate copy of vi running the machine
>> would swap itself silly.
>>
>> This only mattered if everyone had their own separate copy of vi
>> installed. The fix was to put vi in a single system directory, such as
>> /usr/ucb or /exptools. The instruction part of its memory would be
>> shared among all the users, resulting in much less swapping.
>>
> Actually it was much worse than that...
>
> What Mary Ann points out was mostly true of your PDP-11 had DH11's
> installed; which had deeper hardware buffering and 16 character DMA on
> output.   But these were expensive from DEC and also took up a 'full system
> unit' in the CPU for 16 lines.   Until Able (much later) released the
> DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many
> university sites did not use them; but used multiple DL-11/KL-11's instead.
>
> If your system was configured with DL/KL11s or similar (CMU had it's own
> called 'ASLIs' - a synchronous line interfaces) each character took one
> interrupt for each either input or output.  Moreover, the UARTS that DEC
> used which were made by Western Digital had 2 >>or less<< characters of
> input buffering, so they could drop chars[1].  The ASLI's used a later chip
> with a slightly better buffer IIRC but I admit I've forgotten the details
> (Jim Tetter probably remembers them).
>
> So if you had a single line, the interrupt load was huge on a PDP-11.  For
> this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800
> baud, not the full 9600.
>
> DEC later released the DZ-11 which worked on units of 8 ports per board.
> Unfortunately, it was not DMA and the buffering was still pretty shallow.
>  Joy did a lot of work on 4.1BSD in the DZ driver to cut down the
> interrupts because 9600 baud DZ lines could swamp a vax and when running
> the BerkNet between systems (before UCB had ethernet), 9600 baud serial
> lines were standard.
>
>
> [1]  Two things
>  A) The original WD UART chip had very limited buffering.   The timing was
> such that as high rates it could not empty accept a second character
> without the first being overwritten.  This was a long-standing issue for
> many UARTs long in the 1990s.  The original chip NS built and IBM used on
> the PC (the NS8250) was notorious for the same problem.  By the time of
> Motorola's 6881, it had 8 characters of buffering IIRC.
>
> B) As I understand the history, Gordon developed the original idea of the
> UART at DEC for the PDP-1. But I'm not sure of the patent details. He does
> not list the UART patent on his web site although he does mention inventing
> it.   I have been under the impression CMU was somehow mixed up in the
> patent and licensing of it, *i.e.* WD got the license from CMU to make
> them not DEC; which was part of why we had the ASLI's.  Again, IIRC, we got
> the UART chips from WD at cost and could make the ALSI's locally much
> cheaper than DL-11s.  >>I think<< the story was that one of Gordon's
> student's designed a chip, which WD fabbed and licensed.  Before that DEC
> had built UARTs on boards from transistors and later logic gates.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/10f972fa/attachment.html>

From rich.salz at gmail.com  Sat Jan 11 08:53:07 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Fri, 10 Jan 2020 17:53:07 -0500
Subject: [TUHS] Sun employee interviews
Message-ID: <CAFH29to=ZJ16mz53t-05xGhvXyYmRthTPfUo3+2qjqgk3VUTjA@mail.gmail.com>

Sarah Jeong is looking for Sun employees to interview for a potential book
about its rise and fall. Thread here

https://twitter.com/halvarflake/status/1215312568438480897?s=19
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/8e8295cd/attachment.html>

From cbbrowne at gmail.com  Sat Jan 11 10:30:30 2020
From: cbbrowne at gmail.com (Christopher Browne)
Date: Fri, 10 Jan 2020 19:30:30 -0500
Subject: [TUHS] screen editors / machine load
In-Reply-To: <CAP2nic2upndsPWaONuLOvRQbJs6ivF+W7jVs+XdiaGR1wEx4WQ@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <CANq1pfn5ENTZVvZfH5F=6TOWc82txnTP9oZ5kwk6JGUjq8J-ew@mail.gmail.com>
 <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net>
 <CAC20D2N_=tt4_eyEZ+N1BghditKKEh4LVOeuTi-Cr7rcnyAaug@mail.gmail.com>
 <CAP2nic2upndsPWaONuLOvRQbJs6ivF+W7jVs+XdiaGR1wEx4WQ@mail.gmail.com>
Message-ID: <CAFNqd5U_ep6-VRV=jM5BWCEmu7RZTVDonZQFNgmwqEdj2XkoRw@mail.gmail.com>

On Fri, 10 Jan 2020 at 17:19, Adam Thornton <athornton at gmail.com> wrote:

> A) The original WD UART chip had very limited buffering.   The timing was
> such that as high rates it could not empty accept a second character
> without the first being overwritten.  This was a long-standing issue for
> many UARTs long in the 1990s.  The original chip NS built and IBM used on
> the PC (the NS8250) was notorious for the same problem.  By the time of
> Motorola's 6881, it had 8 characters of buffering IIRC.
>
> Great, now I'm having flashbacks to upgrading my 4-port serial card with
> 16450s and then 16550s in the early 90s.
>

Yep, same sorts of memories here.  I recall the 16450 upgrade being a big
deal for Internet connectivity in that a PC lacking the extra bytes of
buffering in the UART would find that the 80386 was having clock cycles
eaten nearly completely by PPP connections.
It was amazing to realize how a few bytes of memory lurking in a crucial
system interface could affect performance in such dramatic ways.
Tagged command queueing on SCSI controllers had a slightly less dramatic
effect on I/O performance, but again, a few hundred bytes of memory in the
right spot could nevertheless have dramatic effects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200110/6500e5d1/attachment.html>

From meillo at marmaro.de  Sun Jan 12 05:58:53 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 11 Jan 2020 20:58:53 +0100
Subject: [TUHS] screen editors
In-Reply-To: <c2480aae-cb54-c43b-0273-2abd5edae3e7@andrewnesbit.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <c2480aae-cb54-c43b-0273-2abd5edae3e7@andrewnesbit.org>
Message-ID: <1iqMuL-1zK-00@marmaro.de>

Hoi.

[2020-01-10 08:17] U'll Be King of the Stars <ullbeking at andrewnesbit.org>
> On 10/01/2020 08:13, markus schnalke wrote:
> >
> > GNU ed [...] seems to be more a demonstration
> > object than actually a programmer's editor.
> 
> Hi Markus, in what way is GNU ed a "demonstration object"?

Thanks for questioning this statement! It seems as if I might have
mixed different memories up. A quick look at GNU ed showed nothing
to support my statement. Sorry for pretending stuff without fact
checking.


My look was at version 1.4, which is the newest one I could look
into. I'm pretty sure I examined GNU ed 1.6 back then, because
that version is in the Pkgfile of my system, but unfortunately I
am unable to find it anywhere. The GNU release mirrors lack all
version 1.5 through 1.10 -- why that? They must have been
released, at least 1.6, because that is used on my system.
Unfortunately I also was unable to access the Changelog of a
newer version to check for changes, because these are lzip
compressed (tar.lz) ... whatever that is, I cannot uncompress it
on my system. Furthermore I neither could find an online
browsable web repo view for checking out version 1.6 or at least
viewing the files within the browser. There's only a cvs repo
access (no cvs on my machine) and it talks about the web page
repo not the ed source repo. Not sure what to think of that.

That's not how things should be. Actually, I'm a bit depressed
now ...


meillo


P.S.
Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like
``vee-eye''), is that what you english speakers do? To me (a
native German speaker) it naturally was ``ed'' (like ``sam'').
As reference some Computerphile video is given, which is now
deleted. Is there a better source?

And what about the pronounciations of `ex' and `qed'?

What about `od'? (That I pronouce ``oh-dee''.)

https://en.wikipedia.org/wiki/Ed_(text_editor)

From dfawcus+lists-tuhs at employees.org  Sun Jan 12 06:54:50 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sat, 11 Jan 2020 20:54:50 +0000
Subject: [TUHS] screen editors
In-Reply-To: <1iqMuL-1zK-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <c2480aae-cb54-c43b-0273-2abd5edae3e7@andrewnesbit.org>
 <1iqMuL-1zK-00@marmaro.de>
Message-ID: <20200111205450.GA84232@clarinet.employees.org>

On Sat, Jan 11, 2020 at 08:58:53PM +0100, markus schnalke wrote:
> 
> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like
> ``vee-eye''), is that what you english speakers do? To me (a
> native German speaker) it naturally was ``ed'' (like ``sam'').

As a native english speaker...

'ed', as in the man's name. I pronounce 'vi' as you have it above,
but others at work pronounce it as 'vye' (as in 'vying'), so no
consistency there.

We also have local inconsistencies for how JIRA is pronounced,
so don't expect a canonical answer.

> And what about the pronounciations of `ex' and `qed'?

I can't say I've pronounced them before, but I think of
former as 'ee-x', I'd be inclined to pronounce the latter
as 'queue-ed'.  Since Q-E-D has its own meaning.

> What about `od'? (That I pronouce ``oh-dee''.)

agreed; otherwise confusing with 'odd'.

But who knows how the authors pronounced them.

DF

From henry.r.bent at gmail.com  Sun Jan 12 07:27:12 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 11 Jan 2020 16:27:12 -0500
Subject: [TUHS] screen editors
In-Reply-To: <1iqMuL-1zK-00@marmaro.de>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de>
 <c2480aae-cb54-c43b-0273-2abd5edae3e7@andrewnesbit.org>
 <1iqMuL-1zK-00@marmaro.de>
Message-ID: <CAEdTPBeoUpKWTe_COu_OKwPe8QamtyrV=E52z06xAbrqrpr31Q@mail.gmail.com>

On Sat, 11 Jan 2020 at 14:59, markus schnalke <meillo at marmaro.de> wrote:

> Hoi.
>
> [2020-01-10 08:17] U'll Be King of the Stars <ullbeking at andrewnesbit.org>
> > On 10/01/2020 08:13, markus schnalke wrote:
> > >
> > > GNU ed [...] seems to be more a demonstration
> > > object than actually a programmer's editor.
> >
> > Hi Markus, in what way is GNU ed a "demonstration object"?
>
> Thanks for questioning this statement! It seems as if I might have
> mixed different memories up. A quick look at GNU ed showed nothing
> to support my statement. Sorry for pretending stuff without fact
> checking.
>
>
> My look was at version 1.4, which is the newest one I could look
> into. I'm pretty sure I examined GNU ed 1.6 back then, because
> that version is in the Pkgfile of my system, but unfortunately I
> am unable to find it anywhere. The GNU release mirrors lack all
> version 1.5 through 1.10 -- why that? They must have been
> released, at least 1.6, because that is used on my system.
> Unfortunately I also was unable to access the Changelog of a
> newer version to check for changes, because these are lzip
> compressed (tar.lz) ... whatever that is, I cannot uncompress it
> on my system. Furthermore I neither could find an online
> browsable web repo view for checking out version 1.6 or at least
> viewing the files within the browser. There's only a cvs repo
> access (no cvs on my machine) and it talks about the web page
> repo not the ed source repo. Not sure what to think of that.
>
> That's not how things should be. Actually, I'm a bit depressed
> now ...
>

GNU ed appears to be written entirely by one person (as in, no changelog
entries by anyone else since 1994), who perhaps not coincidentally is also
the author of the lzip compression program.  As you noted, ed source is
distributed only as lzip-compressed tarballs, so you have to be able to
compile and run lzip to compile and run ed.  lzip is written in C++, so to
have access to GNU ed you need a C++ compiler.  Which is very strange, as
GNU ed is a very simple C program, much as one would expect.

The configure program is extremely basic, which is great - why have more
than you need? - but when it detected that my $(CC) was not gcc, it
hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to
the script.  A strange choice, but one that can easily be edited later in
the Makefile.  The basic C source compiled with no warnings whatsoever,
always a good sign.  At the linking stage I noticed that I needed a library
for some functions it wanted.  Okay, easy enough, just add a library to the
Makefile's LDFLAGS.  But the Makefile had this braindamage:

$(progname) : $(objs)
        $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs)

so on any platform that needs libraries linked after objects, it will fail.

At that point, I gave up.  This is clearly one person's pet project and has
"but it works on my Linux box!" written all over it.  That, coupled with
the fact that the GNU folks are willing to endorse something that is solely
distributed in what can only be described as an extremely obscure
compression format, was just too much for me to handle.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200111/f77d3aad/attachment.html>

From doug at cs.dartmouth.edu  Sun Jan 12 23:43:34 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 12 Jan 2020 08:43:34 -0500
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
Message-ID: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>

Mention of elevators at Tech Square reminds me of visiting there
to see the Lisp machine. I was struck by cultural differences.

At the time we were using Jerqs, where multiple windows ran
like multiple time-sharing sessions. To me that behavior was a
no-brainer. Surprisingly, Lisp-machine windows didn't work that
way; only the user-selected active window got processor time.

The biggest difference was emacs, which no one used at Bell
Labs. Emacs, of course was native to the Lisp machine and
provided a powerful and smoothly extensible environment. For
example, its reflective ability made it easy to display a
list of its commands. "Call elevator" stood out amng mundane
programmering actions like cut, paste and run.

After scrolling through the command list, I wondered how long
it was and asked to have it counted. Easy, I thought, just
pass it to a wc-like program. But "just pass it" and "wc-like"
were not givens as they are in Unix culture.  It took several
minutes for the gurus to do it--without leaving emacs, if I
remember right.

Doug

From imp at bsdimp.com  Mon Jan 13 02:56:48 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 12 Jan 2020 09:56:48 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
Message-ID: <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>

On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Mention of elevators at Tech Square reminds me of visiting there
> to see the Lisp machine. I was struck by cultural differences.
>
> At the time we were using Jerqs, where multiple windows ran
> like multiple time-sharing sessions. To me that behavior was a
> no-brainer. Surprisingly, Lisp-machine windows didn't work that
> way; only the user-selected active window got processor time.
>
> The biggest difference was emacs, which no one used at Bell
> Labs. Emacs, of course was native to the Lisp machine and
> provided a powerful and smoothly extensible environment. For
> example, its reflective ability made it easy to display a
> list of its commands. "Call elevator" stood out amng mundane
> programmering actions like cut, paste and run.
>
> After scrolling through the command list, I wondered how long
> it was and asked to have it counted. Easy, I thought, just
> pass it to a wc-like program. But "just pass it" and "wc-like"
> were not givens as they are in Unix culture.  It took several
> minutes for the gurus to do it--without leaving emacs, if I
> remember right.
>

It should have been something like  (list-length (command-list-fn)) but
I'll bet that ? was bound to a complicated function that just displayed the
results and didn't properly abstract out the UI (printing) from the data
collection (getting a list), which is what made it so hard. I've had so
many gnu emacs experiences like this over the years, but to the community's
credit, there's fewer and fewer as time goes by.

ObUnix: This shows the power of having the right abstractions and being
disciplined to code to those ideal abstractions any time there might be
reuse...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200112/a8e113db/attachment.html>

From meillo at marmaro.de  Mon Jan 13 03:21:14 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sun, 12 Jan 2020 18:21:14 +0100
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
Message-ID: <1iqgvK-2KJ-00@marmaro.de>

Hoi.

[2020-01-12 09:56] Warner Losh <imp at bsdimp.com>
>
> It should have been something like  (list-length (command-list-fn)) but I'll
> bet that ? was bound to a complicated function that just displayed the results
> and didn't properly abstract out the UI (printing) from the data collection
> (getting a list), which is what made it so hard. I've had so many gnu emacs
> experiences like this over the years, but to the community's credit, there's
> fewer and fewer as time goes by.
> 
> ObUnix: This shows the power of having the right abstractions and being
> disciplined to code to those ideal abstractions any time there might be
> reuse...

True words.

These concepts (what you call abstractions) is no optional geek
pleasure but the most important information for everyone using the
system or language. It's important to teach them, make them explicit,
deal with them, substract points in exams for correct solutions that
have bad style, keep the libraries and books on a high level, ...

This is one of the lesser regarded aspects of what Unix did really
well.


meillo

From kevin.bowling at kev009.com  Mon Jan 13 06:25:13 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 12 Jan 2020 13:25:13 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
Message-ID: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>

This is kind of illustrative of the '60s acid trip that perpetuates in
programming "Everything's a string maaaaan".  The output is seen as
truth because the representation is for some reason too hard to get at
or too hard to cascade through the system.

There's a total comedy of work going on in the unix way of a wc
pipeline versus calling a length function on a list.  Nonetheless, the
unix pipeline was and is often magnitude easier for a single user to
get at.  This kind of thing is amusing and endearing to me about our
profession in modern day.

Regards,
Kevin

On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>
>> Mention of elevators at Tech Square reminds me of visiting there
>> to see the Lisp machine. I was struck by cultural differences.
>>
>> At the time we were using Jerqs, where multiple windows ran
>> like multiple time-sharing sessions. To me that behavior was a
>> no-brainer. Surprisingly, Lisp-machine windows didn't work that
>> way; only the user-selected active window got processor time.
>>
>> The biggest difference was emacs, which no one used at Bell
>> Labs. Emacs, of course was native to the Lisp machine and
>> provided a powerful and smoothly extensible environment. For
>> example, its reflective ability made it easy to display a
>> list of its commands. "Call elevator" stood out amng mundane
>> programmering actions like cut, paste and run.
>>
>> After scrolling through the command list, I wondered how long
>> it was and asked to have it counted. Easy, I thought, just
>> pass it to a wc-like program. But "just pass it" and "wc-like"
>> were not givens as they are in Unix culture.  It took several
>> minutes for the gurus to do it--without leaving emacs, if I
>> remember right.
>
>
> It should have been something like  (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by.
>
> ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse...
>
> Warner

From lm at mcvoy.com  Mon Jan 13 06:32:41 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 12 Jan 2020 12:32:41 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
Message-ID: <20200112203241.GB9174@mcvoy.com>

I'll counter with Linux's /proc where everything is a string.  It's super
pleasant and I say that coming from SysV /proc where it was all a mess.

If performance is the metric, everything is a string is not so much.
If performance is not the high order bit, a /proc that you can read
with cat or grep is super pleasant.

On Sun, Jan 12, 2020 at 01:25:13PM -0700, Kevin Bowling wrote:
> This is kind of illustrative of the '60s acid trip that perpetuates in
> programming "Everything's a string maaaaan".  The output is seen as
> truth because the representation is for some reason too hard to get at
> or too hard to cascade through the system.
> 
> There's a total comedy of work going on in the unix way of a wc
> pipeline versus calling a length function on a list.  Nonetheless, the
> unix pipeline was and is often magnitude easier for a single user to
> get at.  This kind of thing is amusing and endearing to me about our
> profession in modern day.
> 
> Regards,
> Kevin
> 
> On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp at bsdimp.com> wrote:
> >
> >
> >
> > On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> >>
> >> Mention of elevators at Tech Square reminds me of visiting there
> >> to see the Lisp machine. I was struck by cultural differences.
> >>
> >> At the time we were using Jerqs, where multiple windows ran
> >> like multiple time-sharing sessions. To me that behavior was a
> >> no-brainer. Surprisingly, Lisp-machine windows didn't work that
> >> way; only the user-selected active window got processor time.
> >>
> >> The biggest difference was emacs, which no one used at Bell
> >> Labs. Emacs, of course was native to the Lisp machine and
> >> provided a powerful and smoothly extensible environment. For
> >> example, its reflective ability made it easy to display a
> >> list of its commands. "Call elevator" stood out amng mundane
> >> programmering actions like cut, paste and run.
> >>
> >> After scrolling through the command list, I wondered how long
> >> it was and asked to have it counted. Easy, I thought, just
> >> pass it to a wc-like program. But "just pass it" and "wc-like"
> >> were not givens as they are in Unix culture.  It took several
> >> minutes for the gurus to do it--without leaving emacs, if I
> >> remember right.
> >
> >
> > It should have been something like  (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by.
> >
> > ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse...
> >
> > Warner

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From jon at fourwinds.com  Mon Jan 13 06:34:26 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 12:34:26 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
Message-ID: <202001122034.00CKYQ39571239@darkstar.fourwinds.com>

Kevin Bowling writes:
> This is kind of illustrative of the '60s acid trip that perpetuates in
> programming "Everything's a string maaaaan".  The output is seen as
> truth because the representation is for some reason too hard to get at
> or too hard to cascade through the system.
>
> There's a total comedy of work going on in the unix way of a wc
> pipeline versus calling a length function on a list.  Nonetheless, the
> unix pipeline was and is often magnitude easier for a single user to
> get at.  This kind of thing is amusing and endearing to me about our
> profession in modern day.
>
> Regards,
> Kevin

Can you please elaborate?  I read your post, and while I can see that it
contains English words I can't make any sense out of what you said.

Thanks,
	Jon

From kevin.bowling at kev009.com  Mon Jan 13 06:40:53 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 12 Jan 2020 13:40:53 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
Message-ID: <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>

I honestly can't tell if this is genius level snark :) in case you're
sincere we generally go to great lengths to build up data types and
structures (in C lingo) when programming only to tear those useful
attributes off often at inopportune times.  Basically type
systems/type safety have been too expensive or too difficult to use
through history.

Think of sitting at an SQL prompt as a counterpoint.  You can pretty
easily get at the underlying representation and relationships of the
data and the output is just a side effect.  Not saying SQL is the
ultimate answer, just that most people have a bit of experience with
it and UNIX so can mentally compare the two for themselves and see the
pros and cons to preserving the underlying representations.

Regards,
Kevin

On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Kevin Bowling writes:
> > This is kind of illustrative of the '60s acid trip that perpetuates in
> > programming "Everything's a string maaaaan".  The output is seen as
> > truth because the representation is for some reason too hard to get at
> > or too hard to cascade through the system.
> >
> > There's a total comedy of work going on in the unix way of a wc
> > pipeline versus calling a length function on a list.  Nonetheless, the
> > unix pipeline was and is often magnitude easier for a single user to
> > get at.  This kind of thing is amusing and endearing to me about our
> > profession in modern day.
> >
> > Regards,
> > Kevin
>
> Can you please elaborate?  I read your post, and while I can see that it
> contains English words I can't make any sense out of what you said.
>
> Thanks,
>         Jon

From jon at fourwinds.com  Mon Jan 13 06:44:30 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 12:44:30 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
Message-ID: <202001122044.00CKiUNV573279@darkstar.fourwinds.com>

Kevin Bowling writes:
> I honestly can't tell if this is genius level snark :) in case you're
> sincere we generally go to great lengths to build up data types and
> structures (in C lingo) when programming only to tear those useful
> attributes off often at inopportune times.  Basically type
> systems/type safety have been too expensive or too difficult to use
> through history.
>
> Think of sitting at an SQL prompt as a counterpoint.  You can pretty
> easily get at the underlying representation and relationships of the
> data and the output is just a side effect.  Not saying SQL is the
> ultimate answer, just that most people have a bit of experience with
> it and UNIX so can mentally compare the two for themselves and see the
> pros and cons to preserving the underlying representations.
>
> Regards,
> Kevin
>
> On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > Kevin Bowling writes:
> > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > programming "Everything's a string maaaaan".  The output is seen as
> > > truth because the representation is for some reason too hard to get at
> > > or too hard to cascade through the system.
> > >
> > > There's a total comedy of work going on in the unix way of a wc
> > > pipeline versus calling a length function on a list.  Nonetheless, the
> > > unix pipeline was and is often magnitude easier for a single user to
> > > get at.  This kind of thing is amusing and endearing to me about our
> > > profession in modern day.
> > >
> > > Regards,
> > > Kevin
> >
> > Can you please elaborate?  I read your post, and while I can see that it
> > contains English words I can't make any sense out of what you said.
> >
> > Thanks,
> >         Jon

I wasn't being snarky.  You said

  "The output is seen as truth because the representation is for some
  reason too hard to get at or too hard to cascade through the system."

I honestly have no idea what that means.

Likewise, 

  "There's a total comedy of work going on in the unix way of
  a wc pipeline versus calling a length function on a list."

I just don't know what you mean.

Jon

From kevin.bowling at kev009.com  Mon Jan 13 07:03:39 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 12 Jan 2020 14:03:39 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
Message-ID: <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>

On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Kevin Bowling writes:
> > I honestly can't tell if this is genius level snark :) in case you're
> > sincere we generally go to great lengths to build up data types and
> > structures (in C lingo) when programming only to tear those useful
> > attributes off often at inopportune times.  Basically type
> > systems/type safety have been too expensive or too difficult to use
> > through history.
> >
> > Think of sitting at an SQL prompt as a counterpoint.  You can pretty
> > easily get at the underlying representation and relationships of the
> > data and the output is just a side effect.  Not saying SQL is the
> > ultimate answer, just that most people have a bit of experience with
> > it and UNIX so can mentally compare the two for themselves and see the
> > pros and cons to preserving the underlying representations.
> >
> > Regards,
> > Kevin
> >
> > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon at fourwinds.com> wrote:
> > >
> > > Kevin Bowling writes:
> > > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > > programming "Everything's a string maaaaan".  The output is seen as
> > > > truth because the representation is for some reason too hard to get at
> > > > or too hard to cascade through the system.
> > > >
> > > > There's a total comedy of work going on in the unix way of a wc
> > > > pipeline versus calling a length function on a list.  Nonetheless, the
> > > > unix pipeline was and is often magnitude easier for a single user to
> > > > get at.  This kind of thing is amusing and endearing to me about our
> > > > profession in modern day.
> > > >
> > > > Regards,
> > > > Kevin
> > >
> > > Can you please elaborate?  I read your post, and while I can see that it
> > > contains English words I can't make any sense out of what you said.
> > >
> > > Thanks,
> > >         Jon
>
> I wasn't being snarky.  You said
>
>   "The output is seen as truth because the representation is for some
>   reason too hard to get at or too hard to cascade through the system."
>
> I honestly have no idea what that means.

If the SQL prompt example did not clarify you are welcome to go one on
one if this is something you think is curious to you, I think I've
explained the point I was making adequately for a general audience.

>
> Likewise,
>
>   "There's a total comedy of work going on in the unix way of
>   a wc pipeline versus calling a length function on a list."
>
> I just don't know what you mean.
>

Reason through what happens in a shell pipeline, the more detail the
better.  A quick nudge is fork/exec, what happens in the kernel, what
happens in page tables, what happens at the buffered output, tty layer
etc.  Very few people actually understand all these steps even at a
general level in modern systems.

If you had a grocery list on a piece of paper would you
a) count the lines or read it directly off the last line number on the
paper if it is numbered

b) copy each character letter by letter to a new piece of equipment
(say, a word processor), until you encounter a special character that
happens to be represented as a space on the screen, increment a
counter, repeat until you reach another special character, output the
result and then destroy and throw away both the list and the word
processor equipment.

This kind of thing doesn't really matter in the small or at all for
performance because computers are fast.  But most programming bugs in
the large eventually boil down to some kind of misunderstanding where
the representation was lost and recast in a way that does not make
sense.

Regards,
Kevin

From jon at fourwinds.com  Mon Jan 13 07:37:21 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 13:37:21 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
Message-ID: <202001122137.00CLbMrw582813@darkstar.fourwinds.com>

Kevin Bowling writes:
> On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > Kevin Bowling writes:
> > > I honestly can't tell if this is genius level snark :) in case you're
> > > sincere we generally go to great lengths to build up data types and
> > > structures (in C lingo) when programming only to tear those useful
> > > attributes off often at inopportune times.  Basically type
> > > systems/type safety have been too expensive or too difficult to use
> > > through history.
> > >
> > > Think of sitting at an SQL prompt as a counterpoint.  You can pretty
> > > easily get at the underlying representation and relationships of the
> > > data and the output is just a side effect.  Not saying SQL is the
> > > ultimate answer, just that most people have a bit of experience with
> > > it and UNIX so can mentally compare the two for themselves and see the
> > > pros and cons to preserving the underlying representations.
> > >
> > > Regards,
> > > Kevin
> > >
> > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon at fourwinds.com> wrote:
> > > >
> > > > Kevin Bowling writes:
> > > > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > > > programming "Everything's a string maaaaan".  The output is seen as
> > > > > truth because the representation is for some reason too hard to get at
> > > > > or too hard to cascade through the system.
> > > > >
> > > > > There's a total comedy of work going on in the unix way of a wc
> > > > > pipeline versus calling a length function on a list.  Nonetheless, the
> > > > > unix pipeline was and is often magnitude easier for a single user to
> > > > > get at.  This kind of thing is amusing and endearing to me about our
> > > > > profession in modern day.
> > > > >
> > > > > Regards,
> > > > > Kevin
> > > >
> > > > Can you please elaborate?  I read your post, and while I can see that it
> > > > contains English words I can't make any sense out of what you said.
> > > >
> > > > Thanks,
> > > >         Jon
> >
> > I wasn't being snarky.  You said
> >
> >   "The output is seen as truth because the representation is for some
> >   reason too hard to get at or too hard to cascade through the system."
> >
> > I honestly have no idea what that means.
>
> If the SQL prompt example did not clarify you are welcome to go one on
> one if this is something you think is curious to you, I think I've
> explained the point I was making adequately for a general audience.
>
> >
> > Likewise,
> >
> >   "There's a total comedy of work going on in the unix way of
> >   a wc pipeline versus calling a length function on a list."
> >
> > I just don't know what you mean.
> >
>
> Reason through what happens in a shell pipeline, the more detail the
> better.  A quick nudge is fork/exec, what happens in the kernel, what
> happens in page tables, what happens at the buffered output, tty layer
> etc.  Very few people actually understand all these steps even at a
> general level in modern systems.
>
> If you had a grocery list on a piece of paper would you
> a) count the lines or read it directly off the last line number on the
> paper if it is numbered
>
> b) copy each character letter by letter to a new piece of equipment
> (say, a word processor), until you encounter a special character that
> happens to be represented as a space on the screen, increment a
> counter, repeat until you reach another special character, output the
> result and then destroy and throw away both the list and the word
> processor equipment.
>
> This kind of thing doesn't really matter in the small or at all for
> performance because computers are fast.  But most programming bugs in
> the large eventually boil down to some kind of misunderstanding where
> the representation was lost and recast in a way that does not make
> sense.
>
> Regards,
> Kevin

OK, I have trouble correlating this with your original post but I think
that I understand it well enough to comment.

I agree that it is a problem that very few people understand what's going on
inside anything today from a toaster to a computer.  On the computer end of
things this concerns me a lot and improving the quality of education in this
area is one of my main late-in-life missions.  I'm under the illusion that
I've helped some based on comments that I've received from people who have
tracked me down and let me know how much the information in my book helped them.

On to your example...

If I had a grocery list on a piece of paper I would count the lines because I
don't number my grocery lists.  I'm going to guess that few people do.  So, I
would count the lines in my head and remember the result.  This is pretty much
equivalent to what happens when something is piped into wc.

I don't see much difference between a and b in your example.  That's because
when I count up the number of lines in the list, I am making a temporary copy
of the list in my head and then forgetting what was on the list (which may
account for the late night trip to the grocery store a couple of days ago).

So I think that the point that you're trying to make, correct me if I'm wrong,
is that if lists just knew how long they were you could just ask and that it
would be more efficient.

While that may be true, it sort of assume that this is something so common that
the extra overhead for line counting should be part of every list.  And it doesn't
address the issue that while maybe you want a line count I may want a character
count or a count of all lines that begin with the letter A.  Limiting this example
to just line numbers ignores the fact that different people might want different
information that can't all be predicted in advance and built into every program.

It also seems to me that the root problem here is that the data in the original
example was in an emacs-specific format instead of the default UNIX text file
format.

The beauty of UNIX is that with a common file format one can create tools that
process data in different ways that then operate on all data.  Yes, it's not as
efficient as creating a custom tool for a particular purpose, but is much better
for casual use.  One can always create a special purpose tool if a particular
use becomes so prevalent that the extra efficiency is worthwhile.  If you're not
familiar with it, find a copy of the Communications of the ACM issue where Knuth
presented a clever search algorithm (if I remember correctly) and McIlroy did a
critique.  One of the things that Doug pointed out what that while Don's code was
more efficient, by creating a new pile of special-purpose code he introduced bugs.

Many people have claimed, incorrectly in my opinion, that this model fails in the
modern era because it only works on text data.  They change the subject when I
point out that ImageMagick works on binary data.  And, there are now stream
processing utilities for JSON data and such that show that the UNIX model still
works IF you understand it and know how to use it.

I don't agree with your closing comment about "most programming bugs".  Do you
have any data to support this or is it just an opinion?  My opinion is that most
programming bugs today result from total incompetence as one can prety much get
a computer science degree today without every learning that programs run on
computers or what a computer is.  That's something I'm trying to change, but it's
probably a lost cause.  A long topic, and not necessarily appropriate for this list.

Jon

From bakul at bitblocks.com  Mon Jan 13 07:41:45 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 12 Jan 2020 13:41:45 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: Your message of "Sun, 12 Jan 2020 12:44:30 -0800."
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
Message-ID: <20200112214152.9824C156E42D@mail.bitblocks.com>

On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon at fourwinds.com> wrote:
>
> I wasn't being snarky.  You said
>
>   "The output is seen as truth because the representation is for some
>   reason too hard to get at or too hard to cascade through the system."
>
> I honestly have no idea what that means.
>
> Likewise, 
>
>   "There's a total comedy of work going on in the unix way of
>   a wc pipeline versus calling a length function on a list."
>
> I just don't know what you mean.

May be this is not what Kevin meant but the way I interpreted
his message: smushing everything down to strings for output as
in unix pipelines loses any underlying structure which then
may have to be rediscovered by the next program in the
pipeline by parsing. This is slower, indirect and errorprone.
If one can communicate a structured representation of data between
components that would be better.

From jon at fourwinds.com  Mon Jan 13 07:47:44 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 13:47:44 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <20200112214152.9824C156E42D@mail.bitblocks.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <20200112214152.9824C156E42D@mail.bitblocks.com>
Message-ID: <202001122147.00CLligX584670@darkstar.fourwinds.com>

Bakul Shah writes:
> On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > I wasn't being snarky.  You said
> >
> >   "The output is seen as truth because the representation is for some
> >   reason too hard to get at or too hard to cascade through the system."
> >
> > I honestly have no idea what that means.
> >
> > Likewise, 
> >
> >   "There's a total comedy of work going on in the unix way of
> >   a wc pipeline versus calling a length function on a list."
> >
> > I just don't know what you mean.
>
> May be this is not what Kevin meant but the way I interpreted
> his message: smushing everything down to strings for output as
> in unix pipelines loses any underlying structure which then
> may have to be rediscovered by the next program in the
> pipeline by parsing. This is slower, indirect and errorprone.
> If one can communicate a structured representation of data between
> components that would be better.

Ah.  So lines IS the structure that a lot of people want.  As I just
said in a post, the JSON tools are a good example of communicating
structured data although I would have done them differently.

Jon

From doug at cs.dartmouth.edu  Mon Jan 13 08:25:38 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 12 Jan 2020 17:25:38 -0500
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
Message-ID: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>

>> After scrolling through the command list, I wondered how
>> long it was and asked to have it counted. Easy, I thought,
>> just pass it to a wc-like program. But "just pass it" and
>> "wc-like" were not givens as they are in Unix culture.
>> It took several minutes for the gurus to do it--without
>> leaving emacs, if I remember right.

> This is kind of illustrative of the '60s acid trip that
> perpetuates in programming "Everything's a string maaaaan".
> The output is seen as truth because the representation is
> for some reason too hard to get at or too hard to cascade
> through the system.

How did strings get into the discussion? Warner showed how
emacs could be expected to do the job--and more efficiently
than the Unix way, at that: (list-length (command-list-fn)).
The surprise was that this wasn't readily available.

Back then, in fact, you couldn't ask sh for its command
list. help|wc couldn't be done because help wasn't there.

Emacs had a different problem. It had a universal internal
interface--lists rather than strings--yet did not have
a way to cause this particular list to "cascade through
the system". (print(command-list-fn)) was provided, while
(command-list-fn) was hidden.

Doug

From kevin.bowling at kev009.com  Mon Jan 13 08:40:15 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 12 Jan 2020 15:40:15 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors)
In-Reply-To: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>

On Sun, Jan 12, 2020 at 3:26 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> >> After scrolling through the command list, I wondered how
> >> long it was and asked to have it counted. Easy, I thought,
> >> just pass it to a wc-like program. But "just pass it" and
> >> "wc-like" were not givens as they are in Unix culture.
> >> It took several minutes for the gurus to do it--without
> >> leaving emacs, if I remember right.
>
> > This is kind of illustrative of the '60s acid trip that
> > perpetuates in programming "Everything's a string maaaaan".
> > The output is seen as truth because the representation is
> > for some reason too hard to get at or too hard to cascade
> > through the system.
>
> How did strings get into the discussion? Warner showed how
> emacs could be expected to do the job--and more efficiently
> than the Unix way, at that: (list-length (command-list-fn)).
> The surprise was that this wasn't readily available.

Bakul provided an explanation for the pipeline, the funny cue to me
that I interpreted from Warner's message is just that emacs had the
ability to do it in a coherent way but did not and ISTM that the way
you make a mess of that is by losing the intent of the representation.
I am regularly surprised by how surprising type systems are to
computing professionals.  The language and environment may help or
dissuade you from doing that, wasn't really relevant to my original
point.

Larry tells me the message is somehow inflammatory, it wasn't intended
that way I was just trying to make light of the situation and provide
people a launch pad to think for themselves about some fundamentals
because it's worthwhile to do so occasionally.

> Back then, in fact, you couldn't ask sh for its command
> list. help|wc couldn't be done because help wasn't there.
>
> Emacs had a different problem. It had a universal internal
> interface--lists rather than strings--yet did not have
> a way to cause this particular list to "cascade through
> the system". (print(command-list-fn)) was provided, while
> (command-list-fn) was hidden.

The only response I can come up with to these two points eventually
boils down to a philosophical riddle:  does the work matter or does
how the work is done matter?  Both, the situation dictates.  I execute
innumerable shell pipelines per day and perhaps craft a dozen
ephemerals ones.

Regards,
Kevin

From jon at fourwinds.com  Mon Jan 13 09:40:40 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 15:40:40 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
Message-ID: <202001122340.00CNeef0604557@darkstar.fourwinds.com>

Kevin Bowling writes:
>
> I am regularly surprised by how surprising type systems are to
> computing professionals.

I am currently astonished at this.  Unfortunately, I need to make a hopefully
minor change to the linux kernel to support something that I want to do in my
current project.  But, this is my first time looking at the internals which is
way different that my recollection of UNIX kernels.  It's being enough of an
adventure that I'm writing up a travelogue of my journey through the code.
While I swore that I was done writing books this is sure looking like another
one :-)

So I came across this piece of what I consider to be bad programming that's
all over the place...

One of my programming style rules is to program in the language in which you're
programming.  The canonical example of not doing this is the Bourne shell which
was originally written using macros to redefine C to look like Algol68.

Linux contains several sets of list_for_each_entry() macros that are essentially
obfuscated for loops that generate inefficient code.  To make things worse, the
way that they're implemented is by embedding list_head structures into other
structures.

In the diagram below, the labels above boxes are structure names.  Names inside
of boxes are structure member names.  super_blocks, s_list, s_mounts, and
mnt_instance are all list_head structures.  (Trick question, how many lines are
in this diagram :-) )

+-----------------------------------------+
|                     super_block         |
|  +--------------+   +----------+        |
+->| super_blocks |<->|  s_list  |<- ... -+
   +--------------+   +----------+
                      |          |        mount              mount
                      |   ...    |   +--------------+   +--------------+
                      |          |   |      ...     |   |      ...     |
                      +----------+   +--------------+   +--------------+
                   +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+
                   |  +----------+   +--------------+   +--------------+        |
                   |                 |      ...     |   |      ...     |        |
                   |                 +--------------+   +--------------+        |
                   +------------------------------------------------------------+

The bizarre thing to me is that the list_head structures point to other list_head
structures that are embedded in other structures.  When one needs to access a
non list-head member of the structure one has to pass both the structure type and
the list_head member name to a macro that figures out how to subtract the offset
of the list_head member of the structure from the address of that list_head to
get the address of the structure, and then casts that as the structure type so
that members can be accessed.

The reason why I think that this is bad is because one can pass anything into that
macro; you just have to know what type of structures make up the list which is not
at all obvious as:

        struct  foo     {
                int                     bar;
                struct  list_head       name;
        };

gives no information about the list, unlike this:

        struct  foo     {
                int                     bar;
                struct  foo             *next;
        };

It completely bypasses the compiler type-checking.  In my opinion, very error prone.
Not to mention completely opaque to someone reading the code.  Without even the
consideration of decent comments, for example:

        struct list_head        s_list;         /* Keep this first */
        struct list_head        s_mounts;       /* list of mounts; _not_ for fs use */
        struct list_head        s_inodes_wb;    /* writeback inodes */

say nothing about what type of structures are in the lists.

In addition to generating less-efficient code than a for loop would and avoiding
type-checking, this approach seems to be used without much thought in the kernel
where memory is at a premium.  Many of these are used to implement circular
double-linked lists where neither the circularity nor the doubly-linking are
needed or used.

As an aside, one has to descend through 8 levels of macros calling macros and
six extra header files just to track down what this stuff does and how it works.

So I just don't get this at all.  I have no idea why someone would code this
way in C unless they just wanted to foist a construct from another language
that they preferred.  Somehow I expected better in the kernel.

Like usual, I could be completely off-base here and if I am, please correct me.

Jon

From lm at mcvoy.com  Mon Jan 13 09:50:51 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 12 Jan 2020 15:50:51 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001122340.00CNeef0604557@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
Message-ID: <20200112235051.GG9174@mcvoy.com>

On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> Linux contains several sets of list_for_each_entry() macros that are essentially
> obfuscated for loops that generate inefficient code.  

Very common idiom in any real system.  BitKeeper has them as well, they are
used everywhere.  They are too useful to not use.  The BitKeeper ones give
you most of Perl's list capabilities.

From jon at fourwinds.com  Mon Jan 13 10:01:02 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 16:01:02 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <20200112235051.GG9174@mcvoy.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <20200112235051.GG9174@mcvoy.com>
Message-ID: <202001130001.00D012bC608441@darkstar.fourwinds.com>

Larry McVoy writes:
> On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > Linux contains several sets of list_for_each_entry() macros that are essentially
> > obfuscated for loops that generate inefficient code.  
>
> Very common idiom in any real system.  BitKeeper has them as well, they are
> used everywhere.  They are too useful to not use.  The BitKeeper ones give
> you most of Perl's list capabilities.

I don't see it.  In the cases that I've seen so far in linux the only uses are
inserting, deleting, and traversing lists.  My opinion that anyone who can't
write
	for (p = list; p != NULL; p = p->next)

shouldn't be programming, much less in the kernel.  To me, type-checking and
code clarity are vastly more important.  If I want to program in Perl, I do
so.  When I program in C that's what I do.

I do want to be clear that I'm coming at this from a code maintenance angle.
Code that I write for my personal use looks way different than what I write
professionally.  I'm willing to put in more work up front to make sure that
other people can easily understand my code because I don't want to be stuck
maintaining stuff.  And I recognize that unless one is coding a web page with
an expected lifespan of 30 seconds the cost of maintenance dwarfs the cost of
development.

Jon

From lm at mcvoy.com  Mon Jan 13 10:22:19 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 12 Jan 2020 16:22:19 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001130001.00D012bC608441@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <20200112235051.GG9174@mcvoy.com>
 <202001130001.00D012bC608441@darkstar.fourwinds.com>
Message-ID: <20200113002219.GJ9174@mcvoy.com>

On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > > Linux contains several sets of list_for_each_entry() macros that are essentially
> > > obfuscated for loops that generate inefficient code.  
> >
> > Very common idiom in any real system.  BitKeeper has them as well, they are
> > used everywhere.  They are too useful to not use.  The BitKeeper ones give
> > you most of Perl's list capabilities.
> 
> I don't see it.  In the cases that I've seen so far in linux the only uses are
> inserting, deleting, and traversing lists.  My opinion that anyone who can't
> write
> 	for (p = list; p != NULL; p = p->next)
> 
> shouldn't be programming, much less in the kernel.  To me, type-checking and
> code clarity are vastly more important.  If I want to program in Perl, I do
> so.  When I program in C that's what I do.
> 
> I do want to be clear that I'm coming at this from a code maintenance angle.

I'd argue that the code we wrote for BitKeeper would hold up as some
of the most professionally written code ever.  Every commit was peer
reviewed by at least 2 other people, code that add/changed/deleted user
interfaces had to have docs and tests.  The philosophy is very much in
line with code maintenance, I vetoed stuff that was clever, my mantra was
"write once, read many so optimize for read".

Some dude on twitter found our code when we open sourced it and tweeted
something like "Wow, I've just spent the afternoon reading some of the
best written C code I've ever seen.  I didn't know C could be that nice".
So it's not just my opinion, I don't know that dude.

The list code that we have is super pleasant to use and has been
in production use for over 2 decades.  And we maintained it easily,
our 24x7 *average* responsive time on a bug report was 24 minutes.
The only reason it was that high was because we had to sleep (we were
spread out from East to West coast).  During working hours, response time
was almost always under 10 minutes, usually 2-3 minutes.  By "response",
I don't mean some automated nonsense that says "We value your input,
this is to let you know your report has been entered into our system".
I mean an engineer looked at the problem, figured out what was causing the
problem by looking at our source, about 90% of the time we knew what the
fix was, and we sent an update to the bug report with that information.

The list structure was auto resizing, it knew both how much was allocated
and how much was used in the first word of the list (we resized only in
powers of 2 so we could store size in log2 bits, used the rest of the
bits for the length), you could have a list in as short as two words 
and it scaled really well to millions of entries.  

It was, and is, super useful.  Wayne is back at Intel and he's teasing
it out of our libc to use there.

So you may not like it but that's you.  It has worked well in an extremely
professional environment.  Well coding professional, personalities might
have been a bit wonky :)

From jon at fourwinds.com  Mon Jan 13 10:31:10 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 16:31:10 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <20200113002219.GJ9174@mcvoy.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <20200112235051.GG9174@mcvoy.com>
 <202001130001.00D012bC608441@darkstar.fourwinds.com>
 <20200113002219.GJ9174@mcvoy.com>
Message-ID: <202001130031.00D0VAuW613942@darkstar.fourwinds.com>

Larry McVoy writes:
> On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
> > Larry McVoy writes:
> > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > > > Linux contains several sets of list_for_each_entry() macros that are essentially
> > > > obfuscated for loops that generate inefficient code.  
> > >
> > > Very common idiom in any real system.  BitKeeper has them as well, they are
> > > used everywhere.  They are too useful to not use.  The BitKeeper ones give
> > > you most of Perl's list capabilities.
> > 
> > I don't see it.  In the cases that I've seen so far in linux the only uses are
> > inserting, deleting, and traversing lists.  My opinion that anyone who can't
> > write
> > 	for (p = list; p != NULL; p = p->next)
> > 
> > shouldn't be programming, much less in the kernel.  To me, type-checking and
> > code clarity are vastly more important.  If I want to program in Perl, I do
> > so.  When I program in C that's what I do.
> > 
> > I do want to be clear that I'm coming at this from a code maintenance angle.
>
> I'd argue that the code we wrote for BitKeeper would hold up as some
> of the most professionally written code ever.  Every commit was peer
> reviewed by at least 2 other people, code that add/changed/deleted user
> interfaces had to have docs and tests.  The philosophy is very much in
> line with code maintenance, I vetoed stuff that was clever, my mantra was
> "write once, read many so optimize for read".
>
> Some dude on twitter found our code when we open sourced it and tweeted
> something like "Wow, I've just spent the afternoon reading some of the
> best written C code I've ever seen.  I didn't know C could be that nice".
> So it's not just my opinion, I don't know that dude.
>
> The list code that we have is super pleasant to use and has been
> in production use for over 2 decades.  And we maintained it easily,
> our 24x7 *average* responsive time on a bug report was 24 minutes.
> The only reason it was that high was because we had to sleep (we were
> spread out from East to West coast).  During working hours, response time
> was almost always under 10 minutes, usually 2-3 minutes.  By "response",
> I don't mean some automated nonsense that says "We value your input,
> this is to let you know your report has been entered into our system".
> I mean an engineer looked at the problem, figured out what was causing the
> problem by looking at our source, about 90% of the time we knew what the
> fix was, and we sent an update to the bug report with that information.
>
> The list structure was auto resizing, it knew both how much was allocated
> and how much was used in the first word of the list (we resized only in
> powers of 2 so we could store size in log2 bits, used the rest of the
> bits for the length), you could have a list in as short as two words 
> and it scaled really well to millions of entries.  
>
> It was, and is, super useful.  Wayne is back at Intel and he's teasing
> it out of our libc to use there.
>
> So you may not like it but that's you.  It has worked well in an extremely
> professional environment.  Well coding professional, personalities might
> have been a bit wonky :)

I was commenting on what I found in the linux kernel.  Your code and list
interface may be better.

Jon

From bakul at bitblocks.com  Mon Jan 13 10:35:51 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 12 Jan 2020 16:35:51 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001122340.00CNeef0604557@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
Message-ID: <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>

On Jan 12, 2020, at 3:40 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Kevin Bowling writes:
>> 
>> I am regularly surprised by how surprising type systems are to
>> computing professionals.
> 
> I am currently astonished at this.  Unfortunately, I need to make a hopefully
> minor change to the linux kernel to support something that I want to do in my
> current project.  But, this is my first time looking at the internals which is
> way different that my recollection of UNIX kernels.  It's being enough of an
> adventure that I'm writing up a travelogue of my journey through the code.
> While I swore that I was done writing books this is sure looking like another
> one :-)
> 
> So I came across this piece of what I consider to be bad programming that's
> all over the place...
> 
> One of my programming style rules is to program in the language in which you're
> programming.  The canonical example of not doing this is the Bourne shell which
> was originally written using macros to redefine C to look like Algol68.
> 
> Linux contains several sets of list_for_each_entry() macros that are essentially
> obfuscated for loops that generate inefficient code.  To make things worse, the
> way that they're implemented is by embedding list_head structures into other
> structures.
> 
> In the diagram below, the labels above boxes are structure names.  Names inside
> of boxes are structure member names.  super_blocks, s_list, s_mounts, and
> mnt_instance are all list_head structures.  (Trick question, how many lines are
> in this diagram :-) )
> 
> +-----------------------------------------+
> |                     super_block         |
> |  +--------------+   +----------+        |
> +->| super_blocks |<->|  s_list  |<- ... -+
>   +--------------+   +----------+
>                      |          |        mount              mount
>                      |   ...    |   +--------------+   +--------------+
>                      |          |   |      ...     |   |      ...     |
>                      +----------+   +--------------+   +--------------+
>                   +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+
>                   |  +----------+   +--------------+   +--------------+        |
>                   |                 |      ...     |   |      ...     |        |
>                   |                 +--------------+   +--------------+        |
>                   +------------------------------------------------------------+
> 
> The bizarre thing to me is that the list_head structures point to other list_head
> structures that are embedded in other structures.  When one needs to access a
> non list-head member of the structure one has to pass both the structure type and
> the list_head member name to a macro that figures out how to subtract the offset
> of the list_head member of the structure from the address of that list_head to
> get the address of the structure, and then casts that as the structure type so
> that members can be accessed.

There is similar code in FreeBSD kernel. Embedding head and next ptrs reduces
memory allocation and improves cache locality somewhat. Since C doesn't have
generics, they try to gain the same functionality with macros. See 

https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h

Not that this is the same as what Linux does (which I haven't dug into) but
I suspect they may have had similar motivation.


From jon at fourwinds.com  Mon Jan 13 10:44:47 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 12 Jan 2020 16:44:47 -0800
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
Message-ID: <202001130044.00D0ilcV616661@darkstar.fourwinds.com>

Bakul Shah writes:
> On Jan 12, 2020, at 3:40 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> > 
> > Kevin Bowling writes:
> >> 
> >> I am regularly surprised by how surprising type systems are to
> >> computing professionals.
> > 
> > I am currently astonished at this.  Unfortunately, I need to make a hopefully
> > minor change to the linux kernel to support something that I want to do in my
> > current project.  But, this is my first time looking at the internals which is
> > way different that my recollection of UNIX kernels.  It's being enough of an
> > adventure that I'm writing up a travelogue of my journey through the code.
> > While I swore that I was done writing books this is sure looking like another
> > one :-)
> > 
> > So I came across this piece of what I consider to be bad programming that's
> > all over the place...
> > 
> > One of my programming style rules is to program in the language in which you're
> > programming.  The canonical example of not doing this is the Bourne shell which
> > was originally written using macros to redefine C to look like Algol68.
> > 
> > Linux contains several sets of list_for_each_entry() macros that are essentially
> > obfuscated for loops that generate inefficient code.  To make things worse, the
> > way that they're implemented is by embedding list_head structures into other
> > structures.
> > 
> > In the diagram below, the labels above boxes are structure names.  Names inside
> > of boxes are structure member names.  super_blocks, s_list, s_mounts, and
> > mnt_instance are all list_head structures.  (Trick question, how many lines are
> > in this diagram :-) )
> > 
> > +-----------------------------------------+
> > |                     super_block         |
> > |  +--------------+   +----------+        |
> > +->| super_blocks |<->|  s_list  |<- ... -+
> >    +--------------+   +----------+
> >                       |          |        mount              mount
> >                       |   ...    |   +--------------+   +--------------+
> >                       |          |   |      ...     |   |      ...     |
> >                       +----------+   +--------------+   +--------------+
> >                    +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+
> >                    |  +----------+   +--------------+   +--------------+        |
> >                    |                 |      ...     |   |      ...     |        |
> >                    |                 +--------------+   +--------------+        |
> >                    +------------------------------------------------------------+
> > 
> > The bizarre thing to me is that the list_head structures point to other list_head
> > structures that are embedded in other structures.  When one needs to access a
> > non list-head member of the structure one has to pass both the structure type and
> > the list_head member name to a macro that figures out how to subtract the offset
> > of the list_head member of the structure from the address of that list_head to
> > get the address of the structure, and then casts that as the structure type so
> > that members can be accessed.
>
> There is similar code in FreeBSD kernel. Embedding head and next ptrs reduces
> memory allocation and improves cache locality somewhat. Since C doesn't have
> generics, they try to gain the same functionality with macros. See 
>
> https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h
>
> Not that this is the same as what Linux does (which I haven't dug into) but
> I suspect they may have had similar motivation.

Not sure that I understand.

A list_head structure takes exactly the same amount of space as a pair of pointers,
so the memory allocation should be identical.

I also don't see the cache locality.  Both the embedded list_head and the start
of the structure are accessed in either case; once the programmer has played
guess-the-type the list macro returns a pointer to the start of the structure.

So again, I'm just commenting on what I'm seeing in linux, and while it is
possible that I may be misunderstanding something so far I don't think so.

Jon

From wkt at tuhs.org  Mon Jan 13 10:49:12 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 13 Jan 2020 10:49:12 +1000
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001130044.00D0ilcV616661@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
 <202001130044.00D0ilcV616661@darkstar.fourwinds.com>
Message-ID: <20200113004912.GA27610@minnie.tuhs.org>

All, can we move this not-really-Unix discussion to COFF?
Thanks, Warren

P.S A bit more self-regulation too, please. You shouldn't need me to point
out when the topic has drifted so far :-)

From tytso at mit.edu  Mon Jan 13 10:44:33 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 12 Jan 2020 19:44:33 -0500
Subject: [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001130001.00D012bC608441@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
 <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
 <202001122340.00CNeef0604557@darkstar.fourwinds.com>
 <20200112235051.GG9174@mcvoy.com>
 <202001130001.00D012bC608441@darkstar.fourwinds.com>
Message-ID: <20200113004433.GA440748@mit.edu>

(Not sure this is appropriate for TUHS)

On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > > Linux contains several sets of list_for_each_entry() macros that are essentially
> > > obfuscated for loops that generate inefficient code.  
> >
> > Very common idiom in any real system.  BitKeeper has them as well, they are
> > used everywhere.  They are too useful to not use.  The BitKeeper ones give
> > you most of Perl's list capabilities.
> 
> I don't see it.  In the cases that I've seen so far in linux the only uses are
> inserting, deleting, and traversing lists.  My opinion that anyone who can't
> write
> 	for (p = list; p != NULL; p = p->next)

There are many places where there is a desire to

(a) add an object to the end of the list
(b) remove an object from a linked list where the object was not found
    via iterating over the linked list

One or the other was true for all of the linked lists that you
complained about earlier up-thread.  For example, a struct super has a
doubly linked list of struct mount where we might want to drop a
struct mount without needing iterate over the whole linked list.

So "just use an open-coded singly linked list" is really not that
simple.  In addition, it should be noted that there are
read-copy-update variants of these functions (e.g.,
list_for_each_entry_rcu, list_del_rcu) that can be used with the same
struct list_head structure.

Sure, it would be simpler to just take a global kernel lock, and
iterating over the entire singly linked list to remove an object from
it, or adding an object to the end of a list.  That would be
*simpler*.  But that would be much more, not less, inefficient.

Cheers,

						- Ted

From wkt at tuhs.org  Mon Jan 13 12:13:03 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 13 Jan 2020 12:13:03 +1000
Subject: [TUHS] OK, keep going on type checking
Message-ID: <20200113021303.GA7633@minnie.tuhs.org>

All, I've had a few subscribers argue that the type checking
thread was still Unix-related, so feel free to keep posting
here in TUHS. But if it does drift away to non-Unix areas,
please pass it over to COFF.

Thanks & apologies for being too trigger-happy!

Cheers, Warren

From paul.winalski at gmail.com  Tue Jan 14 05:58:12 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 13 Jan 2020 14:58:12 -0500
Subject: [TUHS] History of symbol preemption
Message-ID: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>

The Executable and Linkable Format (ELF) is the modern standard for
object files in Unix and Unix-like OSes (e.g., Linux), and even for
OpenVMS.  LInux, AIX and probably other implementations of ELF have a
feature in the runtime loader called symbol preemption.  When loading
a shared library, the runtime loader examines the library's symbol
table.  If there is a global symbol with default visibility, and a
value for that symbol has already been loaded, all references to the
symbol in the library being loaded are rebound to the existing
definition.  The existing value thus preempts the definition in the
library.

I'm curious about the history of symbol preemption.  It does not exist
in other implementations of shared libraries, such as IBM OS/370 and
its descendants, OpenVMS, and Microsoft Windows NT.  ELF apparently
was designed in the mid-1990s.  I have found a copy of the System V
Application Binary Interface from April 2001 that describes symbol
preemption in the section on the ELF symbol table.

When was symbol preemption when loading shared objects first
implemented in Unix?  Are there versions of Unix that don't do symbol
preemption?

-Paul W.

From rp at servium.ch  Tue Jan 14 06:46:52 2020
From: rp at servium.ch (Rico Pajarola)
Date: Mon, 13 Jan 2020 12:46:52 -0800
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
Message-ID: <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>

This seems to have originated with SunOS 4. I believe a good proxy for
finding anything that inherited from or was inspired by this is a linker
that recognizes LD_PRELOAD. I wonder if there are other independent
implementations in the Unix space.


On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

> The Executable and Linkable Format (ELF) is the modern standard for
> object files in Unix and Unix-like OSes (e.g., Linux), and even for
> OpenVMS.  LInux, AIX and probably other implementations of ELF have a
> feature in the runtime loader called symbol preemption.  When loading
> a shared library, the runtime loader examines the library's symbol
> table.  If there is a global symbol with default visibility, and a
> value for that symbol has already been loaded, all references to the
> symbol in the library being loaded are rebound to the existing
> definition.  The existing value thus preempts the definition in the
> library.
>
> I'm curious about the history of symbol preemption.  It does not exist
> in other implementations of shared libraries, such as IBM OS/370 and
> its descendants, OpenVMS, and Microsoft Windows NT.  ELF apparently
> was designed in the mid-1990s.  I have found a copy of the System V
> Application Binary Interface from April 2001 that describes symbol
> preemption in the section on the ELF symbol table.
>
> When was symbol preemption when loading shared objects first
> implemented in Unix?  Are there versions of Unix that don't do symbol
> preemption?
>
> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/de4c1184/attachment.html>

From clemc at ccc.com  Tue Jan 14 07:04:14 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 13 Jan 2020 16:04:14 -0500
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
Message-ID: <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>

@ Rico I'm failing sure ELF came from AT&T Summit, not Sun.
@ Steve Johnson were you the manager when was created or were you folks
still using COFF?

Anyway... There were issues with COFF WRT being
architecture-independent and supporting dynamic loading well.  Steve Rago
would also be a good person to ask if you want some of the details.  At one
point there was a COFF2 document, but it may have been System Vx licenses
only.   Also, one of the issues was that AT&T had officially tied up COFF
as a proprietary format -- all part of the 'consider it standard' trying to
force their lunch down all the other UNIX systems throat which was not
having it.   As a result, CMU's MachO was about to become the default
format (OSF and Apple were already using it for that reason), and Unix
International stepped in and convinced AT&T to released the ELF documents
(I was on the UI technical board at that point).  I'm not sure how/why OSF
decided to back off, maybe because after ELF became public it got supported
by GCC.

Now my memory is a little hazy... I think OSF/1-386 used MachO originally,
but I've forgotten.   Switching the kernel to use ELF was one of the
differences between OSF1 and Tru64 IIRC.

On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola <rp at servium.ch> wrote:

> This seems to have originated with SunOS 4. I believe a good proxy for
> finding anything that inherited from or was inspired by this is a linker
> that recognizes LD_PRELOAD. I wonder if there are other independent
> implementations in the Unix space.
>
>
> On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> The Executable and Linkable Format (ELF) is the modern standard for
>> object files in Unix and Unix-like OSes (e.g., Linux), and even for
>> OpenVMS.  LInux, AIX and probably other implementations of ELF have a
>> feature in the runtime loader called symbol preemption.  When loading
>> a shared library, the runtime loader examines the library's symbol
>> table.  If there is a global symbol with default visibility, and a
>> value for that symbol has already been loaded, all references to the
>> symbol in the library being loaded are rebound to the existing
>> definition.  The existing value thus preempts the definition in the
>> library.
>>
>> I'm curious about the history of symbol preemption.  It does not exist
>> in other implementations of shared libraries, such as IBM OS/370 and
>> its descendants, OpenVMS, and Microsoft Windows NT.  ELF apparently
>> was designed in the mid-1990s.  I have found a copy of the System V
>> Application Binary Interface from April 2001 that describes symbol
>> preemption in the section on the ELF symbol table.
>>
>> When was symbol preemption when loading shared objects first
>> implemented in Unix?  Are there versions of Unix that don't do symbol
>> preemption?
>>
>> -Paul W.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/7be5956f/attachment.html>

From rp at servium.ch  Tue Jan 14 07:40:35 2020
From: rp at servium.ch (Rico Pajarola)
Date: Mon, 13 Jan 2020 13:40:35 -0800
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
Message-ID: <CACwAiQnGghCWDENNou7+8qndDZC1UfiTHadWKDyt7HcbdH_nYg@mail.gmail.com>

On Mon, Jan 13, 2020 at 1:04 PM Clem Cole <clemc at ccc.com> wrote:

> @ Rico I'm failing sure ELF came from AT&T Summit, not Sun.
>
yes, but unless my memory is playing tricks, SunOS a.out had this feature.


> @ Steve Johnson were you the manager when was created or were you folks
> still using COFF?
>
> Anyway... There were issues with COFF WRT being
> architecture-independent and supporting dynamic loading well.  Steve Rago
> would also be a good person to ask if you want some of the details.  At one
> point there was a COFF2 document, but it may have been System Vx licenses
> only.   Also, one of the issues was that AT&T had officially tied up COFF
> as a proprietary format -- all part of the 'consider it standard' trying to
> force their lunch down all the other UNIX systems throat which was not
> having it.   As a result, CMU's MachO was about to become the default
> format (OSF and Apple were already using it for that reason), and Unix
> International stepped in and convinced AT&T to released the ELF documents
> (I was on the UI technical board at that point).  I'm not sure how/why OSF
> decided to back off, maybe because after ELF became public it got supported
> by GCC.
>
> Now my memory is a little hazy... I think OSF/1-386 used MachO originally,
> but I've forgotten.   Switching the kernel to use ELF was one of the
> differences between OSF1 and Tru64 IIRC.
>
> On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola <rp at servium.ch> wrote:
>
>> This seems to have originated with SunOS 4. I believe a good proxy for
>> finding anything that inherited from or was inspired by this is a linker
>> that recognizes LD_PRELOAD. I wonder if there are other independent
>> implementations in the Unix space.
>>
>>
>> On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski at gmail.com>
>> wrote:
>>
>>> The Executable and Linkable Format (ELF) is the modern standard for
>>> object files in Unix and Unix-like OSes (e.g., Linux), and even for
>>> OpenVMS.  LInux, AIX and probably other implementations of ELF have a
>>> feature in the runtime loader called symbol preemption.  When loading
>>> a shared library, the runtime loader examines the library's symbol
>>> table.  If there is a global symbol with default visibility, and a
>>> value for that symbol has already been loaded, all references to the
>>> symbol in the library being loaded are rebound to the existing
>>> definition.  The existing value thus preempts the definition in the
>>> library.
>>>
>>> I'm curious about the history of symbol preemption.  It does not exist
>>> in other implementations of shared libraries, such as IBM OS/370 and
>>> its descendants, OpenVMS, and Microsoft Windows NT.  ELF apparently
>>> was designed in the mid-1990s.  I have found a copy of the System V
>>> Application Binary Interface from April 2001 that describes symbol
>>> preemption in the section on the ELF symbol table.
>>>
>>> When was symbol preemption when loading shared objects first
>>> implemented in Unix?  Are there versions of Unix that don't do symbol
>>> preemption?
>>>
>>> -Paul W.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/ffc0d216/attachment.html>

From paul.winalski at gmail.com  Tue Jan 14 07:42:24 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 13 Jan 2020 16:42:24 -0500
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
Message-ID: <CABH=_VSie4JQkr4Bs0GDbeByBkcP1qALBwOcQFH7q_5rtWhbqA@mail.gmail.com>

On 1/13/20, Clem Cole <clemc at ccc.com> wrote:
>
> As a result, CMU's MachO was about to become the default
> format (OSF and Apple were already using it for that reason), and Unix
> International stepped in and convinced AT&T to released the ELF documents
> (I was on the UI technical board at that point).  I'm not sure how/why OSF
> decided to back off, maybe because after ELF became public it got supported
> by GCC.

Mach-O was decidedly a step up from a.out in terms of flexibility and
extensibility, but it is inferior to both COFF and ELF, IMO.  Mach-O
(at least the Apple OS X implementation) handles global symbols and
relocations in a clumsy and baroque way.  Of the three
object/executable formats, ELF is by far the cleanest and most
flexible, and that's possibly why OSF went to it once it became
available.

Microsoft went with COFF, sort-of, in Windows.  But PECOFF (Portable
and Extensible Common Object File Format) is different enough from
vanilla COFF that when I implemented support for it in GEM I found to
better to write an entire new module for PECOFF rather than put
conditional code in the existing COFF-handling code.  I think this was
another of MS's "embrace and extend" gambits to keep control over
their development environment.

> Now my memory is a little hazy... I think OSF/1-386 used MachO originally,
> but I've forgotten.   Switching the kernel to use ELF was one of the
> differences between OSF1 and Tru64 IIRC.

GEM never had to support Mach-O on any of its target platforms.  DEC's
Unix on MIPS used COFF.  Tru64 used ELF exclusively.  I don't know
what Apple used for object files before OS X.  IIRC NeXT was based on
the CMU MACH microkernel and hence used Mach-O.  OS X is
FreeBSD-based, but it uses Mach-O.

Tru64 has symbol preemption.  The Tru64 C/C++ compiler by default
turns off symbol preemption by using PROTECTED visibility for global
symbols, but it does have a --preempt_symbol option.  Using that
option can have disastrous effects on optimization.

Was symbol visibility (default/protected/internal) part of the
original ELF spec from the 1990s, or was it added later?

-Paul W.

From paul.winalski at gmail.com  Tue Jan 14 07:44:46 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 13 Jan 2020 16:44:46 -0500
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CACwAiQnGghCWDENNou7+8qndDZC1UfiTHadWKDyt7HcbdH_nYg@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
 <CACwAiQnGghCWDENNou7+8qndDZC1UfiTHadWKDyt7HcbdH_nYg@mail.gmail.com>
Message-ID: <CABH=_VQgzhG-dCZbq1ZkwCwMNyxv_LWQSp6ZSjckUbN0FN4=Aw@mail.gmail.com>

On 1/13/20, Rico Pajarola <rp at servium.ch> wrote:
>
> yes, but unless my memory is playing tricks, SunOS a.out had this feature.

Do you mean support for shared libraries, or symbol preemption?

-Paul W.

From rp at servium.ch  Tue Jan 14 07:45:48 2020
From: rp at servium.ch (Rico Pajarola)
Date: Mon, 13 Jan 2020 13:45:48 -0800
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CABH=_VQgzhG-dCZbq1ZkwCwMNyxv_LWQSp6ZSjckUbN0FN4=Aw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
 <CACwAiQnGghCWDENNou7+8qndDZC1UfiTHadWKDyt7HcbdH_nYg@mail.gmail.com>
 <CABH=_VQgzhG-dCZbq1ZkwCwMNyxv_LWQSp6ZSjckUbN0FN4=Aw@mail.gmail.com>
Message-ID: <CACwAiQ=+J2A0GyAKh9ywuHCPbqT0h05HDmttOu5-raLXWJ8ZNw@mail.gmail.com>

On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 1/13/20, Rico Pajarola <rp at servium.ch> wrote:
> >
> > yes, but unless my memory is playing tricks, SunOS a.out had this
> feature.
>
> Do you mean support for shared libraries, or symbol preemption?
>
symbol preemption


> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/44199071/attachment.html>

From lm at mcvoy.com  Tue Jan 14 08:20:21 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 13 Jan 2020 14:20:21 -0800
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CACwAiQ=+J2A0GyAKh9ywuHCPbqT0h05HDmttOu5-raLXWJ8ZNw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
 <CACwAiQnGghCWDENNou7+8qndDZC1UfiTHadWKDyt7HcbdH_nYg@mail.gmail.com>
 <CABH=_VQgzhG-dCZbq1ZkwCwMNyxv_LWQSp6ZSjckUbN0FN4=Aw@mail.gmail.com>
 <CACwAiQ=+J2A0GyAKh9ywuHCPbqT0h05HDmttOu5-raLXWJ8ZNw@mail.gmail.com>
Message-ID: <20200113222021.GG8511@mcvoy.com>

On Mon, Jan 13, 2020 at 01:45:48PM -0800, Rico Pajarola wrote:
> On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski <paul.winalski at gmail.com>
> wrote:
> 
> > On 1/13/20, Rico Pajarola <rp at servium.ch> wrote:
> > >
> > > yes, but unless my memory is playing tricks, SunOS a.out had this
> > feature.
> >
> > Do you mean support for shared libraries, or symbol preemption?
> >
> symbol preemption

My memory of this is it was dns lookups that wanted something like this.
SunOS really wanted the world to love YP but the world wanted Sun to
support DNS.  You could, and people did, make a shared lib that overloaded
the default gethostbyname(3) that wanted to do YP, the lib would provide
a DNS based one instead.

That's where I first learned of this stuff.  Gingell would know if you
want to know for sure.

From cbbrowne at gmail.com  Tue Jan 14 08:38:03 2020
From: cbbrowne at gmail.com (Christopher Browne)
Date: Mon, 13 Jan 2020 17:38:03 -0500
Subject: [TUHS] OK, keep going on type checking
In-Reply-To: <20200113021303.GA7633@minnie.tuhs.org>
References: <20200113021303.GA7633@minnie.tuhs.org>
Message-ID: <CAFNqd5XpYDtva-MQ_78ssZUt_qpwavhORajJvMiqzCt99+ooNQ@mail.gmail.com>

On Sun, 12 Jan 2020 at 21:13, Warren Toomey <wkt at tuhs.org> wrote:

> All, I've had a few subscribers argue that the type checking
> thread was still Unix-related, so feel free to keep posting
> here in TUHS. But if it does drift away to non-Unix areas,
> please pass it over to COFF.
>
> Thanks & apologies for being too trigger-happy!
>

Discussion is just busy enough that it's good to keep things somewhat on
track :-).

I have something that has been lurking on my ToDo list that's on this trail
in what I'd think is a relevant way :-)
~/GitWeb> task project:shell | cat
ID Active Age Project Tag  Description Urg
-- ------ --- ------- ---- ----------- ----
24 2w     4w  shell   unix Oh Types      14

Oh is a claimant to the notion of trying to evolve shells to "better."
https://github.com/michaelmacinnis/oh

The name is probably not for the best, but it seems interesting.
MacInnis noted several problems common to shells, and somewhat
strong typing falls into the set of would-be solutions.  He noticed that
there have been lots of attempts to create shells that are embedded
in other languages, which seems universally to lead to them falling
into being curiosities.  Embedding scripts in Lisp or Python or Perl
never seems to turn out.  The pains he points at are...
- Undefined variables lead to bugs.  set -e -u and such may help, but are
optional...
- automatically varadic functions can easily just lose parameters
- splitting lists on whitespace blows up when files are allowed to have
spaces in their names
- return values intentionally look like process return codes, which can be
good, or not...
- global variables are mostly all you have, preventing having much
modularity
- variable expansions/rewrites have sometimes tortured syntax

He built a shell that has a Scheme lying in behind (which I partly like,
and partly
find suspicious).  Mechanisms to address the above are:
- data and code have the same syntax (conses)
- a richer type set (strings, symbols, return codes, a number tower of
Int/Float/Rational, lists, environments)
- first class environments that support modularity
- Fexprs (see John N Shutt's thesis, vau: the ultimate abstraction) allow
implementing your own control structures
- dynamic communications patterns (Rob Pike did a paper on this, on Squeak)
The early bits point at Scheme; dynamic comm points at Go channels, and the
shell is written in Go.

I have had this percolating in my head the last few weeks, and I watched
the recent
conversation about what ":" means with interest, as Oh makes interesting
use of :,
using it to indicate that the remaining portion of a command line is to be
evaluated/expanded, thus:
oh$ write: div 65536 256 2 (add 4 3)
128/7
oh$ define lc3: quote: a b c
oh$ echo $lc3
a b c

For a wee while, I was getting quite tortured by its interpretation (that I
had not yet internalized) of :

I have been unable as of yet to decide if the author's on to something, or
if this is a mere curiosity.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/7a6548bb/attachment.html>

From henry.r.bent at gmail.com  Tue Jan 14 08:53:48 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 13 Jan 2020 17:53:48 -0500
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CABH=_VSie4JQkr4Bs0GDbeByBkcP1qALBwOcQFH7q_5rtWhbqA@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
 <CABH=_VSie4JQkr4Bs0GDbeByBkcP1qALBwOcQFH7q_5rtWhbqA@mail.gmail.com>
Message-ID: <CAEdTPBcTHyJ+7k9RhyeYo4XrZ1SORdPLDTJobL-szThGS7mU3g@mail.gmail.com>

On Mon, 13 Jan 2020 at 16:43, Paul Winalski <paul.winalski at gmail.com> wrote:

>
> > Now my memory is a little hazy... I think OSF/1-386 used MachO
> originally,
> > but I've forgotten.   Switching the kernel to use ELF was one of the
> > differences between OSF1 and Tru64 IIRC.
>
> GEM never had to support Mach-O on any of its target platforms.  DEC's
> Unix on MIPS used COFF.  Tru64 used ELF exclusively.  I don't know
> what Apple used for object files before OS X.  IIRC NeXT was based on
> the CMU MACH microkernel and hence used Mach-O.  OS X is
> FreeBSD-based, but it uses Mach-O.
>

OSF/1 on MIPS used ECOFF by default, but at least some versions could also
create and run ELF executables.  That was all early to mid 1992, I
believe.  I don't have my DECstation up right now to check but I'm sure
that the OSF/1 2.0 beta can do it, and I wouldn't be surprised if the
versions of 1.0 with the v3.0 compiler could also do it.  I remember trying
to do ELF shared libraries but I think that support wasn't ready yet, which
is a shame because the ECOFF shared libraries on that platform are not fun
to deal with.  Not as bad as SGI's ECOFF shared libraries on IRIX 4
though.  I'm not sure if anyone outside of SGI ever bothered to put in the
work required to make one.

Wasn't OSF's original intent to use the OSF/ROSE object format?

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/559aa075/attachment.html>

From crossd at gmail.com  Tue Jan 14 09:46:43 2020
From: crossd at gmail.com (Dan Cross)
Date: Mon, 13 Jan 2020 18:46:43 -0500
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
Message-ID: <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>

[Resending as this got squashed a few days ago. Jon, sorry for the
duplicate. Again.]

On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart <jon at fourwinds.com> wrote:

> [snip]
> So I think that the point that you're trying to make, correct me if I'm
> wrong,
> is that if lists just knew how long they were you could just ask and that
> it
> would be more efficient.
>

What I understood was that, by translating into a lowest-common-denominator
format like text, one loses much of the semantic information implicit in a
richer representation. In particular, much of the internal knowledge (like
type information...) is lost during translation and presentation. Put
another way, with text as usually used by the standard suite of Unix tools,
type information is implicit, rather than explicit. I took this to be less
an issue of efficiency and more of expressiveness.

It is, perhaps, important to remember that Unix works so well because of
heavy use of convention: to take Doug's example, the total number of
commands might be easy to find with `wc` because one assumes each command
is presented on a separate line, with no gaudy header or footer information
or extraneous explanatory text.

This sort of convention, where each logical "record" is a line by itself,
is pervasive on Unix systems, but is not guaranteed. In some sense, those
representations are fragile: a change in output might break something else
downstream in the pipeline, whereas a representation that captures more
semantic meaning is more robust in the face of change but, as in Doug's
example, often harder to use. The Lisp Machine had all sorts of cool
information in the image and a good Lisp hacker familiar with the machine's
structures could write programs to extract and present that information.
But doing so wasn't trivial in the way that '| wc -l' in response to a
casual query is.

While that may be true, it sort of assume that this is something so common
> that
> the extra overhead for line counting should be part of every list.  And it
> doesn't
> address the issue that while maybe you want a line count I may want a
> character
> count or a count of all lines that begin with the letter A.  Limiting this
> example
> to just line numbers ignores the fact that different people might want
> different
> information that can't all be predicted in advance and built into every
> program.
>

This I think illustrates an important point: Unix conventions worked well
enough in practice that many interesting tasks were not just tractable, but
easy and in some cases trivial. Combining programs was easy via pipelines.
Harder stuff involving more elaborate data formats was possible, but, well,
harder and required more involved programming. By contrast, the Lisp
machine could do the hard stuff, but the simple stuff also required
non-trivial programming.

The SQL database point was similarly interesting: having written programs
to talk to relational databases, yes, one can do powerful things: but the
amount of programming required is significant at a minimum and often
substantial.


> It also seems to me that the root problem here is that the data in the
> original
> example was in an emacs-specific format instead of the default UNIX text
> file
> format.
>
> The beauty of UNIX is that with a common file format one can create tools
> that
> process data in different ways that then operate on all data.  Yes, it's
> not as
> efficient as creating a custom tool for a particular purpose, but is much
> better
> for casual use.  One can always create a special purpose tool if a
> particular
> use becomes so prevalent that the extra efficiency is worthwhile.  If
> you're not
> familiar with it, find a copy of the Communications of the ACM issue where
> Knuth
> presented a clever search algorithm (if I remember correctly) and McIlroy
> did a
> critique.  One of the things that Doug pointed out what that while Don's
> code was
> more efficient, by creating a new pile of special-purpose code he
> introduced bugs.
>

The flip side is that one often loses information in the conversion to
text: yes, there are structured data formats with text serializations that
can preserve the lost information, but consuming and processing those with
the standard Unix tools can be messy. Seemingly trivial changes in text,
like reversing the order of two fields, can break programs that consume
that data. Data must be suitable for pipelining (e.g., perhaps free-form
text must be free of newlines or something). These are all limitations.
Where I think the argument went awry is in not recognizing that very often
those problems, while real, are at least tractable.

Many people have claimed, incorrectly in my opinion, that this model fails
> in the
> modern era because it only works on text data.  They change the subject
> when I
> point out that ImageMagick works on binary data.  And, there are now stream
> processing utilities for JSON data and such that show that the UNIX model
> still
> works IF you understand it and know how to use it.
>

Certainly. I think you hit the nail on the head with the proviso that one
must _understand_ the Unix model and how to use it. If one does so, it's
very powerful indeed, and it really is applicable more often than not. But
it is not a panacea (not that anyone suggested it is). As an example, how
do I apply an unmodified `grep` to arbitrary JSON data (which may span more
than one line)? Perhaps there is a way (I can imagine a 'record2line'
program that consumes a single JSON object and emits it as a syntactically
valid one-liner...) but I can also imagine all sorts of ways that might go
wrong.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/778d3d33/attachment.html>

From clemc at ccc.com  Tue Jan 14 10:31:53 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 13 Jan 2020 19:31:53 -0500
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CAEdTPBcTHyJ+7k9RhyeYo4XrZ1SORdPLDTJobL-szThGS7mU3g@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <CACwAiQ=QTRc6OJrGDQ_Jw50sAPUCaTqQq3mJVLJ3GN0K4U=YBw@mail.gmail.com>
 <CAC20D2PsgKMtANSSQ2be4of8VDKCZZ5j7jmQYeGa6N5U532mfA@mail.gmail.com>
 <CABH=_VSie4JQkr4Bs0GDbeByBkcP1qALBwOcQFH7q_5rtWhbqA@mail.gmail.com>
 <CAEdTPBcTHyJ+7k9RhyeYo4XrZ1SORdPLDTJobL-szThGS7mU3g@mail.gmail.com>
Message-ID: <CAC20D2Pm1m1KNG4OM4PyMW87D2LGHZ_2+K1ko_4Ea2H73OQMwQ@mail.gmail.com>

On Mon, Jan 13, 2020 at 5:54 PM Henry Bent <henry.r.bent at gmail.com> wrote:

> Wasn't OSF's original intent to use the OSF/ROSE object format?
>
Yes and when I said OSF/1 I meant the version from OSF itself which was on
the 386,  MIPS and an Encore box
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/373fd7f5/attachment.html>

From rich.salz at gmail.com  Tue Jan 14 11:58:08 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 13 Jan 2020 20:58:08 -0500
Subject: [TUHS] OK, keep going on type checking
In-Reply-To: <CAFNqd5XpYDtva-MQ_78ssZUt_qpwavhORajJvMiqzCt99+ooNQ@mail.gmail.com>
References: <20200113021303.GA7633@minnie.tuhs.org>
 <CAFNqd5XpYDtva-MQ_78ssZUt_qpwavhORajJvMiqzCt99+ooNQ@mail.gmail.com>
Message-ID: <CAFH29tr7um0H8SGfFe8Zgix_oF20xoX46FAmrb6M8s1vtU6a9g@mail.gmail.com>

A custom struct conveys information to those applications that have the
struct compiled-in (assuming C).
A string version of the same struct data also works for those applications
that would know the struct, but is also useful to a whole bunch of other
tools.
Yeah, there's round-off errors for floating point numbers I suppose, but
the trade-off seems like infinite to approximately zero, no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200113/520a7ea1/attachment.html>

From gingell at computer.org  Tue Jan 14 12:53:33 2020
From: gingell at computer.org (Rob Gingell)
Date: Mon, 13 Jan 2020 18:53:33 -0800
Subject: [TUHS] History of symbol preemption
In-Reply-To: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
Message-ID: <5e9784ef-155a-6982-50dc-73a863b13028@computer.org>

On 1/13/2020 11:58 AM, Paul Winalski wrote:
> When was symbol preemption when loading shared objects first
> implemented in Unix?  Are there versions of Unix that don't do symbol
> preemption?

The behavior described was in dynamic linking as introduced in SunOS 
4.0. There had been a couple of earlier shared library implementations, 
notably System V Shared Libraries but I couldn't speak to whether any of 
them had the behavior.

The reason the behavior is present is to (try to) preserve the behavior 
of an "ld" command line with respect to how the order of library 
specification impacted which definition of a given symbol was used to 
resolve references to it. With archive libraries the ordering could be 
used to effect interposition in sometimes obscure and questionable ways 
especially when archives were unordered. With shared objects, given that 
the whole object is always present, the usual intent of the ordering of 
libraries with respect to interposition is preserved by having the first 
definition be used to resolve all references.

(And the reason "ld"'s behavior was relevant is that the idea was to 
make link editing an ongoing process as code assembled rather than a one 
time thing. So yes the run-time link-editor does it but that's because 
it's conceptually the functionality of the static link-editor continuing 
its work to knit together the still-assembling program.)

The evolution of link editors in Solaris eventually resulted in the 
ability to effect more granular scoping and binding operations, 
including shared objects whose references to internal symbols could not 
be interposed upon and thus perhaps reflected the behavior of other 
systems mentioned in the original question.

But the interposition / preemption behavior was the one which, at the 
time dynamic linking was introduced, best satisfied the "Principle of 
Least Surprise".

On 1/13/2020 12:46 PM, Rico Pajarola wrote:
> I believe a good proxy for 
> finding anything that inherited from or was inspired by this is a linker 
> that recognizes LD_PRELOAD.

On 1/13/2020 2:20 PM, Larry McVoy wrote:
> You could, and people did, make a shared lib that overloaded
> the default gethostbyname(3) that wanted to do YP, the lib would provide
> a DNS based one instead.

Handling interposition in this way turned it into an explicit feature. 
Once multiple definitions for a symbol could exist in a program (or, 
definitions not yet referenced), devices to permit the navigation of the 
interposition like LD_PRELOAD, or the Name Service Switch, or Pluggable 
Authentication Modules became things that could be built around the 
functionality.

On 1/13/2020 1:04 PM, Clem Cole wrote:
> @ Rico I'm failing sure ELF came from AT&T Summit, not Sun.

Yes, SunOS 4.0 rode the a.out object file format. ELF originated at 
Summit and as others have noted was a vast improvement.

From lars at nocrew.org  Tue Jan 14 18:54:45 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 14 Jan 2020 08:54:45 +0000
Subject: [TUHS] Spacewar at Bell Labs
Message-ID: <7wmuaqju3u.fsf@junk.nocrew.org>

Hello,

https://www.bell-labs.com/usr/dmr/www/spacetravel.html says:

> Later we fixed Space Travel so it would run under (PDP-7) Unix instead
> of standalone, and did also a very faithful copy of the Spacewar game

I have a file with ".TITLE PDP-9/GRAPHIC II VERSION OF SPACEWAR".  (I
hope it will go public soon.)  It seems to be a standalone program, and
it's written in something close to MACRO-9 syntax.  I'm guessing the
Bell Labs version would have been written using the Unix assembler.

Best regards,
Lars Brinkhoff

From jon at fourwinds.com  Wed Jan 15 02:59:11 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 14 Jan 2020 08:59:11 -0800
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <7wmuaqju3u.fsf@junk.nocrew.org>
References: <7wmuaqju3u.fsf@junk.nocrew.org>
Message-ID: <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>

Lars Brinkhoff writes:
> Hello,
>
> https://www.bell-labs.com/usr/dmr/www/spacetravel.html says:
>
> > Later we fixed Space Travel so it would run under (PDP-7) Unix instead
> > of standalone, and did also a very faithful copy of the Spacewar game
>
> I have a file with ".TITLE PDP-9/GRAPHIC II VERSION OF SPACEWAR".  (I
> hope it will go public soon.)  It seems to be a standalone program, and
> it's written in something close to MACRO-9 syntax.  I'm guessing the
> Bell Labs version would have been written using the Unix assembler.
>
> Best regards,
> Lars Brinkhoff

I have a copy of double-sun space war (sorry, just the binary) for the
PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written
in octal on the leader.  Not sure if it's of any use but it's a nice
historical artifact from the BTL explorer scout days.

Jon

From lars at nocrew.org  Wed Jan 15 03:15:06 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 14 Jan 2020 17:15:06 +0000
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Tue, 14 Jan 2020 08:59:11 -0800")
References: <7wmuaqju3u.fsf@junk.nocrew.org>
 <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>
Message-ID: <7wsgkihsdh.fsf@junk.nocrew.org>

Jon Steinhart wrote:
> I have a copy of double-sun space war (sorry, just the binary) for the
> PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written
> in octal on the leader.  Not sure if it's of any use

I'm very interested in this!  Is the paper tape readable somehow?

From jon at fourwinds.com  Wed Jan 15 03:19:17 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 14 Jan 2020 09:19:17 -0800
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <7wsgkihsdh.fsf@junk.nocrew.org>
References: <7wmuaqju3u.fsf@junk.nocrew.org>
 <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>
 <7wsgkihsdh.fsf@junk.nocrew.org>
Message-ID: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com>

Lars Brinkhoff writes:
> Jon Steinhart wrote:
> > I have a copy of double-sun space war (sorry, just the binary) for the
> > PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written
> > in octal on the leader.  Not sure if it's of any use
>
> I'm very interested in this!  Is the paper tape readable somehow?

Now that's an interesting question.  Being paper tape, it's from the days
in which you could see a bit with the naked eye.  Another industrial
artifact that I have somewhere is a paper tape reader, but it would take
time away from skiing to get it working.  Does anybody know if the
Computer History Museum or equivalent has a DEC paper tape reader that
works?  I could probably lay it out on a scanner but that would be
tedious.  Might actually be best, it's over 45 years old and probably
fragile.

From clemc at ccc.com  Wed Jan 15 03:25:44 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 14 Jan 2020 12:25:44 -0500
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <7wsgkihsdh.fsf@junk.nocrew.org>
References: <7wmuaqju3u.fsf@junk.nocrew.org>
 <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>
 <7wsgkihsdh.fsf@junk.nocrew.org>
Message-ID: <CAC20D2OTFhpO-uw989bJuuRjevFF+7HBLuviDsGodY1ggGQpDw@mail.gmail.com>

I built a paper tape reader at one point, lord knows were it is. It's
pretty easy -- Two pieces of wood to hold the paper with a mm or 2 shaved
off the bottom of one of them the width of the paper tape. Then 9 parallel
holes and put optical transistors connected to a 5 volt supply via a series
resistor, running into a parallel port the 4th one is used as a strobe to
pick of the 8 data bits and small light bulb on the other piece of wood.
 You then just pull it through and its self strobing.   Set up a cat <
/dev/parallel > /tmp/foo
Your basically done, you'll need to pick reasonable values for the
resistors to that match your transistors to switch on/off if the light
passed through the hole.  I've forgotten what I used, it something I had in
the parts box.





On Tue, Jan 14, 2020 at 12:16 PM Lars Brinkhoff <lars at nocrew.org> wrote:

> Jon Steinhart wrote:
> > I have a copy of double-sun space war (sorry, just the binary) for the
> > PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written
> > in octal on the leader.  Not sure if it's of any use
>
> I'm very interested in this!  Is the paper tape readable somehow?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200114/dbb20aef/attachment.html>

From lars at nocrew.org  Wed Jan 15 03:26:41 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 14 Jan 2020 17:26:41 +0000
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Tue, 14 Jan 2020 09:19:17 -0800")
References: <7wmuaqju3u.fsf@junk.nocrew.org>
 <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>
 <7wsgkihsdh.fsf@junk.nocrew.org>
 <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com>
Message-ID: <7wk15uhru6.fsf@junk.nocrew.org>

Jon Steinhart wrote:
>> Is the paper tape readable somehow?
> Does anybody know if the Computer History Museum or equivalent has a
> DEC paper tape reader that works?

I'm almost certain they do.  If you can get it to them, that's probably
the best option.  To people closer to Seattle I would recommend Living
Computers Museum.

> I could probably lay it out on a scanner but that would be tedious.
> Might actually be best, it's over 45 years old and probably fragile.

Having recently read some Whirwind paper tapes, I'm sure the CHM people
know how to handle old tapes.  Paper or otherwise.

From sauer at technologists.com  Wed Jan 15 05:21:34 2020
From: sauer at technologists.com (Charles H Sauer)
Date: Tue, 14 Jan 2020 13:21:34 -0600
Subject: [TUHS] two AIX items [was Re:  History of symbol preemption
In-Reply-To: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
Message-ID: <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>



On 1/13/2020 1:58 PM, Paul Winalski wrote:

> ...  LInux, AIX and probably other implementations of ELF have a
> feature in the runtime loader called symbol preemption.  When loading

As far as I know, AIX has never used ELF.

On the RT, AIX 1 & 2 used a.out enhanced for basic shared library 
support, designed by Larry Loucks with help from ISC, probably John 
Levine, if I recall correctly.

Starting with AIX 3, AIX used an extended COFF. See Auslander et al, 
"Dynamic Linking and Loading in the AIX System", SA23-2619 RISC 
System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.) 
See, also, https://en.wikipedia.org/wiki/XCOFF.

It seems likely that AIX XCOFF supported symbol preemption, I haven't 
tried to determine one way or the other.

AIX on 386 & 370 probably used a.out. Clem probably knows.

An IBM retirees group on Facebook led me to IBM AIX Enhancements and 
Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html, 
just available yesterday. I tend to think of AIX as abandoned by IBM in 
favor of Linux, but, of course, that isn't really true. I've downloaded 
the PDF, but not looked inside.

Charlie

-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From clemc at ccc.com  Wed Jan 15 06:31:12 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 14 Jan 2020 15:31:12 -0500
Subject: [TUHS] two AIX items [was Re: History of symbol preemption
In-Reply-To: <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
Message-ID: <CAC20D2P6kXaRERBhDNUsCwD1w_FA=KdhederqGnPvJmCu-NmVQ@mail.gmail.com>

On Tue, Jan 14, 2020 at 2:29 PM Charles H Sauer <sauer at technologists.com>
wrote:

> AIX on 386 & 370 probably used a.out. Clem probably knows.
>
I don't remember for sure, but I think that's right.  It might have used
COFF, given the time frame but I don't think so since it was originally
targetted for University/Research sites which were a.out oriented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200114/03508c25/attachment.html>

From kevin.bowling at kev009.com  Wed Jan 15 09:17:46 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 14 Jan 2020 16:17:46 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
Message-ID: <CAK7dMtDRjWJ3B1wpndTcuCmxfDen+rg_6dFDQJtVh5WS5qcLqw@mail.gmail.com>

Thanks Dan, this message is exactly what I was trying to express.  To
piggyback on some of your idea, one limitation on getting at the
representation is the simplicity of the shell.  If you look back at
The Mother of All Demos, or environments like the LispM, Project
Oberon, Alto, even the BLIT it seems to me like there may be ways to
harmonize the underlying representation with ({use?, implementation?,
mental model?} What is it that makes the unix shell and pipelines so
desirable and unchanged?

One thing I notice is that as my millenial peers learn, adopt, and use
unix as software or doctrine, it is a fixture.  It seems like older
generations have some of this as well but we can make computers do
whatever we want;  there are no rules only conventions.

I'm not trying to convince anyone of anything, there is mounting
science that we basically never change our minds on anything.  The
conversation was useful for solidifying my own views and maybe making
people who have done this for a long time to express their views on
the basics for shared consideration.

Regards,
Kevin

On Mon, Jan 13, 2020 at 4:48 PM Dan Cross <crossd at gmail.com> wrote:
>
> [Resending as this got squashed a few days ago. Jon, sorry for the duplicate. Again.]
>
> On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart <jon at fourwinds.com> wrote:
>>
>> [snip]
>> So I think that the point that you're trying to make, correct me if I'm wrong,
>> is that if lists just knew how long they were you could just ask and that it
>> would be more efficient.
>
>
> What I understood was that, by translating into a lowest-common-denominator format like text, one loses much of the semantic information implicit in a richer representation. In particular, much of the internal knowledge (like type information...) is lost during translation and presentation. Put another way, with text as usually used by the standard suite of Unix tools, type information is implicit, rather than explicit. I took this to be less an issue of efficiency and more of expressiveness.
>
> It is, perhaps, important to remember that Unix works so well because of heavy use of convention: to take Doug's example, the total number of commands might be easy to find with `wc` because one assumes each command is presented on a separate line, with no gaudy header or footer information or extraneous explanatory text.
>
> This sort of convention, where each logical "record" is a line by itself, is pervasive on Unix systems, but is not guaranteed. In some sense, those representations are fragile: a change in output might break something else downstream in the pipeline, whereas a representation that captures more semantic meaning is more robust in the face of change but, as in Doug's example, often harder to use. The Lisp Machine had all sorts of cool information in the image and a good Lisp hacker familiar with the machine's structures could write programs to extract and present that information. But doing so wasn't trivial in the way that '| wc -l' in response to a casual query is.
>
>> While that may be true, it sort of assume that this is something so common that
>> the extra overhead for line counting should be part of every list.  And it doesn't
>> address the issue that while maybe you want a line count I may want a character
>> count or a count of all lines that begin with the letter A.  Limiting this example
>> to just line numbers ignores the fact that different people might want different
>> information that can't all be predicted in advance and built into every program.
>
>
> This I think illustrates an important point: Unix conventions worked well enough in practice that many interesting tasks were not just tractable, but easy and in some cases trivial. Combining programs was easy via pipelines. Harder stuff involving more elaborate data formats was possible, but, well, harder and required more involved programming. By contrast, the Lisp machine could do the hard stuff, but the simple stuff also required non-trivial programming.
>
> The SQL database point was similarly interesting: having written programs to talk to relational databases, yes, one can do powerful things: but the amount of programming required is significant at a minimum and often substantial.
>
>>
>> It also seems to me that the root problem here is that the data in the original
>> example was in an emacs-specific format instead of the default UNIX text file
>> format.
>>
>> The beauty of UNIX is that with a common file format one can create tools that
>> process data in different ways that then operate on all data.  Yes, it's not as
>> efficient as creating a custom tool for a particular purpose, but is much better
>> for casual use.  One can always create a special purpose tool if a particular
>> use becomes so prevalent that the extra efficiency is worthwhile.  If you're not
>> familiar with it, find a copy of the Communications of the ACM issue where Knuth
>> presented a clever search algorithm (if I remember correctly) and McIlroy did a
>> critique.  One of the things that Doug pointed out what that while Don's code was
>> more efficient, by creating a new pile of special-purpose code he introduced bugs.
>
>
> The flip side is that one often loses information in the conversion to text: yes, there are structured data formats with text serializations that can preserve the lost information, but consuming and processing those with the standard Unix tools can be messy. Seemingly trivial changes in text, like reversing the order of two fields, can break programs that consume that data. Data must be suitable for pipelining (e.g., perhaps free-form text must be free of newlines or something). These are all limitations. Where I think the argument went awry is in not recognizing that very often those problems, while real, are at least tractable.
>
>> Many people have claimed, incorrectly in my opinion, that this model fails in the
>> modern era because it only works on text data.  They change the subject when I
>> point out that ImageMagick works on binary data.  And, there are now stream
>> processing utilities for JSON data and such that show that the UNIX model still
>> works IF you understand it and know how to use it.
>
>
> Certainly. I think you hit the nail on the head with the proviso that one must _understand_ the Unix model and how to use it. If one does so, it's very powerful indeed, and it really is applicable more often than not. But it is not a panacea (not that anyone suggested it is). As an example, how do I apply an unmodified `grep` to arbitrary JSON data (which may span more than one line)? Perhaps there is a way (I can imagine a 'record2line' program that consumes a single JSON object and emits it as a syntactically valid one-liner...) but I can also imagine all sorts of ways that might go wrong.
>
>         - Dan C.
>

From kevin.bowling at kev009.com  Wed Jan 15 09:22:38 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 14 Jan 2020 16:22:38 -0700
Subject: [TUHS] two AIX items [was Re: History of symbol preemption
In-Reply-To: <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
Message-ID: <CAK7dMtChcnOWitg4zjMDKM1+R8FPKA548mQW9T9o8Kof-z1dfg@mail.gmail.com>

I've got a bunch of paper AIX internals documentation outside the
usual, most interesting from memory is one describing the 4.1 work
where it gained SMP support, pthreads, and a bunch of other things.  I
need to get some kind of scanning setup if you are interested.

On Tue, Jan 14, 2020 at 12:29 PM Charles H Sauer
<sauer at technologists.com> wrote:
>
>
>
> On 1/13/2020 1:58 PM, Paul Winalski wrote:
>
> > ...  LInux, AIX and probably other implementations of ELF have a
> > feature in the runtime loader called symbol preemption.  When loading
>
> As far as I know, AIX has never used ELF.
>
> On the RT, AIX 1 & 2 used a.out enhanced for basic shared library
> support, designed by Larry Loucks with help from ISC, probably John
> Levine, if I recall correctly.
>
> Starting with AIX 3, AIX used an extended COFF. See Auslander et al,
> "Dynamic Linking and Loading in the AIX System", SA23-2619 RISC
> System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.)
> See, also, https://en.wikipedia.org/wiki/XCOFF.
>
> It seems likely that AIX XCOFF supported symbol preemption, I haven't
> tried to determine one way or the other.
>
> AIX on 386 & 370 probably used a.out. Clem probably knows.
>
> An IBM retirees group on Facebook led me to IBM AIX Enhancements and
> Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html,
> just available yesterday. I tend to think of AIX as abandoned by IBM in
> favor of Linux, but, of course, that isn't really true. I've downloaded
> the PDF, but not looked inside.
>
> Charlie
>
> --
> voice: +1.512.784.7526       e-mail: sauer at technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/Skype/Twitter: CharlesHSauer

From tuhs at cuzuco.com  Wed Jan 15 13:32:45 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Tue, 14 Jan 2020 22:32:45 -0500 (EST)
Subject: [TUHS] Spacewar at Bell Labs
Message-ID: <202001150332.00F3WjAQ013229@cuzuco.com>

> Papertape reader?

The last Cyphercon had a paper tape reader in their badge --

https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/

You can proably buy one from the con https://cyphercon.com/, or the makers
http://www.tymkrs.com/ or ebay...

-Brian

From jon at fourwinds.com  Wed Jan 15 14:01:11 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 14 Jan 2020 20:01:11 -0800
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <202001150332.00F3WjAQ013229@cuzuco.com>
References: <202001150332.00F3WjAQ013229@cuzuco.com>
Message-ID: <202001150401.00F41Bpj1685249@darkstar.fourwinds.com>

Brian Walden writes:
> > Papertape reader?
>
> The last Cyphercon had a paper tape reader in their badge --
>
> https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/
>
> You can proably buy one from the con https://cyphercon.com/, or the makers
> http://www.tymkrs.com/ or ebay...
>
> -Brian

That's cool, but I'm worried about the fragility of the tape after all this time.
Maybe because I got my start in the early networking era when I had to transfer
files from one machine to another by feeding the paper tape from the punch in one
ASR-33 into the reader of another :-)

From bakul at bitblocks.com  Wed Jan 15 14:50:33 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 14 Jan 2020 20:50:33 -0800
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: Your message of "Tue, 14 Jan 2020 20:01:11 -0800."
 <202001150401.00F41Bpj1685249@darkstar.fourwinds.com>
References: <202001150332.00F3WjAQ013229@cuzuco.com>
 <202001150401.00F41Bpj1685249@darkstar.fourwinds.com>
Message-ID: <20200115045040.A6BA0156E42D@mail.bitblocks.com>

On Tue, 14 Jan 2020 20:01:11 -0800 Jon Steinhart <jon at fourwinds.com> wrote:
>
> That's cool, but I'm worried about the fragility of the tape after all this
> time.

I thought paper tape lasted much longer that magtapes....

From tuhs at cuzuco.com  Wed Jan 15 14:54:15 2020
From: tuhs at cuzuco.com (Brian Walden)
Date: Tue, 14 Jan 2020 23:54:15 -0500 (EST)
Subject: [TUHS] A portrait of cut(1)
Message-ID: <202001150454.00F4sF9H013965@cuzuco.com>

Random832 <random832 at fastmail.com> writes:
>markus schnalke <meillo at marmaro.de> writes:
>> [2015-11-09 08:58] Doug McIlroy <doug at cs.dartmouth.edu>
>>> things like "cut" and "paste", whose exact provenance
>>> I can't recall.
>>
>> Thanks for reminding me that I wanted to share my portrait of
>> cut(1) with you. (I sent some questions to this list, a few
>> months ago, remember?) Now, here it is:
>>
>>      http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf
>
>Did you happen to find out what GWRL stands for, in the the comments at
>the top of early versions of cut.c and paste.c?
>
>/* cut : cut and paste columns of a table (projection of a relation) (GWRL) */
>/* Release 1.5; handles single backspaces as produced by nroff    */
>/* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */
>/*        (-s option: serial concatenation like old (127's) paste command */
>
>For that matter, what's the "old (127's) paste command" it refers to?

I know this thread is almost 5 years old, I came across it searching for
something else But as no one could answer these questions back then, I can.

GWRL stands for Gottfried W. R. Luderer, the author of cut(1) and paste(1),
probably around 1978.  Those came either from PWB or USG, as he worked with,
or for, Berkley Tague. Thus they made their way into AT&T commercial UNIX,
first into System III and the into System V, and that's why they are missing
from early BSD releases as they didn't get into Research UNIX until the
8th Edition.  Also "127" was the internal department number for the Computer
Science Research group at Bell Labs where UNIX originated

Dr. Luderer co-authored this paper in the orginal 1978 BSTJ on UNIX --
https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/bstj57-6-2201.pdf

I knew Dr. Luderer and he was even kind enough to arrange for me stay with his
relatives for a few days in Braunschweig, West Germany (correct county name for
the time) on my first trip to Europe many decades ago. But haven't had contact nor
even thought of him forever until I saw his initials. I also briefly worked for Berk
when he was the department head for 45263 in Whippany Bell Labs before moving to
Murray Hill.

And doing a quick search for him, it looks like he wrote and autobiograhy, which I
am now going to have to purchase
http://www.lulu.com/shop/gottfried-luderer/go-west-young-german/paperback/product-23385772.html?ppn=1

-Brian

From fair-tuhs at netbsd.org  Wed Jan 15 15:42:55 2020
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Tue, 14 Jan 2020 21:42:55 -0800
Subject: [TUHS] Looking for Maitre'd tarball
In-Reply-To: <087068da-86b5-c886-2273-81538a731a41@embarqmail.com>
Message-ID: <16250.1579066975@cesium.clock.org>

Are you sure you don't mean Brian Bershad?

https://homes.cs.washington.edu/~bershad/CV/cv.htm

	Erik

From lars at nocrew.org  Wed Jan 15 16:17:26 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 15 Jan 2020 06:17:26 +0000
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <202001150332.00F3WjAQ013229@cuzuco.com> (Brian Walden's message
 of "Tue, 14 Jan 2020 22:32:45 -0500 (EST)")
References: <202001150332.00F3WjAQ013229@cuzuco.com>
Message-ID: <7wsgkhgs5l.fsf@junk.nocrew.org>

Brian Walden wrote:
>> Papertape reader?
> The last Cyphercon had a paper tape reader in their badge --
> https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/

I'd be all over this if there also were a way to punch tapes.

From earl.baugh at gmail.com  Wed Jan 15 16:34:29 2020
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 15 Jan 2020 01:34:29 -0500
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <7wsgkhgs5l.fsf@junk.nocrew.org>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
Message-ID: <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>

Why not build a variation of this with an Arduino?
 https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. You could use cardboard rather than wood if it’s just a one time job. ( or scan the tape into files and process digitally ?) 

Earl 

Sent from my iPhone

> On Jan 15, 2020, at 1:18 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Brian Walden wrote:
>>> Papertape reader?
>> The last Cyphercon had a paper tape reader in their badge --
>> https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/
> 
> I'd be all over this if there also were a way to punch tapes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200115/ad8be5a9/attachment.html>

From jon at fourwinds.com  Wed Jan 15 17:10:53 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 14 Jan 2020 23:10:53 -0800
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
 <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
Message-ID: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>

Earl Baugh writes:
> Why not build a variation of this with an Arduino?
>  https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/.
> You could use cardboard rather than wood if it’s just a one time job. ( or scan
> the tape into files and process digitally ?) 
> 
> Earl 

I thought that I said earlier that I had a paper tape reader here but don't
remember much about it or if it ever worked.  If I didn't have a huge project
list and it wasn't ski season I could hook it up to a pi.  More likely that
I'll get to a computer museum sooner.

Just to keep this UNIX-related so that Warren doesn't get cranky, I believe
that this reader came out of some sort of experimental telephone exchange
in our group that was decommissioned.  Dave Weller was very supportive of my
interests and somehow arranged for me to take much of it home as surplus
equipment.  Kept me in 7400-series parts and Augat wire-wrap boards for a
long time.  While there was no way that I could have kept the thing, I wish
that I had the magnetic drum memory because it was so cool from an industrial
art perspective.

Heinz may remember more about this than I do because he actually worked on
this project, but our department developed what I believe was the first
all-digital telephone exchange that used digital filtering (Hal Alles and
Jim Kaiser were in the group).  I think that it had a pair of PDP-11/10s
in it, and a bigger PDP-11 as a supervisory machine that ran UNIX.  I have
vague memories of Heinz and Carl poring over huge C program listings.  I
also remember that there was a bug in the long-distance code where it wasn't
sending out the ST tone that ended up taking all of the key pulse senders in
the Berkeley Heights telephone exchange that provided the trunk line to our
lab off line as they didn't have timeouts and needed to be manually reset.
But hey, we were the phone company too so what could they do about it?

Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s
but those turned out to be useless because of the way that DEC did the DRAM
refresh; it wasn't interleaved, they just stopped everything every so many
ms and refreshed everything.  Non-starter for real-time systems.

And another thought, this machine may have been why Heinz wrote MERT.

I was gone before this system was completed so I have no idea how it fared
and how many of the ideas were incorporated into production systems.  Oh,
yeah, I think that it was called the SS1 for Slave Switch 1.

Jon

From rly1 at embarqmail.com  Wed Jan 15 17:38:30 2020
From: rly1 at embarqmail.com (Ron Young)
Date: Tue, 14 Jan 2020 23:38:30 -0800
Subject: [TUHS] Looking for Maitre'd tarball
In-Reply-To: <16250.1579066975@cesium.clock.org>
References: <16250.1579066975@cesium.clock.org>
Message-ID: <ABF10135-AA03-475E-834E-56DA7B69AEA8@embarqmail.com>

On January 14, 2020 9:42:55 PM PST, "Erik E. Fair" <fair-tuhs at netbsd.org> wrote:
>Are you sure you don't mean Brian Bershad?
>
>https://homes.cs.washington.edu/~bershad/CV/cv.htm
>
>	Erik

Thanks for this.... Gives me more research materials to try and track. Still no joy on a tarball however 

-ron
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From meillo at marmaro.de  Wed Jan 15 18:02:15 2020
From: meillo at marmaro.de (markus schnalke)
Date: Wed, 15 Jan 2020 09:02:15 +0100
Subject: [TUHS] A portrait of cut(1)
In-Reply-To: <202001150454.00F4sF9H013965@cuzuco.com>
References: <202001150454.00F4sF9H013965@cuzuco.com>
Message-ID: <1irdd1-81R-00@marmaro.de>

Hoi,

thanks a lot for sharing these yet missing pieces of information
and the stories. Very interesting.


meillo


[2020-01-14 23:54] Brian Walden <tuhs at cuzuco.com>
> Random832 <random832 at fastmail.com> writes:
> >markus schnalke <meillo at marmaro.de> writes:
> >> [2015-11-09 08:58] Doug McIlroy <doug at cs.dartmouth.edu>
> >>> things like "cut" and "paste", whose exact provenance
> >>> I can't recall.
> >>
> >> Thanks for reminding me that I wanted to share my portrait of
> >> cut(1) with you. (I sent some questions to this list, a few
> >> months ago, remember?) Now, here it is:
> >>
> >>      http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf
> >
> >Did you happen to find out what GWRL stands for, in the the comments at
> >the top of early versions of cut.c and paste.c?
> >
> >/* cut : cut and paste columns of a table (projection of a relation) (GWRL) */
> >/* Release 1.5; handles single backspaces as produced by nroff    */
> >/* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */
> >/*        (-s option: serial concatenation like old (127's) paste command */
> >
> >For that matter, what's the "old (127's) paste command" it refers to?
> 
> I know this thread is almost 5 years old, I came across it searching for
> something else But as no one could answer these questions back then, I can.
> 
> GWRL stands for Gottfried W. R. Luderer, the author of cut(1) and paste(1),
> probably around 1978.  Those came either from PWB or USG, as he worked with,
> or for, Berkley Tague. Thus they made their way into AT&T commercial UNIX,
> first into System III and the into System V, and that's why they are missing
> from early BSD releases as they didn't get into Research UNIX until the
> 8th Edition.  Also "127" was the internal department number for the Computer
> Science Research group at Bell Labs where UNIX originated
> 
> Dr. Luderer co-authored this paper in the orginal 1978 BSTJ on UNIX --
> https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/bstj57-6-2201.pdf
> 
> I knew Dr. Luderer and he was even kind enough to arrange for me stay with his
> relatives for a few days in Braunschweig, West Germany (correct county name for
> the time) on my first trip to Europe many decades ago. But haven't had contact nor
> even thought of him forever until I saw his initials. I also briefly worked for Berk
> when he was the department head for 45263 in Whippany Bell Labs before moving to
> Murray Hill.
> 
> And doing a quick search for him, it looks like he wrote and autobiograhy, which I
> am now going to have to purchase
> http://www.lulu.com/shop/gottfried-luderer/go-west-young-german/paperback/product-23385772.html?ppn=1
> 
> -Brian
> 

From earl.baugh at gmail.com  Wed Jan 15 18:05:16 2020
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 15 Jan 2020 03:05:16 -0500
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>
References: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>
Message-ID: <C1328B18-7197-45F8-A4DA-CEDF3D8EA38A@gmail.com>

I thought the concern was about the fragility of the tape and the concern about running it thru a period reader. I was just thinking these two options would be safer on the tape.  That’s why I was suggesting them.  Just trying to be helpful .. all to familiar with the long project list :-) 

Earl 


Sent from my iPhone

> On Jan 15, 2020, at 2:12 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Earl Baugh writes:
>> Why not build a variation of this with an Arduino?
>> https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/.
>> You could use cardboard rather than wood if it’s just a one time job. ( or scan
>> the tape into files and process digitally ?) 
>> 
>> Earl 
> 
> I thought that I said earlier that I had a paper tape reader here but don't
> remember much about it or if it ever worked.  If I didn't have a huge project
> list and it wasn't ski season I could hook it up to a pi.  More likely that
> I'll get to a computer museum sooner.
> 
> Just to keep this UNIX-related so that Warren doesn't get cranky, I believe
> that this reader came out of some sort of experimental telephone exchange
> in our group that was decommissioned.  Dave Weller was very supportive of my
> interests and somehow arranged for me to take much of it home as surplus
> equipment.  Kept me in 7400-series parts and Augat wire-wrap boards for a
> long time.  While there was no way that I could have kept the thing, I wish
> that I had the magnetic drum memory because it was so cool from an industrial
> art perspective.
> 
> Heinz may remember more about this than I do because he actually worked on
> this project, but our department developed what I believe was the first
> all-digital telephone exchange that used digital filtering (Hal Alles and
> Jim Kaiser were in the group).  I think that it had a pair of PDP-11/10s
> in it, and a bigger PDP-11 as a supervisory machine that ran UNIX.  I have
> vague memories of Heinz and Carl poring over huge C program listings.  I
> also remember that there was a bug in the long-distance code where it wasn't
> sending out the ST tone that ended up taking all of the key pulse senders in
> the Berkeley Heights telephone exchange that provided the trunk line to our
> lab off line as they didn't have timeouts and needed to be manually reset.
> But hey, we were the phone company too so what could they do about it?
> 
> Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s
> but those turned out to be useless because of the way that DEC did the DRAM
> refresh; it wasn't interleaved, they just stopped everything every so many
> ms and refreshed everything.  Non-starter for real-time systems.
> 
> And another thought, this machine may have been why Heinz wrote MERT.
> 
> I was gone before this system was completed so I have no idea how it fared
> and how many of the ideas were incorporated into production systems.  Oh,
> yeah, I think that it was called the SS1 for Slave Switch 1.
> 
> Jon

From jfoust at threedee.com  Wed Jan 15 22:29:32 2020
From: jfoust at threedee.com (John Foust)
Date: Wed, 15 Jan 2020 06:29:32 -0600
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
 <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
Message-ID: <20200115132428.EDF319B898@minnie.tuhs.org>

At 12:34 AM 1/15/2020, Earl Baugh wrote:
>Why not build a variation of this with an Arduino?
> <https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/>https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. You could use cardboard rather than wood if it’s just a one time job. ( or scan the tape into files and process digitally ?) 

We're so close, I wish someone would figure out a way to let
a contemporary office scanner like the Fujitsu ScanSnap to
handle paper tapes.  Reliable feed mechanism, nice scanner,
just needs a little software and maybe a guide.  And a way
to re-spool the tape.  Darn, just got complicated.  

Same thing for a new way to read a magtape.  You'd think it 
could be done with a universal read head and some software.

Nine years ago I visited <http://www.comco-inc.com/>http://www.comco-inc.com/ , perhaps
one of the last sellers and refurbishers of 9-tracks.  I dropped
off three 9-tracks I didn't need.  He seems to be surviving 
because oil survey companies still call and are willing to 
write five-figure checks for particular working hardware.

- John


From clemc at ccc.com  Thu Jan 16 00:50:02 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 15 Jan 2020 09:50:02 -0500
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
 <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
 <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>
Message-ID: <CAC20D2M5-Pfxr9VSQ=0AtyYX5x-NEUWzPOC-ZYeSs7AGGw3-fw@mail.gmail.com>

On Wed, Jan 15, 2020 at 2:12 AM Jon Steinhart <jon at fourwinds.com> wrote:

> we tried to use LSI-11s
> but those turned out to be useless because of the way that DEC did the DRAM
> refresh; it wasn't interleaved, they just stopped everything every so many
> ms and refreshed everything.  Non-starter for real-time systems.
>
Be careful as to who you denigrate, my friend. 😂

Very interesting history, IMO.    Yes, DEC sold the LSI-11, but Western
Digital designed it.  DEC (KO specifically) had just put Ray Ball and Ken
O'humundro's CalData out of business for cloning the PDP-11/45 with a
Unibus on his Caldata 500
<http://www.bitsavers.org/pdf/calData/CalData_Brochures_1974.pdf>.   At the
time, WD had developed and started to sell to the systems manufacturers a
new set of bit-slice chips the MCP-1600
<https://en.wikipedia.org/wiki/MCP-1600>, to compete with AMD's 2900 and
Intel 3000 series (plus they were already a chip supplier to DEC for UARTS).
   So WD designs and builds a few LSI-11 as a sales demo of what you could
do with their new bit-slice chip (*i.e. *as those things often go, the
board, bus, and memory was a quick and cheap hack).

It's important to note that the way DEC nailed CalData was the *same
instruction set on the same bus*, WD did their own bus for their demo.
Also, please remember that at the time, WD was in the chip business.   KO's
reaction this time was different.  Instead of suing, DEC got the design and
started to build and sell them.   WD took the board design, wrote a new set
of microcode based on the USCD Pascal-P machine
<https://en.wikipedia.org/wiki/UCSD_Pascal>, then sold that as a 'system'
called the Pascal MicroEngine
<https://en.wikipedia.org/wiki/Pascal_MicroEngine>, but primarily used it
is the sales demo.

I remember seeing one of the WD Pascal-P systems once when we were at Tek
(along with my favorite named workstation, the Modula based Lilith
<https://en.wikipedia.org/wiki/Lilith_(computer)>).  But I do not think the
Pascal-P (nor Lilith) was very successful.   Also, AMD ultimately won the
bit-slice chip business, as most designers at manufacturers like DEC,
Masscomp, FPS, *et al*. designed their new systems or at least the FP/AP
coprocessors with the 2900 series.

BTW: this is also why a few years later when Ken O'Humundro created another
full computer board with a 68000 on it with his new Able  Computer Corp, he
put it on the QBUS which DEC could not lock up because they did not create
it as WD had.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200115/968bdae7/attachment.html>

From paul.winalski at gmail.com  Thu Jan 16 02:41:06 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 15 Jan 2020 11:41:06 -0500
Subject: [TUHS] two AIX items [was Re: History of symbol preemption
In-Reply-To: <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
References: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>
 <e7f59486-228b-54b6-2b20-1df152441476@technologists.com>
Message-ID: <CABH=_VTAhJ2ik0SwZM_JT4qmgqzkNGOg2budVgpe13eWFASL3w@mail.gmail.com>

On 1/14/20, Charles H Sauer <sauer at technologists.com> wrote:
>
> As far as I know, AIX has never used ELF.

You're right.  My mistake.

-Paul W.

From jnc at mercury.lcs.mit.edu  Thu Jan 16 02:46:47 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 15 Jan 2020 11:46:47 -0500 (EST)
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
Message-ID: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu>

    > From: Clem Cole

    > So WD designs and builds a few LSI-11 as a sales demo of what you could
    > do
    > ...
    > he put it on the QBUS which DEC could not lock up because they did not
    > create it as WD had.

Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to the
QBUS between the original demo WD boards and the first DEC ones? Are there any
documents about the WD original still extant, do you know?

(FWIW, it seems that whoever did the QBUS interrupt cycle had heard about the
metastability issues when using a flop to do the grant-passing arbitrations;
see here for more:

  https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS#QBUS_Interrupts

DEC had previously bent themselves into knots trying to solve it on the UNIBUS:

  https://gunkies.org/wiki/M782_Interrupt_Control#Revisions

so it would be interesting to know if it was WD or DEC who did the DIN thing to
get rid of it on the QBUS.)

    Noel

From clemc at ccc.com  Thu Jan 16 04:35:48 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 15 Jan 2020 13:35:48 -0500
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu>
References: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NCCHvo_wjtguVrfd4om3ZeV1kA-eekVhBYrFLp9fuViw@mail.gmail.com>

On Wed, Jan 15, 2020 at 11:47 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to
> the
> QBUS between the original demo WD boards and the first DEC ones?

I can not say I know and I would suspect they peed on it in some manner,
that *was the DEC culture*.  I've just sent a note to Mr. BI to see if he
knows and I'll pass back anything I learn if I do.  Sounds like the sort of
thing they might have gotten changed before it was release.




> Are there any documents about the WD original still extant, do you know?
>
I'm pretty sure we had some stuff from WD at CMU, because CM* was made out
of a lot of them, and CMU did custom microcode so they could talk to the
capabilities and K.map HW.  I remember seeing some prints with WD markings
on it, but I was not heavily involved other than working the new
distributed front-end which we did with LSI-11s.

Somebody from the CMU HW lab like Jim Teter might know, although he did the
11/40e for C.mmp, I'm not sure who was the microcode guru on CM*  as that
was all happening as I was leaving.  I sent a couple of emails to folks
like Danny Klein, Mike Liebensberger, and Tron McConnell. Danny and Mike
are SW folks, Tron was a EE/HW type but mostly worked on other stuff at
Mellon Institute in those days.    But, IIRC, Tron was worked on a 3Mbit
Xerox board for the LSIs, so he might have had something.   We all did some
stuff with CM* (Mike more than any of us). FWIW: Tron was (is) a bit of
packrat and if he ever had anything like that, he might still have it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200115/dcd97e35/attachment.html>

From aek at bitsavers.org  Thu Jan 16 09:32:10 2020
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 15 Jan 2020 15:32:10 -0800
Subject: [TUHS] Spacewar at Bell Labs
In-Reply-To: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com>
References: <7wmuaqju3u.fsf@junk.nocrew.org>
 <202001141659.00EGxBTs1036759@darkstar.fourwinds.com>
 <7wsgkihsdh.fsf@junk.nocrew.org>
 <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com>
Message-ID: <a8c23ab5-74fc-4d1c-072d-2cfcab74d13f@bitsavers.org>



On 1/14/20 9:19 AM, Jon Steinhart wrote:
> Does anybody know if the
> Computer History Museum or equivalent has a DEC paper tape reader that
> works?

It does in my lab at CHM Fremont.
You near by?



From aek at bitsavers.org  Thu Jan 16 09:40:24 2020
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 15 Jan 2020 15:40:24 -0800
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <CAC20D2M5-Pfxr9VSQ=0AtyYX5x-NEUWzPOC-ZYeSs7AGGw3-fw@mail.gmail.com>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
 <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
 <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com>
 <CAC20D2M5-Pfxr9VSQ=0AtyYX5x-NEUWzPOC-ZYeSs7AGGw3-fw@mail.gmail.com>
Message-ID: <39a1b5b7-f256-a6fa-c1e4-4630689d9703@bitsavers.org>



On 1/15/20 6:50 AM, Clem Cole wrote:
> WD took the board design, wrote a
> new set of microcode based on the USCD Pascal-P machine <https://en.wikipedia.org/wiki/UCSD_Pascal>, then sold that as a
> 'system' called the Pascal MicroEngine <https://en.wikipedia.org/wiki/Pascal_MicroEngine>, but primarily used it is the
> sales demo.

And Volition Systems, took the P-System chip set and put it on the QBus, later put Modula-2 on it.




From imp at bsdimp.com  Thu Jan 16 10:17:00 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 15 Jan 2020 17:17:00 -0700
Subject: [TUHS] MUNIX Sources
Message-ID: <CANCZdfqtJkXv5b3ZW574jrsPLgp4eXJD8Ghf_OpjzPG8Uf=oww@mail.gmail.com>

Greetings,

I've so far been unable to locate a copy of munix. This is John Hawley's
dual PDP-11/50 version of Unix he wrote for his PHd Thesis in June 1975 at
the Naval Postgraduate School in Monterey, CA.

I don't suppose that any known copies of this exist? To date, my searches
have turned up goose-eggs.

Hawley's paper can be found here https://calhoun.nps.edu/handle/10945/20959

Warner

P.S. I'm doing another early history talk at FOSDEM in a couple of weeks.
So if you're in the audience, no spoilers please :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200115/7d8c8b95/attachment.html>

From aek at bitsavers.org  Thu Jan 16 10:17:44 2020
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 15 Jan 2020 16:17:44 -0800
Subject: [TUHS] tape reading (was Re:  Spacewar at Bell Labs)
In-Reply-To: <20200115132428.EDF319B898@minnie.tuhs.org>
References: <7wsgkhgs5l.fsf@junk.nocrew.org>
 <ADAE525A-E250-465A-BA9D-C3288239D69D@gmail.com>
 <20200115132428.EDF319B898@minnie.tuhs.org>
Message-ID: <8ba0abdf-fefe-5494-785f-c0bcd020bdc9@bitsavers.org>



On 1/15/20 4:29 AM, John Foust wrote:

> Same thing for a new way to read a magtape.  You'd think it 
> could be done with a universal read head and some software.

It's been done. You need a good transport that has enough torque to deal with
sticky tapes and a digitizer with about 100gigs of ram if you're doing acquisition
with a Saleae Logic16 USB3 analyzer.

https://github.com/LenShustek/readtape

The setup is a couple thousand dollars.



From rdm at cfcl.com  Thu Jan 16 14:27:07 2020
From: rdm at cfcl.com (Rich Morin)
Date: Wed, 15 Jan 2020 20:27:07 -0800
Subject: [TUHS] free dead trees, to the best possible home
Message-ID: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com>

TL; DR.  I'm trying to find the best possible home for some dead trees.

I have about a foot-high stack of manilla folders containing "early Unix papers".  They have been boxed up for a few decades, but appear to be in perfect condition.  I inherited this collection from Jim Joyce, who taught the first Unix course at UC Berkeley and went on to run a series of ventures in Unix-related bookselling, instruction, publishing, etc.

The collection has been boxed up for a few decades, but appears to be in perfect condition.  I don't think it has much financial value, but I suspect that some of the papers may have historical significance.  Indeed, some of them may not be available in any other form, so they definitely should be scanned in and republished.

I also have a variety of newer materials, including full sets of BSD manuals, SunExpert and Unix Review issues, along with a lot of books and course handouts and maybe a SUGtape or two.  I'd like to donate these materials to an institution that will take care of them, make them available to interested parties, etc.  Here are some suggested recipients:

- The Computer History Museum (Mountain View, CA, USA)
- The Internet Archive (San Francisco, CA, USA)
- The Living Computers Museum (Seattle, WA, USA)
- The UC Berkeley Library (Berkeley, CA, USA)
- The Unix Heritage Association (Australia?) 
- The USENIX Association (Berkeley, CA, USA)

According to Warren Toomey, TUHS probably isn't the best possibility.  The Good News about most of the others is that I can get materials to them in the back of my car.  However, I may be overlooking some better possibility, so I am following Warren's suggestion and asking here.  I'm open to any suggestions that have a convincing rationale.

Now, open for suggestions (ducks)...

-r


From rdm at cfcl.com  Thu Jan 16 14:26:57 2020
From: rdm at cfcl.com (Rich Morin)
Date: Wed, 15 Jan 2020 20:26:57 -0800
Subject: [TUHS] introduction and sales pitch...
Message-ID: <633DAB15-0F13-425E-9600-1125308C9E6A@cfcl.com>

I just found out about TUHS today; I plan to skim the archives RSN to get some context.  Meanwhile, this note is a somewhat long-winded introduction, followed by a (non-monetary) sales pitch.  I think some of the introduction may be interesting and/or relevant to the pitch, but YMMV...

Introduction

In 1970, I was introduced to programming by a cabal of social science professors at SF State College.  They had set up a lab space with a few IBM 2741 (I/O Selectric) terminals, connected by dedicated lines to Stanford's Wylbur system.  I managed to wangle a spot as a student assistant and never looked back.  I also played a tiny bit with a PDP-12 in a bio lab and ran one (1) program on SFSC's "production system", an IBM 1620 Mark II (yep; it's a computer...).

While a student, I actually got paid to work with a CDC 3150, a DEC PDP-15, and (once) on an IBM 360/30.  After that, I had some Real Jobs: assembler on a Varian 620i and a PDP-11, COBOL on an IBM mainframe, Fortran on assorted CDC and assorted DEC machines, etc.

By the late 80's, my personal computers were a pair of aging LSI-11's, running RT-11.  At work (Naval Research Lab, in DC), I was mostly using TOPS-10 and Vax/VMS.  I wanted to upgrade my home system and knew that I wanted all the cool stuff: a bit-mapped screen, multiprocessing, virtual memory, etc.

There was no way I could afford to buy this sort of setup from DEC, but my friend Jim Joyce had been telling me about Unix for a few years, so I attended the Boston USENIX in 1982 (sharing a cheap hotel room with Dick Karpinski :-) and wandered around looking at the workstation offerings.  I made a bet on Sun (buying stock would have been far more lucrative, but also more risky and less fun) and ended up buying Sun #285 from John Gage.

At one point, John was wandering around Sun, asking for a slogan that Sun could use on a conference button to indicate how they differed from the competition.  I suggested "The Joy of Unix", which he immediately adopted.  This decision wasn't totally appreciated by some USENIX attendees from Murray Hill, who printed up (using troff, one presumes) and wore individualized paper badges proclaiming themselves as "The <whatever> of Unix".  Imitation is the sincerest form of flattery... (bows)

IIRC, I received my Sun-1 late in a week (of course :-), but managed to set it up with fairly little pain.  I got some help on the weekend from someone named Bill, who happened to be in the office on the weekend ... seemed quite competent ... I ran for a position on the Sun User Group board, saying that I would try to protect the interests of the "smaller" users.  I think I was able to do some good in that position, not least because I was able to get John Gilmore and the Sun lawyers to agree on a legal notice, edit some SUGtapes, etc.

Later on, I morphed this effort into Prime Time Freeware, which produced book/CD collections of what is now called Open Source software.  Back when there were trade magazines, I also wrote a few hundred articles for Unix Review, SunExpert, etc.  Of course, I continue to play (happily) with computers...

Perkify

If you waded through all of that introduction, you'll have figured out that I'm a big fan of making libre software more available, usable, etc.  This actually leads into Perkify, one of my current projects.  Perkify is (at heart) a blind-friendly virtual machine, based on Ubuntu, Vagrant, and VirtualBox.  As you might expect, it has a strong emphasis on text-based programs, which Unix (and Linux) have in large quantities.

However, Perkify's charter has expanded quite a bit.  At some point, I realized that (within limits) there was very little point to worrying about how big the Vagrant "box" became.  After all, a couple of dozen GB of storage is no longer an issue, and having a big VM on the disk (or even running) doesn't slow anything down.  So, the current distro weighs in at about 10 GB and 4,000 or so APT packages (mostly brought in as dependencies or recommendations).  Think of it as "a well-equipped workshop, just down the hall".  For details, see:

- http://pa.cfcl.com/item?key=Areas/Content/Overviews/Perkify_Intro/main.toml
- http://pa.cfcl.com/item?key=Areas/Content/Overviews/Perkify_Index/main.toml

Sales Pitch

I note that assorted folks on this list are trying to dig up copies of Ken's Space Travel program.  Amusingly, I was making the same search just the other day.  However, finding software that can be made to run on Ubuntu is only part of the challenge I face; I also need to come up APT (or whatever) packages that Just Work when I add them to the distribution.

So, here's the pitch.  Help me (and others) to create packages for use in Perkify and other Debian-derived distros.  The result will be software that has reliable repos, distribution, etc.  It may also help the code to live on after you and I are no longer able (or simply interested enough) to keep it going.

-r


From imp at bsdimp.com  Fri Jan 17 06:52:00 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 16 Jan 2020 13:52:00 -0700
Subject: [TUHS] History of TUHS
Message-ID: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>

Is there a history of TUHS page I've missed?

When was it formed? Was it an outgrowth of PUPS? etc.

Again, I'm working on a talk and would like to include some of this
information and it made me think that the history of the historians should
be documented too.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200116/c2fc3d6d/attachment.html>

From wkt at tuhs.org  Fri Jan 17 08:01:21 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 17 Jan 2020 08:01:21 +1000
Subject: [TUHS] History of TUHS
In-Reply-To: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>
References: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>
Message-ID: <20200116220121.GA29855@minnie.tuhs.org>

On Thu, Jan 16, 2020 at 01:52:00PM -0700, Warner Losh wrote:
>    Is there a history of TUHS page I've missed?
>    When was it formed? Was it an outgrowth of PUPS? etc.
>    Again, I'm working on a talk and would like to include some of this
>    information and it made me think that the history of the historians
>    should be documented too.
>    Warner

Heh, I hadn't thought that TUHS itself should now be considered historical,
but I guess 25 years in the IT industry is a long time. A while back I
wrote an answer to this question here:

https://minnie.tuhs.org/Blog/2015_12_14_why_start_tuhs.html

I started the PDP-11 Unix Preservation Society mailing list around
October 1995. Eventually I realised that there needed to be a forum/group
with a wider remit, so I started a separate TUHS list in 2000. Some time
after that, the two lists got merged to be the single TUHS list.

Let me know if you have other questions.

Cheers, Warren

From rdm at cfcl.com  Fri Jan 17 12:44:41 2020
From: rdm at cfcl.com (Rich Morin)
Date: Thu, 16 Jan 2020 18:44:41 -0800
Subject: [TUHS] free dead trees, to the best possible home
In-Reply-To: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com>
References: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com>
Message-ID: <FE460A73-56A4-4145-9CA4-995803A7ED68@cfcl.com>

I received several recommendations for the Living Computers Museum, including some from folks on this list.  Based on this, I contacted Stephen Jones and am now working with him to tie down the details.  Thanks to all who responded; you guys rock!

Because no good deed goes unpunished, I may be asking some of you for autographs on things you wrote.  (I asked Stephen if this would be useful to them; no response as yet).  Also, if you have some detritus that you've been meaning to give away to a good home, this might be a good way to make it happen.  Let me know if you want to get involved...

-r


From gtaylor at tnetconsulting.net  Fri Jan 17 13:48:34 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 16 Jan 2020 20:48:34 -0700
Subject: [TUHS] History of TUHS
In-Reply-To: <20200116220121.GA29855@minnie.tuhs.org>
References: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>
 <20200116220121.GA29855@minnie.tuhs.org>
Message-ID: <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net>

On 1/16/20 3:01 PM, Warren Toomey wrote:
> Let me know if you have other questions.

Is it worth mentioning COFF anywhere in there?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200116/4203748c/attachment.bin>

From lars at nocrew.org  Fri Jan 17 15:46:18 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 17 Jan 2020 05:46:18 +0000
Subject: [TUHS] History of TUHS
In-Reply-To: <20200116220121.GA29855@minnie.tuhs.org> (Warren Toomey's message
 of "Fri, 17 Jan 2020 08:01:21 +1000")
References: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>
 <20200116220121.GA29855@minnie.tuhs.org>
Message-ID: <7wzhembpp1.fsf@junk.nocrew.org>

Warren Toomey wrote:
> Heh, I hadn't thought that TUHS itself should now be considered
> historical

I often imagine future historians 100 years from now pouring over
mailing list archives and bitrotted GitHub repositories, including those
that contain historical research.  Metahistory maybe?

Hello people in the future!  How's the singularity treating you?
Sorry about the climate.

From wkt at tuhs.org  Fri Jan 17 16:51:49 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 17 Jan 2020 16:51:49 +1000
Subject: [TUHS] History of TUHS
In-Reply-To: <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net>
References: <CANCZdfqR0FMJkgaamu6d4i8fvEsauDNQh-+MpBT6d=PFRLK78w@mail.gmail.com>
 <20200116220121.GA29855@minnie.tuhs.org>
 <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net>
Message-ID: <20200117065149.GA4002@minnie.tuhs.org>

On Thu, Jan 16, 2020 at 08:48:34PM -0700, Grant Taylor via TUHS wrote:
> Is it worth mentioning COFF anywhere in there?

Hmm, I'm not sure. Based on the mailing list archive at
https://minnie.tuhs.org/pipermail/coff/, I set it up in
July 2018 so that us old farts can talk about old computers
when the topic was not strictly Unix-related.

Cheers, Warren

From jsteve at superglobalmegacorp.com  Fri Jan 17 20:23:22 2020
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 17 Jan 2020 10:23:22 +0000 (UTC)
Subject: [TUHS] History of TUHS
Message-ID: <25E62EB5E090E7CB.28844bdc-bd25-4a29-96a2-8db35ec8a453@mail.outlook.com>

Of all those CSV repositories, geocities sites and yahoo groups are any indicator, it's going to be up to people to put the past onto plastic and get it out there. 
If anything right now the utzoo archives along with people posting source and patches to usenet survived... 
Not to mention all those shovel ware CD-ROMs from the 90s that ironically preserved so much early free software and other gems of the pre Linux/NT world. 
Github will eventually be shuttered like anything else and all that will remain is dead links..  It really needs to be distributed by nature, but then you have people using Github as cloud storage of all things. 
I don't think the CSRG CD's were hot sellers, and I couldn't imagine getting utzoo or TUHS pressed... Although maybe it's something to look at. 
It might be interesting. From: TUHS <tuhs-bounces at minnie.tuhs.org> on behalf of Lars Brinkhoff <lars at nocrew.org>
Sent: Friday, January 17, 2020, 2:47 p.m.
To: Warren Toomey
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] History of TUHS

Warren Toomey wrote:
> Heh, I hadn't thought that TUHS itself should now be considered
> historical

I often imagine future historians 100 years from now pouring over
mailing list archives and bitrotted GitHub repositories, including those
that contain historical research.  Metahistory maybe?

Hello people in the future!  How's the singularity treating you?
Sorry about the climate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/4b9db558/attachment.html>

From doug at cs.dartmouth.edu  Sat Jan 18 00:31:03 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 17 Jan 2020 09:31:03 -0500
Subject: [TUHS] Lions book
Message-ID: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>

I learned from Marianne Lions that she's still receiving
royalties from John's book. What a testimonial to both
John and the system!

Doug

From clemc at ccc.com  Sat Jan 18 00:50:24 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 17 Jan 2020 09:50:24 -0500
Subject: [TUHS] Lions book
In-Reply-To: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>

Indeed!!


FWIW I continue recommend it young hackers to read/examine/study before
they try to open something like the current Linux kernel.  The MIT xv6 work
 to put it on an Intel Architecture just adds to the value.

As the recent thread/argument on the merits/demerits of the use/abuse of
the preprocessor shows - simple and straightforward is easier to understand
regardless of the arguments wrt how helpful the macros can be.

6th Edition is clear and if you want to understand what it takes and how it
works, John's commentary it difficult to be.

On Fri, Jan 17, 2020 at 9:32 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> I learned from Marianne Lions that she's still receiving
> royalties from John's book. What a testimonial to both
> John and the system!
>
> Doug
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/bb6a435a/attachment.html>

From lm at mcvoy.com  Sat Jan 18 01:23:34 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 17 Jan 2020 07:23:34 -0800
Subject: [TUHS] Lions book
In-Reply-To: <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
Message-ID: <20200117152334.GJ28686@mcvoy.com>

On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote:
> 6th Edition is clear and if you want to understand what it takes and how it
> works, John's commentary it difficult to beat.

It's a good starting point but it's pretty outdated.  I like to go on and
on about how much I love the SunOS 4.x kernel but it is outdated as well.

I wish there was a v6/SunOS like kernel that was as clean but had good
support for SMP and NUMA and TCP offload (and probably a long list of
other useful stuff I've forgotten).

Teaching kids how a single threaded kernel works is cool but it's
also misleading, the world has gotten a lot more complex.  And while
the kernels of decades ago were clean and simple, I don't know of
a kernel to point people to that has the clean code that SunOS had.
Solaris isn't it, though it has some bright spots.  Linux is meh, it's
better than nothing by a lot but I would not point to it as "read this,
kid, you'll see the architecture".  It's not clear there is a good
answer.

From jpl.jpl at gmail.com  Sat Jan 18 01:24:57 2020
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Fri, 17 Jan 2020 10:24:57 -0500
Subject: [TUHS] Lions book
In-Reply-To: <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
Message-ID: <CAC0cEp-M9oWTTp+nkRf+EVAWJaDFL6D_1fRZNsppa_=zmBc8ew@mail.gmail.com>

I heard from her as well. So far, no immediate fire danger where she lives
in Australia, but her garden (which may be Australian for lawn) is dying
because of water restrictions.

On Fri, Jan 17, 2020 at 9:52 AM Clem Cole <clemc at ccc.com> wrote:

> Indeed!!
>
>
> FWIW I continue recommend it young hackers to read/examine/study before
> they try to open something like the current Linux kernel.  The MIT xv6 work
>  to put it on an Intel Architecture just adds to the value.
>
> As the recent thread/argument on the merits/demerits of the use/abuse of
> the preprocessor shows - simple and straightforward is easier to understand
> regardless of the arguments wrt how helpful the macros can be.
>
> 6th Edition is clear and if you want to understand what it takes and how
> it works, John's commentary it difficult to be.
>
> On Fri, Jan 17, 2020 at 9:32 AM Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
>
>> I learned from Marianne Lions that she's still receiving
>> royalties from John's book. What a testimonial to both
>> John and the system!
>>
>> Doug
>>
> --
> Sent from a handheld expect more typos than usual
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/6b6404a0/attachment.html>

From imp at bsdimp.com  Sat Jan 18 02:00:48 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Jan 2020 09:00:48 -0700
Subject: [TUHS] Lions book
In-Reply-To: <20200117152334.GJ28686@mcvoy.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
 <20200117152334.GJ28686@mcvoy.com>
Message-ID: <CANCZdfq9jZCHyuNfWV1khYpUvuStL6WWFQQH_TJh9mhp7o32ZQ@mail.gmail.com>

On Fri, Jan 17, 2020 at 8:24 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote:
> > 6th Edition is clear and if you want to understand what it takes and how
> it
> > works, John's commentary it difficult to beat.
>
> It's a good starting point but it's pretty outdated.  I like to go on and
> on about how much I love the SunOS 4.x kernel but it is outdated as well.
>
> I wish there was a v6/SunOS like kernel that was as clean but had good
> support for SMP and NUMA and TCP offload (and probably a long list of
> other useful stuff I've forgotten).
>
> Teaching kids how a single threaded kernel works is cool but it's
> also misleading, the world has gotten a lot more complex.  And while
> the kernels of decades ago were clean and simple, I don't know of
> a kernel to point people to that has the clean code that SunOS had.
> Solaris isn't it, though it has some bright spots.  Linux is meh, it's
> better than nothing by a lot but I would not point to it as "read this,
> kid, you'll see the architecture".  It's not clear there is a good
> answer.
>

It's but the first step on the road to understanding. I'd been working on
the FreeBSD kernel for years when I re-read the Lions book. The stark
simplicity of the v6 kernel helped everything suddenly 'click' into place
in the code I was reading in the FreeBSD kernel, even with 30ish years of
changes to the v6 code base that lead to the FreeBSD kernel...

Newer systems are a lot more complicated. And they need to be to get the
full performance out of the system. Yet understanding the basics without
the extra clutter has great value.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/619c3b3a/attachment.html>

From clemc at ccc.com  Sat Jan 18 02:15:01 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 17 Jan 2020 11:15:01 -0500
Subject: [TUHS] Lions book
In-Reply-To: <CANCZdfq9jZCHyuNfWV1khYpUvuStL6WWFQQH_TJh9mhp7o32ZQ@mail.gmail.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
 <20200117152334.GJ28686@mcvoy.com>
 <CANCZdfq9jZCHyuNfWV1khYpUvuStL6WWFQQH_TJh9mhp7o32ZQ@mail.gmail.com>
Message-ID: <CAC20D2NcL1fj0Dst67Rzm1k1qKGWfmGFxsLsh3JAFeF+mgk8nQ@mail.gmail.com>

I completely agree.  Studying and >>learning<< from V6 allows you to
consider the basics of what any good OS, no just a UNIX-like system, has to
do provide simple but complete services.  Examining V6 not most of the
things you find today removes a lot of the noise, like threading, parallel
execution, vm, networking, which are fine topics for later, but Warner is
right - get a solid understanding first.  It also helps to understand what
makes 'UNIX-ness' and why it was different from anything before it came on
the scene.

BTW: It' why I still like Pascal (Delphi) over C or C++ as a first language
(I admit, I'm leaning towards Go these days, but Go lacks a good teaching
text).  This is what I heard Doug saying.   IMO:  Lion's book and the V6,
can be considered 'old' by contemporary standards, but they are still 100%
appropriate and because the book and code is so simple, the teacher and the
student can focus on what really matters (*i.e.* learning to walk carefully
in a directed manner and get to your destination before you are forced to
run with the bulls and avoid getting run over).

On Fri, Jan 17, 2020 at 11:01 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Fri, Jan 17, 2020 at 8:24 AM Larry McVoy <lm at mcvoy.com> wrote:
>
>> On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote:
>> > 6th Edition is clear and if you want to understand what it takes and
>> how it
>> > works, John's commentary it difficult to beat.
>>
>> It's a good starting point but it's pretty outdated.  I like to go on and
>> on about how much I love the SunOS 4.x kernel but it is outdated as well.
>>
>> I wish there was a v6/SunOS like kernel that was as clean but had good
>> support for SMP and NUMA and TCP offload (and probably a long list of
>> other useful stuff I've forgotten).
>>
>> Teaching kids how a single threaded kernel works is cool but it's
>> also misleading, the world has gotten a lot more complex.  And while
>> the kernels of decades ago were clean and simple, I don't know of
>> a kernel to point people to that has the clean code that SunOS had.
>> Solaris isn't it, though it has some bright spots.  Linux is meh, it's
>> better than nothing by a lot but I would not point to it as "read this,
>> kid, you'll see the architecture".  It's not clear there is a good
>> answer.
>>
>
> It's but the first step on the road to understanding. I'd been working on
> the FreeBSD kernel for years when I re-read the Lions book. The stark
> simplicity of the v6 kernel helped everything suddenly 'click' into place
> in the code I was reading in the FreeBSD kernel, even with 30ish years of
> changes to the v6 code base that lead to the FreeBSD kernel...
>
> Newer systems are a lot more complicated. And they need to be to get the
> full performance out of the system. Yet understanding the basics without
> the extra clutter has great value.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/12a0654d/attachment.html>

From arrigo at alchemistowl.org  Sat Jan 18 02:01:47 2020
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Fri, 17 Jan 2020 17:01:47 +0100
Subject: [TUHS] On the origins of Linux - "an academic question"
Message-ID: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>

[I originally asked the following on Twitter which was probably not the smartest idea]

I was recently wondering about the origins of Linux, i.e. Linux Torvalds doing his MSc and deciding to write Linux (the kernel) for the i386 because Minix did not support the i386 properly. While this is perfectly understandable I was trying to understand why, as he was in academia, he did not decide to write a “free X” for a different X. The example I picked was Plan 9, simply because I always liked it but X could be any number of other operating systems which he would have been exposed to in academia. This all started in my mind because I was thinking about my friends who were CompSci university students with me at the time and they were into all sorts of esoteric stuff like Miranda-based operating systems, building a complete interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I guess you could define it as “the usual frivolous MSc projects”) and comparing their choices with Linus’.

The answers I got varied from “the world needed a free Unix and BSD was embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive license” (to the latter my response was that “so did Unix and that’s why Linus built Linux!”) but I don’t feel any of the answers addressed my underlying question as to what was wrong in the exposure to other operating systems which made Unix the choice?

Personally I feel that if we had a distributed OS now instead of Linux we’d be better off with the current architecture of the world so I am sad that "Linux is not Plan 9" which is what prompted the question.

Obviously I am most grateful for being able to boot the Mathematics department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not having to code Fortran 77 in Notepad followed by eventually taking over the department with X-Terminals based on Linux connected to the departmental servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a huge gap.

Arrigo


From imp at bsdimp.com  Sat Jan 18 02:53:52 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Jan 2020 09:53:52 -0700
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
Message-ID: <CANCZdfo1-1y8EQN-Rf3tB1txYvdXaG52gN7RMZhf9Dx3kamoSQ@mail.gmail.com>

On Fri, Jan 17, 2020 at 9:42 AM Arrigo Triulzi <arrigo at alchemistowl.org>
wrote:

> [I originally asked the following on Twitter which was probably not the
> smartest idea]
>
> I was recently wondering about the origins of Linux, i.e. Linux Torvalds
> doing his MSc and deciding to write Linux (the kernel) for the i386 because
> Minix did not support the i386 properly. While this is perfectly
> understandable I was trying to understand why, as he was in academia, he
> did not decide to write a “free X” for a different X. The example I picked
> was Plan 9, simply because I always liked it but X could be any number of
> other operating systems which he would have been exposed to in academia.
> This all started in my mind because I was thinking about my friends who
> were CompSci university students with me at the time and they were into all
> sorts of esoteric stuff like Miranda-based operating systems, building a
> complete interface builder for X11 on SunOS including sparkly mouse
> pointers, etc. (I guess you could define it as “the usual frivolous MSc
> projects”) and comparing their choices with Linus’.
>
> The answers I got varied from “the world needed a free Unix and BSD was
> embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a
> restrictive license” (to the latter my response was that “so did Unix and
> that’s why Linus built Linux!”) but I don’t feel any of the answers
> addressed my underlying question as to what was wrong in the exposure to
> other operating systems which made Unix the choice?
>

The AT&T lawsuit (April 1992) post-dated Linus starting on his work (eg
0.12 released January 1992). He said in an interview once he was unaware
that net/2 was out and could be leveraged to get a working system when he
started. It did give a big boost to Linux at a critical time due to the
huge amount of FUD that it created over BSD's future.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/58e87806/attachment.html>

From arrigo at alchemistowl.org  Sat Jan 18 03:08:03 2020
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Fri, 17 Jan 2020 18:08:03 +0100
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <CANCZdfo1-1y8EQN-Rf3tB1txYvdXaG52gN7RMZhf9Dx3kamoSQ@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <CANCZdfo1-1y8EQN-Rf3tB1txYvdXaG52gN7RMZhf9Dx3kamoSQ@mail.gmail.com>
Message-ID: <407987A1-5591-465B-8A77-0B0FCF98F161@alchemistowl.org>

On 17 Jan 2020, at 17:53, Warner Losh <imp at bsdimp.com> wrote:
> The AT&T lawsuit (April 1992) post-dated Linus starting on his work (eg 0.12 released January 1992). He said in an interview once he was unaware that net/2 was out and could be leveraged to get a working system when he started. It did give a big boost to Linux at a critical time due to the huge amount of FUD that it created over BSD's future.

Well, that plainly removes the AT&T lawsuit argument from the answers list so the remaining question I had about its origins is clearer.



From athornton at gmail.com  Sat Jan 18 03:21:58 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 17 Jan 2020 10:21:58 -0700
Subject: [TUHS] Lions book
In-Reply-To: <20200117152334.GJ28686@mcvoy.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
 <20200117152334.GJ28686@mcvoy.com>
Message-ID: <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com>



> On Jan 17, 2020, at 8:23 AM, Larry McVoy <lm at mcvoy.com> wrote:
>  I don't know of
> a kernel to point people to that has the clean code that SunOS had.

It’s not exactly a kernel and it’s not exacly … well, anyway:

selfie is pretty cool.

http://selfie.cs.uni-salzburg.at/

Adam

From brantley at coraid.com  Sat Jan 18 03:25:15 2020
From: brantley at coraid.com (Brantley Coile)
Date: Fri, 17 Jan 2020 17:25:15 +0000
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
Message-ID: <55A1AC0C-AFAE-43E1-9A51-2992071027FC@coraid.com>

Since I was a close observer and an early adopter of Plan 9, which is still my main development platform, I'll contribute my thoughts on the question.

Plan 9 was still being developed in the time frame that Torvalds was working out Linux. Everyone working in the Unix field wanted a version that was not under AT&T's expensive license. The last one I bought was north of $64K. 

The biggest reason that Plan 9 isn't the current Linux is that the world didn't need a cloud operating system in the early 1990's. They just needed a Unix for which they could get the source.

Plan 9 solves the problem of "How do I make a bunch of machines look like a single system?" If you wanted to mess around with a system in the early 1990's you didn't have a bunch of people and a bunch of systems you needed to make appear as one. You just had a single box. 

So, my Plan 9 remains small. In fact, I've been removing things from it, like local disks, that is contrary to the original vision. (Or set of visions. I remember getting a lot of different answers form everyone involved in 1127 about what it was that they were doing.)

The general question of why Linux emerged and not others didn't is a very hard question that computer historians will be researching for a lot time. It's complex, like all economics.

  Brantley

> On Jan 17, 2020, at 11:01 AM, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
> 
> [I originally asked the following on Twitter which was probably not the smartest idea]
> 
> I was recently wondering about the origins of Linux, i.e. Linux Torvalds doing his MSc and deciding to write Linux (the kernel) for the i386 because Minix did not support the i386 properly. While this is perfectly understandable I was trying to understand why, as he was in academia, he did not decide to write a “free X” for a different X. The example I picked was Plan 9, simply because I always liked it but X could be any number of other operating systems which he would have been exposed to in academia. This all started in my mind because I was thinking about my friends who were CompSci university students with me at the time and they were into all sorts of esoteric stuff like Miranda-based operating systems, building a complete interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I guess you could define it as “the usual frivolous MSc projects”) and comparing their choices with Linus’.
> 
> The answers I got varied from “the world needed a free Unix and BSD was embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive license” (to the latter my response was that “so did Unix and that’s why Linus built Linux!”) but I don’t feel any of the answers addressed my underlying question as to what was wrong in the exposure to other operating systems which made Unix the choice?
> 
> Personally I feel that if we had a distributed OS now instead of Linux we’d be better off with the current architecture of the world so I am sad that "Linux is not Plan 9" which is what prompted the question.
> 
> Obviously I am most grateful for being able to boot the Mathematics department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not having to code Fortran 77 in Notepad followed by eventually taking over the department with X-Terminals based on Linux connected to the departmental servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a huge gap.
> 
> Arrigo
> 


From arno.griffioen at ieee.org  Sat Jan 18 05:59:08 2020
From: arno.griffioen at ieee.org (Arno Griffioen)
Date: Fri, 17 Jan 2020 20:59:08 +0100
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
Message-ID: <20200117195908.GF15253@ancienthardware.org>

On Fri, Jan 17, 2020 at 05:01:47PM +0100, Arrigo Triulzi wrote:
> I was recently wondering about the origins of Linux, i.e. Linux Torvalds 
> doing his MSc and deciding to write Linux (the kernel) for the i386 
> because Minix did not support the i386 properly. 

If I remember correctly from those days as a student, that was not the 
starting point for Linux.

He did not 'decide' to write Linux at the start.. He initially didn't even
decide to write an OS at all.. 

As I recall he actually got an i386 based machine and wanted to explore 
the features of that CPU compared to the 286 and the like. To do that he 
decided to basically write (if I remember right..) an editor that ran 
directly on the hardware and made use of the new i386 features.

But of course that meant he had to do his own filesystem code to read/write
stuff, do some sort of memory management, have some sort of internal
'task' scheduler, etc.

At some point, in hindsight probably crucial, he came to the conclusion that
it was starting to look more like an OS kernel and looked for something
that he could fairly easily run the userland binaries from.

MINIX was the obvious one as a userland 'donor' here. Code AND installation
media were easily available on discs to us in europe at the time, unlike
many of the others out there.

At the time Linus was in Finland and most European universities and colleges
in those days (late 80's start 90's) were very, very wary of any legal 
implications even before all the lawsuits. So as a result anything with a 
big license text on it (even 'kinda free' ones like BSD) were classed as 
'risky' and access kept to a bare minimum.

Add fledgeling internet access that was also highly restricted because the 
telco costs in europe were usually massively higher than in the US, so 
learning about new stuff was harder and then getting it from 'somewhere' 
was often a painful process.

At the time I suspect he just wanted to 'finish' the little i386 
learing project with a 'look what I made!' and move on once he did that.

So chasing after some other, more esoteric OS, just wasn't worth the effort
at the time.

However, once he did publish it the MINIX userland basically became the 
'incubator' for this new little (monolithic! :P ) kernel broke out when 
GCC and slowly the other GNU tools became available so it could self-host.

Somehow Linus at that time found so much fun from getting all these 
patches and code to stick into his funny little kernel and watching it
grow and evolve that he stuck with it and didn't move to other projects.

So all in all.. As I remember it, there was never really a decision to 'make 
this great new OS!'.. It kinda happened with right place, right time, right 
people, etc.

I vaguely remeber that Linus did give such a timeline in an interview once..

								Bye, Arno.

From imp at bsdimp.com  Sat Jan 18 06:06:49 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Jan 2020 13:06:49 -0700
Subject: [TUHS] bitsavers.org down?
Message-ID: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>

I'm trying to grab some stuff from bitsavers.org. It seems to be failing to
lookup name records. I'd send mail directly to Al, but the only address I
have for him at at bitsavers.org :(

Anybody have a better contact or good back-channel to Al?

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/1e2cffd1/attachment-0001.html>

From gregg.drwho8 at gmail.com  Sat Jan 18 07:41:06 2020
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Fri, 17 Jan 2020 16:41:06 -0500
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
Message-ID: <CAC5iaNHn7gBhCubtncF7n+H=8VQ8=K_u74+9oHQQd627FYf2Zg@mail.gmail.com>

Hello!
Sadly I do not, but have you tried any of their mirrors? The one at
http://www.mirrorservice.org/ which is called "The UK Mirror Service"
which is based in Kent (UK) has everything.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Fri, Jan 17, 2020 at 3:11 PM Warner Losh <imp at bsdimp.com> wrote:
>
> I'm trying to grab some stuff from bitsavers.org. It seems to be failing to lookup name records. I'd send mail directly to Al, but the only address I have for him at at bitsavers.org :(
>
> Anybody have a better contact or good back-channel to Al?
>
> Warner

From imp at bsdimp.com  Sat Jan 18 08:02:06 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Jan 2020 15:02:06 -0700
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <CAC5iaNHn7gBhCubtncF7n+H=8VQ8=K_u74+9oHQQd627FYf2Zg@mail.gmail.com>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <CAC5iaNHn7gBhCubtncF7n+H=8VQ8=K_u74+9oHQQd627FYf2Zg@mail.gmail.com>
Message-ID: <CANCZdfoHYC-fFEQURGtiF==DjEAhEVbE1D5Js0fBZujmujqgfA@mail.gmail.com>

On Fri, Jan 17, 2020 at 2:41 PM Gregg Levine <gregg.drwho8 at gmail.com> wrote:

> Hello!
> Sadly I do not, but have you tried any of their mirrors? The one at
> http://www.mirrorservice.org/ which is called "The UK Mirror Service"
> which is based in Kent (UK) has everything.
>

(a) Yes. Those work great.
(b) I texted Al and he's on top of it.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/60c76f6e/attachment.html>

From dave at horsfall.org  Sat Jan 18 08:06:38 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 18 Jan 2020 09:06:38 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <202001080010.0080APtC1678972@darkstar.fourwinds.com>
References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU>
 <20200107023834.GN20269@mcvoy.com>
 <202001071630.007GUrBj030452@freefriends.org>
 <202001080010.0080APtC1678972@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.21.9999.2001180901330.908@aneurin.horsfall.org>

On Tue, 7 Jan 2020, Jon Steinhart wrote:

> Also because that great vi trainer program rogue existed :-)

The story is told of some professor having to learn VI, because EMACS was 
not available.  After a few minutes, he said "Hmmm...  It's just like 
Rogue".

FWIW, I once discovered a bug in the Curses library following an upgrade 
on the Mac: Rogue had stopped working :-)

-- Dave

From andreww591 at gmail.com  Sat Jan 18 09:11:39 2020
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Fri, 17 Jan 2020 16:11:39 -0700
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
Message-ID: <CAD-qYGrEAsOzW=UvODQsvDtS8t8Xe9S0xdO07es1E5atQtmfLA@mail.gmail.com>

On 1/17/20, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
>
> The answers I got varied from “the world needed a free Unix and BSD was
> embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive
> license” (to the latter my response was that “so did Unix and that’s why
> Linus built Linux!”) but I don’t feel any of the answers addressed my
> underlying question as to what was wrong in the exposure to other operating
> systems which made Unix the choice?
>
Linus has always struck me as purely a pragmatist and not idealistic
at all, so I'm not surprised that he wrote a conventional Unix rather
than something more architecturally progressive.

On 1/17/20, Brantley Coile <brantley at coraid.com> wrote:
>
> Plan 9 solves the problem of "How do I make a bunch of machines look like a
> single system?" If you wanted to mess around with a system in the early
> 1990's you didn't have a bunch of people and a bunch of systems you needed
> to make appear as one. You just had a single box.
>
> So, my Plan 9 remains small. In fact, I've been removing things from it,
> like local disks, that is contrary to the original vision. (Or set of
> visions. I remember getting a lot of different answers form everyone
> involved in 1127 about what it was that they were doing.)
>
Wasn't the point of single-system-image clustering originally to allow
building relatively inexpensive systems with more CPUs than could
reasonably be fit into a single machine? Now that all current CPUs
except for some low-end embedded ones are multi-core and fully
programmable GPUs are ubiquitous, I don't think Plan 9/Amoeba-style
SSI is really all that relevant for anything other than HPC. However,
I do think distributed network-transparent sharing of devices and
services along the lines of QNX or Domain/OS is more relevant than
ever.

From robpike at gmail.com  Sat Jan 18 09:20:40 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 18 Jan 2020 10:20:40 +1100
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <CAD-qYGrEAsOzW=UvODQsvDtS8t8Xe9S0xdO07es1E5atQtmfLA@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <CAD-qYGrEAsOzW=UvODQsvDtS8t8Xe9S0xdO07es1E5atQtmfLA@mail.gmail.com>
Message-ID: <CAKzdPgxyoa1vnbdosJXq0BbMY3-N8HXjRKk62VNGbmiR7w1FHw@mail.gmail.com>

Plan 9 is not a "single-system-image cluster".

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/72f504b9/attachment.html>

From rtomek at ceti.pl  Sat Jan 18 09:24:58 2020
From: rtomek at ceti.pl (Tomasz Rola)
Date: Sat, 18 Jan 2020 00:24:58 +0100
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
Message-ID: <20200117232457.GA17503@tau1.ceti.pl>

On Fri, Jan 17, 2020 at 01:06:49PM -0700, Warner Losh wrote:
> I'm trying to grab some stuff from bitsavers.org. It seems to be failing to
> lookup name records. I'd send mail directly to Al, but the only address I
> have for him at at bitsavers.org :(

I could grab the ip from dns (71.91.242.107, apparently) but the route
(from my side of the ocean, at least) goes into the woods and gets
lost there (but the woods are in States, at least). It is being hosted
in same ip pool as classiccmp.org (71.91.242.75) - both by the same
provider AFAICT - and the route to classicmp goes into the woods,
too. At least right now, on my end of cable.

So in short, it looks like somebody dropped their router on the floor?
Hard fridays night, perhaps. Power glitch?

-- 
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 brantley at coraid.com  Sat Jan 18 09:38:05 2020
From: brantley at coraid.com (Brantley Coile)
Date: Fri, 17 Jan 2020 23:38:05 +0000
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgxyoa1vnbdosJXq0BbMY3-N8HXjRKk62VNGbmiR7w1FHw@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <CAD-qYGrEAsOzW=UvODQsvDtS8t8Xe9S0xdO07es1E5atQtmfLA@mail.gmail.com>
 <CAKzdPgxyoa1vnbdosJXq0BbMY3-N8HXjRKk62VNGbmiR7w1FHw@mail.gmail.com>
Message-ID: <DEF66F93-20DD-4CB7-A214-8321FDF3097C@coraid.com>

what he said.

> On Jan 17, 2020, at 6:20 PM, Rob Pike <robpike at gmail.com> wrote:
> 
> Plan 9 is not a "single-system-image cluster".
> 
> -rob
> 


From dave at horsfall.org  Sat Jan 18 09:38:53 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 18 Jan 2020 10:38:53 +1100 (EST)
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2M2Z6tiLXYPkstaxkF3K5ZaB4p9mLcn0C3aw5FAg9_9vg@mail.gmail.com>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <CAC20D2M2Z6tiLXYPkstaxkF3K5ZaB4p9mLcn0C3aw5FAg9_9vg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2001181036400.908@aneurin.horsfall.org>

On Wed, 8 Jan 2020, Clem Cole wrote:

> Although the famous ? error from the original version was annoying.

Was it Ken or Dennis who thought of a car with but a single alarm 
indicator; "the experienced driver will know what it means".

-- Dave

From ryan at boringtranquility.io  Sat Jan 18 10:07:34 2020
From: ryan at boringtranquility.io (Ryan Casalino)
Date: Fri, 17 Jan 2020 16:07:34 -0800
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001181036400.908@aneurin.horsfall.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <CAC20D2M2Z6tiLXYPkstaxkF3K5ZaB4p9mLcn0C3aw5FAg9_9vg@mail.gmail.com>
 <alpine.BSF.2.21.9999.2001181036400.908@aneurin.horsfall.org>
Message-ID: <f04584d3-b3b8-4a21-8943-66a33eb0f480@www.fastmail.com>

On Fri, Jan 17, 2020, at 3:38 PM, Dave Horsfall wrote:
> On Wed, 8 Jan 2020, Clem Cole wrote:
> 
> > Although the famous ? error from the original version was annoying.
> 
> Was it Ken or Dennis who thought of a car with but a single alarm 
> indicator; "the experienced driver will know what it means".
> 
> -- Dave
> 

I actually just started using ed for the first time last week (based on one of your earlier comments, Clem) and I couldn't disagree more. 

? is refreshing in its simplicity. Anyway, back to being a fly on the wall. :) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/7593025d/attachment.html>

From wobblygong at gmail.com  Sat Jan 18 10:23:35 2020
From: wobblygong at gmail.com (Wesley Parish)
Date: Sat, 18 Jan 2020 13:23:35 +1300
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
Message-ID: <CACNPpebCzXGHgtBcCUuNFt_1yVzviTWDA98kfeS5NwQ5ghg3+g@mail.gmail.com>

There's a book called "Just For Fun: The Story of an Accidental
Revolutionary" co-authored by Linus Torvalds and David Diamond that
sets out how he came to write the Linux kernel.

Wesley Parish

On 1/18/20, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
> [I originally asked the following on Twitter which was probably not the
> smartest idea]
>
> I was recently wondering about the origins of Linux, i.e. Linux Torvalds
> doing his MSc and deciding to write Linux (the kernel) for the i386 because
> Minix did not support the i386 properly. While this is perfectly
> understandable I was trying to understand why, as he was in academia, he did
> not decide to write a “free X” for a different X. The example I picked was
> Plan 9, simply because I always liked it but X could be any number of other
> operating systems which he would have been exposed to in academia. This all
> started in my mind because I was thinking about my friends who were CompSci
> university students with me at the time and they were into all sorts of
> esoteric stuff like Miranda-based operating systems, building a complete
> interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I
> guess you could define it as “the usual frivolous MSc projects”) and
> comparing their choices with Linus’.
>
> The answers I got varied from “the world needed a free Unix and BSD was
> embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive
> license” (to the latter my response was that “so did Unix and that’s why
> Linus built Linux!”) but I don’t feel any of the answers addressed my
> underlying question as to what was wrong in the exposure to other operating
> systems which made Unix the choice?
>
> Personally I feel that if we had a distributed OS now instead of Linux we’d
> be better off with the current architecture of the world so I am sad that
> "Linux is not Plan 9" which is what prompted the question.
>
> Obviously I am most grateful for being able to boot the Mathematics
> department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not
> having to code Fortran 77 in Notepad followed by eventually taking over the
> department with X-Terminals based on Linux connected to the departmental
> servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running
> eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a
> huge gap.
>
> Arrigo
>
>

From pnr at planet.nl  Sat Jan 18 10:32:51 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 18 Jan 2020 01:32:51 +0100
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
Message-ID: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>


Rich was kind enough to look through the Joyce papers to see if it contained "CSRG Tech Report 4: Proposals for Unix on the VAX”. It did.

As list regulars will know I’ve been looking for that paper for years as it documents the early ideas for networking and IPC in what was to become 4.2BSD.

It is an intriguing paper that discusses a network API that is imo fairly different from what ended up being in 4.1a and 4.2BSD. It confirms Kirk McKusick’s recollection that the select statement was modelled after the ADA select statement. It also confirms Clem Cole’s recollection that the initial ideas for 4.2BSB were significantly influenced by the ideas of Richard Rashid (Aleph/Accent/Mach).

Besides IPC and networking, it also discusses file systems and a wide array of potential improvements in various other areas.


From imp at bsdimp.com  Sat Jan 18 10:36:46 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Jan 2020 17:36:46 -0700
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
Message-ID: <CANCZdfqv1wVYbEKwbgj0q3CU8Cwvj7xNaar_QU9vgJYEFdNyEg@mail.gmail.com>

On Fri, Jan 17, 2020 at 5:33 PM Paul Ruizendaal <pnr at planet.nl> wrote:

>
> Rich was kind enough to look through the Joyce papers to see if it
> contained "CSRG Tech Report 4: Proposals for Unix on the VAX”. It did.
>
> As list regulars will know I’ve been looking for that paper for years as
> it documents the early ideas for networking and IPC in what was to become
> 4.2BSD.
>
> It is an intriguing paper that discusses a network API that is imo fairly
> different from what ended up being in 4.1a and 4.2BSD. It confirms Kirk
> McKusick’s recollection that the select statement was modelled after the
> ADA select statement. It also confirms Clem Cole’s recollection that the
> initial ideas for 4.2BSB were significantly influenced by the ideas of
> Richard Rashid (Aleph/Accent/Mach).
>
> Besides IPC and networking, it also discusses file systems and a wide
> array of potential improvements in various other areas.
>

Awesome! Is that something that will be scanned in so we can all see it?

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/15feacbd/attachment.html>

From rdm at cfcl.com  Sat Jan 18 10:50:27 2020
From: rdm at cfcl.com (Rich Morin)
Date: Fri, 17 Jan 2020 16:50:27 -0800
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <CANCZdfqv1wVYbEKwbgj0q3CU8Cwvj7xNaar_QU9vgJYEFdNyEg@mail.gmail.com>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <CANCZdfqv1wVYbEKwbgj0q3CU8Cwvj7xNaar_QU9vgJYEFdNyEg@mail.gmail.com>
Message-ID: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com>

> Awesome! Is that something that will be scanned in so we can all see it?

I scanned the paper and then Paul aggregated the scans into a single PDF.
It should be available here:

    http://cfcl.com/private/CSRG_TR_4.pdf

-r


From clemc at ccc.com  Sat Jan 18 11:14:52 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 17 Jan 2020 20:14:52 -0500
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <CANCZdfqv1wVYbEKwbgj0q3CU8Cwvj7xNaar_QU9vgJYEFdNyEg@mail.gmail.com>
 <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com>
Message-ID: <CAC20D2OhFinLQ7rwTRZXa08tX2Y9+MzDiEO4g1cUgN7VV8aRcQ@mail.gmail.com>

Indeed many thanks.

On Fri, Jan 17, 2020 at 7:51 PM Rich Morin <rdm at cfcl.com> wrote:

> > Awesome! Is that something that will be scanned in so we can all see it?
>
> I scanned the paper and then Paul aggregated the scans into a single PDF.
> It should be available here:
>
>     http://cfcl.com/private/CSRG_TR_4.pdf
>
> -r
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/7a58465d/attachment.html>

From mparson at bl.org  Sat Jan 18 11:55:07 2020
From: mparson at bl.org (Michael Parson)
Date: Fri, 17 Jan 2020 19:55:07 -0600 (CST)
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.02.2001101214150.19787@frieza.hoshinet.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <1ippPk-8PE-00@marmaro.de> <c9286ba0-6cfa-b79b-de6b-13c2e793b1f1@gmail.com>
 <CAEoi9W4jG8w7CziNnj-6oRnA=7U5s9V1epoH5HsH2igpUd+zfQ@mail.gmail.com>
 <alpine.BSF.2.02.2001101214150.19787@frieza.hoshinet.org>
Message-ID: <alpine.NEB.2.21.2001171941250.1764@neener.bl.org>

On Fri, 10 Jan 2020, Steve Nickolas wrote:
> On Fri, 10 Jan 2020, Dan Cross wrote:
>> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224 at gmail.com>
>> wrote:
>>
>>> In earlier days, my wife was given email by telnetting to an SGI
>>> system and using elm.  One day, I visited her office as she was
>>> composing a message.  Intrigued, I asked her what the editor
>>> was. She did not know and pointed to her cheat-sheet listing editor
>>> commands.  One was ^X^C to exit-and-send.  She is not a programmer
>>> and I was a bit surprised at their choice.
>>
>>
>> Hmm, I'm actually kind of not. Starting users off with a modal
>> editor (that starts in command mode, no less!) can be surprising for
>> novices; with emacs, at least you can start typing text and, well,
>> see text.
>
> This is one of the reasons I liked E when I first used it: it was
> modal, but it started in edit mode.  (Also you KNEW what mode you were
> in, which I understand isn't always the case with vi, although it
> usually is in the clones iirc?)
>
>> I think that one of the smartest things Marc Crispin ever did was
>> write `pico` to go with `pine`. A simple editor targeted at the
>> novice was really useful for casual and/or new users, particularly as
>> the Internet spread and an account on a Unix system was the default
>> introduction to email etc for so many.
>
> And I still use nano - which is a rewrite of pico.

The 'gnu' version (or maybe just gnu licensed) of pico, cuz there has to
be a 'gnu' licensed of everything :-/

> pico Just Works(R)(TM)(C), and it's not enormous.  nano adds a few things I 
> like, but the UI is the same.  Heck...I still use PINE and am sending this 
> message from it ;)

I used pine for years, now alpine, fingers are as hard wired for moving
around in it as they are for doing things in vi(m).  However, I also
have (al)pine use vi for the message editing. :)

I learned ed a long time ago because I once had some box that would boot
into single-user mode, but not far enough to get any termcap/info stuff
loaded, vi didn't work, ex didn't work, but ed did.  Not too long ago, I
used ed to fix a hosed up passwd file via salt... did something like:

sudo salt some-box cmd.run 'printf "1\n/mparson\ns/foo/bar/\nw\nq\n" | ed /etc/passwd'

I don't remember what exactly was wrong, but it prevented someone from
being able to log in and it wasn't fixable with the 'users' state.
Maybe it was a bad path to root's shell and we couldn't log in on the
console or something.  I've slept since then, lost the details.

The guy watching over my shoulder didn't even know what 'ed' was.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From mparson at bl.org  Sat Jan 18 12:11:19 2020
From: mparson at bl.org (Michael Parson)
Date: Fri, 17 Jan 2020 20:11:19 -0600 (CST)
Subject: [TUHS] screen editors
In-Reply-To: <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
 <202001091721.009HLf2V503811@darkstar.fourwinds.com>
 <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com>
Message-ID: <alpine.NEB.2.21.2001172008360.1764@neener.bl.org>

On Thu, 9 Jan 2020, Bakul Shah wrote:
> On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon at fourwinds.com> wrote:
>>
>> It's for that reason that I hate the addition of multiple windows to vi.  I
>> already have a windowing system on my machine, and that's what I use for windows.
>> To me, the correct thing to do is to open a new desktop window to edit a new file
>> and start a new instance of vi, not to use vi to open another internal window.
>
> The Rand editor made good use of multiple windows. You could set things up so
> that two windows would scroll *in sync*. This is handy e.g. when you are looking
> at two columns or rows that far apart in the same file or in different files and
> too large so you need to scroll.

For your .vimrc:

nmap =f :vsplit<bar>wincmd l<bar>exe "norm! Ljz<c-v><cr>"<cr>:set scb<cr>:wincmd h<cr>:set scb<cr>

Don't remember where I picked that up, but this will give you two vim
windows, showing your file in both, one-screen's worth apart, with
synchronized scolling.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From mparson at bl.org  Sat Jan 18 12:06:09 2020
From: mparson at bl.org (Michael Parson)
Date: Fri, 17 Jan 2020 20:06:09 -0600 (CST)
Subject: [TUHS] screen editors
In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
Message-ID: <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>

On Wed, 8 Jan 2020, Jon Steinhart wrote:

> Clem Cole writes:
>>
>> make a new command, don't break the old one....  maybe offer a way to map
>> the new one over the old -- but don't make it the default.
>> and my lawn was lush and green before the snow came ;-)
>
> Clem, this seems like an unusual position for you to take.  vim is backwards
> compatible with vi (and also ed), so it added to an existing ecosystem.

It's like 99% compatible.  The undo change bothered me a lot, I still
don't really 'get' vim's undo method even having mostly given up on
old vi about 10 years ago.  I'm sure it's better, if I ever got around
to learning it, but I agree with Clem, vim's 'enhanced unlmited undo'
should have moved to a different keybinding.

'vim' also moved the "increment number" command to a new key.

And the one that visually bothered me is 'cw' or 'c<anything>',
immediately removes the text that's going to be replaced.  I liked old
vi's way of leaving it there for you to type over.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From clemc at ccc.com  Sat Jan 18 13:13:45 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 17 Jan 2020 22:13:45 -0500
Subject: [TUHS] screen editors
In-Reply-To: <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
 <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>
Message-ID: <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>

On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson at bl.org> wrote:

> It's like 99% compatible.

Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
"I'll give you partial credit when you can bring be me a female that is
partially pregnant."

To be you are either compatible or not.  I would have been ok to have had
an option that you could turn on that gave you new behavior (but make the
user turn it on thank you).

BTW:  the cX command's behavior I also find annoying visually, but it does
not screw up 30-40 years of programming in my fingers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200117/eb3b0b83/attachment.html>

From g.branden.robinson at gmail.com  Sat Jan 18 13:35:56 2020
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Sat, 18 Jan 2020 14:35:56 +1100
Subject: [TUHS] Lions book
In-Reply-To: <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com>
References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU>
 <CAC20D2Ncjeo5xhC2nGEgAR_KnxytuanGHK-bj3yun7tc1q3-+w@mail.gmail.com>
 <20200117152334.GJ28686@mcvoy.com>
 <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com>
Message-ID: <20200118033553.pcagcabtsebs3m33@localhost.localdomain>

At 2020-01-17T10:21:58-0700, Adam Thornton wrote:
> It’s not exactly a kernel and it’s not exacly … well, anyway:
> 
> selfie is pretty cool.
> 
> http://selfie.cs.uni-salzburg.at/

Oh, heck yeah, it is.  Every bullet point makes my heart go pitter-pat.

:D

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/aca53cf6/attachment.sig>

From tytso at mit.edu  Sat Jan 18 13:50:51 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 17 Jan 2020 22:50:51 -0500
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <20200117195908.GF15253@ancienthardware.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
Message-ID: <20200118035051.GC481935@mit.edu>

On Fri, Jan 17, 2020 at 08:59:08PM +0100, Arno Griffioen wrote:
> If I remember correctly from those days as a student, that was not the 
> starting point for Linux.
> 
> He did not 'decide' to write Linux at the start.. He initially didn't even
> decide to write an OS at all.. 
> 
> As I recall he actually got an i386 based machine and wanted to explore 
> the features of that CPU compared to the 286 and the like. To do that he 
> decided to basically write (if I remember right..) an editor that ran 
> directly on the hardware and made use of the new i386 features.

Not an editor, but rather a terminal emulator, to talk to a modem so
he could connect to the university's computers.

He first started by having two processes, one which would print just
'A' characters, and another that would print 'B', and had a simple
scheduler so they would alternate printing to the screen: "AAAABBBB",
etc., then "ABABABAB", etc.   And from there he wrote the terminal emulator.

What he did after that isn't well recorded; it could have been an
editor, but for a long time he using Minix for editing and compiling
the proto-kernel that would later become Linux.   

> However, once he did publish it the MINIX userland basically became the 
> 'incubator' for this new little (monolithic! :P ) kernel broke out when 
> GCC and slowly the other GNU tools became available so it could self-host.
> 
> Somehow Linus at that time found so much fun from getting all these 
> patches and code to stick into his funny little kernel and watching it
> grow and evolve that he stuck with it and didn't move to other projects.

At the time when Linus announced his creation (not yet named) on
comp.os.minix in August 1991, it was already self-hosting.  And that
happened pretty quickly; he first started working on the project in
June or July.

Around the end of 1991, I had added Job Control (implemented from
POSIX.1 as a the specification), so we could put jobs in the
background.  In 1992 X Windows was ported to Linux.  Networking
support followed shortly thereafter.

> So all in all.. As I remember it, there was never really a decision to 'make 
> this great new OS!'.. It kinda happened with right place, right time, right 
> people, etc.

In the super-early days (late 1991, early 1992), those of us who
worked on it just wanted a "something Unix-like" that we could run at
home (my first computer was a 40 MHz 386 with 16 MB of memory).  This
was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
may have been demonstrating 386BSD in private, I was certainly never
aware of it --- and Linus was publishing new versions every few days
on an ftp site.  We'd send patches, and in less than a week, there'd
be a new release dropped that we could download.

So the argument, "Linus would have never started on Linux if itT
weren't for the AT&T Lawsuit" I don't think fits with the timeline.
Development was very fast paced, and so it was *fun*.  And at least
for me, the lacking of networking during the early days didn't bother
me much, since I didn't have networking at home.  (I didn't have
grounded outlets, either, in my 3 people for $1050/month apartment.
Each leg was 50-60V to ground, and the wiring was cloth wrapped, and
was either steel or aluminum; I never did figured out which....)
Using zmodem over a 2400 bps modem was way more efficient than PPP, so
even once we had networking, I didn't always bring up pppd.  And the
most common way I would download source was using set of 1.44 MB
floppies and a station wagon (literally; I was driving a Corolla wagon).

During those early days, the fact that Linux was more "primitive" than
BSD may have been an advantage, since it sources was small, and
release engineering is simple when you only support one architecture.

The other things I noticed was that because we didn't have the weight
of the Unix/BSD legacy, we were more free to experiment.  Bruce Evans
was working on the serial driver for FreeBSD, and I was working on the
serial driver for Linux, and we had a friendly competition to see who
could get better throughput using the very primitive 8250 and later
16550 UART.  The figure of merit we were using was the CPU overhead of
a C-Kermit file transfer over two RS-232 ports connected via a
loopback cable.  We'd compare notes to see how we could make things
better, me for Linux, and Bruce for FreeBSD, and it was *fun*.
Eventually, it got to the point where I was making changes to the tty
layer to further optimize things, and at that point Bruce reported
that he couldn't do some of the optimizations, since it would have
required changing the TTY layer that had been handed down from the
Gods of Olympus^H^H^H^H^H^H^H^H BSD and so it was nixed by his
colleagues in FreeBSD land.

In contrast, in Linux, people felt free to rip out and replace code if
it would make things better.  Depending on how you count things, the
networking layer in Linux was ripped out and replaced three or four
times in the space of as many years.  Sure, the first version was
pretty crappy, and was barely good enough for simple telnet
connections.  But things got better fast, because people were felt
free to experiment.

My personal belief is that it was this development velocity and
freedom to experiment starting with a super simple base is what caused
Linux to become very popular amongst the those who just wanted to play
with kernel development.  Compare and contrast Linus's willingness to
accept patches from others and his turnaround time to get those
patches into new releases with Bill Jolitz's 386BSD effort --- and I
don't think you need the AT&T lawsuit to explain why Linux took off in
1991-1992.  FreeBSD and NetBSD was started in 1993 because of the
failure of Jolitz to accept patches in a timely fashion.

    	     	  	     	     - Ted

From khm at sciops.net  Sat Jan 18 13:44:27 2020
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 17 Jan 2020 19:44:27 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>
 <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>
Message-ID: <20200118034427.GC70100@wopr>

On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson at bl.org> wrote:
> 
> > It's like 99% compatible.
> 
> Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
> "I'll give you partial credit when you can bring be me a female that is
> partially pregnant."
> 
> To be you are either compatible or not.  I would have been ok to have had
> an option that you could turn on that gave you new behavior (but make the
> user turn it on thank you).
> 
> BTW:  the cX command's behavior I also find annoying visually, but it does
> not screw up 30-40 years of programming in my fingers.

There was a time when, by default, vim started in 'compatible' mode, in
which u didn't ignore u, so you got the toggle-style undo.  Compatible
mode also keeps the ol$ style of c representation, and so forth.  You
can still force this by making a ~/.vimrc file that just contains

set compatible

I don't remember when vim stopped launching in compatible mode by
default, but that was basically when I stopped using it.  I only figured
out how to force it back because it's on all the linux computers I run
into at work.

As I recall, the 'set compatible' command is shorthand to set all the
vi-compatibility flags by default; it is possible to set them
individually as well.  So your proposal is (was?) at least implemented,
if not in a very useful manner.

khm

From grog at lemis.com  Sat Jan 18 14:08:25 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 18 Jan 2020 15:08:25 +1100
Subject: [TUHS] Bruce Evans: RIP
Message-ID: <20200118040825.GA67053@eureka.lemis.com>

Ted Ts'o mentioned Bruce Evans in a reply to "On the origins of
Linux".  I'm really sorry to have to announce that he died last month.
His family is holding a "small farewell gathering" in Sydney in late
February.  To quote his sister Julie Saravanos:

  We would be pleased if you, or any other BSD/computer friend, came

There's no date yet, and I don't think it's appropriate to broadcast
details.  If anybody is interested, please contact Warren or me.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/2b2808fc/attachment.sig>

From grog at lemis.com  Sat Jan 18 14:19:13 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 18 Jan 2020 15:19:13 +1100
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200118035051.GC481935@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
Message-ID: <20200118041913.GB67053@eureka.lemis.com>

On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote:
>
> In the super-early days (late 1991, early 1992), those of us who
> worked on it just wanted a "something Unix-like" that we could run at
> home (my first computer was a 40 MHz 386 with 16 MB of memory).  This
> was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
> may have been demonstrating 386BSD in private, I was certainly never
> aware of it

At the start of this time, Bill was working for BSDI, who were
preparing a commercial product that (in March 1992) became BSD/386.
As Rob Kolstad told me in mid-1992, he had a (to put it mildly)
difference of opinion with Rob, and probably others, about the
commercial nature (at the time BSD/386 cost $1000), and he resigned at
the end of 1991.  So 386BSD presumably didn't exist before that.

On the other hand, Bill did write the articles in Dr. Dobbs Journal,
which started in January 1991, so my best guess is that Linus just
wasn't informed about the developments.  It's easy to forget how
difficult it was to get this kind of information in those days.  I was
informed about the articles, but more by chance than anything else.  I
didn't find out about BSD/386 until March 1992, when the first betas
were released.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/1fb9275b/attachment.sig>

From andreww591 at gmail.com  Sat Jan 18 16:15:11 2020
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Fri, 17 Jan 2020 23:15:11 -0700
Subject: [TUHS] Distributed systems,
 was:  On the origins of Linux - "an academic question"
Message-ID: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>

On 1/17/20, Brantley Coile <brantley at coraid.com> wrote:
> what he said.
>
>> On Jan 17, 2020, at 6:20 PM, Rob Pike <robpike at gmail.com> wrote:
>>
>> Plan 9 is not a "single-system-image cluster".
>>
>> -rob
>>
>
>
I guess SSI isn't the right term for Plan 9 clustering since not
everything is shared, although I would still say it has some aspects
of SSI. I was talking about systems that try to make a cluster look
like a single machine in some way even if they don't share everything
(I'm not sure if there's a better term for such systems besides the
rather vague "distributed" which could mean anything from full SSI to
systems that allow transparent access to services/devices on other
machines without trying to make a cluster look like a single system).

From robpike at gmail.com  Sat Jan 18 16:25:14 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 18 Jan 2020 17:25:14 +1100
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
Message-ID: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>

I am convinced that large-scale modern compute centers would be run very
differently, with fewer or at least lesser problems, if they were treated
as a single system rather than as a bunch of single-user computers ssh'ed
together.

But history had other ideas.

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/f2e984c8/attachment.html>

From andreww591 at gmail.com  Sat Jan 18 17:30:09 2020
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Sat, 18 Jan 2020 00:30:09 -0700
Subject: [TUHS] [TUHS -> COFF] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
Message-ID: <CAD-qYGqDU_ikweP0yWshkarbmrHViSPX63OHKBfqAOpz8iFfTQ@mail.gmail.com>

On 1/17/20, Rob Pike <robpike at gmail.com> wrote:
> I am convinced that large-scale modern compute centers would be run very
> differently, with fewer or at least lesser problems, if they were treated
> as a single system rather than as a bunch of single-user computers ssh'ed
> together.
>
> But history had other ideas.
>
[moving to COFF since this isn't specific to historic Unix]

For applications (or groups of related applications) that are already
distributed across multiple machines I'd say "cluster as a single
system" definitely makes sense, but I still stand by what I said
earlier about it not being relevant for things like workstations, or
for server applications that are run on a single machine. I think
clustering should be an optional subsystem, rather than something that
is deeply integrated into the core of an OS. With an OS that has
enough extensibiity, it should be possible to have an optional
clustering subsystem without making it feel like an afterthought.

That is what I am planning to do in UX/RT, the OS that I am writing.
The "core supervisor" (seL4 microkernel + process server + low-level
system library) will lack any built-in network support and will just
have support for local file servers using microkernel IPC. The network
stack, 9P client filesystem, 9P server, and clustering subsystem will
all be separate regular processes. The 9P server will use regular
read()/write()-like APIs rather than any special hooks (there will be
read()/write()-like APIs that expose the message registers and shared
buffer to make this more efficient), and similarly the 9P client
filesystem will use the normal API for local filesystem servers (which
will also use read()/write() to send messages). The clustering
subsystem will work by intercepting process API calls and forwarding
them to either the local process server or to a remote instance as
appropriate. Since UX/RT will go even further than Plan 9 with its
file-oriented architecture and make process APIs file-oriented, this
will be transparent to applications. Basically, the way that the
file-oriented process API will work is that every process will have a
special "process server connection" file descriptor that carries all
process server API calls over a minimalist form of RPC, and it will be
possible to redirect this to an intermediary at process startup (of
course, this redirection will be inherited by child processes
automatically).

From thomas.paulsen at firemail.de  Sat Jan 18 19:01:25 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Sat, 18 Jan 2020 10:01:25 +0100
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <CANCZdfqv1wVYbEKwbgj0q3CU8Cwvj7xNaar_QU9vgJYEFdNyEg@mail.gmail.com>
 <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com>
Message-ID: <30304771245b987553fb6baccb1d992a@firemail.de>

>I scanned the paper and then Paul aggregated the scans into a single PDF.
>It should be available here:
> http://cfcl.com/private/CSRG_TR_4.pdf
thanks for the link to an really important document!






From elbingmiss at gmail.com  Sat Jan 18 21:55:58 2020
From: elbingmiss at gmail.com (=?UTF-8?Q?=C3=81lvaro_Jurado?=)
Date: Sat, 18 Jan 2020 12:55:58 +0100
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
Message-ID: <CAHJeKDVpxUPodBaTpqDMjWThXh=EUhjqKO1ZhiRHEAQ6qJrFcA@mail.gmail.com>

On Sat, 18 Jan 2020 at 07:26, Rob Pike <robpike at gmail.com> wrote:

> I am convinced that large-scale modern compute centers would be run very
> differently, with fewer or at least lesser problems, if they were treated
> as a single system rather than as a bunch of single-user computers ssh'ed
> together.
>
> But history had other ideas.
>
> -rob
>
>
IBM Watson is not that concept?
I think history (bussiness) tends right now to a decentralized model for
large systems, which is not clear if it’s an advantage for now. Rather than
emulating centralized computing systems across many machines. Anyway, the
main interest for researching about is still keeping the bussiness running.
And for now Unix descendants do it really well.

—
Álvaro Jurado

-- 
Álvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/def9de08/attachment.html>

From mparson at bl.org  Sun Jan 19 00:22:59 2020
From: mparson at bl.org (Michael Parson)
Date: Sat, 18 Jan 2020 08:22:59 -0600 (CST)
Subject: [TUHS] screen editors
In-Reply-To: <c9832fa7-09c0-2c16-bf06-a973094526fe@gmail.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
 <c9832fa7-09c0-2c16-bf06-a973094526fe@gmail.com>
Message-ID: <alpine.NEB.2.21.2001180821290.1764@neener.bl.org>

On Wed, 8 Jan 2020, Nemo Nusquam wrote:
> On 01/08/20 04:46, Rudi Blom wrote:
>> That's a real big vi in RHL. Looking at a few (commercial) unixes I get
>> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
>>   - /usr/bin/vi: iAPX 386 executable
>> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
>>   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
>> sticky executable or object module stripped - version 3.13-14
>> HP-UX 11.31 748996 Aug 28 2009 /bin/vi
>>   -- /bin/vi: ELF-32 executable object file - IA64
>
> Solaris 10 on Ultrasparc 239828
>  /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1, dynamically 
> linked, stripped
>
> Any others?

I've been playing with this for the last few months:

$ uname -a
UNIX_System_V amix 4.0 2.1c 0800430 Amiga (Unlimited) m68k

$ file /usr/bin/vi
/usr/bin/vi:    ELF 32-bit MSB executable M68000 Version 1

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From lm at mcvoy.com  Sun Jan 19 01:25:45 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 18 Jan 2020 07:25:45 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200118041913.GB67053@eureka.lemis.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
Message-ID: <20200118152545.GB28686@mcvoy.com>

On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote:
> On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote:
> >
> > In the super-early days (late 1991, early 1992), those of us who
> > worked on it just wanted a "something Unix-like" that we could run at
> > home (my first computer was a 40 MHz 386 with 16 MB of memory).  This
> > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
> > may have been demonstrating 386BSD in private, I was certainly never
> > aware of it
> 
> At the start of this time, Bill was working for BSDI, who were
> preparing a commercial product that (in March 1992) became BSD/386.

Wikipedia says he was working on 386BSD as early has 1989 and that
clicks with me (Jolitz worked for me around 1992 or 3).  I don't
remember him mentioning working at BSDI, are you sure about that
part?  Those guys did not like each other at all.

From lm at mcvoy.com  Sun Jan 19 01:30:00 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 18 Jan 2020 07:30:00 -0800
Subject: [TUHS] On the origins of Linux - "an academic question"
In-Reply-To: <20200118035051.GC481935@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
Message-ID: <20200118153000.GC28686@mcvoy.com>

On Fri, Jan 17, 2020 at 10:50:51PM -0500, Theodore Y. Ts'o wrote:
+1 to everything Ted said, that's how I remember it as well.  I knew
about both Linux and 386BSD and while 386BSD felt very familiar to
a SunOS guy, there was something special about Linux.  For a while I
played with both, 386BSD was sort of better in that it had networking,
but like Ted, my network was a modem and TCP over a modem wasn't pleasant.
So Linux won out and eventually networked just fine.

> At the time when Linus announced his creation (not yet named) on
> comp.os.minix in August 1991, it was already self-hosting.  And that
> happened pretty quickly; he first started working on the project in
> June or July.
> 
> Around the end of 1991, I had added Job Control (implemented from
> POSIX.1 as a the specification), so we could put jobs in the
> background.  In 1992 X Windows was ported to Linux.  Networking
> support followed shortly thereafter.
> 
> > So all in all.. As I remember it, there was never really a decision to 'make 
> > this great new OS!'.. It kinda happened with right place, right time, right 
> > people, etc.
> 
> In the super-early days (late 1991, early 1992), those of us who
> worked on it just wanted a "something Unix-like" that we could run at
> home (my first computer was a 40 MHz 386 with 16 MB of memory).  This
> was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
> may have been demonstrating 386BSD in private, I was certainly never
> aware of it --- and Linus was publishing new versions every few days
> on an ftp site.  We'd send patches, and in less than a week, there'd
> be a new release dropped that we could download.
> 
> So the argument, "Linus would have never started on Linux if itT
> weren't for the AT&T Lawsuit" I don't think fits with the timeline.
> Development was very fast paced, and so it was *fun*.  And at least
> for me, the lacking of networking during the early days didn't bother
> me much, since I didn't have networking at home.  (I didn't have
> grounded outlets, either, in my 3 people for $1050/month apartment.
> Each leg was 50-60V to ground, and the wiring was cloth wrapped, and
> was either steel or aluminum; I never did figured out which....)
> Using zmodem over a 2400 bps modem was way more efficient than PPP, so
> even once we had networking, I didn't always bring up pppd.  And the
> most common way I would download source was using set of 1.44 MB
> floppies and a station wagon (literally; I was driving a Corolla wagon).
> 
> During those early days, the fact that Linux was more "primitive" than
> BSD may have been an advantage, since it sources was small, and
> release engineering is simple when you only support one architecture.
> 
> The other things I noticed was that because we didn't have the weight
> of the Unix/BSD legacy, we were more free to experiment.  Bruce Evans
> was working on the serial driver for FreeBSD, and I was working on the
> serial driver for Linux, and we had a friendly competition to see who
> could get better throughput using the very primitive 8250 and later
> 16550 UART.  The figure of merit we were using was the CPU overhead of
> a C-Kermit file transfer over two RS-232 ports connected via a
> loopback cable.  We'd compare notes to see how we could make things
> better, me for Linux, and Bruce for FreeBSD, and it was *fun*.
> Eventually, it got to the point where I was making changes to the tty
> layer to further optimize things, and at that point Bruce reported
> that he couldn't do some of the optimizations, since it would have
> required changing the TTY layer that had been handed down from the
> Gods of Olympus^H^H^H^H^H^H^H^H BSD and so it was nixed by his
> colleagues in FreeBSD land.
> 
> In contrast, in Linux, people felt free to rip out and replace code if
> it would make things better.  Depending on how you count things, the
> networking layer in Linux was ripped out and replaced three or four
> times in the space of as many years.  Sure, the first version was
> pretty crappy, and was barely good enough for simple telnet
> connections.  But things got better fast, because people were felt
> free to experiment.
> 
> My personal belief is that it was this development velocity and
> freedom to experiment starting with a super simple base is what caused
> Linux to become very popular amongst the those who just wanted to play
> with kernel development.  Compare and contrast Linus's willingness to
> accept patches from others and his turnaround time to get those
> patches into new releases with Bill Jolitz's 386BSD effort --- and I
> don't think you need the AT&T lawsuit to explain why Linux took off in
> 1991-1992.  FreeBSD and NetBSD was started in 1993 because of the
> failure of Jolitz to accept patches in a timely fashion.
> 
>     	     	  	     	     - Ted

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From jsteve at superglobalmegacorp.com  Sun Jan 19 01:35:40 2020
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Sat, 18 Jan 2020 15:35:40 +0000 (UTC)
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
Message-ID: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com>

I would imagine that the user land changes made its way into 386 Mach.  Although I haven't seen anything I can recall off the top of my head about 386 commits in user land until much later. 
Maybe one day more of that Mt Xinu stuff will surface, although I'm still amazed I got the kernel to build. 
Internet legend is that the rift was massive.  
From: TUHS <tuhs-bounces at minnie.tuhs.org> on behalf of Larry McVoy <lm at mcvoy.com>
Sent: Sunday, January 19, 2020, 12:26 a.m.
To: Greg 'groggy' Lehey
Cc: UNIX Heritage Society
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")

On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote:
> On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote:
> >
> > In the super-early days (late 1991, early 1992), those of us who
> > worked on it just wanted a "something Unix-like" that we could run at
> > home (my first computer was a 40 MHz 386 with 16 MB of memory).  This
> > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
> > may have been demonstrating 386BSD in private, I was certainly never
> > aware of it
> 
> At the start of this time, Bill was working for BSDI, who were
> preparing a commercial product that (in March 1992) became BSD/386.

Wikipedia says he was working on 386BSD as early has 1989 and that
clicks with me (Jolitz worked for me around 1992 or 3).  I don't
remember him mentioning working at BSDI, are you sure about that
part?  Those guys did not like each other at all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/7d998a79/attachment.html>

From lm at mcvoy.com  Sun Jan 19 01:37:25 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 18 Jan 2020 07:37:25 -0800
Subject: [TUHS] screen editors
In-Reply-To: <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>
 <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>
Message-ID: <20200118153725.GD28686@mcvoy.com>

On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson at bl.org> wrote:
> 
> > It's like 99% compatible.
> 
> Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
> "I'll give you partial credit when you can bring be me a female that is
> partially pregnant."
> 
> To be you are either compatible or not.  I would have been ok to have had
> an option that you could turn on that gave you new behavior (but make the
> user turn it on thank you).

It's rare event when I disagree with you, Clem (sometimes it seems like
we were separated at birth :)  If it was compat by default then you
wouldn't learn any of the new stuff.  

set compatible

isn't that hard but we'd have to read docs to find that.  

Anyhoo, cross reference to Ted's thought that Linux didn't have to 
deal with the Gods of BSD so they could rip stuff out and try again,
his point is that worked better than the BSD way.  Compat is fine
but if you want progress, sometimes you break compat.

For me, I've got a .exrc that I've been carrying around for decades
(has maps in it for some compat bindings to an editor I used on CP/M,
it's _that_ old) and vim is perfectly happy with it.

I mostly use vim as a vi compat but I regularly use 2 panes, that's
super useful.  It's progress and you can have compat mode easily,
seems like a win.

From mparson at bl.org  Sun Jan 19 01:45:22 2020
From: mparson at bl.org (Michael Parson)
Date: Sat, 18 Jan 2020 09:45:22 -0600 (CST)
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>

On Mon, 13 Jan 2020, Dan Cross wrote:
> 
> [Resending as this got squashed a few days ago. Jon, sorry for the
> duplicate. Again.]
>
> On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart <jon at fourwinds.com> wrote:

<snip>

>> Many people have claimed, incorrectly in my opinion, that this model
>> fails in the modern era because it only works on text data.  They
>> change the subject when I point out that ImageMagick works on binary
>> data.  And, there are now stream processing utilities for JSON data
>> and such that show that the UNIX model still works IF you understand
>> it and know how to use it.
>
>
> Certainly. I think you hit the nail on the head with the proviso
> that one must _understand_ the Unix model and how to use it. If one
> does so, it's very powerful indeed, and it really is applicable more
> often than not. But it is not a panacea (not that anyone suggested it
> is). As an example, how do I apply an unmodified `grep` to arbitrary
> JSON data (which may span more than one line)? Perhaps there is a way
> (I can imagine a 'record2line' program that consumes a single JSON
> object and emits it as a syntactically valid one-liner...) but I can
> also imagine all sorts of ways that might go wrong.

And here, understanding the model is important, namely, grep is the
wrong tool for searching/parsing JSON output. Dealing with JSON from the
shell, you should use jq.  I've been dragged kicking and screaming into
dealing with JSON, and about all I can say about it is, I like it about
this >< much more than XML. :)

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From lm at mcvoy.com  Sun Jan 19 01:49:48 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 18 Jan 2020 07:49:48 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com>
References: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com>
Message-ID: <20200118154948.GE28686@mcvoy.com>

On Sat, Jan 18, 2020 at 03:35:40PM +0000, Jason Stevens wrote:
> Internet legend is that the rift was massive.????

It was and Jolitz was unfairly crapped on at a Usenix, the one after
the lawsuit.  At the time, everyone thought it was about copyright and
Jolitz told me that there was a lot of code that was unchanged from v7.
He knew that I knew the file system code and he said "Go look at bmap(),
it's byte for byte exactly the same".  He was right and there was other
stuff, it wasn't just one function.

This was after both BSDI and 386BSD were a thing.  At a Usenix conference,
the BSDI guys pissed all over him, put down his efforts on 386BSD,
it was obviously self serving because they wanted a business, but it
wasn't a nice thing to do at all.

Bill thought he had the goods on them for copyright infringement but
he held his tongue and took the abuse because he didn't want to help
the lawsuit.  In his mind, he was a martyr for the cause.

So, yeah, those guys didn't like each other.  I know all of them and
wished they had handled this better.

I heard about all this, I was probably at that Usenix or maybe someone
told me, I don't remember.  I felt bad for Bill and was in a position
where I could hire him, so I did.  He didn't really do anything for me
though we did have some fascinating discussions about the short comings
of C++ and mused about how a language would have to work to truly layer
"correctly".  The context was the SCSI subsystem, it was part replicated
protocol in each driver and part driver specific stuff and we were trying
to imagine a programming language that would let us have the replicated
stuff in one place and plumb in the specific stuff as needed.  Needless to
say, we didn't come up with an answer but it was a fun thought experiment.
He's a sharp guy, quirky, but sharp.

From reed at reedmedia.net  Sun Jan 19 02:19:06 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Sat, 18 Jan 2020 10:19:06 -0600 (CST)
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200118152545.GB28686@mcvoy.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200118152545.GB28686@mcvoy.com>
Message-ID: <alpine.NEB.2.21.2001181010180.50@t1.m.reedmedia.net>

> I don't remember him mentioning working at BSDI, are you sure about 
> that part?

See https://tech-insider.org/unix/research/1992/0319.html
coworkers said:
"Jolitz was one of the founders of Berkeley Software Design, Inc. ...
was a full time employee of BSDI for 11 months of 1991 -- from
January 1, 1991 through November 30, 1991
... a founder of BSDI as well as its first full-time paid employee"

And his wife wrote "Bill did work for UUNET from January to
June of 1991."

Jeremy C. Reed

echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \
 tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy"

From aek at bitsavers.org  Sun Jan 19 04:20:05 2020
From: aek at bitsavers.org (Al Kossow)
Date: Sat, 18 Jan 2020 10:20:05 -0800
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <20200117232457.GA17503@tau1.ceti.pl>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
Message-ID: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>



On 1/17/20 3:24 PM, Tomasz Rola wrote:

> So in short, it looks like somebody dropped their router on the floor?
> Hard fridays night, perhaps. Power glitch?
> 

The entire classiccmp server was lost. The bitsavers data is safe since
I maintain my own copy, and the mirrors should have the image of it before
the crash, which was the whole point of having the site completely static.
If Jay decides not to continue hosting bitsavers, this may be the end
since I can't afford to host the site.


From jon at fourwinds.com  Sun Jan 19 04:45:28 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 18 Jan 2020 10:45:28 -0800
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
Message-ID: <202001181845.00IIjSRE2543512@darkstar.fourwinds.com>

Michael Parson writes:
> On Mon, 13 Jan 2020, Dan Cross wrote:
> > 
> > [Resending as this got squashed a few days ago. Jon, sorry for the
> > duplicate. Again.]
> >
> > On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> <snip>
>
> >> Many people have claimed, incorrectly in my opinion, that this model
> >> fails in the modern era because it only works on text data.  They
> >> change the subject when I point out that ImageMagick works on binary
> >> data.  And, there are now stream processing utilities for JSON data
> >> and such that show that the UNIX model still works IF you understand
> >> it and know how to use it.
> >
> >
> > Certainly. I think you hit the nail on the head with the proviso
> > that one must _understand_ the Unix model and how to use it. If one
> > does so, it's very powerful indeed, and it really is applicable more
> > often than not. But it is not a panacea (not that anyone suggested it
> > is). As an example, how do I apply an unmodified `grep` to arbitrary
> > JSON data (which may span more than one line)? Perhaps there is a way
> > (I can imagine a 'record2line' program that consumes a single JSON
> > object and emits it as a syntactically valid one-liner...) but I can
> > also imagine all sorts of ways that might go wrong.
>
> And here, understanding the model is important, namely, grep is the
> wrong tool for searching/parsing JSON output. Dealing with JSON from the
> shell, you should use jq.  I've been dragged kicking and screaming into
> dealing with JSON, and about all I can say about it is, I like it about
> this >< much more than XML. :)
>
> -- 
> Michael Parson
> Pflugerville, TX
> KF5LGQ

Slight disagreement here.  I would say that grep is *a* a tool for JSON and
that jq is *a better* one.  The UNIX model part of this is that jq is another
tool in a toolbox and plays well with others.  What disturbs me about a lot
of software (and my tractor) it when it does the equivalent of throwing a
random metric bolt into something that's built from SAE hardware.

Jon


From mparson at bl.org  Sun Jan 19 04:59:45 2020
From: mparson at bl.org (Michael Parson)
Date: Sat, 18 Jan 2020 12:59:45 -0600 (CST)
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <202001181845.00IIjSRE2543512@darkstar.fourwinds.com>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
 <202001181845.00IIjSRE2543512@darkstar.fourwinds.com>
Message-ID: <alpine.NEB.2.21.2001181257190.676@neener.bl.org>

On Sat, 18 Jan 2020, Jon Steinhart wrote:
> Michael Parson writes:
>> On Mon, 13 Jan 2020, Dan Cross wrote:
>>>
>>> [Resending as this got squashed a few days ago. Jon, sorry for the
>>> duplicate. Again.]
>>>
>>> On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart <jon at fourwinds.com> wrote:
>>
>> <snip>
>>
>>>> Many people have claimed, incorrectly in my opinion, that this model
>>>> fails in the modern era because it only works on text data.  They
>>>> change the subject when I point out that ImageMagick works on binary
>>>> data.  And, there are now stream processing utilities for JSON data
>>>> and such that show that the UNIX model still works IF you understand
>>>> it and know how to use it.
>>>
>>>
>>> Certainly. I think you hit the nail on the head with the proviso
>>> that one must _understand_ the Unix model and how to use it. If one
>>> does so, it's very powerful indeed, and it really is applicable more
>>> often than not. But it is not a panacea (not that anyone suggested it
>>> is). As an example, how do I apply an unmodified `grep` to arbitrary
>>> JSON data (which may span more than one line)? Perhaps there is a way
>>> (I can imagine a 'record2line' program that consumes a single JSON
>>> object and emits it as a syntactically valid one-liner...) but I can
>>> also imagine all sorts of ways that might go wrong.
>>
>> And here, understanding the model is important, namely, grep is the
>> wrong tool for searching/parsing JSON output. Dealing with JSON from the
>> shell, you should use jq.  I've been dragged kicking and screaming into
>> dealing with JSON, and about all I can say about it is, I like it about
>> this >< much more than XML. :)
>>
>> --
>> Michael Parson
>> Pflugerville, TX
>> KF5LGQ
>
> Slight disagreement here.  I would say that grep is *a* a tool for JSON and
> that jq is *a better* one.

OK, yeah, I'll use grep to find what I'm looking for in the json output,
then fight with^W^Wuse jq to extract the info I'm looking for in the json
output.

> The UNIX model part of this is that jq is another tool in a toolbox
> and plays well with others.  What disturbs me about a lot of software
> (and my tractor) it when it does the equivalent of throwing a random
> metric bolt into something that's built from SAE hardware.
>
> Jon
>

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From rdm at cfcl.com  Sun Jan 19 05:25:18 2020
From: rdm at cfcl.com (Rich Morin)
Date: Sat, 18 Jan 2020 11:25:18 -0800
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
Message-ID: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com>

[ No good deed goes unpunished...  -r ]

> On Jan 18, 2020, at 01:08, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> At the bottom of page 6 TR/4 references TR/3:
> 
> A more complete description of the motivation of the IPC architecture
> described here, measurements of a prototype implementation, comparisons
> with other work and a complete bibliography are given in CSRG TR/3: “An IPC
> Architecture for UNIX”.
> 
> I hesitate to ask, but is the TR/3 report also in Jim’s papers?
> I’m not asking for a scan, just if it is there.

Would this do?  FYI, it's about 50 pages, including a four-page bibliography.

An Architecture for Interprocess Communication in UNIX*
-- DRAFT of June 22, 1981 --
William Joy and Robert Fabry

Paul sez:
> Before yesterday I did not know that TR/3 existed and in my (arguable) view it is even a bigger find than TR/4, as it gives great insight how design trade-offs were perceived back in 1981.

Again, I scanned the paper and then Paul aggregated the scans into a single PDF.
It should be available here:

   http://cfcl.com/private/CSRG_TR_3.pdf

-r


From rdm at cfcl.com  Sun Jan 19 05:27:39 2020
From: rdm at cfcl.com (Rich Morin)
Date: Sat, 18 Jan 2020 11:27:39 -0800
Subject: [TUHS] "What UNIX Cost Us"
Message-ID: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>

FWIW, I found this talk to be quite amusing and interesting.

"What UNIX Cost Us" - Benno Rice (LCA 2020)
https://www.youtube.com/watch?v=9-IWMbJXoLM

-r


From michael at kjorling.se  Sun Jan 19 06:04:39 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 18 Jan 2020 20:04:39 +0000
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
Message-ID: <c3gdqsn7s3msmpvctqhp4733@localhost>

On 18 Jan 2020 10:20 -0800, from aek at bitsavers.org (Al Kossow):
> The bitsavers data is safe since
> I maintain my own copy, and the mirrors should have the image of it before
> the crash, which was the whole point of having the site completely static.
> If Jay decides not to continue hosting bitsavers, this may be the end
> since I can't afford to host the site.

If that does turn out to be the case, might you consider transferring
the data wholesale to, say, the Internet Archive?

Out of curiosity, how much data are we talking about?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From aek at bitsavers.org  Sun Jan 19 06:13:21 2020
From: aek at bitsavers.org (Al Kossow)
Date: Sat, 18 Jan 2020 12:13:21 -0800
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <c3gdqsn7s3msmpvctqhp4733@localhost>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
Message-ID: <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>



On 1/18/20 12:04 PM, Michael Kjörling wrote:

> If that does turn out to be the case, might you consider transferring
> the data wholesale to, say, the Internet Archive?

Jason already takes everything.
We have mutually different goals. I want the data everywhere, they only want it at the IA



From arnold at skeeve.com  Sun Jan 19 06:19:10 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 18 Jan 2020 13:19:10 -0700
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
Message-ID: <202001182019.00IKJAtK021714@freefriends.org>

Al Kossow <aek at bitsavers.org> wrote:

>
>
> On 1/18/20 12:04 PM, Michael Kjörling wrote:
>
> > If that does turn out to be the case, might you consider transferring
> > the data wholesale to, say, the Internet Archive?
>
> Jason already takes everything.
> We have mutually different goals. I want the data everywhere, they only want it at the IA
>

Perhaps some sort of crowd-funding would let you continue running things?

Just a thought,

Arnold

From athornton at gmail.com  Sun Jan 19 06:24:21 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 18 Jan 2020 13:24:21 -0700
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
Message-ID: <BE27DB83-F2F1-4D51-BCE3-C9B82A583CAB@gmail.com>



> On Jan 17, 2020, at 11:25 PM, Rob Pike <robpike at gmail.com> wrote:
> 
> I am convinced that large-scale modern compute centers would be run very differently, with fewer or at least lesser problems, if they were treated as a single system rather than as a bunch of single-user computers ssh'ed together.
> 
> But history had other ideas.

So I’ve clearly got a dog in this fight (https://athornton.github.io/Tucson-Python-Dec-2019/ et al. (also mostly at athornton.github.io)) but I feel like Kubernetes is an interesting compromise in that space.

Admittedly, I come to this not only from a Unix/Linux background but an IBM VM background, but:

1) containerization is a necessary but not sufficient first step
2) black magic to handle the internal networking and endpoint exposure through fairly simple configuration on the user’s part is essential
3) abstractions to describe resources (the current enumerated-objects quota stuff is clunky but sufficient; the CPU/Memory quota stuff is fine), and
4) an automated lifecycle manager

taken together give you a really nifty platform for defining complex applications via composition, which (IMHO) is one of the fundamental wins of Unix, although in this case, it’s really _not_ very analogous to plugging pipeline stages together.

Note that _running_ Kubernetes is still a pain, so unless running data centers is your job, just rent capacity from someone else’s managed Kubernetes service.

Adam

From aek at bitsavers.org  Sun Jan 19 06:24:32 2020
From: aek at bitsavers.org (Al Kossow)
Date: Sat, 18 Jan 2020 12:24:32 -0800
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <202001182019.00IKJAtK021714@freefriends.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
Message-ID: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>


On 1/18/20 12:19 PM, arnold at skeeve.com wrote:

> Perhaps some sort of crowd-funding would let you continue running things?
> 

Let's see what happens with the server first.
I have a copy of the most recent data, and the mirrors are all still there.
I've asked that we disable the rsyncs until we can do
a fixity check.

I have no idea how much bandwith is used. The archive is about 300gb


From athornton at gmail.com  Sun Jan 19 06:31:46 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 18 Jan 2020 13:31:46 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <alpine.NEB.2.21.2001181257190.676@neener.bl.org>
References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU>
 <CANCZdfrPvQKEhb2dP1_iM72pZU_Gw7dPMZLy4GMKU-1Q5iEY7w@mail.gmail.com>
 <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
 <202001181845.00IIjSRE2543512@darkstar.fourwinds.com>
 <alpine.NEB.2.21.2001181257190.676@neener.bl.org>
Message-ID: <52C6CADB-C6FA-4AD5-8B21-D28DBAA9BFEE@gmail.com>

On Jan 18, 2020, at 11:59 AM, Michael Parson <mparson at bl.org> wrote:
> OK, yeah, I'll use grep to find what I'm looking for in the json output,
> then fight with^W^Wuse jq to extract the info I'm looking for in the json
> output.

Glad to know it’s not just me that finds the jq query language…difficult to comprehend.

Adam

From velocityboy at gmail.com  Sun Jan 19 06:33:54 2020
From: velocityboy at gmail.com (Jim Geist)
Date: Sat, 18 Jan 2020 15:33:54 -0500
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
Message-ID: <CAJohCKKN1u1J=aOo-TrJZaDfAnik=yhHu7w_UF7GkOo1HJNqMA@mail.gmail.com>

I mainly lurk here but if something will help save bitsavers I'm in. I've
gotten way to much use out of it over the years to not contribute if needed.

On Sat, Jan 18, 2020 at 3:26 PM Al Kossow <aek at bitsavers.org> wrote:

>
> On 1/18/20 12:19 PM, arnold at skeeve.com wrote:
>
> > Perhaps some sort of crowd-funding would let you continue running things?
> >
>
> Let's see what happens with the server first.
> I have a copy of the most recent data, and the mirrors are all still there.
> I've asked that we disable the rsyncs until we can do
> a fixity check.
>
> I have no idea how much bandwith is used. The archive is about 300gb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/206fc96b/attachment.html>

From steffen at sdaoden.eu  Sun Jan 19 06:34:22 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 18 Jan 2020 21:34:22 +0100
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
Message-ID: <20200118203422.2c7o_%steffen@sdaoden.eu>

Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>:
 |FWIW, I found this talk to be quite amusing and interesting.
 |
 |"What UNIX Cost Us" - Benno Rice (LCA 2020)
 |https://www.youtube.com/watch?v=9-IWMbJXoLM

That is the one who mutilated the FreeBSD fortune program no?
(Despite it saying

  The potentially offensive fortunes are installed by default on FreeBSD
  systems.  If you're absolutely, *positively*, without-a-shadow-of-a-doubt
  sure that your user community goes berzerk/sues your pants off/drops dead
  upon reading one of them, edit the Makefile in the subdirectory datfiles,
  and do "make all install".)

Nothing but a hollow lie ever since!

--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 athornton at gmail.com  Sun Jan 19 06:35:17 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 18 Jan 2020 13:35:17 -0700
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
Message-ID: <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>

So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost.  But even that…how popular is it _really_ ?

It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep.

I’ll put out some feelers.  Rough bandwidth data, if we can figure out some way to find it, would be good to have.

Adam

> On Jan 18, 2020, at 1:24 PM, Al Kossow <aek at bitsavers.org> wrote:
> 
> 
> On 1/18/20 12:19 PM, arnold at skeeve.com wrote:
> 
>> Perhaps some sort of crowd-funding would let you continue running things?
>> 
> 
> Let's see what happens with the server first.
> I have a copy of the most recent data, and the mirrors are all still there.
> I've asked that we disable the rsyncs until we can do
> a fixity check.
> 
> I have no idea how much bandwith is used. The archive is about 300gb
> 


From toby at telegraphics.com.au  Sun Jan 19 06:37:34 2020
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 18 Jan 2020 15:37:34 -0500
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <202001182019.00IKJAtK021714@freefriends.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
Message-ID: <e701b36c-7928-f580-2ab0-719967ac50f1@telegraphics.com.au>

On 2020-01-18 3:19 PM, arnold at skeeve.com wrote:
> Al Kossow <aek at bitsavers.org> wrote:
> 
>>
>>
>> On 1/18/20 12:04 PM, Michael Kjörling wrote:
>>
>>> If that does turn out to be the case, might you consider transferring
>>> the data wholesale to, say, the Internet Archive?
>>
>> Jason already takes everything.
>> We have mutually different goals. I want the data everywhere, they only want it at the IA
>>
> 
> Perhaps some sort of crowd-funding would let you continue running things?

Hm, let's see... the richest man in the world owns some kind of cloud
infra... I guess he's not very interested in computing history though.

> 
> Just a thought,
> 
> Arnold
> 


From toby at telegraphics.com.au  Sun Jan 19 06:40:41 2020
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 18 Jan 2020 15:40:41 -0500
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <BE27DB83-F2F1-4D51-BCE3-C9B82A583CAB@gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
 <BE27DB83-F2F1-4D51-BCE3-C9B82A583CAB@gmail.com>
Message-ID: <58b728c7-2605-2418-df97-50bfea85bc46@telegraphics.com.au>

On 2020-01-18 3:24 PM, Adam Thornton wrote:
> 
> 
>> On Jan 17, 2020, at 11:25 PM, Rob Pike <robpike at gmail.com> wrote:
>>
>> I am convinced that large-scale modern compute centers would be run very differently, with fewer or at least lesser problems, if they were treated as a single system rather than as a bunch of single-user computers ssh'ed together.
>>
>> But history had other ideas.
> 
> So I’ve clearly got a dog in this fight (https://athornton.github.io/Tucson-Python-Dec-2019/ et al. (also mostly at athornton.github.io)) but I feel like Kubernetes is an interesting compromise in that space.
> 
> Admittedly, I come to this not only from a Unix/Linux background but an IBM VM background, but:
> 
> 1) containerization is a necessary but not sufficient first step

Exactly.

> 2) black magic to handle the internal networking and endpoint exposure through fairly simple configuration on the user’s part is essential
> 3) abstractions to describe resources (the current enumerated-objects quota stuff is clunky but sufficient; the CPU/Memory quota stuff is fine), and
> 4) an automated lifecycle manager

Right, I think we use the terms "orchestration", "service discovery", etc.

--T

> 
> taken together give you a really nifty platform for defining complex applications via composition, which (IMHO) is one of the fundamental wins of Unix, although in this case, it’s really _not_ very analogous to plugging pipeline stages together.
> 
> Note that _running_ Kubernetes is still a pain, so unless running data centers is your job, just rent capacity from someone else’s managed Kubernetes service.
> 
> Adam
> 


From usotsuki at buric.co  Sun Jan 19 06:53:07 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 18 Jan 2020 15:53:07 -0500 (EST)
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
 <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>
Message-ID: <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>

On Sat, 18 Jan 2020, Adam Thornton wrote:

> So…that’s not a lot of archive, so I’m guessing that it’s outbound 
> bandwidth that will be the driving cost.  But even that…how popular is 
> it _really_ ?
>
> It seems like, given the nature of the collection, it might not be hard 
> to persuade one of the cloud providers into discounted rates for 
> hosting, although…it’s so small that that might not work, because that 
> little data, well, you’re not a customer big enough to have a Google or 
> Amazon rep.
>
> I’ll put out some feelers.  Rough bandwidth data, if we can figure out 
> some way to find it, would be good to have.

What about renting an OVH server and slapping it on that?  I think the 
KimSufi 1 is 500 GB disk space - dunno if that's cheap enough.

-uso.

From athornton at gmail.com  Sun Jan 19 07:04:01 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 18 Jan 2020 14:04:01 -0700
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
 <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>
 <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>
Message-ID: <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com>



> On Jan 18, 2020, at 1:53 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Sat, 18 Jan 2020, Adam Thornton wrote:
> 
>> So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost.  But even that…how popular is it _really_ ?
>> 
>> It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep.
>> 
>> I’ll put out some feelers.  Rough bandwidth data, if we can figure out some way to find it, would be good to have.
> 
> What about renting an OVH server and slapping it on that?  I think the KimSufi 1 is 500 GB disk space - dunno if that's cheap enough.


A possibly-stopgap-but-maybe-not-idiotic solution just occurred to me.

This isn’t exactly the sort of data that’s GOOD for hosting via Git, since it’s mostly-binary and mostly-read-only.

But checking it into a GitHub public repo until we were told to stop…or checking in some indexes, paying for some S3 buckets, and using Git Large File Support pointing at the buckets for the binary blobs…might not be the dumbest idea in the world.  I mean, GitHub is well-indexed, has a lot of incentive to maintain good backups, and probably isn’t going anywhere any time soon.

Adam

From toby at telegraphics.com.au  Sun Jan 19 07:22:37 2020
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 18 Jan 2020 16:22:37 -0500
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
 <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>
 <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>
 <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com>
Message-ID: <8ced9228-5126-681c-11d1-9af4e4dda1ed@telegraphics.com.au>

On 2020-01-18 4:04 PM, Adam Thornton wrote:
> 
> 
>> On Jan 18, 2020, at 1:53 PM, Steve Nickolas <usotsuki at buric.co> wrote:
>>
>> On Sat, 18 Jan 2020, Adam Thornton wrote:
>>
>>> So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost.  But even that…how popular is it _really_ ?
>>>
>>> It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep.
>>>
>>> I’ll put out some feelers.  Rough bandwidth data, if we can figure out some way to find it, would be good to have.
>>
>> What about renting an OVH server and slapping it on that?  I think the KimSufi 1 is 500 GB disk space - dunno if that's cheap enough.
> 
> 
> A possibly-stopgap-but-maybe-not-idiotic solution just occurred to me.
> 
> This isn’t exactly the sort of data that’s GOOD for hosting via Git, since it’s mostly-binary and mostly-read-only.
> 
> But checking it into a GitHub public repo until we were told to stop…or checking in some indexes, paying for some S3 buckets, and using Git Large File Support pointing at the buckets for the binary blobs…might not be the dumbest idea in the world.  I mean, GitHub is well-indexed, has a lot of incentive to maintain good backups, and probably isn’t going anywhere any time soon.

S3 already serves static content directly.

Anyone thinking about this problem should consider what you get in S3
that you'd otherwise have to replace in other ways.

--T

> 
> Adam
> 


From michael at kjorling.se  Sun Jan 19 07:31:01 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 18 Jan 2020 21:31:01 +0000
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <c3gdqsn7s3msmpvctqhp4733@localhost>
 <f1dfad9d-486b-d260-d70b-bf10df86c382@bitsavers.org>
 <202001182019.00IKJAtK021714@freefriends.org>
 <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org>
 <D54CF1F7-200F-4AC4-8BA6-515DC23E9403@gmail.com>
 <alpine.BSF.2.02.2001181551500.14055@frieza.hoshinet.org>
Message-ID: <4wfn9dxck39qq9trvk7tq4rt@localhost>

On 18 Jan 2020 15:53 -0500, from usotsuki at buric.co (Steve Nickolas):
> What about renting an OVH server and slapping it on that?  I think the
> KimSufi 1 is 500 GB disk space - dunno if that's cheap enough.

I just checked with another ISP, just to get a data point. Hetzner
(which has datacenters in Germany and Finland, but I'm not sure how
they feel about customers in the US) charge €0.05/GB/month plus VAT
for extra storage volumes; ignoring VAT, 300 GB comes out to
€15/month. 500 GB would be €25/month. Especially for static content,
their low-end VPS would almost certainly be plenty powerful enough for
serving it, so add €2.50/month for that. So starting at some €20/month
for VPS hosting with sufficient storage. They also include 20 TB/month
outgoing traffic in all VPS plans; additional traffic is extra.
ISP-side backups cost an additional 20%. Add VAT to taste.

I looked at the KimSufi 1; that looks like it comes out to $3.35/month
for their cheapest tier VPS, plus $42/month for 500 GB of storage
(next tier down is 200 GB at $21/month, so not enough). So about
$45/month. Not sure if that's inclusive or exclusive of VAT, but
still, about twice the price.

So if a single server is merely nice to have as opposed to critical,
it definitely looks to be doable with a VPS in the 30-50 currency per
month price range.

-- 
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  Sun Jan 19 07:56:49 2020
From: rtomek at ceti.pl (Tomasz Rola)
Date: Sat, 18 Jan 2020 22:56:49 +0100
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
Message-ID: <20200118215649.GA2390@tau1.ceti.pl>

On Sat, Jan 18, 2020 at 10:20:05AM -0800, Al Kossow wrote:
> 
> 
> On 1/17/20 3:24 PM, Tomasz Rola wrote:
> 
> > So in short, it looks like somebody dropped their router on the floor?
> > Hard fridays night, perhaps. Power glitch?
> > 
> 
> The entire classiccmp server was lost. 
[...]

Holy crap. Does it mean the content hosted there (which includes some
long gone collector's websites) is gone too? I have copied some of it
for my own purposes, but it is far from being complete or anything
like this.

-- 
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 aek at bitsavers.org  Sun Jan 19 08:04:31 2020
From: aek at bitsavers.org (Al Kossow)
Date: Sat, 18 Jan 2020 14:04:31 -0800
Subject: [TUHS] bitsavers.org down?
In-Reply-To: <20200118215649.GA2390@tau1.ceti.pl>
References: <CANCZdfosCF-eYiESfS5Ge5EA2JeMt_iGSPRVbBRMTP5JapYxdg@mail.gmail.com>
 <20200117232457.GA17503@tau1.ceti.pl>
 <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org>
 <20200118215649.GA2390@tau1.ceti.pl>
Message-ID: <7a869ed9-4814-6f23-3c30-ec0e03327485@bitsavers.org>



On 1/18/20 1:56 PM, Tomasz Rola wrote:

>> The entire classiccmp server was lost. 
> [...]
> 
> Holy crap. Does it mean the content hosted there (which includes some
> long gone collector's websites) is gone too?

We don't know yet. Jay is working on trying to recover it.
This is also why the cctalk/cctech mailing lists are down.

Fortunately, Jay created a Discord channel a few months ago,
so there is a comms channel independent of his servers.




From meillo at marmaro.de  Sun Jan 19 08:11:14 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 18 Jan 2020 23:11:14 +0100
Subject: [TUHS] screen editors
In-Reply-To: <20200118153725.GD28686@mcvoy.com>
References: <alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
 <CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
 <20200109012830.GC16808@mcvoy.com>
 <D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
 <CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
 <20200109020720.GG16808@mcvoy.com>
 <CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
 <202001090423.0094NooZ379407@darkstar.fourwinds.com>
 <alpine.NEB.2.21.2001172002140.1764@neener.bl.org>
 <CAC20D2OjzTtsXrKAhW0EcSRk_CS2OP39nvMgmsEbSOe03dDBMA@mail.gmail.com>
 <20200118153725.GD28686@mcvoy.com>
Message-ID: <1iswJG-1JH-00@marmaro.de>

Hoi.

Not wanting to heaten this rather annoying editor discussion, but
as no one yet has mentioned argv[0]:

[2020-01-18 07:37] Larry McVoy <lm at mcvoy.com>
> On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> > 
> > To be you are either compatible or not.  I would have been ok to have had
> > an option that you could turn on that gave you new behavior (but make the
> > user turn it on thank you).

> If it was compat by default then you
> wouldn't learn any of the new stuff.  

> set compatible

Shouldn't all that be solved by acting compatible if called as
`vi' and being free from compatibility bounds when called as
`vim'?

If I say `vi' I want a vi. If I want Vim, I say so. (No matter
if these are links to the same binary.)

Problem solved. Everyone happy?


meillo

From reed at reedmedia.net  Sun Jan 19 07:38:50 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Sat, 18 Jan 2020 15:38:50 -0600 (CST)
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com>
Message-ID: <alpine.NEB.2.21.2001181454150.50@t1.m.reedmedia.net>

On Sat, 18 Jan 2020, Rich Morin wrote:

> [ No good deed goes unpunished...  -r ]

Thanks again!
Do you have a bibliography or list of all the papers and books you have 
in that collection?

I have a very very long list of things I am looking for, such as:

- "The Conversion of U.C. Berkeley Time Sharing Systems to UNIX Version 
Seven" by Bob Kridle 1981;

- various Unix News 1975-1976;

- more 1970's Western Electric licensing examples; Univ. of California / 
Berkeley; Univ. of Toronto, or any other 1970's "Unix" licenses. (An 
example I am looking for is AT&T/USL vs. BSDI/Univ. of California June 
1992 complaint Exhibit F "32V Software Agreement" dated April 1, 1979 
(or Exhibit B to the DeFazio Affidavit)? (See 920724.complaint.txt and 
more details in 930107.amicus.txt and 930108.oppose.txt.)  Or maybe the 
1981 relicense?

- 1970's release announcements of any Unix or any Berkeley Unix related 
software (like Berkeley Pascal)

- "PWB/Unix overview and synopsis of facilities" 1977 by Dolotta and 
Haight;

- M. Nielsen, "SUN Student Workstation System Overview" Computer 
Science Department, Stanford Univ. 1981

- Shannon and Lyon's paper "4.2BSD on the Sun Workstation (or What we 
Did on our Summer Vacation)(or How to Emulate a VAX on a 68000)" from 
Winter 1983 Usenix/Unicom?  (Sure seems like I found this but don't see 
now.)

- BBN QTR "Combined Quarterly Technical Report" 18, 21, 22, 25, 28

Maybe we should make a TUHS wiki page of documents we are looking for? 
(Or maybe there already is?)


From imp at bsdimp.com  Sun Jan 19 08:35:11 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 18 Jan 2020 15:35:11 -0700
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <alpine.NEB.2.21.2001181454150.50@t1.m.reedmedia.net>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com>
 <alpine.NEB.2.21.2001181454150.50@t1.m.reedmedia.net>
Message-ID: <CANCZdfq=yrB829+hxZPGOM3UHf+yYzphvenV_eLWCdEtPrteGw@mail.gmail.com>

On Sat, Jan 18, 2020 at 3:23 PM <reed at reedmedia.net> wrote:

> On Sat, 18 Jan 2020, Rich Morin wrote:
>
> > [ No good deed goes unpunished...  -r ]
>
> - "PWB/Unix overview and synopsis of facilities" 1977 by Dolotta and
> Haight;
>

ACM published

An introduction to the Programmer's Workbench
<https://dl.acm.org/doi/abs/10.5555/800253.807669>

   - [image: T A Dolotta profile image]T. A. Dolotta
   <https://dl.acm.org/profile/81100113027>,
   - [image: John Russell Mashey profile image]J. R. Mashey
   <https://dl.acm.org/profile/81100046339>

ICSE '76: Proceedings of the 2nd international conference on Software
engineering <https://dl.acm.org/doi/proceedings/10.5555/800253> October
1976, pp 164–168

There's about 6 or 7 PWB articles in those proceedings. Do you have copies
of those?


Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/151d7066/attachment.html>

From greg.m.travis at gmail.com  Sun Jan 19 09:02:24 2020
From: greg.m.travis at gmail.com (greg travis)
Date: Sat, 18 Jan 2020 18:02:24 -0500
Subject: [TUHS] screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001181036400.908@aneurin.horsfall.org>
References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de>
 <alpine.BSF.2.21.9999.2001090844510.40155@aneurin.horsfall.org>
 <CAC20D2M2Z6tiLXYPkstaxkF3K5ZaB4p9mLcn0C3aw5FAg9_9vg@mail.gmail.com>
 <alpine.BSF.2.21.9999.2001181036400.908@aneurin.horsfall.org>
Message-ID: <CAJvuEa1G8EpmB+dO3FTcfiL9JmdzmkFA7wf3APypyBp+cKfbWw@mail.gmail.com>

'Ken Thompson has an automobile which he helped design. Unlike most
automobiles, it has neither speedometer, nor gas gauge, nor any of the
other numerous idiot lights which plague the modern driver. Rather, if the
driver makes a mistake, a giant “?” lights up in the center of the
dashboard. “The experienced driver,” says Thompson, “will usually know
what’s wrong.”'

On Fri, Jan 17, 2020 at 6:39 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 8 Jan 2020, Clem Cole wrote:
>
> > Although the famous ? error from the original version was annoying.
>
> Was it Ken or Dennis who thought of a car with but a single alarm
> indicator; "the experienced driver will know what it means".
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200118/7c54a716/attachment.html>

From cmhanson at eschatologist.net  Sun Jan 19 08:48:45 2020
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sat, 18 Jan 2020 14:48:45 -0800
Subject: [TUHS] Atari System V media and books?
Message-ID: <E569AF4F-7DE1-4C71-BAE1-600832FD8B34@eschatologist.net>

I’ve seen the archives of Atari System V Release 4 for the TT030, and the scanned user and developer manuals. Has anything else been preserved, e.g. the installation tapes and any other manuals?

Is there even a full accounting of what was in the box and what shipped afterwards (patches etc.)?

  -- Chris


From mparson at bl.org  Sun Jan 19 09:19:59 2020
From: mparson at bl.org (Michael Parson)
Date: Sat, 18 Jan 2020 17:19:59 -0600 (CST)
Subject: [TUHS] Atari System V media and books?
In-Reply-To: <E569AF4F-7DE1-4C71-BAE1-600832FD8B34@eschatologist.net>
References: <E569AF4F-7DE1-4C71-BAE1-600832FD8B34@eschatologist.net>
Message-ID: <alpine.NEB.2.21.2001181715530.676@neener.bl.org>

On Sat, 18 Jan 2020, Chris Hanson wrote:

> I’ve seen the archives of Atari System V Release 4 for the TT030,
> and the scanned user and developer manuals. Has anything else been
> preserved, e.g. the installation tapes and any other manuals?
>
> Is there even a full accounting of what was in the box and what
> shipped afterwards (patches etc.)?

Most of I've seen is the stuff I found while playing with Amiga UNIX,
which is the stuff hosted at atariunix.com.  I was able to pull the
Motif (v 1.1.1) bits out of the Atari UNIX disk images and get them
running on Amiga UNIX.

Speaking of old versions of Motif, are the sources for the pre-OpenMotif
bits available anywhere?  Even if under lock and key for now, I'd be
happy knowing they'd been preserved for potential future availability.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

From rdm at cfcl.com  Sun Jan 19 09:22:08 2020
From: rdm at cfcl.com (Rich Morin)
Date: Sat, 18 Jan 2020 15:22:08 -0800
Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers
In-Reply-To: <CANCZdfq=yrB829+hxZPGOM3UHf+yYzphvenV_eLWCdEtPrteGw@mail.gmail.com>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
 <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com>
 <alpine.NEB.2.21.2001181454150.50@t1.m.reedmedia.net>
 <CANCZdfq=yrB829+hxZPGOM3UHf+yYzphvenV_eLWCdEtPrteGw@mail.gmail.com>
Message-ID: <7411167F-9781-4520-BDD4-08D5A57F2188@cfcl.com>

> On Jan 18, 2020, at 14:35, Warner Losh <imp at bsdimp.com> wrote:
> 
> There's about 6 or 7 PWB articles in those proceedings. Do you have copies of those?

The box I have from Jim Joyce only has smallish photocopies.  I may have some conference
proceedings, but not the ones you mention.  More generally, I would be wary of scanning
and publishing anything that ACM or IEEE claims to own. (sigh)

-r


From krewat at kilonet.net  Sun Jan 19 09:27:38 2020
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 18 Jan 2020 18:27:38 -0500
Subject: [TUHS] Atari System V media and books?
In-Reply-To: <E569AF4F-7DE1-4C71-BAE1-600832FD8B34@eschatologist.net>
References: <E569AF4F-7DE1-4C71-BAE1-600832FD8B34@eschatologist.net>
Message-ID: <fee7d92d-d7a5-50eb-5406-2148bcd642f8@kilonet.net>

Wow, never knew Atari was involved in anything like UNIX.

Thank you!


On 1/18/2020 5:48 PM, Chris Hanson wrote:
> I’ve seen the archives of Atari System V Release 4 for the TT030, and the scanned user and developer manuals. Has anything else been preserved, e.g. the installation tapes and any other manuals?
>
> Is there even a full accounting of what was in the box and what shipped afterwards (patches etc.)?
>
>    -- Chris
>
>
>


From tytso at mit.edu  Sun Jan 19 12:49:00 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sat, 18 Jan 2020 21:49:00 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200118041913.GB67053@eureka.lemis.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
Message-ID: <20200119024900.GA15860@mit.edu>

On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote:
> On the other hand, Bill did write the articles in Dr. Dobbs Journal,
> which started in January 1991, so my best guess is that Linus just
> wasn't informed about the developments.

I don't believe that to be correct.  "Porting Unix to the 386: Missing
Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz,
was published in the May 1992 issue of Dr. Dobbs Journal.

https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764

      	       	   	    	     	     	     - Ted

From grog at lemis.com  Sun Jan 19 13:12:25 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 19 Jan 2020 14:12:25 +1100
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119024900.GA15860@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
Message-ID: <20200119031225.GI67053@eureka.lemis.com>

On Saturday, 18 January 2020 at 21:49:00 -0500, Theodore Y. Ts'o wrote:
> On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote:
>> On the other hand, Bill did write the articles in Dr. Dobbs Journal,
>> which started in January 1991, so my best guess is that Linus just
>> wasn't informed about the developments.
>
> I don't believe that to be correct.  "Porting Unix to the 386: Missing
> Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz,
> was published in the May 1992 issue of Dr. Dobbs Journal.
>
> https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764

That appears to be a different pair of articles.  My quotation was
from Wikipedia, which I believe to be correct I was working in the USA
in those days, and I saw the magazine in a bookshop in Austin TX.  I
stopped working there in December 1991.  Unfortunately I wasn't very
interested at the time ("who cares about BSD?").  Check the references
in the Wikipedia article.  Unfortunately the Dr. Dobbs site can't find
them.

May 1992 was significantly after the first release of 386BSD in March
1992.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/f1195250/attachment.sig>

From wkt at tuhs.org  Sun Jan 19 13:47:21 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 19 Jan 2020 13:47:21 +1000
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <20200119031225.GI67053@eureka.lemis.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
Message-ID: <20200119034721.GA28096@minnie.tuhs.org>

On Sun, Jan 19, 2020 at 02:12:25PM +1100, Greg 'groggy' Lehey wrote:
> May 1992 was significantly after the first release of 386BSD in March
> 1992.

https://dl.acm.org/doi/abs/10.5555/119491.121544 shows:

Dr. Dobb's Journal Vol. 16, No. 8
"The basic kernel: overview and initialization"
Authors: William Frederick Jolitz, Lynne Greer Jolitz
Publication: Dr. Dobb's Journal June 1991 

Cheers, Warren

From grog at lemis.com  Sun Jan 19 13:51:32 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 19 Jan 2020 14:51:32 +1100
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <20200119034721.GA28096@minnie.tuhs.org>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119034721.GA28096@minnie.tuhs.org>
Message-ID: <20200119035132.GJ67053@eureka.lemis.com>

On Sunday, 19 January 2020 at 13:47:21 +1000, Warren Toomey wrote:
> On Sun, Jan 19, 2020 at 02:12:25PM +1100, Greg 'groggy' Lehey wrote:
>> May 1992 was significantly after the first release of 386BSD in March
>> 1992.
>
> https://dl.acm.org/doi/abs/10.5555/119491.121544 shows:
>
> Dr. Dobb's Journal Vol. 16, No. 8
> "The basic kernel: overview and initialization"
> Authors: William Frederick Jolitz, Lynne Greer Jolitz
> Publication: Dr. Dobb's Journal June 1991

Yes, that's one of the articles referenced in the references on the WP
page, specifically
https://en.wikipedia.org/wiki/386BSD#Further_reading.  This one was
the 9th of 18 articles, which ran from January 1991 to July 1992.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/90f79a63/attachment.sig>

From grog at lemis.com  Sun Jan 19 13:58:08 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 19 Jan 2020 14:58:08 +1100
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119031225.GI67053@eureka.lemis.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
Message-ID: <20200119035808.GK67053@eureka.lemis.com>

On Sunday, 19 January 2020 at 14:12:25 +1100, Greg 'groggy' Lehey wrote:
> On Saturday, 18 January 2020 at 21:49:00 -0500, Theodore Y. Ts'o wrote:
>>
>> I don't believe that to be correct.  "Porting Unix to the 386: Missing
>> Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz,
>> was published in the May 1992 issue of Dr. Dobbs Journal.
>>
>> https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764
>
> That appears to be a different pair of articles.

Sorry, I was wrong.  That particular article was number 16 of the 18
part series, as shown at
https://en.wikipedia.org/wiki/386BSD#Further_reading.  It does raise
the question why the Dr Dobb's search engine didn't find any of them.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/51020af3/attachment.sig>

From kevin.bowling at kev009.com  Sun Jan 19 19:33:04 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 19 Jan 2020 02:33:04 -0700
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <20200118203422.2c7o_%steffen@sdaoden.eu>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200118203422.2c7o_%steffen@sdaoden.eu>
Message-ID: <CAK7dMtBs8vF6OrxH_RrkM+dCPcntTx0RTtAmtnaGGqQoOYOdtA@mail.gmail.com>

Apropos of nothing, I've noticed there are a handful of systems
charlatans that fast talk, relish in condencention, and make lame
humor to try to appeal to the unlearned (because systems has become
fairly esoteric in the expanding industry) frequenting the conference
tracks.  I guess everyone is supposed to be impressed.  Cool.

IMO not worth this list's time.

On Sat, Jan 18, 2020 at 1:35 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>
> Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>:
>  |FWIW, I found this talk to be quite amusing and interesting.
>  |
>  |"What UNIX Cost Us" - Benno Rice (LCA 2020)
>  |https://www.youtube.com/watch?v=9-IWMbJXoLM
>
> That is the one who mutilated the FreeBSD fortune program no?
> (Despite it saying
>
>   The potentially offensive fortunes are installed by default on FreeBSD
>   systems.  If you're absolutely, *positively*, without-a-shadow-of-a-doubt
>   sure that your user community goes berzerk/sues your pants off/drops dead
>   upon reading one of them, edit the Makefile in the subdirectory datfiles,
>   and do "make all install".)
>
> Nothing but a hollow lie ever since!
>
> --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 katolaz at freaknet.org  Sun Jan 19 20:29:37 2020
From: katolaz at freaknet.org (Vincenzo Nicosia)
Date: Sun, 19 Jan 2020 11:29:37 +0100
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
Message-ID: <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>

On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote:
> FWIW, I found this talk to be quite amusing and interesting.
> 
> "What UNIX Cost Us" - Benno Rice (LCA 2020)
> https://www.youtube.com/watch?v=9-IWMbJXoLM
> 

...which is along the same lines of the talk the same guy gave about
systemd and why everybody should like it. The message is simple: we
just want to run our shiny MacBooks and we don't understand Unix
anyway, so we'd better get rid of it and move on.

A flawed analysis that obviously leads to flawed conclusions.


From coppero1237 at gmail.com  Sun Jan 19 20:46:00 2020
From: coppero1237 at gmail.com (Tyler Adams)
Date: Sun, 19 Jan 2020 12:46:00 +0200
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>
Message-ID: <CAEuQd1CKw0fEgD0f2PJ-Y2FOYcsXTn2iBNwocXdcBRxEHumyZQ@mail.gmail.com>

His example of the USB driver was pretty silly. The unix code even *looked*
cleaner and straightforward compared to the convoluted windows/mac messes,
but he's mad because he had to figure out a *filepath*. What!?


 Tyler


On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia <katolaz at freaknet.org>
wrote:

> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote:
> > FWIW, I found this talk to be quite amusing and interesting.
> >
> > "What UNIX Cost Us" - Benno Rice (LCA 2020)
> > https://www.youtube.com/watch?v=9-IWMbJXoLM
> >
>
> ...which is along the same lines of the talk the same guy gave about
> systemd and why everybody should like it. The message is simple: we
> just want to run our shiny MacBooks and we don't understand Unix
> anyway, so we'd better get rid of it and move on.
>
> A flawed analysis that obviously leads to flawed conclusions.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/94f5c1a4/attachment.html>

From tytso at mit.edu  Sun Jan 19 23:25:51 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 19 Jan 2020 08:25:51 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119035808.GK67053@eureka.lemis.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
Message-ID: <20200119132551.GC15860@mit.edu>

On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote:
> 
> Sorry, I was wrong.  That particular article was number 16 of the 18
> part series, as shown at
> https://en.wikipedia.org/wiki/386BSD#Further_reading.  It does raise
> the question why the Dr Dobb's search engine didn't find any of them.

Out of curiosity, did the articles contain download information for a
bootable copy of 386BSD?

						- Ted

From clemc at ccc.com  Sun Jan 19 23:48:56 2020
From: clemc at ccc.com (Clem Cole)
Date: Sun, 19 Jan 2020 08:48:56 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119132551.GC15860@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu>
Message-ID: <CAC20D2OWe450=GaQzex1y5djPDCOUcT11Fvw-0xAV5593rGJsg@mail.gmail.com>

I don't remember, to be honest, I don't think so. When it first was
released which was before Linus's famous announcement, the ftp site was
from ucbvax and any UCB licensee that asked for got sent a copy of the URL
but you had to ask for it.

It was not a well kept secret.  When the BSDi / UCB vs ATT came later, as
Larry said a lot of us who were primarily driven by wanting a 'real unix'
for the 386 thought it was about copyright and that's when we looked at
Linux.  Then it came out that was a TS suit and many of us switched back
because Linux lacked networking and X11

On Sun, Jan 19, 2020 at 8:26 AM Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote:
> >
> > Sorry, I was wrong.  That particular article was number 16 of the 18
> > part series, as shown at
> > https://en.wikipedia.org/wiki/386BSD#Further_reading.  It does raise
> > the question why the Dr Dobb's search engine didn't find any of them.
>
> Out of curiosity, did the articles contain download information for a
> bootable copy of 386BSD?
>
>                                                 - Ted
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/20c0eb6d/attachment.html>

From jnc at mercury.lcs.mit.edu  Mon Jan 20 00:17:04 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Jan 2020 09:17:04 -0500 (EST)
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
Message-ID: <20200119141704.983E918C07B@mercury.lcs.mit.edu>

    > From: Greg 'groggy' Lehey <grog at lemis.com>

    > Unfortunately the Dr. Dobbs site can't find them.

    > 18 articles, which ran from January 1991 to July 1992.

If you search for "Jolitz", they almost all turn up:

  https://www.drdobbs.com/open-source/porting-unix-to-the-386-a-practical-appr/184408470
  https://www.drdobbs.com/open-source/porting-unix-to-the-386-three-initial-pc/184408496
  https://www.drdobbs.com/cpp/porting-unix-to-the-386-the-standalone-s/184408513
  https://www.drdobbs.com/open-source/porting-unix-to-the-386-language-tools-c/184408529
  https://www.drdobbs.com/porting-unix-to-the-386-the-initial-root/184408547
  https://www.drdobbs.com/porting-unix-to-the-386-research-the-co/184408566
  https://www.drdobbs.com/parallel/porting-unix-to-the-386-a-stripped-down/184408583
  https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408600
  https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408617
  https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408637
  https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408655
  https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408710
  https://www.drdobbs.com/embedded-systems/porting-unix-to-the-386-device-drivers/184408727
  https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408747
  https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764
  https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-i/184408782
  https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800

They're not totally open access; you have to register with DD to get all of them. However,
while looking for something else (below), I did find this:

  https://www.386bsd.org/releases

which appear to be the same as the above.


One of the items listed in WP, "Copyright, Copyleft, and Competitive
Advantage" (Apr/1991) wasn't in the search results (the "Editorial" at the
right point in the search results wasn't it, alas). A Web search didn't turn
it up either. Since it's not in the 'releases' page, it might not really be
part of the series?

     Noel

From jnc at mercury.lcs.mit.edu  Mon Jan 20 02:05:51 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Jan 2020 11:05:51 -0500 (EST)
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
Message-ID: <20200119160551.6A1D818C079@mercury.lcs.mit.edu>

    > If you search for "Jolitz"

Oh, I meant in the DDJ search box, not a general Web search.

    > One of the items listed in WP, "Copyright, Copyleft, and Competitive
    > Advantage" (Apr/1991) wasn't in the search results .. Since it's not in
    > the 'releases' page, it might not really be part of the series?

Also, the last article in the series ("The Final Step") says the series was 17
articles long, not the 18 you get if you include "Copyright".

	 Noel

From imp at bsdimp.com  Mon Jan 20 02:33:23 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 19 Jan 2020 09:33:23 -0700
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <CAEuQd1CKw0fEgD0f2PJ-Y2FOYcsXTn2iBNwocXdcBRxEHumyZQ@mail.gmail.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>
 <CAEuQd1CKw0fEgD0f2PJ-Y2FOYcsXTn2iBNwocXdcBRxEHumyZQ@mail.gmail.com>
Message-ID: <CANCZdfqbnBh9_FEx9FAmasvptB_b0T0ZZADH=34WPz=qx_Gjsw@mail.gmail.com>

Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster
fire. It has a lot of cool ideas, but is coded by someone that has poor
listening skills and is more stubborn than he's technically competent. It's
had a crapton of severe security bugs in it. It's given us abominations
like eth4156 as a NIC name. It doesn't like it when you & a job and log out
for Pete's sake. It's a total mess that breaks everything to try to push
the state of the art. Beno's talk on it may have been a little over the
top, but he's not wrong about much of his criticism. Systemd has swung too
far from the do one thing and do it well philosophy, admittedly in ways
that are ham-fisted and don't necessarily mean that it's philosophically
wrong, that it shows at least some of thee wisdom of simplicity.

Benno's Unix talk is similar. He's not wrong. The everything is a file
paradigm has issues.

On Sun, Jan 19, 2020 at 3:47 AM Tyler Adams <coppero1237 at gmail.com> wrote:

> His example of the USB driver was pretty silly. The unix code even
> *looked* cleaner and straightforward compared to the convoluted
> windows/mac messes, but he's mad because he had to figure out a *filepath*.
> What!?
>

Figure a  dozen file paths out, cat the right thing to them so other files
show up and  then you can  do the same thing again? That's  not a sane
interface. Everything isn't a file.  We've known this since the 70's. The
first NCP/TCP stacks were terrible in this way. You opened /dev/net/london.
And while that sounds cool, it means you have to have some kind of name
lookup in kernel which isn't a directory lookup. You either need a userland
daemon to do  the work and sleep, or you need to do crazy things like that
in the kernel. And there was no really good way to do what we do with
select, poll, kqueue or the like. And trying to do really high end, high
data rate stuff with read/write is inefficient.

At Netflix we use sendfile for our stuff. It's one of the least
unixy things in the kernel. It reads from a file, then TLS encrypts the
file and sends it out the socket. This means state has to be carefully
managed with some setup in userland before the handoff. The other non-unixy
thing is that it's all non blocking. sendfile asks for a set of pages from
a file. When they are ready, it gets a callback to schedule encryption, and
when that fires it's scheduled to the NIC for transmission and either
retransmission or freeing up depending on the ACKs that come back. At
~190Gbps, this isn't something one can do with the normal Unix interfaces,
which was the point of his talk. He's not wrong, but his examples could use
some work.

The real world is messy, and often requires complexity. Going too simple
for simplicity's sake is just as bad as going too complicated for
complexity's sake. A proper balance is needed. And he's not wrong to make
that point.

Warner

P.S. complaining about Benno's involvement in cleaning up FreeBSD's fortune
in response to his talk is lame and puerile. Totally off topic and typical
of the stupid and ill-informed attacks that he attracted around the code of
conduct stuff by jerks that had no stake in the FreeeBSD community, but
instead wanted to fight for their absolute right to be self-absorbed jerks
without consequences. It totally burned him out, and the FreeBSD community
lost a contributing member because of the grief he got. It's unbecoming to
see it on this list.


>  Tyler
>
>
> On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia <katolaz at freaknet.org>
> wrote:
>
>> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote:
>> > FWIW, I found this talk to be quite amusing and interesting.
>> >
>> > "What UNIX Cost Us" - Benno Rice (LCA 2020)
>> > https://www.youtube.com/watch?v=9-IWMbJXoLM
>> >
>>
>> ...which is along the same lines of the talk the same guy gave about
>> systemd and why everybody should like it. The message is simple: we
>> just want to run our shiny MacBooks and we don't understand Unix
>> anyway, so we'd better get rid of it and move on.
>>
>> A flawed analysis that obviously leads to flawed conclusions.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/2d06f529/attachment.html>

From rdm at cfcl.com  Mon Jan 20 03:40:35 2020
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 19 Jan 2020 09:40:35 -0800
Subject: [TUHS] CSRG report TR/3 (IPC Architecture)
In-Reply-To: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
References: <DFC407A8-397F-4074-AFF5-D7DC053B5AC7@planet.nl>
Message-ID: <E0AB8AEB-7418-45CB-8202-236409E1FA00@cfcl.com>

I think the following may have been missed, because folks thought it was more
discussion about the CSRG TR/4.  Read on...

> On Jan 18, 2020, at 01:08, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> At the bottom of page 6 TR/4 references TR/3:
> 
> A more complete description of the motivation of the IPC architecture
> described here, measurements of a prototype implementation, comparisons
> with other work and a complete bibliography are given in CSRG TR/3: “An IPC
> Architecture for UNIX”.

This was also in the box: about 50 pages, including a four-page bibliography.

An Architecture for Interprocess Communication in UNIX*
-- DRAFT of June 22, 1981 --
William Joy and Robert Fabry

Paul sez:
> Before yesterday I did not know that TR/3 existed and in my (arguable) view
> it is even a bigger find than TR/4, as it gives great insight how design
> trade-offs were perceived back in 1981.

Again, I scanned the paper and then Paul aggregated the scans into a single PDF.
It should be available here:

  http://cfcl.com/private/CSRG_TR_3.pdf

-r


From kevin.bowling at kev009.com  Mon Jan 20 04:16:01 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 19 Jan 2020 11:16:01 -0700
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <CANCZdfqbnBh9_FEx9FAmasvptB_b0T0ZZADH=34WPz=qx_Gjsw@mail.gmail.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>
 <CAEuQd1CKw0fEgD0f2PJ-Y2FOYcsXTn2iBNwocXdcBRxEHumyZQ@mail.gmail.com>
 <CANCZdfqbnBh9_FEx9FAmasvptB_b0T0ZZADH=34WPz=qx_Gjsw@mail.gmail.com>
Message-ID: <CAK7dMtCai9hLBqDtkm1AipmuZHShLwQnMA8fZLmcM9GzqAiqmg@mail.gmail.com>

On Sun, Jan 19, 2020 at 9:35 AM Warner Losh <imp at bsdimp.com> wrote:
>
> Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster fire. It has a lot of cool ideas, but is coded by someone that has poor listening skills and is more stubborn than he's technically competent. It's had a crapton of severe security bugs in it. It's given us abominations like eth4156 as a NIC name. It doesn't like it when you & a job and log out for Pete's sake. It's a total mess that breaks everything to try to push the state of the art. Beno's talk on it may have been a little over the top, but he's not wrong about much of his criticism. Systemd has swung too far from the do one thing and do it well philosophy, admittedly in ways that are ham-fisted and don't necessarily mean that it's philosophically wrong, that it shows at least some of thee wisdom of simplicity.
>
> Benno's Unix talk is similar. He's not wrong. The everything is a file paradigm has issues.

The problem is this talk is just self aggrandizement at large.  It
would have been cute in the year 2000.  It's pretty ridiculous
cherry-picking hoping to target an unknowing audience in 2020.

I can alt/option+space on my FreeBSD desktop, open a monitor, and kill
a process in a GUI with a top right search box the exact same as OS X.
Cool.

Modern Linux distros don't even use X11 (except nested as OS X in case
of legacy application).

The crude APIs (he calls out Linux and Windows and BSD and C) are not
secret.  I would be surprised if Linus himself didn't agree that a lot
of the Linux interfaces suck.  There's just an issue of backwards
compatibility, and you know, doing some work instead of fishing for
social points at a conference.

Android has deviated significantly from Linux.  Linux from UNIX.
Basically nobody at a Linux conference is blindly following the UNIX
philosophy.  This message makes little sense to that crowd in absolute
terms.  The kindest critique I can give is:  fighting the last war.

> On Sun, Jan 19, 2020 at 3:47 AM Tyler Adams <coppero1237 at gmail.com> wrote:
>>
>> His example of the USB driver was pretty silly. The unix code even looked cleaner and straightforward compared to the convoluted windows/mac messes, but he's mad because he had to figure out a filepath. What!?
>
>
> Figure a  dozen file paths out, cat the right thing to them so other files show up and  then you can  do the same thing again? That's  not a sane interface. Everything isn't a file.  We've known this since the 70's. The first NCP/TCP stacks were terrible in this way. You opened /dev/net/london. And while that sounds cool, it means you have to have some kind of name lookup in kernel which isn't a directory lookup. You either need a userland daemon to do  the work and sleep, or you need to do crazy things like that in the kernel. And there was no really good way to do what we do with select, poll, kqueue or the like. And trying to do really high end, high data rate stuff with read/write is inefficient.
>
> At Netflix we use sendfile for our stuff. It's one of the least unixy things in the kernel. It reads from a file, then TLS encrypts the file and sends it out the socket. This means state has to be carefully managed with some setup in userland before the handoff. The other non-unixy thing is that it's all non blocking. sendfile asks for a set of pages from a file. When they are ready, it gets a callback to schedule encryption, and when that fires it's scheduled to the NIC for transmission and either retransmission or freeing up depending on the ACKs that come back. At ~190Gbps, this isn't something one can do with the normal Unix interfaces, which was the point of his talk. He's not wrong, but his examples could use some work.
>
> The real world is messy, and often requires complexity. Going too simple for simplicity's sake is just as bad as going too complicated for complexity's sake. A proper balance is needed. And he's not wrong to make that point.
>
> Warner
>
> P.S. complaining about Benno's involvement in cleaning up FreeBSD's fortune in response to his talk is lame and puerile. Totally off topic and typical of the stupid and ill-informed attacks that he attracted around the code of conduct stuff by jerks that had no stake in the FreeeBSD community, but instead wanted to fight for their absolute right to be self-absorbed jerks without consequences. It totally burned him out, and the FreeBSD community lost a contributing member because of the grief he got. It's unbecoming to see it on this list.
>
>>
>>  Tyler
>>
>>
>> On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia <katolaz at freaknet.org> wrote:
>>>
>>> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote:
>>> > FWIW, I found this talk to be quite amusing and interesting.
>>> >
>>> > "What UNIX Cost Us" - Benno Rice (LCA 2020)
>>> > https://www.youtube.com/watch?v=9-IWMbJXoLM
>>> >
>>>
>>> ...which is along the same lines of the talk the same guy gave about
>>> systemd and why everybody should like it. The message is simple: we
>>> just want to run our shiny MacBooks and we don't understand Unix
>>> anyway, so we'd better get rid of it and move on.
>>>
>>> A flawed analysis that obviously leads to flawed conclusions.
>>>

From athornton at gmail.com  Mon Jan 20 05:45:39 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sun, 19 Jan 2020 12:45:39 -0700
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <CANCZdfqbnBh9_FEx9FAmasvptB_b0T0ZZADH=34WPz=qx_Gjsw@mail.gmail.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200119102937.3s2hwl3ziupa7ese@unixfarts.net>
 <CAEuQd1CKw0fEgD0f2PJ-Y2FOYcsXTn2iBNwocXdcBRxEHumyZQ@mail.gmail.com>
 <CANCZdfqbnBh9_FEx9FAmasvptB_b0T0ZZADH=34WPz=qx_Gjsw@mail.gmail.com>
Message-ID: <60F817C2-3C85-42CF-8C3F-7BE8EDBA551E@gmail.com>



> On Jan 19, 2020, at 9:33 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster fire. It has a lot of cool ideas, but is coded by someone that has poor listening skills and is more stubborn than he's technically competent. It's had a crapton of severe security bugs in it. It's given us abominations like eth4156 as a NIC name. It doesn't like it when you & a job and log out for Pete's sake. It's a total mess that breaks everything to try to push the state of the art.


Hoo boy.

I just had this argument on one of the Slacks I’m on.


> Beno's talk on it may have been a little over the top, but he's not wrong about much of his criticism. Systemd has swung too far from the do one thing and do it well philosophy, admittedly in ways that are ham-fisted and don't necessarily mean that it's philosophically wrong, that it shows at least some of thee wisdom of simplicity.


No, it’s philosophically wrong.

I will grant that there is a problem there that needs solving.  Let’s look at BSD rc and SysVinit; they’re both extremely difficult to automate installing and uninstalling services.  SysVInit works better than rc in that regard, but they’re both kind of crappy.  Let’s look at the things that suck about SysVInit:

1: no actual dependency graphs.  Sure, there was a whole framework of magic comments to sorta-kinda-glue one in.  Didn’t work very well.
2: tons of shell ceremony around start/stop/restart

What you want in an init system is:
First and foremost, a process manager, that acts as a signal handler of last resort.
  * It would be nice if it _can_ and _usually does_ run as PID 1, but doesn’t insist on it.
  * Has a firm notion of “this service depends on _that_ service” and can sequence startup and shutdown appropriately.
  * Has a declarative syntax that lets you configure most services with just a little declarative text, probably with an escape hatch for more complicated services

Here’s what you don’t want _in your init system_:

A new approach to logging that puts your logs in a human-unreadable binary format.

A system-wide event bus.  This is actually quite a good idea, but it doesn’t need to be part of the init system.

A sound manager.

You get the idea.

Yeah, SysVInit needed to be superseded.  Runit, Daemontools, Upstart all had reasonable approaches.  But the devouring hippo of SystemD won, mostly because Lennart worked at Red Hat.  And it’s a terrible idea because it tangles all these things together.  It’s also a terrible idea because your init system should have goals other than time from pressing the power button to getting a login prompt on Lennart’s laptop, but I digress.

> 
> Figure a  dozen file paths out, cat the right thing to them so other files show up and  then you can  do the same thing again? That's  not a sane interface. Everything isn't a file.  

[…]

To be fair: BSD sockets are not pretty, and they’re not elegant.  They won, and SysV Streams were worse in a lot of ways, but I still suspect there was some way of doing a TCP/IP stack that seemed more Unixy, without (maybe) needing DNS (or a service locator) in a sidecar userland process…but as soon as you start thinking about it, yeah, it gets gross.

> At Netflix we use sendfile for our stuff. It's one of the least unixy things in the kernel. It reads from a file, then TLS encrypts the file and sends it out the socket. This means state has to be carefully managed with some setup in userland before the handoff. The other non-unixy thing is that it's all non blocking. sendfile asks for a set of pages from a file. When they are ready, it gets a callback to schedule encryption, and when that fires it's scheduled to the NIC for transmission and either retransmission or freeing up depending on the ACKs that come back. At ~190Gbps, this isn't something one can do with the normal Unix interfaces, which was the point of his talk. He's not wrong, but his examples could use some work.

And here we see Unix as a victim of its own success.  It’s pretty damn weird, when you think about it, that we’re using a half-century-old typesetting system to power both the front and back ends of sending cat pictures and porn videos in real-time all over the planet all the time.

This also speaks to https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf (mentioned here several months ago).     The fork()/exec() model is great in a single-threaded pipeline-processing model.  But, yeah, it’s totally true that it (and read()/write()) is not the best thing for writing user-facing nonblocking GUIs.

> The real world is messy, and often requires complexity. Going too simple for simplicity's sake is just as bad as going too complicated for complexity's sake. A proper balance is needed. And he's not wrong to make that point.

That said: Linux now has _way_ too many syscalls.  I would be flabbergasted if the rarely-used ones are not crawling with exploitable bugs.  I am surprised that Google hasn’t done more with fuchsia + gvisor (well, maybe they have but haven’t showed us yet).  Gvisor is a fascinating experiment in worse-is-better, in that, no, it makes no attempt to replace _all_ the Linux system calls, just the ones that _the programs you really want to run_ use.

Things do grow cruft over time.  And things change over time.  Containers are absolutely essential to what I’m doing these days.  They were not ten years ago.  Alpine is going there (in terms of a minimal container-focused support system (== OS layer), but clearly the more-right thing would be something like gvisor-plus-something-like-fuschia: my container only contains _code_ for the syscalls my application actually uses.  Can’t exploit what isn’t there.

This also hits the “People shouldn’t be using C in 2020” argument.  But _that_ in turn is less about C not providing modern strong typing features and letting you play fast and loose with pointers and making you do your own memory management, and more about: your computer is really, really not a PDP-11 anymore.  A language that provides the abstraction of a simple in-order execution stream is _lying_ to you.

The problem with that is that thinking about something as bizarrely complex as modern CPUs and writing software to exploit the way they actually work is _really really hard_.

Wow, that was a ramble.  Anyway: Benno’s not wrong.  But everything’s historically contingent, right?  We’ve got a half-century of C and a half-century of a typesetting system that got too big for its britches, that’s now running, basically, the entire underpinnings of the 21st century…I was going to say “economy” but really, it’s “world.”

Adam


From ksspiers at gmail.com  Mon Jan 20 06:00:27 2020
From: ksspiers at gmail.com (Kathryn Spiers)
Date: Sun, 19 Jan 2020 12:00:27 -0800
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <20200118203422.2c7o_%steffen@sdaoden.eu>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200118203422.2c7o_%steffen@sdaoden.eu>
Message-ID: <CAGM9nhRPfZA2s17ociJfUTyq6WGt1rsqq=796xGynRD9c3bZbg@mail.gmail.com>

On Sat, Jan 18, 2020, 12:35 Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>:
>  |FWIW, I found this talk to be quite amusing and interesting.
>  |
>  |"What UNIX Cost Us" - Benno Rice (LCA 2020)
>  |https://www.youtube.com/watch?v=9-IWMbJXoLM
>
> That is the one who mutilated the FreeBSD fortune program no?
> (Despite it saying
>
>   The potentially offensive fortunes are installed by default on FreeBSD
>   systems.  If you're absolutely, *positively*, without-a-shadow-of-a-doubt
>   sure that your user community goes berzerk/sues your pants off/drops dead
>   upon reading one of them, edit the Makefile in the subdirectory datfiles,
>   and do "make all install".)
>
> Nothing but a hollow lie ever since!
>
> --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)
>

Or you could remove the offensive fortunes and make the default more
friendly for everyone...

Probably best not to re-litigate that change on this thread though.
-K

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/bc31d359/attachment.html>

From cym224 at gmail.com  Mon Jan 20 06:49:28 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Sun, 19 Jan 2020 15:49:28 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119141704.983E918C07B@mercury.lcs.mit.edu>
References: <20200119141704.983E918C07B@mercury.lcs.mit.edu>
Message-ID: <ff79c6e1-a96a-22fe-3be7-9f8ed9161841@gmail.com>

On 01/19/20 09:17, Noel Chiappa wrote:
> [...]
> One of the items listed in WP, "Copyright, Copyleft, and Competitive
> Advantage" (Apr/1991) wasn't in the search results (the "Editorial" at the right point in the search results wasn't it, alas). A Web search didn't turn it up either. Since it's not in the 'releases' page, it might not really be part of the series?
>
>       Noel
I subscribed to DDJ at the time but all my issues are in storage. If 
important, I could set aside some time next week to spelunk.

N.

From gtaylor at tnetconsulting.net  Mon Jan 20 07:22:29 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 19 Jan 2020 14:22:29 -0700
Subject: [TUHS] Shell Level...
Message-ID: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>

Hi,

Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?

I had largely dismissed it until a recent conversation in a newsgroup. 
I learned that shelling out of programs also increments the shell level. 
  I.e. :shell or :!/bin/sh in vim.

Someone also mentioned quickly starting a new sub-shell from the current 
shell for quick transient tasks, i.e. dc / bc, mount / cp / unmount, 
{,r,s}cp, etc., in an existing terminal window to avoid cluttering that 
first terminals history with the transient commands.

That got me to wondering if there were other uses for shell level 
($SHLVL).  Hence my question.

This is more about using (contemporary) shells on Unix, than it is about 
Unix history.  But I suspect that TUHS is one of the best places to find 
the most people that are likely to know about shell level.  Feel free to 
reply to COFF if it would be better there.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/77b30aec/attachment-0001.bin>

From pnr at planet.nl  Mon Jan 20 08:11:10 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 19 Jan 2020 23:11:10 +0100
Subject: [TUHS] "What Unix cost us" and Unix in 1981
Message-ID: <8573E48C-FC18-49D8-BA1A-75266EBF26CA@planet.nl>

I thought Benno Rice’s argument a bit unorganized and ultimately unconvincing, but I think the underlying point that we should from time to time step back a bit and review fundamentals has some merit. Unfortunately he does not distinguish much between a poor concept and a poor implementation.

For example, what does “everything is a file” mean in Unix?
- Devices and files are accessed through the same small API?
- All I/O is through unstructured byte streams?
- I/O is accessed via a single unified name space? etc.
Once that is clear, how can the concept then best be applied to USB devices?

Or: is there a fundamental difference between windows-style completion ports and completion signals?

Many of the underlying questions have been considered in the past, with carefully laid out arguments in various papers. In my view it is worthwhile to go back to these papers and see how the arguments pro and contra various approaches were weighed then and considering if the same still holds true today.

Interestingly, several points that Benno touches upon in his talk were also the topic of debate when Unix was transitioning to a 32 bits address space and incorporating networking in the early 80’s, as the TR/4 and TR/3 papers show. Of course, the system that CSRG delivered is different from the ambitions expressed in these papers and for sure opinions on the best choices differed as much back then as they will now - and that makes for an interesting discussion.




From wkt at tuhs.org  Mon Jan 20 08:15:54 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 20 Jan 2020 08:15:54 +1000
Subject: [TUHS] Cctalk mail list is back up
Message-ID: <CBB07598-9E35-4004-A23E-006DD53C52EF@tuhs.org>

Just thought you should know.
http://www.classiccmp.org/pipermail/cctalk/
Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/2e63454d/attachment.html>

From thomas.paulsen at firemail.de  Mon Jan 20 09:21:07 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Mon, 20 Jan 2020 00:21:07 +0100
Subject: [TUHS] Shell Level...
In-Reply-To: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
Message-ID: <cad6cadd584bef035670281a0829fc74@firemail.de>

>Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?
Its part of my default $PS1 since > 30 years when I anticipated' it under SysV4/ksh because of my frequent use of sub-shells then. Luckily its a bash build-in . Thanks RMS/Chet.



From woods at robohack.ca  Mon Jan 20 13:32:57 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Sun, 19 Jan 2020 19:32:57 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200119132551.GC15860@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu>
Message-ID: <m1itNo9-0036tPC@more.local>

At Sun, 19 Jan 2020 08:25:51 -0500, "Theodore Y. Ts'o" <tytso at mit.edu> wrote:
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")
>
> On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote:
> >
> > Sorry, I was wrong.  That particular article was number 16 of the 18
> > part series, as shown at
> > https://en.wikipedia.org/wiki/386BSD#Further_reading.  It does raise
> > the question why the Dr Dobb's search engine didn't find any of them.
>
> Out of curiosity, did the articles contain download information for a
> bootable copy of 386BSD?

Yes, they did:

     https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800

See also:

    http://gunkies.org/wiki/386BSD

Also keep in mind that NetBSD started as a set of "net" (as in usenet)
patch kits for 386BSD.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200119/13df2f84/attachment.sig>

From ggm at algebras.org  Mon Jan 20 13:51:55 2020
From: ggm at algebras.org (George Michaelson)
Date: Mon, 20 Jan 2020 13:51:55 +1000
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <m1itNo9-0036tPC@more.local>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
Message-ID: <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>

It does me no credit, that I initially reacted very badly to 386BSD,
and the initial {Net,Free,Open} situation.

I found all this "fragmentation" pretty hard to understand. -BSDI felt
like it had occupied the space, and I couldn't entirely understand
what was going on, or why any of it mattered.

I also reacted very badly to the public dirty linen spats around the
Jolitz's IPR, and who-did-what to-whom  in woodshed, with colonel
mustard and the lead pipe.

What worried me was the loss of intellectual capital. People I liked
online, and respected, seemed to be running to the four winds. Why was
something I worked with turning to suck?

What I think I missed (didn't understand) was how draining support was
for Berkeley, and in the absence of a sugar daddy (Earth Sciences?
DOE? IBM?) and loss of contracts like the NSFNet support for BSD-rt
(they stopped using PC-Rt as a platform for routing) It was
increasingly hard for a teaching and research institution to justify
what was going on. Sun spun out of Stanford. MIT was doing the Gui
work. Compilers had gone really funny with Gnu and an income stream
had evaporated, and a lawsuit was in the offing, and people who hadn't
done full on DOTCOM boom vesting suddenly found growing old and not
having a 401k at the scale they needed to maintain a wine cellar ...

What I also missed is that it stopped innovating. People were
innovating in other places, doing things I didn't understand. I
totally did NOT get what 8th ed. and Plan9 was on. Drugs I couldn't
fathom.

Nothing lasts forever. Had you said to me "ha.. VMS is going to die,
and Dec is going to die, and Sun is going to fold into Larry Ellisons
personal empire" I'd have taken every one of those bets on what turned
out to be the loosing side.

From nobozo at gmail.com  Mon Jan 20 13:59:06 2020
From: nobozo at gmail.com (Jon Forrest)
Date: Sun, 19 Jan 2020 19:59:06 -0800
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
Message-ID: <932dc73b-c2f9-a22c-ad20-4b41d23e929e@gmail.com>



On 1/19/2020 7:51 PM, George Michaelson wrote:

> What I think I missed (didn't understand) was how draining support was
> for Berkeley

Two of the founders of NetBSD were undergrads who were also members of
the Postgres research group that I was a part of. They did
NetBSD without any formal support from UC Berkeley. Whether or not
this was a good thing is debatable.

Jon


From meillo at marmaro.de  Mon Jan 20 18:15:56 2020
From: meillo at marmaro.de (markus schnalke)
Date: Mon, 20 Jan 2020 09:15:56 +0100
Subject: [TUHS] Shell Level...
In-Reply-To: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
Message-ID: <1itSE0-5Td-00@marmaro.de>

Hoi.

[2020-01-19 14:22] Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
>
> Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?

What's the use of it? The only use of $SHLVL I can think of is the
answer to the question if ^D will close the last shell or just a
sub shell. I hardly ever ask myself this question. Probably that
starts to become relevant when you open sub shells frequently.


> Someone also mentioned quickly starting a new sub-shell from the current 
> shell for quick transient tasks, i.e. dc / bc, mount / cp / unmount, 
> {,r,s}cp, etc., in an existing terminal window to avoid cluttering that 
> first terminals history with the transient commands.

With tmux or screen at hand, this use case is obsolete for me.
(Besides, my shell doesn't know about $SHLVL.)

This all pretty much depends on your working habits, of course.
For instance, I never use history expansion but search the
history frequently, thus additional entries in the shell history
are no problem. I rather like to have all shell histories merged
into one for having search access to all the commands I executed.
This seems to be more of a modern shell usage concept.

Job control, OTOH, I use a lot, to suspend the editor, grep for
something, resume the editor, and the like. Which seems to be more
of an older style usage concept.


> That got me to wondering if there were other uses for shell level 
> ($SHLVL).  Hence my question.

I'm interested as well, as I've got difficulties imagine these
uses.


One thing to clarify: Are you looking for uses of the shell
variable $SHLVL or for uses of frequent sub shells?


meillo

From khm at sciops.net  Mon Jan 20 18:39:28 2020
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 20 Jan 2020 00:39:28 -0800
Subject: [TUHS] Shell Level...
In-Reply-To: <1itSE0-5Td-00@marmaro.de>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de>
Message-ID: <20200120083928.GA68939@wopr>

On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote:
> Hoi.
> 
> [2020-01-19 14:22] Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> >
> > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?
> 
> What's the use of it? 

I have seen it used -- and I do not use it this way myself -- to
construct a sort of work batch, where a control script launches many
instances of itself, which then inspect $SHLVL to determine that they
are subordinates, and process elements of a central work queue.  The
parent instance would monitor the number of copies of the script in use
and launch new subordinates in the case some of them exited for whatever
reason.

The whole thing felt alien, but it seemed to work.  

The other, more common use I've seen is to e.g. clear the terminal
window on logout (e.g. in .bash_logout when SHLVL=1) but not when
exiting any nested shell.

It's not POSIX, so I've never relied on it.

khm

From txomsy at yahoo.es  Tue Jan 21 00:59:46 2020
From: txomsy at yahoo.es (Jose R. Valverde)
Date: Mon, 20 Jan 2020 15:59:46 +0100
Subject: [TUHS] Screen editors
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
Message-ID: <20200120155946.169b39e0@sagittariusa.cnb.csic.es>

Talking of editors...

Once I learned Wordstar in old CP/M (before that it was mostly line
editing), and then soon, other editors that supported the Wordstar key
combinations, I got hooked on those. Joe is, to date, one of my
favorites.

On ancient UNIX, my editor of choice was 's' from Software Tools, its
main advantage being that it didn't require curses. Then we got VMS and
'eve' and that took over for a while (though I never took advantage of
all its power), mostly until I ported 's' and 'joe'.

Then came X, and when nedit was released, I was hooked on it. It has
been for decades almost the only one that could do block selection 'a
la' RAND editor.

I have been struggling to continue using it despite it lack of support
for UTF, trying various projects spun off nedit, until I recently
discovered xnedit, which is an update available on GitHub and is again
all I need, with support for UTF8, some minor UI improvements and
support for modern fonts.

Now, I still use 's' for ancient Unix emulators, 'joe' for the
command line and 'xnedit' for X.

				j

-- 
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es

From toby at telegraphics.com.au  Tue Jan 21 02:07:01 2020
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 20 Jan 2020 11:07:01 -0500
Subject: [TUHS] Screen editors
In-Reply-To: <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
Message-ID: <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>

On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote:
> Talking of editors...
> 
> Once I learned Wordstar in old CP/M (before that it was mostly line
> editing), and then soon, other editors that supported the Wordstar key
> combinations, I got hooked on those. Joe is, to date, one of my
> favorites.

Speaking of WordStar, on CP/M there was also WordMaster, lighter weight,
better as a programmer's editor. Not sure who wrote it (but istr it came
from the WordStar people?) Adding here for completeness...

--T

> 
> On ancient UNIX, my editor of choice was 's' from Software Tools, 

...
> 
> Now, I still use 's' for ancient Unix emulators, 'joe' for the
> command line and 'xnedit' for X.
> 
> 				j
> 


From lm at mcvoy.com  Tue Jan 21 02:20:08 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Jan 2020 08:20:08 -0800
Subject: [TUHS] Screen editors
In-Reply-To: <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
Message-ID: <20200120162008.GE28686@mcvoy.com>

On Mon, Jan 20, 2020 at 11:07:01AM -0500, Toby Thain wrote:
> On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote:
> > Talking of editors...
> > 
> > Once I learned Wordstar in old CP/M (before that it was mostly line
> > editing), and then soon, other editors that supported the Wordstar key
> > combinations, I got hooked on those. Joe is, to date, one of my
> > favorites.
> 
> Speaking of WordStar, on CP/M there was also WordMaster, lighter weight,
> better as a programmer's editor. Not sure who wrote it (but istr it came
> from the WordStar people?) Adding here for completeness...

My memory fu is weak but there was a small editor for CP/M that I liked
a lot.  Can't remember what it was called but I stole some keybindings 
from it:

map # :.,$		# does from here to the bottom
map @ :1,.		@ does from top to here

Anyone remember that?

From ullbeking at andrewnesbit.org  Tue Jan 21 03:05:30 2020
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Mon, 20 Jan 2020 17:05:30 +0000
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAHJeKDVpxUPodBaTpqDMjWThXh=EUhjqKO1ZhiRHEAQ6qJrFcA@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
 <CAHJeKDVpxUPodBaTpqDMjWThXh=EUhjqKO1ZhiRHEAQ6qJrFcA@mail.gmail.com>
Message-ID: <6071258e-83f7-da7d-35a1-5f5ece216750@andrewnesbit.org>

On 18/01/2020 11:55, Álvaro Jurado wrote:
> IBM Watson is not that concept?

I don't want to go too off topic but out of all the cloud computing 
providers I think that IBM Cloud is the nicest in terms of its interface 
and functionality.

Does anybody else think the same?

I'm considering investing more of my time and resources into learning 
about it.  It certainly has the most interesting ecosystem.  It doesn't 
make me feel bombarded with information overload in the same way that 
AWS does[1].

Nevertheless I think it's useful to have at least one AWS EC2 machine if 
you're working professionally in the field of cloud computing and to 
know one's way around the UI.  It is, after all, the industry standard 
reference platform in this field.

Andrew

[1] https://www.lastweekinaws.com is the saving grace that makes the 
complicated AWS ecosystem understandable to me.
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From clemc at ccc.com  Tue Jan 21 03:19:25 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 12:19:25 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
Message-ID: <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>

On Sun, Jan 19, 2020 at 10:52 PM George Michaelson <ggm at algebras.org> wrote:

> It does me no credit, that I initially reacted very badly to 386BSD,
> and the initial {Net,Free,Open} situation.
>
First, be careful.   What we sometimes call 386BSD as a 'release' started
just as a port of NET2 to the 386 based 'commodity' hardware platform.  The
history is that in the late 1970s/early 80s Bill Jolitz was working for Nat
Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had
built, which was similar to the Stanford University Network (SUN) terminal
what had a 68000.  He eventually built a 'luggable' using that and updated
to the port to 4.2++.   He (and Lynn I believe) started a company to sell
that hardware/software solution and for whatever reason, it did not really
take off.

At some point, he got his hands on a 386based PC (Compaq I think) and
started to move his port over to that system.   A number of people helped
him (for instance I did a bunch of the AT/disk controller work as I had
access to the WD design documents for another consulting gig I had at the
time - Bill mentioned this in the articles BTW).

Bill and Lynn's NS16032 and 386 code went back to the CSRG 'masters' -
although how and that happened was never completely clear to me. The SCCS
deltas tell at least part of the story.     Bill managed to make a bootable
image that mostly installed on a PC/386 as the minicomputer versions did
from the formal release.   The ftp area of ucbvax had all of these bootable
images available for download such as one for an HP 68K system and I think
the DEC VAX and PMAX, the CCG system and a few others IIRC.  As I have said
in other messages if you were a UCB licensee you had the passwords to
look/download from that area.    Bill placed that version in the same ftp
area.  The 386 based port went viral at least with the UCB licensees.  (In
fact, if Linus had known about it, theoretically he could have used it
also.   His university was licensee, but as Larry McVoy likes to point, not
all the schools were as free with the IP, so I will not go down that
rathole).

The bottom line is that many people (like me on a Wyse386) started with
Bill's original port; including the BSDi founders.

When Jolitz and BSDi went separate ways, Jolitiz continued to update the
CSRG 386 based tarball (to an extent).  One of the issues was there
originally was attempt to keep the different architectural versions of BSD
in sync ( to a point and NetBSD does yet exist).    A number of people were
unhappy and the speed, depth *etc*. of the 386 version, most notably Jordan
Hubbard and FreeBSD was born.  The two biggest issues Jordan wanted to fix,
was easier install and a bit wider support for more hardware (again I sent
Jordan the changes to FreeBSN 1x for the Wyse and a couple of NCR boxes).
The NetBSD project would birth from the original ideals of CSRG and trying
to keep everything the same but that's still in the future.




>
> I found all this "fragmentation" pretty hard to understand. -BSDI felt
> like it had occupied the space, and I couldn't entirely understand
> what was going on, or why any of it mattered.
>
See below....




> What I think I missed (didn't understand) was how draining support was
> for Berkeley, and in the absence of a sugar daddy
>
Herein is the issue that many people on the sidelines missed.

CRSG was a large project and funded a lot of work at UCB in EECS. It never
funded me (I was funded by Tektronix, HP, DEC *et al*), but that project
did a fund a number of students.  However, at some point CSRG stopped being
a research project and started being a support project for DARPA.  There
was also a good deal of resentment by some groups in EECS that were not
getting DARPA funding.
I'll not say if that was good or bad but I will say that it did cause great
deal consternation at UCB within the department and many people doing more
formal research were not happy.    In the end, the EECS Department mothers
and fathers along with the Dean *et al*, decided to stop/end the CSRG
project.  Many people who were directly or indirectly working on BSD, like
Mary Ann and myself, had graduated and had since left.  Bob Kridle had
formed Mt. Xinu, Asa Romberger has formed Unisoft, Joy had left/was leaving
for Sun, *etc*.    So the question remained what to do with CSRG.   As to
what everyone would do, became every person for her/himself and as we know
some of the folks, along with a few folks from the USENIX community formed
BSDi.

As was noted elsewhere, NetBSD would eventually be formed by volunteers to
keep the different ports alive (in fact much of the efforts was from folks
not at UCB), but that was still in the offing.   Remember, while CSRG
itself was not a research project, a lot of people around the world were
using the BSD code base for their own research.  The whole idea of NetBSD
was to create a uniform platform that people could compare things.  So, the
question of how that was to come about or do any work on BSD if DARPA was
not paying the bills, was still an open one.  But, the idea that would
eventually create FreeBSD, was supporting a pure commodity *solution for
day-to-day use, not as a research platform*. [I'll leave off the later
OpenBSD/NetBSD fork by Theo here as it has little to do with the question].

BSDi had a similar/same goal of producing something like SunOS/VMS *etc* but
supported on commodity hardware.  That solution was to sell it and using
the revenues from the support contract, be able to pay people to do that
work.  As I said and in some other messages, it is noted that Bill Jolitz
wanted something more FOSS.   Truth is BSDi code was 'open source' but it
took a $1K license to *get the source from them*.

In the end, the real problem was not the infighting between the different
BSD camps, but AT&T, who wanted the entire pie.  Clearly, their executives
saw anything other than their complete control of the UNIX IP as a threat.
Hence the court case, the eventually AT&T/Sun relationship *etc*...

Your lack of 'sugar daddy,' really comes back to that.   There were few
people at the time that could pay the bills.  Until then DARPA had been
it.  I do not know if DARPA wanted out or if another group could have been
formed that could take over CSRG.  I did have discussions with Rob over a
beer that at least the thought had crossed the BSDi folks mind, that once
started; they would apply for a DARPA contract.

At the time had blow up, I was a consultant and I personally was
considering what I was going to do next and if they had had a real future,
the talks with Rob might have gotten more serious.   My wife wanted me to
stop being independent if we were to start a family (I would join Locus
instead).

BTW: I was in an interesting position as I was friends with all of the
different sides in the war/original fight.  Like Jolitz, I wanted to see
what we now call a 'FOSS' release of BSD.   But like Rob, I knew it was
going to take some revenue stream to make it happen/continue the support.
  In the end, the AT&T legal mess blew it all up.   BSDi ended up failing
and Jordan's work stayed around.

BTW: what pays for Linux development these days by number of 'committers
salary' is Intel (#1), IBM (#2), then a load of other firms including the
different distros.  But for *any* platform to be successful and actually
continue to be used in the market, someone has to pay the salaries of some
set of professional programmers to do the work.

That said when AT&T injoined BSDi and UCB a lot of people (myself included)
started to hack on Linux.  But just think if AT&T had actually won the case
and courts decided UNIX was allowed to be a trade secret, then Linux and
all of the UNIX 'clones' would have been in violation.

No matter what flavor of UNIX you like, we are all in debt to UCB and BSDi
for settling the IP argument.  The court was clear, the >>ideas<< behind
UNIX (*a.k.a.* the intellectual property) came from Ken, Dennis and friends
at AT&T and *they did own it.*   But because of the 1956 consent decree
that published the ideas and the moment the ideas were published, we all
can now >>use<< them.  The provenance of the source code does not relate to
the provenance of the idea, so* the source code itself does not define what
UNIX is or is not.  *

I bring this all up in hopes to try to close this rat hole of Linux, *vs*.
*BSD.   Like editors, we all have our own favorites.  That's cool, we don't
want one thing to be forced down our throat.  Having a choice is what is
good.   And what I value, Larry or Jon may not necessarily like.   Most of
us if not all on this list probably want something that approximates Ken
and Dennis's original ideas not what IBM, DEC, CDC were trying to make us
use in the old days or what Microsoft calls a system today.

The discussion of how we got there and what people valued at the time is
useful so we can try to remember the history and learn from it; but getting
into right/wrong, good/bad, or you could have had this is a tad tiresome;
IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/e99fc07a/attachment.html>

From steffen at sdaoden.eu  Tue Jan 21 03:40:06 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 20 Jan 2020 18:40:06 +0100
Subject: [TUHS] "What UNIX Cost Us"
In-Reply-To: <CAGM9nhRPfZA2s17ociJfUTyq6WGt1rsqq=796xGynRD9c3bZbg@mail.gmail.com>
References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com>
 <20200118203422.2c7o_%steffen@sdaoden.eu>
 <CAGM9nhRPfZA2s17ociJfUTyq6WGt1rsqq=796xGynRD9c3bZbg@mail.gmail.com>
Message-ID: <20200120174006.MYvii%steffen@sdaoden.eu>

Hello Kathry.

Kathryn Spiers wrote in <CAGM9nhRPfZA2s17ociJfUTyq6WGt1rsqq=796xGynRD9c3\
bZbg at mail.gmail.com>:
 |On Sat, Jan 18, 2020, 12:35 Steffen Nurpmeso <[1]steffen at sdaoden.eu[/1]> \
 |wrote:
 |
 |  [1] mailto:steffen at sdaoden.eu
 |
 ||Rich Morin wrote in <[2]5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com[/2\
 ||]>:
 || |FWIW, I found this talk to be quite amusing and interesting.
 || |
 || |"What UNIX Cost Us" - Benno Rice (LCA 2020)
 || |[3]https://www.youtube.com/watch?v=9-IWMbJXoLM[/3]
 |
 ||That is the one who mutilated the FreeBSD fortune program no?
 ||(Despite it saying
 |
 ||  The potentially offensive fortunes are installed by default on FreeBSD
 ||  systems.  If you're absolutely, *positively*, without-a-shadow-of-a-\
 ||doubt
 ||  sure that your user community goes berzerk/sues your pants off/drops \
 ||dead
 ||  upon reading one of them, edit the Makefile in the subdirectory \
 ||datfiles,
 ||  and do "make all install".)
 |
 ||Nothing but a hollow lie ever since!
 ...
 |Or you could remove the offensive fortunes and make the default more \
 |friendly for everyone...
 |
 |Probably best not to re-litigate that change on this thread though.

Maybe the latter.  But for the former.  A citation is a citation,
and whereas you can clean your house, with huge amounts of
desinfection and insecticides, you could claim but i promise it is
not clean, and never will be, yes, in fact you will not even stay
alive without a tremendous amount of bacteria and more inside of
you, and on your surface.  But you do end up in a deserted and
deadly place.

So you remove citations of Hitler which are prominently marked as
Hitler citations, because you claim that is less offensive and
makes the world a smoothie place, but i do not think so.  In the
thread by then i think i said something like "back in the 70s
people had the capability to see things in a context", you know,
and if _i_ see a Hitler citation, then i, not only but also
because i am German, put that in a tremendous, let me say in
a monstrous context.  And it is plain, dear Lady, that the demon
is not gone, it is in almost each and everyone.  And in _my_
opinion, the "cleaning" that has been done is nothing but
a trivialisation, which goes alongside a common flattening that
happens in public discourse in general.

This is nothing new, and people sang about "shiny happy people"
decades ago, and have by far not been the first which did.  If
i recall correctly, the actual argument on the removal, which if
i recall happened "just like that", without discussion or that
issue tracker that FreeBSD now uses, was because of a Hitler
citation on women.  If i recall correctly it was in turn
a citation which revealed that Hitler did not understand Nietzsche
correctly.  Maybe i understand Nietzsche false.  Nietzsche also
sings and dances alongside the road that Richard Wagner claimed
some decades before Nietzsches book we are talking about.  Hitler
also was impressed by Wagner's art and saying, yet, did he
understand it, really?  So we are now about enter the space of
culture, philosophy and religion, the human being and its way of
self-organization, about the necessity of self-reflection, as
called for, and named, by the mentioned.  Will you ever be able to
develop self-reflection without a context, dear Lady, i am asking?

Off-topic, whereas i blame Hitler, and the endless shame that comes
alongside -- and today in a week is the 75th anniversary of the
rescue, of the remains, of Auschwitz --, the older i get, the less
i can blame my forefathers desires.  I can stand this ground, and
it is good that after WWII the winners acted more wise and
reflected than after WWI.  And i thought it was Churchill, but
i think it has been John F. Kennedy who said ~"either mankind will
put an end on war, or war will put an end on mankind".

Citations have been placed in a Unix distribution, to come back to
the topic.  Decades ago.  I do not think it was a giggling funny
old man who put them there, but even a giggling funny old man has
decades of life to look onto.  I who approach my 50ies in a not
too distant future (if i am lucky) have already seen dozens of
dirty wars, thousands of lies, and aggressively put false contexts
which are not lies yet are lies indeed, and millions and millions
of terrible deaths, and maybe-death-would-have-been-better's, too.
I personally do not think this gets better if the public discourse
becomes even more superficial or even becomes the total farce of
misinformation as opposed to slight censorship, which happens in
the western world even without official propaganda, which i hate
to the bottom of my heart.

But i am not Mr. Clean, the falsely understood.  My only concern
on the MeToo that i hate, is that the Suffragettes get finally
blown away because those who came up short wanted to have a whole
evening on Netflix or the BBC (nice neighbours for sure),
exclusively.  I have not and never had problems with strong women,
they always existed, and my very personal point of view is in fact
that today we have a lot less of strong women with personality
than when i was young.  And ever and ever again i read and see
stories of strong women from more than hundred years ago, when
Germany indeed was a source of science, culture and beauty, too.
I cannot do anything against people who read the bible as an
operator's guide, nor mental hedgehoppers which do not get
Nietzsche nor Wagner right, but only Might and Money.  The problem
seems to be that these people govern the world.

No, the sticky and greasy cloud cover of misinformation and
superficiality sometimes has to be torn open, and i admire that
the *BSD fortune program took the opportunity to burst in the
focused and selfish view that most people, me included, have on
a day by day base.  And how often do i myself become conscious of
something that i did not understand first, take the line Wagner
.. Nietzsche, .. and the incapable brain which did not get it
thereafter .. and has been lifted to responsibility nonetheless!
(Just a few weeks ago my eyes were opened that the "Fonty" in
Günther Grass's "Ein weites Feld" was indeed Theodor Fontane.
Granted that i did not really "lived" in "Ein weites Feld", but
maybe ... i should read it again!  But that is just bla.)

And, dear Lady, whereas i like friendliness, i think it should be
wholehearted and holistic.  Removing some citations which, by the
very heart of a citation, have a context, in which they should be
contemplated, strives me as peculiar if at the same time we,
western world citizens, either directly or indirectly, by means of
our buying behaviour, for example, kill or suppress people, and
even destroy life on earth as such.
Regarding MeToo i am happy that here in Germany this overheated
thing has been normalizest; crimes are crimes, and need to be
punished (maybe i am an antisemit when i bring sympathy to the
Public Enemy text "Jeffrey Dahmer, into the room without cuffs --
how the hell do we get stuffed????  In the back of a cell on an
Isle.").  But what if Jack Nicholson would have not been brought
to go nuts in Shining, what if Brad Pitt would not have had to
repeat the scene where he drags the dead Hector dozens of times,
what if raped "bitches" (or non-bitches) would look like if they
come from a gala dinner.  That is just grazy.

I personally do not think that removing these citations made the
world a better place.  And whereas i also do not think that it
make the world a worse place, hah, i start hoping he could impress
a nice young women, they got married and have some kids.
A nice evening i wish,
Miss Kathryn Spiers,

--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 imp at bsdimp.com  Tue Jan 21 03:49:21 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Jan 2020 10:49:21 -0700
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
Message-ID: <CANCZdfrw7KUZjyaJ0eBxrn2S-VDrj5amY-YFD4B5sPEu==mHUQ@mail.gmail.com>

Thanks Clem.

One minor clarification.  Jordan and the patchkit work did predate NetBSD.
However, the NetBSD project formed a little before the FreeBSD project that
grew out of the patchkit days. Jordan didn't get that moving until NetBSD
made rumblings... it was still a time that you heard a lot of what was
going on by word of mouth, not so much by postings and email...

The OpenBSD split was years later... and a complicated mix of personality
conflicts and technical differences. But in many ways it was a smaller
split since for a long time they were almost 100% compatible at the driver
level (something you could never really say about net and free).

Warner

On Mon, Jan 20, 2020, 10:21 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Sun, Jan 19, 2020 at 10:52 PM George Michaelson <ggm at algebras.org>
> wrote:
>
>> It does me no credit, that I initially reacted very badly to 386BSD,
>> and the initial {Net,Free,Open} situation.
>>
> First, be careful.   What we sometimes call 386BSD as a 'release' started
> just as a port of NET2 to the 386 based 'commodity' hardware platform.  The
> history is that in the late 1970s/early 80s Bill Jolitz was working for Nat
> Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had
> built, which was similar to the Stanford University Network (SUN) terminal
> what had a 68000.  He eventually built a 'luggable' using that and
> updated to the port to 4.2++.   He (and Lynn I believe) started a company
> to sell that hardware/software solution and for whatever reason, it did not
> really take off.
>
> At some point, he got his hands on a 386based PC (Compaq I think) and
> started to move his port over to that system.   A number of people helped
> him (for instance I did a bunch of the AT/disk controller work as I had
> access to the WD design documents for another consulting gig I had at the
> time - Bill mentioned this in the articles BTW).
>
> Bill and Lynn's NS16032 and 386 code went back to the CSRG 'masters' -
> although how and that happened was never completely clear to me. The SCCS
> deltas tell at least part of the story.     Bill managed to make a bootable
> image that mostly installed on a PC/386 as the minicomputer versions did
> from the formal release.   The ftp area of ucbvax had all of these bootable
> images available for download such as one for an HP 68K system and I think
> the DEC VAX and PMAX, the CCG system and a few others IIRC.  As I have said
> in other messages if you were a UCB licensee you had the passwords to
> look/download from that area.    Bill placed that version in the same ftp
> area.  The 386 based port went viral at least with the UCB licensees.  (In
> fact, if Linus had known about it, theoretically he could have used it
> also.   His university was licensee, but as Larry McVoy likes to point, not
> all the schools were as free with the IP, so I will not go down that
> rathole).
>
> The bottom line is that many people (like me on a Wyse386) started with
> Bill's original port; including the BSDi founders.
>
> When Jolitz and BSDi went separate ways, Jolitiz continued to update the
> CSRG 386 based tarball (to an extent).  One of the issues was there
> originally was attempt to keep the different architectural versions of BSD
> in sync ( to a point and NetBSD does yet exist).    A number of people were
> unhappy and the speed, depth *etc*. of the 386 version, most
> notably Jordan Hubbard and FreeBSD was born.  The two biggest issues Jordan
> wanted to fix, was easier install and a bit wider support for more hardware
> (again I sent Jordan the changes to FreeBSN 1x for the Wyse and a couple of
> NCR boxes).  The NetBSD project would birth from the original ideals of
> CSRG and trying to keep everything the same but that's still in the future.
>
>
>
>
>>
>> I found all this "fragmentation" pretty hard to understand. -BSDI felt
>> like it had occupied the space, and I couldn't entirely understand
>> what was going on, or why any of it mattered.
>>
> See below....
>
>
>
>
>> What I think I missed (didn't understand) was how draining support was
>> for Berkeley, and in the absence of a sugar daddy
>>
> Herein is the issue that many people on the sidelines missed.
>
> CRSG was a large project and funded a lot of work at UCB in EECS. It never
> funded me (I was funded by Tektronix, HP, DEC *et al*), but that project
> did a fund a number of students.  However, at some point CSRG stopped being
> a research project and started being a support project for DARPA.  There
> was also a good deal of resentment by some groups in EECS that were not
> getting DARPA funding.
> I'll not say if that was good or bad but I will say that it did cause
> great deal consternation at UCB within the department and many people doing
> more formal research were not happy.    In the end, the EECS
> Department mothers and fathers along with the Dean *et al*, decided to
> stop/end the CSRG project.  Many people who were directly or indirectly
> working on BSD, like Mary Ann and myself, had graduated and had since
> left.  Bob Kridle had formed Mt. Xinu, Asa Romberger has formed Unisoft, Joy
> had left/was leaving for Sun, *etc*.    So the question remained what to
> do with CSRG.   As to what everyone would do, became every person for
> her/himself and as we know some of the folks, along with a few folks from
> the USENIX community formed BSDi.
>
> As was noted elsewhere, NetBSD would eventually be formed by volunteers to
> keep the different ports alive (in fact much of the efforts was from folks
> not at UCB), but that was still in the offing.   Remember, while CSRG
> itself was not a research project, a lot of people around the world were
> using the BSD code base for their own research.  The whole idea of NetBSD
> was to create a uniform platform that people could compare things.  So, the
> question of how that was to come about or do any work on BSD if DARPA was
> not paying the bills, was still an open one.  But, the idea that would
> eventually create FreeBSD, was supporting a pure commodity *solution for
> day-to-day use, not as a research platform*. [I'll leave off the later
> OpenBSD/NetBSD fork by Theo here as it has little to do with the question].
>
> BSDi had a similar/same goal of producing something like SunOS/VMS *etc* but
> supported on commodity hardware.  That solution was to sell it and using
> the revenues from the support contract, be able to pay people to do that
> work.  As I said and in some other messages, it is noted that Bill Jolitz
> wanted something more FOSS.   Truth is BSDi code was 'open source' but it
> took a $1K license to *get the source from them*.
>
> In the end, the real problem was not the infighting between the different
> BSD camps, but AT&T, who wanted the entire pie.  Clearly, their executives
> saw anything other than their complete control of the UNIX IP as a threat.
> Hence the court case, the eventually AT&T/Sun relationship *etc*...
>
> Your lack of 'sugar daddy,' really comes back to that.   There were few
> people at the time that could pay the bills.  Until then DARPA had been
> it.  I do not know if DARPA wanted out or if another group could have been
> formed that could take over CSRG.  I did have discussions with Rob over a
> beer that at least the thought had crossed the BSDi folks mind, that once
> started; they would apply for a DARPA contract.
>
> At the time had blow up, I was a consultant and I personally was
> considering what I was going to do next and if they had had a real future,
> the talks with Rob might have gotten more serious.   My wife wanted me to
> stop being independent if we were to start a family (I would join Locus
> instead).
>
> BTW: I was in an interesting position as I was friends with all of the
> different sides in the war/original fight.  Like Jolitz, I wanted to see
> what we now call a 'FOSS' release of BSD.   But like Rob, I knew it was
> going to take some revenue stream to make it happen/continue the support.
>   In the end, the AT&T legal mess blew it all up.   BSDi ended up failing
> and Jordan's work stayed around.
>
> BTW: what pays for Linux development these days by number of 'committers
> salary' is Intel (#1), IBM (#2), then a load of other firms including the
> different distros.  But for *any* platform to be successful and actually
> continue to be used in the market, someone has to pay the salaries of some
> set of professional programmers to do the work.
>
> That said when AT&T injoined BSDi and UCB a lot of people (myself
> included) started to hack on Linux.  But just think if AT&T had actually
> won the case and courts decided UNIX was allowed to be a trade secret, then
> Linux and all of the UNIX 'clones' would have been in violation.
>
> No matter what flavor of UNIX you like, we are all in debt to UCB and BSDi
> for settling the IP argument.  The court was clear, the >>ideas<< behind
> UNIX (*a.k.a.* the intellectual property) came from Ken, Dennis and
> friends at AT&T and *they did own it.*   But because of the 1956 consent
> decree that published the ideas and the moment the ideas were published, we
> all can now >>use<< them.  The provenance of the source code does not
> relate to the provenance of the idea, so* the source code itself does not
> define what UNIX is or is not.  *
>
> I bring this all up in hopes to try to close this rat hole of Linux, *vs*.
> *BSD.   Like editors, we all have our own favorites.  That's cool, we don't
> want one thing to be forced down our throat.  Having a choice is what is
> good.   And what I value, Larry or Jon may not necessarily like.   Most of
> us if not all on this list probably want something that approximates Ken
> and Dennis's original ideas not what IBM, DEC, CDC were trying to make us
> use in the old days or what Microsoft calls a system today.
>
> The discussion of how we got there and what people valued at the time is
> useful so we can try to remember the history and learn from it; but getting
> into right/wrong, good/bad, or you could have had this is a tad tiresome;
> IMO.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/380ab673/attachment-0001.html>

From lm at mcvoy.com  Tue Jan 21 04:04:32 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Jan 2020 10:04:32 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
Message-ID: <20200120180432.GJ28686@mcvoy.com>

On Mon, Jan 20, 2020 at 12:19:25PM -0500, Clem Cole wrote:
> On Sun, Jan 19, 2020 at 10:52 PM George Michaelson <ggm at algebras.org> wrote:
> 
> > It does me no credit, that I initially reacted very badly to 386BSD,
> > and the initial {Net,Free,Open} situation.
> >
> First, be careful.   What we sometimes call 386BSD as a 'release' started
> just as a port of NET2 to the 386 based 'commodity' hardware platform.  The
> history is that in the late 1970s/early 80s Bill Jolitz was working for Nat
> Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had
> built, which was similar to the Stanford University Network (SUN) terminal
> what had a 68000.  He eventually built a 'luggable' using that and updated
> to the port to 4.2++.   He (and Lynn I believe) started a company to sell
> that hardware/software solution and for whatever reason, it did not really
> take off.

I know those Nat Semi chips very well, or did at the time.  I so wanted to
love those chips, the instruction set felt like whoever did the PDP-11
did the 320xx chips.  But they couldn't produce chips without bugs and
that killed them.  It's a crying shame, I liked the instruction set
WAY better than the VAX.  The VAX seemed really messing compared to 
the PDP-11, the 320xx chips seemed clean.  Might be rose colored 
glasses but that's my memory.

From david at kdbarto.org  Tue Jan 21 04:09:55 2020
From: david at kdbarto.org (David Barto)
Date: Mon, 20 Jan 2020 10:09:55 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200120180432.GJ28686@mcvoy.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
Message-ID: <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org>

On Jan 20, 2020, at 10:04 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Mon, Jan 20, 2020 at 12:19:25PM -0500, Clem Cole wrote:
>> On Sun, Jan 19, 2020 at 10:52 PM George Michaelson <ggm at algebras.org> wrote:
>> 
>>> It does me no credit, that I initially reacted very badly to 386BSD,
>>> and the initial {Net,Free,Open} situation.
>>> 
>> First, be careful.   What we sometimes call 386BSD as a 'release' started
>> just as a port of NET2 to the 386 based 'commodity' hardware platform.  The
>> history is that in the late 1970s/early 80s Bill Jolitz was working for Nat
>> Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had
>> built, which was similar to the Stanford University Network (SUN) terminal
>> what had a 68000.  He eventually built a 'luggable' using that and updated
>> to the port to 4.2++.   He (and Lynn I believe) started a company to sell
>> that hardware/software solution and for whatever reason, it did not really
>> take off.
> 
> I know those Nat Semi chips very well, or did at the time.  I so wanted to
> love those chips, the instruction set felt like whoever did the PDP-11
> did the 320xx chips.  But they couldn't produce chips without bugs and
> that killed them.  It's a crying shame, I liked the instruction set
> WAY better than the VAX.  The VAX seemed really messing compared to 
> the PDP-11, the 320xx chips seemed clean.  Might be rose colored 
> glasses but that's my memory.


My memory as well. A friend and I got ahold of the complete set of chips
and started to build out the hardware for a Unix box. We got most of the
way there too, and then the odd quirks started showing up. We tracked
some of them to our layout and the others to the NS chips. Then we gave
it up as a “ah, it would have been nice if only” project.

	David


From krewat at kilonet.net  Tue Jan 21 04:34:40 2020
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 20 Jan 2020 13:34:40 -0500
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org>
Message-ID: <b55bfc3a-2d71-13c1-43f4-d05b5cbd0164@kilonet.net>

On 1/20/2020 1:09 PM, David Barto wrote:
> My memory as well. A friend and I got ahold of the complete set of chips
> and started to build out the hardware for a Unix box. We got most of the
> way there too, and then the odd quirks started showing up. We tracked
> some of them to our layout and the others to the NS chips. Then we gave
> it up as a “ah, it would have been nice if only” project.
A friend of mine and I did the same, but with 68000. I wrote the 
assembler and other utilities, he did the hardware design (although we 
both took turns critiquing each other's work), and we both (and his 
girlfriend) did the wire-wrapping.

We were eventually consumed by other real-life happenings, and it fell 
by the wayside, but looking back at it now, UNIX would have been the 
perfect choice. I did have visions of grandeur that I would write my own 
OS for it - I'm sure I would have eventually learned my lesson ;)

art k.

PS: We cheated, and used static RAM. A few failed development projects 
at my (then) current place of employment, and no one knew what to do 
with "all these chips" that were left over. No problem, I know what to 
do with them... they wound up in the trunk of my Triumph TR7



From clemc at ccc.com  Tue Jan 21 05:00:45 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 14:00:45 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CANCZdfrw7KUZjyaJ0eBxrn2S-VDrj5amY-YFD4B5sPEu==mHUQ@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <CANCZdfrw7KUZjyaJ0eBxrn2S-VDrj5amY-YFD4B5sPEu==mHUQ@mail.gmail.com>
Message-ID: <CAC20D2NP4FTKLKsYXsK6BS=b2Scs7Tv=bAZznefVAgauur0B2w@mail.gmail.com>

On Mon, Jan 20, 2020 at 12:49 PM Warner Losh <imp at bsdimp.com> wrote:

> Thanks Clem.
>
Most welcome

>
> One minor clarification.  Jordan and the patchkit work did predate NetBSD.
> However, the NetBSD project formed a little before the FreeBSD project that
> grew out of the patchkit days. Jordan didn't get that moving until NetBSD
> made rumblings...
>
Right - if I was not clear, on that ordering, mei culpa.


> it was still a time that you heard a lot of what was going on by word of
> mouth, not so much by postings and email...
>
Exactly.


>
> The OpenBSD split was years later... and a complicated mix of personality
> conflicts and technical differences.
>
A real shame IMO, but giving the personalities, I'm not sure it was not
predestined,



> But in many ways it was a smaller split since for a long time they were
> almost 100% compatible at the driver level
>
Very true, I run OpenBSD on my router/main server - I just want a minimum
system, that I feel it safe.
I have NetBSD on a couple of boxes cause it runs and FreeBSD or Linux on
others.   And MacOS on my desktop.

I'm sort of, whatever gets the job done and I don't have to think too much
about it, but it's probably why the little incompatibilities drive me nuts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/44715410/attachment.html>

From tytso at mit.edu  Tue Jan 21 05:09:00 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Mon, 20 Jan 2020 14:09:00 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <m1itNo9-0036tPC@more.local>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
Message-ID: <20200120190900.GH15860@mit.edu>

On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote:
> > Out of curiosity, did the articles contain download information for a
> > bootable copy of 386BSD?
> 
> Yes, they did:
> 
>      https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800

.... which is dated July 1992, and describes a "launch" of 386BSD
Release 0.0 in March 17, 1992.  This is contemporaneous with Linux
0.95a (which by coincidence was also released on March 17th, 1992.)

The first "real" distribution, the Soft Landing System, was released
in May 1992.  (The Manchester Computer Centre distribution in November
1991 was a floppy-based distro containing command-line and development
utilities, but not X Windows, so some people don't feel it counts as a
full-featured distribution.)

> Also keep in mind that NetBSD started as a set of "net" (as in usenet)
> patch kits for 386BSD.

It looks like NetBSD's source code repository was established on March
21, 1993.  Patchkit 0.2.2 was apparently also released on the same
date.  NetBSD's first release, 0.8, was released on April 19, 1993.

The FreeBSD project was named in June 19, 1993, with its first release
in November 1993.

So it's easy to use the lawsuit as the scapegoat for why the BSD's
failed to take off, but at best it's only one of many factors.  The
Jolitzs' refusal to accept many patches, forcing a delay of a year
before spawning two project forks, was one.  The dispersal of effort
as a side effect of various people trying to start companies around
BSD code (SunOS, NetApp, BSDI, Wasabi Systems, etc.)  was another.
BSD-licensed code seems to thrive best when there are grants or
non-profit institutions funding its work; but attempts to support BSD
code from as part of commercial work doesn't seem to have worked out
as well.

As dwheeler (I think Dave Wheeler, but I'm not certain) astutely
observed in 2006:

   I think the BSD license has been a lot of trouble to the
   *BSDs. Every few years, someone says, "hey, let's start a company
   based on this BSD code!" (BSD/OS in particular comes to mind, but
   SunOS and others did the same). They pull the *BSD code in, and
   some of the best BSD developers, and write a proprietary
   derivative. But as a proprietary vendor, their fork becomes
   expensive to self-maintain, and eventually the company
   founders. All that company work is lost forever, and good
   developers were sucked away during that period. Repeat, repeat,
   repeat. That's more than enough to explain why the BSDs manage to
   make steps forward, but just don't manage to maintain the pace of
   Linux kernel development.

   Meanwhile, the GPL has legally enforced a consortia on major
   commercial companies. Red Hat, Novell, IBM, and many others are all
   contributing, and feel safe in doing so because the others are
   legally required to do the same. It's basically created a "safe"
   zone of cooperation, without anyone having to sign complicated
   legal documents. A company can't feel safe contributing code to the
   BSDs, because its competitors might simply copy it without
   reciprocating. There's much more corporate cooperation in the
   GPL'ed kernel code than with the BSD'd kernel code. Which means
   that in practice, it's actually been the GPL that's most
   "business-friendly". So while the BSDs have lost energy every time
   a company gets involved, the GPL'ed programs gain almost every time
   a company gets involved. And that explains it all.

   - https://lwn.net/Articles/197875/

I'll also note that the GPL licensing means that I've been able to
carry my expertise in the code base across 4 job changes (MIT, VA
Linux Systems, IBM, Google).  In effect, this arrangement and the
business models forced by the GPL allocates more value to the
community at large and to the engineers working at those companies, at
the expense of value that can be extracted to the corporate
shareholders --- for better or for worse.

And so while I don't have a private jet like some of the early
founders of Sun, NetApp, et. al., and I'm still a working stiff, I
lead a comfortable life, and it seems like a good tradeoff to me.  :-)

In the long run, it might be interesting to see how the Illumos (Open
Solaris) derivatives fare compared to Free/Net/Open/Dragon BSD's.
There seem to be some interesting cooperation from the set of
companies that use Illumos, which is encouraged by the CDDL's weak
provisions.  So if Illumos and its derivatives are able to overtake
*BSD's despite the *BSD's having an earlier start, that might be an
interesting confirmation of dwheeler's point above.

					- Ted

From clemc at ccc.com  Tue Jan 21 05:18:48 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 14:18:48 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200120180432.GJ28686@mcvoy.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
Message-ID: <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>

On Mon, Jan 20, 2020 at 1:04 PM Larry McVoy <lm at mcvoy.com> wrote:

> I know those Nat Semi chips very well, or did at the time.  I so wanted to
> love those chips, the instruction set felt like whoever did the PDP-11
> did the 320xx chips.

It was clear, the NS folks, like the Moto folk, knew the PDP-11 and VAX.
 It was a nice architecture and should been a win but...



> But they couldn't produce chips without bugs and that killed them.

I really think it was they were the third man and too late.   Between Apple
on the Mac and Apollo, Masscomp and eventually Sun, the 68000 and later
68010 had volume.   8086 family had volume with the PC.

As Jon can tell you, Tektronix decided the use the NS chip and tossed a
working 68000/68010 design (Magnolia - which would later ship at 4400) for
a completely new workstation.  But it meant starting from scratch.   Big
mistake...

If they had just shipped Magnolia at the beginning, I'm not sure either
Masscomp or Sun would have been birthed.   Apollo and Triple-Drip were
already there, but thy would have had the first UNIX workstation on the
market, with a super graphics system.  Sigh....



> It's a crying shame, I liked the instruction set
> WAY better than the VAX.  The VAX seemed really messing compared to
> the PDP-11, the 320xx chips seemed clean.  Might be rose colored
> glasses but that's my memory.

I would not say way better, but much cleaner.  To DEC's credit, the idea of
the VAX was to take the PDP-11 forward and keep things running.   Funny, DG
did that better in the end, but that was the idea at least.   NS was trying
to make the VAX without the rough edges, mistakes DEC had made.  Prof. Yale
Patt consulted on both Instructions sets BTW, which may be why they look so
similar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/f7f4cdaf/attachment.html>

From tytso at mit.edu  Tue Jan 21 05:40:57 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Mon, 20 Jan 2020 14:40:57 -0500
Subject: [TUHS] Shell Level...
In-Reply-To: <1itSE0-5Td-00@marmaro.de>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de>
Message-ID: <20200120194057.GI15860@mit.edu>

On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote:
> Hoi.
> 
> [2020-01-19 14:22] Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> >
> > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?
> 
> What's the use of it? The only use of $SHLVL I can think of is the
> answer to the question if ^D will close the last shell or just a
> sub shell. I hardly ever ask myself this question. Probably that
> starts to become relevant when you open sub shells frequently.

<Raises hand>

The normal reason why I'm starting subshells is because I need to
control various environment variables on an ad-hoc basis.  It might be
PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some
combination of the above.  Back when I was regularly using Kerberos
root/admin bits, I had some hard-coded shell aliases to indicate
explicitly I was in a shell that was using my
tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU kerberos
tickets.

But for ad-hoc use cases, SHLVL is great way to track whether I'm a
non-standard shell environment.  For me, some use case probably comes
up at least week or two.

> With tmux or screen at hand, this use case is obsolete for me.
> (Besides, my shell doesn't know about $SHLVL.)

Before I was using bash regularly, I had hard-coded something like
SHLVL in my .tcshrc.

						- Ted

From jon at fourwinds.com  Tue Jan 21 05:46:05 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 20 Jan 2020 11:46:05 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
Message-ID: <202001201946.00KJk5er3071186@darkstar.fourwinds.com>

Clem Cole writes:
>
> On Mon, Jan 20, 2020 at 1:04 PM Larry McVoy <lm at mcvoy.com> wrote:
>
> > I know those Nat Semi chips very well, or did at the time.  I so wanted to
> > love those chips, the instruction set felt like whoever did the PDP-11
> > did the 320xx chips.
>
> It was clear, the NS folks, like the Moto folk, knew the PDP-11 and VAX.
>  It was a nice architecture and should been a win but...
>
> > But they couldn't produce chips without bugs and that killed them.
>
> I really think it was they were the third man and too late.   Between Apple
> on the Mac and Apollo, Masscomp and eventually Sun, the 68000 and later
> 68010 had volume.   8086 family had volume with the PC.
>
> As Jon can tell you, Tektronix decided the use the NS chip and tossed a
> working 68000/68010 design (Magnolia - which would later ship at 4400) for
> a completely new workstation.  But it meant starting from scratch.   Big
> mistake...
>
> If they had just shipped Magnolia at the beginning, I'm not sure either
> Masscomp or Sun would have been birthed.   Apollo and Triple-Drip were
> already there, but thy would have had the first UNIX workstation on the
> market, with a super graphics system.  Sigh....
>
> > It's a crying shame, I liked the instruction set
> > WAY better than the VAX.  The VAX seemed really messing compared to
> > the PDP-11, the 320xx chips seemed clean.  Might be rose colored
> > glasses but that's my memory.
>
> I would not say way better, but much cleaner.  To DEC's credit, the idea of
> the VAX was to take the PDP-11 forward and keep things running.   Funny, DG
> did that better in the end, but that was the idea at least.   NS was trying
> to make the VAX without the rough edges, mistakes DEC had made.  Prof. Yale
> Patt consulted on both Instructions sets BTW, which may be why they look so
> similar.

I remember it slightly differently than Clem, but close.  The Magnolia wasn't
a UNIX workstation, it was an experimental Smalltalk machine.  I don't recall
much about it, but I don't think that it had to address many of the problems
that UNIX had at the time with the 68000 such as the lack of a MMU.  I think
that the Magnolia predated the 68010 and certainly predated the 68020 and
awful but usable PMMU.  There were also many political issues because by this
time the legacy of Howard Vollum had departed Tektronix and it was starting to
die the slow death of a poorly managed company being looted by top management
which has become all too common since.  But at least Tek lead in something!

Part of the issue was that the Magnolia was developed in Tek Labs, which was
the research end of things.  It wasn't a product organization, the Magnolia
at the time hadn't gone through any of the rigorous environmental testing
required by Tek which was a company that actually provided warranty service.
And there was no marketing, not that Tek was a marketing powerhouse.  Given
the way that things panned out I don't think that the Magnolia would have been
a player once things like Suns appeared, if for no other reason that Tek had no
clue as to how to do anything in volume and our stuff was way too expensive.

The 32032 made sense for the workstation division based on the data sheets.
But, it turned out to be extremely buggy, and unlike the 68K I don't recall
the ability to look at and patch the state of the microcode.

In any case, while the 32032 was a problem, the real reason that Tek failed
in the workstation biz was management.  What happened was that programmable
instrumentation was becoming a thing.  Every instrument group in the company
was building their own "controller" for instrument programming.  In a rare
case of good decision-making it was decided that a single group would build
a controller that everyone else would use; this was the workstation division.
But, this took the most fun thing away from all of the other groups.  They
way that management structured things, instrument groups have to use the
workstation unless it was missing something that they required.  The result
was that the workstation had to meet the union of all requirements, real or
imagined.  The I/O board in this thing had like 4 GPIB ports, 24 RS-232 ports,
8 RS-422 ports (I don't remember the exact number), and so on, making it more
expensive than anybody else's CPU board.  Of course, when the IBM PC came along
all of the instrument groups said "well, we have 2 RS-232 ports and a parallel
port and so we'll work with that."  Had management said that the workstation
group could do what was reasonable and that everyone would have to adapt and
use it we could have parallel groups competing on 32K and 68K designs.

Jon

From clemc at ccc.com  Tue Jan 21 05:51:52 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 14:51:52 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200120190900.GH15860@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <20200120190900.GH15860@mit.edu>
Message-ID: <CAC20D2M7H0DFtmU2vvue0nszn=ddpYGhw0TQkq3oEVOJfRxfpg@mail.gmail.com>

On Mon, Jan 20, 2020 at 2:10 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:

> .... which is dated July 1992, and describes a "launch" of 386BSD

Ouch....  this is why people get confused. I'm probably not helping by not
being precise enough.

386/Net/Free/OpenBSD as >>projects<< are different from the original 386
work that Bill and Lynn did to get it running on the first 386 and get that
code back into the CRSG project.   The 386 was released in 1985 by Intel.
A number of firms started to use it.  Wikipedia says Compaw was first (The
Compaq Deskpro 386/25 was '89 according to google and we used a Wyse 32:16
at Stellar before that).  Bill Jolitz did is work originally on a Multibus
based 386 from Intel (using his NS system to bootstrap) and moved it to the
PC (I thought a Deskpro) shortly after it started to ship.

Most of us call that work '386BSD' but it was 4.X BSD that booted on a 386
based PC and not really what you are discussing.  These bits are/were the
'hidden' ftp - which is not to be confused with the first BSD 'distro' for
the 386 which would be much more public,

BTW: The original BSD on a 386, install was very rough.   Bill had created
the boot floppies on his NS system.   You had a use a DOS program to create
them via an image copy and the boot was really funky.   As I said, the
original AT driver was wrong, and kept getting hosed until I fixed it when
I was consulting for NCR (on their 386 system in 1989).   IIRC Jolitz had
created it by looking at that Minx AT driver and made some guess.   I had
(think I still have) the WD1003 documents, so I knew what the registers
really looked like and it was not handling some error conditions IIRC.

And the naming is really the root of the whole argument BTW....   BSD 4.x
for a 386 based system *vs.* a real distribution.   Bill Jolitz tried to
make a better release for a BSD on a 386 (*a.k.a.* 386BSD)  The install for
a PC/386 improved. IIRC, Intel had paid CMU to do some work as part of
Andrew and the Mach stuff (Bob Barron was the author of this I believe).,
 They wrote a version fdisk, and a bunch of things to allow dual booting
and some other tools that ran on DOS.  I don't remember how, but Bill
Jolitz got that code and very early on the BSD 386 port used it - probably
as part of the CMU/Mach to CSRG push/intermixing.

And later on yet to Jordan's credit, and it was after Linux, NetBSD, *etc*
was all there, that FreeBSD, completely redid the install scripts and made
the system that pretty much is the model for all current PC based systems
now.   In fact, around that time I had started work with Linux and one of
the things liked about FreeBSD 1.x was the install compared to the
original  Linus package (although I had an early Slackware pretty earlier
in my Linux time and that improved things).  I think your comment and about
the healthy competition was true, each team was trying to do better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/9304afee/attachment.html>

From clemc at ccc.com  Tue Jan 21 06:15:55 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 15:15:55 -0500
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
Message-ID: <CAC20D2O5wHbEdVKCR7VHVoyeLzoQO9XT3dy=UqeAPGqybLYu3w@mail.gmail.com>

On Mon, Jan 20, 2020 at 2:47 PM Jon Steinhart <jon at fourwinds.com> wrote:

> I remember it slightly differently than Clem, but close.

Ouch -- I was 1/2 of the Magnolia development team -- I remember a lot
about it!!!
For the curious when bitsavers comes back:   <goog_573452328>
http://bitsavers.trailing-edge.com/pdf/tektronix/magnolia/

Roger Bates had just finished the Dorado at PARC.  I had just left CMU.
 We were cubical mates in TekLabs.   Motorola had an experimental chip that
was not yet numbered.   We were given them in the Computer Research group
in Tek Labs. So, we started building a personal computer at night for
ourselves.

Our boss saw the notes and asked what we would do differently if Tek paid
for it.  I was originally using 8" floppies and immediately said 'a real
disk.'   We got a Tek '$10K project' and a few months to build a prototype.
I already had written (well sort of hacked) a simple C compiler based on
Dennis's PDP-11 compiler (when it screwed up it would sometimes include
PDP-11 code - and I never supported FP).   Paul Blattner wrote an assembler
and linker.     Using that, Steve Glaser and I ported UNIX/V7 to it.



> The Magnolia wasn't a UNIX workstation, it was an experimental Smalltalk
> machine.

That was 2+ years later actually.   Once they had the system, a couple of
other folks moved Smalltalk to it.  And in fact, it eventually did release
it as a product called the 4404.




> I don't recall
> much about it, but I don't think that it had to address many of the
> problems
> that UNIX had at the time with the 68000 such as the lack of a MMU.

Be careful... It most definitely did have an MMU, I designed it!!!  The
Xerox Altos and Dorado's never had MMU's.  So Roger was not familiar with
them.  I had to teach him.   Magnolia had a base/limit register MMU similar
to the PDP-11/70.  The original OS was V7 and swapped.  It ran just fine.



> I think
> that the Magnolia predated the 68010 and certainly predated the 68020 and
> awful but usable PMMU.

The wire-wrapped prototype was originally an X-series chip and yes the
first 'production' units were real 10Mhz 68000s.   After I went back to
grad school, Roger spliced a 68010 into and ripped out my MMU.  The late
Terry Laskodi put 4.1BSD on it.



> Part of the issue was that the Magnolia was developed in Tek Labs, which
> was
> the research end of things.  It wasn't a product organization, the Magnolia
> at the time hadn't gone through any of the rigorous environmental testing
> required by Tek which was a company that actually provided warranty
> service.
> And there was no marketing, not that Tek was a marketing powerhouse.  Given
> the way that things panned out I don't think that the Magnolia would have
> been
> a player once things like Suns appeared, if for no other reason that Tek
> had no
> clue as to how to do anything in volume and our stuff was way too
> expensive.
>
Very possible, but they did have first mover position.  In fact, folks at
Harvard Business as much as said so later.  There is a great HBS case study
written about it called "Why Skunk Projects Don't Work" (which I have
somewhere) -- I should get that scanned at added to the Magnolia archive on
BitSavers.




>
> In any case, while the 32032 was a problem, the real reason that Tek failed
> in the workstation biz was management.

No doubt... but it was 3 years later.   Which I think was a huge issue.




>  "well, we have 2 RS-232 ports and a parallel port and so we'll work with
> that."

Which of course was what Magnolia had been 3.5 years earlier and was what
became the 4404 Smalltalk machine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/943b2eff/attachment.html>

From clemc at ccc.com  Tue Jan 21 06:19:43 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Jan 2020 15:19:43 -0500
Subject: [TUHS] Distributed systems,
 was: On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
 <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
Message-ID: <CAC20D2OP6yrBOsqPCp=3B4zzp4uB2ExYbiQA50jYU8Se0KaO2A@mail.gmail.com>

On Sat, Jan 18, 2020 at 1:25 AM Rob Pike <robpike at gmail.com> wrote:

> I am convinced that large-scale modern compute centers would be run very
> differently, with fewer or at least lesser problems, if they were treated
> as a single system rather than as a bunch of single-user computers ssh'ed
> together.
>
+1


> But history had other ideas.
>
History and 'good' (cheap) enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/61cefecc/attachment.html>

From robpike at gmail.com  Tue Jan 21 06:28:39 2020
From: robpike at gmail.com (Rob Pike)
Date: Tue, 21 Jan 2020 07:28:39 +1100
Subject: [TUHS] Unix quix
Message-ID: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>

I reposted the original Unix quiz, which disappeared when public Google
Plus was turned off. Answers will reappear in a few days.

https://commandcenter.blogspot.com/2020/01/unix-quiz.html

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/34b1683e/attachment.html>

From athornton at gmail.com  Tue Jan 21 07:06:45 2020
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 20 Jan 2020 14:06:45 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
Message-ID: <E940C80D-E4B9-4FCF-B579-9AD3853458CF@gmail.com>

On Jan 20, 2020, at 1:28 PM, Rob Pike <robpike at gmail.com> wrote:
> I reposted the original Unix quiz, which disappeared when public Google Plus was turned off. Answers will reappear in a few days.
> 
> https://commandcenter.blogspot.com/2020/01/unix-quiz.html <https://commandcenter.blogspot.com/2020/01/unix-quiz.html>

I am slightly terrified that I can answer a non-trivial fraction (though by no means a majority!) of these without looking up answers.

The TSO one in particular I knew instantly and it’s still quite true.

I don’t know the story behind #23 but I certainly want to.

Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/f6afd459/attachment.html>

From woods at robohack.ca  Tue Jan 21 09:04:33 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Mon, 20 Jan 2020 15:04:33 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200120190900.GH15860@mit.edu>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <20200120190900.GH15860@mit.edu>
Message-ID: <m1itg5x-0036tRC@more.local>

At Mon, 20 Jan 2020 14:09:00 -0500, "Theodore Y. Ts'o" <tytso at mit.edu> wrote:
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")
>
> On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote:
> > > Out of curiosity, did the articles contain download information for a
> > > bootable copy of 386BSD?
> >
> > Yes, they did:
> >
> >      https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800
>
> .... which is dated July 1992, and describes a "launch" of 386BSD
> Release 0.0 in March 17, 1992.  This is contemporaneous with Linux
> 0.95a (which by coincidence was also released on March 17th, 1992.)

Yes, though as I recall all of the articles mentioned that the OS could
be downloaded, but I pointed at that final article as it was the first
one in which I found explicit mention of the FTP server name(s).

> The first "real" distribution, the Soft Landing System, was released
> in May 1992.  (The Manchester Computer Centre distribution in November
> 1991 was a floppy-based distro containing command-line and development
> utilities, but not X Windows, so some people don't feel it counts as a
> full-featured distribution.)

The actual 386bsd Release 0.0 (the one done directly by Bill and Lynne
Jolitz) announcement is dated "March 7, 1992" according to the first
post about it on comp.unix.bsd (and according to that announcement there
was a meeting at Apple in Cupertino (SVNet) on the 11'th where copies of
the floppies were made available for copying (comp.unix.bsd:
<2763 at tardis.Tymnet.COM>).

Note that according to an article from Unigram ("Issue 396", dated
August 3-7, 1992, (p)re-posted by Tom Limoncelli in comp.unix.bsd) this
"386bsd 0.0" was actually a re-write of earlier work to create a "386"
based release of BSD.  Apparently UCB lawyers asked Jolitz to destroy
all the initial work done for the release, and he complied and rewrote
what became 0.0 from scratch again, starting with the plain NET2
release.  (comp.unix.bsd: <1992Aug1.020513.14170 at plts.uucp>)

I would argue that in one way of looking at things NetBSD (and by
extension FreeBSD) really started with the 0.0 patch kit, and that's
also dated March 15, 1992 by Chris Demetriou.  I agree though that the
creation of the first commits in the CVS repository represent a more
direct reflection of the intent to create a unique thing called NetBSD.

(On March 13, 1992 there was a post by Mike Stump on comp.unix.bsd
asking for someone to coordinate patches for 386bsd; and Pace Willisson
posted the first patch in response on March 14, 1992; and Chris replied
on the same day saying he would put such patches up on
agate.berkeley.edu; and the "README.PATCHES" file appeared there on
March 15, 1992.)

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/6a4067c5/attachment-0001.sig>

From woods at robohack.ca  Tue Jan 21 09:43:44 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Mon, 20 Jan 2020 15:43:44 -0800
Subject: [TUHS] Shell Level...
In-Reply-To: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
Message-ID: <m1itghs-0036tPC@more.local>

At Sun, 19 Jan 2020 14:22:29 -0700, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
Subject: [TUHS] Shell Level...
>
> Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?

I invented my own variant, $LEV, for Ksh, starting before 1993, probably
when I first started using DMD-5620 terminals and layers, though
possibly slightly before that when I first started using Ksh (about 1989
when I bought a used ATT3B2/400 for home use).  I used my own $LEV in my
prompt (or the window title, if using a windowing system) just to remind
me if I'd started a sub-shell for some reason, such as in order to
preserve my current working directory and environment.

Early Ksh didn't have $SHLVL, and it's not universal (i.e. POSIX), so
I've never really used $SHLVL itself (though I have very recently added
a hook to set my $LEV from it IFF it is available).

See https://github.com/robohack/dotfiles  :-)

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/6ea54384/attachment.sig>

From terry at jon.es  Tue Jan 21 09:51:33 2020
From: terry at jon.es (Terry Jones)
Date: Tue, 21 Jan 2020 00:51:33 +0100
Subject: [TUHS] Shell Level...
In-Reply-To: <20200120194057.GI15860@mit.edu>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu>
Message-ID: <CACqnu4UhqiJ-iJdbN57dFRrpZ8E63E4gBNCNgRiymdaFWkXwew@mail.gmail.com>

I also make new shells fairly regularly, about half the time because I wan
to set some variables that I don't want to have to reset.  Then if/when I
forget which window I was in, I can check with SHLVL (at least when using
bash, which I normally don't do).  But I'm normally in & out of the
sub-shells very quickly so don't often need to check.

Terry


On Mon, Jan 20, 2020 at 8:43 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote:
> > Hoi.
> >
> > [2020-01-19 14:22] Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> > >
> > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of
> Unix?
> >
> > What's the use of it? The only use of $SHLVL I can think of is the
> > answer to the question if ^D will close the last shell or just a
> > sub shell. I hardly ever ask myself this question. Probably that
> > starts to become relevant when you open sub shells frequently.
>
> <Raises hand>
>
> The normal reason why I'm starting subshells is because I need to
> control various environment variables on an ad-hoc basis.  It might be
> PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some
> combination of the above.  Back when I was regularly using Kerberos
> root/admin bits, I had some hard-coded shell aliases to indicate
> explicitly I was in a shell that was using my
> tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU kerberos
> tickets.
>
> But for ad-hoc use cases, SHLVL is great way to track whether I'm a
> non-standard shell environment.  For me, some use case probably comes
> up at least week or two.
>
> > With tmux or screen at hand, this use case is obsolete for me.
> > (Besides, my shell doesn't know about $SHLVL.)
>
> Before I was using bash regularly, I had hard-coded something like
> SHLVL in my .tcshrc.
>
>                                                 - Ted
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/ebf9b5f3/attachment.html>

From woods at robohack.ca  Tue Jan 21 09:55:47 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Mon, 20 Jan 2020 15:55:47 -0800
Subject: [TUHS] Shell Level...
In-Reply-To: <1itSE0-5Td-00@marmaro.de>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de>
Message-ID: <m1itgtX-0036tPC@more.local>

At Mon, 20 Jan 2020 09:15:56 +0100, markus schnalke <meillo at marmaro.de> wrote:
Subject: Re: [TUHS] Shell Level...
>
> What's the use of it? The only use of $SHLVL I can think of is the
> answer to the question if ^D will close the last shell or just a
> sub shell. I hardly ever ask myself this question. Probably that
> starts to become relevant when you open sub shells frequently.

I've always just used "set ignoreeof" (first in Csh and later in Ksh),
but just in my initial login shell (i.e. set in ~/.login), to prevent ^D
from logging me out.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/290fa18d/attachment.sig>

From imp at bsdimp.com  Tue Jan 21 10:13:48 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Jan 2020 17:13:48 -0700
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <m1itg5x-0036tRC@more.local>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <20200120190900.GH15860@mit.edu> <m1itg5x-0036tRC@more.local>
Message-ID: <CANCZdfraqvi+17VjWhyFqiNyxec_ecR8Zh2QDHYNcO2c=ExxEQ@mail.gmail.com>

On Mon, Jan 20, 2020, 4:06 PM Greg A. Woods <woods at robohack.ca> wrote:

> At Mon, 20 Jan 2020 14:09:00 -0500, "Theodore Y. Ts'o" <tytso at mit.edu>
> wrote:
> Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux -
> "an academic question")
> >
> > On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote:
> > > > Out of curiosity, did the articles contain download information for a
> > > > bootable copy of 386BSD?
> > >
> > > Yes, they did:
> > >
> > >
> https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800
> >
> > .... which is dated July 1992, and describes a "launch" of 386BSD
> > Release 0.0 in March 17, 1992.  This is contemporaneous with Linux
> > 0.95a (which by coincidence was also released on March 17th, 1992.)
>
> Yes, though as I recall all of the articles mentioned that the OS could
> be downloaded, but I pointed at that final article as it was the first
> one in which I found explicit mention of the FTP server name(s).
>
> > The first "real" distribution, the Soft Landing System, was released
> > in May 1992.  (The Manchester Computer Centre distribution in November
> > 1991 was a floppy-based distro containing command-line and development
> > utilities, but not X Windows, so some people don't feel it counts as a
> > full-featured distribution.)
>
> The actual 386bsd Release 0.0 (the one done directly by Bill and Lynne
> Jolitz) announcement is dated "March 7, 1992" according to the first
> post about it on comp.unix.bsd (and according to that announcement there
> was a meeting at Apple in Cupertino (SVNet) on the 11'th where copies of
> the floppies were made available for copying (comp.unix.bsd:
> <2763 at tardis.Tymnet.COM>).
>
> Note that according to an article from Unigram ("Issue 396", dated
> August 3-7, 1992, (p)re-posted by Tom Limoncelli in comp.unix.bsd) this
> "386bsd 0.0" was actually a re-write of earlier work to create a "386"
> based release of BSD.  Apparently UCB lawyers asked Jolitz to destroy
> all the initial work done for the release, and he complied and rewrote
> what became 0.0 from scratch again, starting with the plain NET2
> release.  (comp.unix.bsd: <1992Aug1.020513.14170 at plts.uucp>)
>
> I would argue that in one way of looking at things NetBSD (and by
> extension FreeBSD) really started with the 0.0 patch kit, and that's
> also dated March 15, 1992 by Chris Demetriou.  I agree though that the
> creation of the first commits in the CVS repository represent a more
> direct reflection of the intent to create a unique thing called NetBSD.
>

Lots of people were building CVS repos based on the patchkits... Chris
wasn't trying to start a project, but more was trying to find a way of
organizing everything that people were working on. At least that's what I
recall from the rumors I'd heard on campus after Chris visited Boulder...

Warner

(On March 13, 1992 there was a post by Mike Stump on comp.unix.bsd
> asking for someone to coordinate patches for 386bsd; and Pace Willisson
> posted the first patch in response on March 14, 1992; and Chris replied
> on the same day saying he would put such patches up on
> agate.berkeley.edu; and the "README.PATCHES" file appeared there on
> March 15, 1992.)
>
> --
>                                         Greg A. Woods <gwoods at acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
> Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200120/490caab4/attachment.html>

From bakul at bitblocks.com  Tue Jan 21 10:44:32 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 20 Jan 2020 16:44:32 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: Your message of "Mon, 20 Jan 2020 12:19:25 -0500."
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
Message-ID: <20200121004439.4A5AD156E448@mail.bitblocks.com>

On Mon, 20 Jan 2020 12:19:25 -0500 Clem Cole <clemc at ccc.com> wrote:
>
> I bring this all up in hopes to try to close this rat hole of Linux, *vs*.

Ha!

> *BSD.   Like editors, we all have our own favorites.  That's cool, we don't
> want one thing to be forced down our throat.  Having a choice is what is
> good.   And what I value, Larry or Jon may not necessarily like.   Most of
> us if not all on this list probably want something that approximates Ken
> and Dennis's original ideas not what IBM, DEC, CDC were trying to make us
> use in the old days or what Microsoft calls a system today.

I want an *evolution* of their original ideas. Instead we have
significantly more complicated systems which may be more
efficient but certainly a lot more bloaty and less flexible
(with a few exceptions). [Ties in with the single system idea]

> The discussion of how we got there and what people valued at the time is
> useful so we can try to remember the history and learn from it; but getting
> into right/wrong, good/bad, or you could have had this is a tad tiresome;
> IMO.

+1

From lars at nocrew.org  Tue Jan 21 16:58:12 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 21 Jan 2020 06:58:12 +0000
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <202001201946.00KJk5er3071186@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Mon, 20 Jan 2020 11:46:05 -0800")
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
Message-ID: <7wk15l70u3.fsf@junk.nocrew.org>

Jon Steinhart wrote:
> The 32032 made sense for the workstation division based on the data sheets.
> But, it turned out to be extremely buggy, and unlike the 68K I don't recall
> the ability to look at and patch the state of the microcode.

Did you have the ability to look at and patch the state of 68000
microcode?  How?

From clemc at ccc.com  Wed Jan 22 00:30:39 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 09:30:39 -0500
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <7wk15l70u3.fsf@junk.nocrew.org>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
Message-ID: <CAC20D2MP2Y0ef7pm-kLRi4ien436rf_5f37KX76XH07BptsriA@mail.gmail.com>

It's possible they added an internal register or two to help save the fault
State but I don't think so. We'd have to ask Les Crudele or Nick T. to be
sure.   As I understand it from my days of commuting with Les to Stellar
and his talking about the project on those trips, the only real difference
between the 68000 and 68010 was Nick's microcode which was in the mask.  I
think they may have stepped the mask in a few places for better yields but
I understand the impression that was not externally electrical different in
function.

[Les was the 68000's main logic designer and Nick wrote the microcode].

On Tue, Jan 21, 2020 at 1:59 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Jon Steinhart wrote:
> > The 32032 made sense for the workstation division based on the data
> sheets.
> > But, it turned out to be extremely buggy, and unlike the 68K I don't
> recall
> > the ability to look at and patch the state of the microcode.
>
> Did you have the ability to look at and patch the state of 68000
> microcode?  How?
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/5ded86ac/attachment.html>

From jon at fourwinds.com  Wed Jan 22 03:17:36 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 21 Jan 2020 09:17:36 -0800
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <7wk15l70u3.fsf@junk.nocrew.org>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
Message-ID: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>

Lars Brinkhoff writes:
> Jon Steinhart wrote:
> > The 32032 made sense for the workstation division based on the data sheets.
> > But, it turned out to be extremely buggy, and unlike the 68K I don't recall
> > the ability to look at and patch the state of the microcode.
>
> Did you have the ability to look at and patch the state of 68000
> microcode?  How?

My memory is very very very fuzzy on this.  I seem to recall that microcode
state was pushed onto a stack in certain cases, and that it was possible to
fix some problems there for certain weird cases relating to memory management.
That's all that I remember about it as that's not the part of things that I
was working on, just heard grumbles from other folks about it.

Jon

From imp at bsdimp.com  Wed Jan 22 03:22:38 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 21 Jan 2020 10:22:38 -0700
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
Message-ID: <CANCZdfph+LJhxS=ir68Kzi0ft-Pb+mtpMEFSYk5duVcSLcVsRw@mail.gmail.com>

On Tue, Jan 21, 2020, 10:18 AM Jon Steinhart <jon at fourwinds.com> wrote:

> Lars Brinkhoff writes:
> > Jon Steinhart wrote:
> > > The 32032 made sense for the workstation division based on the data
> sheets.
> > > But, it turned out to be extremely buggy, and unlike the 68K I don't
> recall
> > > the ability to look at and patch the state of the microcode.
> >
> > Did you have the ability to look at and patch the state of 68000
> > microcode?  How?
>
> My memory is very very very fuzzy on this.  I seem to recall that microcode
> state was pushed onto a stack in certain cases, and that it was possible to
> fix some problems there for certain weird cases relating to memory
> management.
> That's all that I remember about it as that's not the part of things that I
> was working on, just heard grumbles from other folks about it.
>

This isn't for the two cpu design to allow instructions to be restarted
after a page fault.

Warner

Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/dc12da82/attachment.html>

From jon at fourwinds.com  Wed Jan 22 03:25:34 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 21 Jan 2020 09:25:34 -0800
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <CANCZdfph+LJhxS=ir68Kzi0ft-Pb+mtpMEFSYk5duVcSLcVsRw@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu>
 <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
 <CANCZdfph+LJhxS=ir68Kzi0ft-Pb+mtpMEFSYk5duVcSLcVsRw@mail.gmail.com>
Message-ID: <202001211725.00LHPYOO3282464@darkstar.fourwinds.com>

Warner Losh writes:
>
> On Tue, Jan 21, 2020, 10:18 AM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Lars Brinkhoff writes:
> > > Jon Steinhart wrote:
> > > > The 32032 made sense for the workstation division based on the data
> > sheets.
> > > > But, it turned out to be extremely buggy, and unlike the 68K I don't
> > recall
> > > > the ability to look at and patch the state of the microcode.
> > >
> > > Did you have the ability to look at and patch the state of 68000
> > > microcode?  How?
> >
> > My memory is very very very fuzzy on this.  I seem to recall that microcode
> > state was pushed onto a stack in certain cases, and that it was possible to
> > fix some problems there for certain weird cases relating to memory
> > management.
> > That's all that I remember about it as that's not the part of things that I
> > was working on, just heard grumbles from other folks about it.
> >
>
> This isn't for the two cpu design to allow instructions to be restarted
> after a page fault.
>
> Warner
>
> Jon

No, this was using a 68020 with the PMMU.

From nobozo at gmail.com  Wed Jan 22 03:52:20 2020
From: nobozo at gmail.com (Jon Forrest)
Date: Tue, 21 Jan 2020 09:52:20 -0800
Subject: [TUHS] Unix on Zilog Z8000?
Message-ID: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>

There's been a lot of discussion about early Unix on Intel, National
Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
the Z8000, and if not, why not.

As I remember the Z8000 was going to be the great white hope that
would continue Zilog's success with the Z80 into modern times.
But, it obviously didn't happen.

Why?

Jon

From usotsuki at buric.co  Wed Jan 22 04:13:13 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 21 Jan 2020 13:13:13 -0500 (EST)
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <alpine.BSF.2.02.2001211312550.63702@frieza.hoshinet.org>

On Tue, 21 Jan 2020, Jon Forrest wrote:

> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
> Jon
>

Didn't Coherent run on the Z8K?  Though that's not really Unix.

-uso.

From henry.r.bent at gmail.com  Wed Jan 22 04:15:53 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 21 Jan 2020 13:15:53 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>

On Tue, 21 Jan 2020 at 12:53, Jon Forrest <nobozo at gmail.com> wrote:

> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>

A tiny bit of research would have answered this question for you:
https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/cb04830e/attachment.html>

From lm at mcvoy.com  Wed Jan 22 04:20:45 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 21 Jan 2020 10:20:45 -0800
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
Message-ID: <20200121182045.GO26619@mcvoy.com>

On Tue, Jan 21, 2020 at 01:15:53PM -0500, Henry Bent wrote:
> On Tue, 21 Jan 2020 at 12:53, Jon Forrest <nobozo at gmail.com> wrote:
> 
> > There's been a lot of discussion about early Unix on Intel, National
> > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> > the Z8000, and if not, why not.
> >
> 
> A tiny bit of research would have answered this question for you:
> https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems

Yeah, it ran on the 16 bit one but I looked and couldn't find if they
got Unix on the z80000 (which I suspect is what Jon meant).

From pechter at gmail.com  Wed Jan 22 04:27:22 2020
From: pechter at gmail.com (William Pechter)
Date: Tue, 21 Jan 2020 13:27:22 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <alpine.BSF.2.02.2001211312550.63702@frieza.hoshinet.org>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <alpine.BSF.2.02.2001211312550.63702@frieza.hoshinet.org>
Message-ID: <455e1c85-8a45-4d20-8653-2274674608ef.maildroid@localhost>

IIRC... Zilog had Zeus (a SYSIII version) running.  Exxon Office Systems swallowed and regurgitated Zilog. They were a Vax customer in Princeton in the late '80s.  I installed one of the Vax 11/780s with the first RM80 I (and my office) ever saw as a brand new Field Service grunt. 

The US Internal Revenue Service was looking at replacing (Z8000 systems) them with AT&T sold Pyramid boxes when I was there.  Then they swallowed NCR and it all fell apart. This was around '94 or so. 

AT&T and Siemens were both Pyramid OEMs and were about 50% of Pyramid's business (I was told). Anyone have further info?   When Exxon pulled the plug on EOS I thing things were up in the air... 

Bill

Sent from pechter at gmail.com

-----Original Message-----
From: Steve Nickolas <usotsuki at buric.co>
To: Jon Forrest <nobozo at gmail.com>
Cc: The Unix Heritage Society mailing list <tuhs at tuhs.org>
Sent: Tue, 21 Jan 2020 13:14
Subject: Re: [TUHS] Unix on Zilog Z8000?

On Tue, 21 Jan 2020, Jon Forrest wrote:

> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
> Jon
>

Didn't Coherent run on the Z8K?  Though that's not really Unix.

-uso.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/2bc648a7/attachment.html>

From clemc at ccc.com  Wed Jan 22 04:28:14 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 13:28:14 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>

The Onyx box redated all the 68K and later Intel or other systems.   John
Bass brought one to USENIX to demo in early 1980 ru a V7 port and everyone
was blown away. Playing with it. It was a desktop (19" rack) system that
worked like a PDP-11.   I don't remember the bus, but I would guess it was
either custom or Multibus-I.

Besides being one of the first non-PDP-11 'ports', the original lockf(2)
system call was defined for the database that they had built.  John would
release the specs to /usr/group later.  I remember at one meeting in the
early 1980s discussing if file locking needed to be in the original
specification (Heinz probably remembers also as the chair of that
meeting).  I'm not at home, so I don't have the document to see if it was
picked up.  The argument was that serious computers like VMS or the like
ran real databases and without file locking UNIX would never be considered
a real OS that people could use.

BTW: Joy would later use Bass's call as a model for the 4.2 call, but Joy
made the locks advisory, Bass's version was full / mandatory locks.

FWIW: I think a search will pick up a number of other Z8000 based systems,
but Onyx was the first UNIX box.

On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest <nobozo at gmail.com> wrote:

> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/003a72b4/attachment.html>

From pechter at gmail.com  Wed Jan 22 04:32:17 2020
From: pechter at gmail.com (William Pechter)
Date: Tue, 21 Jan 2020 13:32:17 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
Message-ID: <32a4c33a-1382-4140-89cb-154b25c6d02b.maildroid@localhost>

IRS Pyramid buy and 3B2-Mips on Google. 

https://books.google.com/books?id=a4Jp5vySB-UC&pg=PA100&lpg=PA100&dq=Irs+to+buy+pyramid+at%26t&source=bl&ots=G_oVO6qpOx&sig=ACfU3U3EckPvlhXgj1NGrwhO1lsaBp3iWQ&hl=en&sa=X&ved=2ahUKEwjF1uy2qZXnAhVxmuAKHXhCCqEQ6AEwAHoECAEQAQ#v=onepage&q=Irs%20to%20buy%20pyramid%20at%26t&f=false
Sent from pechter at gmail.com

-----Original Message-----
From: Henry Bent <henry.r.bent at gmail.com>
To: Jon Forrest <nobozo at gmail.com>
Cc: The Unix Heritage Society mailing list <tuhs at tuhs.org>
Sent: Tue, 21 Jan 2020 13:17
Subject: Re: [TUHS] Unix on Zilog Z8000?

On Tue, 21 Jan 2020 at 12:53, Jon Forrest <nobozo at gmail.com> wrote:

> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>

A tiny bit of research would have answered this question for you:
https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/5f856c23/attachment.html>

From clemc at ccc.com  Wed Jan 22 04:43:10 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 13:43:10 -0500
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
Message-ID: <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com>

On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon at fourwinds.com> wrote:

> My memory is very very very fuzzy on this.  I seem to recall that microcode
> state was pushed onto a stack in certain cases,

State, not the code.

In fact, Masscomp having built the first MP UNIX box, ran into this problem
early on.  Different processor stepping had different internal microcode
state on the stack after an IRQ.  If you resumed with a processor that was
a different processor revision, the wrong state was returned.

Will may remember this, but Masscomp issues strick orders to the FE that
all CPU boards had to be the revision.  You could not just swap a CPU
board, they had to go as sets. It was a real bummer.

Moto fixed that with the 020 and later devices as more people made MP
systems.





> ...  just heard grumbles from other folks about it.
>
Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to figure
out that problem.   It was not originally documented, other than to state
on certain faults X bytes of reserved information was pushed on the stack.


BTS: I don't remember, but it may have started with the 68010.
 Becuase before that, the 'executor' was wait stated and the fixor handled
and fixed the fault so the 68000 never actually saw  fault in the original
Masscomp CPU board.   The "MPU" board was the same board with a couple of
PAL's changed and an 68010 as the executor.   It was allowed to actually
fault and do something else while the fixor corrected the fault.  But the
key is that when the fault was repaired, another executor on a different
MPU board could be the processor that 'returned' from the fault.   That
ended up being a no-no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/3f2cd2ee/attachment.html>

From clemc at ccc.com  Wed Jan 22 04:44:55 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 13:44:55 -0500
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
 <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com>
Message-ID: <CAC20D2MeAtw4fLoGbtqhVfH98xo1oFuAXXrnHfMXEnJLLK_R5w@mail.gmail.com>

sorry...    all *MPU* boards had to be the revision but we may have done
the same with the CPU boards.

On Tue, Jan 21, 2020 at 1:43 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
>> My memory is very very very fuzzy on this.  I seem to recall that
>> microcode
>> state was pushed onto a stack in certain cases,
>
> State, not the code.
>
> In fact, Masscomp having built the first MP UNIX box, ran into this
> problem early on.  Different processor stepping had different internal
> microcode state on the stack after an IRQ.  If you resumed with a processor
> that was a different processor revision, the wrong state was returned.
>
> Will may remember this, but Masscomp issues strick orders to the FE that
> all CPU boards had to be the revision.  You could not just swap a CPU
> board, they had to go as sets. It was a real bummer.
>
> Moto fixed that with the 020 and later devices as more people made MP
> systems.
>
>
>
>
>
>> ...  just heard grumbles from other folks about it.
>>
> Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to figure
> out that problem.   It was not originally documented, other than to state
> on certain faults X bytes of reserved information was pushed on the stack.
>
>
> BTS: I don't remember, but it may have started with the 68010.
>  Becuase before that, the 'executor' was wait stated and the fixor handled
> and fixed the fault so the 68000 never actually saw  fault in the original
> Masscomp CPU board.   The "MPU" board was the same board with a couple of
> PAL's changed and an 68010 as the executor.   It was allowed to actually
> fault and do something else while the fixor corrected the fault.  But the
> key is that when the fault was repaired, another executor on a different
> MPU board could be the processor that 'returned' from the fault.   That
> ended up being a no-no.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/e0fb5500/attachment.html>

From pete at nomadlogic.org  Wed Jan 22 05:02:38 2020
From: pete at nomadlogic.org (Pete Wright)
Date: Tue, 21 Jan 2020 11:02:38 -0800
Subject: [TUHS] Apollo Domain/OS
Message-ID: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>

Apologies that this isn't specifically a Unix specific question but I 
was wondering if anyone had insight in running domain/OS and it's 
relationship to Plan 9 (assuming there is any).

One of my early mentors was a former product person at Apollo in Mass. 
and was nice enough to tell me all sorts of war stories working there.  
I had known about Plan9 at the time, and from what he described to me 
about domain/OS it sounded like there was lots of overlap between the 
two from a high level design perspective at the least.  I've always been 
keen to understand if domain/OS grew out of former Bell Labs folks, or 
how it got started.

As an aside, he gifted me a whole bunch of marketing collateral from 
Apollo (from before the HQ acquisition) that i'd be happy to share if 
there is any historical value in that.  At the time I was a 
video/special effects engineer are was amazed at how beneficial having 
something like domain/OS or Plan9 would have been for us, it felt we 
were basically trying to accomplish a lot of the same goals by duct 
taping a bunch of Irix and Linux systems together.

Cheers,
-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA


From lm at mcvoy.com  Wed Jan 22 05:14:15 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 21 Jan 2020 11:14:15 -0800
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
Message-ID: <20200121191415.GT26619@mcvoy.com>

On Tue, Jan 21, 2020 at 11:02:38AM -0800, Pete Wright wrote:
> Apologies that this isn't specifically a Unix specific question but I was
> wondering if anyone had insight in running domain/OS and it's relationship
> to Plan 9 (assuming there is any).

It would be news to me if there was overlap.

I used apollos at my first job and hated them.  Diskless and slow as
molasses.  The first thing I did was port the cross compiler to the
Sun file server and did all my work there.

From imp at bsdimp.com  Wed Jan 22 05:14:45 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 21 Jan 2020 12:14:45 -0700
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <CAC20D2MeAtw4fLoGbtqhVfH98xo1oFuAXXrnHfMXEnJLLK_R5w@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
 <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com>
 <CAC20D2MeAtw4fLoGbtqhVfH98xo1oFuAXXrnHfMXEnJLLK_R5w@mail.gmail.com>
Message-ID: <CANCZdfoEAm5=thcZNKjF_5tcMH=iFP_E+QeVUhxRo154G1=pCA@mail.gmail.com>

On Tue, Jan 21, 2020, 11:46 AM Clem Cole <clemc at ccc.com> wrote:

> sorry...    all *MPU* boards had to be the revision but we may have done
> the same with the CPU boards.
>

When did Masscomp ship their first MP system?

Warner

On Tue, Jan 21, 2020 at 1:43 PM Clem Cole <clemc at ccc.com> wrote:
>
>>
>>
>> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon at fourwinds.com> wrote:
>>
>>> My memory is very very very fuzzy on this.  I seem to recall that
>>> microcode
>>> state was pushed onto a stack in certain cases,
>>
>> State, not the code.
>>
>> In fact, Masscomp having built the first MP UNIX box, ran into this
>> problem early on.  Different processor stepping had different internal
>> microcode state on the stack after an IRQ.  If you resumed with a processor
>> that was a different processor revision, the wrong state was returned.
>>
>> Will may remember this, but Masscomp issues strick orders to the FE that
>> all CPU boards had to be the revision.  You could not just swap a CPU
>> board, they had to go as sets. It was a real bummer.
>>
>> Moto fixed that with the 020 and later devices as more people made MP
>> systems.
>>
>>
>>
>>
>>
>>> ...  just heard grumbles from other folks about it.
>>>
>> Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to
>> figure out that problem.   It was not originally documented, other than
>> to state on certain faults X bytes of reserved information was pushed on
>> the stack.
>>
>> BTS: I don't remember, but it may have started with the 68010.
>>  Becuase before that, the 'executor' was wait stated and the fixor handled
>> and fixed the fault so the 68000 never actually saw  fault in the original
>> Masscomp CPU board.   The "MPU" board was the same board with a couple of
>> PAL's changed and an 68010 as the executor.   It was allowed to actually
>> fault and do something else while the fixor corrected the fault.  But the
>> key is that when the fault was repaired, another executor on a different
>> MPU board could be the processor that 'returned' from the fault.   That
>> ended up being a no-no.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/28941b0b/attachment.html>

From clemc at ccc.com  Wed Jan 22 06:27:04 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 15:27:04 -0500
Subject: [TUHS] Early Linux and BSD
In-Reply-To: <CANCZdfoEAm5=thcZNKjF_5tcMH=iFP_E+QeVUhxRo154G1=pCA@mail.gmail.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
 <CAC20D2M70qm-sgK+Oq8c7EK2pDO+pdz=pL8VbE2C8tw=CwQE-A@mail.gmail.com>
 <202001201946.00KJk5er3071186@darkstar.fourwinds.com>
 <7wk15l70u3.fsf@junk.nocrew.org>
 <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>
 <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com>
 <CAC20D2MeAtw4fLoGbtqhVfH98xo1oFuAXXrnHfMXEnJLLK_R5w@mail.gmail.com>
 <CANCZdfoEAm5=thcZNKjF_5tcMH=iFP_E+QeVUhxRo154G1=pCA@mail.gmail.com>
Message-ID: <CAC20D2MQa0DQ+3Da+heVSCWu8YsHg_RjhXxnrs6fi5FE+6rcqA@mail.gmail.com>

1982, the dual-processor MC500/DP originally with 68000s upgraded to 010's
shortly after they became available[see below]
1984, the 16 Processor MC5000/700 using '020 [the 500 was renamed the
MC5000/500 and a single processor MC5000/300 was also introduced.  In the
/700 and /300 design the fixor was unneeded and the base 020 serviced it's
own faults].

FWIW: Purdue VAX predates the 500/DP, but was a one-off that George made.
 The Sequent MP box would be about 3 or 4 years later.

Through the RTU 2.x, the OS originally ran Purdue VAX-like [*Goble/Marsh: ISCA
'82: Proceedings of the 9th annual symposium on Computer Architecture: "A
Dual Processor VAX 11/780", **Pages 291–298*] in all interrupts and system
calls went to a 'master'  and the second MPU/CPU board ran as a 'slave' (
*i.e.* user-mode code). By RTU 3.0 ~12 mons later, full locks were done and
each processor could service anything.


Note each CPU/MPU board had processor two chips on it, the executor and
fixor but the board was really not a multiprocessor - the second chip was
literally just running kernel code to service the page fault.  Thus (not
including the other 68000's processors in graphics or I/O boards) the
500/DP had either 4 68000's or 2 68010 & 2 68000's in it when it had two
CPU or two MPU boards in the backplane.  The idea was originally proposed
for the Z8000 by Forest Baskett at an early Asilomar conference.   The
formal citation is: Forest Baskett: "*Pascal and Virtual Memory in a Z8000
or MC68000 based Design Station*," COMPCON 80, Digest of Papers, pp
456-459, IEEE Computer Society, Feb. 25, 1980.

On Tue, Jan 21, 2020 at 2:14 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Tue, Jan 21, 2020, 11:46 AM Clem Cole <clemc at ccc.com> wrote:
>
>> sorry...    all *MPU* boards had to be the revision but we may have done
>> the same with the CPU boards.
>>
>
> When did Masscomp ship their first MP system?
>
> Warner
>
> On Tue, Jan 21, 2020 at 1:43 PM Clem Cole <clemc at ccc.com> wrote:
>>
>>>
>>>
>>> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon at fourwinds.com>
>>> wrote:
>>>
>>>> My memory is very very very fuzzy on this.  I seem to recall that
>>>> microcode
>>>> state was pushed onto a stack in certain cases,
>>>
>>> State, not the code.
>>>
>>> In fact, Masscomp having built the first MP UNIX box, ran into this
>>> problem early on.  Different processor stepping had different internal
>>> microcode state on the stack after an IRQ.  If you resumed with a processor
>>> that was a different processor revision, the wrong state was returned.
>>>
>>> Will may remember this, but Masscomp issues strick orders to the FE that
>>> all CPU boards had to be the revision.  You could not just swap a CPU
>>> board, they had to go as sets. It was a real bummer.
>>>
>>> Moto fixed that with the 020 and later devices as more people made MP
>>> systems.
>>>
>>>
>>>
>>>
>>>
>>>> ...  just heard grumbles from other folks about it.
>>>>
>>> Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to
>>> figure out that problem.   It was not originally documented, other than
>>> to state on certain faults X bytes of reserved information was pushed on
>>> the stack.
>>>
>>> BTS: I don't remember, but it may have started with the 68010.
>>>  Becuase before that, the 'executor' was wait stated and the fixor handled
>>> and fixed the fault so the 68000 never actually saw  fault in the original
>>> Masscomp CPU board.   The "MPU" board was the same board with a couple of
>>> PAL's changed and an 68010 as the executor.   It was allowed to actually
>>> fault and do something else while the fixor corrected the fault.  But the
>>> key is that when the fault was repaired, another executor on a different
>>> MPU board could be the processor that 'returned' from the fault.   That
>>> ended up being a no-no.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/3f83119a/attachment-0001.html>

From gtaylor at tnetconsulting.net  Wed Jan 22 06:42:32 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 21 Jan 2020 13:42:32 -0700
Subject: [TUHS] Shell Level...
In-Reply-To: <20200120083928.GA68939@wopr>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <20200120083928.GA68939@wopr>
Message-ID: <98babe9c-5599-1448-f8e0-b3cd25499b5d@spamtrap.tnetconsulting.net>

On 1/20/20 1:39 AM, Kurt H Maier wrote:
> The other, more common use I've seen is to e.g. clear the terminal window 
> on logout (e.g. in .bash_logout when SHLVL=1) but not when exiting any 
> nested shell.

Interesting use case.

Thank you for sharing Kurt.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/aec59d3f/attachment.bin>

From gtaylor at tnetconsulting.net  Wed Jan 22 06:44:07 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 21 Jan 2020 13:44:07 -0700
Subject: [TUHS] Shell Level...
In-Reply-To: <20200120194057.GI15860@mit.edu>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu>
Message-ID: <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net>

On 1/20/20 12:40 PM, Theodore Y. Ts'o wrote:
> The normal reason why I'm starting subshells is because I need to control 
> various environment variables on an ad-hoc basis.  It might be PYTHONPATH, 
> KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some combination of 
> the above.  Back when I was regularly using Kerberos root/admin bits, I 
> had some hard-coded shell aliases to indicate explicitly I was in a shell 
> that was using my tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU 
> kerberos tickets.

If I'm understanding you correctly, you used a sub-shell with a modified 
/ task / process specific environment.  Correct?

Thank you for sharing Theodore.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/de23bfa1/attachment.bin>

From gtaylor at tnetconsulting.net  Wed Jan 22 06:46:14 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 21 Jan 2020 13:46:14 -0700
Subject: [TUHS] Shell Level...
In-Reply-To: <m1itgtX-0036tPC@more.local>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <m1itgtX-0036tPC@more.local>
Message-ID: <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net>

On 1/20/20 4:55 PM, Greg A. Woods wrote:
> I've always just used "set ignoreeof" (first in Csh and later in Ksh), 
> but just in my initial login shell (i.e. set in ~/.login), to prevent 
> ^D from logging me out.

It sounds like you're making your initial / login shell behave 
differently based on the shell level.

Conceptually similar to Kurt's example, just changing a different aspect 
of your shell.

Thank you for sharing Greg.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/107c3ee4/attachment.bin>

From heinz at osta.com  Wed Jan 22 07:07:07 2020
From: heinz at osta.com (Heinz Lycklama)
Date: Tue, 21 Jan 2020 13:07:07 -0800
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
Message-ID: <85e9f90a-8ab2-2c43-f7a8-7a34e96bd9e8@osta.com>

That is correct. John Bass did contribute the lockf(2) system call
to the /usr/group standard. It is in the 1984 document.

Heinz

On 1/21/2020 10:28 AM, Clem Cole wrote:
> The Onyx box redated all the 68K and later Intel or other systems.  
>  John Bass brought one to USENIX to demo in early 1980 ru a V7 port 
> and everyone was blown away. Playing with it. It was a desktop (19" 
> rack) system that worked like a PDP-11.   I don't remember the bus, 
> but I would guess it was either custom or Multibus-I.
>
> Besides being one of the first non-PDP-11 'ports', the original 
> lockf(2) system call was defined for the database that they had built. 
> John would release the specs to /usr/group later.  I remember at one 
> meeting in the early 1980s discussing if file locking needed to be in 
> the original specification (Heinz probably remembers also as the chair 
> of that meeting).  I'm not at home, so I don't have the document to 
> see if it was picked up.  The argument was that serious computers like 
> VMS or the like ran real databases and without file locking UNIX would 
> never be considered a real OS that people could use.
>
> BTW: Joy would later use Bass's call as a model for the 4.2 call, but 
> Joy made the locks advisory, Bass's version was full / mandatory locks.
>
> FWIW: I think a search will pick up a number of other Z8000 based 
> systems, but Onyx was the first UNIX box.
>
> On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest <nobozo at gmail.com 
> <mailto:nobozo at gmail.com>> wrote:
>
>     There's been a lot of discussion about early Unix on Intel, National
>     Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
>     the Z8000, and if not, why not.
>
>     As I remember the Z8000 was going to be the great white hope that
>     would continue Zilog's success with the Z80 into modern times.
>     But, it obviously didn't happen.
>
>     Why?
>
>     Jon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/150aa462/attachment.html>

From nobozo at gmail.com  Wed Jan 22 07:24:00 2020
From: nobozo at gmail.com (Jon Forrest)
Date: Tue, 21 Jan 2020 13:24:00 -0800
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
Message-ID: <83795ac7-9ea1-82ba-d7c2-4f9705ca8935@gmail.com>



On 1/21/2020 10:15 AM, Henry Bent wrote:
>     There's been a lot of discussion about early Unix on Intel, National
>     Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
>     the Z8000, and if not, why not.
> 
> 
> A tiny bit of research would have answered this question for you: 
> https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems

True, but sometimes oldtimers like those of us who hang out here
remember additional, or different, things than what Wikipedia pages
say.

Jon


From crossd at gmail.com  Wed Jan 22 07:28:16 2020
From: crossd at gmail.com (Dan Cross)
Date: Tue, 21 Jan 2020 16:28:16 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
Message-ID: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>

To my knowledge, there was never a link between Plan 9 and Domain/OS.

As I understood it, Domain/OS was more influenced by Multics and maybe the
Pr1me machines than anything else. Plan 9 came from the Unix heritage (and
thus had Multics as a grandparent, in a manner of speaking).

If there was any connection at all, I suspect it was tenuous and more in
the form of an indirect influence, such as an idea someone got from a paper
or something like that.

        - Dan C.


On Tue, Jan 21, 2020 at 2:11 PM Pete Wright <pete at nomadlogic.org> wrote:

> Apologies that this isn't specifically a Unix specific question but I
> was wondering if anyone had insight in running domain/OS and it's
> relationship to Plan 9 (assuming there is any).
>
> One of my early mentors was a former product person at Apollo in Mass.
> and was nice enough to tell me all sorts of war stories working there.
> I had known about Plan9 at the time, and from what he described to me
> about domain/OS it sounded like there was lots of overlap between the
> two from a high level design perspective at the least.  I've always been
> keen to understand if domain/OS grew out of former Bell Labs folks, or
> how it got started.
>
> As an aside, he gifted me a whole bunch of marketing collateral from
> Apollo (from before the HQ acquisition) that i'd be happy to share if
> there is any historical value in that.  At the time I was a
> video/special effects engineer are was amazed at how beneficial having
> something like domain/OS or Plan9 would have been for us, it felt we
> were basically trying to accomplish a lot of the same goals by duct
> taping a bunch of Irix and Linux systems together.
>
> Cheers,
> -pete
>
> --
> Pete Wright
> pete at nomadlogic.org
> @nomadlogicLA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/efa26bde/attachment.html>

From dfawcus+lists-tuhs at employees.org  Wed Jan 22 07:32:51 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 21 Jan 2020 21:32:51 +0000
Subject: [TUHS] Onyx (was Re:  Unix on Zilog Z8000?)
In-Reply-To: <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
Message-ID: <20200121213251.GA25322@clarinet.employees.org>

On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote:
> The Onyx box redated all the 68K and later Intel or other systems.

That was a fun bit of grubbing around courtesy of a bitsavers mirror
(https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/).

It seems they started with a board based upon the non-segmented Z8002
and only later switched to using the segmented Z8001.  In the initial
board, they created their own MMU:

  Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf

  Memory Management Controller:

  The Memory Management Controller (MMC) enables the C8002 to perform
  address translation, memory block protection, and separation of
  instruction and data spaces. Sixteen independent map sets are
  implemented, with each map set consisting of an instruction map and
  a data map. Within each map there are 32 page registers. Each page
  register relocates and validates a 2K byte page. The MMC generates
  a 20 bit address allowing the C8002 to access up to one Mbyte of
  physical memory.

So I'd guess the MMC was actually programed through I/O instuctions
to io space, and hence preserved the necessary protection domains.

Cute.  I've had a background interest in the Z8000 (triggered by reading
a Z80000 datasheet around 87/88), and always though about using
the segmented rather than unsegmented device.

The following has a bit more info about the version of System III
ported to their boxes:

  https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf

DF

From nw at retrocomputingtasmania.com  Wed Jan 22 07:48:37 2020
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Wed, 22 Jan 2020 08:48:37 +1100
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <20200121182045.GO26619@mcvoy.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
 <20200121182045.GO26619@mcvoy.com>
Message-ID: <CACCFpdzZc-u=aq5ExGZdV6dGCE9dYXBpRK=0DVr=x0-wNxEFBg@mail.gmail.com>

On Wed, Jan 22, 2020 at 5:22 AM Larry McVoy <lm at mcvoy.com> wrote:
> Yeah, it ran on the 16 bit one but I looked and couldn't find if they
> got Unix on the z80000 (which I suspect is what Jon meant).

I spent some time attempting to confirm whether the Z80000 (the 32-bit
flat address space development of the Z8000) ever went to silicon and
was not able to confirm it did. My suspicion remains that the Z80000
was only ever a paper specification and did not even get to a first
spin. If anyone knows and has some evidence I would be glad to update
the wikipedia page.

From dfawcus+lists-tuhs at employees.org  Wed Jan 22 07:57:46 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 21 Jan 2020 21:57:46 +0000
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
References: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
Message-ID: <20200121215746.GB25322@clarinet.employees.org>

On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote:
> 
> And here, understanding the model is important, namely, grep is the
> wrong tool for searching/parsing JSON output. Dealing with JSON from the
> shell, you should use jq.  I've been dragged kicking and screaming into
> dealing with JSON, and about all I can say about it is, I like it about
> this >< much more than XML. :)

If push comes to shove, one can always use xmlawk (xml extension for gawk)
to beat the latter in to submission.

DF

From henry.r.bent at gmail.com  Wed Jan 22 08:00:50 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 21 Jan 2020 17:00:50 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CACCFpdzZc-u=aq5ExGZdV6dGCE9dYXBpRK=0DVr=x0-wNxEFBg@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
 <20200121182045.GO26619@mcvoy.com>
 <CACCFpdzZc-u=aq5ExGZdV6dGCE9dYXBpRK=0DVr=x0-wNxEFBg@mail.gmail.com>
Message-ID: <CAEdTPBcdirTwB=TtJB1papDBnitKnnCkkJAAGt=ByLQRirkrcA@mail.gmail.com>

On Tue, 21 Jan 2020 at 16:49, Nigel Williams <nw at retrocomputingtasmania.com>
wrote:

> On Wed, Jan 22, 2020 at 5:22 AM Larry McVoy <lm at mcvoy.com> wrote:
> > Yeah, it ran on the 16 bit one but I looked and couldn't find if they
> > got Unix on the z80000 (which I suspect is what Jon meant).
>
> I spent some time attempting to confirm whether the Z80000 (the 32-bit
> flat address space development of the Z8000) ever went to silicon and
> was not able to confirm it did. My suspicion remains that the Z80000
> was only ever a paper specification and did not even get to a first
> spin. If anyone knows and has some evidence I would be glad to update
> the wikipedia page.
>

This thread reminded me that I own a copy of the Zilog "1983/84 Components
Data Book," which I am talking to Al Kossow about scanning.  It fully
details the Z80,000 on paper but does not say anything about hardware,
everything is labeled preliminary.  It is dated September 1983.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/d6464cbe/attachment.html>

From cmhanson at eschatologist.net  Wed Jan 22 07:52:59 2020
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Tue, 21 Jan 2020 13:52:59 -0800
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
Message-ID: <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>

My understanding is that there’s a direct line from MULTICS to Prime to Apollo, in that Apollo was founded by former Prime folks who took their philosophy with them.

Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and interesting ideas and was quite influential despite the relatively small number of people who used it. A lot of what we take for granted today in distributed computing came via Apollo more than anywhere else, as Apollo users and alumni took what they learned to other systems.

  — Chris



From drb at msu.edu  Wed Jan 22 08:09:53 2020
From: drb at msu.edu (Dennis Boone)
Date: Tue, 21 Jan 2020 17:09:53 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: (Your message of Tue, 21 Jan 2020 13:52:59 -0800.)
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
References: <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
Message-ID: <20200121220953.8B49716DBEB@yagi.h-net.msu.edu>

 > My understanding is that there’s a direct line from MULTICS to Prime
 > to Apollo, in that Apollo was founded by former Prime folks who took
 > their philosophy with them.

Among others, and perhaps key, Bill Poduska, Prime's VP Engineering.

De

From jsteve at superglobalmegacorp.com  Wed Jan 22 08:35:59 2020
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 21 Jan 2020 22:35:59 +0000 (UTC)
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <20200121182045.GO26619@mcvoy.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
 <20200121182045.GO26619@mcvoy.com>
Message-ID: <25E62EB5E090E7CB.f810e0c9-fa0e-409f-880d-5f8dc51ff5e7@mail.outlook.com>

The only one I know is Coherent.  Disk images recently surfaced 




https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-0.7/ 




This is for the Commodore B 900 prototype. 




http://www.floodgap.com/retrobits/ckb/secret/900.html 




Get Outlook for Android







On Wed, Jan 22, 2020 at 2:22 AM +0800, "Larry McVoy" <lm at mcvoy.com> wrote:










On Tue, Jan 21, 2020 at 01:15:53PM -0500, Henry Bent wrote:
> On Tue, 21 Jan 2020 at 12:53, Jon Forrest  wrote:
> 
> > There's been a lot of discussion about early Unix on Intel, National
> > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> > the Z8000, and if not, why not.
> >
> 
> A tiny bit of research would have answered this question for you:
> https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems

Yeah, it ran on the 16 bit one but I looked and couldn't find if they
got Unix on the z80000 (which I suspect is what Jon meant).





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/7402c7f6/attachment.html>

From dfawcus+lists-tuhs at employees.org  Wed Jan 22 08:36:55 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 21 Jan 2020 22:36:55 +0000
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAEdTPBcdirTwB=TtJB1papDBnitKnnCkkJAAGt=ByLQRirkrcA@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <CAEdTPBeiEHuooowP2RvT1FjPZ18ykErFhVY-0F2VDLuiXYzi3A@mail.gmail.com>
 <20200121182045.GO26619@mcvoy.com>
 <CACCFpdzZc-u=aq5ExGZdV6dGCE9dYXBpRK=0DVr=x0-wNxEFBg@mail.gmail.com>
 <CAEdTPBcdirTwB=TtJB1papDBnitKnnCkkJAAGt=ByLQRirkrcA@mail.gmail.com>
Message-ID: <20200121223655.GA54133@clarinet.employees.org>

On Tue, Jan 21, 2020 at 05:00:50PM -0500, Henry Bent wrote:
> 
> This thread reminded me that I own a copy of the Zilog "1983/84 Components
> Data Book," which I am talking to Al Kossow about scanning.  It fully
> details the Z80,000 on paper but does not say anything about hardware,
> everything is labeled preliminary.  It is dated September 1983.

http://bitsavers.trailing-edge.com/components/zilog/_dataBooks/1983_84_Components_Data_Book.pdf

DF

From clemc at ccc.com  Wed Jan 22 08:36:57 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 17:36:57 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
Message-ID: <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>

On Tue, Jan 21, 2020 at 5:03 PM Chris Hanson <cmhanson at eschatologist.net>
wrote:

> My understanding is that there’s a direct line from MULTICS to Prime to
> Apollo,

Yes in some ways...



> in that Apollo was founded by former Prime folks who took their philosophy
> with them.
>
Actually not quite.  MIT/Multics to Honeywell to Pr1me to Apollo (to
Belmont/Stellar)  Bill P and his former TA from MIT (Mike Spourer) actually
wanted to break a little when they did Apollo.  The whole ideas was too
risky for Honeywell, so he created Pr1me.    Apollo was too risky for Pr1me
so he created Apollo.  Stellar was too risky for Apollo so he created
Belmont - a.k.a. Stellar.

[By the way, I spoke to Bill over the holidays.  He's a still the same].

>
> Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and
> interesting ideas and was quite influential

I absolutely agree.

But a number new idea were from an influx of MIT and ex-DEC folks
actually.  And that that terrible sin called the registry that lives on
winders came from Paul (some of us thought it was a bad idea then too BTW).

IMO: The best idea was the typed file system and the ability to run user
code specific with a file type.  That's how IP, TCP, UDP are all
implemented.  Very, very cool.  There is a USENIX paper that describes it
I'll have to dig up the reference.  It's worth reading.  But I have never
seen it implemented again as well.




> A lot of what we take for granted today in distributed computing came via
> Apollo more than anywhere else, as Apollo users and alumni took what they
> learned to other systems.
>
Yes and no.   I agree it was a wonderful intellectual playground for some
very cool ideas.   Some worked pretty well, but not all did.  For example,
as Larry said earlier today, the "twin'ed" or diskless nodes were awful
(replace the S with C for what many of us think about them).  But it got
Sun to make them too and ended up being a great add-in disk business
later.  I refused at Masscomo and ended up losing war, even though the cost
of a WS500 was less than a Sun2 with a disk, people bought Sun's diskless
and then after they discovered they sucked, spent another 6K to buy a desk
system for them (we lost for economics, but I was technically right -
a.k.a. Cole's law of economics vs. sophisticated technology).

Anyway, we (as a community) are better for having that system but other
than the registry, I can think of little actual technology that we continue
to use from Aegis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/ec05a785/attachment.html>

From kevin.bowling at kev009.com  Wed Jan 22 08:43:51 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 21 Jan 2020 15:43:51 -0700
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
Message-ID: <CAK7dMtBvWC64+4Cb-M08v957esA4zGuzeskZWwQ4qhTa4+HsKA@mail.gmail.com>

On Tue, Jan 21, 2020 at 3:39 PM Clem Cole <clemc at ccc.com> wrote:
>
>
>
> On Tue, Jan 21, 2020 at 5:03 PM Chris Hanson <cmhanson at eschatologist.net> wrote:
>>
>> My understanding is that there’s a direct line from MULTICS to Prime to Apollo,
>
> Yes in some ways...
>
>
>>
>> in that Apollo was founded by former Prime folks who took their philosophy with them.
>
> Actually not quite.  MIT/Multics to Honeywell to Pr1me to Apollo (to Belmont/Stellar)  Bill P and his former TA from MIT (Mike Spourer) actually wanted to break a little when they did Apollo.  The whole ideas was too risky for Honeywell, so he created Pr1me.    Apollo was too risky for Pr1me so he created Apollo.  Stellar was too risky for Apollo so he created Belmont - a.k.a. Stellar.
>
> [By the way, I spoke to Bill over the holidays.  He's a still the same].

I respect someone that is willing to put their time (and money?) where
their mouth is like that.  Would he be willing to write up some
post-mortems on some of these?  I believe at least late Apollo and
Stellar can qualify as unix?

>>
>>
>> Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and interesting ideas and was quite influential
>
> I absolutely agree.
>
> But a number new idea were from an influx of MIT and ex-DEC folks actually.  And that that terrible sin called the registry that lives on winders came from Paul (some of us thought it was a bad idea then too BTW).
>
> IMO: The best idea was the typed file system and the ability to run user code specific with a file type.  That's how IP, TCP, UDP are all implemented.  Very, very cool.  There is a USENIX paper that describes it I'll have to dig up the reference.  It's worth reading.  But I have never seen it implemented again as well.
>
>
>
>>
>> A lot of what we take for granted today in distributed computing came via Apollo more than anywhere else, as Apollo users and alumni took what they learned to other systems.
>
> Yes and no.   I agree it was a wonderful intellectual playground for some very cool ideas.   Some worked pretty well, but not all did.  For example, as Larry said earlier today, the "twin'ed" or diskless nodes were awful (replace the S with C for what many of us think about them).  But it got Sun to make them too and ended up being a great add-in disk business later.  I refused at Masscomo and ended up losing war, even though the cost of a WS500 was less than a Sun2 with a disk, people bought Sun's diskless and then after they discovered they sucked, spent another 6K to buy a desk system for them (we lost for economics, but I was technically right - a.k.a. Cole's law of economics vs. sophisticated technology).
>
> Anyway, we (as a community) are better for having that system but other than the registry, I can think of little actual technology that we continue to use from Aegis.

From tytso at mit.edu  Wed Jan 22 09:00:25 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 21 Jan 2020 18:00:25 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
Message-ID: <20200121230025.GL15860@mit.edu>

On Tue, Jan 21, 2020 at 05:36:57PM -0500, Clem Cole wrote:
> > A lot of what we take for granted today in distributed computing came via
> > Apollo more than anywhere else, as Apollo users and alumni took what they
> > learned to other systems.
> 
> Anyway, we (as a community) are better for having that system but other
> than the registry, I can think of little actual technology that we continue
> to use from Aegis.

The OSF/DCE's RPC system came from Apollo, as does the predecessor for
the UUID layout still in use today (RFC 4122).  Paul Leach brought
both to the OSF, and as the Kerberos V5 Tech Lead, I worked with Paul,
and used an early Internet-Draft spec of the OSF UUID and implemented
it in e2fsprogs for labelling ext2/3/4 superblocks, and from there the
infection vector spread to the GNOME project.  When Paul brought both
of those technologies to Microsoft when he went there after OSF went
belly up.

	     		       	       - Ted

From tytso at mit.edu  Wed Jan 22 09:10:23 2020
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 21 Jan 2020 18:10:23 -0500
Subject: [TUHS] Shell Level...
In-Reply-To: <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu>
 <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net>
Message-ID: <20200121231023.GM15860@mit.edu>

On Tue, Jan 21, 2020 at 01:44:07PM -0700, Grant Taylor via TUHS wrote:
> On 1/20/20 12:40 PM, Theodore Y. Ts'o wrote:
> > The normal reason why I'm starting subshells is because I need to
> > control various environment variables on an ad-hoc basis.  It might be
> > PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some
> > combination of the above.  Back when I was regularly using Kerberos
> > root/admin bits, I had some hard-coded shell aliases to indicate
> > explicitly I was in a shell that was using my tytso/root at ATHENA.MIT.EDU
> > or tytso/admin at ATHENA.MIT.EDU kerberos tickets.
> 
> If I'm understanding you correctly, you used a sub-shell with a modified /
> task / process specific environment.  Correct?

Correct.  And I would often suspend the shell when I didn't need to
use the Kerberos administration credentials, and then go back to it
later when I did need it, and since I was often bouncing back and
forth between the sub-shell and the parent shell, having the SHLVL
displayed in the prompt for non-top-level shells was useful.

For similar reasons, my shell prompt will also display what git branch
I happen to be one.  For example:

<tytso at lambda> {/usr/projects/e2fsprogs/e2fsprogs-maint}, level 2   (debian/master)
1001% 

Says that I'm on the debian/master git branch, and "level 2" indicates
that I'm in a subshell.  (If I'm in a top level shell, no level will
be printed at all.)  The prompt also displays the hostname ("lambda"
in this case") which is super-useful to identify remote logins.

	     	 	    		  	     - Ted

From woods at robohack.ca  Wed Jan 22 09:39:16 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 21 Jan 2020 15:39:16 -0800
Subject: [TUHS] Shell Level...
In-Reply-To: <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net>
References: <f8fe34ae-e3e3-dfbd-8bc8-15bc58474062@spamtrap.tnetconsulting.net>
 <1itSE0-5Td-00@marmaro.de> <m1itgtX-0036tPC@more.local>
 <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net>
Message-ID: <m1iu376-0036tPC@more.local>

At Tue, 21 Jan 2020 13:46:14 -0700, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
Subject: Re: [TUHS] Shell Level...
>
> [1  <text/plain (en-US); windows-1252 (quoted-printable)>]
> On 1/20/20 4:55 PM, Greg A. Woods wrote:
> > I've always just used "set ignoreeof" (first in Csh and later in
> > Ksh), but just in my initial login shell (i.e. set in ~/.login), to
> > prevent ^D from logging me out.
>
> It sounds like you're making your initial / login shell behave
> differently based on the shell level.

More like the other way around -- all sub-shells behave differently
based on the fact they're not login shells.  Note I also considered (and
still consider) all initial shells in each "window" to be a "login"
shell.  In the days of "layers" (e.g. on the DMD5620) I did that by
inspecting the environment to look for clues that the shell was started
by "layers", but ever since X11 took over my life (and my DMDs have been
scrapped and/or put into storage) I've used XTerm's "-ls" option to make
the shell a "real" login shell.

The $LEV (or $SHLVL) value is just an indicator, one that I only ever
used as a visual cue/clue.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/2f567643/attachment.sig>

From woods at robohack.ca  Wed Jan 22 09:45:27 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 21 Jan 2020 15:45:27 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <CANCZdfraqvi+17VjWhyFqiNyxec_ecR8Zh2QDHYNcO2c=ExxEQ@mail.gmail.com>
References: <C7972CAB-7A91-49CD-9F7A-9675400E81E5@alchemistowl.org>
 <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <20200120190900.GH15860@mit.edu> <m1itg5x-0036tRC@more.local>
 <CANCZdfraqvi+17VjWhyFqiNyxec_ecR8Zh2QDHYNcO2c=ExxEQ@mail.gmail.com>
Message-ID: <m1iu3D5-0036tPC@more.local>

At Mon, 20 Jan 2020 17:13:48 -0700, Warner Losh <imp at bsdimp.com> wrote:
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")
>
> Lots of people were building CVS repos based on the patchkits... Chris
> wasn't trying to start a project, but more was trying to find a way of
> organizing everything that people were working on. At least that's what I
> recall from the rumors I'd heard on campus after Chris visited Boulder...

Indeed, that is no doubt a far more accurate way of stating things.

I was only watching from afar, effectively.

Of course it didn't take too long before he announced 0.8 and made it
all official.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/e70fd18c/attachment.sig>

From ron at ronnatalie.com  Wed Jan 22 09:53:00 2020
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 21 Jan 2020 18:53:00 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
 <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
Message-ID: <AC412B39-B5D9-4E46-8E74-2DB4649957DE@ronnatalie.com>

Apollo gave us the long term use of a DN1000.    I ported our image processing system to it.     The amusing thing was when you fired up an X window manager on the thing, it wrapped all three segments of the little status bar at the bottom with window borders.    The DN10000 docs came with a beautiful 5 volume set that described all the internals.   It was quite detailed for what was there.   What I really needed was the documentation on the graphics system which was in Volume 3.   My set was missing this.   After much digging around Apollo, it turns out that they never wrote volume 3, just assigned the volume number to some yet to be written document.

I learned the hard way not to open the gull wing doors on the thing while someone was using it.

When HP/Apollo merged and they formally pulled the plug on Domain, I was over at the FAA and they showed me the “latest” computer they got in that was running a system to show where all the planes in the airspace system were (think of FlightAware.COM <http://flightaware.com/>, this was a first stab at pulling that data from the ATC computers).    It was a DN4000? running domain.   Always using the latest stuff at the FAA.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/81870a5c/attachment.html>

From sauer at technologists.com  Wed Jan 22 08:58:10 2020
From: sauer at technologists.com (Charles H Sauer)
Date: Tue, 21 Jan 2020 16:58:10 -0600
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
Message-ID: <317a33f8-ff97-21a0-aa2c-e9821b8f3d13@technologists.com>



On 1/21/2020 4:36 PM, Clem Cole wrote:

> Anyway, we (as a community) are better for having that system but other 
> than the registry, I can think of little actual technology that we 
> continue to use from Aegis.

don't forget UIDs/UUIDs/GUIDs

-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From woods at robohack.ca  Wed Jan 22 10:14:00 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 21 Jan 2020 16:14:00 -0800
Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an
 academic question")
In-Reply-To: <20200120180432.GJ28686@mcvoy.com>
References: <20200117195908.GF15253@ancienthardware.org>
 <20200118035051.GC481935@mit.edu>
 <20200118041913.GB67053@eureka.lemis.com>
 <20200119024900.GA15860@mit.edu>
 <20200119031225.GI67053@eureka.lemis.com>
 <20200119035808.GK67053@eureka.lemis.com>
 <20200119132551.GC15860@mit.edu> <m1itNo9-0036tPC@more.local>
 <CAKr6gn3Vhzn=g_55NdOQfQCUqi9YBSBZNbjM+YMoS8cg82PSbQ@mail.gmail.com>
 <CAC20D2ONRuze8sxOkiuWqYV7i6+vy9r3jGuM3P52fin2gQHKjg@mail.gmail.com>
 <20200120180432.GJ28686@mcvoy.com>
Message-ID: <m1iu3ei-0036tPC@more.local>

At Mon, 20 Jan 2020 10:04:32 -0800, Larry McVoy <lm at mcvoy.com> wrote:
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")
> 
> I know those Nat Semi chips very well, or did at the time.  I so wanted to
> love those chips, the instruction set felt like whoever did the PDP-11
> did the 320xx chips.  But they couldn't produce chips without bugs and
> that killed them.  It's a crying shame, I liked the instruction set
> WAY better than the VAX.  The VAX seemed really messing compared to 
> the PDP-11, the 320xx chips seemed clean.  Might be rose colored 
> glasses but that's my memory.

I held a lot of anticipation for the NS chips as well, and I remember
well excitedly going around to trade shows for a year or two and playing
around with the very few Unix systems based on them that showed up on
occasion.

From what I understand it was really only the original NS32016 that was
too buggy to be trusted.  The NS32032 was a bug-fix release that also
came a full 32-bit external bus, and the NS32532 a while later was quite
a contender at the time in terms of performance (wikipedia says "about
twice as performant as the competing MC68030 and i80386").

In the end though I discovered the ATT 3b2 systems and their also quite
nicely orthogonal WE32000 CPUs (though in the end I never did write more
than a very simple demo program in assembler, just to know I could).  My
copy of the WE32100 Information Manual sits right beside my VAX
Instruction Reference Manual.  Sadly the 3B2s I had were never as
powerful as a PC532 was though -- more like the sluggish i386 and m68k
systems of the day.

-- 
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/1a8b53e2/attachment.sig>

From clemc at ccc.com  Wed Jan 22 10:20:57 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 19:20:57 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <20200121230025.GL15860@mit.edu>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
 <20200121230025.GL15860@mit.edu>
Message-ID: <CAC20D2OfnqHaub+LCCB9q_imdqR0VSkDPRV4zzKpSoCVg6eWZw@mail.gmail.com>

Ted point taken. As I was driving home tonight I thought about both DCE and
UUIDs.  The later is clearly important and we do owe the guys in Chelmsford
a great thank you for that one.  But the registry ...  really now.

On Tue, Jan 21, 2020 at 6:00 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Tue, Jan 21, 2020 at 05:36:57PM -0500, Clem Cole wrote:
> > > A lot of what we take for granted today in distributed computing came
> via
> > > Apollo more than anywhere else, as Apollo users and alumni took what
> they
> > > learned to other systems.
> >
> > Anyway, we (as a community) are better for having that system but other
> > than the registry, I can think of little actual technology that we
> continue
> > to use from Aegis.
>
> The OSF/DCE's RPC system came from Apollo, as does the predecessor for
> the UUID layout still in use today (RFC 4122).  Paul Leach brought
> both to the OSF, and as the Kerberos V5 Tech Lead, I worked with Paul,
> and used an early Internet-Draft spec of the OSF UUID and implemented
> it in e2fsprogs for labelling ext2/3/4 superblocks, and from there the
> infection vector spread to the GNOME project.  When Paul brought both
> of those technologies to Microsoft when he went there after OSF went
> belly up.
>
>                                        - Ted
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/123f2347/attachment.html>

From jon at fourwinds.com  Wed Jan 22 10:25:05 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 21 Jan 2020 16:25:05 -0800
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
Message-ID: <202001220025.00M0P5bG3369286@darkstar.fourwinds.com>

Chris Hanson writes:
> My understanding is that there’s a direct line from MULTICS to Prime to Apollo,
> in that Apollo was founded by former Prime folks who took their philosophy with them.
>
> Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and
> interesting ideas and was quite influential despite the relatively small
> number of people who used it. A lot of what we take for granted today in
> distributed computing came via Apollo more than anywhere else, as Apollo
> users and alumni took what they learned to other systems.
>
>   — Chris

I stil have some Domain/OS books here if anyone wants 'em.

From rich.salz at gmail.com  Wed Jan 22 11:18:59 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Tue, 21 Jan 2020 20:18:59 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <20200121230025.GL15860@mit.edu>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
 <20200121230025.GL15860@mit.edu>
Message-ID: <CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>

Paul was still at Apollo at the time that OSF/DCE picked Apollo's NCA/NCS
as the RPC system.  I don't know when he left Apollo (or HP/Chelmsford
after they bought it) for Microsoft, but it was before OSF died.  That
latter happened because Sun (Rob Gingell?) insisted OSF stop doing all
development as the price of ending the Unix wars and joining everyone in
opposing Redmond.  We could no longer say OSF stood for Oppose Sun Forever.

I liked that NCA could handle env vars in pathnames, which Locus also had
IIRC.  Domain also had "fat executables" similar to what Apple did when
migrating across CPUs.  And their build and source system was recreated as
ClearCase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/f481b3b0/attachment.html>

From cmhanson at eschatologist.net  Wed Jan 22 12:47:40 2020
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Tue, 21 Jan 2020 18:47:40 -0800
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <AC412B39-B5D9-4E46-8E74-2DB4649957DE@ronnatalie.com>
References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org>
 <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <AC412B39-B5D9-4E46-8E74-2DB4649957DE@ronnatalie.com>
Message-ID: <20686601-773C-408B-98FD-E2DC2680D5E1@eschatologist.net>

On Jan 21, 2020, at 3:53 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> Apollo gave us the long term use of a DN1000.    I ported our image processing system to it.     The amusing thing was when you fired up an X window manager on the thing, it wrapped all three segments of the little status bar at the bottom with window borders.    The DN10000 docs came with a beautiful 5 volume set that described all the internals.   It was quite detailed for what was there.   What I really needed was the documentation on the graphics system which was in Volume 3.   My set was missing this.   After much digging around Apollo, it turns out that they never wrote volume 3, just assigned the volume number to some yet to be written document.

Also the DN10000 is extremely heavy. Mine’s in a basement and claims are it’s never coming out…

If anyone has DN10000 documentation like Roland describes above, I would love to get my hands on it and ensure it’s preserved. My DN10000 is a long term restoration project, and we could use some docs.

  -- Chris



From lars at nocrew.org  Wed Jan 22 17:11:38 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 22 Jan 2020 07:11:38 +0000
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net> (Chris
 Hanson's message of "Tue, 21 Jan 2020 13:52:59 -0800")
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
Message-ID: <7wpnfc55jp.fsf@junk.nocrew.org>

Chris Hanson wrote:
> My understanding is that there’s a direct line from MULTICS to Prime
> to Apollo, in that Apollo was founded by former Prime folks who took
> their philosophy with them.

Other Multics inspired systems:

M.A.G.I.C. / MagicSix (Interdata minis at MIT Architecture Machine)
Amber (S-1 super computer)

Any recollections?  *COFF* *COFF*

From arnold at skeeve.com  Wed Jan 22 17:21:47 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 22 Jan 2020 00:21:47 -0700
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <20200121215746.GB25322@clarinet.employees.org>
References: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
 <20200121215746.GB25322@clarinet.employees.org>
Message-ID: <202001220721.00M7Ll5D021031@freefriends.org>

> On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote:
> > 
> > And here, understanding the model is important, namely, grep is the
> > wrong tool for searching/parsing JSON output. Dealing with JSON from the
> > shell, you should use jq.  I've been dragged kicking and screaming into
> > dealing with JSON, and about all I can say about it is, I like it about
> > this >< much more than XML. :)

Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> If push comes to shove, one can always use xmlawk (xml extension for gawk)
> to beat the latter in to submission.

There is also a simple JSON extension for gawk in the gawkextlib project
that can suck in a single JSON record and turn it into a gawk
multidimensional array, and vice versa.  (Gawk has true multidimensional
arrays and isarray/typeof functions so that you can easily traverse
such an array.)

(<horn ownership="mine">Toot!</horn>)

Arnold

From coppero1237 at gmail.com  Wed Jan 22 17:29:43 2020
From: coppero1237 at gmail.com (Tyler Adams)
Date: Wed, 22 Jan 2020 09:29:43 +0200
Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think
 efficiency now ]
In-Reply-To: <202001220721.00M7Ll5D021031@freefriends.org>
References: <CAK7dMtAH2frfiTCy=XxeYb4F5u5ndQsMVk_-MSxQd6aVfjWOwQ@mail.gmail.com>
 <202001122034.00CKYQ39571239@darkstar.fourwinds.com>
 <CAK7dMtBhRNUS4t-CaUFnWAP7TWpLRetTA36pL5wP1q6=19APnQ@mail.gmail.com>
 <202001122044.00CKiUNV573279@darkstar.fourwinds.com>
 <CAK7dMtB0-dpyZHsxuLpL8dCEJGV24xuD9VE+ueYFM_dbFxPicg@mail.gmail.com>
 <202001122137.00CLbMrw582813@darkstar.fourwinds.com>
 <CAEoi9W4fXLaTRM1mv4wnVbifCFBEw_iKL9cds8ds-FBRTwM-=g@mail.gmail.com>
 <CAEoi9W6LedGGjWPO=ZgZzVdGLqs8drhqcWkvA_DfKTOtMDgegQ@mail.gmail.com>
 <CAEoi9W5nykr0V_qgXCr-5W=T6k_5h8j87-YNDnWCRj21DfPwfA@mail.gmail.com>
 <alpine.NEB.2.21.2001180941080.1764@neener.bl.org>
 <20200121215746.GB25322@clarinet.employees.org>
 <202001220721.00M7Ll5D021031@freefriends.org>
Message-ID: <CAEuQd1CPaY9OnCrkbwPXyGqUAryPY-xXzSg+WiOeHNpet7EZQA@mail.gmail.com>

Also for anything where jq gets too complicated, you can use python to whip
up an arbitrary json filter

Theres only 5 lines of boiler plate

import json
import sys
d = json.load(sys.stdin)
# your code here
print(json.dumps(d))

Tyler

On Wed, Jan 22, 2020, 09:22 <arnold at skeeve.com> wrote:

> > On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote:
> > >
> > > And here, understanding the model is important, namely, grep is the
> > > wrong tool for searching/parsing JSON output. Dealing with JSON from
> the
> > > shell, you should use jq.  I've been dragged kicking and screaming into
> > > dealing with JSON, and about all I can say about it is, I like it about
> > > this >< much more than XML. :)
>
> Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> > If push comes to shove, one can always use xmlawk (xml extension for
> gawk)
> > to beat the latter in to submission.
>
> There is also a simple JSON extension for gawk in the gawkextlib project
> that can suck in a single JSON record and turn it into a gawk
> multidimensional array, and vice versa.  (Gawk has true multidimensional
> arrays and isarray/typeof functions so that you can easily traverse
> such an array.)
>
> (<horn ownership="mine">Toot!</horn>)
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/bcbfe097/attachment.html>

From arrigo at alchemistowl.org  Wed Jan 22 18:18:29 2020
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 22 Jan 2020 09:18:29 +0100
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
References: <CAC20D2MuKVqDdosO8FMZ52H1=GY=ziMUsFJsFoyVa0TAGwCx8A@mail.gmail.com>
Message-ID: <2208089D-FF73-4F34-8F52-8EDD0E3A5AE0@alchemistowl.org>

On 21 Jan 2020, at 19:30, Clem Cole <clemc at ccc.com> wrote:
> FWIW: I think a search will pick up a number of other Z8000 based systems, but Onyx was the first UNIX box.

The very first “Unix at home” system for me was an Onyx 8002 “pedestal” which was connected to three serial terminals: dad, uncle, me :) It was definitely 1980 as it was delivered at home the day of my (unforgettable) 7th birthday. Previously I had only “played” with dad’s TTY into the University systems. Ended up being taught C instead of riding a bicycle… 

We still have the manuals somewhere but the machine was gone when the Avioon came in. No idea where it ended, sadly.

Arrigo 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/1b789b60/attachment.html>

From robpike at gmail.com  Wed Jan 22 19:31:15 2020
From: robpike at gmail.com (Rob Pike)
Date: Wed, 22 Jan 2020 20:31:15 +1100
Subject: [TUHS] Unix quix
In-Reply-To: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
Message-ID: <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>

The answers are up:

https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/ec714428/attachment.html>

From pnr at planet.nl  Wed Jan 22 20:56:08 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 22 Jan 2020 11:56:08 +0100
Subject: [TUHS] Unix on Zilog Z8000?
Message-ID: <3E0694EF-1742-4313-BA34-D4D386FF6942@planet.nl>

A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version:
https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/

Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse.

I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction.

If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging.

Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production.


> Message: 7
> Date: Tue, 21 Jan 2020 21:32:51 +0000
> From: Derek Fawcus <dfawcus+lists-tuhs at employees.org>
> To: The Unix Heritage Society mailing list <tuhs at tuhs.org>
> Subject: [TUHS] Onyx (was Re:  Unix on Zilog Z8000?)
> Message-ID: <20200121213251.GA25322 at clarinet.employees.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote:
>> The Onyx box redated all the 68K and later Intel or other systems.
> 
> That was a fun bit of grubbing around courtesy of a bitsavers mirror
> (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/).
> 
> It seems they started with a board based upon the non-segmented Z8002
> and only later switched to using the segmented Z8001.  In the initial
> board, they created their own MMU:
> 
>  Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf
> 
>  Memory Management Controller:
> 
>  The Memory Management Controller (MMC) enables the C8002 to perform
>  address translation, memory block protection, and separation of
>  instruction and data spaces. Sixteen independent map sets are
>  implemented, with each map set consisting of an instruction map and
>  a data map. Within each map there are 32 page registers. Each page
>  register relocates and validates a 2K byte page. The MMC generates
>  a 20 bit address allowing the C8002 to access up to one Mbyte of
>  physical memory.
> 
> So I'd guess the MMC was actually programed through I/O instuctions
> to io space, and hence preserved the necessary protection domains.
> 
> Cute.  I've had a background interest in the Z8000 (triggered by reading
> a Z80000 datasheet around 87/88), and always though about using
> the segmented rather than unsegmented device.
> 
> The following has a bit more info about the version of System III
> ported to their boxes:
> 
>  https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf
> 
> DF

From pnr at planet.nl  Wed Jan 22 23:14:26 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 22 Jan 2020 14:14:26 +0100
Subject: [TUHS] Unix on Zilog Z8000?
Message-ID: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl>

My memory failed me: the part numbers were Z8001/Z8002 for the original and Z8003/Z8004 for the revised chips (segmented/unsegmented).

Hence it is unlikely that the Onyx had any form of demand paging (other than extending the stack in PDP11-like fashion).

——

A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version:
https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/

Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse.

I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction.

If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging.

Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production.


> Message: 7
> Date: Tue, 21 Jan 2020 21:32:51 +0000
> From: Derek Fawcus <dfawcus+lists-tuhs at employees.org>
> To: The Unix Heritage Society mailing list <tuhs at tuhs.org>
> Subject: [TUHS] Onyx (was Re:  Unix on Zilog Z8000?)
> Message-ID: <20200121213251.GA25322 at clarinet.employees.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote:
>> The Onyx box redated all the 68K and later Intel or other systems.
> 
> That was a fun bit of grubbing around courtesy of a bitsavers mirror
> (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/).
> 
> It seems they started with a board based upon the non-segmented Z8002
> and only later switched to using the segmented Z8001.  In the initial
> board, they created their own MMU:
> 
> Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf
> 
> Memory Management Controller:
> 
> The Memory Management Controller (MMC) enables the C8002 to perform
> address translation, memory block protection, and separation of
> instruction and data spaces. Sixteen independent map sets are
> implemented, with each map set consisting of an instruction map and
> a data map. Within each map there are 32 page registers. Each page
> register relocates and validates a 2K byte page. The MMC generates
> a 20 bit address allowing the C8002 to access up to one Mbyte of
> physical memory.
> 
> So I'd guess the MMC was actually programed through I/O instuctions
> to io space, and hence preserved the necessary protection domains.
> 
> Cute.  I've had a background interest in the Z8000 (triggered by reading
> a Z80000 datasheet around 87/88), and always though about using
> the segmented rather than unsegmented device.
> 
> The following has a bit more info about the version of System III
> ported to their boxes:
> 
> https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf
> 
> DF

From crossd at gmail.com  Thu Jan 23 00:57:50 2020
From: crossd at gmail.com (Dan Cross)
Date: Wed, 22 Jan 2020 09:57:50 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
Message-ID: <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>

The quiz and answers were also printed in the Australian Unix User's Group
Newsletter, volume 5, numbers 5 and 6, respectively. It looks like that
might also have been copied from ';login:'? It's unclear to me.

I appreciate the additional commentary, though. Obviously some of these are
very site-specific (Chesson's phone extension, for example).

The "Who wrote the Bourne shell?" question kind of reminds me of the old
Bugs Bunny bit where he'd be on some radio gameshow and the host would ask,
"Who's buried in Grant's Tomb?" and no one would get it right. (Except
totally different because, of course, no one is buried in Grant's Tomb:
Grant and his wife are entombed in sarcophagi above ground, not buried
below.)

Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would
think the answer would be `cafbde`. Apparently in the original, option
'(d)' is missing; one imagines that was to trick the unwary who failed to
adequately read the question.

        - Dan C.


On Wed, Jan 22, 2020 at 4:32 AM Rob Pike <robpike at gmail.com> wrote:

> The answers are up:
>
> https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html
>
> -rob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/3764636a/attachment.html>

From clemc at ccc.com  Thu Jan 23 01:14:25 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 10:14:25 -0500
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl>
References: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl>
Message-ID: <CAC20D2NPMWo9UnyTjRDUmGnnViiXuS9OmxhedEWTbCGKEbJLWQ@mail.gmail.com>

On Wed, Jan 22, 2020 at 8:15 AM Paul Ruizendaal <pnr at planet.nl> wrote:

> Hence it is unlikely that the Onyx had any form of demand paging (other
> than extending the stack in PDP11-like fashion).
>
Actually, more importantly, it was a pure V7 port.  BSD 3.0 (Vax - first
demand paging support for UNIX) was being created and had not yet released.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/cc37a371/attachment.html>

From paul.winalski at gmail.com  Thu Jan 23 02:31:22 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 22 Jan 2020 11:31:22 -0500
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
 <20200121230025.GL15860@mit.edu>
 <CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>
Message-ID: <CABH=_VS6mEDC1gorq44T98P0CyfnvjNqjpUJFWbbSjdq7bAUMQ@mail.gmail.com>

On 1/21/20, Richard Salz <rich.salz at gmail.com> wrote:
>
>And their build and source system was recreated as
> ClearCase.

That was the Domain Software Engineering Environment (DSEE).  One of
my fellow engineers in DEC's Software Development Methods & Tools
group was Dave Leblang,  He had been working on CMS (Code Management
System), DEC's source code versioning system for VAX/VMS.  At Apollo
he developed DSEE, and he was a co-founder of Atria.  CMS took many
ideas from SCCS on the PWB.

Apollo also did some early work in the field of CGI ray-tracing.  They
released the very impressive 4-minute film "Quest: A Long Ray's
Journey into Night" in 1986.  The ray-tracing was done by a network of
100 Apollo workstations and was revolutionary for its time.

-Paul W.

From mah at mhorton.net  Thu Jan 23 03:00:52 2020
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 22 Jan 2020 09:00:52 -0800
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <e44f0597-bff4-2cdd-8ca5-be394eb2e434@mhorton.net>

Absolutely. When I was an impoverished grad student at Berkeley, Zilog 
hired me as a consultant to port vi and the other Berkeley tools to 
their Z8000 UNIX system. It was a treasured paying gig.

As I recall, it was a 16 bit system (with some addressing enhancements 
ala the 11/70). By then, the VAX was popular and everybody wanted 32 bit 
systems. People were pinning their micro-UNIX hopes on the Motorola 68K.

Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box 
based on the Z8000. They loaned one to Berkeley, and it was my first 
home computer when I took it home to port the tools. Everything had to 
be copied over by serial port.

     Mary Ann

On 1/21/20 9:52 AM, Jon Forrest wrote:
> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
> Jon

From imp at bsdimp.com  Thu Jan 23 03:54:08 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Jan 2020 10:54:08 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
Message-ID: <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>

On Wed, Jan 22, 2020 at 7:59 AM Dan Cross <crossd at gmail.com> wrote:

> Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would
> think the answer would be `cafbde`. Apparently in the original, option
> '(d)' is missing; one imagines that was to trick the unwary who failed to
> adequately read the question.
>

I think this is wrong:
16. Q:  Sort the following into chronological order: a) PWB 1.2, b) V7, c)
Whirlwind, d) System V, e) 4.2BSD, f) MERT.
A: cagbef
Whirlwind is a ringer.

So the MERT ACM paper is 1975. The BSTJ is July/Aug 1978 (received Feb
1978). Somewhere I read (don't have a handy reference for it) that MERT
ported V4 as a supervisor process which puts it in 1974 or so. In any
event, this predates everything except Whirlwind which I can't find a paper
for.
PWB 1.2 is based on V6 + stuff. PWB 1.0 was released 1977, but we don't
have an extant 1.2 tape to verify dates with, but 1978 wouldn't be
unreasonable.
We know 7th Edition was released Jan 1979 (PWB 2.0 was released, 1980
sometime)
System V was released January 1983
4.2BSD was released September 1983 (4.1c was released in 1982 though :)

So that would make the right answer c f a b d e

Even DMERT for the 3B20 was released in January 1983 (or the IEEE paper for
it was released then), so it can't be last.

I also have questions about this:

81. Q:  What was the first Unix network?
A: spider
You thought it was Datakit, didn't you? But Sandy Fraser had an earlier
project.

When did Alexander G Fraser's spider cell network happen? For that matter,
when did Datakit happen? I can't find references to either start date on
line (nor anything on spider except for references to it in Dr Fraser's
bio). I can find references to Datakit in 1978 or so.

I  thought the answer was "ARPANET" since we had a NCP on 4th edition Unix
in late 1974 or early 1975 from the University of Illinois dating from that
time (the code in TUHS appears to be based on V6 + a number of patches).

Warner


>         - Dan C.
>
>
> On Wed, Jan 22, 2020 at 4:32 AM Rob Pike <robpike at gmail.com> wrote:
>
>> The answers are up:
>>
>> https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html
>>
>> -rob
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/77cf5fac/attachment.html>

From katolaz at freaknet.org  Thu Jan 23 04:01:36 2020
From: katolaz at freaknet.org (Vincenzo Nicosia)
Date: Wed, 22 Jan 2020 19:01:36 +0100
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
Message-ID: <20200122180136.dcahjd2mjqqcnvn3@unixfarts.net>

On Wed, Jan 22, 2020 at 10:54:08AM -0700, Warner Losh wrote:
> On Wed, Jan 22, 2020 at 7:59 AM Dan Cross <crossd at gmail.com> wrote:
> 
> > Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would
> > think the answer would be `cafbde`. Apparently in the original, option
> > '(d)' is missing; one imagines that was to trick the unwary who failed to
> > adequately read the question.
> >
> 
> I think this is wrong:
> 16. Q:  Sort the following into chronological order: a) PWB 1.2, b) V7, c)
> Whirlwind, d) System V, e) 4.2BSD, f) MERT.
> A: cagbef
> Whirlwind is a ringer.
> 

If not anything else, at least because there is no option g... :)
But I might have missed a joke here?

HND

From pete at nomadlogic.org  Thu Jan 23 04:06:02 2020
From: pete at nomadlogic.org (Pete Wright)
Date: Wed, 22 Jan 2020 10:06:02 -0800
Subject: [TUHS] Apollo Domain/OS
In-Reply-To: <CABH=_VS6mEDC1gorq44T98P0CyfnvjNqjpUJFWbbSjdq7bAUMQ@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
 <DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
 <CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
 <20200121230025.GL15860@mit.edu>
 <CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>
 <CABH=_VS6mEDC1gorq44T98P0CyfnvjNqjpUJFWbbSjdq7bAUMQ@mail.gmail.com>
Message-ID: <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org>



On 2020-01-22 08:31, Paul Winalski wrote:
>
> Apollo also did some early work in the field of CGI ray-tracing.  They
> released the very impressive 4-minute film "Quest: A Long Ray's
> Journey into Night" in 1986.  The ray-tracing was done by a network of
> 100 Apollo workstations and was revolutionary for its time.
Thanks Paul, I vaguely remember being told about this effort by my 
mentor which is what sparked my interest.  At the time we were trying to 
optimally use all available CPU resources for rendering and while we did 
have working solutions it required lots of perl and shell.  so the idea 
of CPU resources being available and shared as a foundational concept on 
the network was really interesting to me.

I also seem to remember him telling me about working on the patriot 
missile system, although i am not certain if i am remembering correctly 
that this was something he did at apollo or at another company in the 
boston area.

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA


From clemc at ccc.com  Thu Jan 23 04:21:13 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 13:21:13 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
Message-ID: <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>

On Wed, Jan 22, 2020 at 12:55 PM Warner Losh <imp at bsdimp.com> wrote:

> I  thought the answer was "ARPANET" since we had a NCP on 4th edition Unix
> in late 1974 or early 1975 from the University of Illinois dating from that
> time (the code in TUHS appears to be based on V6 + a number of patches).
>
Because we can't ask Greg sadly, I think the Holmgren is the last around
that would know definitively and I've personally lost track of him.

That said, I don't think UofI had anything earlier than 5th edition (I
fairly sure that there were very few copies of 4th edition distributed
outside of the Bell: i.e. Columbia, NYU and I thought Harvard; but I don't
think too many more than that).  Lou Katz would be a better source than I,
but I was always under the impression that the number 5th editions, the
count was also a smaller 2 digit integer.  6th was where Unix began to
'spread' and by 7th, 'go viral.'

And to be honest, I personally thought that Steve and Greg did the ArpaNet
NCP work on V6, but it might have been v5th I suppose.  I did not know
about it until the 6th edition work.  But, they were fairly early.  BTW: I
thought the Rand PIPE code was also developed on 6th, but those also might
have been 5th.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/dfbaf3e7/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Jan 23 04:42:44 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 22 Jan 2020 13:42:44 -0500 (EST)
Subject: [TUHS] Unix quix
Message-ID: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>

    > From: Warner Losh

    > this predates everything except Whirlwind which I can't find a paper for.

Given the 'Whirlwind is a ringer' comment, I asssume this:

  https://en.wikipedia.org/wiki/Whirlwind_I<

is what they mean.


Pretty interesting machine, if you study its instruction set, BTW; with no
stack, subroutines are 'interesting'.


   Noel

From imp at bsdimp.com  Thu Jan 23 05:00:41 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Jan 2020 12:00:41 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
Message-ID: <CANCZdfr_s790dbnptEGVkqiEp6sGG4kN85swdYQJFuJ=3WmPPg@mail.gmail.com>

On Wed, Jan 22, 2020 at 10:54 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Jan 22, 2020 at 7:59 AM Dan Cross <crossd at gmail.com> wrote:
>
>> Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would
>> think the answer would be `cafbde`. Apparently in the original, option
>> '(d)' is missing; one imagines that was to trick the unwary who failed to
>> adequately read the question.
>>
>
> I think this is wrong:
> 16. Q:  Sort the following into chronological order: a) PWB 1.2, b) V7, c)
> Whirlwind, d) System V, e) 4.2BSD, f) MERT.
> A: cagbef
> Whirlwind is a ringer.
>
> So the MERT ACM paper is 1975. The BSTJ is July/Aug 1978 (received Feb
> 1978). Somewhere I read (don't have a handy reference for it) that MERT
> ported V4 as a supervisor process which puts it in 1974 or so. In any
> event, this predates everything except Whirlwind which I can't find a paper
> for.
> PWB 1.2 is based on V6 + stuff. PWB 1.0 was released 1977, but we don't
> have an extant 1.2 tape to verify dates with, but 1978 wouldn't be
> unreasonable.
> We know 7th Edition was released Jan 1979 (PWB 2.0 was released, 1980
> sometime)
> System V was released January 1983
> 4.2BSD was released September 1983 (4.1c was released in 1982 though :)
>
> So that would make the right answer c f a b d e
>
> Even DMERT for the 3B20 was released in January 1983 (or the IEEE paper
> for it was released then), so it can't be last.
>
> I also have questions about this:
>
> 81. Q:  What was the first Unix network?
> A: spider
> You thought it was Datakit, didn't you? But Sandy Fraser had an earlier
> project.
>
> When did Alexander G Fraser's spider cell network happen? For that matter,
> when did Datakit happen? I can't find references to either start date on
> line (nor anything on spider except for references to it in Dr Fraser's
> bio). I can find references to Datakit in 1978 or so.
>

Oopa, spoke one google search too soon. I found this:

"Sandy (A. G.) Fraser devised the Spider local-area ring (v6) and the
Datakit switch (v7) that have served in the lab for overadecade. Special
services on Spider included a central network file store, nfs, and a
communication package, ufs. Datakit, a ‘‘central office’’ for data
communication, gav e added impetus to research in distributed computing.
Fraser undertook the Unix Circuit Design System (see CDL in section 4.3) to
support his hardware projects"

in "A Research UNIX Reader: Annotated Excerpts from the Programmer’s
Manual, 1971-1986" by Doug Mcillroy.


> I  thought the answer was "ARPANET" since we had a NCP on 4th edition Unix
> in late 1974 or early 1975 from the University of Illinois dating from that
> time (the code in TUHS appears to be based on V6 + a number of patches).
>
> Warner
>
>
>>         - Dan C.
>>
>>
>> On Wed, Jan 22, 2020 at 4:32 AM Rob Pike <robpike at gmail.com> wrote:
>>
>>> The answers are up:
>>>
>>> https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html
>>>
>>> -rob
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/4bfea0f8/attachment-0001.html>

From imp at bsdimp.com  Thu Jan 23 05:42:21 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Jan 2020 12:42:21 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
 <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
Message-ID: <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>

On Wed, Jan 22, 2020 at 11:21 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Wed, Jan 22, 2020 at 12:55 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> I  thought the answer was "ARPANET" since we had a NCP on 4th edition
>> Unix in late 1974 or early 1975 from the University of Illinois dating from
>> that time (the code in TUHS appears to be based on V6 + a number of
>> patches).
>>
> Because we can't ask Greg sadly, I think the Holmgren is the last around
> that would know definitively and I've personally lost track of him.
>

The publication date for the ACM paper is November 1975. I think I misspoke
and you are right. The 4th edition was Nov 73, and 5th Edition was June 74
(6th was June 75). In order to meet deadlines for ACM publication, it most
likely was 5th Edition, but there's also earlier references to it.

That said, I don't think UofI had anything earlier than 5th edition (I
> fairly sure that there were very few copies of 4th edition distributed
> outside of the Bell: i.e. Columbia, NYU and I thought Harvard; but I don't
> think too many more than that).  Lou Katz would be a better source than I,
> but I was always under the impression that the number 5th editions, the
> count was also a smaller 2 digit integer.  6th was where Unix began to
> 'spread' and by 7th, 'go viral.'
>

Berkeley's license was executed in January 74, so it might be on the list,
unless there was a big delay.

And to be honest, I personally thought that Steve and Greg did the ArpaNet
> NCP work on V6, but it might have been v5th I suppose.  I did not know
> about it until the 6th edition work.  But, they were fairly early.  BTW: I
> thought the Rand PIPE code was also developed on 6th, but those also might
> have been 5th.
>

The code we have is from the 6th edition (judging by diffs, though there's
some weird quirks between it and Dennis_v6, as well as a number of local
patches).

In addition to the Nov 1975 CACM paper, there's CAC 155, published by the
University of Illinois on 3/15/75 which pre-dates the 6th edition by a few
months. You can read it here
https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y
if
you'd like. There's also CAC 177, which covers the period of Jan 1, 1974 to
Dec 31, 1974 which references that Unix had been enhanced to add this after
the contract periopd. This this report may have been issued after CAC 155
and may not be proof of an earlier date (though the issue date in its
metadata in https://www.ideals.illinois.edu/handle/2142/34150 is 31 DEC
1974, it also reports activity through the end of the year so likely was
written later). There's also CAC 162 dated May 15, 1975 (
https://www.ideals.illinois.edu/handle/2142/32293) that references UNIX
talking to the mulix machine via the ARPANET protocols.

RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155
report  (it seems, I've not looked at them exactly, just a quick glance)
that talks about this work. It's the earliest mention of Unix in an RFC
(the next one isn't until 2 years later for an email address for Dave
Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it explodes
in references).

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/9a2928a3/attachment.html>

From pnr at planet.nl  Thu Jan 23 05:54:20 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 22 Jan 2020 20:54:20 +0100
Subject: [TUHS] Spider [was: Unix quix]
Message-ID: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl>

I can answer some of the below, as I was looking into that a few years ago.

> 81. Q:  What was the first Unix network?
> A: spider
> You thought it was Datakit, didn't you? But Sandy Fraser had an earlier
> project.
> 
> When did Alexander G Fraser's spider cell network happen? For that matter,
> when did Datakit happen? I can't find references to either start date on
> line (nor anything on spider except for references to it in Dr Fraser's
> bio). I can find references to Datakit in 1978 or so.

Spider was designed between 1969 and 1974 - the final lab report (#23) dates from December 1974. It was based around a serial loop running at T1 signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about Spider, second half about Datakit).

It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure.

There is an interesting visit report from 1975 that discusses some of the stuff that was done with Spider here: https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf
Beyond those experiments I think Spider usage was limited to file serving (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was used for remote login, but I have not found any traces of such usage. Same for email usage.

From what little I know, I think that Datakit became operational in a test network in 1979 and as a product in 1982.

> I  thought the answer was "ARPANET" since we had a NCP on 4th edition Unix
> in late 1974 or early 1975 from the University of Illinois dating from that
> time (the code in TUHS appears to be based on V6 + a number of patches).

“Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of 1974. To my best knowledge they used V5 and migrated to V6 as it came along. I think they were getting regular update tapes, and they implemented their system as a device driver (plus userland support) to be able to keep up with the steady flow of updates. Greg Chesson was also involved with this Arpanet Unix.

As far as I can tell, Arpanet Unix saw fairly wide deployment within the Arpanet research community, also as a front end processor for other systems.

A few years back I asked on this list why “Network Unix” was not more enthusiastically received by the core Unix development team and (conceptually) integrated into the main code base. I understood the replies as that (i) people were very satisfied with Spider; and (ii) being part of Bell they wanted a networking system that was more compatible with the Bell network, i.e. Datakit.

==

In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long conceptual shadow. From Spider onwards, the Research systems viewed the network as a device (Spider), that could be multiplexed (V8 streams) or even mounted (Plan9). The Arpa lineage saw the network as a long distance bidirectional pipe, with the actual I/O device hidden from view; this view persists all the way to 4.2BSD and beyond.

I often wonder if it was (is?) possible to come up with a design with the conceptual clarity of Plan9, but organised around the “network as a pipe” view instead.



From andreas.hein at berlan.de  Thu Jan 23 05:55:56 2020
From: andreas.hein at berlan.de (Andreas Hein)
Date: Wed, 22 Jan 2020 20:55:56 +0100
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>

As far as i know, there was a U8001 (Z8001 CPU Clone) in the System 
P8000 which run a System III based Unix System named "Wega"
It was designed and produced by Company EAW from East-Berlin GDR (German 
Democratic Republic)

Details with Docs, Schematics and Sourcecode at: http://www.pofo.de/P8000/

KR,

Andreas

Am 21.01.20 um 18:52 schrieb Jon Forrest:
> There's been a lot of discussion about early Unix on Intel, National
> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
> the Z8000, and if not, why not.
>
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
> Jon

From pnr at planet.nl  Thu Jan 23 06:16:26 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 22 Jan 2020 21:16:26 +0100
Subject: [TUHS] "Network Unix" (i.e. Arpanet Unix)
Message-ID: <C0A95C4E-AB5E-4D5E-976E-44D6F5C5B068@planet.nl>

> Because we can't ask Greg sadly, I think the Holmgren is the last around that would know definitively and I've personally lost track of him.

Steve Holmgren and the Arpanet Unix team are still around (at least they were 3 years ago). I just remembered that I put some of my notes & findings in a draft wiki that I wanted to develop for TUHS - but I never finished it:
http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking

The recent find of CSRG report 3 and 4 may be the incentive I needed to complete my notes about 4.1a, 4.1c and 4.2BSD. However, still looking for the actual source tape to 4.1a - the closest I have is its derivative in 2.9BSD (https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net)




From clemc at ccc.com  Thu Jan 23 06:42:18 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 15:42:18 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
 <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
 <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>
Message-ID: <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>

On Wed, Jan 22, 2020 at 2:42 PM Warner Losh <imp at bsdimp.com> wrote:

>
> Berkeley's license was executed in January 74, so it might be on the list,
> unless there was a big delay.
>
That makes sense.


> In addition to the Nov 1975 CACM paper, there's CAC 155, published by the
> University of Illinois on 3/15/75 which pre-dates the 6th edition by a few
> months. You can read it here
> https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y if
> you'd like.
>
Thanks, that tells us it was 5th (BTW the PDF is missing page 1 in the scan
- although I suspect the missing info can be gleaned from RFC 681)

BTW: There is another hint in CAC 155/RFC 681.  The line on page 2 that
reads: "since the user is allowed only sixteen open files."   My memory is
V6 allowed more than 16, over 20 is my memory; but we would have to look at
the structure to see what it is defined as.



>
> RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155
> report  (it seems, I've not looked at them exactly, just a quick glance)
> that talks about this work. It's the earliest mention of Unix in an RFC
> (the next one isn't until 2 years later for an email address for Dave
> Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it explodes
> in references).
>
And that pretty much syncs with my memory of the time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/18f1ca13/attachment.html>

From doug at cs.dartmouth.edu  Thu Jan 23 06:49:24 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 22 Jan 2020 15:49:24 -0500
Subject: [TUHS] Unix quix
Message-ID: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>

The first edition ran on pdp-11, not pdp-7.

Tukey buttered parsnips at the labs, but Brits did
so several centuries before.

Contrary to urban legend, patent was not invoked to
justify the Unix pdp-11; word-processing was. The
quiz does not make this mistake.

The phototypesetter did not smell. The chemicals
for (externally) devoloping photo paper did.

Shahpazian is Dick Shahpazian; Maranzano is Joe Maranzano.

cagbef addresses out of bounds.

I appreciate Rob's discretion about the Waterloo theft.

Doug

From clemc at ccc.com  Thu Jan 23 07:01:23 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 16:01:23 -0500
Subject: [TUHS] "Network Unix" (i.e. Arpanet Unix)
In-Reply-To: <C0A95C4E-AB5E-4D5E-976E-44D6F5C5B068@planet.nl>
References: <C0A95C4E-AB5E-4D5E-976E-44D6F5C5B068@planet.nl>
Message-ID: <CAC20D2NuGE33Y=2u-LF0p2p5M+79c33pU1tD24xCHyYV0Yrdpw@mail.gmail.com>

Paul - this is great.  Thank you.
Clem

On Wed, Jan 22, 2020 at 3:16 PM Paul Ruizendaal <pnr at planet.nl> wrote:

> > Because we can't ask Greg sadly, I think the Holmgren is the last around
> that would know definitively and I've personally lost track of him.
>
> Steve Holmgren and the Arpanet Unix team are still around (at least they
> were 3 years ago). I just remembered that I put some of my notes & findings
> in a draft wiki that I wanted to develop for TUHS - but I never finished it:
>
> http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking
>
> The recent find of CSRG report 3 and 4 may be the incentive I needed to
> complete my notes about 4.1a, 4.1c and 4.2BSD. However, still looking for
> the actual source tape to 4.1a - the closest I have is its derivative in
> 2.9BSD (https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/7496f720/attachment.html>

From nobozo at gmail.com  Thu Jan 23 07:04:23 2020
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 22 Jan 2020 13:04:23 -0800
Subject: [TUHS] Life at UC Berkeley (was Unix on Zilog Z8000?)
In-Reply-To: <e44f0597-bff4-2cdd-8ca5-be394eb2e434@mhorton.net>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <e44f0597-bff4-2cdd-8ca5-be394eb2e434@mhorton.net>
Message-ID: <1f0a98ad-b7f2-fe79-79f1-441800b21b55@gmail.com>



On 1/22/2020 9:00 AM, Mary Ann Horton wrote:

> Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box 
> based on the Z8000. They loaned one to Berkeley, and it was my first 
> home computer when I took it home to port the tools. 

As someone who played a very minor role at UC Berkeley, I thought
I'd amplify this a little. It was amazing how the various vendors
would happily lend (or give) equipment to UC Berkeley. I don't
know how things were at the other top CS schools, but at Berkeley
I found that if I needed something, telling my faculty boss/mentor
would often make the item appear.

For example, I did an early port of Postgres to Windows NT using
a DEC PC with 16MB of RAM. With such a small amount of RAM this
was excruciatingly slow but I made enough progress to show Mike
Stonebraker. He then talked to his friends in industry and all of
a sudden a MIPS(!) box with 64MB of RAM showed up. I was then able
to get the port to the point where it could run the Wisconsin benchmark.

Something similar happened when the group wanted to port an early
version of Postgres95 to Solaris (it had been developed on DEC Alphas 
running OSF/1). Mike said to write up a proposal to Sun that he'd sign
and then send in, which I did. Soon after a couple of Sparcstation 10s
(or 20, I don't remember) showed up and the port was done.

There other systems research groups at UCB in the 90s also were
the happy recipients of all kinds of great hardware. The limiting factor
for such donations was usually finding space to house them. The end
result was that the RAID, Risc, and Postgres groups weren't slowed down
by lack of hardware.

I have no idea what it's like today. Eric Allman, would you care to
comment?

Jon Forrest


From robpike at gmail.com  Thu Jan 23 09:06:46 2020
From: robpike at gmail.com (Rob Pike)
Date: Thu, 23 Jan 2020 10:06:46 +1100
Subject: [TUHS] Unix quix
In-Reply-To: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>

The answers to the quiz are the answers to the quiz. Whether they are
correct may be hard to verify, and cagbef is what my notes have so who
knows?

I've added a word to eliminate the castigation of CAT's hygiene.

-rob


On Thu, Jan 23, 2020 at 7:50 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> The first edition ran on pdp-11, not pdp-7.
>
> Tukey buttered parsnips at the labs, but Brits did
> so several centuries before.
>
> Contrary to urban legend, patent was not invoked to
> justify the Unix pdp-11; word-processing was. The
> quiz does not make this mistake.
>
> The phototypesetter did not smell. The chemicals
> for (externally) devoloping photo paper did.
>
> Shahpazian is Dick Shahpazian; Maranzano is Joe Maranzano.
>
> cagbef addresses out of bounds.
>
> I appreciate Rob's discretion about the Waterloo theft.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200123/b5f6cbe4/attachment.html>

From robpike at gmail.com  Thu Jan 23 09:10:53 2020
From: robpike at gmail.com (Rob Pike)
Date: Thu, 23 Jan 2020 10:10:53 +1100
Subject: [TUHS] Unix quix
In-Reply-To: <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
 <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
 <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>
 <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>
Message-ID: <CAKzdPgx4L4vUwDZN8Qv5-4=VYLyDxsHphAsbZBMg4fMuFh=nRw@mail.gmail.com>

I think the 'd' slipped in during some editing. I've removed it. cagbef it
is.

Don't confuse quiz answers with absolute truth. All history is fiction to
some extent.

-rob


On Thu, Jan 23, 2020 at 7:43 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Wed, Jan 22, 2020 at 2:42 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>> Berkeley's license was executed in January 74, so it might be on the
>> list, unless there was a big delay.
>>
> That makes sense.
>
>
>> In addition to the Nov 1975 CACM paper, there's CAC 155, published by the
>> University of Illinois on 3/15/75 which pre-dates the 6th edition by a few
>> months. You can read it here
>> https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y if
>> you'd like.
>>
> Thanks, that tells us it was 5th (BTW the PDF is missing page 1 in the
> scan - although I suspect the missing info can be gleaned from RFC 681)
>
> BTW: There is another hint in CAC 155/RFC 681.  The line on page 2 that
> reads: "since the user is allowed only sixteen open files."   My memory
> is V6 allowed more than 16, over 20 is my memory; but we would have to look
> at the structure to see what it is defined as.
>
>
>
>>
>> RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155
>> report  (it seems, I've not looked at them exactly, just a quick glance)
>> that talks about this work. It's the earliest mention of Unix in an RFC
>> (the next one isn't until 2 years later for an email address for Dave
>> Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it
>> explodes in references).
>>
> And that pretty much syncs with my memory of the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200123/bcfa26da/attachment.html>

From imp at bsdimp.com  Thu Jan 23 09:34:49 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Jan 2020 16:34:49 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
 <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
 <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>
 <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>
Message-ID: <CANCZdfq=fv22+8DUNB2FZaNLoBikD1HvMt__AGTAFi=jZCBCsw@mail.gmail.com>

On Wed, Jan 22, 2020 at 1:42 PM Clem Cole <clemc at ccc.com> wrote:

> BTW: There is another hint in CAC 155/RFC 681.  The line on page 2 that
> reads: "since the user is allowed only sixteen open files."   My memory
> is V6 allowed more than 16, over 20 is my memory; but we would have to look
> at the structure to see what it is defined as.
>

Looking at the source in the archives for V5, we see that param.h has "#define
NOFILE  15" and for V6 we see "#define NOFILE 15 /* max open files per
process */". V7 has "#define NOFILE 20 /* max open files per process */"
though, so maybe you are thinking of V7 bumping the limit to 20? Or maybe
it was a local change for MIT, since param.h could be edited... But in any
event, I think this means that the CAC 155 reference to 16 files just means
V6 or earlier.

However, I just noticed there's more direct evidence for it being based on
V5. On page 2 of CAC 155 we see

"For further information concerning the different I/O calls the reader is
directed to The UNIX Programmer's Manual, fifth edition, K. Thompson and D.
M. Ritchie, June 1974."

BTW, CAC 155 is the PDF we have linked from the early network page. I
hadn't noticed before now, but seeing the missing page refreshes my
recollection.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/c16dd296/attachment.html>

From clemc at ccc.com  Thu Jan 23 09:42:34 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 18:42:34 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfq=fv22+8DUNB2FZaNLoBikD1HvMt__AGTAFi=jZCBCsw@mail.gmail.com>
References: <CAKzdPgwkFiOtrkLyOdrpcobLJLVbJp+EHRcc4b8Gk8GLg16=Pg@mail.gmail.com>
 <CAKzdPgx-UtNfW-ywoVHP2pwSYQz7zbCb9n4Qn-a5nz7-4x7xsA@mail.gmail.com>
 <CAEoi9W6Y4R8XGT8PNWz6cXeZhHWyrd=kUAvE15D4O_9usg4fvw@mail.gmail.com>
 <CANCZdfoz-YqzDx0hF0gF4WyivChS755O5vdVBTY1UXn5_CnG9g@mail.gmail.com>
 <CAC20D2M3AfLkXOg9p+u2rRPtqHNb13_jLP0zHv31wN7+Yr63iw@mail.gmail.com>
 <CANCZdfrta7MdJSCysLJso=_+6HYY2kbfx9sNSHwn74Fem4yVvw@mail.gmail.com>
 <CAC20D2MA2gWX1-n_R_2_sOA_oyW2reZL1qHWDWuAy2Q_JZ=QQw@mail.gmail.com>
 <CANCZdfq=fv22+8DUNB2FZaNLoBikD1HvMt__AGTAFi=jZCBCsw@mail.gmail.com>
Message-ID: <CAC20D2NWDuz=zQE2Z6GNc6J1+y4G9OiSyv=X5SMyd6ZB+s2vuA@mail.gmail.com>

👍

On Wed, Jan 22, 2020 at 6:35 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Jan 22, 2020 at 1:42 PM Clem Cole <clemc at ccc.com> wrote:
>
>> BTW: There is another hint in CAC 155/RFC 681.  The line on page 2 that
>> reads: "since the user is allowed only sixteen open files."   My memory
>> is V6 allowed more than 16, over 20 is my memory; but we would have to look
>> at the structure to see what it is defined as.
>>
>
> Looking at the source in the archives for V5, we see that param.h has "#define
> NOFILE  15" and for V6 we see "#define NOFILE 15 /* max open files per
> process */". V7 has "#define NOFILE 20 /* max open files per process */"
> though, so maybe you are thinking of V7 bumping the limit to 20? Or maybe
> it was a local change for MIT, since param.h could be edited... But in any
> event, I think this means that the CAC 155 reference to 16 files just means
> V6 or earlier.
>
> However, I just noticed there's more direct evidence for it being based on
> V5. On page 2 of CAC 155 we see
>
> "For further information concerning the different I/O calls the reader is
> directed to The UNIX Programmer's Manual, fifth edition, K. Thompson and D.
> M. Ritchie, June 1974."
>
> BTW, CAC 155 is the PDF we have linked from the early network page. I
> hadn't noticed before now, but seeing the missing page refreshes my
> recollection.
>
> Warner
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/e27f474e/attachment.html>

From imp at bsdimp.com  Thu Jan 23 11:00:35 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Jan 2020 18:00:35 -0700
Subject: [TUHS] Spider [was: Unix quix]
In-Reply-To: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl>
References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl>
Message-ID: <CANCZdfo6ai6sDqJxcepsxquQCYQuiKqtNS0kbYrsP7+qo1cgwg@mail.gmail.com>

On Wed, Jan 22, 2020 at 12:54 PM Paul Ruizendaal <pnr at planet.nl> wrote:

> I can answer some of the below, as I was looking into that a few years ago.
>
> > 81. Q:  What was the first Unix network?
> > A: spider
> > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier
> > project.
> >
> > When did Alexander G Fraser's spider cell network happen? For that
> matter,
> > when did Datakit happen? I can't find references to either start date on
> > line (nor anything on spider except for references to it in Dr Fraser's
> > bio). I can find references to Datakit in 1978 or so.
>
> Spider was designed between 1969 and 1974 - the final lab report (#23)
> dates from December 1974. It was based around a serial loop running at T1
> signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about
> it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about
> Spider, second half about Datakit).
>

Cool! I'll have to watch that.

It connected to its hosts via a (discrete TTL-based) microcontroller or
> “TIU” and seems to have been connected almost immediately to Unix systems:
> the oldest driver I have been able to locate is in the V4 tree (
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It
> used a DMA-based parallel interface into the PDP11. As such, it seems to
> have been much faster than the typical Datakit connection later - but I
> know too little about Datakit to be sure.
>

Me too. I know even less about Spider. I've been looking for Bell Labs
Computing Science Technical Report #23. It's referenced in the visit report
below. So far, the closest I've come is
https://www.computerhistory.org/collections/catalog/102773566 which says
that CHM has it on paper. :/ From about 1990 or so, these reports are easy
to find.


> There is an interesting visit report from 1975 that discusses some of the
> stuff that was done with Spider here:
> https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf
> Beyond those experiments I think Spider usage was limited to file serving
> (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was
> used for remote login, but I have not found any traces of such usage. Same
> for email usage.
>

Oh that's very interesting. The earliest Network Unix was all about remote
login and file transfer (not file servering). The earliest version were for
telnet/ftp clients. Later versions have the servers in them.


> From what little I know, I think that Datakit became operational in a test
> network in 1979 and as a product in 1982.
>

OK.  That's good to know. Are there good references for this?


> > I  thought the answer was "ARPANET" since we had a NCP on 4th edition
> Unix
> > in late 1974 or early 1975 from the University of Illinois dating from
> that
> > time (the code in TUHS appears to be based on V6 + a number of patches).
>
> “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written
> by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of
> 1974. To my best knowledge they used V5 and migrated to V6 as it came
> along. I think they were getting regular update tapes, and they implemented
> their system as a device driver (plus userland support) to be able to keep
> up with the steady flow of updates. Greg Chesson was also involved with
> this Arpanet Unix.
>

That makes sense. The version in our archive is very close to V6.


> As far as I can tell, Arpanet Unix saw fairly wide deployment within the
> Arpanet research community, also as a front end processor for other systems.
>

My research matches that. Starting in about 1976 there was an explosion of
host names with -unix in their name. There's a number of ARPANET census
reports, or ARPANET resource reports that have lots of Unix systems. RFCs
show the explosion from 1977 onward. Google has these reports that can be
downloaded as a PDF, but are otherwise kinda hard to find :(.


> A few years back I asked on this list why “Network Unix” was not more
> enthusiastically received by the core Unix development team and
> (conceptually) integrated into the main code base. I understood the replies
> as that (i) people were very satisfied with Spider; and (ii) being part of
> Bell they wanted a networking system that was more compatible with the Bell
> network, i.e. Datakit.
>

Yea. I never understood how Unix could be so leading edge in computing, yet
so backward (at least so poor at picking winners) at networking. But this
does make a certain amount of sense. We've also seen NIH in the children of
Unix as well (Linux, NetBSD, FreeBSD, OpenBSD and MacOS have all had this
issue, sometimes for good, sometimes for ill).


> In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long
> conceptual shadow. From Spider onwards, the Research systems viewed the
> network as a device (Spider), that could be multiplexed (V8 streams) or
> even mounted (Plan9). The Arpa lineage saw the network as a long distance
> bidirectional pipe, with the actual I/O device hidden from view; this view
> persists all the way to 4.2BSD and beyond.
>

Yes. It's difficult to match a connected socket to a network interface...
And sockets definitely take the view that it's not a device you are talking
to at all, but a special kind of thing that you can do normal I/O to (and a
few other special things too).


> I often wonder if it was (is?) possible to come up with a design with the
> conceptual clarity of Plan9, but organised around the “network as a pipe”
> view instead.
>

We'll never know.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200122/e29b08ff/attachment-0001.html>

From fair at netbsd.org  Thu Jan 23 12:08:11 2020
From: fair at netbsd.org (Erik Fair)
Date: Wed, 22 Jan 2020 18:08:11 -0800
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <e44f0597-bff4-2cdd-8ca5-be394eb2e434@mhorton.net>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <e44f0597-bff4-2cdd-8ca5-be394eb2e434@mhorton.net>
Message-ID: <B19A30B1-C01C-4FF8-859F-7584F1A6D708@netbsd.org>

… and after Mary Ann was done with it (sometime 1981?), Professor Fabry gave the UCB Onyx to a bunch of undergraduates which they used as the first computer of the Undergraduate Computing Facility (UCF, predecessor to the UCB XCF which had a pile of Suns to play with) in room B50 (basement) of Evans Hall. I was one of those undergrads.

That machine became the “x” host on the UCB BerkNet, and it was where B version netnews software was written by Matt Glickman (he was a high school student at the time and while he had Mary Ann’s patronage, my memory is that none of the more official computer services in CS or the Computer Center would give him an account - but we did). At the time, every other computer had restrictions on who could use ‘em, or that you had to pay hefty fees for use (the computer center PDP-11/70s were in that class) - our policy was: if you have a current UCB student ID, we’ll give you an account. We didn’t care whether you were a CS or Engineering student, or not.

I remember fixing bugs in various bits of BSD stuff we added to the userland and kernel - we had full source to play with, which was nice. Adding job control was a top priority, and one of our hacks was to change the tty line discipline to restore previous “cooked” character processing state if the program in foreground which had last changed it exited non-zero - that way, programs that modified tty state didn’t need to be recoded for job control too, which, in a system with PDP-11-like memory restrictions (64k text, 64k data maximum per process), was useful.

We trained an awful lot of students in the ways of Unix, and many of them became system administrators of the explosion of Unix systems which came to UCB later: the workstation clusters, other microcomputer based Unixes, etc. Kernel hackers (systems programmers) too.

Mary Ann also allowed me to photocopy a samizdat copy of the Lions Book, too. I still have that … somewhere, though I bought a copy of the Peter Salus 1996 republication, too.

	Erik Fair

> On Jan 22, 2020, at 09:00, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> Absolutely. When I was an impoverished grad student at Berkeley, Zilog hired me as a consultant to port vi and the other Berkeley tools to their Z8000 UNIX system. It was a treasured paying gig.
> 
> As I recall, it was a 16 bit system (with some addressing enhancements ala the 11/70). By then, the VAX was popular and everybody wanted 32 bit systems. People were pinning their micro-UNIX hopes on the Motorola 68K.
> 
> Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box based on the Z8000. They loaned one to Berkeley, and it was my first home computer when I took it home to port the tools. Everything had to be copied over by serial port.
> 
>     Mary Ann
> 
> On 1/21/20 9:52 AM, Jon Forrest wrote:
>> There's been a lot of discussion about early Unix on Intel, National
>> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
>> the Z8000, and if not, why not.
>> 
>> As I remember the Z8000 was going to be the great white hope that
>> would continue Zilog's success with the Z80 into modern times.
>> But, it obviously didn't happen.
>> 
>> Why?
>> 
>> Jon


From ggm at algebras.org  Thu Jan 23 13:42:29 2020
From: ggm at algebras.org (George Michaelson)
Date: Thu, 23 Jan 2020 13:42:29 +1000
Subject: [TUHS] Spider [was: Unix quix]
In-Reply-To: <CANCZdfo6ai6sDqJxcepsxquQCYQuiKqtNS0kbYrsP7+qo1cgwg@mail.gmail.com>
References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl>
 <CANCZdfo6ai6sDqJxcepsxquQCYQuiKqtNS0kbYrsP7+qo1cgwg@mail.gmail.com>
Message-ID: <CAKr6gn2zju=a4tWVt9XgPF_oN3aOibMk=Dc2S-Kh6JXwmO6rjA@mail.gmail.com>

Be careful talking about "spider" in UNIX contexts, thats a UK
(Scottish?) UNIX consultancy, which did JANET X.25 related work.
Different Spider. Spider Systems maybe.

-G

On Thu, Jan 23, 2020 at 11:01 AM Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Wed, Jan 22, 2020 at 12:54 PM Paul Ruizendaal <pnr at planet.nl> wrote:
>>
>> I can answer some of the below, as I was looking into that a few years ago.
>>
>> > 81. Q:  What was the first Unix network?
>> > A: spider
>> > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier
>> > project.
>> >
>> > When did Alexander G Fraser's spider cell network happen? For that matter,
>> > when did Datakit happen? I can't find references to either start date on
>> > line (nor anything on spider except for references to it in Dr Fraser's
>> > bio). I can find references to Datakit in 1978 or so.
>>
>> Spider was designed between 1969 and 1974 - the final lab report (#23) dates from December 1974. It was based around a serial loop running at T1 signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about Spider, second half about Datakit).
>
>
> Cool! I'll have to watch that.
>
>> It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure.
>
>
> Me too. I know even less about Spider. I've been looking for Bell Labs Computing Science Technical Report #23. It's referenced in the visit report below. So far, the closest I've come is https://www.computerhistory.org/collections/catalog/102773566 which says that CHM has it on paper. :/ From about 1990 or so, these reports are easy to find.
>
>>
>> There is an interesting visit report from 1975 that discusses some of the stuff that was done with Spider here: https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf
>> Beyond those experiments I think Spider usage was limited to file serving (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was used for remote login, but I have not found any traces of such usage. Same for email usage.
>
>
> Oh that's very interesting. The earliest Network Unix was all about remote login and file transfer (not file servering). The earliest version were for telnet/ftp clients. Later versions have the servers in them.
>
>>
>> From what little I know, I think that Datakit became operational in a test network in 1979 and as a product in 1982.
>
>
> OK.  That's good to know. Are there good references for this?
>
>>
>> > I  thought the answer was "ARPANET" since we had a NCP on 4th edition Unix
>> > in late 1974 or early 1975 from the University of Illinois dating from that
>> > time (the code in TUHS appears to be based on V6 + a number of patches).
>>
>> “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of 1974. To my best knowledge they used V5 and migrated to V6 as it came along. I think they were getting regular update tapes, and they implemented their system as a device driver (plus userland support) to be able to keep up with the steady flow of updates. Greg Chesson was also involved with this Arpanet Unix.
>
>
> That makes sense. The version in our archive is very close to V6.
>
>>
>> As far as I can tell, Arpanet Unix saw fairly wide deployment within the Arpanet research community, also as a front end processor for other systems.
>
>
> My research matches that. Starting in about 1976 there was an explosion of host names with -unix in their name. There's a number of ARPANET census reports, or ARPANET resource reports that have lots of Unix systems. RFCs show the explosion from 1977 onward. Google has these reports that can be downloaded as a PDF, but are otherwise kinda hard to find :(.
>
>>
>> A few years back I asked on this list why “Network Unix” was not more enthusiastically received by the core Unix development team and (conceptually) integrated into the main code base. I understood the replies as that (i) people were very satisfied with Spider; and (ii) being part of Bell they wanted a networking system that was more compatible with the Bell network, i.e. Datakit.
>
>
> Yea. I never understood how Unix could be so leading edge in computing, yet so backward (at least so poor at picking winners) at networking. But this does make a certain amount of sense. We've also seen NIH in the children of Unix as well (Linux, NetBSD, FreeBSD, OpenBSD and MacOS have all had this issue, sometimes for good, sometimes for ill).
>
>>
>> In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long conceptual shadow. From Spider onwards, the Research systems viewed the network as a device (Spider), that could be multiplexed (V8 streams) or even mounted (Plan9). The Arpa lineage saw the network as a long distance bidirectional pipe, with the actual I/O device hidden from view; this view persists all the way to 4.2BSD and beyond.
>
>
> Yes. It's difficult to match a connected socket to a network interface...  And sockets definitely take the view that it's not a device you are talking to at all, but a special kind of thing that you can do normal I/O to (and a few other special things too).
>
>>
>> I often wonder if it was (is?) possible to come up with a design with the conceptual clarity of Plan9, but organised around the “network as a pipe” view instead.
>
>
> We'll never know.
>
> Warner

From jon at fourwinds.com  Thu Jan 23 14:31:34 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 22 Jan 2020 20:31:34 -0800
Subject: [TUHS] Spider [was: Unix quix]
In-Reply-To: <CAKr6gn2zju=a4tWVt9XgPF_oN3aOibMk=Dc2S-Kh6JXwmO6rjA@mail.gmail.com>
References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl>
 <CANCZdfo6ai6sDqJxcepsxquQCYQuiKqtNS0kbYrsP7+qo1cgwg@mail.gmail.com>
 <CAKr6gn2zju=a4tWVt9XgPF_oN3aOibMk=Dc2S-Kh6JXwmO6rjA@mail.gmail.com>
Message-ID: <202001230431.00N4VYfb3655315@darkstar.fourwinds.com>

It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately
to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than
the typical Datakit connection later - but I know too little about Datakit to be sure.

I have vague memories here that maybe Heinz can help with if his are any better.
I believe that Sandy played a part in "the loop" or "the ring" or whatever it
was called that we had connecting our Honeywell 516 to peripherals.  I do
remember the 74S00 repeaters because of the amount of time that Dave Weller
spent tuning them when the error rate got high.  Also, being a loop, Joe
Condon used to pull his connectors out of the wall whenever people weren't
showing up to a meeting on time.  I don't know whether our network was a
forerunner to the spider network.

Jon

From pnr at planet.nl  Thu Jan 23 18:38:02 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 23 Jan 2020 09:38:02 +0100
Subject: [TUHS] Spider
Message-ID: <A13160AD-7108-48AB-BB99-F262382CC0A8@planet.nl>


> I have vague memories here that maybe Heinz can help with if his are any better.
> I believe that Sandy played a part in "the loop" or "the ring" or whatever it
> was called that we had connecting our Honeywell 516 to peripherals.  I do
> remember the 74S00 repeaters because of the amount of time that Dave Weller
> spent tuning them when the error rate got high.  Also, being a loop, Joe
> Condon used to pull his connectors out of the wall whenever people weren't
> showing up to a meeting on time.  I don't know whether our network was a
> forerunner to the spider network.

It most likely was Spider - it became operational in 1972. The vist report that I linked to earlier also says:

"The current system contains just one loop with the switching computer (TEMPO I),
four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers,
and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are
connected in turn to other items of digital equipment.”

It would be interesting to know more about the H516’s and Spider, any other recollections?




From lehmann at ans-netz.de  Thu Jan 23 22:01:20 2020
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Thu, 23 Jan 2020 13:01:20 +0100
Subject: [TUHS] Unix on Zilog Z8000?
In-Reply-To: <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>
Message-ID: <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net>

Hi,

let me just reply to this single message :)

> Details with Docs, Schematics and Sourcecode at: http://www.pofo.de/P8000/

Wow - my page gets quoted on TUHS-ML :)

The 16 Bit board runs WEGA (renamed copy of ZEUS). The board is a copy  
of the 16 Bit Board from Zilogs System 8000. Some parts where added  
because the subsystem design is different (serial ports, harddisk,  
floppy disks instead of tape,...).
WEGA only runs on a Z8001 (no Z8002) and the OS was able to execute  
(and compile) segmented (full memory access) and unsegmented (only 64K  
access iirc) binaries.

The OS of the P8000 is as I said a copy of ZEUS. The name ZEUS was  
"replaced" with WEGA in the executables (hex editor).
Some parts of the system where reverse engineered and altered. I had  
contact to a kernel developer after the system collapsed who told me  
some stories ;)
While the userland ist nearly a 100% copy of ZEUS, main parts of the  
kernel (dev) where changed to handle the different system layout.

I own a complete and running P8000 as well as a S8000 which could run  
if I would have
a) a copy of the Zilog ZEUS Installation Tape (+ system diagnostic tape)
b) a working tape drive (non-standard tape not compatible to something else)
c) a SA1100 harddisk, or c) a SMD Controller + SMD disks.
d) time

After I designed, built and programmed a harddisk subsystem emulator  
for the P8000, I also planed to emulate the whole disk subsystem of  
the S8000. Additionally I planned to use a partial backup of a ZEUS  
installation I have + WEGA to generate a running ZEUS-a-like but then  
I became a father and time was gone ;)

So right now my S8000 sits in my basement togehter with some circuit  
ideas and logical analysation results and waits for more time ;)

Some links...

Kernel Sources of WEGA I could get my hands on, or are disassembled  
and "make-it-C-code-again"ed by me
https://github.com/OlliL/P8000/tree/master/WEGA/src/uts
Beside that there is also other stuff like C compiler sources and so  
on - just navigate around :)

Zilog S8000 pics
http://pics.pofo.de/index.php?/category/129

EAW P8000 pics
http://pics.pofo.de/index.php?/category/21

Some S8000 sources (mostly firmware, rebuilt with having access to the  
P8000 firmware)
https://github.com/OlliL/S8000

Any questions are welcome....

Best regards,
Oliver

From leah at vuxu.org  Fri Jan 24 01:56:49 2020
From: leah at vuxu.org (Leah Neukirchen)
Date: Thu, 23 Jan 2020 16:56:49 +0100
Subject: [TUHS] Unix quix
In-Reply-To: <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 (Rob Pike's message of "Thu, 23 Jan 2020 10:06:46 +1100")
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
Message-ID: <87h80m6u9q.fsf@vuxu.org>

Rob Pike <robpike at gmail.com> writes:

> The answers to the quiz are the answers to the quiz. Whether they are
> correct may be hard to verify, and cagbef is what my notes have so who
> knows?

The question is missing a part:

16. Sort the following into chronological order: a) PWB 1.2, b) V7, c)
Whirlwind, e) System V, f) 4.2BSD, g)
    MERT.
             cagbef|c a g b e f

>From an file George Rosamond sent me in 2009:
http://leahneukirchen.org/trivium/unixquiz-solution.txt
I also collected some more sources:
http://leahneukirchen.org/trivium/2009-01-18

hth,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From jon at fourwinds.com  Fri Jan 24 03:40:04 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Jan 2020 09:40:04 -0800
Subject: [TUHS] Spider
In-Reply-To: <A13160AD-7108-48AB-BB99-F262382CC0A8@planet.nl>
References: <A13160AD-7108-48AB-BB99-F262382CC0A8@planet.nl>
Message-ID: <202001231740.00NHe4nY3787935@darkstar.fourwinds.com>

Paul Ruizendaal writes:
> 
>
> > I have vague memories here that maybe Heinz can help with if his are any better.
> > I believe that Sandy played a part in "the loop" or "the ring" or whatever it
> > was called that we had connecting our Honeywell 516 to peripherals.  I do
> > remember the 74S00 repeaters because of the amount of time that Dave Weller
> > spent tuning them when the error rate got high.  Also, being a loop, Joe
> > Condon used to pull his connectors out of the wall whenever people weren't
> > showing up to a meeting on time.  I don't know whether our network was a
> > forerunner to the spider network.
>
> It most likely was Spider - it became operational in 1972. The vist report that I linked to earlier also says:
>
> "The current system contains just one loop with the switching computer (TEMPO I),
> four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers,
> and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are
> connected in turn to other items of digital equipment.”
>
> It would be interesting to know more about the H516’s and Spider, any other recollections?

Ugh.  Memory lane has a lot of potholes.  This was a really long time ago.

I believe that the 516 network predated your quote above and was most likely
designed for the 516 as I'm pretty sure that Sandy was in our department; I
have some recollection of his office being in our block of rooms and of
spending some time talking to him.

I am guessing that one of these was installed in the UNIX lab but I
really don't know.  My guess is based on a recollection that there was a
GLANCE G up there, and the only interface to one of these was the network.
I can't imagine them not having a cool toy like the GLANCE G up there.
Maybe Doug or Ken remembers.

I also recall that the network was technically a Pierce Loop, named after
John Pierce of course.  My best recollection is that this ran off of the
DMA controller on the 516.  I think that it regularly sent a big block of
data around the loop.  That block had "holes" in it in which any "terminal"
device could say "hey, gimme some attention" or "here's some data".  I'm
using terminal here to mean any device other than the 516 that was moving
the bits around.  I have no memory of how collisions were handled or whether
there was any sort of bit-per-terminal device to avoid collisions.

The bits were sent around on coax.  They didn't go very far, and there were
repeater boards everywhere.  I don't recall any separate power supplies for
the repeater boards so maybe there was some DC on the coax for that.  The
repeater boards used 74S00s for drivers, and there was some sort of tuned
circuit that had an adjustment.  Every once in a while Dave Weller would
make the circuit with a scope and a little green screwdriver to keep things
working.

A day sticks out in my memory.  We were still in building 2 before buildings
6 and 7 were built and we moved to building 7.  The error rate on the network
went through the roof and became unusable, and I think when that happened the
516 crashed.  Wasn't a repeater, wasn't Joe pulling the plugs out of the wall.
Someone in a nearby lab had left a cover off of their cyclotron.  Can't express
how comforting that was; on par with discovering that the track on which I ran
in junior high school was a radioactive toxic waste dump or coming across family
photos of me in an open-pit Quebec asbestos mine as a kid.

I know that there were other instances of this network around the labs.  I did
a project that supported integrated circuit test systems in labs driven by a
single cost computer.  Yes folks, there was a day in which a computer cost more
than a wafer stepper :-)  This system was based on 516-TSS and the network.  It
sticks in my mind because I was working on it during the big Western Electric
debacle around the memory chip failures in the big new ESS installed in the
basement of the Chicago Sears Tower.

Anyway, that's all I can remember about this at the moment.  Heinz should know
something about it but his memory may be as bad as mine.  Another person who
would know is John Camlet.  Don't know if he's still around; a quick search
shows someone of about the right age living in Plainfield, NJ so if someone
lives out there try knocking on the door.

Jon

From jon at fourwinds.com  Fri Jan 24 04:42:35 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Jan 2020 10:42:35 -0800
Subject: [TUHS] Another oldie but goodie available if anyone wants it [
 DECNET ]
Message-ID: <202001231842.00NIgZju3798969@darkstar.fourwinds.com>

Was looking for my DomainOS manuals and came across a fat notebook
containing the DECNET Phase III spec.  Anyone want it?  Not anything
that I need to keep and low-hanging fruit on the decluttering list.

Jon

From jon at fourwinds.com  Fri Jan 24 05:01:16 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Jan 2020 11:01:16 -0800
Subject: [TUHS] More oldies but goodies available if anyone wants them
Message-ID: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>

Kind of scary what's in my basement.  For those of you building UNIX
workstations in the early days, I have a big fat notebook full of
Weitek floating point chip specs, many of which are marked as preliminary.
Also a set of CORBA specs.  Again, low-hanging fruit that's getting
recycled unless anyone has a use for them.

In the not completely sure that I want to part with them yet for some
strange reason, I have a set of SunOS manuals.

Also, if anyone collects old hardware I have a SparcStation 20 with a
slightly modified SunOS sitting around and an Ultra 60 Solaris box.

Jon

From kevin.bowling at kev009.com  Fri Jan 24 09:01:20 2020
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 23 Jan 2020 16:01:20 -0700
Subject: [TUHS] More oldies but goodies available if anyone wants them
In-Reply-To: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
Message-ID: <CAK7dMtDZa68sb4csvWV7KJq19i_jbiv4M0JRofZE9PR2pxDhPw@mail.gmail.com>

What are the mods?  I have a stack of 10s and 20s but will take it for safe
keeping if nobody else will.

On Thu, Jan 23, 2020 at 12:01 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Kind of scary what's in my basement.  For those of you building UNIX
> workstations in the early days, I have a big fat notebook full of
> Weitek floating point chip specs, many of which are marked as preliminary.
> Also a set of CORBA specs.  Again, low-hanging fruit that's getting
> recycled unless anyone has a use for them.
>
> In the not completely sure that I want to part with them yet for some
> strange reason, I have a set of SunOS manuals.
>
> Also, if anyone collects old hardware I have a SparcStation 20 with a
> slightly modified SunOS sitting around and an Ultra 60 Solaris box.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200123/8f95391d/attachment.html>

From gregg.drwho8 at gmail.com  Fri Jan 24 09:08:04 2020
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Thu, 23 Jan 2020 18:08:04 -0500
Subject: [TUHS] More oldies but goodies available if anyone wants them
In-Reply-To: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
Message-ID: <CAC5iaNGAGitd9aZvQMEzJzLVGjxRxi2KTKqec5sHG_oxLXf+cg@mail.gmail.com>

Hello!
At one point I'd be delighted to take one or the other of the Sun
boxes, but I've been advised to no longer do that. Kevin do me a favor
and take both. However... I'm looking for DEC Terminal Server devices,
the Model 90L or Model 90L Plus devices.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Thu, Jan 23, 2020 at 2:02 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Kind of scary what's in my basement.  For those of you building UNIX
> workstations in the early days, I have a big fat notebook full of
> Weitek floating point chip specs, many of which are marked as preliminary.
> Also a set of CORBA specs.  Again, low-hanging fruit that's getting
> recycled unless anyone has a use for them.
>
> In the not completely sure that I want to part with them yet for some
> strange reason, I have a set of SunOS manuals.
>
> Also, if anyone collects old hardware I have a SparcStation 20 with a
> slightly modified SunOS sitting around and an Ultra 60 Solaris box.
>
> Jon

From jon at fourwinds.com  Fri Jan 24 09:48:30 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Jan 2020 15:48:30 -0800
Subject: [TUHS] More oldies but goodies available if anyone wants them
In-Reply-To: <CAK7dMtDZa68sb4csvWV7KJq19i_jbiv4M0JRofZE9PR2pxDhPw@mail.gmail.com>
References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
 <CAK7dMtDZa68sb4csvWV7KJq19i_jbiv4M0JRofZE9PR2pxDhPw@mail.gmail.com>
Message-ID: <202001232348.00NNmUmc3853455@darkstar.fourwinds.com>

Kevin Bowling writes:
>
> What are the mods?  I have a stack of 10s and 20s but will take it for safe
> keeping if nobody else will.
>
> On Thu, Jan 23, 2020 at 12:01 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Kind of scary what's in my basement.  For those of you building UNIX
> > workstations in the early days, I have a big fat notebook full of
> > Weitek floating point chip specs, many of which are marked as preliminary.
> > Also a set of CORBA specs.  Again, low-hanging fruit that's getting
> > recycled unless anyone has a use for them.
> >
> > In the not completely sure that I want to part with them yet for some
> > strange reason, I have a set of SunOS manuals.
> >
> > Also, if anyone collects old hardware I have a SparcStation 20 with a
> > slightly modified SunOS sitting around and an Ultra 60 Solaris box.
> >
> > Jon

The Sparc 20 includes the double-buffered graphics board.  Thanks to an
unnamed employee, I got the code to do a kernel mod so that I can run
SunView on the front buffer and X on the rear buffer and switch between
the two by running the mouse off of the side of the screen.

I probably have installation media around for both of these systems.
Which means that I also have a QIC-150 drive to go with 'em.  And a
stack of QIC-150 and QIC-50 tapes that I've been wanting to get rid
of but haven't managed to procure a good bulk eraser yet.  Also may
have Sun DDS-2, DDS-3, and DDS-4 DAT drives; will have to look.  I
also have one of the Archive Python DAT drives with the special SGI
firmware that lets the DDS layer be turned off so that you can read
and write audio DATs; that's currently loaned out and I'd need to
check the status of it.

Jon

From pnr at planet.nl  Fri Jan 24 11:28:19 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 24 Jan 2020 02:28:19 +0100
Subject: [TUHS] Spider
Message-ID: <EB9601C1-EE17-4E43-B69F-C9802A506597@planet.nl>

> Ugh. Memory lane has a lot of potholes. This was a really long time ago. 

Many thanks for that post - really interesting!

I had to look up "Pierce Network", and found it described in the Bell Journal:
https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf

In my reading the Spider network is a type of Pierce network.

However, the network that you remember is indeed most likely different from Spider:
- it was coax based, whereas the Spider line was a twisted pair
- there was more than one, whereas Spider only ever had one (operational) loop

Condon and Weller are acknowledged in the report about Spider as having done many of its hardware details. The report discusses learnings from the project and having to tune repeaters is not among them (but another operational issue with its 'line access modules’ is discussed).

All in all, maybe these coax loops were pre-cursors to the Spider network, without a switch on the loop (“C” nodes in the Pierce paper). It makes sense to first try out the electrical and line data protocol before starting work on higher level functions.

I have no idea what a GLANCE G is...





From pnr at planet.nl  Fri Jan 24 11:59:23 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 24 Jan 2020 02:59:23 +0100
Subject: [TUHS] Spider (and back to quiz)
Message-ID: <13430143-695E-4DBD-A443-9ECCA0FB4283@planet.nl>

There is more in that issue of BSTJ, and indeed it seems this was a precursor.

https://ia801905.us.archive.org/25/items/bstj51-6-1147/bstj51-6-1147_text.pdf
https://ia801603.us.archive.org/0/items/bstj51-6-1167/bstj51-6-1167_text.pdf

The first paper makes mention of repeaters starting to self oscillate, and a redesign being underway.

There is a possibility that a Unix PDP11 was connected to this earlier network prior to Spider existing, in which case the accepted quiz answer would be wrong.


>> Ugh. Memory lane has a lot of potholes. This was a really long time ago. 
> 
> Many thanks for that post - really interesting!
> 
> I had to look up "Pierce Network", and found it described in the Bell Journal:
> https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf
> 
> In my reading the Spider network is a type of Pierce network.
> 
> However, the network that you remember is indeed most likely different from Spider:
> - it was coax based, whereas the Spider line was a twisted pair
> - there was more than one, whereas Spider only ever had one (operational) loop
> 
> Condon and Weller are acknowledged in the report about Spider as having done many of its hardware details. The report discusses learnings from the project and having to tune repeaters is not among them (but another operational issue with its 'line access modules’ is discussed).
> 
> All in all, maybe these coax loops were pre-cursors to the Spider network, without a switch on the loop (“C” nodes in the Pierce paper). It makes sense to first try out the electrical and line data protocol before starting work on higher level functions.
> 
> I have no idea what a GLANCE G is...





From jon at fourwinds.com  Fri Jan 24 12:37:24 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Jan 2020 18:37:24 -0800
Subject: [TUHS] Spider
In-Reply-To: <EB9601C1-EE17-4E43-B69F-C9802A506597@planet.nl>
References: <EB9601C1-EE17-4E43-B69F-C9802A506597@planet.nl>
Message-ID: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com>

Paul Ruizendaal writes:
> > Ugh. Memory lane has a lot of potholes. This was a really long time ago. 
>
> Many thanks for that post - really interesting!
>
> I had to look up "Pierce Network", and found it described in the Bell Journal:
> https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf
>
> In my reading the Spider network is a type of Pierce network.
>
> However, the network that you remember is indeed most likely different from Spider:
> - it was coax based, whereas the Spider line was a twisted pair
> - there was more than one, whereas Spider only ever had one (operational) loop
>
> Condon and Weller are acknowledged in the report about Spider as having done
> many of its hardware details. The report discusses learnings from the project
> and having to tune repeaters is not among them (but another operational issue
> with its 'line access modules’ is discussed).
>
> All in all, maybe these coax loops were pre-cursors to the Spider network,
> without a switch on the loop (“C” nodes in the Pierce paper). It makes sense
> to first try out the electrical and line data protocol before starting work
> on higher level functions.
>
> I have no idea what a GLANCE G is...

Again, very fuzzy memory here but there are a few folks on the list who might
remember more like Heinz.  As I said earlier, I recall Sandy being in our group
so our network may have been the first try.  I don't know who designed it.

The GLANCE G was an experimental graphics terminal developed in our group.  I
think that John Camlet did a bunch of the hardware design as I have a strong
memory of a long afternoon with him after having weird squiggles show up in
short vectors which turned out to be a microcode bug.  The thing had 4K
resolution in at least one axis, it may have been a square screen.  It used
1K DRAMs and was built around a 74S181 bit slice machine.  A lot of interesting
stuff was done on it;  I mentioned Dick Hause's Display Terminal Editor in an
earlier post.  I also remember a really nice graphical demo of how the phone
network routed around outages which of course no longer works due to lack of
redundancy.

Oh, yeah, the real use for these comes back to me :-)  A number of the folks
in the group including Carl Christensen (who was one of the two people who
interviewed Ken for his job at the labs) had purchased property up in
Vermont for ski cabins.  These lots had ancient surveys, the old "from the big
tree near the large rock" sort of property descriptions.  So the main use of
the Glance G's for a while was to draw out the surveys and figure out what to
do about closure errors.  If you don't know about it, and this is the only
reason why I do, a closure error is when you follow the property boundary
described by the survey and the end isn't at the beginning.

Anyway, these were very cool machines for their time.  I don't recall any other
graphical devices at the time except for glass tty terminals, Tektronix storage
tubes, and the GRIN-2 on the PDP-15 that we used for space war as per earlier
posts.

Dave Hagelbarger designed the keyboard and to this date it's still one of the
best keyboards that I ever used as far as feel goes.  It had plastic cups under
the keys that gave resistance and then accelerated after a certain point so you
pushed on a key and then it would shoot the rest of the way.  And there was a
solenoid on the bottom of the circuit board so there was a little click that
you felt in your fingers.  Great feedback.

There were some extra parts left over from building these.  I remember that Joe
Condon had the glass shop do some work on an extra or dead CRT, and one of the
terminals in his office was actually a fish tank.  When you turned it on a light
would come on behind the tube and you could see the fish swimming around in it.
Maybe Joe deserves credit for the original fish screen saver.

Oh yeah, another thing that I remember being tried was that someone had built an
array of LEDs and photodiodes surrounding the screen that could be used as an
input device.  It was low res but you could point at things with your fingers.

One of the projects that I did was to write software for nicely plotting graphs
on these.  Was used a bunch by Jim Kaiser and crowd for their digital filter
work.  I remember a really nice graph that Jim did that showed just how carefully
the touch tone frequencies were chosen to have no harmonics in common.

This isn't really UNIX stuff but I suppose that it passes for prehistory.  Again,
I seem to recall that one of these was up in the UNIX lab but have no memory of
what it was used for.  If I had to guess, it would be chess.

Oh yeah, I think that you can see the GLANCE G instruction set if you have a
first edition copy of Newman and Sproul.  I remember getting a copy of that book
and having a weird sense of deja vu during their discussion of vector graphics.
Then I realized that it was because it was the instruction set that was burned
into my memory.

Jon

From imp at bsdimp.com  Fri Jan 24 12:44:58 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 23 Jan 2020 19:44:58 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <87h80m6u9q.fsf@vuxu.org>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 <87h80m6u9q.fsf@vuxu.org>
Message-ID: <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>

On Thu, Jan 23, 2020, 8:57 AM Leah Neukirchen <leah at vuxu.org> wrote:

> Rob Pike <robpike at gmail.com> writes:
>
> > The answers to the quiz are the answers to the quiz. Whether they are
> > correct may be hard to verify, and cagbef is what my notes have so who
> > knows?
>
> The question is missing a part:
>
> 16. Sort the following into chronological order: a) PWB 1.2, b) V7, c)
> Whirlwind, e) System V, f) 4.2BSD, g)
>     MERT.
>              cagbef|c a g b e f
>
> From an file George Rosamond sent me in 2009:
> http://leahneukirchen.org/trivium/unixquiz-solution.txt
> I also collected some more sources:
> http://leahneukirchen.org/trivium/2009-01-18


MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while
pwb 1.2  is 1978 or 1979. By the time pwb 1.2 was coming out, it had
mutated to UNIX/RT... MERT was V4 while releases of PWB were V6 based. And
the link for the graph (which are often horribly sourced for the early
stuff) is dead.

Warner


> hth,
> --
> Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200123/064ce4b4/attachment.html>

From gregg.drwho8 at gmail.com  Fri Jan 24 13:03:02 2020
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Thu, 23 Jan 2020 22:03:02 -0500
Subject: [TUHS] Spider
In-Reply-To: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com>
References: <EB9601C1-EE17-4E43-B69F-C9802A506597@planet.nl>
 <202001240237.00O2bOEG3883117@darkstar.fourwinds.com>
Message-ID: <CAC5iaNEm6CoBza2iah=y-z+MFH2z=mGO=seG1uE3vNV38Z4Qgg@mail.gmail.com>

Hello!
GACK! (Excuse me.) Hello!
That description of how someone back there used a batch of LEDs and
photodiodes to form an input device triggered a memory of my own. One
Steve Ciarcia who wrote the Circuit Cellar column for Byte magazine
described that same method. He even included a photo of the prototype
using a picture frame to hold them. The code to manage it was written
in BASIC of all things for one of his custom cards, and it was mounted
on his equally custom system. He also described a similar method of
generating graphics using two DAC devices and a scope itself switched
into X-Y mode. (Code was also in BASIC for starters.)

Let us now return to the wonders of UNIX and as it relates to the
early networking ideas.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Thu, Jan 23, 2020 at 9:38 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Paul Ruizendaal writes:
> > > Ugh. Memory lane has a lot of potholes. This was a really long time ago.
> >
> > Many thanks for that post - really interesting!
> >
> > I had to look up "Pierce Network", and found it described in the Bell Journal:
> > https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf
> >
> > In my reading the Spider network is a type of Pierce network.
> >
> > However, the network that you remember is indeed most likely different from Spider:
> > - it was coax based, whereas the Spider line was a twisted pair
> > - there was more than one, whereas Spider only ever had one (operational) loop
> >
> > Condon and Weller are acknowledged in the report about Spider as having done
> > many of its hardware details. The report discusses learnings from the project
> > and having to tune repeaters is not among them (but another operational issue
> > with its 'line access modules’ is discussed).
> >
> > All in all, maybe these coax loops were pre-cursors to the Spider network,
> > without a switch on the loop (“C” nodes in the Pierce paper). It makes sense
> > to first try out the electrical and line data protocol before starting work
> > on higher level functions.
> >
> > I have no idea what a GLANCE G is...
>
> Again, very fuzzy memory here but there are a few folks on the list who might
> remember more like Heinz.  As I said earlier, I recall Sandy being in our group
> so our network may have been the first try.  I don't know who designed it.
>
> The GLANCE G was an experimental graphics terminal developed in our group.  I
> think that John Camlet did a bunch of the hardware design as I have a strong
> memory of a long afternoon with him after having weird squiggles show up in
> short vectors which turned out to be a microcode bug.  The thing had 4K
> resolution in at least one axis, it may have been a square screen.  It used
> 1K DRAMs and was built around a 74S181 bit slice machine.  A lot of interesting
> stuff was done on it;  I mentioned Dick Hause's Display Terminal Editor in an
> earlier post.  I also remember a really nice graphical demo of how the phone
> network routed around outages which of course no longer works due to lack of
> redundancy.
>
> Oh, yeah, the real use for these comes back to me :-)  A number of the folks
> in the group including Carl Christensen (who was one of the two people who
> interviewed Ken for his job at the labs) had purchased property up in
> Vermont for ski cabins.  These lots had ancient surveys, the old "from the big
> tree near the large rock" sort of property descriptions.  So the main use of
> the Glance G's for a while was to draw out the surveys and figure out what to
> do about closure errors.  If you don't know about it, and this is the only
> reason why I do, a closure error is when you follow the property boundary
> described by the survey and the end isn't at the beginning.
>
> Anyway, these were very cool machines for their time.  I don't recall any other
> graphical devices at the time except for glass tty terminals, Tektronix storage
> tubes, and the GRIN-2 on the PDP-15 that we used for space war as per earlier
> posts.
>
> Dave Hagelbarger designed the keyboard and to this date it's still one of the
> best keyboards that I ever used as far as feel goes.  It had plastic cups under
> the keys that gave resistance and then accelerated after a certain point so you
> pushed on a key and then it would shoot the rest of the way.  And there was a
> solenoid on the bottom of the circuit board so there was a little click that
> you felt in your fingers.  Great feedback.
>
> There were some extra parts left over from building these.  I remember that Joe
> Condon had the glass shop do some work on an extra or dead CRT, and one of the
> terminals in his office was actually a fish tank.  When you turned it on a light
> would come on behind the tube and you could see the fish swimming around in it.
> Maybe Joe deserves credit for the original fish screen saver.
>
> Oh yeah, another thing that I remember being tried was that someone had built an
> array of LEDs and photodiodes surrounding the screen that could be used as an
> input device.  It was low res but you could point at things with your fingers.
>
> One of the projects that I did was to write software for nicely plotting graphs
> on these.  Was used a bunch by Jim Kaiser and crowd for their digital filter
> work.  I remember a really nice graph that Jim did that showed just how carefully
> the touch tone frequencies were chosen to have no harmonics in common.
>
> This isn't really UNIX stuff but I suppose that it passes for prehistory.  Again,
> I seem to recall that one of these was up in the UNIX lab but have no memory of
> what it was used for.  If I had to guess, it would be chess.
>
> Oh yeah, I think that you can see the GLANCE G instruction set if you have a
> first edition copy of Newman and Sproul.  I remember getting a copy of that book
> and having a weird sense of deja vu during their discussion of vector graphics.
> Then I realized that it was because it was the instruction set that was burned
> into my memory.
>
> Jon

From rp at servium.ch  Fri Jan 24 18:42:10 2020
From: rp at servium.ch (Rico Pajarola)
Date: Fri, 24 Jan 2020 00:42:10 -0800
Subject: [TUHS] More oldies but goodies available if anyone wants them
In-Reply-To: <202001232348.00NNmUmc3853455@darkstar.fourwinds.com>
References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com>
 <CAK7dMtDZa68sb4csvWV7KJq19i_jbiv4M0JRofZE9PR2pxDhPw@mail.gmail.com>
 <202001232348.00NNmUmc3853455@darkstar.fourwinds.com>
Message-ID: <CACwAiQn_oO33txusmQuRvP5iwovV4TKbpzZ0DGzhMNw-=P2b5g@mail.gmail.com>

On Thu, Jan 23, 2020 at 3:49 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Kevin Bowling writes:
> >
> > What are the mods?  I have a stack of 10s and 20s but will take it for
> safe
> > keeping if nobody else will.
> >
> > On Thu, Jan 23, 2020 at 12:01 PM Jon Steinhart <jon at fourwinds.com>
> wrote:
> >
> > > Kind of scary what's in my basement.  For those of you building UNIX
> > > workstations in the early days, I have a big fat notebook full of
> > > Weitek floating point chip specs, many of which are marked as
> preliminary.
> > > Also a set of CORBA specs.  Again, low-hanging fruit that's getting
> > > recycled unless anyone has a use for them.
> > >
> > > In the not completely sure that I want to part with them yet for some
> > > strange reason, I have a set of SunOS manuals.
> > >
> > > Also, if anyone collects old hardware I have a SparcStation 20 with a
> > > slightly modified SunOS sitting around and an Ultra 60 Solaris box.
> > >
> > > Jon
>
> The Sparc 20 includes the double-buffered graphics board.  Thanks to an
> unnamed employee, I got the code to do a kernel mod so that I can run
> SunView on the front buffer and X on the rear buffer and switch between
> the two by running the mouse off of the side of the screen.
>
that sounds really cool, is there any way you could extract that mod from
the machine?

(I don't really need another Sparc 20, but the mod interests me).


>
> I probably have installation media around for both of these systems.
> Which means that I also have a QIC-150 drive to go with 'em.  And a
> stack of QIC-150 and QIC-50 tapes that I've been wanting to get rid
> of but haven't managed to procure a good bulk eraser yet.  Also may
> have Sun DDS-2, DDS-3, and DDS-4 DAT drives; will have to look.  I
> also have one of the Archive Python DAT drives with the special SGI
> firmware that lets the DDS layer be turned off so that you can read
> and write audio DATs; that's currently loaned out and I'd need to
> check the status of it.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200124/5ed38f3f/attachment.html>

From clemc at ccc.com  Sat Jan 25 00:49:54 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 24 Jan 2020 09:49:54 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 <87h80m6u9q.fsf@vuxu.org>
 <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>
Message-ID: <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>

On Thu, Jan 23, 2020 at 9:45 PM Warner Losh <imp at bsdimp.com> wrote:

> MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while
> pwb 1.2  is 1978 or 1979.
>
I can not say, I have any knowledge so I would trust Rob's sources, but ...
I also what I would have thought MERT predates PWB.  Heinz, are you able to
illuminate any of these details?



> MERT was V4 while releases of PWB were V6 based.
>
I can verify and agree with the later of PWB 1.x being 6th edition, but the
MERT tidbit is interesting/thought-provoking. I frankly would have
expected the MERT folks to have started with something closer to 5th and
then tracked any significant differences as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200124/9f18cab8/attachment.html>

From jon at fourwinds.com  Sat Jan 25 02:34:41 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 24 Jan 2020 08:34:41 -0800
Subject: [TUHS] Unix quix
In-Reply-To: <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 <87h80m6u9q.fsf@vuxu.org>
 <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>
 <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>
Message-ID: <202001241634.00OGYfHr4021769@darkstar.fourwinds.com>

Clem Cole writes:
>
> On Thu, Jan 23, 2020 at 9:45 PM Warner Losh <imp at bsdimp.com> wrote:
>
> > MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while
> > pwb 1.2  is 1978 or 1979.
> >
> I can not say, I have any knowledge so I would trust Rob's sources, but ...
> I also what I would have thought MERT predates PWB.  Heinz, are you able to
> illuminate any of these details?
>
> > MERT was V4 while releases of PWB were V6 based.
> >
> I can verify and agree with the later of PWB 1.x being 6th edition, but the
> MERT tidbit is interesting/thought-provoking. I frankly would have
> expected the MERT folks to have started with something closer to 5th and
> then tracked any significant differences as possible.

My very fuzzy memory would put MERT at v4 or v5.  I think that the department
had an 11/40 running v3 back when it was in building 2.  I recall a much bigger
machine, I think an 11/70, after the move to building 6.  I think that Heinz's
office was across the hall from the room that had the 516 and the SS1, the 11/70
was across the hall and left a couple of doors from Heinz's office.  I'm pretty
sure that I used that machine to do the docs for the IC test system since the
department that I was in then didn't have a UNIX system.  I do have a v6 manual
from back then so that's where things were at the end of my time there.  Anyway,
from a timing thing I'm guessing that MERT was v4 or v5.

Jon

From imp at bsdimp.com  Sat Jan 25 02:40:40 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 24 Jan 2020 09:40:40 -0700
Subject: [TUHS] Unix quix
In-Reply-To: <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 <87h80m6u9q.fsf@vuxu.org>
 <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>
 <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>
Message-ID: <CANCZdfpjbosHkfDM0+KVn+_NdB4sEBgy8606OHG9FkfsCCLFSw@mail.gmail.com>

On Fri, Jan 24, 2020 at 7:50 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Thu, Jan 23, 2020 at 9:45 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while
>> pwb 1.2  is 1978 or 1979.
>>
> I can not say, I have any knowledge so I would trust Rob's sources, but
> ... I also what I would have thought MERT predates PWB.  Heinz, are you
> able to illuminate any of these details?
>

The group that created PWB may well have started before the MERT group, at
least from what I can find documented in early papers... However, the first
release we have of PWB is labeled 1.0 and it is 1977. The ACM MERT papers
are from 1975.


> MERT was V4 while releases of PWB were V6 based.
>>
> I can verify and agree with the later of PWB 1.x being 6th edition, but
> the MERT tidbit is interesting/thought-provoking. I frankly would have
> expected the MERT folks to have started with something closer to 5th and
> then tracked any significant differences as possible.
>

I believe that they did track releases. And this may be a case of rolling
release. I'm told, but can't find a good reference for it, that editions
were just a manual thing and that there wasn't a 'master tape' made of each
edition until late in the process (like maybe as late as the 7th edition
since I see references to different versions of the 6th edition, though
that may be nothing more than the '50 patches' tape). This makes some of
the traffic difficult. The Network Unix folks started with 5th editionish
release, but had frequent updates during their work as the 6th edition was
being prepped and then settled on the 6th edition to release their work
(since the tapes we have of it are of a lightly-modified 6th edition (at
least relative to dennis_v6). I'm also unsure of when the first "release"
of MERT was, which may be critical to answering that question...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200124/adca62ea/attachment.html>

From paul.winalski at gmail.com  Sat Jan 25 04:57:05 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 24 Jan 2020 13:57:05 -0500
Subject: [TUHS] Unix quix
In-Reply-To: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
Message-ID: <CABH=_VQPqv90fywr3Dj-CDyyA9QjnCg0pASHeS_HO_6bouH+XQ@mail.gmail.com>

On 1/22/20, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> Pretty interesting machine, if you study its instruction set, BTW; with no
> stack, subroutines are 'interesting'.

The IBM S/360/370 operating systems such as DOS/360 and DOS/VS didn't
use a stack, either, unless you were doing recursion.  When we got our
VAX, I was puzzled as to why they would throw away an entire register
just to point at a stack.

-Paul W.

From beebe at math.utah.edu  Sat Jan 25 05:38:32 2020
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 24 Jan 2020 12:38:32 -0700
Subject: [TUHS] Unix quix
Message-ID: <CMM.0.95.0.1579894712.beebe@gamma.math.utah.edu>

On 1/22/20, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> Pretty interesting machine, if you study its instruction set, BTW; with no
> stack, subroutines are 'interesting'.

Another machine family like that was the CDC 6x00 and 7x00 machines of
the late 1960s and early 1970s.  

I worked on a CDC 6400 for a few years.  A call was done by storing
the return address in the first word of the called routine, and
jumping to its second word.  The return was done with an indirect jump
through the first word.

That was fine for Fortran, which at the time had no concept of
recursion.  However, Urs Ammann implemented a compiler for Niklaus
Wirth's Pascal language on a CDC 6400 (or 6600) in Zurich, and he had
to simulate a stack.  See

	On Code Generation in a PASCAL Compiler
	Software --- Practice and Experience 7(3) 391--423 May/June 1977
	https://doi.org/10.1002/spe.4380070311

I have read that article in the past, but don't have download access
from our academic library to get a copy to refresh my memory.

-------------------------------------------------------------------------------
- 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 bakul at bitblocks.com  Sat Jan 25 06:05:35 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 24 Jan 2020 12:05:35 -0800
Subject: [TUHS] Unix quix
In-Reply-To: <CMM.0.95.0.1579894712.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1579894712.beebe@gamma.math.utah.edu>
Message-ID: <C8C3AF26-C599-4B4C-AB4B-49E1EDC8CF28@bitblocks.com>


On Jan 24, 2020, at 11:46 AM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> 
> That was fine for Fortran, which at the time had no concept of
> recursion.  However, Urs Ammann implemented a compiler for Niklaus
> Wirth's Pascal language on a CDC 6400 (or 6600) in Zurich, and he had
> to simulate a stack.  See
> 
>    On Code Generation in a PASCAL Compiler
>    Software --- Practice and Experience 7(3) 391--423 May/June 1977
>    https://doi.org/10.1002/spe.4380070311
> 
> I have read that article in the past, but don't have download access
> from our academic library to get a copy to refresh my memory.

https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68668/eth-3056-01.pdf?sequence=1&isAllowed=y
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200124/19a3ed2b/attachment.html>

From lehmann at ans-netz.de  Sat Jan 25 11:46:51 2020
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 25 Jan 2020 02:46:51 +0100
Subject: [TUHS] Dhrystone Benchmark (was: Unix on Zilog Z8000?)
In-Reply-To: <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>
 <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net>
Message-ID: <20200125024651.Horde.9JSIrRz3jdgpqkeDXz78FY_@avocado.salatschuessel.net>

By the way.... I found some dhry-c output I ran on WEGA

#83 cc -O -DHZ=60  -DREG=register -c dhry_1.c
#84 cc -O -DREG=register -c dhry_2.c
#85 cc -o dhry dhry_1.o dhry_2.o
#86 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
/per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
Dhrystone Benchmark, Version 2.1 (Language: C)
Microseconds for one run through Dhrystone: 1652.8
Dhrystones per Second:                       605.0
Dhrystone MIPS:                                0.3443
#87 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
/per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
Dhrystone Benchmark, Version 2.1 (Language: C)
Microseconds for one run through Dhrystone: 1652.2
Dhrystones per Second:                       605.2
Dhrystone MIPS:                                0.3445
Oliver Lehmann <lehmann at ans-netz.de> wrote:

> Hi,
>
> let me just reply to this single message :)
>
>> Details with Docs, Schematics and Sourcecode at: http://www.pofo.de/P8000/
>
> Wow - my page gets quoted on TUHS-ML :)
>
> The 16 Bit board runs WEGA (renamed copy of ZEUS). The board is a  
> copy of the 16 Bit Board from Zilogs System 8000. Some parts where  
> added because the subsystem design is different (serial ports,  
> harddisk, floppy disks instead of tape,...).
> WEGA only runs on a Z8001 (no Z8002) and the OS was able to execute  
> (and compile) segmented (full memory access) and unsegmented (only  
> 64K access iirc) binaries.
>
> The OS of the P8000 is as I said a copy of ZEUS. The name ZEUS was  
> "replaced" with WEGA in the executables (hex editor).
> Some parts of the system where reverse engineered and altered. I had  
> contact to a kernel developer after the system collapsed who told me  
> some stories ;)
> While the userland ist nearly a 100% copy of ZEUS, main parts of the  
> kernel (dev) where changed to handle the different system layout.
>
> I own a complete and running P8000 as well as a S8000 which could  
> run if I would have
> a) a copy of the Zilog ZEUS Installation Tape (+ system diagnostic tape)
> b) a working tape drive (non-standard tape not compatible to something else)
> c) a SA1100 harddisk, or c) a SMD Controller + SMD disks.
> d) time
>
> After I designed, built and programmed a harddisk subsystem emulator  
> for the P8000, I also planed to emulate the whole disk subsystem of  
> the S8000. Additionally I planned to use a partial backup of a ZEUS  
> installation I have + WEGA to generate a running ZEUS-a-like but  
> then I became a father and time was gone ;)
>
> So right now my S8000 sits in my basement togehter with some circuit  
> ideas and logical analysation results and waits for more time ;)
>
> Some links...
>
> Kernel Sources of WEGA I could get my hands on, or are disassembled  
> and "make-it-C-code-again"ed by me
> https://github.com/OlliL/P8000/tree/master/WEGA/src/uts
> Beside that there is also other stuff like C compiler sources and so  
> on - just navigate around :)
>
> Zilog S8000 pics
> http://pics.pofo.de/index.php?/category/129
>
> EAW P8000 pics
> http://pics.pofo.de/index.php?/category/21
>
> Some S8000 sources (mostly firmware, rebuilt with having access to  
> the P8000 firmware)
> https://github.com/OlliL/S8000
>
> Any questions are welcome....
>
> Best regards,
> Oliver



From lehmann at ans-netz.de  Sat Jan 25 11:49:57 2020
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 25 Jan 2020 02:49:57 +0100
Subject: [TUHS] Dhrystone Benchmark (was: Unix on Zilog Z8000?)
In-Reply-To: <20200125024651.Horde.9JSIrRz3jdgpqkeDXz78FY_@avocado.salatschuessel.net>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>
 <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net>
 <20200125024651.Horde.9JSIrRz3jdgpqkeDXz78FY_@avocado.salatschuessel.net>
Message-ID: <20200125024957.Horde.cyIJwuHu99ty3x4GDh2veYy@avocado.salatschuessel.net>

Sorry... I hit send to early by mistake... I wanted to include a  
comparison chart...

CPU   MIPS   MIPS
     System                      OS          CPU     (MHz)  V1.1   V2.1  REF
### ---------------------- ------------ ----------- ----- ------ ------ ---
...
316 IBM PC/AT              PCDOS 3.0    80286         6.0    0.39 -----   0
317 ATT PC6300             MSDOS 2.11   8086          8.0    0.39 -----   0
318 Onyx C8002             IS/1 1.1(V7) Z8000         4.0    0.29 -----   0
319 PDP 11/34              UNIX V7M     ----------- -----    0.25 -----   0
...

So WEGA at P8000 is between 317 and 318 - and 318 is the the Onyx  
mentioned as well.... but what is "IS/1 1.1"?

Best Regards,
Oliver

Oliver Lehmann <lehmann at ans-netz.de> wrote:

> By the way.... I found some dhry-c output I ran on WEGA
>
> #83 cc -O -DHZ=60  -DREG=register -c dhry_1.c
> #84 cc -O -DREG=register -c dhry_2.c
> #85 cc -o dhry dhry_1.o dhry_2.o
> #86 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
> /per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
> Dhrystone Benchmark, Version 2.1 (Language: C)
> Microseconds for one run through Dhrystone: 1652.8
> Dhrystones per Second:                       605.0
> Dhrystone MIPS:                                0.3443
> #87 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
> /per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
> Dhrystone Benchmark, Version 2.1 (Language: C)
> Microseconds for one run through Dhrystone: 1652.2
> Dhrystones per Second:                       605.2
> Dhrystone MIPS:                                0.3445

From imp at bsdimp.com  Sat Jan 25 12:29:22 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 24 Jan 2020 19:29:22 -0700
Subject: [TUHS] Dhrystone Benchmark (was: Unix on Zilog Z8000?)
In-Reply-To: <20200125024957.Horde.cyIJwuHu99ty3x4GDh2veYy@avocado.salatschuessel.net>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
 <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de>
 <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net>
 <20200125024651.Horde.9JSIrRz3jdgpqkeDXz78FY_@avocado.salatschuessel.net>
 <20200125024957.Horde.cyIJwuHu99ty3x4GDh2veYy@avocado.salatschuessel.net>
Message-ID: <CANCZdfooJLrna7-5cNZRATu-PX6+NsWFitrbJMyBpMrG6c4R_Q@mail.gmail.com>

On Fri, Jan 24, 2020, 6:50 PM Oliver Lehmann <lehmann at ans-netz.de> wrote:

> Sorry... I hit send to early by mistake... I wanted to include a
> comparison chart...
>
> CPU   MIPS   MIPS
>      System                      OS          CPU     (MHz)  V1.1   V2.1
> REF
> ### ---------------------- ------------ ----------- ----- ------ ------ ---
> ...
> 316 IBM PC/AT              PCDOS 3.0    80286         6.0    0.39 -----   0
> 317 ATT PC6300             MSDOS 2.11   8086          8.0    0.39 -----   0
> 318 Onyx C8002             IS/1 1.1(V7) Z8000         4.0    0.29 -----   0
> 319 PDP 11/34              UNIX V7M     ----------- -----    0.25 -----   0
> ...
>
> So WEGA at P8000 is between 317 and 318 - and 318 is the the Onyx
> mentioned as well.... but what is "IS/1 1.1"?
>

This would be the Interactive Systems V6 port, I think. At least that is
what wikipedia says:

"ISC's 1977 offering, IS/1, was a Version 6 Unix
<https://en.m.wikipedia.org/wiki/Version_6_Unix> variant enhanced for
office automation running on the PDP-11
<https://en.m.wikipedia.org/wiki/PDP-11>."

But there is a V7 after it, so maybe it's a Version 7 port instead...

Warner

Best Regards,
> Oliver
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> > By the way.... I found some dhry-c output I ran on WEGA
> >
> > #83 cc -O -DHZ=60  -DREG=register -c dhry_1.c
> > #84 cc -O -DREG=register -c dhry_2.c
> > #85 cc -o dhry dhry_1.o dhry_2.o
> > #86 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
> > /per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
> > Dhrystone Benchmark, Version 2.1 (Language: C)
> > Microseconds for one run through Dhrystone: 1652.8
> > Dhrystones per Second:                       605.0
> > Dhrystone MIPS:                                0.3443
> > #87 echo 30000 | ./dhry | awk '/Lang/ || /^Micro/ {print} \
> > /per Sec/ {mips=$4/1757;print;printf("Dhrystone MIPS:%38.04f\n",mips)}'
> > Dhrystone Benchmark, Version 2.1 (Language: C)
> > Microseconds for one run through Dhrystone: 1652.2
> > Dhrystones per Second:                       605.2
> > Dhrystone MIPS:                                0.3445
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200124/100079e6/attachment.html>

From g.branden.robinson at gmail.com  Sun Jan 26 01:00:13 2020
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Sun, 26 Jan 2020 02:00:13 +1100
Subject: [TUHS] [TUHS/groff] Provenance of .SB macro in man pages
Message-ID: <20200125150010.dwqpgs5upkmuoleu@localhost.localdomain>

Hi folks,

I've been adding a history subsection to the groff_man(7) page for the
next groff release (date TBD) and thanks to the TUHS archives I've been
able to answer almost all the questions I had about the origins of the
man(7) language's macros and registers (number and string).

I'm inlining my findings in rendered and source form below, but there's
one feature I haven't been able to sort out--where did .SB (small bold)
come from?  The oldest groff release I can find online is 1.02 (June
1991), and .SB is already there, but I can't find it anywhere else.  Is
it a GNUism?  Did it perhaps appear in a proprietary Unix first?

I'm aware of Kristaps Dzonsons's history of Unix man pages[1], but
unfortunately for me that is more of a history of the *roff system(s),
and does not have much detail about the evolution of the man(7) macro
language itself.

If you can shed any light on this, I'd appreciate it!

   History
       Version 7 Unix (1979) supported all of the macros described in this
       page not listed as extensions, except .P, .SB, and the deprecated .AT
       and .UC.  The only string registers defined were R and S; no number
       registers were documented.  .UC appeared in 3BSD (1980) and .P in AT&T
       Unix System III (1980).  4BSD (1980) added lq and rq string registers.
       4.3BSD (1986) added .AT and AT&T's .P.  DEC Ultrix 11 (1988) added the
       Tm string register.

.\" ====================================================================
.SS History
.\" ====================================================================
.
Version\~7 Unix (1979) supported all of the macros described in this
page not listed as extensions,
except
.BR .P ,
.BR .SB ,
.\" .SS was implemented in tmac.an but not documented in man(7).
and the deprecated
.BR .AT
and
.BR .UC .
.
The only string registers defined were
.B R
and
.BR S ;
no number registers were documented.
.
.B .UC
appeared in 3BSD (1980) and
.B .P
in AT&T Unix System\~III (1980).
.
4BSD (1980) added
.\" undocumented .VS and .VE macros to mark regions with 12-point box
.\" rules (\[br]) as margin characters, as well as...
.B lq
and
.B rq
string registers.
.
4.3BSD (1986) added
.\" undocumented .DS and .DE macros for "displays", which are .RS/.RE
.\" wrappers with filling disabled and vertical space of 1v before and
.\" .5v after, as well as...
.B .AT
and
AT&T's
.BR .P .
.
DEC Ultrix\~11 (1988) added the
.B Tm
string register.
.
.\" TODO: Determine provenance of .SB.

Regards,
Branden

[1] https://manpages.bsd.lv/history.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200126/7fda4c37/attachment.sig>

From reed at reedmedia.net  Sun Jan 26 05:13:44 2020
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Sat, 25 Jan 2020 13:13:44 -0600 (CST)
Subject: [TUHS] [TUHS/groff] Provenance of .SB macro in man pages
In-Reply-To: <20200125150010.dwqpgs5upkmuoleu@localhost.localdomain>
References: <20200125150010.dwqpgs5upkmuoleu@localhost.localdomain>
Message-ID: <alpine.NEB.2.21.2001251254310.50@t1.m.reedmedia.net>

On Sun, 26 Jan 2020, G. Branden Robinson wrote:

> I'm inlining my findings in rendered and source form below, but there's
> one feature I haven't been able to sort out--where did .SB (small bold)
> come from?  The oldest groff release I can find online is 1.02 (June
> 1991), and .SB is already there, but I can't find it anywhere else.  Is
> it a GNUism?  Did it perhaps appear in a proprietary Unix first?

I see .SB used in the 
C Manual - Language
Edited by R.P.A. Collinson
Document No: DOC/UNIX.K3.10/1
and UKC IO Library docs also from Collinson at Univ. of Kent.
as found in the usenix-78-uk1 tape.
Maybe that is uk1.tar at 
https://www.tuhs.org/Archive/Applications/Spencer_Tapes/

I also see a SB Stymie Bold font in v7 troff.

From g.branden.robinson at gmail.com  Sun Jan 26 05:36:58 2020
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Sun, 26 Jan 2020 06:36:58 +1100
Subject: [TUHS] [TUHS/groff] Provenance of .SB macro in man pages
In-Reply-To: <alpine.NEB.2.21.2001251254310.50@t1.m.reedmedia.net>
References: <20200125150010.dwqpgs5upkmuoleu@localhost.localdomain>
 <alpine.NEB.2.21.2001251254310.50@t1.m.reedmedia.net>
Message-ID: <20200125193655.g6mwesmitjkxjebf@localhost.localdomain>

Thanks for the quick follow-up, Reed!

At 2020-01-25T13:13:44-0600, reed at reedmedia.net wrote:
> On Sun, 26 Jan 2020, G. Branden Robinson wrote:
> 
> > I'm inlining my findings in rendered and source form below, but
> > there's one feature I haven't been able to sort out--where did .SB
> > (small bold) come from?  The oldest groff release I can find online
> > is 1.02 (June 1991), and .SB is already there, but I can't find it
> > anywhere else.  Is it a GNUism?  Did it perhaps appear in a
> > proprietary Unix first?
> 
> I see .SB used in the 
> C Manual - Language
> Edited by R.P.A. Collinson
> Document No: DOC/UNIX.K3.10/1
> and UKC IO Library docs also from Collinson at Univ. of Kent.
> as found in the usenix-78-uk1 tape.
> Maybe that is uk1.tar at 
> https://www.tuhs.org/Archive/Applications/Spencer_Tapes/

There's definitely an .SB macro used in that and a few other *roff
documents in the uk1 archive, all of which have filenames ending in
".n".

They're not laid out like man pages, there's no tmac.n file in the
archive, and the macros used don't seem to come from Matt Bishop's News
macro package, also named tmac.n.

Given the absence of the macro package source it's hard to say what the
semantics of these documents' ".SB" might be.  They appear to be used as
section headings, but C function prototypes are used with them as well.
But since a C library is being documented alongside the language, maybe
that's not too surprising.

> I also see a SB Stymie Bold font in v7 troff.

That's a different namespace.  Something it took me an embarrassingly
long to figure out was the ridiculously terse naming convention of *roff
font description files.

The "foundry" name gets the first letter, and after that you get "R" for
roman, "B" for bold, "I" for italic, "BI" for bold italic, and "S" for a
"special" font (symbols for math typesetting or dingbats).  Bold and
italics didn't apply to special fonts.

So, if your system has Helvetica you'll have files called:
	HR
	HB
	HI
	HBI

If my guess is right, alongside Stymie Bold you'll see SR, SI, and
possibly SBI as well.

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200126/c9006492/attachment.sig>

From heinz at osta.com  Sun Jan 26 10:03:02 2020
From: heinz at osta.com (Heinz Lycklama)
Date: Sat, 25 Jan 2020 16:03:02 -0800
Subject: [TUHS] Unix quix
In-Reply-To: <202001241634.00OGYfHr4021769@darkstar.fourwinds.com>
References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxvtnO4ELg41L-1heFsODOcM4jRscuqpZuJ6eKdv7eQpg@mail.gmail.com>
 <87h80m6u9q.fsf@vuxu.org>
 <CANCZdfo_fKeKttr2_hU+=6FNcKU0E9RwsG6trWt2666T5MstLA@mail.gmail.com>
 <CAC20D2Mgm+eMPXi-3b=kLaspohxOr5ivBU63sgt42_0PAF5LOg@mail.gmail.com>
 <202001241634.00OGYfHr4021769@darkstar.fourwinds.com>
Message-ID: <c3e6b183-eaec-4d46-f54f-f968f6a8afae@osta.com>

Jon, your dates are correct on MERT. I think UNIX v6 was introduced
in 1975. So we may have used v4 in 1973 and then upgraded to V6
later on in preparation to the general release of MERT 0. Clem, you may
be able to confirm this from the MERT 0 manual you borrowed from me.

Thanks.

Heinz

On 1/24/2020 8:34 AM, Jon Steinhart wrote:
> Clem Cole writes:
>> On Thu, Jan 23, 2020 at 9:45 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>> MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while
>>> pwb 1.2  is 1978 or 1979.
>>>
>> I can not say, I have any knowledge so I would trust Rob's sources, but ...
>> I also what I would have thought MERT predates PWB.  Heinz, are you able to
>> illuminate any of these details?
>>
>>> MERT was V4 while releases of PWB were V6 based.
>>>
>> I can verify and agree with the later of PWB 1.x being 6th edition, but the
>> MERT tidbit is interesting/thought-provoking. I frankly would have
>> expected the MERT folks to have started with something closer to 5th and
>> then tracked any significant differences as possible.
> My very fuzzy memory would put MERT at v4 or v5.  I think that the department
> had an 11/40 running v3 back when it was in building 2.  I recall a much bigger
> machine, I think an 11/70, after the move to building 6.  I think that Heinz's
> office was across the hall from the room that had the 516 and the SS1, the 11/70
> was across the hall and left a couple of doors from Heinz's office.  I'm pretty
> sure that I used that machine to do the docs for the IC test system since the
> department that I was in then didn't have a UNIX system.  I do have a v6 manual
> from back then so that's where things were at the end of my time there.  Anyway,
> from a timing thing I'm guessing that MERT was v4 or v5.
>
> Jon


From heinz at osta.com  Sun Jan 26 11:01:06 2020
From: heinz at osta.com (Heinz Lycklama)
Date: Sat, 25 Jan 2020 17:01:06 -0800
Subject: [TUHS] Spider
In-Reply-To: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com>
References: <EB9601C1-EE17-4E43-B69F-C9802A506597@planet.nl>
 <202001240237.00O2bOEG3883117@darkstar.fourwinds.com>
Message-ID: <cfc27e95-4af9-614f-6673-5048891882ef@osta.com>

Interesting history. Carl Christensen was also one of about 4 people
who interviewed me for a job at Bell Labs during a snowstorm in
Summit and Murray Hill in early 1969. I did use the early Glance terminals
during my programming days at Bell Labs, but had nothing to do
with their design. Carl and I taught a group of Explorer Scouts on
Monday evenings at Murray Hill in the early 1970's. Jon was one
of those scouts that we taught UNIX and its programming languages.
And we introduced them (including Jon) to  spelunking! in the summer.

Heinz

On 1/23/2020 6:37 PM, Jon Steinhart wrote:
> Paul Ruizendaal writes:
>>> Ugh. Memory lane has a lot of potholes. This was a really long time ago.
>> Many thanks for that post - really interesting!
>>
>> I had to look up "Pierce Network", and found it described in the Bell Journal:
>> https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf
>>
>> In my reading the Spider network is a type of Pierce network.
>>
>> However, the network that you remember is indeed most likely different from Spider:
>> - it was coax based, whereas the Spider line was a twisted pair
>> - there was more than one, whereas Spider only ever had one (operational) loop
>>
>> Condon and Weller are acknowledged in the report about Spider as having done
>> many of its hardware details. The report discusses learnings from the project
>> and having to tune repeaters is not among them (but another operational issue
>> with its 'line access modules’ is discussed).
>>
>> All in all, maybe these coax loops were pre-cursors to the Spider network,
>> without a switch on the loop (“C” nodes in the Pierce paper). It makes sense
>> to first try out the electrical and line data protocol before starting work
>> on higher level functions.
>>
>> I have no idea what a GLANCE G is...
> Again, very fuzzy memory here but there are a few folks on the list who might
> remember more like Heinz.  As I said earlier, I recall Sandy being in our group
> so our network may have been the first try.  I don't know who designed it.
>
> The GLANCE G was an experimental graphics terminal developed in our group.  I
> think that John Camlet did a bunch of the hardware design as I have a strong
> memory of a long afternoon with him after having weird squiggles show up in
> short vectors which turned out to be a microcode bug.  The thing had 4K
> resolution in at least one axis, it may have been a square screen.  It used
> 1K DRAMs and was built around a 74S181 bit slice machine.  A lot of interesting
> stuff was done on it;  I mentioned Dick Hause's Display Terminal Editor in an
> earlier post.  I also remember a really nice graphical demo of how the phone
> network routed around outages which of course no longer works due to lack of
> redundancy.
>
> Oh, yeah, the real use for these comes back to me :-)  A number of the folks
> in the group including Carl Christensen (who was one of the two people who
> interviewed Ken for his job at the labs) had purchased property up in
> Vermont for ski cabins.  These lots had ancient surveys, the old "from the big
> tree near the large rock" sort of property descriptions.  So the main use of
> the Glance G's for a while was to draw out the surveys and figure out what to
> do about closure errors.  If you don't know about it, and this is the only
> reason why I do, a closure error is when you follow the property boundary
> described by the survey and the end isn't at the beginning.
>
> Anyway, these were very cool machines for their time.  I don't recall any other
> graphical devices at the time except for glass tty terminals, Tektronix storage
> tubes, and the GRIN-2 on the PDP-15 that we used for space war as per earlier
> posts.
>
> Dave Hagelbarger designed the keyboard and to this date it's still one of the
> best keyboards that I ever used as far as feel goes.  It had plastic cups under
> the keys that gave resistance and then accelerated after a certain point so you
> pushed on a key and then it would shoot the rest of the way.  And there was a
> solenoid on the bottom of the circuit board so there was a little click that
> you felt in your fingers.  Great feedback.
>
> There were some extra parts left over from building these.  I remember that Joe
> Condon had the glass shop do some work on an extra or dead CRT, and one of the
> terminals in his office was actually a fish tank.  When you turned it on a light
> would come on behind the tube and you could see the fish swimming around in it.
> Maybe Joe deserves credit for the original fish screen saver.
>
> Oh yeah, another thing that I remember being tried was that someone had built an
> array of LEDs and photodiodes surrounding the screen that could be used as an
> input device.  It was low res but you could point at things with your fingers.
>
> One of the projects that I did was to write software for nicely plotting graphs
> on these.  Was used a bunch by Jim Kaiser and crowd for their digital filter
> work.  I remember a really nice graph that Jim did that showed just how carefully
> the touch tone frequencies were chosen to have no harmonics in common.
>
> This isn't really UNIX stuff but I suppose that it passes for prehistory.  Again,
> I seem to recall that one of these was up in the UNIX lab but have no memory of
> what it was used for.  If I had to guess, it would be chess.
>
> Oh yeah, I think that you can see the GLANCE G instruction set if you have a
> first edition copy of Newman and Sproul.  I remember getting a copy of that book
> and having a weird sense of deja vu during their discussion of vector graphics.
> Then I realized that it was because it was the instruction set that was burned
> into my memory.
>
> Jon


From pnr at planet.nl  Mon Jan 27 00:04:34 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 26 Jan 2020 15:04:34 +0100
Subject: [TUHS] More Spider
Message-ID: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>

I noted with much pleasure that the main bitsavers site is back up, and that at some point it has added a full set of scans of “Datamation”. The Feb 1975 issue contains an article from Dr. Fraser about Spider and the network setup in Murray Hill early in 1975:
http://bitsavers.org/pdf/datamation/197502.pdf

For ease of reference I have also temporarily put the relevant 4 pages of the issue here:
https://gitlab.com/pnru/spider/blob/master/spider.pdf

I find the graphic that shows how Spider connected machines and departments the most interesting, as it helps understand how the pro’s and con’s of Arpa Unix might have been perceived at that time.

The more I read, the more confused I become whether the “Pierce loop” was a precursor to “Spider” or a parallel effort.

The facts appear to be that John Pierce (https://en.wikipedia.org/wiki/John_R._Pierce) submitted his paper to BSTJ in December 1970, essentially describing a loop network with fixed size short datagrams, suggesting T1 frames. It is quite generic. In February 1971 W.J. Kropfl submits a paper that describes an implementation of the ideas in the Pierce paper with actual line protocols and a TIU. In October 1971 C.H. Coker describes in a 3rd paper how to interact with this TIU from a H516 programming perspective.

Several Spider papers mention that the project was started in 1969 and that the first Spider link was operational in 1972. The team appears to be entirely different: the h/w is credited to Condon and Weller, and the s/w to Frazer, Jensen and Plaugher. The Spider TIU is much more complex (200 TTL chips vs. 50 in the Kropfl TIU). The main reason for that - at first glance - appears to be that in the Spider network the TIU handled guaranteed in order delivery (i.e managed time outs and retransmissions), whereas in the Kropfl implementation this was left to the hosts.

It would seem logical that the latter was an evolution of the former, having been developed at the same site at the same time. A 1981 book seems to take that view as well: “Local Computer Network Technologies” by Carl Tropper includes the text "Spider Spider is an experimental data communications network which was built at the Bell Telephone Laboratories (Murray Hill, New Jersey) under the direction of A. G. Fraser. A detailed description of the network is given by Fraser [FRAS74]. This network was built with the notion of investigating Pierce's idea of ...” The chapter is titled “The Pierce loop and its derivatives”. This is a much as Google will give me - if somebody has the book please let me know.

On the other hand, the Spider papers do not mention the Kropfl network or Pierce’s paper at all. The graphic in Datamation appears to show two Kropfl loops as part of the network setup. Yet, this is described in the accompanying text as "4. Honeywell 5l6: Supports research into comunications techniques and systems. The machine has a serial loop I/O bus threaded through several labs at Murray Hill. Equipment under test is connected either directly to the bus or to a minicomputer which is then connected to the bus. Also avail- able are graphics display terminals and a device that can write read-only memory chips.” Maybe this is a different bus, but if it is the same as the Kropfl loop, to call it a “serial loop I/O bus” suggests it was a parallel effort unrelated to Spider.

Does anybody on the list recall whether Spider was a parallel effort or a continuation of the earlier work?






From ken at google.com  Mon Jan 27 02:56:12 2020
From: ken at google.com (Ken Thompson)
Date: Sun, 26 Jan 2020 08:56:12 -0800
Subject: [TUHS] More Spider
In-Reply-To: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
References: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
Message-ID: <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>

the pierce loop had its own protocol  on its own wire.
that meant it could only be local-area. the PL was
in operation on a packard-bell 516 when i arrived
at the labs in june '66. carl christensen was the
software person for both the loop and the 516.
i assume that pierce and condon were the hw
guys, but that was before my time.

spider was similar, but was designed to run on
the standard telephone T1 lines. thus, the whole
idea was more wide-area. the major draw back
of spider, and probably the reason it was never
really used, was that it couldnt make a connection.
all connections were pre-created at boot time.
a lesser reason was that the controller was a
tempo computer that no one loved. the system
software sucked. quickly it became unmaintained.
i think tempo went out of business. anyway, the
spider controller was the first and only tempo
computer that i saw or even heard of.


On Sun, Jan 26, 2020 at 6:05 AM Paul Ruizendaal <pnr at planet.nl> wrote:

> I noted with much pleasure that the main bitsavers site is back up, and
> that at some point it has added a full set of scans of “Datamation”. The
> Feb 1975 issue contains an article from Dr. Fraser about Spider and the
> network setup in Murray Hill early in 1975:
> http://bitsavers.org/pdf/datamation/197502.pdf
>
> For ease of reference I have also temporarily put the relevant 4 pages of
> the issue here:
> https://gitlab.com/pnru/spider/blob/master/spider.pdf
>
> I find the graphic that shows how Spider connected machines and
> departments the most interesting, as it helps understand how the pro’s and
> con’s of Arpa Unix might have been perceived at that time.
>
> The more I read, the more confused I become whether the “Pierce loop” was
> a precursor to “Spider” or a parallel effort.
>
> The facts appear to be that John Pierce (
> https://en.wikipedia.org/wiki/John_R._Pierce) submitted his paper to BSTJ
> in December 1970, essentially describing a loop network with fixed size
> short datagrams, suggesting T1 frames. It is quite generic. In February
> 1971 W.J. Kropfl submits a paper that describes an implementation of the
> ideas in the Pierce paper with actual line protocols and a TIU. In October
> 1971 C.H. Coker describes in a 3rd paper how to interact with this TIU from
> a H516 programming perspective.
>
> Several Spider papers mention that the project was started in 1969 and
> that the first Spider link was operational in 1972. The team appears to be
> entirely different: the h/w is credited to Condon and Weller, and the s/w
> to Frazer, Jensen and Plaugher. The Spider TIU is much more complex (200
> TTL chips vs. 50 in the Kropfl TIU). The main reason for that - at first
> glance - appears to be that in the Spider network the TIU handled
> guaranteed in order delivery (i.e managed time outs and retransmissions),
> whereas in the Kropfl implementation this was left to the hosts.
>
> It would seem logical that the latter was an evolution of the former,
> having been developed at the same site at the same time. A 1981 book seems
> to take that view as well: “Local Computer Network Technologies” by Carl
> Tropper includes the text "Spider Spider is an experimental data
> communications network which was built at the Bell Telephone Laboratories
> (Murray Hill, New Jersey) under the direction of A. G. Fraser. A detailed
> description of the network is given by Fraser [FRAS74]. This network was
> built with the notion of investigating Pierce's idea of ...” The chapter is
> titled “The Pierce loop and its derivatives”. This is a much as Google will
> give me - if somebody has the book please let me know.
>
> On the other hand, the Spider papers do not mention the Kropfl network or
> Pierce’s paper at all. The graphic in Datamation appears to show two Kropfl
> loops as part of the network setup. Yet, this is described in the
> accompanying text as "4. Honeywell 5l6: Supports research into
> comunications techniques and systems. The machine has a serial loop I/O bus
> threaded through several labs at Murray Hill. Equipment under test is
> connected either directly to the bus or to a minicomputer which is then
> connected to the bus. Also avail- able are graphics display terminals and a
> device that can write read-only memory chips.” Maybe this is a different
> bus, but if it is the same as the Kropfl loop, to call it a “serial loop
> I/O bus” suggests it was a parallel effort unrelated to Spider.
>
> Does anybody on the list recall whether Spider was a parallel effort or a
> continuation of the earlier work?
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200126/ecc10b5d/attachment.html>

From lm at mcvoy.com  Mon Jan 27 02:58:21 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 26 Jan 2020 08:58:21 -0800
Subject: [TUHS] More Spider
In-Reply-To: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
References: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
Message-ID: <20200126165821.GS8287@mcvoy.com>

On Sun, Jan 26, 2020 at 03:04:34PM +0100, Paul Ruizendaal wrote:
> http://bitsavers.org/pdf/datamation/197502.pdf

That is fascinating, what a walk down memory lane!

From jnc at mercury.lcs.mit.edu  Mon Jan 27 03:46:46 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 26 Jan 2020 12:46:46 -0500 (EST)
Subject: [TUHS] More Spider
Message-ID: <20200126174646.9043218C0AA@mercury.lcs.mit.edu>

    > From: Paul Ruizendaal

    > a loop network with fixed size short datagrams

It might be worth mentioning that the Cambridge Ring (in the UK) used a very
similar idea: a head end circulated empty frames which stations could fill in.
I think it started slightly later, though. Material about it is available
online.

  Noel

From jon at fourwinds.com  Mon Jan 27 03:50:31 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 26 Jan 2020 09:50:31 -0800
Subject: [TUHS] More Spider
In-Reply-To: <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>
References: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
 <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>
Message-ID: <202001261750.00QHoVH4334704@darkstar.fourwinds.com>

Ken Thompson via TUHS writes:
>
> the pierce loop had its own protocol  on its own wire.
> that meant it could only be local-area. the PL was
> in operation on a packard-bell 516 when i arrived
> at the labs in june '66. carl christensen was the
> software person for both the loop and the 516.
> i assume that pierce and condon were the hw
> guys, but that was before my time.
>
> spider was similar, but was designed to run on
> the standard telephone T1 lines. thus, the whole
> idea was more wide-area. the major draw back
> of spider, and probably the reason it was never
> really used, was that it couldnt make a connection.
> all connections were pre-created at boot time.
> a lesser reason was that the controller was a
> tempo computer that no one loved. the system
> software sucked. quickly it became unmaintained.
> i think tempo went out of business. anyway, the
> spider controller was the first and only tempo
> computer that i saw or even heard of.

Oh wow, that jogs loose some more stray memory cells.  Found the Tempo
manual on-line which had a front panel picture.  There was one of these
sitting in a rack near the window in the 516 lab back when we were in
building 2.  Not sure if it ever made it to building 7, might have been
tossed.  This thing a telephone handset hanging off of it.

Nice to see the networked IC test system that I mentioned the other day
in the datamation article on page 52.  It was on the loop, not the spider,
when I worked on it.

Jon

From arnold at skeeve.com  Mon Jan 27 04:28:45 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 26 Jan 2020 11:28:45 -0700
Subject: [TUHS] Screen editors
In-Reply-To: <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
Message-ID: <202001261828.00QISjhn009552@freefriends.org>

"Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:

> Talking of editors...
>
> On ancient UNIX, my editor of choice was 's' from Software Tools, its
> main advantage being that it didn't require curses.

That editor was from "A Software Tools Sampler" by Webb Miller, not
"Software Tools" by Kernighan and Plauger.

I happened to pull out my copy of that book a week or so ago. It's truly
strange looking at pre-ANSI / pre-POSIX code.

I feel like that book did not have the same sort of eternally true value
as the two Software Tools books do.

Arnold

From athornton at gmail.com  Mon Jan 27 04:33:13 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sun, 26 Jan 2020 11:33:13 -0700
Subject: [TUHS] Screen editors
In-Reply-To: <202001261828.00QISjhn009552@freefriends.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
Message-ID: <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>



> On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote:
> 
> "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
> 
>> Talking of editors...
>> 
>> On ancient UNIX, my editor of choice was 's' from Software Tools, its
>> main advantage being that it didn't require curses.
> 
> That editor was from "A Software Tools Sampler" by Webb Miller, not
> "Software Tools" by Kernighan and Plauger.


Well, that would explain why I couldn’t find it.

Do you have softcopy of the editor source?  I’d really like a screen editor for v7….

Adam

From arnold at skeeve.com  Mon Jan 27 04:36:07 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 26 Jan 2020 11:36:07 -0700
Subject: [TUHS] Screen editors
In-Reply-To: <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
 <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>
Message-ID: <202001261836.00QIa77j009761@freefriends.org>

Adam Thornton <athornton at gmail.com> wrote:

>
>
> > On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote:
> > 
> > "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
> > 
> >> Talking of editors...
> >> 
> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its
> >> main advantage being that it didn't require curses.
> > 
> > That editor was from "A Software Tools Sampler" by Webb Miller, not
> > "Software Tools" by Kernighan and Plauger.
>
>
> Well, that would explain why I couldn’t find it.
>
> Do you have softcopy of the editor source?  I’d really like a screen editor for v7….
>
> Adam

I don't. Maybe Jose does ...

Arnold

From arnold at skeeve.com  Mon Jan 27 04:40:25 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 26 Jan 2020 11:40:25 -0700
Subject: [TUHS] Screen editors
In-Reply-To: <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
 <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>
Message-ID: <202001261840.00QIePiJ009848@freefriends.org>

Adam Thornton <athornton at gmail.com> wrote:

>
>
> > On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote:
> > 
> > "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
> > 
> >> Talking of editors...
> >> 
> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its
> >> main advantage being that it didn't require curses.
> > 
> > That editor was from "A Software Tools Sampler" by Webb Miller, not
> > "Software Tools" by Kernighan and Plauger.
>
>
> Well, that would explain why I couldn’t find it.
>
> Do you have softcopy of the editor source?  I’d really like a screen editor for v7….
>
> Adam

https://bio.psu.edu/directory/wcm2 is Webb Miller's home page, with
an email address. Maybe you can get the code directly from him...

Arnold

From athornton at gmail.com  Mon Jan 27 05:11:06 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sun, 26 Jan 2020 12:11:06 -0700
Subject: [TUHS] Screen editors
In-Reply-To: <202001261840.00QIePiJ009848@freefriends.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
 <017581D9-BBF4-48A7-8465-3428604B4D8C@gmail.com>
 <202001261840.00QIePiJ009848@freefriends.org>
Message-ID: <7B2BFE7D-272B-44CE-AD5F-6E88B8BC19B7@gmail.com>



> On Jan 26, 2020, at 11:40 AM, arnold at skeeve.com wrote:
> 
> Adam Thornton <athornton at gmail.com> wrote:
> 
>> 
>> 
>>> On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote:
>>> 
>>> "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
>>> 
>>>> Talking of editors...
>>>> 
>>>> On ancient UNIX, my editor of choice was 's' from Software Tools, its
>>>> main advantage being that it didn't require curses.
>>> 
>>> That editor was from "A Software Tools Sampler" by Webb Miller, not
>>> "Software Tools" by Kernighan and Plauger.
>> 
>> 
>> Well, that would explain why I couldn’t find it.
>> 
>> Do you have softcopy of the editor source?  I’d really like a screen editor for v7….
>> 
>> Adam
> 
> https://bio.psu.edu/directory/wcm2 is Webb Miller's home page, with
> an email address. Maybe you can get the code directly from him…


I’ll try that.  In the meantime I’ve added myself to the waitlist to borrow it from the Internet Archive.  I’m a little surprised that the University of Arizona library doesn’t have a copy and neither do any of the other libraries their search engine can find.  I’ll probably try to figure out how to Interlibrary Loan it, since that may well arrive faster than the IA version.

Adam


From nobozo at gmail.com  Mon Jan 27 05:40:49 2020
From: nobozo at gmail.com (Jon Forrest)
Date: Sun, 26 Jan 2020 11:40:49 -0800
Subject: [TUHS] Screen editors
In-Reply-To: <202001261828.00QISjhn009552@freefriends.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
Message-ID: <9995d9d4-470c-d00d-f212-4cc255536dbb@gmail.com>



On 1/26/2020 10:28 AM, arnold at skeeve.com wrote:

> That editor was from "A Software Tools Sampler" by Webb Miller, not
> "Software Tools" by Kernighan and Plauger.
> 
> I happened to pull out my copy of that book a week or so ago. It's truly
> strange looking at pre-ANSI / pre-POSIX code.

I took a class from Webb Miller at UC Santa Barbara in the late 1970s
or early 1980s. I don't remember him being much of a teacher, but then
I was a total jerk back then so I wasn't much of a student. It was
probably my fault.

Anyway, I have a copy of this book for sale. It's in excellent
condition. It wasn't sold with the software that's printed in
the book so you'll have to somehow get the software yourself.

Since used copies of this book start at $899.99 on Amazon, I think
that $50 plus shipping would be a fair price. (I'll only ship to the
US). If you're interested please contact me directly offlist.

Jon Forrest

P. S. If this book sells it will be the second book I've sold
due to mentions on TUHS.

From chet.ramey at case.edu  Mon Jan 27 06:08:19 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 26 Jan 2020 15:08:19 -0500
Subject: [TUHS] Screen editors
In-Reply-To: <202001261828.00QISjhn009552@freefriends.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <202001261828.00QISjhn009552@freefriends.org>
Message-ID: <a42f1b12-619f-293f-692d-c679c5f30b60@case.edu>

On 1/26/20 1:28 PM, arnold at skeeve.com wrote:
> "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
> 
>> Talking of editors...
>>
>> On ancient UNIX, my editor of choice was 's' from Software Tools, its
>> main advantage being that it didn't require curses.
> 
> That editor was from "A Software Tools Sampler" by Webb Miller, not
> "Software Tools" by Kernighan and Plauger.

Before Miller got heavily into genomics and molecular biology research,
he was doing work with row-replacement algorithms and optimal sequence
calculation and screen updating. I think s is the demonstration vehicle he
used for that research, which is probably why it didn't need or use curses.


-- 
``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 pnr at planet.nl  Mon Jan 27 06:32:09 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 26 Jan 2020 21:32:09 +0100
Subject: [TUHS] Screen editors
Message-ID: <6A1B2BB8-58FC-4BCF-9D8A-AA0E27B43EE5@planet.nl>

> > On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote: 
> > 
> > "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote: 
> > 
> >> Talking of editors... 
> >> 
> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its 
> >> main advantage being that it didn't require curses. 
> > 
> > That editor was from "A Software Tools Sampler" by Webb Miller, not 
> > "Software Tools" by Kernighan and Plauger. 
> Well, that would explain why I couldn’t find it. Do you have softcopy of the editor source? I’d really like a screen editor for v7…. Adam

So do I.

Editor source seems to be here:
https://github.com/udo-munk/s

If you are doing a build for V7, I’d be interested in hearing the results.

From doug at cs.dartmouth.edu  Mon Jan 27 07:22:03 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 26 Jan 2020 16:22:03 -0500
Subject: [TUHS] A Dennisism
Message-ID: <202001262122.00QLM3vu070742@tahoe.cs.Dartmouth.EDU>

The anecdote below came from Nils-Peter Nelson, who as a
manager in the computer center bought and installed the
Labs' biggest Unix machine, a Cray 2. He also originated
the string.h package.

Doug

Dennis told me he was going to a class reunion at Harvard.

Me: "I guess you're the most famous member of your class."
dmr: "No, the Unabomber is.

From pnr at planet.nl  Mon Jan 27 07:26:05 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 26 Jan 2020 22:26:05 +0100
Subject: [TUHS] More Spider
In-Reply-To: <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>
References: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
 <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>
Message-ID: <D6C5A8F0-2B63-43A4-97B6-6AAEAEA7E8AD@planet.nl>

On 26 Jan 2020, at 17:56, Ken Thompson <ken at google.com> wrote:

> the pierce loop had its own protocol  on its own wire.
> that meant it could only be local-area. the PL was
> in operation on a packard-bell 516 when i arrived
> at the labs in june '66. carl christensen was the
> software person for both the loop and the 516.
> i assume that pierce and condon were the hw
> guys, but that was before my time.

Ah, so the Pierce loop was operational several years before the papers were submitted to BSTJ. That explains a lot.

> spider was similar, but was designed to run on
> the standard telephone T1 lines. thus, the whole
> idea was more wide-area. the major draw back
> of spider, and probably the reason it was never
> really used, was that it couldnt make a connection.
> all connections were pre-created at boot time.

The Spider report has a section on the protocol for making/breaking connections dynamically, but this is not used in the surviving programs which hard code a destination (channel). I wondered about that when Noel first found the sources for ’nfs’. Maybe this connection protocol was planned but never implemented.

> a lesser reason was that the controller was a
> tempo computer that no one loved. the system
> software sucked. quickly it became unmaintained.
> i think tempo went out of business. anyway, the
> spider controller was the first and only tempo
> computer that i saw or even heard of.

The video that Sandy Fraser recorded has a segment about that at 25:30. Apparently, just before Christmas Ed David gave him $60K budget to buy a computer to build the Spider switch. The catch was that it had to be delivered before New Year. With the above sentiment in mind it was perhaps no surprise that Tempo had a unit sitting on the shelf that could be shipped in that time frame.

> On Sun, Jan 26, 2020 at 6:05 AM Paul Ruizendaal <pnr at planet.nl> wrote:
> I noted with much pleasure that the main bitsavers site is back up, and that at some point it has added a full set of scans of “Datamation”. The Feb 1975 issue contains an article from Dr. Fraser about Spider and the network setup in Murray Hill early in 1975:
> http://bitsavers.org/pdf/datamation/197502.pdf
> 
> For ease of reference I have also temporarily put the relevant 4 pages of the issue here:
> https://gitlab.com/pnru/spider/blob/master/spider.pdf
> 
> I find the graphic that shows how Spider connected machines and departments the most interesting, as it helps understand how the pro’s and con’s of Arpa Unix might have been perceived at that time.
> 
> The more I read, the more confused I become whether the “Pierce loop” was a precursor to “Spider” or a parallel effort.
> 
> The facts appear to be that John Pierce (https://en.wikipedia.org/wiki/John_R._Pierce) submitted his paper to BSTJ in December 1970, essentially describing a loop network with fixed size short datagrams, suggesting T1 frames. It is quite generic. In February 1971 W.J. Kropfl submits a paper that describes an implementation of the ideas in the Pierce paper with actual line protocols and a TIU. In October 1971 C.H. Coker describes in a 3rd paper how to interact with this TIU from a H516 programming perspective.
> 
> Several Spider papers mention that the project was started in 1969 and that the first Spider link was operational in 1972. The team appears to be entirely different: the h/w is credited to Condon and Weller, and the s/w to Frazer, Jensen and Plaugher. The Spider TIU is much more complex (200 TTL chips vs. 50 in the Kropfl TIU). The main reason for that - at first glance - appears to be that in the Spider network the TIU handled guaranteed in order delivery (i.e managed time outs and retransmissions), whereas in the Kropfl implementation this was left to the hosts.
> 
> It would seem logical that the latter was an evolution of the former, having been developed at the same site at the same time. A 1981 book seems to take that view as well: “Local Computer Network Technologies” by Carl Tropper includes the text "Spider Spider is an experimental data communications network which was built at the Bell Telephone Laboratories (Murray Hill, New Jersey) under the direction of A. G. Fraser. A detailed description of the network is given by Fraser [FRAS74]. This network was built with the notion of investigating Pierce's idea of ...” The chapter is titled “The Pierce loop and its derivatives”. This is a much as Google will give me - if somebody has the book please let me know.
> 
> On the other hand, the Spider papers do not mention the Kropfl network or Pierce’s paper at all. The graphic in Datamation appears to show two Kropfl loops as part of the network setup. Yet, this is described in the accompanying text as "4. Honeywell 5l6: Supports research into comunications techniques and systems. The machine has a serial loop I/O bus threaded through several labs at Murray Hill. Equipment under test is connected either directly to the bus or to a minicomputer which is then connected to the bus. Also avail- able are graphics display terminals and a device that can write read-only memory chips.” Maybe this is a different bus, but if it is the same as the Kropfl loop, to call it a “serial loop I/O bus” suggests it was a parallel effort unrelated to Spider.
> 
> Does anybody on the list recall whether Spider was a parallel effort or a continuation of the earlier work?
> 


From clemc at ccc.com  Mon Jan 27 07:49:59 2020
From: clemc at ccc.com (Clem Cole)
Date: Sun, 26 Jan 2020 16:49:59 -0500
Subject: [TUHS] A Dennisism
In-Reply-To: <202001262122.00QLM3vu070742@tahoe.cs.Dartmouth.EDU>
References: <202001262122.00QLM3vu070742@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2MH0O_H=B-K1s=2KN1uYkDLj10uHttUkaK43rFUUTWoXg@mail.gmail.com>

+1

Doug, you made my day.

On Sun, Jan 26, 2020 at 4:22 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> The anecdote below came from Nils-Peter Nelson, who as a
> manager in the computer center bought and installed the
> Labs' biggest Unix machine, a Cray 2. He also originated
> the string.h package.
>
> Doug
>
> Dennis told me he was going to a class reunion at Harvard.
>
> Me: "I guess you're the most famous member of your class."
> dmr: "No, the Unabomber is.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200126/1b3743cf/attachment.html>

From jon at fourwinds.com  Mon Jan 27 07:55:17 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 26 Jan 2020 13:55:17 -0800
Subject: [TUHS] More Spider
In-Reply-To: <D6C5A8F0-2B63-43A4-97B6-6AAEAEA7E8AD@planet.nl>
References: <E1330D79-D607-4DED-A003-571CD1000FCA@planet.nl>
 <CAG=a+rj6E9Mp-b1L96E-bby5hPJPZb+02_8JwdzRRDLG7DJAgA@mail.gmail.com>
 <D6C5A8F0-2B63-43A4-97B6-6AAEAEA7E8AD@planet.nl>
Message-ID: <202001262155.00QLtH5K380329@darkstar.fourwinds.com>

Minor correction to Ken's post, it was a Honeywell 516, not Packard Bell.
I lived on this machine for years.  Carl Christensen was one of the
Explorer Scout advisors along with Heinz which is why we got to play with
their machines.

The Pierce loop was up an running by the time that I showed up which was
maybe 1969 or 1970.  I don't recall ever meeting Pierce.  My recollection
is that the serious digital hardware guys in the group were Dave Weller,
John Sheets, John Schwartzwelder & John Camlet.  And Joe Condon had his
fingers in everything and made sure that everything reeked of cigarette
smoke.

I'm guessing that work was being done on Spider while the loop was in use,
again, because I remember the rack with the tempo, phone handset, and Tek
display near the 516.  And I'm pretty sure that I remember Sandy messing
with it on occasion; I think that he's the one that demonstrated to me that
there was an option to hook the handset up to a DAC that was on the program
counter or something, so one could listen and figure out if things were
running properly.  I think that there was a rack panel with a rotary switch
that one could use to select the handset source.

It sounds like a number of the devices that were connected to the loop
migrated to Spider after I left.

I'm guessing that when the article says that there were graphics display
terminals connected that those were the GLANCE G terminals that I mentioned
in an earlier post.  And, the PROM programmer makes sense too; I think that
this was in the room shared by John Camlet and Dan Belinski and was used to
program the TTL PROMs that contained the GLANCE G microcode.  This sticks
out in my mind because of the time that John and I tracked down and fixed a
microcode bug.

The rest of the network configuration is unfamiliar to me, again as it came
after I left.  I do remember that Max Matthews had a pile of DDP-224s because
his lab was yet another cool place to hang out.  The 516 hooked to the IC test
system was one of my projects.  It wasn't in area 10, I believe that it was in
area 20 under Iverson.  It had its own loop, sounds like it was later replaced
by Spider.

Not sure where it fits into the evolution of things, but I recall that our
department was split.  Hank Macdonald handled the Murry Hill end of things,
and Cher Cutler the Homdel end.  I don't remember exactly what was going on
at Homdel (other than blinding drivers on the Garden State Parkway), but I
recall that they had run a whole bunch of optical fiber underground I think
using the same ductwork that went to the fountains which were not purely
decorative, they were the chillers for the HVAC system too.

Jon

From thomas.paulsen at firemail.de  Mon Jan 27 09:14:53 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Mon, 27 Jan 2020 00:14:53 +0100
Subject: [TUHS] Screen editors
In-Reply-To: <6A1B2BB8-58FC-4BCF-9D8A-AA0E27B43EE5@planet.nl>
References: <6A1B2BB8-58FC-4BCF-9D8A-AA0E27B43EE5@planet.nl>
Message-ID: <05f0aaddc074bbc9131d8d98388dde58@firemail.de>

Hello,

> Editor source seems to be here: https://github.com/udo-munk/s

thanks a lot!

Makefile uses clang. So for all gcc users:
cp trunk/Makefile ./makefile
sed -i 's/clang/gcc/g' makefile 
cp makefile trunk/






From wkt at tuhs.org  Mon Jan 27 10:21:38 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 27 Jan 2020 10:21:38 +1000
Subject: [TUHS] Fwd request: Text of Caldera's free licenses for
 UnixWare/OpenServer
Message-ID: <20200127002138.GA11130@minnie.tuhs.org>

All, I was asked by Max to pass this query on to the TUHS list. Can
you e-mail back to Max directly. Thanks, Warren

----- Forwarded message from Maximilian Lorlacks <maxlorlax at protonmail.com> -----

Date: Sun, 26 Jan 2020 19:46:38 +0000
From: Maximilian Lorlacks <maxlorlax at protonmail.com>
To: "wkt at tuhs.org" <wkt at tuhs.org>
Subject: Fwd request: Text of Caldera's free licenses for UnixWare/OpenServer

Hi Warren,

Could you please forward this to the TUHS list?  I'm not a subscriber
to the list, but I perhaps someone there might know something about
this.

In 2001 and early 2002 (I can't believe it's already been almost two
decades), Caldera Systems, Inc. offered non-commercial licenses at no
cost for OpenServer 5.0.6, UnixWare 7.1(.1?) and Open UNIX 8.  However,
the web archive could not to capture the actual agreement hidden behind
the entrypoint form. I failed to get a license during that time since I
wasn't really interested in UNIX at that point, but in the interest of
historical preservation, I'm interested if anyone got those licenses
from back then and if so, if they've saved the actual license agreement
text.  I'm interested in what it reads.  I'm also curious about whether
the license keys from back then still work with Xinuos's new
registration platform, but it's probably too much to ask for people to
test that.

Please note that I am *not* trying to revive the trainwreck that is
the issue of the validity and scope of the Ancient UNIX license.  The
only way to properly resolve that would be a letter signed from Micro
Focus's legal department, but they've made it exceedingly clear that
they will persistently ignore any and all attempts to elicit any kind
of response regarding Ancient UNIX.

Cheers,

Max

----- End forwarded message -----

From doug at cs.dartmouth.edu  Mon Jan 27 13:17:35 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 26 Jan 2020 22:17:35 -0500
Subject: [TUHS] [TUHS} More Spider
Message-ID: <202001270317.00R3HZGP004867@tahoe.cs.Dartmouth.EDU>

> It might be worth mentioning that the Cambridge Ring (in the UK) used a very
> similar idea: a head end circulated empty frames which stations could fill in.

I'm quite sure the similarity is not accidental. Fraser began the Spider 
project almost immediately upon moving from Cambridge to Bell Labs.

Doug

From gtaylor at tnetconsulting.net  Tue Jan 28 06:41:05 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 27 Jan 2020 13:41:05 -0700
Subject: [TUHS] Fwd request: Text of Caldera's free licenses for
 UnixWare/OpenServer
In-Reply-To: <20200127002138.GA11130@minnie.tuhs.org>
References: <20200127002138.GA11130@minnie.tuhs.org>
Message-ID: <a65f830c-41f7-7567-ac87-66290093769e@tnetconsulting.net>

To: TUHS
CC: Max

I have a boxed copy of SCO OpenServer 5.<something>.  (I actually think 
I can lay my hands on it in about 5 minutes.)

I'll check to see what sort of paperwork is in it.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200127/afd302f0/attachment.bin>

From doug at cs.dartmouth.edu  Wed Jan 29 06:09:21 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 28 Jan 2020 15:09:21 -0500
Subject: [TUHS] man pages, defensive programming, and bibliographic
Message-ID: <202001282009.00SK9Lnr771562@coolidge.cs.dartmouth.edu>

> Always use '\&' (a non-printing, zero width character) to
> make it clear to the software, that the _function_ of the
> character next to it, is neither a sentence-terminating nor
> a control one.

It is unfortunate that such advice has to be given.  One should
not have to defend against stupid AI. This is one of only two
really unfortunate design choices (in my opinion) in original
[nt]roff. (The other is beginning a new page when the vertical
position reaches--as distinct from definitively passing--the 
bottom of a page.)

If AI is used, it should be optional. I happen not to like
double-width intersentence space, but it keeps getting foisted
on me essentially at random. Instead of fattening the manual
with annoying duties like that quoted above, I suggest fattening
it with a new request, "turn on/off doubling of spaces between
apparent sentences", or "put at least the specified space
between apparent sentences".  One can still use \&, but then
it's for a chosen purpose, not just defense against gremlins.

Incidentally, "next to" in the quoted advice must be read with
care. Sometimes it means before, sometimes after.

------------------------------------------------------------

In this old AI-induced trouble I see a cautionary lesson for
paragraph-based line breaking. fmt(1) is an existing program
that tries to do this. On unjustified text (i.e. all text
handled by fmt) it produces paragraphs of different "optimal"
widths, which can be even more distracting than unusually
ragged right margins.

Doug

From dave at horsfall.org  Thu Jan 30 06:25:12 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Jan 2020 07:25:12 +1100 (EST)
Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and
 tangentially related things ]
In-Reply-To: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu>
References: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.2001300722180.15513@aneurin.horsfall.org>

On Wed, 15 Jan 2020, Noel Chiappa wrote:

> Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes 
> to the QBUS between the original demo WD boards and the first DEC ones? 
> Are there any documents about the WD original still extant, do you know?

Which reminds me: I heard a story that DEC did not implement the Unibus as 
specified, in order to lock out 3rd-party vendors; apparently the timing 
was not quite right.  You couldn't complain to DEC because it was not 
their gear, and you couldn't complain to the vendor because they followed 
the spec...

-- Dave

From dave at horsfall.org  Thu Jan 30 08:24:13 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Jan 2020 09:24:13 +1100 (EST)
Subject: [TUHS] Screen editors
In-Reply-To: <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
Message-ID: <alpine.BSF.2.21.9999.2001300918470.15513@aneurin.horsfall.org>

On Mon, 20 Jan 2020, Toby Thain wrote:

> Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, 
> better as a programmer's editor. Not sure who wrote it (but istr it came 
> from the WordStar people?) Adding here for completeness...

I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never 
heard of WordMaster...

Getting a full ANSI C compiler for CP/M was great; I could use some Unix 
tools on it :-)  Can't remember if it was BDS or Hi-Tech; one was ANSI 
(function prototypes and the works) whereas the other wouldn't even 
recognise things like "int i = 1;".

I even found a UUCP for it too, but it was overlaid to hell and back; at 
least it worked...

-- Dave

From lm at mcvoy.com  Thu Jan 30 08:33:22 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 29 Jan 2020 14:33:22 -0800
Subject: [TUHS] Screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001300918470.15513@aneurin.horsfall.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
 <alpine.BSF.2.21.9999.2001300918470.15513@aneurin.horsfall.org>
Message-ID: <20200129223322.GK6410@mcvoy.com>

On Thu, Jan 30, 2020 at 09:24:13AM +1100, Dave Horsfall wrote:
> On Mon, 20 Jan 2020, Toby Thain wrote:
> 
> >Speaking of WordStar, on CP/M there was also WordMaster, lighter weight,
> >better as a programmer's editor. Not sure who wrote it (but istr it came
> >from the WordStar people?) Adding here for completeness...
> 
> I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never
> heard of WordMaster...
> 
> Getting a full ANSI C compiler for CP/M was great; I could use some Unix
> tools on it :-)  Can't remember if it was BDS or Hi-Tech; one was ANSI
> (function prototypes and the works) whereas the other wouldn't even
> recognise things like "int i = 1;".

BDS was pretty good about C, I used it a *lot*, but it had a really funky
not compatible libc/stdio.  I got used to it but had to retrain my brain
when I was on Unix.

From thomas.paulsen at firemail.de  Thu Jan 30 09:00:54 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Thu, 30 Jan 2020 00:00:54 +0100
Subject: [TUHS] Screen editors
In-Reply-To: <alpine.BSF.2.21.9999.2001300918470.15513@aneurin.horsfall.org>
References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>
 <20200120155946.169b39e0@sagittariusa.cnb.csic.es>
 <dfb57629-a249-fe46-5d69-48708d91be43@telegraphics.com.au>
 <alpine.BSF.2.21.9999.2001300918470.15513@aneurin.horsfall.org>
Message-ID: <063ca71ee512ef47b3bd9dcc34de78b1@firemail.de>

 also I never heard of WordMaster!


--- Ursprüngliche Nachricht ---
Von: Dave Horsfall <dave at horsfall.org>
Datum: 29.01.2020 23:24:13
An: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Betreff: Re: [TUHS] Screen editors

On Mon, 20 Jan 2020, Toby Thain wrote:

> Speaking of WordStar, on CP/M there was also WordMaster, lighter weight,

> better as a programmer's editor. Not sure who wrote it (but istr it
came 
> from the WordStar people?) Adding here for completeness...

I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never

heard of WordMaster...

Getting a full ANSI C compiler for CP/M was great; I could use some Unix

tools on it :-)  Can't remember if it was BDS or Hi-Tech; one was ANSI 
(function prototypes and the works) whereas the other wouldn't even 
recognise things like "int i = 1;".

I even found a UUCP for it too, but it was overlaid to hell and back; at

least it worked...

-- Dave




From dave at horsfall.org  Thu Jan 30 14:00:10 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Jan 2020 15:00:10 +1100 (EST)
Subject: [TUHS] Unix quix
In-Reply-To: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.2001301457490.15513@aneurin.horsfall.org>

On Wed, 22 Jan 2020, Noel Chiappa wrote:

[ Whirlwind ]

> Pretty interesting machine, if you study its instruction set, BTW; with 
> no stack, subroutines are 'interesting'.

Not much worse than the PDP-8 :-)  Plant return address in first word and 
jump to the second word; to return, do an indirect jump to the first word.

Recursion was possible. but I think you had to emulate the stack.

-- Dave

From aap at papnet.eu  Thu Jan 30 16:32:06 2020
From: aap at papnet.eu (Angelo Papenhoff)
Date: Thu, 30 Jan 2020 07:32:06 +0100
Subject: [TUHS] Unix quix
In-Reply-To: <alpine.BSF.2.21.9999.2001301457490.15513@aneurin.horsfall.org>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.9999.2001301457490.15513@aneurin.horsfall.org>
Message-ID: <20200130063206.GA28074@indra.papnet.eu>

On 30/01/20, Dave Horsfall wrote:
> On Wed, 22 Jan 2020, Noel Chiappa wrote:
> 
> [ Whirlwind ]
> 
> > Pretty interesting machine, if you study its instruction set, BTW; with 
> > no stack, subroutines are 'interesting'.
> 
> Not much worse than the PDP-8 :-)  Plant return address in first word and 
> jump to the second word; to return, do an indirect jump to the first word.
> 
> Recursion was possible. but I think you had to emulate the stack.

On the whirlwind the sp (subprogram) instruction puts the return address
in the A register. with ta (transfer A) you can put it into the address
part of an instruction, so a function call is as simple as

	...
	sp foo
	...

	foo:	ta foo0
		...
	foo0:	sp .

So it's pretty nice you can use sp for calls and jumps. cp (conditional
sp) works the same but only jumps if AC is negative.
The big difference between the WW and later machines is that there is no
indirection on the WW! You end up writing lots of addresses into
instructions. It's even weirder on the TX-0 with its (original) limited
instruction set where you don't even have instructions to just store an
address, only the full word.

aap

From imp at bsdimp.com  Fri Jan 31 05:23:58 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 30 Jan 2020 12:23:58 -0700
Subject: [TUHS] 1984 AT&T Bell Labs Unix Edition
Message-ID: <CANCZdfpNV=o4VjL9=8WkhiAmK_FAPMh2ii=+vyTNUP+P2o+XFg@mail.gmail.com>

Greetings,

Is this issue online? I may have a copy buried in my boxes of books, and am
on the road. I'd like to read the article  on portability and/or the one on
performance. One of those has a table of internal vs external release names
/ dates. archive.org and elsewhere only has through 83. I discovered I
might have it this morning 20 minutes before I had to leave for the airport
for another talk. :(

Thanks for any help you can provide....

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200130/c92aa70a/attachment.html>

From imp at bsdimp.com  Fri Jan 31 09:02:04 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 30 Jan 2020 16:02:04 -0700
Subject: [TUHS] 1984 AT&T Bell Labs Unix Edition
In-Reply-To: <CANCZdfpNV=o4VjL9=8WkhiAmK_FAPMh2ii=+vyTNUP+P2o+XFg@mail.gmail.com>
References: <CANCZdfpNV=o4VjL9=8WkhiAmK_FAPMh2ii=+vyTNUP+P2o+XFg@mail.gmail.com>
Message-ID: <CANCZdfriWyYW=+a+bFUToW_yqQ4+2TrBS5=rHJBqP1JT9Qnf_Q@mail.gmail.com>

Thanks. I now have what I need. Including a reference to an 8086 port from
1978, just one year after the Interdata and VM/370 ports...

Warner

On Thu, Jan 30, 2020, 2:23 PM Warner Losh <imp at bsdimp.com> wrote:

> Greetings,
>
> Is this issue online? I may have a copy buried in my boxes of books, and
> am on the road. I'd like to read the article  on portability and/or the one
> on performance. One of those has a table of internal vs external release
> names / dates. archive.org and elsewhere only has through 83. I
> discovered I might have it this morning 20 minutes before I had to
> leave for the airport for another talk. :(
>
> Thanks for any help you can provide....
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200130/946712cb/attachment.html>