From kevin.bowling at kev009.com Tue Nov 1 04:21:40 2022
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Mon, 31 Oct 2022 11:21:40 -0700
Subject: [TUHS] Four windowing systems on SunOS
Message-ID: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
Cameron Kaiser has written up a nice survey on some windowing systems
that can run under OS/MP or SunOS
https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html
From lm at mcvoy.com Tue Nov 1 05:14:01 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 31 Oct 2022 12:14:01 -0700
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
Message-ID: <20221031191401.GN22806@mcvoy.com>
Sunview was a toolkit - a really nice one in my opinion, every api had
a set of defaults and a key, so you could call sv_whatever(SV_DONE)
and did whatever with the default values. But you could override the
defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
kept the system from being very verbose.
People like Sunview's api enough that there was an Xview toolkit which
was Sunview ported to X10/X11.
On Mon, Oct 31, 2022 at 11:21:40AM -0700, Kevin Bowling wrote:
> Cameron Kaiser has written up a nice survey on some windowing systems
> that can run under OS/MP or SunOS
> https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From jon at fourwinds.com Tue Nov 1 05:17:59 2022
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 31 Oct 2022 12:17:59 -0700
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <20221031191401.GN22806@mcvoy.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
Message-ID: <202210311917.29VJHxe6110870@darkstar.fourwinds.com>
Larry McVoy writes:
> Sunview was a toolkit - a really nice one in my opinion, every api had
> a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> and did whatever with the default values. But you could override the
> defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> kept the system from being very verbose.
>
> People like Sunview's api enough that there was an Xview toolkit which
> was Sunview ported to X10/X11.
Yeah, but it had its own issues. I did an emergency late night and weekend
consulting contract with Sun because Xview kept crashing. Turns out that
the code had some very suspect pointer dereferencing that worked until the
SPARC processors came along and barfed at unaligned accesses.
Jon
From crossd at gmail.com Tue Nov 1 05:21:56 2022
From: crossd at gmail.com (Dan Cross)
Date: Mon, 31 Oct 2022 15:21:56 -0400
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <202210311917.29VJHxe6110870@darkstar.fourwinds.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
Message-ID: <CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
On Mon, Oct 31, 2022 at 3:18 PM Jon Steinhart <jon at fourwinds.com> wrote:
> Larry McVoy writes:
> > Sunview was a toolkit - a really nice one in my opinion, every api had
> > a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> > and did whatever with the default values. But you could override the
> > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> > kept the system from being very verbose.
> >
> > People like Sunview's api enough that there was an Xview toolkit which
> > was Sunview ported to X10/X11.
>
> Yeah, but it had its own issues. I did an emergency late night and weekend
> consulting contract with Sun because Xview kept crashing. Turns out that
> the code had some very suspect pointer dereferencing that worked until the
> SPARC processors came along and barfed at unaligned accesses.
That sounds like a ton of codebases, though. I remember trying to port an
APL interpreter to 64-bit, and giving up; too much type puning of pointers
through int's.
- Dan C.
From lm at mcvoy.com Tue Nov 1 05:26:44 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 31 Oct 2022 12:26:44 -0700
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <202210311917.29VJHxe6110870@darkstar.fourwinds.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
Message-ID: <20221031192644.GO22806@mcvoy.com>
On Mon, Oct 31, 2022 at 12:17:59PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > Sunview was a toolkit - a really nice one in my opinion, every api had
> > a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> > and did whatever with the default values. But you could override the
> > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> > kept the system from being very verbose.
> >
> > People like Sunview's api enough that there was an Xview toolkit which
> > was Sunview ported to X10/X11.
>
> Yeah, but it had its own issues. I did an emergency late night and weekend
> consulting contract with Sun because Xview kept crashing. Turns out that
> the code had some very suspect pointer dereferencing that worked until the
> SPARC processors came along and barfed at unaligned accesses.
Oh yeah, been there, fixed that.
From beebe at math.utah.edu Tue Nov 1 05:33:28 2022
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 31 Oct 2022 13:33:28 -0600
Subject: [TUHS] Four windowing systems on SunOS
Message-ID: <CMM.0.95.0.1667244808.beebe@gamma.math.utah.edu>
Larry McVoy reports today:
>> People like Sunview's api enough that there was an Xview toolkit which
>> was Sunview ported to X10/X11.
The interface was nicely documented in three editions of a book (I
have no entry for the second edition):
@String{pub-ORA = "O'Reilly \& {Associates, Inc.}"}
@String{pub-ORA:adr = "981 Chestnut Street, Newton, MA 02164, USA"}
@Book{Heller:1990:XPM,
author = "Dan Heller",
title = "{XView} Programming Manual",
volume = "7",
publisher = pub-ORA,
address = pub-ORA:adr,
pages = "xxviii + 557",
year = "1990",
ISBN = "0-937175-38-2",
ISBN-13 = "978-0-937175-38-5",
LCCN = "QA76.76.W56 D44 v.7 1990",
bibdate = "Tue Dec 14 22:55:18 1993",
bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib",
acknowledgement = ack-nhfb,
}
@Book{Heller:1991:XPM,
author = "Dan Heller",
title = "{XView} Programming Manual",
volume = "7A",
publisher = pub-ORA,
address = pub-ORA:adr,
edition = "Third",
pages = "xxxvii + 729",
month = sep,
year = "1991",
ISBN = "0-937175-87-0",
ISBN-13 = "978-0-937175-87-3",
LCCN = "QA76.76.W56 H447 1990",
bibdate = "Mon Jan 3 17:55:53 1994",
bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib",
series = "The Definitive guides to the X Window System",
acknowledgement = ack-nhfb,
}
I have the first edition on a shelf near my campus office chair, and
continue to use olvwm as my window manager on multiple O/Ses, for 30+
years.
Every window manager designed since seems to fail to understand the
importance of user customizable, and pinnable, menus, which I exploit
to the hilt. The menu customization goes into a single, easy to edit,
text file, $HOME/.openwin-menu.
Compare that to the Gnome desktop, with hundreds of files, many of
them binary, stored in hidden directories under $HOME, and for which
any corruption breaks the window system, and prevents login (except
via a GUI console).
Also. olvwm does not litter a default desktop with icons for
applications that many of use would never use: just a simple blank
desktop, with menu popups bound to mouse buttons.
With olvwm, you can have any number of virtual desktops, not just the
2 or 4 offered by more modern window manaugers, and unlike some of
those, windows can be dragged between desktops.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- 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 ron at ronnatalie.com Tue Nov 1 05:59:44 2022
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 31 Oct 2022 19:59:44 +0000
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <20221031192644.GO22806@mcvoy.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<20221031192644.GO22806@mcvoy.com>
Message-ID: <em26aba50a-1dc8-4b3a-9f70-4c6b422a015a@6b571117.com>
My favorite SunView story was the day I was working in the Pentagon (I
was ron at hq.af.mil for a while). One of the Sun workstations had a
Sunview screen lock running and the guy I was visiting was on the phone.
I told him I’d just unlock the thing myself. I promptly set forth
to do so and got it open. He quickly said, “I have to hang up and go
check on something,†and came over and asked how I’d done that.
The screen lock was just a very large window forced to the top of
everything on the screen. If you hit the hot key to iconify it, you
had a fraction of a second to interact before it reasserted itself. So
you keep hitting iconify and maybe getting a letter or two typed into
one of the one terminal windows at a time. You run ps, find the pid of
the screen lock process, and kill it.
-Ron
From tuhs at tuhs.org Tue Nov 1 07:52:03 2022
From: tuhs at tuhs.org (Grant Taylor via TUHS)
Date: Mon, 31 Oct 2022 15:52:03 -0600
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
Message-ID: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
On 10/31/22 1:21 PM, Dan Cross wrote:
> That sounds like a ton of codebases, though. I remember trying to port
> an APL interpreter to 64-bit, and giving up; too much type puning of
> pointers through int's.
This reminds me of the stories I've heard about Microsoft's inability to
port Pinball to /their/ 64-bit processor, the Itanium.
No, not their copy of /AMD/'s 64-bit extension on Intel's x86
architecture. ;-)
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221031/a1872cb6/attachment.p7s>
From rtomek at ceti.pl Tue Nov 1 13:25:19 2022
From: rtomek at ceti.pl (Tomasz Rola)
Date: Tue, 1 Nov 2022 04:25:19 +0100
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <CMM.0.95.0.1667244808.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1667244808.beebe@gamma.math.utah.edu>
Message-ID: <Y2CRn22L6QNT2x7J@tau1.ceti.pl>
On Mon, Oct 31, 2022 at 01:33:28PM -0600, Nelson H. F. Beebe wrote:
> Larry McVoy reports today:
>
> >> People like Sunview's api enough that there was an Xview toolkit which
> >> was Sunview ported to X10/X11.
>
> The interface was nicely documented in three editions of a book (I
> have no entry for the second edition):
[...]
>
> I have the first edition on a shelf near my campus office chair, and
> continue to use olvwm as my window manager on multiple O/Ses, for 30+
> years.
I think (that was so long ago) I had tried each of the guis mentioned
in the blog post, some of them for few hours only. X11 was the best
for me, and then I played with olwm. And then I discovered olvwm and
the concept of virtual desktop - yay, that was really great.
Later I was moved to another SunOS workstation which only had olwm and
they would not install anything when lowly life form asked for it. So
I ftp-ed it from previous workstation and tried, and it occurred that
binary was compatible and ran well... yay, again.
A bit later I had installed my first Linux (Slackware it was) and with it
came olvwm, so I was thrilled to have "emulated" workstation at home.
After that point, I gradually replaced every element of my desktop
environment with other stuff - csh became sh became bash, olvwm became
fvwm with even more virtual desktops, some text editor became emacs
and so on.
> Every window manager designed since seems to fail to understand the
> importance of user customizable, and pinnable, menus, which I exploit
> to the hilt. The menu customization goes into a single, easy to edit,
> text file, $HOME/.openwin-menu.
I am not sure menus are that much important in my life. I liked fvwm
more, because I could more or less easily customize the key shortcuts
for various windows operations (maximize, iconify, resize, resize back
etc), sometimes in combination with mouse button. This and quickly
moving between desktops, arranging windows so neighbouring desktops
contain parts of the workflow.
Nowadays I prefer to run stuff from the terminal, via proper
commands. If it goes wonky, I can see what happened. This makes me a
bit more mess with more terminals but hey, iconify and hooray.
I only very rarely use menus.
> Compare that to the Gnome desktop, with hundreds of files, many of
> them binary, stored in hidden directories under $HOME, and for which
> any corruption breaks the window system, and prevents login (except
> via a GUI console).
Ah, Gnome and KDE, both are - for me at least - too big and too hard
to manage if something goes wrong. Once I started KDE after upgrade
(ok, that was decade and some years ago, it must have improved by
now), and it went blank at once and started to do 100% cpu and God
knows what (because I could not locate any messages about what it was
doing). Never solved this problem, never was willing to spend time on
it, switched back to fvwm and moved on. From preliminary diagnostics,
I suspect it had something to do with enormous number of html files
buried somewhere on my disc. The lousy thing tried to catalogue it and
probably went into O(n^k) loop.
Those environments are nice to the eye but cannot cope when something
is beyound recognition of their developers.
But they are indispensable when one installs Linux for someone who
really is not going to program their desktop, or edit config
files. For me, in such cases xfce is the nice mix of usability and
acceptable looks.
--
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 lproven at gmail.com Tue Nov 1 21:02:59 2022
From: lproven at gmail.com (Liam Proven)
Date: Tue, 1 Nov 2022 12:02:59 +0100
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
Message-ID: <CAMTenCFZj7jT6mFJu-BYgCx3QGYwTxdxVP4jjQvoy6NoOi_jBA@mail.gmail.com>
On Mon, 31 Oct 2022 at 22:55, Grant Taylor via TUHS <tuhs at tuhs.org> wrote:
>
> This reminds me of the stories I've heard about Microsoft's inability to
> port Pinball to /their/ 64-bit processor, the Itanium.
(?) Itanium was Intel's, not Microsoft's.
> No, not their copy of /AMD/'s 64-bit extension on Intel's x86
> architecture. ;-)
Again, not MICROS~1: Intel.
MS is the reason Intel supports x86-64.
When it saw that Itanium was failing, just like i860, just like
iAPX-32, Intel built its own 64-bit extension to x86-32, to compete
with AMD64.
MS told Intel: look, we are already supporting *one* deadbeat
unprofitable 64-bit arch of yours (i.e. Itanic.) We're not supporting
*two*. No. You make it compatible with AMD's, because we're doing just
one 64-bit x86 and we're already working on it.
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
From sjenkin at canb.auug.org.au Wed Nov 2 12:36:34 2022
From: sjenkin at canb.auug.org.au (steve jenkin)
Date: Wed, 2 Nov 2022 13:36:34 +1100
Subject: [TUHS] Early Unix and Keyboard Skills
Message-ID: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’)
and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades.
Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis.
But as well, they wrote papers and man pages, probably more.
I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know?
There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills,
which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially.
Underlying this is something I once caught as a random comment:
The commonality of skills between Writing & Coding.
Does anyone has any good refs for this crossover?
Is it a real effect or a biased view.
That great programmers are also “good writersâ€:
takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing†and “polishingâ€, not rushing it out the door.
Ken is famous for his brevity and succinct statements.
Not sure if that’s a personal preference, a mastered skill or “economy in everythingâ€.
steve j
=========
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
M.D. McIlroy
<https://www.cs.dartmouth.edu/~doug/reader.pdf>
<https://archive.org/details/a_research_unix_reader/page/n13/mode/2up>
pg 10
3.4. Languages
CC (v2 page 52)
V2 saw a burst of languages:
a new TMG,
a B that worked in both core-resident and software-paged versions,
the completion of Fortran IV (Thompson and Ritchie), and
Ritchie's first C, conceived as B with data types.
In that furiously productive year Thompson and Ritchie together
wrote and debugged about
100,000 lines of production code.
=========
Programming's Dirtiest Little Secret
Wednesday, September 10, 2008
<http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html>
It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else.
But when it comes to programming, there are only so many things you can sacrifice!
You can cut down on your documentation.
You can cut down on commenting your code.
You can cut down on email conversations and
participation in online discussions, preferring group discussions and hallway conversations.
And... well, that's about it.
So guess what non-touch-typists sacrifice?
All of it, man.
They sacrifice all of it.
Touch typists can spot an illtyperate programmer from a mile away.
They don't even have to be in the same room.
For starters, non-typists are almost invisible.
They don't leave a footprint in our online community.
=========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
From rdm at cfcl.com Wed Nov 2 13:46:09 2022
From: rdm at cfcl.com (Rich Morin)
Date: Tue, 1 Nov 2022 20:46:09 -0700
Subject: [TUHS] early Unix papers, from Jim Joyce
Message-ID: <28C0C8F2-3FA0-4CE1-AA41-6E8CD42D8C34@cfcl.com>
Some of you may recall my friend Jim Joyce, who was an early proponent of Unix. IIRC, he taught the first course on Unix at UCB. Later on, he started and ran mail-order bookstores and seminars specializing in Unix-related topics, helped to found Unix Review, etc.
In any event, I have about a cubic foot of early Unix papers, saved from Jim's files after his death. It's quite likely that all of these papers are already available in collections, but I'd like to make sure that any exceptions don't get lost. Also, the printed copies may have some independent historical merit. Suggestions?
-r
From jnc at mercury.lcs.mit.edu Wed Nov 2 16:07:30 2022
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 2 Nov 2022 02:07:30 -0400 (EDT)
Subject: [TUHS] early Unix papers, from Jim Joyce
Message-ID: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
> From: Rich Morin
> Suggestions?
Step #0: make a list of what's there, and post it here. That's crucial input
to any recommendation.
Noel
From e5655f30a07f at ewoof.net Wed Nov 2 16:53:25 2022
From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 2 Nov 2022 06:53:25 +0000
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
Message-ID: <a811e443-473b-4abe-ab38-e97d8893d5d7@home.arpa>
On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin):
> There’s at least one Internet meme that highly productive coders
> necessarily have good keyboard skills, which leads to also producing
> documentation or, at least, not avoiding it entirely, as often
> happens commercially.
I wouldn't be so sure that this necessarily follows. Good keyboard
skills definitely help with the mechanics of typing code as well as
text, I'll certainly grant that; but someone can be a good typist yet
write complete gibberish, or be a poor/slow typist and _by necessity_
need to consider each word that they use because typing an extra
sentence takes them so long. If it takes you ten seconds to type out a
normal sentence, revising becomes less of an issue than if typing out
the same sentence takes a minute or a minute and a half.
Also, certainly in my case and I doubt that I'm alone, a lot of my
time "coding" isn't spent doing the mechanics of "writing code", but
rather considering possible solutions to a problem, and what the
consequences would be of different choices. That part of the software
development process is essentially unaffected by how good one is as a
typist, and I expect that the effect would be even more pronounced for
someone using something like an ASR-33 and edlin, than a modern
computer and visual editor. Again, the longer it takes to revise
something, the more it makes sense to get it right on the first
attempt, even if that means some preparatory work up-front.
Writing documentation is probably more an issue of mindset and being
allowed the time, than it is a question of how good one is as a
typist.
--
🪶 Michael Kjörling ðŸ¡Â https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From robpike at gmail.com Wed Nov 2 17:11:26 2022
From: robpike at gmail.com (Rob Pike)
Date: Wed, 2 Nov 2022 18:11:26 +1100
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <a811e443-473b-4abe-ab38-e97d8893d5d7@home.arpa>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<a811e443-473b-4abe-ab38-e97d8893d5d7@home.arpa>
Message-ID: <CAKzdPgzm8fkT5SeAFf+uaesp-oti2UndDdTPiB8MRU3CPebfRw@mail.gmail.com>
Neither ken nor dmr were impressive typists. In fact few programmers were
then, at least of my acquaintance.
In the 1970s Bell Labs created the Getset - think of it as an early wired
smartphone, or a Minitel, with a little screen and keyboard. It cost quite
a bit but was a cool gadget so the executives all got one. But, in
fascinating contrast to the Blackberry a generation later, no one would
touch it - literally - because it had a keyboard, and keyboards were for
(female) secretaries, not (male) executives. The product, although well
ahead of its time, was a complete failure due to the cultural bias then.
There may be a good sociology paper in there somewhere.
I'm not saying K&D shared this blinkered view, not at all, just that typing
skills were not de facto back then. Some of the folks were even two-finger
jabbers. I was a little younger and a faster typist than most of the
others, and I am not a good typist by any modern standard.
bwk was one who could smash out the text faster than many. His having
learned on a teletype, the keyboard would resound with the impact of his
forceful keystrokes.
-rob
On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling <e5655f30a07f at ewoof.net>
wrote:
> On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin):
> > There’s at least one Internet meme that highly productive coders
> > necessarily have good keyboard skills, which leads to also producing
> > documentation or, at least, not avoiding it entirely, as often
> > happens commercially.
>
> I wouldn't be so sure that this necessarily follows. Good keyboard
> skills definitely help with the mechanics of typing code as well as
> text, I'll certainly grant that; but someone can be a good typist yet
> write complete gibberish, or be a poor/slow typist and _by necessity_
> need to consider each word that they use because typing an extra
> sentence takes them so long. If it takes you ten seconds to type out a
> normal sentence, revising becomes less of an issue than if typing out
> the same sentence takes a minute or a minute and a half.
>
> Also, certainly in my case and I doubt that I'm alone, a lot of my
> time "coding" isn't spent doing the mechanics of "writing code", but
> rather considering possible solutions to a problem, and what the
> consequences would be of different choices. That part of the software
> development process is essentially unaffected by how good one is as a
> typist, and I expect that the effect would be even more pronounced for
> someone using something like an ASR-33 and edlin, than a modern
> computer and visual editor. Again, the longer it takes to revise
> something, the more it makes sense to get it right on the first
> attempt, even if that means some preparatory work up-front.
>
> Writing documentation is probably more an issue of mindset and being
> allowed the time, than it is a question of how good one is as a
> typist.
>
> --
> 🪶 Michael Kjörling 🡠https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?â€
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/031d3703/attachment-0001.htm>
From e5655f30a07f at ewoof.net Wed Nov 2 17:32:45 2022
From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 2 Nov 2022 07:32:45 +0000
Subject: [TUHS] early Unix papers, from jim Joyce
In-Reply-To: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
References: <28C0C8F2-3FA0-4CE1-AA41-6E8CD42D8C34@cfcl.com>
<20221102060730.A114A18C08A@mercury.lcs.mit.edu>
Message-ID: <a99aa467-869c-49df-9d3c-57747247e6bf@home.arpa>
On 2 Nov 2022 02:07 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>> Suggestions?
>
> Step #0: make a list of what's there, and post it here. That's crucial input
> to any recommendation.
Agreed.
Also, step #1: Before sending them off somewhere or tossing them,
consider whether some place like the Computer History Museum might be
interested in them.
--
🪶 Michael Kjörling ðŸ¡Â https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From michael at casadevall.pro Wed Nov 2 18:55:20 2022
From: michael at casadevall.pro (Michael Casadevall)
Date: Wed, 2 Nov 2022 04:55:20 -0400
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
Message-ID: <CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
I extensively researched this; there are infact copies of Pinball for
64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s
Pinball had problems relating to 64-bit FPU precision (and this can
actually be reproduced by fiddling with FPU flags), but it did ship in
Windows XP x64 Professional.
Michael
On Mon, Oct 31, 2022 at 5:55 PM Grant Taylor via TUHS <tuhs at tuhs.org> wrote:
> On 10/31/22 1:21 PM, Dan Cross wrote:
> > That sounds like a ton of codebases, though. I remember trying to port
> > an APL interpreter to 64-bit, and giving up; too much type puning of
> > pointers through int's.
>
> This reminds me of the stories I've heard about Microsoft's inability to
> port Pinball to /their/ 64-bit processor, the Itanium.
>
> No, not their copy of /AMD/'s 64-bit extension on Intel's x86
> architecture. ;-)
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/52cf2e3a/attachment.htm>
From steffen at sdaoden.eu Wed Nov 2 22:13:52 2022
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 02 Nov 2022 13:13:52 +0100
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
Message-ID: <20221102121352.MhcLw%steffen@sdaoden.eu>
steve jenkin wrote in
<E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
...
|I’ve never heard anyone mention keyboard skills with the people of \
|the CSRC - doesn’t anyone know?
What i personally find more fascinating (given that -- in the
right condition -- i type pretty fast even in total darkness but
darkest possible monitor brightness) is the multitaskability some
show, in respect to combination of mouse and keyboard (or even
dual-mouse if i remember a message of Rob Pike right). I once
watched a video on the google tube of Russ Cox dancing acme doing
go testing, could be it is [1]. When he starts to actually work
a bit (late on iirc), that is thrilling, i could never select /
paste (kill snarf yank what do i know) that fast.
[1] https://www.youtube.com/watch?v=dP1xVpMPn8M
--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 douglas.mcilroy at dartmouth.edu Wed Nov 2 22:16:41 2022
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Wed, 2 Nov 2022 08:16:41 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
Message-ID: <CAKH6PiV6kmP4YpHWjt13ncKQTmJEhTh065e=AZncus_PnB8BZw@mail.gmail.com>
> Touch typists can spot an illtyperate programmer from a mile away.
> They don't even have to be in the same room.
I once thought of touch typing as employment of all fingers. Then I met
Fred Grampp. Using only four fingers, he typed as fast as most good
programmers. He knew where to hit, with a kinesthetic sense that had
progressed beyond dependence on "home keys". It was an athletic
performance, astonishing to watch.
Doug
From steffen at sdaoden.eu Wed Nov 2 22:24:32 2022
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 02 Nov 2022 13:24:32 +0100
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <20221102121352.MhcLw%steffen@sdaoden.eu>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<20221102121352.MhcLw%steffen@sdaoden.eu>
Message-ID: <20221102122432.og3EI%steffen@sdaoden.eu>
Steffen Nurpmeso wrote in
<20221102121352.MhcLw%steffen at sdaoden.eu>:
|steve jenkin wrote in
| <E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
| ...
||I’ve never heard anyone mention keyboard skills with the people of \
||the CSRC - doesn’t anyone know?
|
|What i personally find more fascinating (given that -- in the
|right condition -- i type pretty fast even in total darkness but
|darkest possible monitor brightness) is the multitaskability some
|show, in respect to combination of mouse and keyboard (or even
|dual-mouse if i remember a message of Rob Pike right). I once
...
I once had a very small infrared / PS/2 keyboard with a track ball
at the upper right corner, and the buttons on the upper left)
where middle finger and forefinger only had to be moved a bit, but
the heel of hand(s) could remain (only twisted a bit). That
allowed for pretty good precision and speed. But i think it was
still not that of Russ Cox and acme and external mouse/mice.
--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 jpl.jpl at gmail.com Wed Nov 2 22:26:35 2022
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Wed, 2 Nov 2022 08:26:35 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <20221102121352.MhcLw%steffen@sdaoden.eu>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<20221102121352.MhcLw%steffen@sdaoden.eu>
Message-ID: <CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
When I was in high school (in the early sixties) I tried to sign up for
typing, which was taught on manual typewriters. I was told that the class
was for girls only, and I was turned away. I never did develop good typing
skills. I'm pretty much a two-fingered typist. Ironically, I have probably
done more typing than 90% of the female classmates who were allowed to take
the class.
Precision figured mightily in those days, which may also have pre-dated
white-out. Eliminating an error was a big deal. Now it's dead easy, and
auto-correct has already fixed several errors in this message.
On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> steve jenkin wrote in
> <E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
> ...
> |I’ve never heard anyone mention keyboard skills with the people of \
> |the CSRC - doesn’t anyone know?
>
> What i personally find more fascinating (given that -- in the
> right condition -- i type pretty fast even in total darkness but
> darkest possible monitor brightness) is the multitaskability some
> show, in respect to combination of mouse and keyboard (or even
> dual-mouse if i remember a message of Rob Pike right). I once
> watched a video on the google tube of Russ Cox dancing acme doing
> go testing, could be it is [1]. When he starts to actually work
> a bit (late on iirc), that is thrilling, i could never select /
> paste (kill snarf yank what do i know) that fast.
>
> [1] https://www.youtube.com/watch?v=dP1xVpMPn8M
>
> --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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/f9065596/attachment.htm>
From stewart at serissa.com Wed Nov 2 23:07:31 2022
From: stewart at serissa.com (Larry Stewart)
Date: Wed, 2 Nov 2022 09:07:31 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
References: <CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
Message-ID: <7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com>
In 1969 at the end of 9 th grade I got a foot injury that kept me on crutches for the summer so I took summer school typing. very worthwhile. I think 90% of the class were young women. My parents encouraged it mostly because it would make writing term papers much easier, which it did, but of course it had many computing benefits as well.
the ancient typewriters had really heavy keys with long strokes. Much like teletypes.
> On Nov 2, 2022, at 8:27 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
>
> 
> When I was in high school (in the early sixties) I tried to sign up for typing, which was taught on manual typewriters. I was told that the class was for girls only, and I was turned away. I never did develop good typing skills. I'm pretty much a two-fingered typist. Ironically, I have probably done more typing than 90% of the female classmates who were allowed to take the class.
>
> Precision figured mightily in those days, which may also have pre-dated white-out. Eliminating an error was a big deal. Now it's dead easy, and auto-correct has already fixed several errors in this message.
>
>> On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>> steve jenkin wrote in
>> <E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
>> ...
>> |I’ve never heard anyone mention keyboard skills with the people of \
>> |the CSRC - doesn’t anyone know?
>>
>> What i personally find more fascinating (given that -- in the
>> right condition -- i type pretty fast even in total darkness but
>> darkest possible monitor brightness) is the multitaskability some
>> show, in respect to combination of mouse and keyboard (or even
>> dual-mouse if i remember a message of Rob Pike right). I once
>> watched a video on the google tube of Russ Cox dancing acme doing
>> go testing, could be it is [1]. When he starts to actually work
>> a bit (late on iirc), that is thrilling, i could never select /
>> paste (kill snarf yank what do i know) that fast.
>>
>> [1] https://www.youtube.com/watch?v=dP1xVpMPn8M
>>
>> --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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/254216c0/attachment.htm>
From lm at mcvoy.com Wed Nov 2 23:16:34 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 2 Nov 2022 06:16:34 -0700
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com>
References: <CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
<7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com>
Message-ID: <20221102131634.GF26791@mcvoy.com>
Self taught touch typer here. I frequently compare typing to running
my excavator. If I don't think about what I'm doing, everything works,
I can type in the dark (doing that right now) but as soon as I start
thinking about where the keys are (or what the joysticks on the excavator
do) it all goes to shit.
And getting back to writing, I personally feel like if you write the
man page first, it settles my messy brain into a good space, the code
comes easier after writing docs. I view writing docs as sort of the
first pass of thinking about how to write the code. Doesn't always
work but it is pleasant when it does.
On Wed, Nov 02, 2022 at 09:07:31AM -0400, Larry Stewart wrote:
> In 1969 at the end of 9 th grade I got a foot injury that kept me on crutches for the summer so I took summer school typing. very worthwhile. I think 90% of the class were young women. My parents encouraged it mostly because it would make writing term papers much easier, which it did, but of course it had many computing benefits as well.
> the ancient typewriters had really heavy keys with long strokes. Much like teletypes.
>
> > On Nov 2, 2022, at 8:27 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
> >
> > ???
> > When I was in high school (in the early sixties) I tried to sign up for typing, which was taught on manual typewriters. I was told that the class was for girls only, and I was turned away. I never did develop good typing skills. I'm pretty much a two-fingered typist. Ironically, I have probably done more typing than 90% of the female classmates who were allowed to take the class.
> >
> > Precision figured mightily in those days, which may also have pre-dated white-out. Eliminating an error was a big deal. Now it's dead easy, and auto-correct has already fixed several errors in this message.
> >
> >> On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> >> steve jenkin wrote in
> >> <E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
> >> ...
> >> |I???ve never heard anyone mention keyboard skills with the people of \
> >> |the CSRC - doesn???t anyone know?
> >>
> >> What i personally find more fascinating (given that -- in the
> >> right condition -- i type pretty fast even in total darkness but
> >> darkest possible monitor brightness) is the multitaskability some
> >> show, in respect to combination of mouse and keyboard (or even
> >> dual-mouse if i remember a message of Rob Pike right). I once
> >> watched a video on the google tube of Russ Cox dancing acme doing
> >> go testing, could be it is [1]. When he starts to actually work
> >> a bit (late on iirc), that is thrilling, i could never select /
> >> paste (kill snarf yank what do i know) that fast.
> >>
> >> [1] https://www.youtube.com/watch?v=dP1xVpMPn8M
> >>
> >> --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)
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From steffen at sdaoden.eu Wed Nov 2 23:27:34 2022
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 02 Nov 2022 14:27:34 +0100
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<20221102121352.MhcLw%steffen@sdaoden.eu>
<CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw@mail.gmail.com>
Message-ID: <20221102132734.PwCRX%steffen@sdaoden.eu>
John P. Linderman wrote in
<CAC0cEp9v1ZhTgEFMNGMGH1GhXo9V87QiOPfbbCuMG1y6D9Esaw at mail.gmail.com>:
|When I was in high school (in the early sixties) I tried to sign up for
|typing, which was taught on manual typewriters. I was told that the class
|was for girls only, and I was turned away. I never did develop good typing
|skills. I'm pretty much a two-fingered typist. Ironically, I have probably
This can be a winner:
https://www.youtube.com/watch?v=G4nX0Xrn-wo
(The classic.)
|done more typing than 90% of the female classmates who were allowed to take
|the class.
These machine-gunners are in another league per se from my modest
point of view. Ten finger thunderstorms.
|Precision figured mightily in those days, which may also have pre-dated
|white-out. Eliminating an error was a big deal. Now it's dead easy, and
|auto-correct has already fixed several errors in this message.
Since i now own a (used!!) smartphone i unfortunately have to live
with such things when doing my little bit of SMS messaging. It is
terrible. Ooften do i have to delete the word entirely to unlock
the screen. Ach! for the Asians who commit suicide because they
messed up a calligraphical painting.
It seems to me TUHS has lost its Sender: message header btw, which
longs for fixing as it is SHOULD in RFC 5322 in this ML case
(except for Warren himself, maybe).
--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 clemc at ccc.com Wed Nov 2 23:28:38 2022
From: clemc at ccc.com (Clem Cole)
Date: Wed, 2 Nov 2022 09:28:38 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAKzdPgzm8fkT5SeAFf+uaesp-oti2UndDdTPiB8MRU3CPebfRw@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<a811e443-473b-4abe-ab38-e97d8893d5d7@home.arpa>
<CAKzdPgzm8fkT5SeAFf+uaesp-oti2UndDdTPiB8MRU3CPebfRw@mail.gmail.com>
Message-ID: <CAC20D2MeDUf7OwUymSPZ7XE56ENn88XoCC8TMaxSvdJjhD4ADA@mail.gmail.com>
On Wed, Nov 2, 2022 at 3:13 AM Rob Pike <robpike at gmail.com> wrote
> bwk was one who could smash out the text faster than many. His having
> learned on a teletype, the keyboard would resound with the impact of his
> forceful keystrokes.
>
Funny, I remember the first time I got to use something other than an ASR33
or an ASR28 sometime time in the early 1970s I think. IIRC It was a Tek
4010, but the memory at the time of being amazed that I did not need so
much energy to push the keys and how quiet it was. Before then I had
equated computing with the feel, sounds, and machine oil smells of Teletype
products. That said, when the VT52 came out in the mid-70s the DEC keyboard
on it was far from the feel of the IBM Selectric III - which was considered
the 'touch typist standard'
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/b2779a43/attachment.htm>
From tuhs at tuhs.org Thu Nov 3 01:32:38 2022
From: tuhs at tuhs.org (Grant Taylor via TUHS)
Date: Wed, 2 Nov 2022 09:32:38 -0600
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
Message-ID: <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
On 11/2/22 12:07 AM, Noel Chiappa wrote:
> Step #0: make a list of what's there, and post it here. That's crucial input
> to any recommendation.
If at all possible, include the date and venue associated with the items.
I've found a few different papers by the same title that have been
different based on date and / or venue.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/9f67cebb/attachment.p7s>
From tuhs at tuhs.org Thu Nov 3 01:34:42 2022
From: tuhs at tuhs.org (Grant Taylor via TUHS)
Date: Wed, 2 Nov 2022 09:34:42 -0600
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
<CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
Message-ID: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
On 11/2/22 2:55 AM, Michael Casadevall wrote:
> I extensively researched this; there are infact copies of Pinball for
> 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s
Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium?
I've not watched the video yet (today).
> Pinball had problems relating to 64-bit FPU precision (and this can
> actually be reproduced by fiddling with FPU flags), but it did ship in
> Windows XP x64 Professional.
My understanding is that Windows XP x64 Professional is 64-bit x86 and
not Itanium.
There is also a chance that I'm misremembering things.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/1c8dfa9f/attachment.p7s>
From e5655f30a07f at ewoof.net Thu Nov 3 01:44:38 2022
From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 2 Nov 2022 15:44:38 +0000
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
<CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
<15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
Message-ID: <8e87638d-ad51-4ea3-8c6b-9955c9bac996@home.arpa>
On 2 Nov 2022 09:34 -0600, from tuhs at tuhs.org (Grant Taylor via TUHS):
>> Pinball had problems relating to 64-bit FPU precision (and this can
>> actually be reproduced by fiddling with FPU flags), but it did ship in
>> Windows XP x64 Professional.
>
> My understanding is that Windows XP x64 Professional is 64-bit x86 and not
> Itanium.
Per Wikipedia, "Windows XP 64-Bit Edition" was for Intel's Itanium
IA-64 architecture; whereas "Windows XP Professional x64 Edition" was
for AMD's x86-64 architecture.
https://en.wikipedia.org/wiki/Windows_XP#Editions
You've just got to love it when two wildly distinct, yet highly
similar, things are named almost, but not quite, the same.
--
🪶 Michael Kjörling ðŸ¡Â https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From jason-tuhs at shalott.net Thu Nov 3 05:01:29 2022
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Wed, 2 Nov 2022 12:01:29 -0700 (PDT)
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
Message-ID: <alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
> I’ve never heard anyone mention keyboard skills with the people of the
> CSRC - doesn’t anyone know?
https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23)
> History tells us that the guys who designed [UNIX] did their own typing
> into the machine. It seems to me that because of this, the main reason
> that UNIX enjoys/suffers from terse input and output is not through any
> intellectual design decisions made at some early stage but because the
> UNIX designers were just bad typists working on slow peripherals.
-Jason
From jpl.jpl at gmail.com Thu Nov 3 05:20:12 2022
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Wed, 2 Nov 2022 15:20:12 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
Message-ID: <CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
On Wed, Nov 2, 2022 at 3:02 PM <jason-tuhs at shalott.net> wrote:
>
> > I’ve never heard anyone mention keyboard skills with the people of the
> > CSRC - doesn’t anyone know?
>
>
> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23)
>
> > History tells us that the guys who designed [UNIX] did their own typing
> > into the machine. It seems to me that because of this, the main reason
> > that UNIX enjoys/suffers from terse input and output is not through any
> > intellectual design decisions made at some early stage but because the
> > UNIX designers were just bad typists working on slow peripherals.
>
>
> -Jason
>
Mostly rampant speculation on my part, but with 110 baud modems, 10
characters per second right?,
and added delays for carriage returns, it was the peripherals that
encouraged brevity. Code would be
viewed multiple times, but entered roughly once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/9ec9eda6/attachment.htm>
From ron at ronnatalie.com Thu Nov 3 06:35:10 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 2 Nov 2022 13:35:10 -0700
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <20221102122432.og3EI%steffen@sdaoden.eu>
References: <20221102122432.og3EI%steffen@sdaoden.eu>
Message-ID: <608A2539-B777-4243-B8A4-483B98297FAC@ronnatalie.com>
My elementary school teacher recommended to my mother that she buy me a typewriter and I took typing in summer school. Little did we know being able to type 60wpm would end up being.
> On Nov 2, 2022, at 05:24, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>
> Steffen Nurpmeso wrote in
> <20221102121352.MhcLw%steffen at sdaoden.eu>:
> |steve jenkin wrote in
> | <E212D205-B786-4441-A95B-B5F5546B5C6C at canb.auug.org.au>:
> | ...
> ||I’ve never heard anyone mention keyboard skills with the people of \
> ||the CSRC - doesn’t anyone know?
> |
> |What i personally find more fascinating (given that -- in the
> |right condition -- i type pretty fast even in total darkness but
> |darkest possible monitor brightness) is the multitaskability some
> |show, in respect to combination of mouse and keyboard (or even
> |dual-mouse if i remember a message of Rob Pike right). I once
> ...
>
> I once had a very small infrared / PS/2 keyboard with a track ball
> at the upper right corner, and the buttons on the upper left)
> where middle finger and forefinger only had to be moved a bit, but
> the heel of hand(s) could remain (only twisted a bit). That
> allowed for pretty good precision and speed. But i think it was
> still not that of Russ Cox and acme and external mouse/mice.
>
> --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 ron at ronnatalie.com Thu Nov 3 11:47:19 2022
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 03 Nov 2022 01:47:19 +0000
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
Message-ID: <emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
I’m not sure the model 33 required a carriage return delay. At 110
baud it had plenty of time to move the carriage. back.
Other printers (especially faster ones) weren’t so lucky, but the LA36
decwriter had a catchup mode to print the backlog after a return.
The LA120 was boustrophedonic so returns weren’t as much of an issue.
------ Original Message ------
>From "John P. Linderman" <jpl.jpl at gmail.com>
To jason-tuhs at shalott.net
Cc "steve jenkin" <sjenkin at canb.auug.org.au>; "TUHS" <tuhs at tuhs.org>
Date 11/2/2022 12:20:12 PM
Subject [TUHS] Re: Early Unix and Keyboard Skills
>
>
>On Wed, Nov 2, 2022 at 3:02 PM <jason-tuhs at shalott.net> wrote:
>>
>> > I’ve never heard anyone mention keyboard skills with the people of
>>the
>> > CSRC - doesn’t anyone know?
>>
>>
>>https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23)
>>
>> > History tells us that the guys who designed [UNIX] did their own
>>typing
>> > into the machine. It seems to me that because of this, the main
>>reason
>> > that UNIX enjoys/suffers from terse input and output is not through
>>any
>> > intellectual design decisions made at some early stage but because
>>the
>> > UNIX designers were just bad typists working on slow peripherals.
>>
>>
>> -Jason
>
>Mostly rampant speculation on my part, but with 110 baud modems, 10
>characters per second right?,
>and added delays for carriage returns, it was the peripherals that
>encouraged brevity. Code would be
>viewed multiple times, but entered roughly once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/5074fe25/attachment-0001.htm>
From tuhs at tuhs.org Thu Nov 3 11:48:36 2022
From: tuhs at tuhs.org (Warren Toomey via TUHS)
Date: Thu, 3 Nov 2022 11:48:36 +1000
Subject: [TUHS] [OT] Usenix Conference in Sydney - anybody else?
Message-ID: <Y2Md9PXes4Ygjb1P@minnie.tuhs.org>
Hi all, I'll be attending the Usenix SREcon22 Asia/Pacific Conference
which is being held in Sydney, Australia on the 7-9 December. Is anybody
else attending? If so, it'd be nice to catch up with some other TUHSers :-)
https://www.usenix.org/conference/srecon22apac/program
Cheers, Warren
From dave at horsfall.org Thu Nov 3 11:59:23 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 3 Nov 2022 12:59:23 +1100 (EST)
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
Message-ID: <alpine.BSF.2.21.9999.2211031255250.43868@aneurin.horsfall.org>
On Thu, 3 Nov 2022, Ronald Natalie wrote:
[...]
> Other printers (especially faster ones) weren’t so lucky, but the LA36
> decwriter had a catchup mode to print the backlog after a return.
Yep; the head went twice as fast to catch up. Wasn't there a method of
locking it into that mode, but then requiring flow control?
> The LA120 was boustrophedonic so returns weren’t as much of an issue.
ISTR that it required a driver to utilise that mode.
-- Dave
From clemc at ccc.com Thu Nov 3 13:01:29 2022
From: clemc at ccc.com (Clem Cole)
Date: Wed, 2 Nov 2022 23:01:29 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
Message-ID: <CAC20D2OEgK_hdvug9LxO4X=jLnCtRp44Ttj7hWP85p5eebO_sQ@mail.gmail.com>
The 33 and 28 needed at least two null chars after the <CR> or it would
lose chars as there was no buffering. The Unix driver has the CR delay
modes to support it. It’s UART as it were was mechanical and a real work
of art. I remember spending a few hours trying to figure out how it
worked.
As for the LA120 yeah you really needed to use real flow control which
could be a problem on DL11s and DZs ports. SW flow was less than
prefect. However, the Able version of the DH supported flow in hardware
(RTS/CTS style) so you could set them to interface with the host at 960cps
and then print as fast as possible swiping back and forth on the paper as
the local microprocessor in the decwritter buffered everything.
On Wed, Nov 2, 2022 at 9:48 PM Ronald Natalie <ron at ronnatalie.com> wrote:
> I’m not sure the model 33 required a carriage return delay. At 110 baud
> it had plenty of time to move the carriage. back.
> Other printers (especially faster ones) weren’t so lucky, but the LA36
> decwriter had a catchup mode to print the backlog after a return.
> The LA120 was boustrophedonic so returns weren’t as much of an issue.
>
> ------ Original Message ------
> From "John P. Linderman" <jpl.jpl at gmail.com>
> To jason-tuhs at shalott.net
> Cc "steve jenkin" <sjenkin at canb.auug.org.au>; "TUHS" <tuhs at tuhs.org>
> Date 11/2/2022 12:20:12 PM
> Subject [TUHS] Re: Early Unix and Keyboard Skills
>
>
>
> On Wed, Nov 2, 2022 at 3:02 PM <jason-tuhs at shalott.net> wrote:
>
>>
>> > I’ve never heard anyone mention keyboard skills with the people of the
>> > CSRC - doesn’t anyone know?
>>
>>
>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23)
>>
>> > History tells us that the guys who designed [UNIX] did their own typing
>> > into the machine. It seems to me that because of this, the main reason
>> > that UNIX enjoys/suffers from terse input and output is not through any
>> > intellectual design decisions made at some early stage but because the
>> > UNIX designers were just bad typists working on slow peripherals.
>>
>>
>> -Jason
>>
>
> Mostly rampant speculation on my part, but with 110 baud modems, 10
> characters per second right?,
> and added delays for carriage returns, it was the peripherals that
> encouraged brevity. Code would be
> viewed multiple times, but entered roughly once.
>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221102/39754695/attachment.htm>
From paul.winalski at gmail.com Fri Nov 4 01:17:38 2022
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 3 Nov 2022 11:17:38 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
Message-ID: <CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
On 11/2/22, Ronald Natalie <ron at ronnatalie.com> wrote:
> I’m not sure the model 33 required a carriage return delay. At 110
> baud it had plenty of time to move the carriage. back.
> Other printers (especially faster ones) weren’t so lucky, but the LA36
> decwriter had a catchup mode to print the backlog after a return.
> The LA120 was boustrophedonic so returns weren’t as much of an issue.
The model 33 had a very fast and powerful carriage return mechanism,
good for cracking walnuts, but it took up to two character times to
complete a CR. If you didn't send two non-printing characters (such
as NUL), you risked having your character struck somewhere in the
middle of the line.
The LA36 DECwriter had a rather slow carriage return. It would buffer
characters while a return was in progress and then print the buffered
characters at 60 characters/second, slowing down to the normal 30 cps
when caught up. There was a company that sold modified LA36
controller boards that were hacked so that the LA36 always thought it
was in catch-up mode and could thus be run at double speed, provided
that you inserted NUL padding after a CR. But that greatly reduced
the longevity of the print mechanism.
-Paul W.
From clemc at ccc.com Fri Nov 4 02:18:22 2022
From: clemc at ccc.com (Clem Cole)
Date: Thu, 3 Nov 2022 12:18:22 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
<CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
Message-ID: <CAC20D2PC=k-OO7wNFC0sawgQ0z4CNwESzvVREe-6P8Rspt6quA@mail.gmail.com>
On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski <paul.winalski at gmail.com>
wrote:
> The LA36 DECwriter had a rather slow carriage return. It would buffer
> characters while a return was in progress and then print the buffered
> characters at 60 characters/second, slowing down to the normal 30 cps
> when caught up.
>
The key point here is that with the DEC Writer (LA36) DEC started to split
the print speed (*in cps*) from the line interface speed (*in baud* as it
was larger than an often character as it would have at least one start bit,
one or more stop bits, and maybe a parity bit too). Herein also lies
another problem, the mechanical interface, be it how fast the carriage
moved, or the head was positioned, etc, could be much longer than the
single character transfer time. As Paul mentioned on some
mechanical devices without any buffering, the print might be random as the
carriage moved the head.
Teletype made an amazing mechanical device that had a minimum amount of
electronics in it. By the time of the LA36, you start to see the
microprocessor revolution and the use of cheap transistors to replace
mechanical things to make faster/better devices with new features (like
buffering and being able to have different speeds for data transfer and
printing). But you also start to see the distinction between the
mechanics (the keyboard/printer) and things like the communications scheme
become even more obvious and terminology starts to be used to address the
specific part of the problem.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/eaa0eb09/attachment.htm>
From cowan at ccil.org Fri Nov 4 03:02:31 2022
From: cowan at ccil.org (John Cowan)
Date: Thu, 3 Nov 2022 13:02:31 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
<CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
Message-ID: <CAD2gp_Toj2HMwg1gGkAvWkKTgDMiK8O2Hj4KAWRqoDPp5yzxhg@mail.gmail.com>
On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski <paul.winalski at gmail.com>
wrote:
> The model 33 had a very fast and powerful carriage return mechanism,
> good for cracking walnuts, but it took up to two character times to
> complete a CR. If you didn't send two non-printing characters (such
> as NUL), you risked having your character struck somewhere in the
> middle of the line.
>
That was not my experience. I cut my teeth on a PDP-8/M running OS/8 with
an ASR-33 attached and directly programming the KE8E controller without any
additional time-delay loops. Outputting additional NULs would have screwed
up binary paper tape output, so that can't have been how it was done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/17e31929/attachment.htm>
From rdm at cfcl.com Fri Nov 4 05:36:45 2022
From: rdm at cfcl.com (Rich Morin)
Date: Thu, 3 Nov 2022 12:36:45 -0700
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAD2gp_Toj2HMwg1gGkAvWkKTgDMiK8O2Hj4KAWRqoDPp5yzxhg@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
<CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
<CAD2gp_Toj2HMwg1gGkAvWkKTgDMiK8O2Hj4KAWRqoDPp5yzxhg@mail.gmail.com>
Message-ID: <188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com>
> On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski <paul.winalski at gmail.com> wrote:
>
> The model 33 had a very fast and powerful carriage return mechanism,
> good for cracking walnuts ...
In 1968, San Francisco State College (now yclept "University") set up a "computer lab", based on a few IBM 2741 terminals. These were hooked by leased lines to Stanford's Wylbur system and allowed us to do line-based editing, interactive Lisp, etc.
Anyway, the terminals were based on the I/O Selectric, and the ball impacts were powered by a spinning bar with pretty much infinite torque. One day, an insufficiently cautious TA got her long, straight hair wound onto the bar. Each character that was printed pulled her head closer to the terminal.
Fortunately, someone hit the OFF switch in time to avoid bloodshed. Then, we were able to carefully unwind her hair and free her from the terminal. IIRC, we didn't even have to cut any of her hair in the process...
-r
From dds at aueb.gr Fri Nov 4 05:43:44 2022
From: dds at aueb.gr (Diomidis Spinellis)
Date: Thu, 3 Nov 2022 21:43:44 +0200
Subject: [TUHS] vi in cooked mode?
Message-ID: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
I remember being told back in the 1980s that vi would set the terminal
to "cooked mode" when vi was in "insert mode", so as to reduce expensive
context switching for each character typed. Only vi's "command mode"
would set the terminal to "raw mode" so as to provide immediate feedback
on each (command) character typed. This would be a clever system
performance optimization, and would also explain designing vi around
distinct insert and command modes.
However, I can't find such evidence even as far back as BSD 1. It seems
that in insert mode ESC was processed like any other character.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vops.c#L507
Cooked mode was only entered when scrolling in order to receive interrupts.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vadjust.c#L180
Also, for this scheme to work ESC would need to be mapped to an
interrupt key, so as to allow exiting the cooked mode through the
corresponding signal handler. Again, grepping for ESC, did not show me
any such code.
I also remember being told that this optimization was what allowed
twenty students to concurrently perform interactive editing on a VAX
11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not provided
to students because it was always operating in raw mode.
Was I misled? Was there perhaps a hacked version of vi that worked in
this way?
-Diomidis
From sauer at technologists.com Fri Nov 4 06:01:04 2022
From: sauer at technologists.com (Charles H Sauer (he/him))
Date: Thu, 3 Nov 2022 15:01:04 -0500
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<alpine.LRH.2.23.453.2211021152530.23126@waffle.shalott.net>
<CAC0cEp9t2dG2+V8o_WFwiNNz2Ro0ifC8Za-PBdYvrBXAuqGgcg@mail.gmail.com>
<emc238c437-aa92-43b8-bb56-2eac700fab91@6b571117.com>
<CABH=_VRiSt6kCrFbOBOkxxsN=bEN-6wf5E6r_gX22Mc0dczz1w@mail.gmail.com>
<CAD2gp_Toj2HMwg1gGkAvWkKTgDMiK8O2Hj4KAWRqoDPp5yzxhg@mail.gmail.com>
<188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com>
Message-ID: <3d93609e-973f-38af-9557-fd388e911d09@technologists.com>
On 11/3/2022 2:36 PM, Rich Morin wrote:
>> On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski <paul.winalski at gmail.com> wrote:
>>
>> The model 33 had a very fast and powerful carriage return mechanism,
>> good for cracking walnuts ...
>
> In 1968, San Francisco State College (now yclept "University") set up a "computer lab", based on a few IBM 2741 terminals. These were hooked by leased lines to Stanford's Wylbur system and allowed us to do line-based editing, interactive Lisp, etc.
>
> Anyway, the terminals were based on the I/O Selectric, and the ball impacts were powered by a spinning bar with pretty much infinite torque. One day, an insufficiently cautious TA got her long, straight hair wound onto the bar. Each character that was printed pulled her head closer to the terminal.
>
> Fortunately, someone hit the OFF switch in time to avoid bloodshed. Then, we were able to carefully unwind her hair and free her from the terminal. IIRC, we didn't even have to cut any of her hair in the process...
I was nominally a music major at S.F. State at that time, in the midst
of my self-imposed avoidance of computers, that started with disdain
from my initial exposure to Fortran on IBM 1620 at U of MO-Columbia in
1964 and ended with semi-abandoning my rock and roll pursuits in early
1971 and starting C.S. studies at UT-Austin. I also took math courses at
S.F. State in 1968 but was unaware of the above cited "lab".
Regarding keyboarding skills, I took touch-typing in summer school after
9th grade, got a SCM portable electric typewriter that I might still
have, and am still grateful for QWERTY facility that has served me ever
since, on card punch, 2741, 3270, Displaywriter, and more obscure and
more modern keyboards.
CHS
--
voice: +1.512.784.7526 e-mail: sauer at technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Twitter: CharlesHSauer
From jnc at mercury.lcs.mit.edu Fri Nov 4 06:17:31 2022
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 3 Nov 2022 16:17:31 -0400 (EDT)
Subject: [TUHS] vi in cooked mode?
Message-ID: <20221103201731.7380A18C09C@mercury.lcs.mit.edu>
> From: Diomidis Spinellis
> I remember being told back in the 1980s that vi would set the terminal
> to "cooked mode" when vi was in "insert mode", so as to reduce expensive
> context switching for each character typed.
> ...
> However, I can't find such evidence even as far back as BSD 1.
Maybe you're thinking of Multics Emacs, which had such a capability:
https://multicians.org/mepap.html
Noel
From clemc at ccc.com Fri Nov 4 06:26:03 2022
From: clemc at ccc.com (Clem Cole)
Date: Thu, 3 Nov 2022 16:26:03 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
Message-ID: <CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis <dds at aueb.gr> wrote:
> Was I misled? Was there perhaps a hacked version of vi that worked in this
> way?
>
I think you may be mixing a few stories ... and features ...
v6 vs v7 PDP-11 vs Vax much less vi vs emacs.
Some thoughts ...
1.) Emacs came from CMU and only a few years later after the Vax had was
stable (post 4.1BSD)
2.) emacs was not so much prohibited as it was slow, it needed megabytes of
memory -- that was limit.
3.) By the time emacs comes on the scene, workstations are showing up, so
you did not have 20 students on a vax to UCB.
4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY
was using V7 using CBREAK (1/2 cooked) which still allows canonicalization
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/b930700d/attachment.htm>
From clemc at ccc.com Fri Nov 4 06:27:45 2022
From: clemc at ccc.com (Clem Cole)
Date: Thu, 3 Nov 2022 16:27:45 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
Message-ID: <CAC20D2PNWMh0SQ8THoVCGpNjRmWqzO6=6QH6EZCKmqJZ4KRcTg@mail.gmail.com>
I should say -- UNIX (Gosling) EMACS came from CMU ....
á§
On Thu, Nov 3, 2022 at 4:26 PM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis <dds at aueb.gr> wrote:
>
>> Was I misled? Was there perhaps a hacked version of vi that worked in this
>> way?
>>
> I think you may be mixing a few stories ... and features ...
>
>
> v6 vs v7 PDP-11 vs Vax much less vi vs emacs.
> Some thoughts ...
>
> 1.) Emacs came from CMU and only a few years later after the Vax had was
> stable (post 4.1BSD)
> 2.) emacs was not so much prohibited as it was slow, it needed megabytes
> of memory -- that was limit.
> 3.) By the time emacs comes on the scene, workstations are showing up, so
> you did not have 20 students on a vax to UCB.
> 4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY
> was using V7 using CBREAK (1/2 cooked) which still allows canonicalization
>
> á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/e696a545/attachment.htm>
From imp at bsdimp.com Fri Nov 4 06:55:20 2022
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 3 Nov 2022 14:55:20 -0600
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
Message-ID: <CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
On Thu, Nov 3, 2022, 2:28 PM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis <dds at aueb.gr> wrote:
>
>> Was I misled? Was there perhaps a hacked version of vi that worked in this
>> way?
>>
> I think you may be mixing a few stories ... and features ...
>
>
> v6 vs v7 PDP-11 vs Vax much less vi vs emacs.
> Some thoughts ...
>
> 1.) Emacs came from CMU and only a few years later after the Vax had was
> stable (post 4.1BSD)
>
There were a diversity of emacs clones for unix as well...
2.) emacs was not so much prohibited as it was slow, it needed megabytes of
> memory -- that was limit.
>
The VAX 11/750 with 1MB we had at nmt ran emacs, but not gnu emacs. It was
something special off the internet that was less featureful so took less
memory. We had to have it since EMACS was popular on the DECsystem 20s we
had.. The Vax could handle 15 students on each of the 15 terminals
connected to it plus 5 or so coming in via telnet doing emacs compilein
100-500 line CS programs without being too insanely bogged down... < 10 and
you didn't notice.
3.) By the time emacs comes on the scene, workstations are showing up, so
> you did not have 20 students on a vax to UCB.
>
Emacs of different flavors predated workstations by a few years though. GNU
Emacs 18 dates to when VAXstations, Suns and others were shipping on
volume.
4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY
> was using V7 using CBREAK (1/2 cooked) which still allows canonicalization
>
All the oddball quirks in tty behavior can be dated to the early 80s to
optimize somebody's use case...
Warner
> á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/43d45bec/attachment.htm>
From clemc at ccc.com Fri Nov 4 07:34:59 2022
From: clemc at ccc.com (Clem Cole)
Date: Thu, 3 Nov 2022 17:34:59 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
Message-ID: <CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
On Thu, Nov 3, 2022 at 4:55 PM Warner Losh <imp at bsdimp.com> wrote:
>
> There were a diversity of emacs clones for unix as well...
>
Absolutely...
But the first in wide used in the UNIX world was Gosling EMACS which
appeared outside of CMU soon after UCB dropped 4.1 in early 1980, probably
the next was Zimmerman (*a.k.a.* CCA) EMACS, then GNU hacked Gosling's
version (that strange trip has been discussed elsewhere and I'll not add it
here). Zimmer's version was 'truer' to the original MIT/PDP-10 version
from ITS than Gosling but Steve had built it when he worked for CCA so it
was licensed (which we had a Masscomp and made available to our
customers). To my knowledge Gosling's version never fit on any PDP-11 nor
Gnu, I'm not sure if Steve ever got his to work on a split I/D [Noel might
know]. I do know some of my MIT friends used to grouse about the
differences between CMU EMACS and ITS EMACS. That said, there was also at
least one microemacs which was originally for CPM and MSDOS IIRC, that got
moved a number of the UNIX boxes which may be what you are referring. I
seem to remember that was released on netnews and was a lot smaller. I
never messed with it, because by then I had the address space of and I
could run Gosling or Zimmerman.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/0727b71f/attachment.htm>
From stuff at riddermarkfarm.ca Fri Nov 4 07:51:44 2022
From: stuff at riddermarkfarm.ca (Stuff Received)
Date: Thu, 3 Nov 2022 17:51:44 -0400
Subject: [TUHS] Early Unix and Keyboard Skills
In-Reply-To: <CAKzdPgzm8fkT5SeAFf+uaesp-oti2UndDdTPiB8MRU3CPebfRw@mail.gmail.com>
References: <E212D205-B786-4441-A95B-B5F5546B5C6C@canb.auug.org.au>
<a811e443-473b-4abe-ab38-e97d8893d5d7@home.arpa>
<CAKzdPgzm8fkT5SeAFf+uaesp-oti2UndDdTPiB8MRU3CPebfRw@mail.gmail.com>
Message-ID: <a5b9b6c4-de7d-3e7d-6c40-d1b3480fceef@riddermarkfarm.ca>
On 2022-11-02 03:11, Rob Pike wrote:
> Neither ken nor dmr were impressive typists. In fact few programmers
> were then, at least of my acquaintance.
>
> In the 1970s Bell Labs created the Getset - think of it as an early
> wired smartphone, or a Minitel, with a little screen and keyboard. It
> cost quite a bit but was a cool gadget so the executives all got one.
> But, in fascinating contrast to the Blackberry a generation later, no
> one would touch it - literally - because it had a keyboard, and
> keyboards were for (female) secretaries, not (male) executives. The
> product, although well ahead of its time, was a complete failure due
> to the cultural bias then.
>
> There may be a good sociology paper in there somewhere.
I remember the dep't administrators having colour terminals connected to
the mainframe, and all they did was look up the occasional telephone
number, whilst the "secretaries" (as they were called then) being given
b&w terminals for work.
> I'm not saying K&D shared this blinkered view, not at all, just that
> typing skills were not de facto back then. Some of the folks were even
> two-finger jabbers. I was a little younger and a faster typist than
> most of the others, and I am not a good typist by any modern standard.
>
> bwk was one who could smash out the text faster than many. His having
> learned on a teletype, the keyboard would resound with the impact of
> his forceful keystrokes.
I learnt in high school on a manual typewriter so I can appreciate
that. (Learning on a manual really builds up the muscles on one's
little fingers. #6-)
N.
>
> -rob
>
> [...]
From imp at bsdimp.com Fri Nov 4 08:28:23 2022
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 3 Nov 2022 16:28:23 -0600
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
<CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
Message-ID: <CANCZdfrZL5Vfx9NKMwJQFwT7=usTsMOrME+SvdPS70dC8wPS_g@mail.gmail.com>
On Thu, Nov 3, 2022 at 3:35 PM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Thu, Nov 3, 2022 at 4:55 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>> There were a diversity of emacs clones for unix as well...
>>
> Absolutely...
>
> But the first in wide used in the UNIX world was Gosling EMACS which
> appeared outside of CMU soon after UCB dropped 4.1 in early 1980, probably
> the next was Zimmerman (*a.k.a.* CCA) EMACS, then GNU hacked Gosling's
> version (that strange trip has been discussed elsewhere and I'll not add it
> here). Zimmer's version was 'truer' to the original MIT/PDP-10 version
> from ITS than Gosling but Steve had built it when he worked for CCA so it
> was licensed (which we had a Masscomp and made available to our
> customers). To my knowledge Gosling's version never fit on any PDP-11 nor
> Gnu, I'm not sure if Steve ever got his to work on a split I/D [Noel might
> know]. I do know some of my MIT friends used to grouse about the
> differences between CMU EMACS and ITS EMACS. That said, there was also at
> least one microemacs which was originally for CPM and MSDOS IIRC, that got
> moved a number of the UNIX boxes which may be what you are referring. I
> seem to remember that was released on netnews and was a lot smaller. I
> never messed with it, because by then I had the address space of and I
> could run Gosling or Zimmerman.
>
IIRC, it was one of the microemacs from netnews (there were a few different
ones) that had been back-ported to BSD (or maybe the early ones just worked
there). It was funky, but it worked with the HP terminals that were
attached to the VAX and was somewhat less that the other, larger emacs in
terms of what it could do beyond just editing.
Warner
> á§sadf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/257380e6/attachment-0001.htm>
From ron at ronnatalie.com Fri Nov 4 08:52:38 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 03 Nov 2022 22:52:38 +0000
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CANCZdfrZL5Vfx9NKMwJQFwT7=usTsMOrME+SvdPS70dC8wPS_g@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
<CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
<CANCZdfrZL5Vfx9NKMwJQFwT7=usTsMOrME+SvdPS70dC8wPS_g@mail.gmail.com>
Message-ID: <eme1e95a05-f005-4af3-9570-24ed8806a324@820bff6f.com>
We used Montgomery’s EMACS and then JOVE on the PDP-11 UNIXes. I did
a short stint working at Unipress on Gosling’s Emacs while their lead
developer was off on another project (I was between jobs at the time).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221103/db2f72aa/attachment.htm>
From lars at nocrew.org Fri Nov 4 16:43:09 2022
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 04 Nov 2022 06:43:09 +0000
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
(Clem Cole's message of "Thu, 3 Nov 2022 17:34:59 -0400")
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
<CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
Message-ID: <7wv8nv1apu.fsf@junk.nocrew.org>
Clem Cole wrote:
> probably the next was Zimmerman (a.k.a. CCA) EMACS, then GNU hacked
> Gosling's version (that strange trip has been discussed elsewhere and
> I'll not add it here). Zimmer's version was 'truer' to the original
> MIT/PDP-10 version from ITS than Gosling but Steve had built it when
> he worked for CCA so it was licensed (which we had a Masscomp and made
> available to our customers).
I recently found a copy of CCA Emacs. It's from 1983 and does not yet
have the Elisp extension language. CCA was bought by Rocket Software,
so they own it now. I asked permission to put it online, but
unfortunately they said no.
Ron Natalie wrote:
> We used Montgomery’s EMACS and then JOVE on the PDP-11 UNIXes.
Montgomery kindly agreed to putting a copy of his editor here, and wrote
about its history:
https://github.com/larsbrinkhoff/emacs-history/tree/sources/ana-3.lcs.mit.edu/%7Ejnc/tech/unix/emacs
https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery%20Emacs%20History.txt
From crossd at gmail.com Sat Nov 5 01:18:15 2022
From: crossd at gmail.com (Dan Cross)
Date: Fri, 4 Nov 2022 11:18:15 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <7wv8nv1apu.fsf@junk.nocrew.org>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
<CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
<7wv8nv1apu.fsf@junk.nocrew.org>
Message-ID: <CAEoi9W40hLtt_mWzZPosBdSpKSum8FAam2Ns40-pPuzBHS3zMA@mail.gmail.com>
On Fri, Nov 4, 2022 at 2:43 AM Lars Brinkhoff <lars at nocrew.org> wrote:
> Clem Cole wrote:
> > probably the next was Zimmerman (a.k.a. CCA) EMACS, then GNU hacked
> > Gosling's version (that strange trip has been discussed elsewhere and
> > I'll not add it here). Zimmer's version was 'truer' to the original
> > MIT/PDP-10 version from ITS than Gosling but Steve had built it when
> > he worked for CCA so it was licensed (which we had a Masscomp and made
> > available to our customers).
>
> I recently found a copy of CCA Emacs. It's from 1983 and does not yet
> have the Elisp extension language. CCA was bought by Rocket Software,
> so they own it now. I asked permission to put it online, but
> unfortunately they said no.
Out of curiosity, did they say why? It's hard to imagine it holds much
commercial value now. Was it some kind of IP ownership thing?
- Dan C.
From lars at nocrew.org Sat Nov 5 03:54:07 2022
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 04 Nov 2022 17:54:07 +0000
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAEoi9W40hLtt_mWzZPosBdSpKSum8FAam2Ns40-pPuzBHS3zMA@mail.gmail.com>
(Dan Cross's message of "Fri, 4 Nov 2022 11:18:15 -0400")
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<CANCZdfp3B0fU0Ada4-=DbUh7z+_YaH+qZDiF6f4CfE2NfM+HFA@mail.gmail.com>
<CAC20D2MMLxOBiyeV_vP_ND5GnmcTG1f5TRrStoK=0eoWyMPmyA@mail.gmail.com>
<7wv8nv1apu.fsf@junk.nocrew.org>
<CAEoi9W40hLtt_mWzZPosBdSpKSum8FAam2Ns40-pPuzBHS3zMA@mail.gmail.com>
Message-ID: <7w7d0a1u80.fsf@junk.nocrew.org>
Dan Cross wrote:
>> CCA was bought by Rocket Software, so they own [CCA Emacs] now. I
>> asked permission to put it online, but unfortunately they said no.
> Out of curiosity, did they say why? It's hard to imagine it holds much
> commercial value now. Was it some kind of IP ownership thing?
I aked through an intermediary who had an inside connection at Rocket
Software, so I don't know why.
From ron at ronnatalie.com Sat Nov 5 04:33:34 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 04 Nov 2022 18:33:34 +0000
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
Message-ID: <embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
>
>v6 vs v7 PDP-11 vs Vax much less vi vs emacs.
>
Amusingly, as weith many of us, I got my start with "ed." I never
actually learned vi. By the time I was ready to move up to screen
editors, the emacs-ish things were available to me.
I did a small stint using INed (Rand-editor variant) at one job.
My employees always found it amusing that if I was stuck on a machine
that didn't have some emacs-ish thing, I just used ed. They marvelled
at my ability to complex substitutions with the s/// regular
expressions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221104/e29f695a/attachment.htm>
From mah at mhorton.net Sat Nov 5 08:13:17 2022
From: mah at mhorton.net (Mary Ann Horton)
Date: Fri, 4 Nov 2022 15:13:17 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
Message-ID: <53541ab4-6cec-59b9-075b-bfb9bc949f94@mhorton.net>
I don't think vi would work correctly in cooked mode. It has to redraw
(some of) the screen, inserting a character on each keystroke, and
repainting the rest of the line.
As Clem points out, in V6 it used raw, in V7 it used cbreak, which is
"half cooked" and allows interrupts.
It certainly affected performance when lots of students were using it,
especially if they all had their own copies of the binary, which was
typical on non-BSD systems. What really helped there was ensuring that
the official vi binary was in /usr/ucb (or another standard directory)
so that only one copy of the instruction space would be in memory,
shared among all the users.
Bell Labs, which typically ran internal versions of UNIX that didn't
have vi, created the exptools package with most of the Berkeley tools
and certain others, such as Montgomery's EMACS. This was partly to
address the performance issue, and to get people to stop installing
their own personal copies of everything.
Thanks,
/Mary Ann Horton/ (she/her/ma'am)
maryannhorton.com <https://maryannhorton.com>
"This is a great book" - Monica Helms
"Brave and Important" - Laura L. Engel
     Available on Amazon and bn.com!
<https://www.amazon.com/Trailblazer-Lighting-Transgender-Equality-Corporate-ebook/dp/B0B8F2BR9B>
On 11/3/22 12:43, Diomidis Spinellis wrote:
> I remember being told back in the 1980s that vi would set the terminal
> to "cooked mode" when vi was in "insert mode", so as to reduce
> expensive context switching for each character typed. Only vi's
> "command mode" would set the terminal to "raw mode" so as to provide
> immediate feedback on each (command) character typed. This would be a
> clever system performance optimization, and would also explain
> designing vi around distinct insert and command modes.
>
> However, I can't find such evidence even as far back as BSD 1. It
> seems that in insert mode ESC was processed like any other character.
>
> https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vops.c#L507
>
>
> Cooked mode was only entered when scrolling in order to receive
> interrupts.
>
> https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vadjust.c#L180
>
>
> Also, for this scheme to work ESC would need to be mapped to an
> interrupt key, so as to allow exiting the cooked mode through the
> corresponding signal handler. Again, grepping for ESC, did not show
> me any such code.
>
> I also remember being told that this optimization was what allowed
> twenty students to concurrently perform interactive editing on a VAX
> 11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not
> provided to students because it was always operating in raw mode.
>
> Was I misled? Was there perhaps a hacked version of vi that worked in
> this way?
>
> -Diomidis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221104/522f77d5/attachment.htm>
From tytso at mit.edu Sat Nov 5 09:42:15 2022
From: tytso at mit.edu (Theodore Ts'o)
Date: Fri, 4 Nov 2022 19:42:15 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
Message-ID: <Y2WjV/RuqqoW7OFL@mit.edu>
On Fri, Nov 04, 2022 at 06:33:34PM +0000, Ron Natalie wrote:
> >
> > v6 vs v7 PDP-11 vs Vax much less vi vs emacs.
>
> Amusingly, as weith many of us, I got my start with "ed." I never actually
> learned vi. By the time I was ready to move up to screen editors, the
> emacs-ish things were available to me.
Yeah, same here, although my start was with the editor that came with
the PDP-8 disk operating system (using an ASR-35), the PDP-15's
foreground/background system (using a KSR-33), and the PDP-11's RT-11
running under TSX-plus (using VT-100's and DECwriter for the
console).
So when I finally got a chance to use Unix when I got to college,
/bin/ed was so similar to the line oriented editors I had used on the
various Digital systems I had a chance to use while growing up and in
high school, I never bothered to use vi. It was either ed or emacs,
depending on how loaded the time-sharing systems I was using my
freshman year. Of course, once I had a chance to use a Vaxstation or
the IBM PC/RT all to myself, I jumped over to emacs and never looked
back --- except when I was recovering a system in single user mode, of
course.
- Ted
From dave at horsfall.org Sat Nov 5 10:45:26 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 5 Nov 2022 11:45:26 +1100 (EST)
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <Y2WjV/RuqqoW7OFL@mit.edu>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
Message-ID: <alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
On Fri, 4 Nov 2022, Theodore Ts'o wrote:
> Yeah, same here, although my start was with the editor that came with
> the PDP-8 disk operating system (using an ASR-35), the PDP-15's
> foreground/background system (using a KSR-33), and the PDP-11's RT-11
> running under TSX-plus (using VT-100's and DECwriter for the console).
I started off with TECO on RT-11; talk about cryptic...
> So when I finally got a chance to use Unix when I got to college,
> /bin/ed was so similar to the line oriented editors I had used on the
> various Digital systems I had a chance to use while growing up and in
> high school, I never bothered to use vi. It was either ed or emacs,
> depending on how loaded the time-sharing systems I was using in my
> freshman year.
Shortly after I switched to "ed" on the 11/40 someone brought out "em"
(editor for mortals) which was sort of a screen editor: I recall saying
"what a stupid command name" as it was only a fumble away from "rm" :-(
> Of course, once I had a chance to use a Vaxstation or the IBM PC/RT all
> to myself, I jumped over to emacs and never looked back --- except when
> I was recovering a system in single user mode, of course.
A boss of mine insisted that everyone had to learned "ed", because after a
system crash it might be the only editor available; that, or having to
dial in over a slow modem.
-- Dave
From lm at mcvoy.com Sat Nov 5 11:02:47 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 4 Nov 2022 18:02:47 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
Message-ID: <20221105010247.GG29525@mcvoy.com>
On Sat, Nov 05, 2022 at 11:45:26AM +1100, Dave Horsfall wrote:
> A boss of mine insisted that everyone had to learned "ed", because after a
> system crash it might be the only editor available; that, or having to
> dial in over a slow modem.
Same. Though vi in ex mode was also good.
I also got a little corrupted by whatever editor came with BDS C, my
.exrc looks like this:
map # :.,$
map @ :1,.
Those came from that editor, # says do whatever to the end of the file,
@ says do whatever from the top of the file to here.
map , !}fmt
This came from Udi Manber, , runs your paragraph through fmt
map!
I set shiftwidth to 4 spaces because when you have code like
if ((this big thing == that big thing) && (this other big thing) &&
(yet another big thing)) {
I use 4 spaces for what I call the continuation line. I used ^A to write
that example, why I don't like ^T is lost to me.
And yeah, I paren stuff that doesn't need to have parens, it just makes
the code more obvious.
set redraw ai aw terse
redraw I think is left over from modems, autoident because duh,
autowrite because who doesn't hack, hack, hack, ^Z, !cc? terse
because I'm not a newbie.
set sections=uhshSHNH
set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH
Troff.
set ts=8 sw=4
set shell=/bin/sh
set showmode
set textwidth=1000
set vb
Etc.
I've been carrying around that .exrc for around 40 years. Sheesh, I'm old.
From bakul at iitbombay.org Sat Nov 5 11:25:03 2022
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 4 Nov 2022 18:25:03 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <20221105010247.GG29525@mcvoy.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
Message-ID: <F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> I also got a little corrupted by whatever editor came with BDS C
I think that was wordstar. I had to retrain my fingers when I
switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
Now I stick to nvi & acme. And cat for small programs/files.
From bakul at iitbombay.org Sat Nov 5 11:25:03 2022
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 4 Nov 2022 18:25:03 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <20221105010247.GG29525@mcvoy.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
Message-ID: <F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> I also got a little corrupted by whatever editor came with BDS C
I think that was wordstar. I had to retrain my fingers when I
switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
Now I stick to nvi & acme. And cat for small programs/files.
From lm at mcvoy.com Sat Nov 5 11:40:29 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 4 Nov 2022 18:40:29 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
<F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
Message-ID: <20221105014029.GH29525@mcvoy.com>
On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote:
> On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > I also got a little corrupted by whatever editor came with BDS C
>
> I think that was wordstar. I had to retrain my fingers when I
> switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
> teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
> Now I stick to nvi & acme. And cat for small programs/files.
I used wordstar but I think BDS C had their own thing. Wordstar
was different.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From rich.salz at gmail.com Sat Nov 5 12:31:19 2022
From: rich.salz at gmail.com (Rich Salz)
Date: Fri, 4 Nov 2022 22:31:19 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <20221105014029.GH29525@mcvoy.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
<F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
<20221105014029.GH29525@mcvoy.com>
Message-ID: <CAFH29tpWDn9yG9=vqM2eLkqYQ7h5BuFNsOv1iUjooLAw-Jpb_Q@mail.gmail.com>
I don't recall BDS C having an editor but I could be wrong. They pushed
Mark of the Unicorn's MINCE (mince is not complete emacs) and scribble, a
scribe mini-clone. BDS was a one man shop, it stood for brain-damaged
software.
On Fri, Nov 4, 2022, 9:40 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote:
> > On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > I also got a little corrupted by whatever editor came with BDS C
> >
> > I think that was wordstar. I had to retrain my fingers when I
> > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
> > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
> > Now I stick to nvi & acme. And cat for small programs/files.
>
> I used wordstar but I think BDS C had their own thing. Wordstar
> was different.
> --
> ---
> Larry McVoy Retired to fishing
> http://www.mcvoy.com/lm/boat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221104/5037e690/attachment.htm>
From bakul at iitbombay.org Sat Nov 5 13:44:22 2022
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 4 Nov 2022 20:44:22 -0700
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <CAFH29tpWDn9yG9=vqM2eLkqYQ7h5BuFNsOv1iUjooLAw-Jpb_Q@mail.gmail.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
<F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
<20221105014029.GH29525@mcvoy.com>
<CAFH29tpWDn9yG9=vqM2eLkqYQ7h5BuFNsOv1iUjooLAw-Jpb_Q@mail.gmail.com>
Message-ID: <D378B970-00A7-4881-9D4F-CD643F52FA12@iitbombay.org>
Wordstar came out in 1978, BDS C in 1979. MINCE was written in BDS C
so it probably didn't come with BDS C (but BDS C came with MINCE)!
In 1981/82 I ported Gosling Emacs to the Fortune box. It was slow
as molasses. My memory is that was due to it using bitfields, for
which our C compiler produced pretty bad code. But I didn't really
investigate it in any detail. In contrast vi & e (Rand editor as
further hacked on by Dave Yost) were so much better, especially on
a 60 line Ann Arbor Ambassador.
> On Nov 4, 2022, at 7:31 PM, Rich Salz <rich.salz at gmail.com> wrote:
>
> I don't recall BDS C having an editor but I could be wrong. They pushed Mark of the Unicorn's MINCE (mince is not complete emacs) and scribble, a scribe mini-clone. BDS was a one man shop, it stood for brain-damaged software.
>
> On Fri, Nov 4, 2022, 9:40 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote:
> > On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > I also got a little corrupted by whatever editor came with BDS C
> >
> > I think that was wordstar. I had to retrain my fingers when I
> > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
> > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
> > Now I stick to nvi & acme. And cat for small programs/files.
>
> I used wordstar but I think BDS C had their own thing. Wordstar
> was different.
> --
> ---
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From tuhs at tuhs.org Sat Nov 5 19:29:42 2022
From: tuhs at tuhs.org (Otto Moerbeek via TUHS)
Date: Sat, 5 Nov 2022 10:29:42 +0100
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <20221105010247.GG29525@mcvoy.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
Message-ID: <Y2YtBmIHOnZ8MKJb@hz.drijf.net>
On Fri, Nov 04, 2022 at 06:02:47PM -0700, Larry McVoy wrote:
> On Sat, Nov 05, 2022 at 11:45:26AM +1100, Dave Horsfall wrote:
> > A boss of mine insisted that everyone had to learned "ed", because after a
> > system crash it might be the only editor available; that, or having to
> > dial in over a slow modem.
>
> Same. Though vi in ex mode was also good.
Yep, the computer lab I had to use had 30 or so terminals connected to
a VAX 11/750 running BSD. To get work done it was often neccesary to
switch to ex mode in vi. Later I was a teacher's assistent with night
access to the lab and I could use it on my own or with only a few
fellow TA's.
-Otto
>
> I also got a little corrupted by whatever editor came with BDS C, my
> .exrc looks like this:
>
>
> map # :.,$
> map @ :1,.
>
> Those came from that editor, # says do whatever to the end of the file,
> @ says do whatever from the top of the file to here.
>
> map , !}fmt
>
> This came from Udi Manber, , runs your paragraph through fmt
>
> map!
>
> I set shiftwidth to 4 spaces because when you have code like
>
> if ((this big thing == that big thing) && (this other big thing) &&
> (yet another big thing)) {
>
> I use 4 spaces for what I call the continuation line. I used ^A to write
> that example, why I don't like ^T is lost to me.
>
> And yeah, I paren stuff that doesn't need to have parens, it just makes
> the code more obvious.
>
> set redraw ai aw terse
>
> redraw I think is left over from modems, autoident because duh,
> autowrite because who doesn't hack, hack, hack, ^Z, !cc? terse
> because I'm not a newbie.
>
> set sections=uhshSHNH
> set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH
>
> Troff.
>
> set ts=8 sw=4
> set shell=/bin/sh
> set showmode
> set textwidth=1000
> set vb
>
> Etc.
>
> I've been carrying around that .exrc for around 40 years. Sheesh, I'm old.
From michael at casadevall.pro Sat Nov 5 20:38:22 2022
From: michael at casadevall.pro (Michael Casadevall)
Date: Sat, 5 Nov 2022 06:38:22 -0400
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
<CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
<15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
Message-ID: <CAEMRDeGPiksRZ0mVd8My=d+d9J4JBQZsCg1zoZuU89UL-gr34A@mail.gmail.com>
On Wed, Nov 2, 2022 at 11:37 AM Grant Taylor via TUHS <tuhs at tuhs.org> wrote:
> On 11/2/22 2:55 AM, Michael Casadevall wrote:
> > I extensively researched this; there are infact copies of Pinball for
> > 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s
>
> Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium?
>
> I've not watched the video yet (today).
>
>
Both actually, since Microsoft included pinball.exe on the Itanium install
disk. Works too (although there are complications)
> > Pinball had problems relating to 64-bit FPU precision (and this can
> > actually be reproduced by fiddling with FPU flags), but it did ship in
> > Windows XP x64 Professional.
>
> My understanding is that Windows XP x64 Professional is 64-bit x86 and
> not Itanium.
>
> There is also a chance that I'm misremembering things.
>
>
>
No, its just the worst product naming scheme known to man.
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221105/00b4718c/attachment.htm>
From lproven at gmail.com Sat Nov 5 21:21:49 2022
From: lproven at gmail.com (Liam Proven)
Date: Sat, 5 Nov 2022 12:21:49 +0100
Subject: [TUHS] Four windowing systems on SunOS
In-Reply-To: <CAEMRDeGPiksRZ0mVd8My=d+d9J4JBQZsCg1zoZuU89UL-gr34A@mail.gmail.com>
References: <CAK7dMtDXTs4+P=G9WEyKg+XzVkpJ0bjTyJ3Fd-i2qPyh0aZ9vg@mail.gmail.com>
<20221031191401.GN22806@mcvoy.com>
<202210311917.29VJHxe6110870@darkstar.fourwinds.com>
<CAEoi9W43-5WzTRaP1WG9+GT=_6XSOuGOxj+SkaOdtyNxs1SQxQ@mail.gmail.com>
<16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net>
<CAEMRDeEs56Fku8yC0dHcd2Lf6VBS4ijThyG9zyrB33f_2NuPpA@mail.gmail.com>
<15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net>
<CAEMRDeGPiksRZ0mVd8My=d+d9J4JBQZsCg1zoZuU89UL-gr34A@mail.gmail.com>
Message-ID: <CAMTenCGP35gw5rsfXf1E7JxtzPQZSWkh-RL36fRGzqL-bWHcaA@mail.gmail.com>
On Sat, 5 Nov 2022 at 11:38, Michael Casadevall <michael at casadevall.pro> wrote:
>
> No, its just the worst product naming scheme known to man.
To be fair -- something I rarely feel in connection with MICROS~1 --
when XP came out in 2002, AMD Sledgehammer did not exist yet. There
was no x86-64 and the only Intel 64-bit architecture was Itanium.
So I feel that they have some excuse.
We should actually give MS _some_ credit on this, because it's only
thanks to MS that Intel didn't do a totally separate incompatible
64-bit x86 extension.
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
From tytso at mit.edu Sun Nov 6 04:34:51 2022
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 5 Nov 2022 14:34:51 -0400
Subject: [TUHS] vi in cooked mode?
In-Reply-To: <20221105014029.GH29525@mcvoy.com>
References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr>
<CAC20D2OFhwHzb0CzQRN=+wzqjy_ygULGE56rcsqKbHGE_cZB0g@mail.gmail.com>
<embfcc1a1d-6a12-4624-a085-f72b735d257b@820bff6f.com>
<Y2WjV/RuqqoW7OFL@mit.edu>
<alpine.BSF.2.21.9999.2211051137590.43868@aneurin.horsfall.org>
<20221105010247.GG29525@mcvoy.com>
<F07A32BE-F8D0-4E12-9964-D3027638F7F9@iitbombay.org>
<20221105014029.GH29525@mcvoy.com>
Message-ID: <Y2asyzskfnzwaVS7@mit.edu>
On Fri, Nov 04, 2022 at 06:40:29PM -0700, Larry McVoy wrote:
> On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote:
> > On Nov 4, 2022, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > I also got a little corrupted by whatever editor came with BDS C
> >
> > I think that was wordstar. I had to retrain my fingers when I
> > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS,
> > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme.
> > Now I stick to nvi & acme. And cat for small programs/files.
>
> I used wordstar but I think BDS C had their own thing. Wordstar
> was different.
There was also Turbo Pascal, which also had a very Wordstar-like
editor.
- Ted
From rdm at cfcl.com Mon Nov 7 09:56:47 2022
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 6 Nov 2022 15:56:47 -0800
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
Message-ID: <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
I'd like to begin by thanking folks for their suggestions. I'd also like to express my awe and appreciation for Nelson Beebe's bibliographic work. That said, I am not now (and will likely never be) in a position to do anything similar for the documents in question, let alone scan and OCR them, etc. If someone wants to take on such a project, please let me know.
However, as a small step along the way, I opened up the box and produced a rough list of the contents (see below). When I noticed version or date information, I noted it, but many of the documents are missing that sort of thing. So, YMMV.
It appears that most of the items are copies of Unix Version 7 documents, printed at UC Berkeley (UCB). Some of the rest are a mix of photocopied articles from magazines (e.g., BSTJ, BYTE, Comm. ACM, Software--Practice and Experience). I assume that most of this content is readily available, but some may not be. In any case, the bibliographic info might be useful.
Finally, there are assorted documents that were edited or produced at UCB. Some of these (especially the ones marked DRAFT) may be of historical interest. Anyway, please let me know if any of this sounds like it might be worth passing along...
-r
P.S. Careful Reader may notice a strong emphasis on text processing in this collection. Jim's research interests included the use of computers to analyze Middle English poetry. For example, the rhyme schemes allowed him to clarify the pronunciation of certain words.
# Notes
The documents are currently stored in manilla folders in a cardboard box.
Folders are separated by bars (---) in the List.
Folders are listed below in the order found in the box.
Dates and "UNX x.y.z" notations are transcribed, when available.
These notations appear to relate to UCB's "UNIX Documentation Guide".
# List
"The Programmer's Workbench -- A Machine for Software Development"
Evan L. Ivie
Comm. ACM; October, 1977
---
"Lint, a C Program Checker"
S. C. Johnson
UNX 12.2.3
July 26, 1978
---
"A Tour Through the Portable C Compiler"
S. C. Johnson
UNX 13.2.7
---
"UNIX Programming -- Second Edition"
Brian W. Kernighan, Dennis M. Ritchie
UNX 2.2.3
November 12, 1978
---
"Some Applications of Inverted Indexes on the UNIX System"
M. E. Lesk
UNX 12.2.2
---
"Why Pascal is Not My Favorite Programming Language"
Brian W. Kernighan
July 18, 1981
---
"A TROFF Tutorial"
Brian W. Kernighan
---
"RATFOR -- A Preprocessor for a Rational Fortran"
Brian W. Kernighan
UNX 12.2.6
---
"Advanced Editing on UNIX"
Brian W. Kernighan
UNX 3.3.3
October 17, 1980
---
"Nroff / Troff User's Manual"
Joseph F. Ossanna
---
"A Typesetter-independent TROFF"
Brian W. Kernighan
---
"A Tutorial Introduction to the UNIX Text Editor"
B. W. Kernighan
---
"PIC -- A Graphics Language for Typesetting"
"User Manual"
Brian W. Kernighan
Revised Edition; March, 1982
"PIC -- A Graphics Language for Typesetting"
"User Manual"
Brian W. Kernighan
---
"Typesetting Mathematics -- User's Guide (Second Edition)"
Brian W. Kernighan and Lorinda L. Cherry
May 30, 1977
---
"A System for Typesetting Mathematics"
Brian W. Kernighan and Lorinda L. Cherry
Comm. ACM; March, 1975
---
"The PIC Graphics Language"
---
"LEARN -- Computer-Aided Instruction on UNIX (Second Edition)"
Brian W. Kernighan, Michael E. Lesk
UNX 12.2.1
January 30, 1979
---
"UNIX Programming -- Second Edition"
Brian W. Kernighan, Dennis M. Ritchie
November 12, 1978
---
"FSCK -- The Unix File System Check Program"
T. J. Kowalski
---
"Typing Documents on UNIX and GCOS: the -ms Macros for Nroff and Troff"
M. E. Lesk
October 8, 1976
"A Revised Version of -ms" (DRAFT)
Bill Tuthill
UNX 4.42
12/6/82
also includes a line printer listing ???
---
"Combining Data Bases: National and Cartographic Files"
Michael E. Lesk
October 26, 1981
---
"Lex - A Lexical Analyzer Generator"
M. E. Lesk and E. Schmidt
UNX 12.2.5
---
SED -- A Non-interactive Text Editor"
Lee E. McMahon
UNX 12.2.8
August 15, 1978
---
"Statistical Text Processing"
L. E. McMahon, L. L. Cherry, and R. Morris
BSTJ Vol. 57, No. 6; July-August, 1978
---
"A Tutorial Introduction to ADB"
J. F. Maranzano, S. R. Bourne
UNX 11.3.1
May 5, 1977
---
"The UNIX (tm) system: making computers easier to use"
Samuel P. Morgan
Bell Laboratories Record; December, 1978
---
"Password Security: A Case History"
Robert Morris, Ken Thompson
UNX 13.2.10
April 3, 1978
---
Uucp Implementation Description
UNX 13.2.9
D. A. Nowitz
UNX 13.2.9
October 31, 1978
---
"C Reference Manual"
Dennis M. Ritchie
---
"The Standard I/O Library"
D. M. Ritchie
E. M. Gould (local editing)
March 27, 1978
---
"Classes: An Abstract Data Type Facility for the C Language"
Bjarne Stroustrup
Bell Labs CSTR No. 84
April 3, 1980
Revised August 14, 1981
---
"A Set of C Classes for Co-routine Style Programming"
Bjarne Stroustrup
Bell Labs CSTR No. 90
November 18, 1980
---
"UNIX Implementation"
K. Thompson
UNX 13.2.4
---
"UNIX Documentation Guide"
Computing Services, UC Berkeley
---
"Berkeley Software for UNIX on the VAX"
"4.1bsd version of May, 1981"
---
"Ex/Edit Command Summary (Version 2.0)"
Computing Services, UC Berkeley
August 29, 1979
---
"-ms Command Summary" (DRAFT 2 May 78)
---
"UNIX Command Summary"
Computer Center, UC Berkeley
January 18, 1978
---
"Ex Reference Manual"
"Version 1.1 -- November, 1977"
William N. Joy
CSD, EECS, USB
November 26, 1977
---
"Experiences with the UNIX Time-sharing System"
John Lions
Software--Practice and Experience, Vol. 9, 702-709 (1979)
---
"Writing Papers with NROFF using -ME"
Eric P. Allman
Electronics Research Laboratory, UCB
May 13, 1978
---
"-ME Reference Manual"
Eric P. Allman
Electronics Research Laboratory, UCB
May 13, 1978
---
"Writing NROFF Terminal Descriptions"
Eric Allman
Britton-Lee, Inc.
---
"Bell's Lettres"
Natalie Angier
Discover; July, 1981
---
"Screen Updating and Cursor Management Optimization: A Library Package"
Kenneth C. R. C. Arnold
CSD, EECS, UCB
4th Berkeley Distribution
---
"Design and Implementation of the Berkeley Virtual Memory Extensions to the UNIX Operating System"
Ozalp Babaoglu, William Joy, Juan Porcar
CSD, EECS, UCB
December 2, 1979
---
"Data Structures Added in the Berkeley Virtual Memory Extensions to the UNIX Operating System"
Ozalp Babaoglu, William Joy
CSD, EECS, UCB
November 23, 1979
---
"UNIX with Satellite Processors"
Amnon B. Barak and Amos Shapir
Software--Practice and Experience, Vol. 10, 383-392 (1980)
---
"Development system interface expedited software design"
Jim Bessemer
Electronics Design; September 2, 1982
---
"LocalNet and UNIX"
K. J. Biba, S. J. Leffler
Sytek, Inc.; June, 1981
---
"Edit: A Tutorial"
Ricki Blau, James Joyce
Computing Services, UCB
UNX 3.3.1
September, 1981
"Edit: A Tutorial"
Ricki Blau, James Joyce
Computing Services Division, Computing Affairs, UCB
January, 1978
"Text Editing with UNIX"
---
"Communicating with UNIX"
Ricki Blau
Computing Services, UCB
UNX 1.3.1
September, 1981
---
"UNIX on a Micro"
Cornelia Boldyreff
SIGSMALL Newsletter, Vol. 7, No. 1; February, 1981
---
"Extending the Interprocess Communication Facility of UNIX for a Distributed Operating System"
Sheng-Yang Chiu
Bolt, Beranek and Newman, Inc.
27 July 1981
Revised: 31 July 1981
Request for Comments: DOS-8
---
"DEAFNET: A Distributed Communications Service for the Deaf"
Earl Craighill
SRI International
May, 1980
---
Programmer's Workbench Papers
Second International Conference on Software Engineering
T. A. Dolotta, J. R. Mashey, D. W. Smith, M. H. Bianchi, J. L. Wood
October 13-15, 1976
---
"The Programmer's Workbench"
T. A. Dolotta, R. C. Haight, J. R. Mashey
BSTJ; July-August, 1978
---
"A Comparison of the Programming Languages C and Pascal"
Alan R. Feuer, Narain H. Gehani
ACM Computing Surveys, Vol. 14, No. 1; March 1982
---
"A Dual Processor VAX 11/780"
George H. Goble, Michael H. Marsh
School of EE, Purdue
TR-EE 81-31; September, 1981
---
"The UNIX Operating System and the XENIX Standard Operating Environment"
Robert B. Greenberg
BYTE; June, 1981
---
"Growing, Pruning and Climbing Binary Trees with tiny-c"
Les Hancock
Dr. Dobb's Journal No. 36, Vol. 4, Issue 6; June/July 1979
---
"Implementing a tiny interpreter with a CP/M-flavored C"
Les Hancock
Dr. Dobb's Journal No. 41
---
"A Portable File Directory System"
David R. Hanson
Software--Practice and Experience, Vol. 10, 623-634 (1980)
---
"Getting Acquainted with Ex: An Aid for Humanities Users"
A Publication of The Old English Colloquium's Unix Project
A. Hernandez
January 1, 1979
---
"Some Facts and Fallacies about UNIX"
Jim Isaak
FORUM, Computer System News; January 18, 1982
---
"Operating systems confer new degree of sophistication on microprocessors"
R. Colin Johnson
Electronics; March 24, 1981
---
"UNIX - New Avenues in Research and Development"
Robert E. Jones
Hardcopy; February, 1982
---
"An Architecture for Interprocess Communication in UNIX"
William Joy and Robert Fabry
CSRG, EECS, UCB
DRAFT of June 22, 1981
"Proposals for enhancement of UNIX on the VAX"
William Joy and Robert Fabry
CSRG, EECS, UCB
July 21, 1981; Revised August 31, 1981
---
"4.2BSD System Manual"
William Joy, Eric Cooper, Robert Fabry, Samuel Leffler and Kirk McKusick
CSRG, EECS, UCB
Draft of February 14, 1982
---
"An Introduction to Display Editing with Vi"
William Joy
CSRG, EECS, UCB
April 2, 1979
---
"Berkeley Pascal User's Manual"
William N. Joy, Susan L. Graham, Charles B. Haley
CSD, EECS, UCB
Version 1.1 - April, 1979
---
"Installing and Operating 4.1bsd"
William N. Joy
CSRG, EECS, UCB
May 18, 1981
---
"Berkeley Pascal PX Implementation Notes"
Version 1.1 - April, 1979
William N. Joy
CSD, EECS, UCB
March 30, 1979
"Berkeley Pascal PX Implementation Notes"
Version 2.0 - January, 1979
William N. Joy, M. Kirk McKusick
CSD, EECS, UCB
April 9, 1981
---
"Berkeley Pascal PXP Implementation Notes"
Version 1.1 - April, 1979
William N. Joy
CSD, EECS, UCB
April 10, 1981
---
"UNIX Aids for English Composition Courses"
James Joyce
Computing in the Humanities; 1982
---
"PIC -- A Crude Graphics Language for Typesetting"
Brian W. Kernighan
Bell Labs CSTR No. 85
January 24, 1981
also published in:
Software--Practice and Experience, Vol. 12, 1-21 (1982)
---
"Printf for the C Function Library"
Christopher Kern
BTYE; May, 1981
---
"The BDS C Compiler"
Christopher Kern
BYTE; June, 1981
---
"The Unix Programming Environment"
Brian W. Kernighan, John R. Mashey
IEEE Computer; April, 1981
---
"Hints on Configuring VAX Systems for UNIX"
Revised: May 4, 1981
Bob Kridle, Bill Joy
CSRG, UCB
---
"Unix Text Formatting for Beginners"
Gordon P. Leffadinger
Computing Services, UCB
May 10, 1982 (DRAFT)
---
"The UNIX Operating System"
"A Sophisticated and Portable Multiuser Operating System"
Bob Marsh, Grant Munsey, Kip Myers, Craig Forney
Microcomputer Operating Systems, in
Microcomputer Applications, (c) 1981
---
"Data Stream Linkage Mechanism"
J. P. Morrison
IBM Syst J, Vol. 17, No. 4; 1978
---
"Unix-like software runs on mini- and microcomputers"
P. J. Plauger and M. S. Krieger
Electronics; March 24, 1981
---
"An Inter-Process Communication Facility for UNIX"
Richard F. Rashid
CMU-CS-80-124
February 4, 1980
Revised: 11 June 1980
"An Inter-Process Communication Facility for UNIX"
Richard F. Rashid
February 4, 1980
Revised: 2 April 1981
---
"Thoughts on 'An Architecture for Interprocess Communication'
by William Joy and Robert Fabry"
DRAFT -- DO NOT CIRCULATE'
A Personal Commentary
Richard F. Rashid
printed 29-Jul-81
---
"An Introduction to the Berkeley Network"
Eric Schmidt
CSD, EECS, UCB
May, 1979
(revised March, 1980)
---
"The UNIXperience for the Unexpert"
Wurster Computer Center
"The UNIXperience for Unexperts was prepared with the UNIX system by Claire E. Taylor, a real beginner, in the Spring of 1979, for the computer graphics course taught by Aaron Marcus"
---
"LIST -- A Source-Listing Program for the C Language"
Jeff Taylor
BYTE; June, 1981
---
"The -mx Macro Package: A Revised Version of -ms"
Bill Tuthill
Computing Services, UCB (DRAFT)
---
"Literary Text Processing by Computer"
William Tuthill
Comparative literature Dept., UCB
15 January 1981
also, man pages for assorted commands in the HUM section:
cedilla, cfreq, dict, dissolve, ...
---
"The Unix Word Processing Facilities"
Vance Vaughan
June 1, 1977
---
"Adapting Unix to a 16-bit microcomputer"
Bruce Weiner and Douglas Swartz
Electronics; March 24, 1981
---
"Productivity Engineering in the UNIX Environment"
EECS & ERL, UCB
This appears to be a grant proposal:
"The proposed contract will be a continuation of contract
N00039-80-K-0649, ARPA Order Number 4031, April 1980 to present."
---
(not in a folder)
"Writing Distributed Programs with Courier"
Eric C. Cooper
CSD, EECS, UCB
"gprof: A Call Graph Execution Profiler"
Susan L. Graham, Peter B. Kessler, Marshall K. McKusick
CSD, EECS, UCB
Proc. ACM SIGPLAN -82 Symp. on Compiler Construction
"VAX/VMS Performance and Configuration"
Hank Levy
Advanced-11 Engineering
August 15, 1978
---
"A Fast File System for UNIX"
DRAFT of September 6, 1982
Marshall Kirk McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry
CSRG, CSD, EECS, UCB
"Refer -- A Bibliography System"
Bill Tuthill
Computing Services, UCB
October 1, 1982
"Refer -- A Bibliography System"
Bill Tuthill
Humanities Computing Service, UCB
September 6, 1982
"The Cambridge Ring and UNIX"
R. P. A. Collinson
Software--Practice and Experience, Vol. 12, 583-594 (1982)
"Description of a Menu Creation and Interpretation System"
Michael J. Heffler
Software--Practice and Experience, Vol. 12, 269-281 (1982)
"A Programmable Text Editor"
Christopher W. Fraser
Software--Practice and Experience, Vol. 12, 241-250 (1982)
"The Syntax of Interactive Command Languages: A Framework for Design"
I. Trotter Hardy, Jr.
Software--Practice and Experience, Vol. 12, 67-75 (1982)
"Why Pascal is Not My Favorite Programming Language"
Brian W. Kernighan
CSTR No. 100
July 18, 1981
"A High-Level Approach to Computer Document Formatting"
Brian K. Reid
1980 ACM 0-89791-011-7
"How Users Search:
A Comparison of Menu and Attribute Retrieval Systems on a Library Catalog"
V. J. Geller
M. E. Lesk
Bell Labs
September 27, 1981
"Porting the Unix Operating System"
Robert Erickson, Peter Tom
HHB-SOFTRON
(describes porting of UNIX/v7 to the SIEMENS R30)
---
"A Walk Through AWK"
Leon S. Levy
Bell Labs
SIGPLAN Notices, V18 #12; December, 1983
---
"Setting Up Unix - Seventh Edition"
Charles B. Haley, Dennis M. Ritchie
Bell Labs
UNX 13.2.2
---
"PARTS - A System for Assigning Word Classes to English Text"
L. L. Cherry
Bell Labs, CSTR No. 81
---
"Writing Tools - The STYLE and DICTION Programs
L. L. Cherry, W. Vesterman
February, 1981
"Writing Tools - The STYLE and DICTION Programs
L. L. Cherry, W. Vesterman
November 22, 1980
Letter from Jim Joyce to Lorinda Cherry, inviting her to speak
at the 1983 meeting of the Association for Literary and Linguistic Computing
"The Seybold Report on Word Processing"
Vol. 4, No. 1, January 1981
ISSN: 0160-9572
---
"Route Finding in Street Maps by Computers and People"
R. J. Elliott, M. E. Lesk
Bell Labs
---
"Regenerating System Software"
Charles B. Haley, Dennis M. Ritchie
Bell Labs
UNX 13.2.3
---
"Make - A Program for Maintaining Computer Programs"
S. I. Feldman
Bell Labs
---
---
From imp at bsdimp.com Tue Nov 8 03:50:33 2022
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 7 Nov 2022 10:50:33 -0700
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
Message-ID: <CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) <
sauer at technologists.com> wrote:
> On 10/11/2022 3:14 PM, Michael Kjörling wrote:
> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy):
> >>> Isn't it relatively well established, though, that IBM culture at
> >>> least for a very long time put heavy emphasis on counting lines of
> >>> source code, and that more SLOC was considered to be better?
> >>
> >> That's just stupid.
> >
> > You're getting no argument from me there.
> >
>
> It was likely true that some parts of IBM put heavy emphasis on LOC, but
> as Marc points out, that wasn't true in Research. I don't remember heavy
> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was
> not "heavy" emphasis.
>
Speaking of "just stupid"
Word on the street is that Elon Musk stack ranked the engineers by lines of
code
over the last year (source: https://ma.nu/blog/bye-twitter) and layed off
the bottom
performers in terms of LoC...
Not 100% sure this is legit, since some tweets about it have been deleted.
Warners
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221107/2d9f5cf4/attachment.htm>
From bakul at iitbombay.org Tue Nov 8 05:57:20 2022
From: bakul at iitbombay.org (Bakul Shah)
Date: Mon, 7 Nov 2022 11:57:20 -0800
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
References: <CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
Message-ID: <26FA85DD-7316-4F7F-A6F9-24FE6E723674@iitbombay.org>
On Nov 7, 2022, at 9:52 AM, Warner Losh <imp at bsdimp.com> wrote:
>
> Speaking of "just stupid"
>
> Word on the street is that Elon Musk stack ranked the engineers by lines of code
> over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom
> performers in terms of LoC...
Just LoCo!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221107/112c5721/attachment.htm>
From crossd at gmail.com Tue Nov 8 06:11:39 2022
From: crossd at gmail.com (Dan Cross)
Date: Mon, 7 Nov 2022 15:11:39 -0500
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
Message-ID: <CAEoi9W7Q7xdozzL_fmi3amJPRpbk5c-4_wr0D3KOukWi4gCixQ@mail.gmail.com>
On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp at bsdimp.com> wrote:
> On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) <sauer at technologists.com> wrote:
>> On 10/11/2022 3:14 PM, Michael Kjörling wrote:
>> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy):
>> >>> Isn't it relatively well established, though, that IBM culture at
>> >>> least for a very long time put heavy emphasis on counting lines of
>> >>> source code, and that more SLOC was considered to be better?
>> >>
>> >> That's just stupid.
>> >
>> > You're getting no argument from me there.
>>
>> It was likely true that some parts of IBM put heavy emphasis on LOC, but
>> as Marc points out, that wasn't true in Research. I don't remember heavy
>> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was
>> not "heavy" emphasis.
>
> Speaking of "just stupid"
>
> Word on the street is that Elon Musk stack ranked the engineers by lines of code
> over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom
> performers in terms of LoC...
Well, if I ever go to work for Twitter, I know how I'm initializing
large arrays.
> Not 100% sure this is legit, since some tweets about it have been deleted.
I suspect it was slightly more nuanced, having more to do with "total output"
measured as some combination of number of changes and their total size.
It sure is dumb, though.
- Dan C.
From tuhs at tuhs.org Tue Nov 8 08:16:24 2022
From: tuhs at tuhs.org (Grant Taylor via TUHS)
Date: Mon, 7 Nov 2022 15:16:24 -0700
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
<86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
Message-ID: <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
On 11/6/22 4:56 PM, Rich Morin wrote:
> However, as a small step along the way, I opened up the box and
> produced a rough list of the contents (see below). When I noticed
> version or date information, I noted it, but many of the documents
> are missing that sort of thing. So, YMMV.
Thank you very much for the list. The provided details and your care to
separate things is appreciated.
> P.S. Careful Reader may notice a strong emphasis on text processing
> in this collection. Jim's research interests included the use of
> computers to analyze Middle English poetry. For example, the rhyme
> schemes allowed him to clarify the pronunciation of certain words.
I noticed that.
I also noticed that I would very much like to spend some (upcoming) cold
winter days with tea reading many of these papers.
I'd be happy to help contribute to get these papers somewhere to be
scanned & shared. Sadly I don't know how to go about doing the scanning
myself.
I'll contribute at least $10 toward getting these papers somewhere to be
scanned.
My efforts to scan front & back covers of my books doesn't scale to
scanning, much less OCRing, books.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221107/e4c925a6/attachment.p7s>
From tuhs at tuhs.org Tue Nov 8 09:12:40 2022
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Mon, 07 Nov 2022 23:12:40 +0000
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
<86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
<332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
Message-ID: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
The following papers stick out to me as papers that haven't surfaced in any of the research I've done (not exhaustive, but what stuck out to me):
The Programmer's Workbench - A Machine for Software Development
- Is this distinct from the Mashey papers?
Why Pascal is Not My Favorite Programming Language
- This sounds fun, not hard UNIX info, but fun
A Typesetter-Independent TROFF
- A ditroff-specific paper? Can't say I've seen such a thing, would be interested in this one. I know someone (can't recall name/email) in the GROFF mailing list seemed particularly excited about ditroff information that could be gleaned from the UNIX/TS 4.0 docs, this may be their golden carrot.
PIC - A Graphics Language for Typesetting
- The list mentions a March 1982 revision. This would post-date the UNIX/TS 4.0 version, although there is the Research V10 version of the paper. However, an initial flip through the V10 Volume 2 manual reveals no specific last-modify date. That would ultimately trace back to https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/doc/pic . I can't find the roff sources for V9 or V10 of this paper though, I've just got the physical book for V10.
The PIC Graphics Language
- Another PIC paper?
FSCK - The Unix File System Check Program
- This paper shows up in UNIX/TS document sets but not research. I'd be curious of the specific date on this one, the latest one we have afaik is 1981, UNIX/TS 4.0.
Combining Data Bases: National and Cartographic Files
- Not explicitly UNIX perhaps? Either way, I like maps, I'd be curious what is going on here
The UNIX System: Making Computers Easier To Use
- Perhaps a transcript of https://www.youtube.com/watch?v=XvDZLjaCJuw ?
C Reference Manual
- Curious on the date, there are many revisions scanned
UNIX Documentation Guide
- BSD "Documentation Roadmap" perhaps? I have a 4BSD paper compilation from some university in Australia, seems to just be a subset of C and Fortran related papers though, I wonder if there's correlation between this and the intro paper in that set...
The Unix Programming Environment
- Kernighan and Mashey? Does this bear any relation to the book authored with Rob Pike? I feel like I've seen this title in passing but am definitely curious.
A Walk Through AWK
- Somewhere between the original AWK paper and the AWK book?
PARTS - A System for Assigning Word Classes to English Text
- Probably the paper underlying descriptions of parts in later WWB literature.
Writing Tools - The STYLE and DICTION Programs
- Ditto, I'd be curious how much of what became trade-book WWB/DWB documentation started as Bell memoranda and if a full manual could be compiled from just memoranda.
Route Finding in Street Maps by Computers and People
- More maps work by Bell, didn't know they did stuff in this area
I would absolutely be interested in throwing my hat in the ring on preservation, can pay for shipping to and fro and scanning would be gratis. That said, if someone expects a certain DPI, OCR, etc. then you can pay someone, I volunteer my resources at the capacity I can volunteer them.
If someone else can do the whole package, I'll also happily donate towards that.
- Matt G.
------- Original Message -------
On Monday, November 7th, 2022 at 2:16 PM, Grant Taylor via TUHS <tuhs at tuhs.org> wrote:
> On 11/6/22 4:56 PM, Rich Morin wrote:
>
> > However, as a small step along the way, I opened up the box and
> > produced a rough list of the contents (see below). When I noticed
> > version or date information, I noted it, but many of the documents
> > are missing that sort of thing. So, YMMV.
>
>
> Thank you very much for the list. The provided details and your care to
> separate things is appreciated.
>
> > P.S. Careful Reader may notice a strong emphasis on text processing
> > in this collection. Jim's research interests included the use of
> > computers to analyze Middle English poetry. For example, the rhyme
> > schemes allowed him to clarify the pronunciation of certain words.
>
>
> I noticed that.
>
> I also noticed that I would very much like to spend some (upcoming) cold
> winter days with tea reading many of these papers.
>
> I'd be happy to help contribute to get these papers somewhere to be
> scanned & shared. Sadly I don't know how to go about doing the scanning
> myself.
>
> I'll contribute at least $10 toward getting these papers somewhere to be
> scanned.
>
> My efforts to scan front & back covers of my books doesn't scale to
> scanning, much less OCRing, books.
>
>
>
> --
> Grant. . . .
> unix || die
From arnold at skeeve.com Tue Nov 8 16:30:42 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 07 Nov 2022 23:30:42 -0700
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
<86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
<332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
<18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
Message-ID: <202211080630.2A86Ugc6004710@freefriends.org>
Hi.
> Why Pascal is Not My Favorite Programming Language
> - This sounds fun, not hard UNIX info, but fun
It's been around for a long time. A while back, I reconstituted
it, see https://www.github.com/arnoldrobbins/cstr100.
> A Typesetter-Independent TROFF
> - A ditroff-specific paper? Can't say I've seen such a thing, would
> be interested in this one. I know someone (can't recall name/email)
> in the GROFF mailing list seemed particularly excited about ditroff
> information that could be gleaned from the UNIX/TS 4.0 docs, this may
> be their golden carrot.
This is also around on the Internet.
If there's interest, I might could wheedle the original out of BWK.
> A Walk Through AWK
> - Somewhere between the original AWK paper and the AWK book?
I missed this in the original list. I'd love to have a copy of it!
Arnold
From g.branden.robinson at gmail.com Wed Nov 9 02:42:20 2022
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 8 Nov 2022 10:42:20 -0600
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
<86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
<332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
<18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
Message-ID: <20221108164220.q5dmgmckl6haenn6@illithid>
At 2022-11-07T23:12:40+0000, segaloco via TUHS wrote:
> The following papers stick out to me as papers that haven't surfaced
> in any of the research I've done (not exhaustive, but what stuck out
> to me):
>
> Why Pascal is Not My Favorite Programming Language
> - This sounds fun, not hard UNIX info, but fun
The infamous CSTR #100. :D It has been in circulation as a while,
though the copy I have has been stripped of its CSTR identifier and the
header margin is suspiciously short for an ms(7) paper.
> A Typesetter-Independent TROFF
> - A ditroff-specific paper? Can't say I've seen such a thing,
> would be interested in this one.
That's CSTR #97, also well-known, albeit not as well known as it should
be by people who regard CSTR #54 (1992 revision) as Torah. #97 is
surely Taldmudic.
> I know someone (can't recall name/email) in the GROFF mailing list
> seemed particularly excited about ditroff information that could be
> gleaned from the UNIX/TS 4.0 docs, this may be their golden carrot.
That was me. The golden carrot would be the [nt]roff source from that
release. Someone pointed me in the direction of McKusick's CSRG CD-ROM
archives for that, but I haven't made the time to chase it down. I'm
trying to eat my vegetables first and get a groff release out. We're
closing in on 400 bugs fixed since 1.22.4...
> PIC - A Graphics Language for Typesetting
> - The list mentions a March 1982 revision. This would post-date
> the UNIX/TS 4.0 version, although there is the Research V10
> version of the paper. However, an initial flip through the V10
> Volume 2 manual reveals no specific last-modify date. That would
> ultimately trace back to
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/doc/pic . I
> can't find the roff sources for V9 or V10 of this paper though,
> I've just got the physical book for V10.
I'm envious, if you have both bound volumes of the V10 manuals.
groff's pic.ms document (identifying Eric Raymond as author, although I
believe it understates its debt to the above document, CSTR #116) muses
about a "pre-ditroff" version of pic, but I have never encountered any
evidence that any such thing existed. The \D drawing command escape
sequences did not exist in Ossanna's troff; see the line 601 switch() in
<https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n1.c>.
> The PIC Graphics Language
> - Another PIC paper?
I'm curious to see any variant documentation of pic, particularly its
early versions.
> Writing Tools - The STYLE and DICTION Programs
> - Ditto, I'd be curious how much of what became trade-book WWB/DWB
> documentation started as Bell memoranda and if a full manual could
> be compiled from just memoranda.
I share your interest in WWB-related documents.
In case there's anyone who's not already aware of this, the Internet
Archive has a very nice cache of documents formerly hosted at
cs.bell-labs.com.
https://web.archive.org/web/20080509085821/http://www.cs.bell-labs.com/cm/cs/cstr.html
I find the refer(1) database of _all_ CSTR document numbers to be of
particular interest.
https://web.archive.org/web/20080509085821/http://www.cs.bell-labs.com/cm/cs/cstr/bib
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/20221108/7c28e18f/attachment.sig>
From marc.donner at gmail.com Wed Nov 9 04:55:36 2022
From: marc.donner at gmail.com (Marc Donner)
Date: Tue, 8 Nov 2022 13:55:36 -0500
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
Message-ID: <CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
My buds in the SRE community confirm that Twitter laid off the entire SRE
team, since of course they didn't write enough code. Good luck with
keeping the system up.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) <
> sauer at technologists.com> wrote:
>
>> On 10/11/2022 3:14 PM, Michael Kjörling wrote:
>> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy):
>> >>> Isn't it relatively well established, though, that IBM culture at
>> >>> least for a very long time put heavy emphasis on counting lines of
>> >>> source code, and that more SLOC was considered to be better?
>> >>
>> >> That's just stupid.
>> >
>> > You're getting no argument from me there.
>> >
>>
>> It was likely true that some parts of IBM put heavy emphasis on LOC, but
>> as Marc points out, that wasn't true in Research. I don't remember heavy
>> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was
>> not "heavy" emphasis.
>>
>
> Speaking of "just stupid"
>
> Word on the street is that Elon Musk stack ranked the engineers by lines
> of code
> over the last year (source: https://ma.nu/blog/bye-twitter) and layed off
> the bottom
> performers in terms of LoC...
>
> Not 100% sure this is legit, since some tweets about it have been deleted.
>
> Warners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221108/35b620b3/attachment.htm>
From frew at ucsb.edu Wed Nov 9 08:56:10 2022
From: frew at ucsb.edu (James Frew)
Date: Tue, 8 Nov 2022 14:56:10 -0800
Subject: [TUHS] early Unix papers, from Jim Joyce
In-Reply-To: <202211080630.2A86Ugc6004710@freefriends.org>
References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu>
<74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net>
<86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com>
<332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net>
<18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com>
<202211080630.2A86Ugc6004710@freefriends.org>
Message-ID: <903541bf-7136-6b4a-e144-9281f04a560c@ucsb.edu>
On 2022-11-07 22:30, arnold at skeeve.com wrote:
>> A Walk Through AWK
>> - Somewhere between the original AWK paper and the AWK book?
> I missed this in the original list. I'd love to have a copy of it!
doi.org/10.1145/988193.988201 <https://doi.org/10.1145/988193.988201>
Enjoy,
/Frew <https://purl.org/frew>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221108/ac61f777/attachment.htm>
From kevin.bowling at kev009.com Wed Nov 9 12:02:25 2022
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 8 Nov 2022 19:02:25 -0700
Subject: [TUHS] Keynote Language - Tim Thompson
Message-ID: <CAK7dMtB2UxquSVkBC=dUdE_8+Gf5rTSAnNu_u_WxVPmRmKk5KA@mail.gmail.com>
Does anyone know if this made it outside the labs?
https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf
I have a rack of outboard synths and samplers, it would be
entertaining to run them with an awk-analogue.
From fjarlq at gmail.com Wed Nov 9 17:46:44 2022
From: fjarlq at gmail.com (Matt Day)
Date: Wed, 9 Nov 2022 00:46:44 -0700
Subject: [TUHS] Keynote Language - Tim Thompson
In-Reply-To: <CAK7dMtB2UxquSVkBC=dUdE_8+Gf5rTSAnNu_u_WxVPmRmKk5KA@mail.gmail.com>
References: <CAK7dMtB2UxquSVkBC=dUdE_8+Gf5rTSAnNu_u_WxVPmRmKk5KA@mail.gmail.com>
Message-ID: <CAHrGxA1UzVDH9qXdUUW3HDdZ2y8nmiSHaE7bkAQhU2opxeLw5g@mail.gmail.com>
Yes, it became KeyKit: https://github.com/nosuchtim/keykit
Tim recorded a demo video of Keynote in 1994:
https://www.youtube.com/watch?v=-c-O57J9W-E
His website: https://timthompson.com/tjt/
On Tue, Nov 8, 2022 at 7:03 PM Kevin Bowling <kevin.bowling at kev009.com>
wrote:
> Does anyone know if this made it outside the labs?
>
> https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf
>
> I have a rack of outboard synths and samplers, it would be
> entertaining to run them with an awk-analogue.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221109/a17af0f4/attachment.htm>
From crossd at gmail.com Wed Nov 9 18:41:24 2022
From: crossd at gmail.com (Dan Cross)
Date: Wed, 9 Nov 2022 03:41:24 -0500
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
<CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
Message-ID: <CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
On Tue, Nov 8, 2022, 1:57 PM Marc Donner <marc.donner at gmail.com> wrote:
> My buds in the SRE community confirm that Twitter laid off the entire SRE
> team, since of course they didn't write enough code. Good luck with
> keeping the system up.
>
It's ok. I'm sure users can just fax problem reports to Elon.
To tie this back to TUHS a little bit...when did being a "sysadmin" become
a thing unto itself? And is it just me, or has that largely been superceded
by SRE (which I think of as what one used to, perhaps, call a "system
programmer") and DevOps, which feels like a more traditional Unix-y kind of
thing?
- Dan C.
=====
> nygeek.net
> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
>
>
> On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) <
>> sauer at technologists.com> wrote:
>>
>>> On 10/11/2022 3:14 PM, Michael Kjörling wrote:
>>> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy):
>>> >>> Isn't it relatively well established, though, that IBM culture at
>>> >>> least for a very long time put heavy emphasis on counting lines of
>>> >>> source code, and that more SLOC was considered to be better?
>>> >>
>>> >> That's just stupid.
>>> >
>>> > You're getting no argument from me there.
>>> >
>>>
>>> It was likely true that some parts of IBM put heavy emphasis on LOC, but
>>> as Marc points out, that wasn't true in Research. I don't remember heavy
>>> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was
>>> not "heavy" emphasis.
>>>
>>
>> Speaking of "just stupid"
>>
>> Word on the street is that Elon Musk stack ranked the engineers by lines
>> of code
>> over the last year (source: https://ma.nu/blog/bye-twitter) and layed
>> off the bottom
>> performers in terms of LoC...
>>
>> Not 100% sure this is legit, since some tweets about it have been deleted.
>>
>> Warners
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221109/52f06db0/attachment-0001.htm>
From arnold at skeeve.com Wed Nov 9 18:49:21 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 09 Nov 2022 01:49:21 -0700
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
<CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
<CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
Message-ID: <202211090849.2A98nLRe006143@freefriends.org>
Dan Cross <crossd at gmail.com> wrote:
> To tie this back to TUHS a little bit...when did being a "sysadmin" become
> a thing unto itself? And is it just me, or has that largely been superceded
> by SRE (which I think of as what one used to, perhaps, call a "system
> programmer") and DevOps, which feels like a more traditional Unix-y kind of
> thing?
>
> - Dan C.
Sys admin was a thing in the mid-80s already; I worked as one at the Emory
U Computing Center for several years, ~ 1985 - 1990. Around then USENIX
started the LISA (Large Installation System Administratin) workshops.
Clem can undoubtedly tell us exactly when.
And yes, SRE + dev ops seem to have displaced that, with SRE focusing
more on keeping the bazillions of systems up and running, and DevOps on
things like build and CI/CD systems.
Personally, I'm glad to have gained the sys admin experience, but I
don't want to do it for a living; it's much more fun building product
and letting someone else have the headaches. :-)
Arnold
From sjenkin at canb.auug.org.au Wed Nov 9 19:01:25 2022
From: sjenkin at canb.auug.org.au (steve jenkin)
Date: Wed, 9 Nov 2022 20:01:25 +1100
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
<CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
<CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
Message-ID: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au>
> On 9 Nov 2022, at 19:41, Dan Cross <crossd at gmail.com> wrote:
>
> To tie this back to TUHS a little bit...when did being a "sysadmin" become a thing unto itself? And is it just me, or has that largely been superceded by SRE (which I think of as what one used to, perhaps, call a "system programmer") and DevOps, which feels like a more traditional Unix-y kind of thing?
>
> - Dan C.
In The Beginning, We were All Programmers…
Machines were smaller, programs simpler and we were closer to the hardware.
Literally, like the “Unix Roomâ€, in the Attic at Bell Labs.
Admin & Operations weren’t too onerous and “Maintenance†was done by the people doing the kernel & systems software, at a guess.
And maybe hardware was fixed by the Vendor, or super-programmers did the plug and play themselves.
As sites got bigger, work became multi-person project ’teams’ and admin problems got tricker, while ‘certain people’ did the work.
When Unix became properly commercial - multiple vendors, big manuals, support contracts, and a plethora of Unix variants - some Bright People created “Unix Training†courses, in many topiocs.
Somewhere around this time, courses and job titles for “System Admin†appeared.
Sadly, all this happened without any distinctions in capability & ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: “fix the broken network in the allotted timeâ€)
SAGE - System Admin Guild, part of USENIX - put together a bunch of small books on (Unix) System Admin Topics and tried to guide the development of the field.
After 10 years, I was out of the loop and hadn’t seen anything positive in the workplace.
SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines.
Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :)
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
From brad at anduin.eldar.org Wed Nov 9 20:55:42 2022
From: brad at anduin.eldar.org (Brad Spencer)
Date: Wed, 09 Nov 2022 05:55:42 -0500
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> (message
from steve jenkin on Wed, 9 Nov 2022 20:01:25 +1100)
Message-ID: <xon1qqcgzwx.fsf@anduin.eldar.org>
steve jenkin <sjenkin at canb.auug.org.au> writes:
[snip]
> SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines.
>
> Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :)
My final $DAYJOB was more DevOps / SRE than system admin which I had
been doing for a long time. And, Very Much Yes, the "potential for
screw-ups" is very much infinite. It seems like that there are a lot of
people messing in areas that they are ill prepared to deal with and tend
to do it poorly at times. Very often they will invent structure that is
just a reinvention of something that already exists because they lack
the background to know what was really available.
> --
> Steve Jenkin, IT Systems and Design
> 0412 786 915 (+61 412 786 915)
> PO Box 38, Kippax ACT 2615, AUSTRALIA
>
> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
--
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org
From stu at remphrey.net Wed Nov 9 21:56:39 2022
From: stu at remphrey.net (Stuart Remphrey)
Date: Wed, 9 Nov 2022 19:56:39 +0800
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
<CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
<CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
<29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au>
Message-ID: <CAD0_1cn4A8QTVg164eBzwuFUhrO51vKTRsSmPpBvrMK4HEhUaQ@mail.gmail.com>
> Never done it myself, but it’d seem the potential for screw-ups is now
infinite and unlimited in time :)
Indeed!
USENIX SREcon generally releases presentations a short while after each
conference.
Some interesting experiences there...
https://www.usenix.org/conferences/byname/925
https://www.usenix.org/srecon
-- Stuart.
On Wed, 9 Nov 2022 at 17:03, steve jenkin <sjenkin at canb.auug.org.au> wrote:
>
> > On 9 Nov 2022, at 19:41, Dan Cross <crossd at gmail.com> wrote:
> >
> > To tie this back to TUHS a little bit...when did being a "sysadmin"
> become a thing unto itself? And is it just me, or has that largely been
> superceded by SRE (which I think of as what one used to, perhaps, call a
> "system programmer") and DevOps, which feels like a more traditional Unix-y
> kind of thing?
> >
> > - Dan C.
>
> In The Beginning, We were All Programmers…
>
> Machines were smaller, programs simpler and we were closer to the hardware.
> Literally, like the “Unix Roomâ€, in the Attic at Bell Labs.
>
> Admin & Operations weren’t too onerous and “Maintenance†was done by the
> people doing the kernel & systems software, at a guess.
> And maybe hardware was fixed by the Vendor, or super-programmers did the
> plug and play themselves.
>
> As sites got bigger, work became multi-person project ’teams’ and admin
> problems got tricker, while ‘certain people’ did the work.
>
> When Unix became properly commercial - multiple vendors, big manuals,
> support contracts, and a plethora of Unix variants - some Bright People
> created “Unix Training†courses, in many topiocs.
>
> Somewhere around this time, courses and job titles for “System Adminâ€
> appeared.
>
> Sadly, all this happened without any distinctions in capability &
> ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of
> testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session:
> “fix the broken network in the allotted timeâ€)
>
> SAGE - System Admin Guild, part of USENIX - put together a bunch of small
> books on (Unix) System Admin Topics and tried to guide the development of
> the field.
> After 10 years, I was out of the loop and hadn’t seen anything positive in
> the workplace.
>
> SRE roles & as a discipline has developed, alongside DevOps, into managing
> & fault finding in large clusters of physical and virtual machines.
>
> Never done it myself, but it’d seem the potential for screw-ups is now
> infinite and unlimited in time :)
>
> --
> Steve Jenkin, IT Systems and Design
> 0412 786 915 (+61 412 786 915)
> PO Box 38, Kippax ACT 2615, AUSTRALIA
>
> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221109/7f57bed9/attachment.htm>
From dave at horsfall.org Thu Nov 10 06:17:23 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Nov 2022 07:17:23 +1100 (EST)
Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral
History": who was in the team in "The Attic"?
In-Reply-To: <202211090849.2A98nLRe006143@freefriends.org>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<20221011201025.GJ11780@mcvoy.com>
<513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa>
<0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com>
<CANCZdfoEg_++R7ANoU=Cg5Uzn5x-MUXm5wpk1zsAurOV_Be9Gg@mail.gmail.com>
<CALQ0xCCNKZ=baxKA=8CXkvT0Q3Zy_5Yqm7Yn8HtjOt6SCMoyfA@mail.gmail.com>
<CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>
<202211090849.2A98nLRe006143@freefriends.org>
Message-ID: <alpine.BSF.2.21.9999.2211100714550.43868@aneurin.horsfall.org>
On Wed, 9 Nov 2022, arnold at skeeve.com wrote:
> Sys admin was a thing in the mid-80s already; I worked as one at the
> Emory U Computing Center for several years, ~ 1985 - 1990. Around then
> USENIX started the LISA (Large Installation System Administratin)
> workshops. Clem can undoubtedly tell us exactly when.
It was a thing in the 70s, when I was maintaining Edition 6 on a lot of
11/40s (and a few 11/23s etc) for UNSW; it's all in AUUGN.
-- Dave
From sjenkin at canb.auug.org.au Thu Nov 10 08:01:42 2022
From: sjenkin at canb.auug.org.au (steve jenkin)
Date: Thu, 10 Nov 2022 09:01:42 +1100
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right &
any surprises?
Message-ID: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
I’ve only recently stumbled across this paper.
It gives the answer to one question I’ve had:
Why did Linux become more popular than everything that came before it?
There were surprises.
The “Dot Boom†then “Dot Bust†along with Y2K.
Microsoft developed an architecture, Active Directory, designed to support Enterprise scale deployments.
Everything Good in A.D. is Old (LDAP, Kerberos, DNS)
everything badly done is New (replicated DB’s & ???).
Other surprises is the rise of “Internet Scale†datacentres, Social Media and Smartphones & Tablets.
All of which are dominated by Linux or Unix derived solutions.
And Virtual Machines on Intel.
IA-64 was in the far future :(
And ARM CPU’s made a big comeback.
==========
The Sourceware Operating System Proposal
9 November 1993
Revision: 1.8
<https://www.landley.net/history/mirror/unix/srcos.html>
==========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
From lm at mcvoy.com Thu Nov 10 08:16:48 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 9 Nov 2022 14:16:48 -0800
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
Message-ID: <20221109221648.GS6203@mcvoy.com>
On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote:
> I???ve only recently stumbled across this paper.
>
> It gives the answer to one question I???ve had:
>
> Why did Linux become more popular than everything that came before it?
Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server
hardware) didn't like the switch from SunOS to SVR4 any more than I did.
He paid me to go argue with the execs for 6 months. That paper was
the result.
It obviously went nowhere and Linux won. Big surprise.
The one thing I learned in that 6 months was respect for the execs.
As an engineer, I had the luxury of taking the time to solve a problem and
know that I solved it correctly. The execs didn't have that. They had
to make decisions essentially with their gut, they couldn't afford the
time to figure out the right answer, they had to come up with the right
answer on the fly. I don't think I could do that.
From clemc at ccc.com Thu Nov 10 08:24:05 2022
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Nov 2022 17:24:05 -0500
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <20221109221648.GS6203@mcvoy.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
Message-ID: <CAC20D2OOQb=02w5JxcN5q5a4_EaWj0KU2Ru3BoPzWiT=-bHQvQ@mail.gmail.com>
On Wed, Nov 9, 2022 at 5:16 PM Larry McVoy <lm at mcvoy.com> wrote:
> Yeah, that was a difficult time.
>
Amen bro ...
Corporate pride -- but you were right. In the end, it comes down to:
Simple Economics matters more the Sophisticated Engineering but corporate
pride wanted to believe my cool engineering is going to crush the
competition.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221109/95a142ea/attachment.htm>
From joseph at josephholsten.com Thu Nov 10 08:51:53 2022
From: joseph at josephholsten.com (Joseph Holsten)
Date: Wed, 09 Nov 2022 14:51:53 -0800
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <20221109221648.GS6203@mcvoy.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
Message-ID: <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
On Wed, Nov 9, 2022, at 14:16, Larry McVoy wrote:
> On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote:
>> I???ve only recently stumbled across this paper.
>>
>> It gives the answer to one question I???ve had:
>>
>> Why did Linux become more popular than everything that came before it?
>
> Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server
> hardware) didn't like the switch from SunOS to SVR4 any more than I did.
> He paid me to go argue with the execs for 6 months. That paper was
> the result.
>
> It obviously went nowhere and Linux won. Big surprise.
>
> The one thing I learned in that 6 months was respect for the execs.
> As an engineer, I had the luxury of taking the time to solve a problem and
> know that I solved it correctly. The execs didn't have that. They had
> to make decisions essentially with their gut, they couldn't afford the
> time to figure out the right answer, they had to come up with the right
> answer on the fly. I don't think I could do that.
It’s painful to look at where (Open)Solaris was when Oracle acquired it and where it is now. SMF, Zones, ZFS, dtrace, mdb. Oracle Cloud doesn’t use Solaris for anything. I can’t recall hearing anyone using dtrace or ZFS around the place.
Meanwhile, illumos derivs have actually done interesting things. Not that NexenStor or SmartOS have made a big dent, but at least they’ve had more recent ideas to copy.
--
Joseph Holsten
http://josephholsten.com
mailto:joseph at josephholsten.com
tel:+1-360-927-7234
From tuhs at tuhs.org Thu Nov 10 10:47:37 2022
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Thu, 10 Nov 2022 00:47:37 +0000
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
Message-ID: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
What I find incredibly interesting any time the concept of fragmentation comes up is how did several versions of UNIX with slightly differing interfaces create such a headache for UNIX vendors and users in the day, but now we've got a Linux/BSD landscape out there with still pretty significant differences between distributions and UNIX's progeny seem to be doing just fine.
Were users looking for different things from their computers in the 90s vs today? Have folks just gotten more used to variability in computing environments and just accept it as part of the plan?
What comes to mind for me is the different init systems, desktop environments, networking tools, user management tools, and basically that anything that isn't lore in POSIX seems to be up in the air these days. However, you go back to when SVR4 derivatives were king, they all had the same init, the same useradd, the same /etc/passwd, the same ifconfig. Maybe some of the snazzier new features were pretty variable, but the most basic stuff like starting your system, creating a user, seeing if you were connected to a network, essential administrative functions, were relatively consistent.
Nowadays I have to wonder if my init system is runlevel based or some systemd monstrosity. I have to question whether I can rely on useradd or some other tool being present or if I should forgo it all and just edit the /etc files directly. Heck, I couldn't say which but I seem to recall a distro I played around with in the past year where this actually didn't work, I had to research whatever arcane user management tools they shipped with that one because whatever they chose broke with convention so much. I have to pray it has ifconfig or else go look up the docs for iproute2 and iw because nobody can make up their mind on what to replace ifconfig with, just that it has to go and replacing it haphazardly and non-universally is better than fixing/modernizing it.
Not looking to start some great debate over which of these components is ideal of course, just remarking at the fact that in the early 90s, if you were on a contemporary UNIX system, you'd probably have no trouble modifying system init, adding users, networks, etc., but today I sit down at an unknown Linux machine and I have no confidence that the particular flavor of system administration that I'm used to will be even remotely represented in the subset of tools that particular distro ships. Luckily, it's free, so perhaps that is what has made the difference, folks are more willing to deal with variability when they aren't paying for what should be a consistent experience, but regardless, the fragmentation in Linux world today feels like it is much more severe than UNIX was in the past, but that's also looking through a lens upon a time I certainly wasn't cognizant of this stuff in.
Anywho, that was definitely an informative read, thanks for the share. As someone who is constantly trying to dial in my own personal Linux distro, the questions of standardization and uniformity feature in my mind often.
- Matt G.
------- Original Message -------
On Wednesday, November 9th, 2022 at 2:51 PM, Joseph Holsten <joseph at josephholsten.com> wrote:
> On Wed, Nov 9, 2022, at 14:16, Larry McVoy wrote:
>
> > On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote:
> >
> > > I???ve only recently stumbled across this paper.
> > >
> > > It gives the answer to one question I???ve had:
> > >
> > > Why did Linux become more popular than everything that came before it?
> >
> > Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server
> > hardware) didn't like the switch from SunOS to SVR4 any more than I did.
> > He paid me to go argue with the execs for 6 months. That paper was
> > the result.
> >
> > It obviously went nowhere and Linux won. Big surprise.
> >
> > The one thing I learned in that 6 months was respect for the execs.
> > As an engineer, I had the luxury of taking the time to solve a problem and
> > know that I solved it correctly. The execs didn't have that. They had
> > to make decisions essentially with their gut, they couldn't afford the
> > time to figure out the right answer, they had to come up with the right
> > answer on the fly. I don't think I could do that.
>
>
> It’s painful to look at where (Open)Solaris was when Oracle acquired it and where it is now. SMF, Zones, ZFS, dtrace, mdb. Oracle Cloud doesn’t use Solaris for anything. I can’t recall hearing anyone using dtrace or ZFS around the place.
>
> Meanwhile, illumos derivs have actually done interesting things. Not that NexenStor or SmartOS have made a big dent, but at least they’ve had more recent ideas to copy.
>
> --
> Joseph Holsten
> http://josephholsten.com
> mailto:joseph at josephholsten.com
> tel:+1-360-927-7234
From joseph at josephholsten.com Thu Nov 10 10:54:02 2022
From: joseph at josephholsten.com (Joseph Holsten)
Date: Wed, 09 Nov 2022 16:54:02 -0800
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
Message-ID: <824c5873-bde9-4cf7-b33a-0f7e352e786d@app.fastmail.com>
On Wed, Nov 9, 2022, at 16:47, segaloco wrote:
> Nowadays I have to wonder if my init system is runlevel based or some
> systemd monstrosity.
Ah, the good old days when we just got annoyed at sysvinit vs bsdinit.
--
Joseph Holsten
http://josephholsten.com
mailto:joseph at josephholsten.com
tel:+1-360-927-7234
From davida at pobox.com Thu Nov 10 11:28:49 2022
From: davida at pobox.com (David Arnold)
Date: Thu, 10 Nov 2022 12:28:49 +1100
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
Message-ID: <E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com>
> On 10 Nov 2022, at 11:47, segaloco via TUHS <tuhs at tuhs.org> wrote:
>
> What I find incredibly interesting any time the concept of fragmentation comes up is how did several versions of UNIX with slightly differing interfaces create such a headache for UNIX vendors and users in the day, but now we've got a Linux/BSD landscape out there with still pretty significant differences between distributions and UNIX's progeny seem to be doing just fine.
>
> Were users looking for different things from their computers in the 90s vs today? Have folks just gotten more used to variability in computing environments and just accept it as part of the plan?
Two things, I think:
a) Today most identifiably Unix software is “sourcewareâ€, and so the differences between Linuxes, *BSD, and macOS are fairly easily taken care of (eg. with autotools).
b) A lot of Unix software is now distributed (more or less) by the OS vendor. Packaging has hidden the portability problem from the end user.
> What comes to mind for me is the different init systems, desktop environments, networking tools, user management tools, and basically that anything that isn't lore in POSIX seems to be up in the air these days. However, you go back to when SVR4 derivatives were king, they all had the same init, the same useradd, the same /etc/passwd, the same ifconfig. Maybe some of the snazzier new features were pretty variable, but the most basic stuff like starting your system, creating a user, seeing if you were connected to a network, essential administrative functions, were relatively consistent.
>
> Nowadays I have to wonder if my init system is runlevel based or some systemd monstrosity. I have to question whether I can rely on useradd or some other tool being present or if I should forgo it all and just edit the /etc files directly. Heck, I couldn't say which but I seem to recall a distro I played around with in the past year where this actually didn't work, I had to research whatever arcane user management tools they shipped with that one because whatever they chose broke with convention so much. I have to pray it has ifconfig or else go look up the docs for iproute2 and iw because nobody can make up their mind on what to replace ifconfig with, just that it has to go and replacing it haphazardly and non-universally is better than fixing/modernizing it.
>
> Not looking to start some great debate over which of these components is ideal of course, just remarking at the fact that in the early 90s, if you were on a contemporary UNIX system, you'd probably have no trouble modifying system init, adding users, networks, etc., but today I sit down at an unknown Linux machine and I have no confidence that the particular flavor of system administration that I'm used to will be even remotely represented in the subset of tools that particular distro ships. Luckily, it's free, so perhaps that is what has made the difference, folks are more willing to deal with variability when they aren't paying for what should be a consistent experience, but regardless, the fragmentation in Linux world today feels like it is much more severe than UNIX was in the past, but that's also looking through a lens upon a time I certainly wasn't cognizant of this stuff in.
iOS and Android are the most popular end-user Unix systems. None of these concerns matter there — they’ve got two completely incompatible layered APIs that hide the fact they’re Unix from applications and users.
Even if you restrict the discussion to non-mobile systems, macOS and ChromeOS probably top the list for end-user systems. Again, none of these concerns matter. I mention this to make the point that “Unix†is not what it once was, both in technical terms, and in commercial success.
d
From lm at mcvoy.com Thu Nov 10 11:42:35 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 9 Nov 2022 17:42:35 -0800
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
Message-ID: <20221110014235.GE31250@mcvoy.com>
On Thu, Nov 10, 2022 at 12:47:37AM +0000, segaloco via TUHS wrote:
> What comes to mind for me is the different init systems, desktop
> environments, networking tools, user management tools, and basically that
> anything that isn't lore in POSIX seems to be up in the air these days.
> However, you go back to when SVR4 derivatives were king, they all had the
> same init, the same useradd, the same /etc/passwd, the same ifconfig.
> Maybe some of the snazzier new features were pretty variable, but the
> most basic stuff like starting your system, creating a user, seeing if
> you were connected to a network, essential administrative functions,
> were relatively consistent.
This is sooooo not true. I was supporting BitKeeper on all Unix
variations as well as MacOS and Windows from about 2000 to 2018ish.
At the very least you had BSD based systems and Sys5 based systems but
the Sys5 systems had all diverged. AIX had smit for admin, other systems
would let you edit the /etc files but they were in different locations.
ifconfig was most definitely not compatible across all the systems, nor
was ps. There were tons and tons of differences. We ended up pulling in
NetBSDs libc so we at least had one libc (we didn't use the native libc,
yep, you read that right, even that was incompatible).
Even /etc/passwd wasn't consist, some places had /etc/shadow that had the
passwords (I think, it's all getting blurry), and I think there was one,
probably AIX, that had /etc/shadow but not in /etc/shadow.
The best way I can explain all of this is a lack of a dictator over
all the versions. You need someone who is pushing back on changes and
is making everything consistent. That's hard to do within a single
organization and impossible over multiple organizations. POSIX tried
but it wasn't enough. It helped a little. If it had worked, we wouldn't
have needed to ship our own libc.
From kevin.bowling at kev009.com Thu Nov 10 14:00:23 2022
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 9 Nov 2022 21:00:23 -0700
Subject: [TUHS] Keynote Language - Tim Thompson
In-Reply-To: <CAHrGxA1UzVDH9qXdUUW3HDdZ2y8nmiSHaE7bkAQhU2opxeLw5g@mail.gmail.com>
References: <CAK7dMtB2UxquSVkBC=dUdE_8+Gf5rTSAnNu_u_WxVPmRmKk5KA@mail.gmail.com>
<CAHrGxA1UzVDH9qXdUUW3HDdZ2y8nmiSHaE7bkAQhU2opxeLw5g@mail.gmail.com>
Message-ID: <CAK7dMtADPRkCJB_jGe9t3bBmEXpZpeaTbQr0-tG1N+g6NvCQRQ@mail.gmail.com>
On Wed, Nov 9, 2022 at 12:47 AM Matt Day <fjarlq at gmail.com> wrote:
> Yes, it became KeyKit: https://github.com/nosuchtim/keykit
>
> Tim recorded a demo video of Keynote in 1994:
> https://www.youtube.com/watch?v=-c-O57J9W-E
>
> His website: https://timthompson.com/tjt/
>
Brilliant, thank you!
> On Tue, Nov 8, 2022 at 7:03 PM Kevin Bowling <kevin.bowling at kev009.com>
> wrote:
>
>> Does anyone know if this made it outside the labs?
>>
>> https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf
>>
>> I have a rack of outboard synths and samplers, it would be
>> entertaining to run them with an awk-analogue.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221109/ebb22a52/attachment.htm>
From tytso at mit.edu Thu Nov 10 16:14:35 2022
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 10 Nov 2022 01:14:35 -0500
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
<E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com>
Message-ID: <Y2yWy8BYFxFiIy4D@mit.edu>
On Thu, Nov 10, 2022 at 12:28:49PM +1100, David Arnold wrote:
> > On 10 Nov 2022, at 11:47, segaloco via TUHS <tuhs at tuhs.org> wrote:
> >
> > What I find incredibly interesting any time the concept of
> > fragmentation comes up is how did several versions of UNIX with
> > slightly differing interfaces create such a headache for UNIX
> > vendors and users in the day, but now we've got a Linux/BSD
> > landscape out there with still pretty significant differences
> > between distributions and UNIX's progeny seem to be doing just
> > fine.
> >
> > Were users looking for different things from their computers in
> > the 90s vs today? Have folks just gotten more used to variability
> > in computing environments and just accept it as part of the plan?
>
> Two things, I think:
>
> a) Today most identifiably Unix software is “sourcewareâ€, and so the
> > differences between Linuxes, *BSD, and macOS are fairly easily
> > taken care of (eg. with autotools).
I'd also argue that (a) the differences between the Linuxes aren't as
big some people would make it out to be --- especially compared to the
differences between AIX and Solaris and HPUX, and (b) *BSD and macOS
has their ports and homebrew systems which also ease any pai that
isn't handled by autoconf and friends.
> b) A lot of Unix software is now distributed (more or less) by the
> OS vendor. Packaging has hidden the portability problem from the
> end user.
In addition to that, a lot of user-desired functionality is made
available via dynamic web "appliances" (e.g., GMail, Concur for those
people who need to submit travel reports) as opposed to compiled
binaries. I'm talking about pure web applications, of course, not
Java web apps.
My horror store from when I was working at IBM was that their expense
reporting tool was written in Java, but it only worked with the Sun
JRE. But if you needed to use to configure an IBM Bladeserver, that
only worked with the IBM JRE. So if I needed to submit an expense
report, I had to kill the browser, set the environment variables to
point at the Sun JRE, and then restart the browser and do the travel
report. And then when I needed to go back to messing with a Blade
Server chasis, I had to kill the browser, and reset the environment
variables, and then restart the browser.
Ah, Java.... write once, debug everywhere. :-)
- Ted
From davida at pobox.com Thu Nov 10 19:12:32 2022
From: davida at pobox.com (David Arnold)
Date: Thu, 10 Nov 2022 20:12:32 +1100
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <Y2yWy8BYFxFiIy4D@mit.edu>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
<E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com> <Y2yWy8BYFxFiIy4D@mit.edu>
Message-ID: <FCEE2FB2-2FB0-43B1-9CCC-9637DD6B13B8@pobox.com>
> On 10 Nov 2022, at 17:14, Theodore Ts'o <tytso at mit.edu> wrote:
> On Thu, Nov 10, 2022 at 12:28:49PM +1100, David Arnold wrote:
>> a) Today most identifiably Unix software is “sourcewareâ€, and so the
>> differences between Linuxes, *BSD, and macOS are fairly easily
>> taken care of (eg. with autotools).
>
> I'd also argue that (a) the differences between the Linuxes aren't as
> big some people would make it out to be --- especially compared to the
> differences between AIX and Solaris and HPUX, and (b) *BSD and macOS
> has their ports and homebrew systems which also ease any pai that
> isn't handled by autoconf and friends.
I agree.
The differences between desktop/server Linux distributions are largely invisible to application code. THe most obvious exceptions are locations for files. I’ve found it’s basically easier to deal with that dynamically (in the application code), rather than doing an autoconf-based distro switch. Init script vs. units, etc, are minor issues too.
Sometimes I’ve found a particular platform doesn’t have a package for eg. the right SSL library, or the right version of something, but that’s fairly rare, and mostly able to be worked around by being conservative in dependency choices.
Alpine’s use of musl rather than glibc was a bigger problem, but musl is increasingly glibc compatible. Other libc versions used by embedded platforms, create more problems, but then those applications tend to be fairly narrowly targeted anyway.
But all that said … it’s a heap easier than making source code compile across every common Unix in the mid-to-late 90’s.
d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221110/da744553/attachment-0001.htm>
From tuhs at tuhs.org Thu Nov 10 23:27:29 2022
From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS)
Date: Thu, 10 Nov 2022 14:27:29 +0100
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <FCEE2FB2-2FB0-43B1-9CCC-9637DD6B13B8@pobox.com> (David Arnold's
message of "Thu, 10 Nov 2022 20:12:32 +1100")
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
<E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com>
<Y2yWy8BYFxFiIy4D@mit.edu>
<FCEE2FB2-2FB0-43B1-9CCC-9637DD6B13B8@pobox.com>
Message-ID: <m28rkjj5xa.fsf@thuvia.hamartun.priv.no>
David Arnold <davida at pobox.com> writes:
> But all that said … it’s a heap easier than making source code compile
> across every common Unix in the mid-to-late 90’s.
"Congratulations! You're not running Eunice." :)
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
From clemc at ccc.com Fri Nov 11 01:33:13 2022
From: clemc at ccc.com (Clem Cole)
Date: Thu, 10 Nov 2022 10:33:13 -0500
Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was
right & any surprises?
In-Reply-To: <Y2yWy8BYFxFiIy4D@mit.edu>
References: <C84CDF4C-28C5-41F3-B144-8CA02B8C8E00@canb.auug.org.au>
<20221109221648.GS6203@mcvoy.com>
<314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com>
<xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>
<E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com> <Y2yWy8BYFxFiIy4D@mit.edu>
Message-ID: <CAC20D2Pw224fiy1x3j2QoDLoyVy4QjCEAt36pueaA-MnU3t3xw@mail.gmail.com>
On Thu, Nov 10, 2022 at 1:14 AM Theodore Ts'o <tytso at mit.edu> wrote:
> I'd also argue that (a) the differences between the Linuxes aren't as big
> some people would make it out to be
>
It's all a matter of degree and what things bite you. This is why we had
to develop the cluster checker because Linux is all over the place
>>still<< -- one famous ISV had 144 possible differences between 'standard'
Linux cluster configurations they needed to test. BTW: that had been a
developer during the UNIX wars and pure Fortran on VMS/IBM etc days. I
suspect they would claim it was not much better for them.
Is it better in some areas? Sure, in another no. It depends if it's
something that bites you and you care about. Things like the "systemd
wars" did not help which I would contend was not much less glorious that
the Unix wars -- just different players. In the end, it's all about who
is making the call of what is different/what is changing. I'm too old to
get too religious about this.
The 'sameness' is because of UNIX not because of Linux. Ken and Dennis's
core ideas created an industry and set of systems that are all 'close
enough that we all can get work done. In the end, at any given time, one
group or any other will have the incentive to have their way lead the
market - and the hard part for many of us to accept is that the incentive
is most often *economic not technical*.
Larry's old paper nailed the basic issue. It was use the core ideas of
Ken and Dennis - (call it anything you want) - and make it freely available
to remove the economic barriers. This is what Linux exploited, and that
is what made it successful. I'm pleased to say, that Larry's 'Sourceware'
came about --> today its in the form of Linux. But the ideas (the core IP)
is called UNIX. And yes there are specific differences. But in general;
they are close enough.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221110/083a3d90/attachment.htm>
From clemc at ccc.com Sun Nov 13 01:54:16 2022
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Nov 2022 10:54:16 -0500
Subject: [TUHS] DG UNIX History
Message-ID: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
This recent activity on the simh mailing list WRT to DG Nova and
Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of
work with DG and DG-UX with their later MP-based ports using commercially
available microprocessors (which I have reported was a very nicely done
system, easy to work on, the locks tended to scale well, e*tc*.).
But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This
could be my failed memory, given that so many people ported V7 in the late
1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
favorite tale). So to the hive mind, did anyone (DG themselves or a
University) ever build 16 or 32-bit tools for the DG architectures and do a
UNIX port, and if so, does anyone know what became of those efforts? Is
this something that needs to be in the TUHS archives also?
Clem
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/2c3d956d/attachment.htm>
From lm at mcvoy.com Sun Nov 13 02:09:40 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 12 Nov 2022 08:09:40 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
Message-ID: <20221112160940.GI652@mcvoy.com>
I dunno. I've heard DG did a pretty much from the ground up rewrite of
Unix to make it scale well on SMP machines. I've never seen the source
or used DG-UX, so it's all heresay. If anyone has more info than what
Clem said, I'm all ears.
The reason I'm interested is the original model of disabling interrupts
really isn't pleasant on an SMP but people tried to evolve it towards
something that scaled. It seems like DG went at it starting over,
designing SMP in from the start. Be interesting to understand what
they did. Sequent as well.
On Sat, Nov 12, 2022 at 10:54:16AM -0500, Clem Cole wrote:
> This recent activity on the simh mailing list WRT to DG Nova and
> Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of
> work with DG and DG-UX with their later MP-based ports using commercially
> available microprocessors (which I have reported was a very nicely done
> system, easy to work on, the locks tended to scale well, e*tc*.).
>
> But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This
> could be my failed memory, given that so many people ported V7 in the late
> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
> favorite tale). So to the hive mind, did anyone (DG themselves or a
> University) ever build 16 or 32-bit tools for the DG architectures and do a
> UNIX port, and if so, does anyone know what became of those efforts? Is
> this something that needs to be in the TUHS archives also?
>
> Clem
> ???
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From arnold at skeeve.com Sun Nov 13 02:52:05 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 12 Nov 2022 09:52:05 -0700
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
Message-ID: <202211121652.2ACGq6Pf015000@freefriends.org>
I'm pretty sure that DG never ported DG-UX to the Nova. There was
a native port to the Eclipse (32 bit). There was also a Eunice-style
Unix environment that sat on top of their native OS, whatever it was
called.
When I was working there, DG gave the Georgia Tech School of Information
and Computer Science an Eclipse running their native OS in the early
mid-80s. I didn't do much with it, and I suspect that nobody else there
did either.
I'm bcc-ing Scott Lee, who was the admin for that machine at the time;
maybe he remembers more.
There was a guy who worked at DG and contributed a lot of the Motorola
88000 code to GCC whose name I don't remember, although I met him
at a USENIX. If someone else remembers who this is, maybe he can
be tracked down for more info.
DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC.
In any case, DG-UX on the Eclipse preceded it on the 88000.
I hope this helps,
Arnold
P.S. For the youngsters here who've never heard of it, I highly
recommend Tracy Kidder's "The Soul of a New Machine" about the
development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
It was originally written in 1982 - 40 years ago!
Clem Cole <clemc at ccc.com> wrote:
> This recent activity on the simh mailing list WRT to DG Nova and
> Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of
> work with DG and DG-UX with their later MP-based ports using commercially
> available microprocessors (which I have reported was a very nicely done
> system, easy to work on, the locks tended to scale well, e*tc*.).
>
> But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This
> could be my failed memory, given that so many people ported V7 in the late
> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
> favorite tale). So to the hive mind, did anyone (DG themselves or a
> University) ever build 16 or 32-bit tools for the DG architectures and do a
> UNIX port, and if so, does anyone know what became of those efforts? Is
> this something that needs to be in the TUHS archives also?
>
> Clem
> ???
From lm at mcvoy.com Sun Nov 13 03:05:03 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 12 Nov 2022 09:05:03 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
Message-ID: <20221112170503.GL652@mcvoy.com>
On Sat, Nov 12, 2022 at 09:52:05AM -0700, arnold at skeeve.com wrote:
> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
>
> It was originally written in 1982 - 40 years ago!
That's a great read, +1.
From miod at online.fr Sun Nov 13 03:09:32 2022
From: miod at online.fr (Miod Vallat)
Date: Sat, 12 Nov 2022 17:09:32 +0000
Subject: [TUHS] DG UNIX History
In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
Message-ID: <Y2/TTKYPgWCiNwSS@tarentaine.gentiane.org>
> There was a guy who worked at DG and contributed a lot of the Motorola
> 88000 code to GCC whose name I don't remember, although I met him
> at a USENIX. If someone else remembers who this is, maybe he can
> be tracked down for more info.
I suppose you're referring to Tom Wood here?
> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
>
> It was originally written in 1982 - 40 years ago!
Seconded - definitely a must read; even if technology has evolved a lot
since then, management and human factors have not.
Miod
From david at kdbarto.org Sun Nov 13 03:13:09 2022
From: david at kdbarto.org (David Barto)
Date: Sat, 12 Nov 2022 09:13:09 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
Message-ID: <CB43EA47-552F-4116-8091-2ABE3E0C2E37@kdbarto.org>
I worked on the DG-UX software porting device drivers to it.
It wasn’t a Unix port, it was a complete re-write from the ground up.
The interfaces to the drivers was different and the internal locking mechanisms
were unique to the OS. I’d never seen anything like it before, or after.
David
> On Nov 12, 2022, at 8:52 AM, arnold at skeeve.com wrote:
>
> I'm pretty sure that DG never ported DG-UX to the Nova. There was
> a native port to the Eclipse (32 bit). There was also a Eunice-style
> Unix environment that sat on top of their native OS, whatever it was
> called.
>
> When I was working there, DG gave the Georgia Tech School of Information
> and Computer Science an Eclipse running their native OS in the early
> mid-80s. I didn't do much with it, and I suspect that nobody else there
> did either.
>
> I'm bcc-ing Scott Lee, who was the admin for that machine at the time;
> maybe he remembers more.
>
> There was a guy who worked at DG and contributed a lot of the Motorola
> 88000 code to GCC whose name I don't remember, although I met him
> at a USENIX. If someone else remembers who this is, maybe he can
> be tracked down for more info.
>
> DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC.
>
> In any case, DG-UX on the Eclipse preceded it on the 88000.
>
> I hope this helps,
>
> Arnold
>
> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
>
> It was originally written in 1982 - 40 years ago!
>
> Clem Cole <clemc at ccc.com> wrote:
>
>> This recent activity on the simh mailing list WRT to DG Nova and
>> Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of
>> work with DG and DG-UX with their later MP-based ports using commercially
>> available microprocessors (which I have reported was a very nicely done
>> system, easy to work on, the locks tended to scale well, e*tc*.).
>>
>> But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This
>> could be my failed memory, given that so many people ported V7 in the late
>> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
>> favorite tale). So to the hive mind, did anyone (DG themselves or a
>> University) ever build 16 or 32-bit tools for the DG architectures and do a
>> UNIX port, and if so, does anyone know what became of those efforts? Is
>> this something that needs to be in the TUHS archives also?
>>
>> Clem
>> ???
From imp at bsdimp.com Sun Nov 13 03:12:54 2022
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 12 Nov 2022 10:12:54 -0700
Subject: [TUHS] DG UNIX History
In-Reply-To: <Y2/TTKYPgWCiNwSS@tarentaine.gentiane.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
<Y2/TTKYPgWCiNwSS@tarentaine.gentiane.org>
Message-ID: <CANCZdfrq6vu8H7=mbPtA2Q4BjtsasPQfOskT0fpJ1qFxNb7zPQ@mail.gmail.com>
On Sat, Nov 12, 2022, 10:10 AM Miod Vallat <miod at online.fr> wrote:
> > There was a guy who worked at DG and contributed a lot of the Motorola
> > 88000 code to GCC whose name I don't remember, although I met him
> > at a USENIX. If someone else remembers who this is, maybe he can
> > be tracked down for more info.
>
> I suppose you're referring to Tom Wood here?
>
> > P.S. For the youngsters here who've never heard of it, I highly
> > recommend Tracy Kidder's "The Soul of a New Machine" about the
> > development of the Eclipse. (
> https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1
> ).
> >
> > It was originally written in 1982 - 40 years ago!
>
> Seconded - definitely a must read; even if technology has evolved a lot
> since then, management and human factors have not.
>
Bring them in, burn them out, sweat every hour out of them... call it
excellence. Bah
Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/b97f2c8d/attachment.htm>
From brad at anduin.eldar.org Sun Nov 13 03:37:52 2022
From: brad at anduin.eldar.org (Brad Spencer)
Date: Sat, 12 Nov 2022 12:37:52 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> (arnold@skeeve.com)
Message-ID: <xonpmds3wgf.fsf@anduin.eldar.org>
arnold at skeeve.com writes:
> I'm pretty sure that DG never ported DG-UX to the Nova. There was
> a native port to the Eclipse (32 bit). There was also a Eunice-style
> Unix environment that sat on top of their native OS, whatever it was
> called.
AOS and then AOS/VS for the Eclipse. In the late 1980s and early 1990s
I messed a whole lot with AOS/VS at the university I was at. It was
very much Not Unix. Towards the end of my time there, a number of
programs that traditionally would be on a Unix system, things like
sendmail, ftpd, and etc.. were natively ported to AOS/VS. The ports
were probably done as best as they could have been, but they lacked a
whole lot of ability if I remember things correctly.
After I left, the university acquired a DG of some sort that ran DG-UX
(or DGUX).
[snip]
>
> Arnold
--
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org
From arnold at skeeve.com Sun Nov 13 03:39:58 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 12 Nov 2022 10:39:58 -0700
Subject: [TUHS] DG UNIX History
In-Reply-To: <Y2/TTKYPgWCiNwSS@tarentaine.gentiane.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
<Y2/TTKYPgWCiNwSS@tarentaine.gentiane.org>
Message-ID: <202211121739.2ACHdww1020587@freefriends.org>
Miod Vallat <miod at online.fr> wrote:
> > There was a guy who worked at DG and contributed a lot of the Motorola
> > 88000 code to GCC whose name I don't remember, although I met him
> > at a USENIX. If someone else remembers who this is, maybe he can
> > be tracked down for more info.
>
> I suppose you're referring to Tom Wood here?
That doesn't sound right... I wish I could remember. :-(
Arnold
From clemc at ccc.com Sun Nov 13 04:04:30 2022
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Nov 2022 13:04:30 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
Message-ID: <CAC20D2MCu5Jub+++eQauYcoxxHia5xUbf9aPF9Jfwx2GNfCeZg@mail.gmail.com>
On Sat, Nov 12, 2022 at 11:52 AM <arnold at skeeve.com> wrote:
>
>
> DG-UX was a pretty generic SVR3
>
User space was generic. But the SVR3/88K kernel was a heavy rewrite.
LCC did a lot of work with DG adding stuff too it -- it was very well done
by the DG team in NC. The memory and FS was well integrated. Of all the
UNIX kernels we did work, it was pretty much the easiest to learn and
modify.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/b5365751/attachment.htm>
From lm at mcvoy.com Sun Nov 13 04:36:23 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 12 Nov 2022 10:36:23 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2MCu5Jub+++eQauYcoxxHia5xUbf9aPF9Jfwx2GNfCeZg@mail.gmail.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
<CAC20D2MCu5Jub+++eQauYcoxxHia5xUbf9aPF9Jfwx2GNfCeZg@mail.gmail.com>
Message-ID: <20221112183623.GO652@mcvoy.com>
On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote:
> On Sat, Nov 12, 2022 at 11:52 AM <arnold at skeeve.com> wrote:
> > DG-UX was a pretty generic SVR3
> >
> User space was generic. But the SVR3/88K kernel was a heavy rewrite.
> LCC did a lot of work with DG adding stuff too it -- it was very well done
> by the DG team in NC. The memory and FS was well integrated.
So read()/write()/mmap() all shared the same cache like SunOS? In SunOS the
only things not in the page cache were directories and inodes. All data
pages had one, and only one, place to be (ZFS broke this in Solaris,
which has always blown my mind).
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From arnold at skeeve.com Sun Nov 13 04:51:46 2022
From: arnold at skeeve.com (Arnold Robbins)
Date: Sat, 12 Nov 2022 20:51:46 +0200
Subject: [TUHS] the rise of discmaster.textfiles.com
Message-ID: <E1otvbW-0002lr-FY@tanda>
http://blog.archive.org/2022/10/24/the-rise-of-discmaster/
There seems to be lots of different vendor unix stuff here, as well
as many other things.
Arnold
From dave at horsfall.org Sun Nov 13 05:16:44 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 13 Nov 2022 06:16:44 +1100 (EST)
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2211130613290.43868@aneurin.horsfall.org>
On Sat, 12 Nov 2022, Clem Cole wrote:
[ ... ]
> (the infamous 'NUIX' bug from the Series/1 port probably being my
> favorite tale).
That would be the "NUXI" bug (byte-swapped words).
> So to the hive mind, did anyone (DG themselves or a University) ever
> build 16 or 32-bit tools for the DG architectures and do a UNIX port,
> and if so, does anyone know what became of those efforts? Is this
> something that needs to be in the TUHS archives also?
I remember Tracey Kidder's "The Soul of a New Machine"... It ran some
proprietary system, though.
-- Dave
From clemc at ccc.com Sun Nov 13 05:31:38 2022
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Nov 2022 14:31:38 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <alpine.BSF.2.21.9999.2211130613290.43868@aneurin.horsfall.org>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<alpine.BSF.2.21.9999.2211130613290.43868@aneurin.horsfall.org>
Message-ID: <CAC20D2PC_u_yHWRYwjf66wp9mndHJz5g0nA9Fiu-4fGj7h72rA@mail.gmail.com>
On Sat, Nov 12, 2022 at 2:16 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>
> That would be the "NUXI" bug (byte-swapped words).
>
Yep -- the reversal in my email was typo and then dyslexia on my part. ;-)
FYI: I was there when the guy from Cleveland State gave the paper. It was
a riot.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/7bbc0e2c/attachment.htm>
From clemc at ccc.com Sun Nov 13 05:36:05 2022
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Nov 2022 14:36:05 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <20221112183623.GO652@mcvoy.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
<CAC20D2MCu5Jub+++eQauYcoxxHia5xUbf9aPF9Jfwx2GNfCeZg@mail.gmail.com>
<20221112183623.GO652@mcvoy.com>
Message-ID: <CAC20D2PM8OVgoHLf96K-u4w2Dh02ELp-6vnczTtJKGnWowEhrg@mail.gmail.com>
To be honest, I've forgotten many (most) of the details. But that sounds
about right. As I remember it, it was like SunOS. The key point was that
the kernel only had one view of the memory system period, no FS
buffer cache etc...which was a departure from many of the traditional UNIX
implementations. IIRC they did not support BSD's mmap -- but check the
SVR3 docs to be sure -- they had the SVR3 user interfaces but none of the
BSD ones. They did support the System V shared memory, however. I do seem
to remember there was something funny in the driver interfaces, it was just
like UNIX only different, and that causes some heartache - but it was
fairly straightforward to move a DMA driver like getting a VME Xylogics
tape controller to work, but it took a little tweaking. I've forgotten
exactly why that was -- it's been a long time ago.
Clem
á§
On Sat, Nov 12, 2022 at 1:36 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote:
> > On Sat, Nov 12, 2022 at 11:52 AM <arnold at skeeve.com> wrote:
> > > DG-UX was a pretty generic SVR3
> > >
> > User space was generic. But the SVR3/88K kernel was a heavy rewrite.
> > LCC did a lot of work with DG adding stuff too it -- it was very well
> done
> > by the DG team in NC. The memory and FS was well integrated.
>
> So read()/write()/mmap() all shared the same cache like SunOS? In SunOS
> the
> only things not in the page cache were directories and inodes. All data
> pages had one, and only one, place to be (ZFS broke this in Solaris,
> which has always blown my mind).
> --
> ---
> Larry McVoy Retired to fishing
> http://www.mcvoy.com/lm/boat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/61f59411/attachment.htm>
From tuhs at tuhs.org Sun Nov 13 06:17:33 2022
From: tuhs at tuhs.org (Grant Taylor via TUHS)
Date: Sat, 12 Nov 2022 13:17:33 -0700
Subject: [TUHS] the rise of discmaster.textfiles.com
In-Reply-To: <E1otvbW-0002lr-FY@tanda>
References: <E1otvbW-0002lr-FY@tanda>
Message-ID: <256db5fa-dda2-8ab7-1a86-5b84bd52fe70@spamtrap.tnetconsulting.net>
On 11/12/22 11:51 AM, Arnold Robbins wrote:
> http://blog.archive.org/2022/10/24/the-rise-of-discmaster/
DiscMaster is EXTREMELY interesting.
I've been really enjoying it for two to three weeks. -- I think I saw
it within it's first week of official release.
I'm subscribing to the RSS feed of what's added on a near daily basis.
N.B. DiscMaster is indexing disk images found on Internet Archive.
DiscMaster is a different type of search engine / gateway to Internet
Archive contents.
> There seems to be lots of different vendor unix stuff here, as well
> as many other things.
Yep. There has been a LOT of vendor unix stuff on Internet Archive for
a long time. It was just a lot harder to find than it is via
DiscMaster's index thereof.
I've seen a lot of SGI Irix stuff as of late.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/8159e6db/attachment.p7s>
From dave at horsfall.org Sun Nov 13 10:02:05 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 13 Nov 2022 11:02:05 +1100 (EST)
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
Message-ID: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
I spotted this when glancing through a book catalogue; well, with a title
like that how could I miss it?
Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch
and illustrated by Kelly Chudler (can't say that I've heard of them).
Summary:
``Programming is behind so much of life today, and this book draws together
a group of distinguished thinkers and technologists to reveal the
stories and people behind the computer coding that shapes our
world. From how university's [sic] databases were set up to
recognise only two genders to the first computer worm and the
first pop-up ad, the diverse topics reveal the consequences of
historical decisions and their long-lasting, profound implications.
Pb $34.99''
Lines of code, eh? :-)
Abbey's Bookshop: www.abbeys.com.au
Disclaimer: I have no connection with them, but I'll likely buy it.
-- Dave
From kennethgoodwin56 at gmail.com Sun Nov 13 10:25:07 2022
From: kennethgoodwin56 at gmail.com (Kenneth Goodwin)
Date: Sat, 12 Nov 2022 19:25:07 -0500
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
Message-ID: <CAMQbRb3hYmvtLtXUwgutX_JhCm=3F=5M5o6h+iifu4yenkNtEw@mail.gmail.com>
Maybe it is just me, but I don't recognize any of the contributors listed
either at the bottom
On Sat, Nov 12, 2022, 7:20 PM Dave Horsfall <dave at horsfall.org> wrote:
> I spotted this when glancing through a book catalogue; well, with a title
> like that how could I miss it?
>
> Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch
> and illustrated by Kelly Chudler (can't say that I've heard of them).
>
> Summary:
>
> ``Programming is behind so much of life today, and this book draws together
> a group of distinguished thinkers and technologists to reveal the
> stories and people behind the computer coding that shapes our
> world. From how university's [sic] databases were set up to
> recognise only two genders to the first computer worm and the
> first pop-up ad, the diverse topics reveal the consequences of
> historical decisions and their long-lasting, profound implications.
> Pb $34.99''
>
> Lines of code, eh? :-)
>
> Abbey's Bookshop: www.abbeys.com.au
>
> Disclaimer: I have no connection with them, but I'll likely buy it.
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221112/7c11f373/attachment.htm>
From stuff at riddermarkfarm.ca Sun Nov 13 11:12:02 2022
From: stuff at riddermarkfarm.ca (Stuff Received)
Date: Sat, 12 Nov 2022 20:12:02 -0500
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
Message-ID: <ffe2e4bb-d2e2-695d-8b60-1c90e2c7f394@riddermarkfarm.ca>
On 2022-11-12 19:02, Dave Horsfall wrote:
> I spotted this when glancing through a book catalogue; well, with a title
> like that how could I miss it?
>
> Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch
> and illustrated by Kelly Chudler (can't say that I've heard of them).
>
> Summary:
>
> ``Programming is behind so much of life today, and this book draws together
> a group of distinguished thinkers and technologists to reveal the
> stories and people behind the computer coding that shapes our
> world. From how university's [sic] databases were set up to
> recognise only two genders to the first computer worm and the
> first pop-up ad, the diverse topics reveal the consequences of
> historical decisions and their long-lasting, profound implications.
> Pb $34.99''
>
> Lines of code, eh? :-)
>
> Abbey's Bookshop: www.abbeys.com.au
>
> Disclaimer: I have no connection with them, but I'll likely buy it.
>
> -- Dave
Does subscribe to COFF anymore? I mentioned this a few weeks ago on
COFF (https://minnie.tuhs.org/pipermail/coff/2022-October/001315.html)
with only one reply.
N.
From robpike at gmail.com Sun Nov 13 11:12:32 2022
From: robpike at gmail.com (Rob Pike)
Date: Sun, 13 Nov 2022 12:12:32 +1100
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <CAMQbRb3hYmvtLtXUwgutX_JhCm=3F=5M5o6h+iifu4yenkNtEw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
<CAMQbRb3hYmvtLtXUwgutX_JhCm=3F=5M5o6h+iifu4yenkNtEw@mail.gmail.com>
Message-ID: <CAKzdPgzAPB+-LjtZ+rhqRY8+Cdk4Fqks5hK1EdmShT_QbGHKjg@mail.gmail.com>
I find it fascinating how, just a few years after the difficulty of stack
switching required a commented challenge in the Unix source, we were using
setjmp and longjmp to do this with no fuss at all. Once the problem is
solved, the solution can simplify dramatically.
See https://github.com/plan9foundation/plan9/blob/main/sys/src/9/port/proc.c
for instance - almost all of sched is bookkeeping and a comment about
locks. The little burst at the bottom, starting around line 163, that does
the work is so compact. (setlabel and gotolabel are setjmp and longjmp.)
Insight.
-rob
On Sun, Nov 13, 2022 at 11:26 AM Kenneth Goodwin <kennethgoodwin56 at gmail.com>
wrote:
> Maybe it is just me, but I don't recognize any of the contributors listed
> either at the bottom
>
> On Sat, Nov 12, 2022, 7:20 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>> I spotted this when glancing through a book catalogue; well, with a title
>> like that how could I miss it?
>>
>> Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch
>> and illustrated by Kelly Chudler (can't say that I've heard of them).
>>
>> Summary:
>>
>> ``Programming is behind so much of life today, and this book draws
>> together
>> a group of distinguished thinkers and technologists to reveal the
>> stories and people behind the computer coding that shapes our
>> world. From how university's [sic] databases were set up to
>> recognise only two genders to the first computer worm and the
>> first pop-up ad, the diverse topics reveal the consequences of
>> historical decisions and their long-lasting, profound implications.
>> Pb $34.99''
>>
>> Lines of code, eh? :-)
>>
>> Abbey's Bookshop: www.abbeys.com.au
>>
>> Disclaimer: I have no connection with them, but I'll likely buy it.
>>
>> -- Dave
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221113/5efdf5c6/attachment.htm>
From lm at mcvoy.com Sun Nov 13 11:52:59 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 12 Nov 2022 17:52:59 -0800
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <CAKzdPgzAPB+-LjtZ+rhqRY8+Cdk4Fqks5hK1EdmShT_QbGHKjg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
<CAMQbRb3hYmvtLtXUwgutX_JhCm=3F=5M5o6h+iifu4yenkNtEw@mail.gmail.com>
<CAKzdPgzAPB+-LjtZ+rhqRY8+Cdk4Fqks5hK1EdmShT_QbGHKjg@mail.gmail.com>
Message-ID: <20221113015259.GJ9823@mcvoy.com>
On Sun, Nov 13, 2022 at 12:12:32PM +1100, Rob Pike wrote:
> See https://github.com/plan9foundation/plan9/blob/main/sys/src/9/port/proc.c
> for instance - almost all of sched is bookkeeping and a comment about
> locks. The little burst at the bottom, starting around line 163, that does
> the work is so compact. (setlabel and gotolabel are setjmp and longjmp.)
This reminds me of code I did for Udi Manber as a grad (or undergrad)
student. He wanted a user space threads library so I wrote one.
It's where I learned how to write swtch() where you enter as one thread
and exit as another one. 99% of the code was C that did all the stuff
you could do in C and then a small amount of assembler that did the flip.
I had heard that swtch() was hard but it really isn't that bad.
The assembler makes you learn that stuff but you need to know that stuff
anyway. I do agree with people who say you aren't a kernel engineer if
you haven't written, or at least understood, that code.
From lm at mcvoy.com Sun Nov 13 11:56:24 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 12 Nov 2022 17:56:24 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2PM8OVgoHLf96K-u4w2Dh02ELp-6vnczTtJKGnWowEhrg@mail.gmail.com>
References: <CAC20D2PCSN74fFWPo5TYOw2gB+cZnNfUTRMRdBMVEgEsKYA8fA@mail.gmail.com>
<202211121652.2ACGq6Pf015000@freefriends.org>
<CAC20D2MCu5Jub+++eQauYcoxxHia5xUbf9aPF9Jfwx2GNfCeZg@mail.gmail.com>
<20221112183623.GO652@mcvoy.com>
<CAC20D2PM8OVgoHLf96K-u4w2Dh02ELp-6vnczTtJKGnWowEhrg@mail.gmail.com>
Message-ID: <20221113015624.GM9823@mcvoy.com>
On Sat, Nov 12, 2022 at 02:36:05PM -0500, Clem Cole wrote:
> To be honest, I've forgotten many (most) of the details. But that sounds
> about right. As I remember it, it was like SunOS. The key point was that
> the kernel only had one view of the memory system period, no FS
> buffer cache etc...which was a departure from many of the traditional UNIX
> implementations. IIRC they did not support BSD's mmap -- but check the
It sounds like they could have supported mmap() easily. I'd love to see
this kernel, it sounds to me like it was SunOS with nicely done SMP
support. The guy that said he'd never seen anything like it before or
since, just makes me want to see it more.
I know someone who was friends with one of the kernel guys, haven't talked
to her in years but I'll see if I can find anything.
From dave at horsfall.org Mon Nov 14 07:58:14 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 14 Nov 2022 08:58:14 +1100 (EST)
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <ffe2e4bb-d2e2-695d-8b60-1c90e2c7f394@riddermarkfarm.ca>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
<ffe2e4bb-d2e2-695d-8b60-1c90e2c7f394@riddermarkfarm.ca>
Message-ID: <alpine.BSF.2.21.9999.2211140856110.43868@aneurin.horsfall.org>
On Sat, 12 Nov 2022, Stuff Received wrote:
> Does subscribe to COFF anymore? I mentioned this a few weeks ago on
> COFF (https://minnie.tuhs.org/pipermail/coff/2022-October/001315.html)
> with only one reply.
Haven't seen anything from COFF for some weeks now; anyway I figured that
is was more "historical Unix" than "old geezer" stuff, hence TUHS.
-- Dave
From arnold at skeeve.com Mon Nov 14 21:44:11 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 14 Nov 2022 04:44:11 -0700
Subject: [TUHS] DG UNIX History
Message-ID: <202211141144.2AEBiB1h017576@freefriends.org>
This is what Scott Lee, who ran the Eclipse at Georgia Tech
recalls. He has given permission for me to forward it, with
the caveat that it was long ago and that "memories are malleable".
Arnold
> Date: Mon, 14 Nov 2022 05:35:51 -0500
> Subject: Re: [TUHS] DG UNIX History
> From: scott at thelees.org
> To: arnold at skeeve.com
>
> > I'm pretty sure that DG never ported DG-UX to the Nova. There was
> > a native port to the Eclipse (32 bit). There was also a Eunice-style
> > Unix environment that sat on top of their native OS, whatever it was
> > called.
>
> Yeh, that was an MV-10000 that we received. As I remember it, we also got
> a copy of DG-UX, which was a port of SYS Vr2, not r3 as mentioned. I
> think that it may have also had a directory with UCB versions of a bunch
> of the utilities ported over so you could run either SysV tools or UCB
> tools.
>
> LeBlanc was going to use it to teach ADA, so I was building some tools to
> create/maintain user accounts, but I believe that I left just before they
> were actually getting around to that.
>
> I was also playing with it on the side, when no one else was using it, to
> build a small OS on it. I found that it followed a lot of the Nova
> behavior, so I figured out how to write code onto a tape and bootstrap it
> into the machine. Wrote a tape driver and a console driver and was
> working on a disk driver. Targeting putting a small OS on it.
>
> Wow... I had almost forgotten that it even existed until I saw this.
>
> Enjoy,
> Scott
From douglas.mcilroy at dartmouth.edu Tue Nov 15 00:14:28 2022
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Mon, 14 Nov 2022 09:14:28 -0500
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
Message-ID: <CAKH6PiXhVt6v_KSYcQjq=+rOORgd7d6NpftqTL+MYfW1b81y=g@mail.gmail.com>
>> To be honest, I've forgotten many (most) of the details. But that sounds
>> about right. As I remember it, it was like SunOS. The key point was that
>> the kernel only had one view of the memory system period, no FS
>> buffer cache etc...which was a departure from many of the traditional UNIX
>> implementations. IIRC they did not support BSD's mmap -- but check the
> It sounds like they could have supported mmap() easily. I'd love to see
> this kernel, it sounds to me like it was SunOS with nicely done SMP
> support. The guy that said he'd never seen anything like it before or
> since, just makes me want to see it more.
"One view of the memory, period." That describes Multics.
Doug
From clemc at ccc.com Tue Nov 15 01:50:29 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 14 Nov 2022 10:50:29 -0500
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <CAKH6PiXhVt6v_KSYcQjq=+rOORgd7d6NpftqTL+MYfW1b81y=g@mail.gmail.com>
References: <CAKH6PiXhVt6v_KSYcQjq=+rOORgd7d6NpftqTL+MYfW1b81y=g@mail.gmail.com>
Message-ID: <CAC20D2N7t4VQLaRGr+i0GQTySGEBfKDw5sK+es0gp+Jme_CB2g@mail.gmail.com>
On Mon, Nov 14, 2022 at 9:16 AM Douglas McIlroy <
douglas.mcilroy at dartmouth.edu> wrote:
> "One view of the memory, period." That describes Multics.
>
Yep -- but not surprising. There were a bunch of folks at DG that had
worked on a single-level store system (Project Fountain-Head) that had
failed [some of that story is described in Kidder's book]. They had studied
Multics extensively, and that system supposedly had taken a great deal from
it. I never completely knew what happened other than something went south
and it end up getting canceled. I later got to know of a number of the
MV10000 folks (who later joined us in the HW team at Stellar). But I
believe a bit issue with Fountain Head was both new HW and SW, whereas the
MV10000 allowed Nova /Eclipse code to 'just work.' [Kidder makes a big
deal out of this in the book].
The lessons and relevance to TUHS I think are a couple of things:
1.) When they did DG-UX, the SW folks had previously developed a kernel
with that view, so it's not surprising.
2.) Cost of >>solution development<< is the real end-customer/deployer
driver (economics beats architecture).
Clem
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221114/d791d6cd/attachment.htm>
From norman at oclsc.org Tue Nov 15 02:58:36 2022
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 14 Nov 2022 11:58:36 -0500 (EST)
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
Message-ID: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org>
Clem Cole:
Yep -- but not surprising. There were a bunch of folks at DG that had
worked on a single-level store system (Project Fountain-Head) that had
failed [some of that story is described in Kidder's book].
====
Are you sure? I thought Fountainhead was a Rand project.
Norman Wilson
Toronto ON
PS: if you don't get it, consider yourself fortunate.
From lm at mcvoy.com Tue Nov 15 05:17:39 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 Nov 2022 11:17:39 -0800
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org>
References: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org>
Message-ID: <20221114191739.GG16293@mcvoy.com>
On Mon, Nov 14, 2022 at 11:58:36AM -0500, Norman Wilson wrote:
> Clem Cole:
>
> Yep -- but not surprising. There were a bunch of folks at DG that had
> worked on a single-level store system (Project Fountain-Head) that had
> failed [some of that story is described in Kidder's book].
>
> ====
>
> Are you sure? I thought Fountainhead was a Rand project.
>
> Norman Wilson
> Toronto ON
>
> PS: if you don't get it, consider yourself fortunate.
I get it. Teenage me thought Rand was a genius, adult me changed his mind.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From dave at horsfall.org Tue Nov 15 05:50:11 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 Nov 2022 06:50:11 +1100 (EST)
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <20221114191739.GG16293@mcvoy.com>
References: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org>
<20221114191739.GG16293@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.2211150648280.95052@aneurin.horsfall.org>
On Mon, 14 Nov 2022, Larry McVoy wrote:
> > Are you sure? I thought Fountainhead was a Rand project.
> >
> > PS: if you don't get it, consider yourself fortunate.
>
> I get it. Teenage me thought Rand was a genius, adult me changed his
> mind.
I certainly had to think about it for a while...
-- Dave, getting off-topic
From pnr at planet.nl Tue Nov 15 08:11:36 2022
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 14 Nov 2022 23:11:36 +0100
Subject: [TUHS] DG UNIX History
Message-ID: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
> Date: Sat, 12 Nov 2022 17:56:24 -0800
> From: Larry McVoy <lm at mcvoy.com>
> Subject: [TUHS] Re: DG UNIX History
>
> It sounds like they could have supported mmap() easily. I'd love to see
> this kernel, it sounds to me like it was SunOS with nicely done SMP
> support. The guy that said he'd never seen anything like it before or
> since, just makes me want to see it more.
> I know someone who was friends with one of the kernel guys, haven't talked
> to her in years but I'll see if I can find anything.
Following on from the exchange on TUHS about DG-UX, it would seem to me that the (Unix) unified cache was invented at least three times for Unix:
- John Reiser at AT&T
- At Sun
- At DG
As to the latter I could find two leads that might help you finding out more. It would seem that this unique Unix is specifically DG-UX version 4:
https://web.archive.org/web/20070930212358/http://www.accessmylibrary.com/coms2/summary_0286-9202012_ITM
and
Michael H. Kelly and Andrew R. Huber, "Engineering a (Multiprocessor) Unix Kernel", Proceedings of the Autumn 1989 EUUG Conference, European Unix Systems User Group, Vienna, Austria, 1989, pp. 7- 19.
The unified cache isn’t mentioned, but it would seem that the multiprocessor redesign might have included it. Maybe the author names are helpful. I could not find the paper online, but there was a web page suggesting that a paper copy still exists in a (university?) library in Sweden.
=====
Publication: DG Review
Publication Date: 01-NOV-88
Author: Huber, Andrew R.
DG-UX 4.00: DG's redesigned kernel lays the foundation for future UNIX systems. (includes related article on DG-UX 4.00's file system and an excerpt from Judith S. Hurwitz's 'Data General's UNIX strategy: an evaluation' report)
COPYRIGHT 1988 New Media Publications
DG/UX 4.00
Revision 4.00 of Data General's native UNIX operating system siginificantly enhances the product and adds unique capabilities not found in other UNIX implementations. This article reviews the goals of DG/UX 4.00 and discusses some of its features.
When DG released DG/UX 1.00 in March, 1985, it was based on AT&T's System V Release 2 and incorporated the Berkeley UNIX file system and networking.
As DG/UX grew, it continued to incorporate functions of the major standard UNIX systems, as illustrated in the following timeline:
* DG/UX 1.00 March, 1985 Based on System V Release 2 and Berkely 4.1.
Included Berkely 4.2 file system and TCP/IP (LAN).
* DG/UX 2.00, September, 1985 Added Berkeley 4.2 system calls.
* DG/UX 3.00, April 1986 Added support for new DG hardware.
* DG/UX 3.10 March, 1987 Added Sun Microsystem's Network File System.sup.(R) Added X Windows.
* DG/UX 4.00, August, 1988 Re-designed and re-implemented kernel and file system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221114/d6c908f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: separator.gif
Type: image/gif
Size: 43 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221114/d6c908f8/attachment.gif>
From clemc at ccc.com Tue Nov 15 08:31:52 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 14 Nov 2022 17:31:52 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
Message-ID: <CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr at planet.nl> wrote:
> Following on from the exchange on TUHS about DG-UX, it would seem to me
> that the (Unix) unified cache was invented at least three times for Unix:
>
Not to quibble too much, but s/cache/memory/ I think is a fairer way of
saying that.
> - John Reiser at AT&T
> - At Sun
> - At DG
>
- At CMU (Mach)
The interesting thing again, is that while they while all of these
implementations seem to have been technologically 'better' - only Mach
lived on from the original developers. And in the case of Mach, by the
time it was mainstream (macOS) the original implementation had been
replaced a few times - so while the concepts are there, I don't think much
of the Original CMU code is left in XNU/Darwin [or for that matter in the
OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never
went anywhere either].
As I said, the lesson to TUHS -- as much as I'm a techie and I am
interested in the 'proper' way of doing things ... "good enough" is often
what rules.
It's too bad none of the good memory implementations made it into
>>systems<< that lasted.
Clem
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221114/a26aab26/attachment.htm>
From dave at horsfall.org Tue Nov 15 08:48:13 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 Nov 2022 09:48:13 +1100 (EST)
Subject: [TUHS] Book: "You Are Not Expected to Understand This"
In-Reply-To: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2211131046080.43868@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2211150946330.95052@aneurin.horsfall.org>
On Sun, 13 Nov 2022, Dave Horsfall wrote:
> Disclaimer: I have no connection with them, but I'll likely buy it.
The book just arrived (that was fast!); I'll review it when I get a
chance, as I'm flat out like a lizard drinking right now.
-- Dave
From imp at bsdimp.com Tue Nov 15 09:54:54 2022
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 14 Nov 2022 16:54:54 -0700
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
Message-ID: <CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
On Mon, Nov 14, 2022 at 3:33 PM Clem Cole <clemc at ccc.com> wrote:
>
>
> On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr at planet.nl> wrote:
>
>> Following on from the exchange on TUHS about DG-UX, it would seem to me
>> that the (Unix) unified cache was invented at least three times for Unix:
>>
> Not to quibble too much, but s/cache/memory/ I think is a fairer way of
> saying that.
>
>
>> - John Reiser at AT&T
>> - At Sun
>> - At DG
>>
> - At CMU (Mach)
>
> The interesting thing again, is that while they while all of these
> implementations seem to have been technologically 'better' - only Mach
> lived on from the original developers. And in the case of Mach, by the
> time it was mainstream (macOS) the original implementation had been
> replaced a few times - so while the concepts are there, I don't think much
> of the Original CMU code is left in XNU/Darwin [or for that matter in the
> OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never
> went anywhere either].
>
Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and
NetBSD with a new uvm. At least for FreeBSD, this is when the buffer cache
was fully (or more fully?) unified because it wasn't quite complete in
4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's been
so long ago now that I've forgotten). Neither are, imho, as good as Sun's
in this respect, but both have been better tuned to scale better than
SunOS. IIRC from OS/MP days, the buffer cache lock contention started to
get bad around 8 or so CPUs (to be fair: SunOS was never MP, these were
Solbourne's locking modifications that weren't super-fine grained).
> As I said, the lesson to TUHS -- as much as I'm a techie and I am
> interested in the 'proper' way of doing things ... "good enough" is often
> what rules.
>
Good enough, and a little more polish to make it even better :)
> It's too bad none of the good memory implementations made it into
> >>systems<< that lasted.á§
>
Yea...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221114/d617cf15/attachment.htm>
From stuff at riddermarkfarm.ca Tue Nov 15 11:21:19 2022
From: stuff at riddermarkfarm.ca (Stuff Received)
Date: Mon, 14 Nov 2022 20:21:19 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
Message-ID: <46715e7b-b0ae-e160-4ac1-7f7c5ea2b467@riddermarkfarm.ca>
On 2022-11-14 17:31, Clem Cole wrote:
> On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr at planet.nl> wrote:
>
> Following on from the exchange on TUHS about DG-UX, it would seem
> to me that the (Unix) unified cache was invented at least three
> times for Unix:
>
> Not to quibble too much, but s/cache/memory/Â I think is a fairer way
> of saying that.
>
> - John Reiser at AT&T
> - At Sun
> - At DG
>
> - At CMU (Mach)
>
> The interesting thing again, is that while they while all of these
> implementations seem to have been technologically 'better' - only Mach
> lived on from the original developers. And in the case of Mach, by
> the time it was mainstream (macOS) the original implementation had
> been replaced a few times - so while the concepts are there, I don't
> think much of the Original CMU code is left in XNU/Darwin [or for that
> matter in the OSF flavors -- Tru64 rewrote it but it died and the
> OSF/RI kernel never went anywhere either].
The CMU copyrights are still there
(https://github.com/apple-opensource/xnu/tree/master/osfmk/mach).
Perhaps someone far more knowledgeable than me could spelunk.
>
> As I said, the lesson to TUHS -- as much as I'm a techie and I am
> interested in the 'proper' way of doing things ... "good enough" is
> often what rules.
Indeed.
>
> It's too bad none of the good memory implementations made it into
> >>systems<< that lasted.
>
> Clem
> á§
From tytso at mit.edu Tue Nov 15 16:03:05 2022
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 15 Nov 2022 01:03:05 -0500
Subject: [TUHS] DG UNIX History
In-Reply-To: <CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
<CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
Message-ID: <Y3MrmQSPfUbLG2rX@mit.edu>
On Mon, Nov 14, 2022 at 04:54:54PM -0700, Warner Losh wrote:
> > The interesting thing again, is that while they while all of these
> > implementations seem to have been technologically 'better' - only Mach
> > lived on from the original developers. And in the case of Mach, by the
> > time it was mainstream (macOS) the original implementation had been
> > replaced a few times - so while the concepts are there, I don't think much
> > of the Original CMU code is left in XNU/Darwin [or for that matter in the
> > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never
> > went anywhere either].
>
> Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and
> NetBSD with a new uvm. At least for FreeBSD, this is when the buffer cache
> was fully (or more fully?) unified because it wasn't quite complete in
> 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's been
> so long ago now that I've forgotten).
FWIW, Linux also has a (mostly) unified page cache. Which is to say,
for all of the major file systems, there is only a single unified page
cache for file data.
There are some legacy file systems in Linux (e.g., befs, qnx4, qnx6,
minix, vfat, etc.) that still use the buffer cache, but the buffer
cache is implemented in terms of the page cache infrastructure, and
that's mainly because no one has really bothered to update those file
systems to use the unified page cache. After all, you're using vfat
to read and write for super-slow USB thumb drive, who cares if data is
getting copied from the USB thumb drive, to the buffer cache, and then
to the page cache? :-)
> > As I said, the lesson to TUHS -- as much as I'm a techie and I am
> > interested in the 'proper' way of doing things ... "good enough" is often
> > what rules.
>
> Good enough, and a little more polish to make it even better :)
Good enough, and backwards compatibility, sure. But for the file
systems where performance is an issue, having a unified page is the
only way to go. :-)
> > It's too bad none of the good memory implementations made it into
> > >>systems<< that lasted.á§
At least in my book, it's not the implementations, but the ideas that
matter. And sometimes implementations are constrained by hardware
limitations (example: clists), and for less contrained hardware,
sometimes you're better re-evaluating whether the ideas in use, and if
that means that you need to reimplement the ideas that still make
sense, there's nothing wrong with that.
- Ted
P.S. I remember back in the day when I was engaging in a friendly
competition with a FreeBSD hacker on improving the serial driver for
the 8250 chip (with no FIFO's!), and I shared with him my idea of
using a pair of ring buffers that would get flipped back and forth
between the interrupt handler and the tty "bottom-half" (read:
software interrupt) handler, and I was told that clists were handed
down from Olympus by the AT&T/Unix Gods and he could never get that
kind of change into the FreeBSD tty layer. Of course, I was free to
make all of the radical changes to Linux's tty layer --- and I did,
all in the name of the number of 115kbaud connections that could be
handled on a single 40 MHz 386 processor...
From lm at mcvoy.com Wed Nov 16 01:11:33 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 15 Nov 2022 07:11:33 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <Y3MrmQSPfUbLG2rX@mit.edu>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
<CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
<Y3MrmQSPfUbLG2rX@mit.edu>
Message-ID: <20221115151133.GL16293@mcvoy.com>
On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote:
> P.S. I remember back in the day when I was engaging in a friendly
> competition with a FreeBSD hacker on improving the serial driver for
> the 8250 chip (with no FIFO's!), and I shared with him my idea of
> using a pair of ring buffers that would get flipped back and forth
> between the interrupt handler and the tty "bottom-half" (read:
> software interrupt) handler, and I was told that clists were handed
> down from Olympus by the AT&T/Unix Gods and he could never get that
> kind of change into the FreeBSD tty layer. Of course, I was free to
> make all of the radical changes to Linux's tty layer --- and I did,
> all in the name of the number of 115kbaud connections that could be
> handled on a single 40 MHz 386 processor...
I remember being pleasantly surprised that Linus/Linux was open to
that sort of change. I get why the traditional Unix shops resisted
be wacks like that but they went too far and it prevented good work.
Linux seemed far more willing to realize that they had it wrong and
there was a better way. That was refreshing.
Of course they got beat up for it with "Linux is stable/compatible".
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From bakul at iitbombay.org Wed Nov 16 01:48:23 2022
From: bakul at iitbombay.org (Bakul Shah)
Date: Tue, 15 Nov 2022 07:48:23 -0800
Subject: [TUHS] DG UNIX History
In-Reply-To: <20221115151133.GL16293@mcvoy.com>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
<CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
<Y3MrmQSPfUbLG2rX@mit.edu> <20221115151133.GL16293@mcvoy.com>
Message-ID: <D7F9B8CC-16FD-47C1-95B6-1D66B9B2B0ED@iitbombay.org>
On Nov 15, 2022, at 7:11 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote:
>> P.S. I remember back in the day when I was engaging in a friendly
>> competition with a FreeBSD hacker on improving the serial driver for
>> the 8250 chip (with no FIFO's!), and I shared with him my idea of
>> using a pair of ring buffers that would get flipped back and forth
>> between the interrupt handler and the tty "bottom-half" (read:
>> software interrupt) handler, and I was told that clists were handed
>> down from Olympus by the AT&T/Unix Gods and he could never get that
>> kind of change into the FreeBSD tty layer. Of course, I was free to
>> make all of the radical changes to Linux's tty layer --- and I did,
>> all in the name of the number of 115kbaud connections that could be
>> handled on a single 40 MHz 386 processor...
>
> I remember being pleasantly surprised that Linus/Linux was open to
> that sort of change. I get why the traditional Unix shops resisted
> be wacks like that but they went too far and it prevented good work.
>
> Linux seemed far more willing to realize that they had it wrong and
> there was a better way. That was refreshing.
>
> Of course they got beat up for it with "Linux is stable/compatible".
At Fortune Systems Dave Yost was able to achieve full-duplex 9600
baud speed on up to 5 ports in V7 Unix without changing the clist
design. This on a 5.6Mhz machine (with 4 cycle memory). The trick
was to specialize interrupt handlers for each port.
From imp at bsdimp.com Wed Nov 16 03:47:20 2022
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 Nov 2022 10:47:20 -0700
Subject: [TUHS] DG UNIX History
In-Reply-To: <Y3MrmQSPfUbLG2rX@mit.edu>
References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl>
<CAC20D2N9pd-9JjwMnU9ChU5LL4z8N3PGw7g5Bh8dsqxAsGsU7g@mail.gmail.com>
<CANCZdfqj1E_nmd8ooKQt6gkFUME0yngKFRcT1z_DDtkT4iKkBg@mail.gmail.com>
<Y3MrmQSPfUbLG2rX@mit.edu>
Message-ID: <CANCZdfoF4Zi_i30f=jx-kyjH_yoU+sLA30vy4V45RjSviKUPrQ@mail.gmail.com>
On Mon, Nov 14, 2022 at 11:03 PM Theodore Ts'o <tytso at mit.edu> wrote:
> On Mon, Nov 14, 2022 at 04:54:54PM -0700, Warner Losh wrote:
> > > The interesting thing again, is that while they while all of these
> > > implementations seem to have been technologically 'better' - only Mach
> > > lived on from the original developers. And in the case of Mach, by the
> > > time it was mainstream (macOS) the original implementation had been
> > > replaced a few times - so while the concepts are there, I don't think
> much
> > > of the Original CMU code is left in XNU/Darwin [or for that matter in
> the
> > > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never
> > > went anywhere either].
> >
> > Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and
> > NetBSD with a new uvm. At least for FreeBSD, this is when the buffer
> cache
> > was fully (or more fully?) unified because it wasn't quite complete in
> > 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's
> been
> > so long ago now that I've forgotten).
>
> FWIW, Linux also has a (mostly) unified page cache. Which is to say,
> for all of the major file systems, there is only a single unified page
> cache for file data.
>
> There are some legacy file systems in Linux (e.g., befs, qnx4, qnx6,
> minix, vfat, etc.) that still use the buffer cache, but the buffer
> cache is implemented in terms of the page cache infrastructure, and
> that's mainly because no one has really bothered to update those file
> systems to use the unified page cache. After all, you're using vfat
> to read and write for super-slow USB thumb drive, who cares if data is
> getting copied from the USB thumb drive, to the buffer cache, and then
> to the page cache? :-)
>
> > > As I said, the lesson to TUHS -- as much as I'm a techie and I am
> > > interested in the 'proper' way of doing things ... "good enough" is
> often
> > > what rules.
> >
> > Good enough, and a little more polish to make it even better :)
>
> Good enough, and backwards compatibility, sure. But for the file
> systems where performance is an issue, having a unified page is the
> only way to go. :-)
>
> > > It's too bad none of the good memory implementations made it into
> > > >>systems<< that lasted.á§
>
> At least in my book, it's not the implementations, but the ideas that
> matter. And sometimes implementations are constrained by hardware
> limitations (example: clists), and for less contrained hardware,
> sometimes you're better re-evaluating whether the ideas in use, and if
> that means that you need to reimplement the ideas that still make
> sense, there's nothing wrong with that.
>
> - Ted
>
> P.S. I remember back in the day when I was engaging in a friendly
> competition with a FreeBSD hacker on improving the serial driver for
> the 8250 chip (with no FIFO's!), and I shared with him my idea of
> using a pair of ring buffers that would get flipped back and forth
> between the interrupt handler and the tty "bottom-half" (read:
> software interrupt) handler, and I was told that clists were handed
> down from Olympus by the AT&T/Unix Gods and he could never get that
> kind of change into the FreeBSD tty layer. Of course, I was free to
> make all of the radical changes to Linux's tty layer --- and I did,
> all in the name of the number of 115kbaud connections that could be
> handled on a single 40 MHz 386 processor...
>
Thankfully, clists have been gone forever from the FreeBSD tty layer (since
FreeBSD 2 or 3 if memory serves). The soft interrupt stuff had to wait to
be replaced until the SMPng efforts to make FreeBSD scale on multicore.
Some cruft remains in the tty layer, to be sure, but it's somewhat better
than before.
Bruce was quite active in FreeBSD and did drive much change in our
thinking, though mostly through getting others to rewrite it in the right
way after the main proponents of that dogma left the project and we could
grow beyond that past. It was a mistake in the earliest days to think
anything from AT&T was sacrosanct and the project is much healthier for
it... We'd never been able to scale with the old AT&T inherited design on
many many things.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221115/0abd434f/attachment.htm>
From fariborz.t at gmail.com Wed Nov 16 09:43:36 2022
From: fariborz.t at gmail.com (Skip Tavakkolian)
Date: Tue, 15 Nov 2022 15:43:36 -0800
Subject: [TUHS] seeking answers to really old unix questions
Message-ID: <CAA1C+h0dM0qn1qeRxJedr7x6vLSz54PwANgUBH1O4KmHfOmyrw@mail.gmail.com>
Some of you might get a chuckle out of this; note the backdated reply.
https://groups.google.com/g/comp.unix.questions/c/W-0VR4Hfpbk
Pointed out by @taviso here:
https://mastodon.sdf.org/@taviso/109331922494730428
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221115/124949a9/attachment.htm>
From rdm at cfcl.com Fri Nov 18 06:42:54 2022
From: rdm at cfcl.com (Rich Morin)
Date: Thu, 17 Nov 2022 12:42:54 -0800
Subject: [TUHS] early Unix papers, from Jim Joyce
Message-ID: <7058E5D4-59AE-4967-9F6B-ADD0A32D1A77@cfcl.com>
Well, I got a lot of interesting responses, but the box of papers is still sitting here. Is anyone willing to take on the collection?
-r
From norman at oclsc.org Mon Nov 21 13:11:30 2022
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 20 Nov 2022 22:11:30 -0500 (EST)
Subject: [TUHS] /usr/mdec
Message-ID: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org>
I'm curious about the origin of the directory name /usr/mdec.
(I am reminded of it because I've noticed that it lives on in
at least one of the BSDs.)
I had a vague notion that it meant `DEC maintenance' but that
seems a bit clumsy to describe a place holding boot blocks.
A random web board suggests it meant `magnetic DECtape.'
That's certainly not true by the time I came along, when it
contained the master copy of the disk boot block(s).
But I suppose it could have meant that early on and
the name just carried forward.
A quick skim of the V1-V7 manuals doesn't explain the name.
Anyone have any clearer memories than I do? Doug or Ken or
anyone who was there when it was coined, do you still recall?
Norman Wilson
Toronto ON
From dave at horsfall.org Mon Nov 21 14:25:43 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 21 Nov 2022 15:25:43 +1100 (EST)
Subject: [TUHS] /usr/mdec
In-Reply-To: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org>
References: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org>
Message-ID: <alpine.BSF.2.21.9999.2211211521220.95052@aneurin.horsfall.org>
On Sun, 20 Nov 2022, Norman Wilson wrote:
> I'm curious about the origin of the directory name /usr/mdec. (I am
> reminded of it because I've noticed that it lives on in at least one of
> the BSDs.)
>
> I had a vague notion that it meant `DEC maintenance' but that seems a
> bit clumsy to describe a place holding boot blocks.
As far as I know, that's right; MAINDEC was certainly on all of their
standalone diagnostic media (a beauty was DECEX, which thrashed the PDP-11
and uncovered a bug in our RK-11 controller; it screwed up on overlapped
seeks which RSX didn't use but Harvard(?) did, so DEC's view was that it
was obviously a Unix problem).
-- Dave
From aap at papnet.eu Mon Nov 21 19:56:29 2022
From: aap at papnet.eu (Angelo Papenhoff)
Date: Mon, 21 Nov 2022 10:56:29 +0100
Subject: [TUHS] /usr/mdec
In-Reply-To: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org>
References: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org>
Message-ID: <Y3tLTflF/BC7y9Sz@indra>
I was also wondering! My theory was that it stands for Magtape & DECtape,
but not sure. Perhaps ken remembers?
aap
On 20/11/22, Norman Wilson wrote:
> I'm curious about the origin of the directory name /usr/mdec.
> (I am reminded of it because I've noticed that it lives on in
> at least one of the BSDs.)
>
> I had a vague notion that it meant `DEC maintenance' but that
> seems a bit clumsy to describe a place holding boot blocks.
>
> A random web board suggests it meant `magnetic DECtape.'
> That's certainly not true by the time I came along, when it
> contained the master copy of the disk boot block(s).
> But I suppose it could have meant that early on and
> the name just carried forward.
>
> A quick skim of the V1-V7 manuals doesn't explain the name.
>
> Anyone have any clearer memories than I do? Doug or Ken or
> anyone who was there when it was coined, do you still recall?
>
> Norman Wilson
> Toronto ON
From jnc at mercury.lcs.mit.edu Tue Nov 22 04:43:48 2022
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 21 Nov 2022 13:43:48 -0500 (EST)
Subject: [TUHS] /usr/mdec
Message-ID: <20221121184348.33A7118C087@mercury.lcs.mit.edu>
> From: Dave Horsfall
> MAINDEC was certainly on all of their standalone diagnostic media
Actually, it was the name for all their diagnostics (usually stand-alone),
dating back to the paper tape days - when that was the only form they were
distributed in. So it makes sense that it's a short form of 'MAINDEC'.
Noel
From dave at horsfall.org Tue Nov 22 07:11:36 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 22 Nov 2022 08:11:36 +1100 (EST)
Subject: [TUHS] /usr/mdec
In-Reply-To: <20221121184348.33A7118C087@mercury.lcs.mit.edu>
References: <20221121184348.33A7118C087@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.2211220809100.24771@aneurin.horsfall.org>
On Mon, 21 Nov 2022, Noel Chiappa wrote:
> > MAINDEC was certainly on all of their standalone diagnostic media
>
> Actually, it was the name for all their diagnostics (usually
> stand-alone), dating back to the paper tape days - when that was the
> only form they were distributed in. So it makes sense that it's a short
> form of 'MAINDEC'.
Yep. We had heaps of paper tape diags (along with a tape and an RK-05)
with "MAINDEC" on the label, so it was just as well that we had a PC-11
(the only one on campus)...
-- Dave
From joseph at josephholsten.com Sat Nov 26 05:55:14 2022
From: joseph at josephholsten.com (Joseph Holsten)
Date: Fri, 25 Nov 2022 11:55:14 -0800
Subject: [TUHS] Archive search down?
Message-ID: <dc338845-3079-40bf-a4ac-3974ff0650da@app.fastmail.com>
Is the search page supposed to be down at https://minnie.tuhs.org/cgi-bin/mailman/tuhs.cgi?
--
Joseph Holsten
http://josephholsten.com
mailto:joseph at josephholsten.com
tel:+1-360-927-7234
From web at loomcom.com Sun Nov 27 04:46:33 2022
From: web at loomcom.com (Seth Morabito)
Date: Sat, 26 Nov 2022 10:46:33 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
Message-ID: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
Hello all,
I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere.
I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true?
Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!)
-Seth
--
Seth Morabito
Poulsbo, WA
web at loomcom.com
From lm at mcvoy.com Sun Nov 27 05:18:27 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 26 Nov 2022 11:18:27 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
Message-ID: <20221126191827.GV18011@mcvoy.com>
On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote:
> Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!)
If the 7300 was the 3B1, M68K, I had one of those and a good friend also
had one. It was a huge step up from a CP/M machine which was my
previous machine. I liked it a lot.
But I wasn't at Bell Labs so perhaps this isn't the info you want. I got
the sense that the 3B2 was not very popular anywhere.
From douglas.mcilroy at dartmouth.edu Sun Nov 27 05:21:27 2022
From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy)
Date: Sat, 26 Nov 2022 14:21:27 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
Message-ID: <CAKH6PiXVYjqbicAGtLh10wqz3PVfFZBm8OTZR0Y1h+ukoRo=4w@mail.gmail.com>
All I can say is that the only 3B2 I can remember was in the Living
Computer Museum in Seattle.
Doug
On Sat, Nov 26, 2022 at 1:47 PM Seth Morabito <web at loomcom.com> wrote:
>
> Hello all,
>
> I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere.
>
> I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true?
>
> Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!)
>
> -Seth
> --
> Seth Morabito
> Poulsbo, WA
> web at loomcom.com
From web at loomcom.com Sun Nov 27 06:04:11 2022
From: web at loomcom.com (Seth Morabito)
Date: Sat, 26 Nov 2022 12:04:11 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <20221126191827.GV18011@mcvoy.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
Message-ID: <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
On Sat, Nov 26, 2022, at 11:18 AM, Larry McVoy wrote:
> On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote:
>> Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!)
>
> If the 7300 was the 3B1, M68K, I had one of those and a good friend also
> had one. It was a huge step up from a CP/M machine which was my
> previous machine. I liked it a lot.
>
> But I wasn't at Bell Labs so perhaps this isn't the info you want. I got
> the sense that the 3B2 was not very popular anywhere.
It was definitely a weird beast. I'm only "fond" of it in the loosest possible sense because I spent so much time trying to understand its internals. It was the perfect combination of too slow, too low specs, and too expensive!
I think one of my slides will simply say "IT WAS BAD AT BEING A COMPUTER"
-Seth
--
Seth Morabito
Poulsbo, WA
web at loomcom.com
From robpike at gmail.com Sun Nov 27 06:42:38 2022
From: robpike at gmail.com (Rob Pike)
Date: Sun, 27 Nov 2022 07:42:38 +1100
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
Message-ID: <CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
It was not popular with CS Research, and we were not popular with them. We
were using VAXes, which the 3B series were attempting to compete against.
The VAX was not exactly graceful, architecturally, but the 3B series was
clumsier and less cost-effective. We weren't interested, despite frequently
applied pressure.
And, although a different topic, there was the way the commercialization of
the Blit forced the 68000 to be replaced by the BELLMAC-32 by essentially
the same people, or at least the same boss (Scanlon), which was a poor
decision on every dimension. The idea was to get BELLMACs out there to
drive up production, but the chip was far less suitable, and each one cost
about what a full Blit with a 68000 instead would have. A loss leader, bad
financially and bad technically.
On the other hand, as I resullt of I did port an OS and other software to
the BELLMAC-32 as a result of this work, and learned how badly it did
things like memory management and the interrupt vector setup, and how buggy
it was.
So there were not many warm feelings between 1127 and the computer division.
-rob
On Sun, Nov 27, 2022 at 7:05 AM Seth Morabito <web at loomcom.com> wrote:
> On Sat, Nov 26, 2022, at 11:18 AM, Larry McVoy wrote:
> > On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote:
> >> Can anyone recall what the general mood was regarding the 3B2 (and the
> 7300 and the 6300, I suppose!)
> >
> > If the 7300 was the 3B1, M68K, I had one of those and a good friend also
> > had one. It was a huge step up from a CP/M machine which was my
> > previous machine. I liked it a lot.
> >
> > But I wasn't at Bell Labs so perhaps this isn't the info you want. I got
> > the sense that the 3B2 was not very popular anywhere.
>
> It was definitely a weird beast. I'm only "fond" of it in the loosest
> possible sense because I spent so much time trying to understand its
> internals. It was the perfect combination of too slow, too low specs, and
> too expensive!
>
> I think one of my slides will simply say "IT WAS BAD AT BEING A COMPUTER"
>
> -Seth
> --
> Seth Morabito
> Poulsbo, WA
> web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/90e33944/attachment.htm>
From clemc at ccc.com Sun Nov 27 07:46:47 2022
From: clemc at ccc.com (Clem Cole)
Date: Sat, 26 Nov 2022 16:46:47 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
Message-ID: <CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
Seth, I've often said the only reason they sold any of them was that AT&T
required you to buy one as the reference system for SVR3 - so anyone that
wanted to port it tended to buy one 3B2 just to have it as the reference
box.
Rob's comment about the BELLMAC-32 was interesting. I could never quite
understand why AT&T wanted to create its own microprocessor and associated
ISA and try to sell it against the other merchant microprocessors (just as
I never could understand why HP and IBM did either - but they were already
formally in the computer business). Selling chips to other people to use
for their designs is a difficult business that needs a sophisticated sales
and marketing team. Even if AT&T could create a technically
competitive device and get the manufacturing cost structure in line
with Moto or Intel so that the street price could be competitive, the
previous sales and marketing scheme of abandoning UNIX on your doorstep was
not going to work, and it was having a new technical sales support team to
match Intel and Moto was just not going to happen any time soon.
Supporting the operating companies is a different beast than supporting,
say, a start-up trying to build a hot new device -> that company's
product. While I suspect Rob and Bart built their own tools for the
redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T,
could you imagine trying to use that device? I can't.
I've told the details of the story elsewhere, and they don't really matter
here. But I remember being at Masscomp and finding a bug in the new FP chip
for the 68020 - which was causing a 'stop shop' on our newest product -
when one of the factory exercisers/diags started to fail. We were paying
a premium at the time and Moto's local folks did not want to listen at
first. Our head of HW came to me because he knew that I knew a bit about
the application program they were using as a test from my grad school
days. With the end help of the Fortran compiler back-end guys in a few
hours of debugging, I was able to isolate the chip failure. Then I wrote a
new 10-line Fortran example and associated assembler code, which we faxed
to Moto. Moto had a 'Technical Consulting Engineer' on the line from
Austin, and indeed it was validated as a problem, and less than 12 hrs
later their team had figured out what was going on in the chip.
I bring this up because I just don't see AT&T has been able to react that
way, although, in the end, we had to solve it once Moto figure out what the
cause of the error was (a slow charge circuit was wiping out the exponent
in R/R instructions under certain conditions - so we changed the compiler
not generate the sequence so we should still ship).
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221126/4bfa35e5/attachment.htm>
From marc.donner at gmail.com Sun Nov 27 09:00:38 2022
From: marc.donner at gmail.com (Marc Donner)
Date: Sat, 26 Nov 2022 18:00:38 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
Message-ID: <CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
My chronology may be borked, but what I remember from that era is that IBM
was selling the AS/400 very effectively against the VAX by then and was
vacuuming up the market. The problem was that DEC's theory of sales was to
have engineers sell to engineers, while IBM sold basement servers to chain
stores. The chains bought these things by the bushel basket. The HW and
OS were both weird (as seen by the computer scientists at Watson) but
remarkably reliable. As near as I can tell, this was what ultimately put
DEC under ... I think the 3B2 was collateral damage ... I presume that AT&T
did not really have time to learn how to sell machines to the commercial
market, particularly to the folks who were buying them in numbers ending in
,000.
What I learned while watching from the sidelines is that I (and by
extension everyone on this list) was not the target audience.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Sat, Nov 26, 2022 at 4:48 PM Clem Cole <clemc at ccc.com> wrote:
> Seth, I've often said the only reason they sold any of them was that AT&T
> required you to buy one as the reference system for SVR3 - so anyone that
> wanted to port it tended to buy one 3B2 just to have it as the reference
> box.
>
> Rob's comment about the BELLMAC-32 was interesting. I could never quite
> understand why AT&T wanted to create its own microprocessor and associated
> ISA and try to sell it against the other merchant microprocessors (just as
> I never could understand why HP and IBM did either - but they were already
> formally in the computer business). Selling chips to other people to use
> for their designs is a difficult business that needs a sophisticated sales
> and marketing team. Even if AT&T could create a technically
> competitive device and get the manufacturing cost structure in line
> with Moto or Intel so that the street price could be competitive, the
> previous sales and marketing scheme of abandoning UNIX on your doorstep was
> not going to work, and it was having a new technical sales support team to
> match Intel and Moto was just not going to happen any time soon.
>
> Supporting the operating companies is a different beast than supporting,
> say, a start-up trying to build a hot new device -> that company's
> product. While I suspect Rob and Bart built their own tools for the
> redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T,
> could you imagine trying to use that device? I can't.
>
> I've told the details of the story elsewhere, and they don't really matter
> here. But I remember being at Masscomp and finding a bug in the new FP chip
> for the 68020 - which was causing a 'stop shop' on our newest product -
> when one of the factory exercisers/diags started to fail. We were paying
> a premium at the time and Moto's local folks did not want to listen at
> first. Our head of HW came to me because he knew that I knew a bit about
> the application program they were using as a test from my grad school
> days. With the end help of the Fortran compiler back-end guys in a few
> hours of debugging, I was able to isolate the chip failure. Then I wrote a
> new 10-line Fortran example and associated assembler code, which we faxed
> to Moto. Moto had a 'Technical Consulting Engineer' on the line from
> Austin, and indeed it was validated as a problem, and less than 12 hrs
> later their team had figured out what was going on in the chip.
>
> I bring this up because I just don't see AT&T has been able to react that
> way, although, in the end, we had to solve it once Moto figure out what the
> cause of the error was (a slow charge circuit was wiping out the exponent
> in R/R instructions under certain conditions - so we changed the compiler
> not generate the sequence so we should still ship).
> á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221126/8f828987/attachment-0001.htm>
From lm at mcvoy.com Sun Nov 27 09:23:23 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 26 Nov 2022 15:23:23 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
Message-ID: <20221126232323.GX18011@mcvoy.com>
On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote:
> remarkably reliable. As near as I can tell, this was what ultimately put
> DEC under ...
Sun Microsystems has entered the chat... They very much competed with
DEC and ate their lunch.
From crossd at gmail.com Sun Nov 27 09:47:52 2022
From: crossd at gmail.com (Dan Cross)
Date: Sat, 26 Nov 2022 18:47:52 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <20221126232323.GX18011@mcvoy.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
Message-ID: <CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
On Sat, Nov 26, 2022, 6:23 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote:
> > remarkably reliable. As near as I can tell, this was what ultimately put
> > DEC under ...
>
> Sun Microsystems has entered the chat... They very much competed with
> DEC and ate their lunch.
>
I think ultimately DEC ate DEC's own lunch. They bet on re VAX 9000 and
that wasn't a wise gamble.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221126/a90c5c32/attachment.htm>
From lm at mcvoy.com Sun Nov 27 10:17:14 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 26 Nov 2022 16:17:14 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
Message-ID: <20221127001714.GY18011@mcvoy.com>
On Sat, Nov 26, 2022 at 06:47:52PM -0500, Dan Cross wrote:
> On Sat, Nov 26, 2022, 6:23 PM Larry McVoy <lm at mcvoy.com> wrote:
>
> > On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote:
> > > remarkably reliable. As near as I can tell, this was what ultimately put
> > > DEC under ...
> >
> > Sun Microsystems has entered the chat... They very much competed with
> > DEC and ate their lunch.
> >
>
> I think ultimately DEC ate DEC's own lunch. They bet on re VAX 9000 and
> that wasn't a wise gamble.
I read the Wikipedia page on the 9000. It's sad that the 9000 wasn't
cancelled when they had better alternatives.
It reminds me of a CPU I got cancelled at SGI. It was in the mid
1990's and the project was code named "Beast". It could do tons of
data movement, to make that happen, the packaging had pin recepters
on all sides, top, bottom, and all 4 sides. The packaging, at volume,
was going to cost $1,200 each. No CPU, just the packaging.
On top of that, SGI did a flip/flop design cycle, flip focussed on
integer performance, databases, while flop focussed on floating point
and catered to the super computing market.
This was when almost all of the processor architects were talking to me
because I had written LMbench which was a set of microbenchmarks that
measured bandwidth and latency of everything. The architects loved them
because they were small and could be run on a simulator.
So I had a pretty good idea what Sun was coming up with (I had left Sun
for SGI), knew what Intel was doing, HP yep, DEC less so but had some
idea about the Alpha roadmap, IBM was the one place that I didn't have
good intel.
I looked at what Beast was claiming, looked at the past predictions
of MIPS chips and when they shipped vs when they would claim to ship,
and looked at the exploding internet / database market and gulped.
Beast was the wrong answer and we were gonna get crushed.
I started shopping my theory around, eventually got a meeting with
Wei Yen (who was someone high enough up). I went over all the info
I had, Wei Yen was super impressed and asked me if this was my job
and I said "oh, no, this is just a hobby I play around with" and he
replied "Keep playing, you play nicely" and went off and cancelled
Beast.
DEC needed someone with that sort of data. I had actual performance
results from every processor in the mainstream and they were no
bullshit results, anyone could reproduce them. Then I had some idea
of almost everyone's roadmap. Without the data, they would have
wasted a ton of money on Beast.
In the end, it didn't really matter, x86 killed SGI just like Sun
and IBM killed DEC. And x86 killed Sun as well.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From rudi.j.blom at gmail.com Sun Nov 27 12:22:52 2022
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 27 Nov 2022 09:22:52 +0700
Subject: [TUHS] /usr/mdec
Message-ID: <CAMYpm84rmXuTpZ+nsVo+zpzHbwrxvbcb1Ch_zmw-6P2j1ae86w@mail.gmail.com>
On DEC's TRU64 UNIX it was /mdec
Making a system image with mkisofs I'd follow with
disklabel -rw -f ${UTMP}/${NAME_ISO} /mdec/rzboot.cdfs /mdec/bootrz.cdfs
Cheers,
uncle rubl
--
The more I learn the better I understand I know nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/a8d2ac1a/attachment.htm>
From phil at ultimate.com Sun Nov 27 14:43:50 2022
From: phil at ultimate.com (Phil Budne)
Date: Sat, 26 Nov 2022 23:43:50 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <20221127001714.GY18011@mcvoy.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com>
Message-ID: <202211270443.2AR4hofO067295@ultimate.com>
Larry McVoy wrote:
> I read the Wikipedia page on the 9000. It's sad that the 9000
> wasn't cancelled when they had better alternatives.
In an oral history Bob Supnik described Ken Olsen couldn't get his
head around the fact that the NVAX chip could equal the 9000:
@2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
In part 2, Bob described how then DEC VP Gordon Bell having earlier
predicted when the microprocessor performance curve would cross over
minis and mainframes:
@1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
He also talks about how the company couldn't command the bsame gross
margins as it did in the VAX era.
From jpl.jpl at gmail.com Sun Nov 27 22:10:28 2022
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Sun, 27 Nov 2022 07:10:28 -0500
Subject: [TUHS] Fred Brooks died
Message-ID: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
We all probably read, and profited from, "The Mythical Man Month".
https://www.nytimes.com/2022/11/23/technology/frederick-p-brooks-jr-dead.html?unlocked_article_code=pcmLspOt6G4B9uXm5cFfTdnHU_KllQB4tCOPPQjVK-YHPpYu1lN4XC-bcbbqYl8saM739PC7FOZWBcMt4uEx7sm0HcLJoaW_izaro6Bapm_JDQqLaOYSlU1wB3iHBjgRbAPJETHRdN_xBFvQ7yZJAt5BfvIVYjzE5UnJys7LzzT5UWkpa4IfYoDjC0YNcQb6QrCzKEoDq0R5Mxpojt4XMSWJs27ruoh86qxqVZ42NItiuF6c_bDFDwnVEgoeUIPRFF6sROunTT8VSYDqokH-HzWQj_9_odmINFB-rOdB3HI913fYLBMuet4A8V_VvVnkmILZ8N81ssia4_fN7poEIJdQzHYjGQ&smid=share-url
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/f9424967/attachment.htm>
From ron at ronnatalie.com Sun Nov 27 23:46:06 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 27 Nov 2022 13:46:06 +0000
Subject: [TUHS] Fred Brooks died
In-Reply-To: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
Message-ID: <em1cecbebf-1746-4448-876c-3e29965e0b78@c62ead55.com>
The man who made Research Triangle. When IBM came to throw some money
into computer science research, he told them to give equal shares to
UNC, State, and Duke.
------ Original Message ------
>From "John P. Linderman" <jpl.jpl at gmail.com>
To "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Date 11/27/2022 7:10:28 AM
Subject [TUHS] Fred Brooks died
>We all probably read, and profited from, "The Mythical Man Month".
>
>https://www.nytimes.com/2022/11/23/technology/frederick-p-brooks-jr-dead.html?unlocked_article_code=pcmLspOt6G4B9uXm5cFfTdnHU_KllQB4tCOPPQjVK-YHPpYu1lN4XC-bcbbqYl8saM739PC7FOZWBcMt4uEx7sm0HcLJoaW_izaro6Bapm_JDQqLaOYSlU1wB3iHBjgRbAPJETHRdN_xBFvQ7yZJAt5BfvIVYjzE5UnJys7LzzT5UWkpa4IfYoDjC0YNcQb6QrCzKEoDq0R5Mxpojt4XMSWJs27ruoh86qxqVZ42NItiuF6c_bDFDwnVEgoeUIPRFF6sROunTT8VSYDqokH-HzWQj_9_odmINFB-rOdB3HI913fYLBMuet4A8V_VvVnkmILZ8N81ssia4_fN7poEIJdQzHYjGQ&smid=share-url
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/19abd755/attachment.htm>
From jpl.jpl at gmail.com Mon Nov 28 00:51:25 2022
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Sun, 27 Nov 2022 09:51:25 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <202211270443.2AR4hofO067295@ultimate.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
Message-ID: <CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command
in single user mode, and it took 20 seconds to run.
Our machine names were themed around bird names, so we christened the 3B2
"junco". Our director said we had to get along,
so we renamed it "jay". But everyone knew what the J stood for. The 3B2
served as a doorstop.
On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
> Larry McVoy wrote:
> > I read the Wikipedia page on the 9000. It's sad that the 9000
> > wasn't cancelled when they had better alternatives.
>
> In an oral history Bob Supnik described Ken Olsen couldn't get his
> head around the fact that the NVAX chip could equal the 9000:
>
> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>
> In part 2, Bob described how then DEC VP Gordon Bell having earlier
> predicted when the microprocessor performance curve would cross over
> minis and mainframes:
>
> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>
> He also talks about how the company couldn't command the bsame gross
> margins as it did in the VAX era.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/d3e8a0bb/attachment.htm>
From lm at mcvoy.com Mon Nov 28 00:53:42 2022
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 27 Nov 2022 06:53:42 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <202211270443.2AR4hofO067295@ultimate.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com>
<202211270443.2AR4hofO067295@ultimate.com>
Message-ID: <20221127145342.GC18011@mcvoy.com>
On Sat, Nov 26, 2022 at 11:43:50PM -0500, Phil Budne wrote:
> Larry McVoy wrote:
> > I read the Wikipedia page on the 9000. It's sad that the 9000
> > wasn't cancelled when they had better alternatives.
>
> In an oral history Bob Supnik described Ken Olsen couldn't get his
> head around the fact that the NVAX chip could equal the 9000:
>
> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>
> In part 2, Bob described how then DEC VP Gordon Bell having earlier
> predicted when the microprocessor performance curve would cross over
> minis and mainframes:
>
> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>
> He also talks about how the company couldn't command the bsame gross
> margins as it did in the VAX era.
Hence the need for hard reproducible data. I'm sure I would have suffered
the same fate at SGI if I had no data.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From arnold at skeeve.com Mon Nov 28 01:29:47 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 27 Nov 2022 08:29:47 -0700
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com>
<202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
Message-ID: <202211271529.2ARFTlef022914@freefriends.org>
Many schools were similarly gifted; I had them both at Georgia Tech and
at Emory. They didn't see a lot of real use. The one more-or-less cool
thing they had was a soft power switch; pushing it started an orderly Unix
shutdown (usually). Once in a while one had to yank the cord from the
wall to shut it down.
Arnold
"John P. Linderman" <jpl.jpl at gmail.com> wrote:
> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command
> in single user mode, and it took 20 seconds to run.
> Our machine names were themed around bird names, so we christened the 3B2
> "junco". Our director said we had to get along,
> so we renamed it "jay". But everyone knew what the J stood for. The 3B2
> served as a doorstop.
>
> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
>
> > Larry McVoy wrote:
> > > I read the Wikipedia page on the 9000. It's sad that the 9000
> > > wasn't cancelled when they had better alternatives.
> >
> > In an oral history Bob Supnik described Ken Olsen couldn't get his
> > head around the fact that the NVAX chip could equal the 9000:
> >
> > @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
> >
> > In part 2, Bob described how then DEC VP Gordon Bell having earlier
> > predicted when the microprocessor performance curve would cross over
> > minis and mainframes:
> >
> > @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
> >
> > He also talks about how the company couldn't command the bsame gross
> > margins as it did in the VAX era.
> >
From ron at ronnatalie.com Mon Nov 28 02:11:34 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 27 Nov 2022 16:11:34 +0000
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
Message-ID: <em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
>. But everyone knew what the J stood for. The 3B2 served as a doorstop.
Shades of the jerq terminal. The J prefix persiste in the code long
after the nickname was quashed.
Being in charge of the Rutgers computer center, we were gifted a lot of
ATT hardware. We had one 3B20 (now that was a pure piece of phone
equipment, you shut it down by turning a switch inside and holding the
button down until it twanged. Just like putting an old 303 modem into
loop back). We also got three 3B5's (noted for the one installed in
the New Brunswick computing room that got completely drenched when a
pipe burst and kept on running) and countless of the 3B2s. I chortled
in that unless you were logged in as root, you couldn't work the power
switch. Yanking the cord out of the wall was still and option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/17782e55/attachment.htm>
From imp at bsdimp.com Mon Nov 28 02:59:10 2022
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 27 Nov 2022 09:59:10 -0700
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
Message-ID: <CANCZdfrqctPPCv5URKjF1Rt_wYztrdvXEA+ZNP-Y=2ySucM_ag@mail.gmail.com>
On Sun, Nov 27, 2022, 9:11 AM Ron Natalie <ron at ronnatalie.com> wrote:
>
> . But everyone knew what the J stood for. The 3B2 served as a doorstop.
>
>
> Shades of the jerq terminal. The J prefix persiste in the code long
> after the nickname was quashed.
>
>
> Being in charge of the Rutgers computer center, we were gifted a lot of
> ATT hardware. We had one 3B20 (now that was a pure piece of phone
> equipment, you shut it down by turning a switch inside and holding the
> button down until it twanged. Just like putting an old 303 modem into
> loop back). We also got three 3B5's (noted for the one installed in the
> New Brunswick computing room that got completely drenched when a pipe burst
> and kept on running) and countless of the 3B2s. I chortled in that
> unless you were logged in as root, you couldn't work the power switch.
> Yanking the cord out of the wall was still and option.
>
When I worked for The Wollongong Group, we had a 3b2, 3b5 and 3b20 for all
the networking products we had. The 3b20 was nice. The 3b5 wasn't
terrible.... the 3b2 was the only machine I've seen that I could visibly
see the characters appear one at a time over the telnet session for some,
but not all, programs. Those programs, iirc, used stdio, but the stdio on
the 3b2 didn't have buffering turned on...
Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/9b19a30c/attachment.htm>
From arnold at skeeve.com Mon Nov 28 04:59:20 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 27 Nov 2022 11:59:20 -0700
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com>
<202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
Message-ID: <202211271859.2ARIxKqL016933@freefriends.org>
Georgia Tech got two 3B20s. They did very little more than consume
electricity and look impressive. I wanted to port 4.2BSD to them,
but that never got off the ground.
"Ron Natalie" <ron at ronnatalie.com> wrote:
>
> >. But everyone knew what the J stood for. The 3B2 served as a doorstop.
>
> Shades of the jerq terminal. The J prefix persiste in the code long
> after the nickname was quashed.
>
>
> Being in charge of the Rutgers computer center, we were gifted a lot of
> ATT hardware. We had one 3B20 (now that was a pure piece of phone
> equipment, you shut it down by turning a switch inside and holding the
> button down until it twanged. Just like putting an old 303 modem into
> loop back). We also got three 3B5's (noted for the one installed in
> the New Brunswick computing room that got completely drenched when a
> pipe burst and kept on running) and countless of the 3B2s. I chortled
> in that unless you were logged in as root, you couldn't work the power
> switch. Yanking the cord out of the wall was still and option.
From dave at horsfall.org Mon Nov 28 06:19:09 2022
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 28 Nov 2022 07:19:09 +1100 (EST)
Subject: [TUHS] Fred Brooks died
In-Reply-To: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
On Sun, 27 Nov 2022, John P. Linderman wrote:
> We all probably read, and profited from, "The Mythical Man Month".
Posted to COFF a week ago, as I didn't think that it was Unix-y...
-- Dave
From norman at oclsc.org Mon Nov 28 06:32:47 2022
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 27 Nov 2022 15:32:47 -0500 (EST)
Subject: [TUHS] Fred Brooks died
Message-ID: <AFAEC50E01952F30F400517F375FCE11.for-standards-violators@oclsc.org>
An appreciation from someone who knew Fred personally:
https://www.cs.columbia.edu/~smb/blog/2022-11/2022-11-18.html
Norman Wilson
(who knows Steve personally)
Toronto ON
From robpike at gmail.com Mon Nov 28 06:45:49 2022
From: robpike at gmail.com (Rob Pike)
Date: Mon, 28 Nov 2022 07:45:49 +1100
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <202211271859.2ARIxKqL016933@freefriends.org>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<em31cf1b57-00bb-4746-b2ac-4ff34db666af@c62ead55.com>
<202211271859.2ARIxKqL016933@freefriends.org>
Message-ID: <CAKzdPgycPuOdXuY95nasb9TGPn5K-Sx=w4uUz+P6v0fNGDbquQ@mail.gmail.com>
But to shut down the dual 3B20 used in switching, you pulled long copper
rod, about 3cm in diameter, from a receptacle between the two machines. It
was attached with a braided conductor to the frame. And then you slid the
rod into another receptacle to short out the power supply for certain.
-rob
On Mon, Nov 28, 2022 at 5:59 AM <arnold at skeeve.com> wrote:
> Georgia Tech got two 3B20s. They did very little more than consume
> electricity and look impressive. I wanted to port 4.2BSD to them,
> but that never got off the ground.
>
> "Ron Natalie" <ron at ronnatalie.com> wrote:
>
> >
> > >. But everyone knew what the J stood for. The 3B2 served as a doorstop.
> >
> > Shades of the jerq terminal. The J prefix persiste in the code long
> > after the nickname was quashed.
> >
> >
> > Being in charge of the Rutgers computer center, we were gifted a lot of
> > ATT hardware. We had one 3B20 (now that was a pure piece of phone
> > equipment, you shut it down by turning a switch inside and holding the
> > button down until it twanged. Just like putting an old 303 modem into
> > loop back). We also got three 3B5's (noted for the one installed in
> > the New Brunswick computing room that got completely drenched when a
> > pipe burst and kept on running) and countless of the 3B2s. I chortled
> > in that unless you were logged in as root, you couldn't work the power
> > switch. Yanking the cord out of the wall was still and option.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/5f1893f9/attachment.htm>
From clemc at ccc.com Mon Nov 28 06:52:36 2022
From: clemc at ccc.com (Clem Cole)
Date: Sun, 27 Nov 2022 15:52:36 -0500
Subject: [TUHS] Fred Brooks died
In-Reply-To: <alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
<alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
Message-ID: <CAC20D2OW8pDbFaLmpFRjs_FwK_7FQsSkHv6fw+7oanpZ4TPc+Q@mail.gmail.com>
He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's
say I was a tad in awe when I was answering his questions when he came on
a factory visit. But he was cool when I asked him if I could go back to my
office and get his book so he could sign it. I think he was pleased to see
a then young professional have it in his office.
á§
On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall <dave at horsfall.org> wrote:
> On Sun, 27 Nov 2022, John P. Linderman wrote:
>
> > We all probably read, and profited from, "The Mythical Man Month".
>
> Posted to COFF a week ago, as I didn't think that it was Unix-y...
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221127/ff34ccc2/attachment.htm>
From arnold at skeeve.com Mon Nov 28 07:00:00 2022
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 27 Nov 2022 14:00:00 -0700
Subject: [TUHS] Fred Brooks died
In-Reply-To: <CAC20D2OW8pDbFaLmpFRjs_FwK_7FQsSkHv6fw+7oanpZ4TPc+Q@mail.gmail.com>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
<alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
<CAC20D2OW8pDbFaLmpFRjs_FwK_7FQsSkHv6fw+7oanpZ4TPc+Q@mail.gmail.com>
Message-ID: <202211272100.2ARL00ua032601@freefriends.org>
I found two typos in the 25th anniversary edition of the book. I used
finger to find his postal address and sent him a letter. He replied with
a nice thank you email. One of them had been in the book since it was
first published!
Clem Cole <clemc at ccc.com> wrote:
> He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's
> say I was a tad in awe when I was answering his questions when he came on
> a factory visit. But he was cool when I asked him if I could go back to my
> office and get his book so he could sign it. I think he was pleased to see
> a then young professional have it in his office.
> á§
>
> On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall <dave at horsfall.org> wrote:
>
> > On Sun, 27 Nov 2022, John P. Linderman wrote:
> >
> > > We all probably read, and profited from, "The Mythical Man Month".
> >
> > Posted to COFF a week ago, as I didn't think that it was Unix-y...
> >
> > -- Dave
> >
From marc.donner at gmail.com Mon Nov 28 21:39:48 2022
From: marc.donner at gmail.com (Marc Donner)
Date: Mon, 28 Nov 2022 06:39:48 -0500
Subject: [TUHS] Fred Brooks died
In-Reply-To: <202211272100.2ARL00ua032601@freefriends.org>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
<alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
<CAC20D2OW8pDbFaLmpFRjs_FwK_7FQsSkHv6fw+7oanpZ4TPc+Q@mail.gmail.com>
<202211272100.2ARL00ua032601@freefriends.org>
Message-ID: <CALQ0xCA17wkjsjhrvTPq=ukvKsBesBrcZ1s=pDE0casHhBV2vg@mail.gmail.com>
In 1980 I applied to grad schools, including UNC. I had read "The Mythical
Man-Month" by then, so I was floored one day sitting in my office when the
phone rang and I heard, "This is Fred Brooks." I visited UNC where I saw
the famous row of clocks that Steve Bellovin mentions in his memorial
post. The "System 360 Principles of Operation" remains one of the most
important pieces of writing in computer history, in my opinion, because it
dominated the hardware and established the principle that an architecture
ensures software execution.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Sun, Nov 27, 2022 at 4:00 PM <arnold at skeeve.com> wrote:
> I found two typos in the 25th anniversary edition of the book. I used
> finger to find his postal address and sent him a letter. He replied with
> a nice thank you email. One of them had been in the book since it was
> first published!
>
>
> Clem Cole <clemc at ccc.com> wrote:
>
> > He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's
> > say I was a tad in awe when I was answering his questions when he came on
> > a factory visit. But he was cool when I asked him if I could go back to
> my
> > office and get his book so he could sign it. I think he was pleased to
> see
> > a then young professional have it in his office.
> > á§
> >
> > On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall <dave at horsfall.org> wrote:
> >
> > > On Sun, 27 Nov 2022, John P. Linderman wrote:
> > >
> > > > We all probably read, and profited from, "The Mythical Man Month".
> > >
> > > Posted to COFF a week ago, as I didn't think that it was Unix-y...
> > >
> > > -- Dave
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/99586078/attachment-0001.htm>
From pnr at planet.nl Mon Nov 28 23:24:52 2022
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 28 Nov 2022 14:24:52 +0100
Subject: [TUHS] Early multiprocessor Unix
Message-ID: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()†calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
Any other notable work in this area prior to 1985?
How was the SMP implementation in SVr3 judged back in its day?
Paul
From stewart at serissa.com Mon Nov 28 23:42:34 2022
From: stewart at serissa.com (Larry Stewart)
Date: Mon, 28 Nov 2022 08:42:34 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
Message-ID: <84EC9581-FABE-48FC-81E8-6559A5239755@serissa.com>
There's a 1975 paper about an MP Unix at the Naval Postgraduate School by Hawley and Meyer.
https://calhoun.nps.edu/handle/10945/20959
> On Nov 28, 2022, at 8:28 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
>
> The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
>
> My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
>
> Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()†calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
>
> Any other notable work in this area prior to 1985?
>
> How was the SMP implementation in SVr3 judged back in its day?
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/f522fe4a/attachment.htm>
From clemc at ccc.com Tue Nov 29 00:05:57 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 28 Nov 2022 09:05:57 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
Message-ID: <CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
As far as I know, the first non-commercial work was done at the Naval Post
Grad school with V6. I have never seen the code for it, only a paper, so I
don't know too much about it to comment.
A few years later (1980), Goble's work became the Purdue Vax [
https://en.wikipedia.org/wiki/George_H._Goble] - which used a master-slave
configuration. He spliced a second 780 CPU onto the SMB and, with some
interesting work, allowed the second CPU to run user code. This was
extremely effective for their usage case -- timesharing of students. If we
don't have the code on TUHS, we should probably dig it up, as it was widely
distributed. The other thing he did was splice an 11/40 onto the UBA of the
same system for debugging - which was a pretty cool hack. He found a
couple of interesting BSD kernel issues, including a famous CVE using his
real-time monitor -- there is a USENIX paper on that tool that is work
checking out.
The first commercial MP Unix was the Masscomp MC500/MP, which was
originally developed as Goble-style Master/Slave and released in RTU 2.0.
A year later, with RTU 3.0 and the release of the MC5000 family, it was
fully SMP.
After that, several SMP UNIX started to appear. Each uses its own lock
scheme. If you are interested, I recommend getting a copy of Schimmel's
book: 'Unix on Modern Processors' which discusses many (most) of the
challenges.
á§
On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal <pnr at planet.nl> wrote:
> The discussion about the 3B2 triggered another question in my head: what
> were the earliest multi-processor versions of Unix and how did they relate?
>
> My current understanding is that the earliest one is a dual-CPU VAX system
> with a modified 4BSD done at Purdue. This would have been late 1981, early
> 1982. I think one CPU was acting as master and had exclusive kernel access,
> the other CPU would only run user mode code.
>
> Then I understand that Keith Kelleman spent a lot of effort to make Unix
> run on the 3B2 in a SMP setup, essentially going through the source and
> finding all critical sections and surrounding those with spinlocks. This
> would be around 1983, and became part of SVr3. I suppose that the “spl()â€
> calls only protected critical sections that were shared between the main
> thread and interrupt sequences, so that a manual review was necessary to
> consider each kernel data structure for parallel access issues in the case
> of 2 CPU’s.
>
> Any other notable work in this area prior to 1985?
>
> How was the SMP implementation in SVr3 judged back in its day?
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/2a940f4b/attachment.htm>
From clemc at ccc.com Tue Nov 29 00:13:31 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 28 Nov 2022 09:13:31 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
Message-ID: <CAC20D2Pv9TeuSxu1=NXL42R1Pvsx_UyoW2aheqUPTJCkjGWfhg@mail.gmail.com>
Paul, the other thing I should point out -- ghg's work was
widely distributed amount the BSD licenses. I somewhat wonder why the Naval
Post Grad school's work was not. My guess is that USENIX was still in its
formative stages when the latter did their work, whereas, by the time of
George's hack, BSD/Vaxen was being used for teaching as University
timesharing systems so his 'upgrade' was a cheap solution.
á§
On Mon, Nov 28, 2022 at 9:05 AM Clem Cole <clemc at ccc.com> wrote:
> As far as I know, the first non-commercial work was done at the Naval Post
> Grad school with V6. I have never seen the code for it, only a paper, so I
> don't know too much about it to comment.
>
> A few years later (1980), Goble's work became the Purdue Vax [
> https://en.wikipedia.org/wiki/George_H._Goble] - which used a
> master-slave configuration. He spliced a second 780 CPU onto the SMB and,
> with some interesting work, allowed the second CPU to run user code. This
> was extremely effective for their usage case -- timesharing of students.
> If we don't have the code on TUHS, we should probably dig it up, as it was
> widely distributed. The other thing he did was splice an 11/40 onto the UBA
> of the same system for debugging - which was a pretty cool hack. He found
> a couple of interesting BSD kernel issues, including a famous CVE using his
> real-time monitor -- there is a USENIX paper on that tool that is work
> checking out.
>
> The first commercial MP Unix was the Masscomp MC500/MP, which was
> originally developed as Goble-style Master/Slave and released in RTU 2.0.
> A year later, with RTU 3.0 and the release of the MC5000 family, it was
> fully SMP.
>
> After that, several SMP UNIX started to appear. Each uses its own lock
> scheme. If you are interested, I recommend getting a copy of Schimmel's
> book: 'Unix on Modern Processors' which discusses many (most) of the
> challenges.
>
>
> á§
>
> On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal <pnr at planet.nl> wrote:
>
>> The discussion about the 3B2 triggered another question in my head: what
>> were the earliest multi-processor versions of Unix and how did they relate?
>>
>> My current understanding is that the earliest one is a dual-CPU VAX
>> system with a modified 4BSD done at Purdue. This would have been late 1981,
>> early 1982. I think one CPU was acting as master and had exclusive kernel
>> access, the other CPU would only run user mode code.
>>
>> Then I understand that Keith Kelleman spent a lot of effort to make Unix
>> run on the 3B2 in a SMP setup, essentially going through the source and
>> finding all critical sections and surrounding those with spinlocks. This
>> would be around 1983, and became part of SVr3. I suppose that the “spl()â€
>> calls only protected critical sections that were shared between the main
>> thread and interrupt sequences, so that a manual review was necessary to
>> consider each kernel data structure for parallel access issues in the case
>> of 2 CPU’s.
>>
>> Any other notable work in this area prior to 1985?
>>
>> How was the SMP implementation in SVr3 judged back in its day?
>>
>> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/9f6b0043/attachment.htm>
From imp at bsdimp.com Tue Nov 29 00:16:11 2022
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 28 Nov 2022 07:16:11 -0700
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
Message-ID: <CANCZdfrE0Lnnz9b+0DdirnWfCWWK_-mKo37QMp5HD3xHvPhu6A@mail.gmail.com>
On Mon, Nov 28, 2022, 7:07 AM Clem Cole <clemc at ccc.com> wrote:
> As far as I know, the first non-commercial work was done at the Naval Post
> Grad school with V6. I have never seen the code for it, only a paper, so I
> don't know too much about it to comment.
>
I tried to find the code a couple of years ago, but no joy. And the timing
suggested he may have started with/used V5, since the paper is dated June
75 and V6 was released in May 75.
Warner
A few years later (1980), Goble's work became the Purdue Vax [
> https://en.wikipedia.org/wiki/George_H._Goble] - which used a
> master-slave configuration. He spliced a second 780 CPU onto the SMB and,
> with some interesting work, allowed the second CPU to run user code. This
> was extremely effective for their usage case -- timesharing of students.
> If we don't have the code on TUHS, we should probably dig it up, as it was
> widely distributed. The other thing he did was splice an 11/40 onto the UBA
> of the same system for debugging - which was a pretty cool hack. He found
> a couple of interesting BSD kernel issues, including a famous CVE using his
> real-time monitor -- there is a USENIX paper on that tool that is work
> checking out.
>
> The first commercial MP Unix was the Masscomp MC500/MP, which was
> originally developed as Goble-style Master/Slave and released in RTU 2.0.
> A year later, with RTU 3.0 and the release of the MC5000 family, it was
> fully SMP.
>
> After that, several SMP UNIX started to appear. Each uses its own lock
> scheme. If you are interested, I recommend getting a copy of Schimmel's
> book: 'Unix on Modern Processors' which discusses many (most) of the
> challenges.
>
>
> á§
>
> On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal <pnr at planet.nl> wrote:
>
>> The discussion about the 3B2 triggered another question in my head: what
>> were the earliest multi-processor versions of Unix and how did they relate?
>>
>> My current understanding is that the earliest one is a dual-CPU VAX
>> system with a modified 4BSD done at Purdue. This would have been late 1981,
>> early 1982. I think one CPU was acting as master and had exclusive kernel
>> access, the other CPU would only run user mode code.
>>
>> Then I understand that Keith Kelleman spent a lot of effort to make Unix
>> run on the 3B2 in a SMP setup, essentially going through the source and
>> finding all critical sections and surrounding those with spinlocks. This
>> would be around 1983, and became part of SVr3. I suppose that the “spl()â€
>> calls only protected critical sections that were shared between the main
>> thread and interrupt sequences, so that a manual review was necessary to
>> consider each kernel data structure for parallel access issues in the case
>> of 2 CPU’s.
>>
>> Any other notable work in this area prior to 1985?
>>
>> How was the SMP implementation in SVr3 judged back in its day?
>>
>> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/d2fc951c/attachment.htm>
From imp at bsdimp.com Tue Nov 29 00:19:03 2022
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 28 Nov 2022 07:19:03 -0700
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CAC20D2Pv9TeuSxu1=NXL42R1Pvsx_UyoW2aheqUPTJCkjGWfhg@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
<CAC20D2Pv9TeuSxu1=NXL42R1Pvsx_UyoW2aheqUPTJCkjGWfhg@mail.gmail.com>
Message-ID: <CANCZdfqJjN30a-JTpumVtDq9Gar4tWg8xsaWM072PLTUfpP4rg@mail.gmail.com>
On Mon, Nov 28, 2022, 7:15 AM Clem Cole <clemc at ccc.com> wrote:
> Paul, the other thing I should point out -- ghg's work was
> widely distributed amount the BSD licenses. I somewhat wonder why the Naval
> Post Grad school's work was not. My guess is that USENIX was still in its
> formative stages when the latter did their work, whereas, by the time of
> George's hack, BSD/Vaxen was being used for teaching as University
> timesharing systems so his 'upgrade' was a cheap solution.
> á§
>
I know the Perdue work on Kirk's DVD collection....
Warner
Warner
On Mon, Nov 28, 2022 at 9:05 AM Clem Cole <clemc at ccc.com> wrote:
>
>> As far as I know, the first non-commercial work was done at the Naval
>> Post Grad school with V6. I have never seen the code for it, only a paper,
>> so I don't know too much about it to comment.
>>
>> A few years later (1980), Goble's work became the Purdue Vax [
>> https://en.wikipedia.org/wiki/George_H._Goble] - which used a
>> master-slave configuration. He spliced a second 780 CPU onto the SMB and,
>> with some interesting work, allowed the second CPU to run user code. This
>> was extremely effective for their usage case -- timesharing of students.
>> If we don't have the code on TUHS, we should probably dig it up, as it was
>> widely distributed. The other thing he did was splice an 11/40 onto the UBA
>> of the same system for debugging - which was a pretty cool hack. He found
>> a couple of interesting BSD kernel issues, including a famous CVE using his
>> real-time monitor -- there is a USENIX paper on that tool that is work
>> checking out.
>>
>> The first commercial MP Unix was the Masscomp MC500/MP, which was
>> originally developed as Goble-style Master/Slave and released in RTU 2.0.
>> A year later, with RTU 3.0 and the release of the MC5000 family, it was
>> fully SMP.
>>
>> After that, several SMP UNIX started to appear. Each uses its own lock
>> scheme. If you are interested, I recommend getting a copy of Schimmel's
>> book: 'Unix on Modern Processors' which discusses many (most) of the
>> challenges.
>>
>>
>> á§
>>
>> On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal <pnr at planet.nl> wrote:
>>
>>> The discussion about the 3B2 triggered another question in my head: what
>>> were the earliest multi-processor versions of Unix and how did they relate?
>>>
>>> My current understanding is that the earliest one is a dual-CPU VAX
>>> system with a modified 4BSD done at Purdue. This would have been late 1981,
>>> early 1982. I think one CPU was acting as master and had exclusive kernel
>>> access, the other CPU would only run user mode code.
>>>
>>> Then I understand that Keith Kelleman spent a lot of effort to make Unix
>>> run on the 3B2 in a SMP setup, essentially going through the source and
>>> finding all critical sections and surrounding those with spinlocks. This
>>> would be around 1983, and became part of SVr3. I suppose that the “spl()â€
>>> calls only protected critical sections that were shared between the main
>>> thread and interrupt sequences, so that a manual review was necessary to
>>> consider each kernel data structure for parallel access issues in the case
>>> of 2 CPU’s.
>>>
>>> Any other notable work in this area prior to 1985?
>>>
>>> How was the SMP implementation in SVr3 judged back in its day?
>>>
>>> Paul
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/5002434c/attachment.htm>
From clemc at ccc.com Tue Nov 29 00:50:33 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 28 Nov 2022 09:50:33 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CANCZdfrE0Lnnz9b+0DdirnWfCWWK_-mKo37QMp5HD3xHvPhu6A@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
<CANCZdfrE0Lnnz9b+0DdirnWfCWWK_-mKo37QMp5HD3xHvPhu6A@mail.gmail.com>
Message-ID: <CAC20D2PGfHtSAs=Ns52gXQPcxOw_7PWsnGCU9GVd=2sCS+C_GA@mail.gmail.com>
On Mon, Nov 28, 2022 at 9:16 AM Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Mon, Nov 28, 2022, 7:07 AM Clem Cole <clemc at ccc.com> wrote:
>
>> As far as I know, the first non-commercial work was done at the Naval
>> Post Grad school with V6. I have never seen the code for it, only a paper,
>> so I don't know too much about it to comment.
>>
>
> I tried to find the code a couple of years ago, but no joy. And the timing
> suggested he may have started with/used V5, since the paper is dated June
> 75 and V6 was released in May 75.
>
Thanks - that makes sense. As I said, I never saw the code, and again, it
agrees with my observation that this was 'pre-USENIX,' particularly since I
believe that those folks are in CA and the original USENIX people were in
NYC and Boston folks, so they would have been less likely to be a part.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/8a38c325/attachment.htm>
From paul.winalski at gmail.com Tue Nov 29 02:30:25 2022
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 28 Nov 2022 11:30:25 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
Message-ID: <CABH=_VQhoRTzHyB7pMzA2OfdbLTSPZq2fO2R4DJJcpzD-RUDgw@mail.gmail.com>
On 11/28/22, Clem Cole <clemc at ccc.com> wrote:
>
> A few years later (1980), Goble's work became the Purdue Vax [
> https://en.wikipedia.org/wiki/George_H._Goble] - which used a master-slave
> configuration. He spliced a second 780 CPU onto the SMB
SBI (Synchronous Backplane Interconnect), the data bus for the 11/780.
The KA780 CPU plugged into it, as did the memory controller, the UBA
(UNIBUS adapter), the MBA (MASSBUS adapter), and the CI (Computer
Interconnect, the high-speed network used for VAXcluster
communication).
> and, with some
> interesting work, allowed the second CPU to run user code. This was
> extremely effective for their usage case -- timesharing of students.
Normally only one KA780 CPU was attached to the SBI, but there was
nothing physical or electronic to prevent plugging in a second one.
IIRC there were a couple of places in the 11/780 microcode that
assumed there was only one CPU on the SBI, but that was easily
tweaked. DEC productized the two-processor asymmetric multiprocessor
configuration as the VAX-11/782. The software development tools group
that I worked in was one of the two beta test sites for the 782 (the
other was MIT). I was the system manager for that machine. Ours ran
VMS, of course, not Unix, but with the same idea that only user mode
code was scheduled to run on the second processor. All I/O and kernel
mode code was done on the primary. It scaled pretty well for
compute-intensive loads. It actually ran slower than a single
processor under high I/O loads, though, and it gave no advantage to
real-time workloads.
I don't know if Ultrix ever supported the 11/782. The product had a
rather short lifetime, as it was soon superseded by VAX models that
were designed for symmetric multiprocessing from the ground up, and
full SMP support had been implemented in VMS and Ultrix.
-Paul W.
From athornton at gmail.com Tue Nov 29 02:42:26 2022
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 28 Nov 2022 09:42:26 -0700
Subject: [TUHS] Fred Brooks died
In-Reply-To: <CALQ0xCA17wkjsjhrvTPq=ukvKsBesBrcZ1s=pDE0casHhBV2vg@mail.gmail.com>
References: <CAC0cEp-63Tqte_oc26+RJgPrVsMAfAm9qND=_bCj_mqm-wRzCw@mail.gmail.com>
<alpine.BSF.2.21.9999.2211280718410.25611@aneurin.horsfall.org>
<CAC20D2OW8pDbFaLmpFRjs_FwK_7FQsSkHv6fw+7oanpZ4TPc+Q@mail.gmail.com>
<202211272100.2ARL00ua032601@freefriends.org>
<CALQ0xCA17wkjsjhrvTPq=ukvKsBesBrcZ1s=pDE0casHhBV2vg@mail.gmail.com>
Message-ID: <67054FFB-258B-48BA-AE2D-0B86002B7AD3@gmail.com>
> On Nov 28, 2022, at 4:39 AM, Marc Donner <marc.donner at gmail.com> wrote:
>
> In 1980 I applied to grad schools, including UNC. I had read "The Mythical Man-Month" by then, so I was floored one day sitting in my office when the phone rang and I heard, "This is Fred Brooks." I visited UNC where I saw the famous row of clocks that Steve Bellovin mentions in his memorial post.
The only direct interaction I ever had with him, alas, is that he politely declined to come address the Engineering Problem Solving class I was teaching at Duke's TIP one summer.
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/501022e1/attachment.htm>
From clemc at ccc.com Tue Nov 29 02:49:57 2022
From: clemc at ccc.com (Clem Cole)
Date: Mon, 28 Nov 2022 11:49:57 -0500
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <CABH=_VQhoRTzHyB7pMzA2OfdbLTSPZq2fO2R4DJJcpzD-RUDgw@mail.gmail.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<CAC20D2PQSg5cs8NohwPk4aFKvwNk32GRxwNHghN0_wCd7opkGQ@mail.gmail.com>
<CABH=_VQhoRTzHyB7pMzA2OfdbLTSPZq2fO2R4DJJcpzD-RUDgw@mail.gmail.com>
Message-ID: <CAC20D2Ot+VAna7cH2M5_Wb=J5n7PpBt+BN=dAGQfs7DGid99xg@mail.gmail.com>
On Mon, Nov 28, 2022 at 11:30 AM Paul Winalski <paul.winalski at gmail.com>
wrote:
> > configuration. He spliced a second 780 CPU onto the SMB
>
> SBI (Synchronous Backplane Interconnect),
>
right SBI -- thanks, Paul -- too many TLAs - bad cache refill.
>
> I don't know if Ultrix ever supported the 11/782.
>
no - the Ultrix group never bothered.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/feec0759/attachment.htm>
From jsg at jsg.id.au Tue Nov 29 02:52:17 2022
From: jsg at jsg.id.au (Jonathan Gray)
Date: Tue, 29 Nov 2022 03:52:17 +1100
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
Message-ID: <Y4TnQVKOaBemFAxL@largo.jsg.id.au>
On Mon, Nov 28, 2022 at 02:24:52PM +0100, Paul Ruizendaal wrote:
> The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
>
> My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
>
> Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()†calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
>
> Any other notable work in this area prior to 1985?
HP-UX on FOCUS/series 500?
https://www.openpa.net/systems/hp-9000_520.html
https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.3.pdf
Jeff Lindberg
A Layered Implementation of the UNIX Kernel on the HP9000 Series 500
Computer
"The HP9000 Series 500 computers are based on a proprietary 32 bit
microprocessor chip set with stack architecture. It has user-transparent
multi-CPU support, for which they included semaphores and a very
carefully worked out scheduler.
HP-UX is based on top of an operating system called SUN (no relation to
Sun Microsystems Inc.). The SUN operating system was intended to be a
modern operating system to support HP's desktop BASIC system. As
designed, though, it turns out to be language independent, and had
several other features that made it attractive as a base upon which to
build a UNIX implementation."
https://archive.org/details/1983-proceedings-unicom-san-diego/page/119/mode/2up
Frederick W. Clegg
Hewlett-Packard’s Entry into the UNIX Community
"Several motivations prompted this somewhat unconventional
implementation of the HP-UX kernel on the HP 9000. It should be
understood that much of the low- level, machine-dependent software for
the HP 9000 was complete before a final commitment was made to offer
UNIX on this product line. Thus reinvention of device and interface
drivers, low-level memory management routines, power-up code, and
architecturally-dependent utility routines was avoided by this approach.
Additionally, this approach permitted leverage of software developed to
support graphics and database management from the BASIC environment.
Additionally, SUN has a number of features which are not present in AT&T
UNIX. These provide opportunities for HP-UX to make a contribution above
and beyond other UNIX implementations. Such features include real-time
performance in the area of interrupt response time and process
switching, support for multiple processors, and reliability in the face
of system errors."
some more details in
https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-03.pdf
HP Journal, March 1984, Volume 35, Number 3
From wlc at jctaylor.com Tue Nov 29 04:53:12 2022
From: wlc at jctaylor.com (William Corcoran)
Date: Mon, 28 Nov 2022 18:53:12 +0000
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
Message-ID: <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
I have a 3b2/300. Anytime you run a command that is compute bound, like factoring a large prime number, the CPU buzzes!
Bill Corcoran
On Nov 27, 2022, at 9:52 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:

[EXTERNAL]
We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command in single user mode, and it took 20 seconds to run.
Our machine names were themed around bird names, so we christened the 3B2 "junco". Our director said we had to get along,
so we renamed it "jay". But everyone knew what the J stood for. The 3B2 served as a doorstop.
On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com<mailto:phil at ultimate.com>> wrote:
Larry McVoy wrote:
> I read the Wikipedia page on the 9000. It's sad that the 9000
> wasn't cancelled when they had better alternatives.
In an oral history Bob Supnik described Ken Olsen couldn't get his
head around the fact that the NVAX chip could equal the 9000:
@2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
In part 2, Bob described how then DEC VP Gordon Bell having earlier
predicted when the microprocessor performance curve would cross over
minis and mainframes:
@1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
He also talks about how the company couldn't command the bsame gross
margins as it did in the VAX era.
THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING THIS EMAIL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/82b8d383/attachment-0001.htm>
From kennethgoodwin56 at gmail.com Tue Nov 29 06:59:50 2022
From: kennethgoodwin56 at gmail.com (Kenneth Goodwin)
Date: Mon, 28 Nov 2022 15:59:50 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
Message-ID: <CAMQbRb3yb5DbuHOMK=c5w8=fj_fZNDCZ7=KWjAYBtBaCc4od4A@mail.gmail.com>
That must be the 300 B superhive model CPU
On Mon, Nov 28, 2022, 1:54 PM William Corcoran <wlc at jctaylor.com> wrote:
> I have a 3b2/300. Anytime you run a command that is compute bound, like
> factoring a large prime number, the CPU buzzes!
>
>
>
> Bill Corcoran
>
>
>
>
>
> On Nov 27, 2022, at 9:52 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
>
> 
>
> [EXTERNAL]
>
>
> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps"
> command in single user mode, and it took 20 seconds to run.
> Our machine names were themed around bird names, so we christened the 3B2
> "junco". Our director said we had to get along,
> so we renamed it "jay". But everyone knew what the J stood for. The 3B2
> served as a doorstop.
>
> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
>
>> Larry McVoy wrote:
>> > I read the Wikipedia page on the 9000. It's sad that the 9000
>> > wasn't cancelled when they had better alternatives.
>>
>> In an oral history Bob Supnik described Ken Olsen couldn't get his
>> head around the fact that the NVAX chip could equal the 9000:
>>
>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>
>> In part 2, Bob described how then DEC VP Gordon Bell having earlier
>> predicted when the microprocessor performance curve would cross over
>> minis and mainframes:
>>
>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>
>> He also talks about how the company couldn't command the bsame gross
>> margins as it did in the VAX era.
>>
>
>
> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of
> the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING
> THIS EMAIL.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/9a3d575a/attachment.htm>
From rminnich at gmail.com Tue Nov 29 08:33:12 2022
From: rminnich at gmail.com (ron minnich)
Date: Mon, 28 Nov 2022 14:33:12 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAMQbRb3yb5DbuHOMK=c5w8=fj_fZNDCZ7=KWjAYBtBaCc4od4A@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
<CAMQbRb3yb5DbuHOMK=c5w8=fj_fZNDCZ7=KWjAYBtBaCc4od4A@mail.gmail.com>
Message-ID: <CAP6exYJ6yvhFTZH=ujzNEq+GxmON97Eg4ydhMQ0ikffZgpGJvA@mail.gmail.com>
I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC
CPUs there, filling ground floor of the central atrium. There was some
swag, which I had for a few years, including refrigerator magnets. The one
I remember:
"Don't be alone, call MACphone!"
I remember reading an article in the early 80s pointing out that, due to
the scale of the Bell System, the center of the universe of semiconductor
fabrication at that time was ... Allentown, PA. Western Electric had an ad,
along the lines of, "who will create the 256 Kb memory part? WE will" -- WE
as in Western Electric.Those parts would have been fabbed in Allentown
IIRC.
It is a bit hard to recall, much less believe. but PA, land of dead still
mills, the Molly Maguires, and underground coal mine fires that will burn
for centuries, also had silicon.
On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin <kennethgoodwin56 at gmail.com>
wrote:
> That must be the 300 B superhive model CPU
>
> On Mon, Nov 28, 2022, 1:54 PM William Corcoran <wlc at jctaylor.com> wrote:
>
>> I have a 3b2/300. Anytime you run a command that is compute bound, like
>> factoring a large prime number, the CPU buzzes!
>>
>>
>>
>> Bill Corcoran
>>
>>
>>
>>
>>
>> On Nov 27, 2022, at 9:52 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
>>
>> 
>>
>> [EXTERNAL]
>>
>>
>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps"
>> command in single user mode, and it took 20 seconds to run.
>> Our machine names were themed around bird names, so we christened the 3B2
>> "junco". Our director said we had to get along,
>> so we renamed it "jay". But everyone knew what the J stood for. The 3B2
>> served as a doorstop.
>>
>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
>>
>>> Larry McVoy wrote:
>>> > I read the Wikipedia page on the 9000. It's sad that the 9000
>>> > wasn't cancelled when they had better alternatives.
>>>
>>> In an oral history Bob Supnik described Ken Olsen couldn't get his
>>> head around the fact that the NVAX chip could equal the 9000:
>>>
>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>
>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier
>>> predicted when the microprocessor performance curve would cross over
>>> minis and mainframes:
>>>
>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>
>>> He also talks about how the company couldn't command the bsame gross
>>> margins as it did in the VAX era.
>>>
>>
>>
>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of
>> the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING
>> THIS EMAIL.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/3be4ed56/attachment.htm>
From marc.donner at gmail.com Tue Nov 29 08:43:30 2022
From: marc.donner at gmail.com (Marc Donner)
Date: Mon, 28 Nov 2022 17:43:30 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CAP6exYJ6yvhFTZH=ujzNEq+GxmON97Eg4ydhMQ0ikffZgpGJvA@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
<CAMQbRb3yb5DbuHOMK=c5w8=fj_fZNDCZ7=KWjAYBtBaCc4od4A@mail.gmail.com>
<CAP6exYJ6yvhFTZH=ujzNEq+GxmON97Eg4ydhMQ0ikffZgpGJvA@mail.gmail.com>
Message-ID: <CALQ0xCAqF7bTUfZOn20kyOc17deAWkAwG4LHr6rmYacArKR=Pw@mail.gmail.com>
IBM built a major semiconductor fab up in Fishkill, NY. About two hours
drive north of NYC. At one point (mid-1980s) it was the biggest fab in the
world according to some metric.
On Mon, Nov 28, 2022, 17:35 ron minnich <rminnich at gmail.com> wrote:
> I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC
> CPUs there, filling ground floor of the central atrium. There was some
> swag, which I had for a few years, including refrigerator magnets. The one
> I remember:
> "Don't be alone, call MACphone!"
>
> I remember reading an article in the early 80s pointing out that, due to
> the scale of the Bell System, the center of the universe of semiconductor
> fabrication at that time was ... Allentown, PA. Western Electric had an ad,
> along the lines of, "who will create the 256 Kb memory part? WE will" -- WE
> as in Western Electric.Those parts would have been fabbed in Allentown
> IIRC.
>
> It is a bit hard to recall, much less believe. but PA, land of dead still
> mills, the Molly Maguires, and underground coal mine fires that will burn
> for centuries, also had silicon.
>
>
>
>
> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin <
> kennethgoodwin56 at gmail.com> wrote:
>
>> That must be the 300 B superhive model CPU
>>
>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran <wlc at jctaylor.com> wrote:
>>
>>> I have a 3b2/300. Anytime you run a command that is compute bound, like
>>> factoring a large prime number, the CPU buzzes!
>>>
>>>
>>>
>>> Bill Corcoran
>>>
>>>
>>>
>>>
>>>
>>> On Nov 27, 2022, at 9:52 AM, John P. Linderman <jpl.jpl at gmail.com>
>>> wrote:
>>>
>>> 
>>>
>>> [EXTERNAL]
>>>
>>>
>>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps"
>>> command in single user mode, and it took 20 seconds to run.
>>> Our machine names were themed around bird names, so we christened the
>>> 3B2 "junco". Our director said we had to get along,
>>> so we renamed it "jay". But everyone knew what the J stood for. The 3B2
>>> served as a doorstop.
>>>
>>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
>>>
>>>> Larry McVoy wrote:
>>>> > I read the Wikipedia page on the 9000. It's sad that the 9000
>>>> > wasn't cancelled when they had better alternatives.
>>>>
>>>> In an oral history Bob Supnik described Ken Olsen couldn't get his
>>>> head around the fact that the NVAX chip could equal the 9000:
>>>>
>>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>>
>>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier
>>>> predicted when the microprocessor performance curve would cross over
>>>> minis and mainframes:
>>>>
>>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>>
>>>> He also talks about how the company couldn't command the bsame gross
>>>> margins as it did in the VAX era.
>>>>
>>>
>>>
>>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of
>>> the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING
>>> THIS EMAIL.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/a52b2146/attachment.htm>
From alanglasser at gmail.com Tue Nov 29 11:49:23 2022
From: alanglasser at gmail.com (Alan Glasser)
Date: Mon, 28 Nov 2022 20:49:23 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <CALQ0xCAqF7bTUfZOn20kyOc17deAWkAwG4LHr6rmYacArKR=Pw@mail.gmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
<20221126191827.GV18011@mcvoy.com>
<764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com>
<CAKzdPgxg4eCYrT96XF2je-Y+WMLANUukrBY3Y+xsmWs0MRN6Ag@mail.gmail.com>
<CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>
<CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com>
<20221126232323.GX18011@mcvoy.com>
<CAEoi9W5T0s5Q2oAw+baOJyX87-0n9a1va36X-+FEf3rXJmtDZQ@mail.gmail.com>
<20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com>
<CAC0cEp_ZGzd5gE+yNSsitSO3RgSi42KGhYXRVrhj2TWzTLVo0A@mail.gmail.com>
<0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com>
<CAMQbRb3yb5DbuHOMK=c5w8=fj_fZNDCZ7=KWjAYBtBaCc4od4A@mail.gmail.com>
<CAP6exYJ6yvhFTZH=ujzNEq+GxmON97Eg4ydhMQ0ikffZgpGJvA@mail.gmail.com>
<CALQ0xCAqF7bTUfZOn20kyOc17deAWkAwG4LHr6rmYacArKR=Pw@mail.gmail.com>
Message-ID: <CALpTLGp_Y6bnptqDymukLMSEPvBfNibfd19MxEfjh+gBHXcLkg@mail.gmail.com>
A few 3B2 stories...
In the late 1970's there were no 3B2's (yet), but there was the MAC 8
processor. The name "MAC 8" was problematic to me and my coworkers: it
stood for Microprocessor Advisory Committee. It was a processor designed
by a committee! It was slow and more problematically, it was not hardware
compatible with Intel 8080 support chips. I don't remember all of the
details but it was an edge versus level set of problems. It was fun to
program. There was an evaluation box (called a MacTutor) that you
connected to an RS-232 line to connect it with a PDP-11 UNIX system for
cross-assembly/cross-compiling (the assembler language was as close to C as
an assembler language could get). The MacTutor was a fun toy. The MAC 8
in production hardware (at least in Holmdel) was a disaster. See
https://archive.org/details/bitsavers_westernEleC8TUTORJul79_3968770/mode/2up
In the early 1980's, I was a Bell Labs technical supervisor in a number of
different development (in contrast to research) organizations. There was
considerable pressure on my management (and me) to utilize 3B2's instead of
DEC hardware; a little later (about 1986) there was pressure to use 6300's
and later 6386's (which ran UNIX).
My first experience with an original 3B2 (one without a model number) was
identical to that of John P Linderman's. Compiling a modest C program took
forever. A little later they gave that one a model number of 300 and came
out with a 400, which was almost reasonable and a 310 which, I believe, had
the same processor and clock as a 400 with less expansion slots. Later came
the 600 and 700, which were pretty reasonable and we used them for a number
of products (DEFINITY Manager 3 for administering a large PBX was one I
brought to market with my team).
In October, 1996 I was promoted to development department head of Global
Messaging Services (GMS) which was better known as AT&T Mail. It was a
hectic time to be joining the organization as the job I took had been being
filled temporarily by another person (who was a friend of mine and, like
me, was new to the organization) and they were in the final throes of
development of a significant new release, about to go into system test (in
another department). One of the first things I learned is that the service
ran on many 3b2/600's mostly in two locations in the US, but had many small
worldwide locations (Hong Kong, Tokyo, Sydney, Tel Aviv, London, Moscow,
and some others I don't remember) all connected by DataKit. The US systems
had been running for many years and could not be powered off, because the
disk drives would seize and not spin up due to an absence of lubricant (as
I was told). This presented some challenges, as I liked to power cycle
systems I worked on and could not do this here. The release was deployed
on Valentine's Day, 1997. It was the worst deployment in the service's
history. Most everything broke. System test hadn't found these very many
latent bugs that were deployed. It was all hands on deck, working all
hours 7x24 with two conference calls a day with the Operations organization
(running the servers) and the Customer Care organization (fielding customer
complaints) until things quieted down towards the end of March.
It was then that I was able to pay more attention to future plans, which
were to replace the 3B2's with Stratus hardware running their fault
tolerant unix (FTX). We had a number of their dual processor systems in
lab test and had just taken delivery of a four processor system, which is
what my predecessor had specified for purchase to replace all of the US
based 3B2's. A group of 3 engineers (one of whom I had hired in 1980)
worked on running benchmarks of GMS workloads on the Stratus systems and
working with Stratus engineers to get fixes to problems in their code when
they arose. They presented the first set of quad processor benchmarks to
me and they were all slower than the "twin" (or 2 processor) benchmarks. I
requested daily updates on the status of this as it was bizarre and indeed
a disaster for our plans. This culminated in my requesting that Stratus
send a small group of their FTX engineers to my location for (what I
called) a formal architecture review of the Quad and FTX. The review was
scheduled for a week. After the first morning, I told them that they
should go back to Stratus and that we'd be in touch. I wrote the following
in an email to my boss, my product manager peer and a handful of others:
Yesterday, 4/15/97, Stratus engineers from their hardware development, FTX
(UNIX) development and performance and design groups met with members of
GMS R&D and AT&T Labs to share information about the Stratus and GMS
architectures.
Executive summary: the Quad will never work for GMS.
The Stratus 1225 (aka "Twin"), is a true SMP (symmetric multi-processor). The
two CPUs each have a one megabyte instruction cache and a one megabyte data
cache, and they both share a memory system of 512 megabytes. Cache
coherency is maintained by a pair of custom chips (ASICs). When data is in
a processor's cache, there is no contention possible. When data is in the
memory system, there is an additional penalty of between 250-390
nanoseconds. Input and output take place on a slower bus.
The Stratus 1245 (aka "Quad") consists of two twin boards that communicate
via the I/O (i.e., slow) bus. This is not symmetric, hence not SMP. Each
board contains 512MB of memory. All of the Unix kernel data resides on one
board (the boot board). When a processor on the non-boot board needs to
access memory on the boot board, the cost is 1700 nanoseconds (a penalty of
4.4 to 6.8 times worse).
Since all Unix kernel data resides on the boot board, any software that
makes significant use of Unix system calls (e.g., GMS) will pay a high
penalty when running on the non-boot board. Further, if a program (e.g.,
the GMS User Agent) is simultaneously running on both boards, its
instructions will reside in the memory of only one of the boards, thus
incurring significant overhead to access instructions for some processes.
It appears that the hardware designers never consulted with the Unix
designers. They are located in different locations (Massachusetts and
California), which can't help. They claim they've seen between 1.4 and 1.6
times improvement in going from Twin to Quad for other customers. They do
note, however, that an optimal application for the Quad is
one which needs to execute application user-mode instructions and make very
few system calls (e.g., a graphics rendering application). GMS, in its
current architecture, assumes free and easy access to system calls. GMS
can never run well on a Quad.
We should immediately abandon any efforts aimed at deploying Quads and
focus all of our attention on extracting compensatory Twins from Stratus.
Needless to say, we were able to get an appropriate number of Twins and
retired all of our 3B2s.
Alan
On Mon, Nov 28, 2022 at 5:45 PM Marc Donner <marc.donner at gmail.com> wrote:
> IBM built a major semiconductor fab up in Fishkill, NY. About two hours
> drive north of NYC. At one point (mid-1980s) it was the biggest fab in the
> world according to some metric.
>
> On Mon, Nov 28, 2022, 17:35 ron minnich <rminnich at gmail.com> wrote:
>
>> I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC
>> CPUs there, filling ground floor of the central atrium. There was some
>> swag, which I had for a few years, including refrigerator magnets. The one
>> I remember:
>> "Don't be alone, call MACphone!"
>>
>> I remember reading an article in the early 80s pointing out that, due to
>> the scale of the Bell System, the center of the universe of semiconductor
>> fabrication at that time was ... Allentown, PA. Western Electric had an ad,
>> along the lines of, "who will create the 256 Kb memory part? WE will" -- WE
>> as in Western Electric.Those parts would have been fabbed in Allentown
>> IIRC.
>>
>> It is a bit hard to recall, much less believe. but PA, land of dead
>> still mills, the Molly Maguires, and underground coal mine fires that will
>> burn for centuries, also had silicon.
>>
>>
>>
>>
>> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin <
>> kennethgoodwin56 at gmail.com> wrote:
>>
>>> That must be the 300 B superhive model CPU
>>>
>>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran <wlc at jctaylor.com> wrote:
>>>
>>>> I have a 3b2/300. Anytime you run a command that is compute bound,
>>>> like factoring a large prime number, the CPU buzzes!
>>>>
>>>>
>>>>
>>>> Bill Corcoran
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Nov 27, 2022, at 9:52 AM, John P. Linderman <jpl.jpl at gmail.com>
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> [EXTERNAL]
>>>>
>>>>
>>>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps"
>>>> command in single user mode, and it took 20 seconds to run.
>>>> Our machine names were themed around bird names, so we christened the
>>>> 3B2 "junco". Our director said we had to get along,
>>>> so we renamed it "jay". But everyone knew what the J stood for. The 3B2
>>>> served as a doorstop.
>>>>
>>>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne <phil at ultimate.com> wrote:
>>>>
>>>>> Larry McVoy wrote:
>>>>> > I read the Wikipedia page on the 9000. It's sad that the 9000
>>>>> > wasn't cancelled when they had better alternatives.
>>>>>
>>>>> In an oral history Bob Supnik described Ken Olsen couldn't get his
>>>>> head around the fact that the NVAX chip could equal the 9000:
>>>>>
>>>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>>>
>>>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier
>>>>> predicted when the microprocessor performance curve would cross over
>>>>> minis and mainframes:
>>>>>
>>>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU
>>>>>
>>>>> He also talks about how the company couldn't command the bsame gross
>>>>> margins as it did in the VAX era.
>>>>>
>>>>
>>>>
>>>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE
>>>> of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING
>>>> THIS EMAIL.
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/31be141f/attachment.htm>
From joseph at josephholsten.com Tue Nov 29 17:31:15 2022
From: joseph at josephholsten.com (Joseph Holsten)
Date: Mon, 28 Nov 2022 23:31:15 -0800
Subject: [TUHS] Re.: Princeton's "Unix: An Oral History": who was in the
team in "The Attic"?
In-Reply-To: <202210120659.29C6xDvY007440@freefriends.org>
References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl>
<20221011134842.GA11780@mcvoy.com>
<CANCZdfrY0DHVC+VNcJGKcyYNfHN0uM=OP8z3wm-2dEsDVd8RqA@mail.gmail.com>
<CALQ0xCA8djfEVxvxkmtwg0uE+YCEYNh1n7etbuJS=9+3=qPq7A@mail.gmail.com>
<20221011195447.GI11780@mcvoy.com>
<8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa>
<CAKzdPgwNUjTLMu5xfDJ6WEawy73+aBA=qgoq19MQKzzYQ0o15A@mail.gmail.com>
<202210120659.29C6xDvY007440@freefriends.org>
Message-ID: <04c68d82-1ed1-4958-9c46-067400e3b7cd@app.fastmail.com>
On Tue, Oct 11, 2022, at 23:59, arnold at skeeve.com wrote:
> Rob Pike <robpike at gmail.com> wrote:
>
>> I think it is (used to be?) a common pattern.
>
> Clearly, the metric in both cases should have been the absolute
> value of the number of lines of code changed...
>
> Both stories are rather sad; one hopes that today's world is
> a better place.
I do hope the anecdotes of twitter’s firings based on LoC end up being mistaken.
But I’m also reading Machiavelli’s Discourses on Livy while catching up on TUHS, I’m not sure I believe in better places any more.
And it reminds me of the Pascal quote, “I have made this longer than usual because I have not had time to make it shorter.†https://quoteinvestigator.com/2012/04/28/shorter-letter/
--
Joseph Holsten
From jsg at jsg.id.au Tue Nov 29 19:39:47 2022
From: jsg at jsg.id.au (Jonathan Gray)
Date: Tue, 29 Nov 2022 20:39:47 +1100
Subject: [TUHS] Early multiprocessor Unix
In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
Message-ID: <Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>
On Mon, Nov 28, 2022 at 02:24:52PM +0100, Paul Ruizendaal wrote:
> The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
>
> My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
>
> Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()†calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
>
> Any other notable work in this area prior to 1985?
Sequent Balance 8000 from 1984 had up to 12 National NS32000 processors
and ran the 4.2BSD derived DYNIX.
Bob Beck, Bob Kasten
VLSI Assist in Building a Multiprocessor UNIX System
USENIX 1985 Summer Conference Proceedings
https://archive.org/details/1985-proceedings-summer-portland/page/254/mode/2up
National had their own 4.1BSD derived GENIX. I can't find any
references to it running on multiprocessor machines.
Gould PowerNode 9080, a dual processor machine was announced in 1984 and
ran a 4.2BSD derived UTX/32.
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1659257
Pyramid Technology, 90Mx dual processor early 1985, 98x late 1985
https://archive.org/details/sim_systems-software_1985-02_4_2/page/n37/mode/2up
Systems & Software 1985-02: Vol 4 Iss 2
"The new 90Mx, the first dual-processor machine from Pyramid, can
support up to 256 users. It has a maximum of 32 megabytes of main
memory, and comes in one single-cabinet and three dual-cabinet
configurations. The 90x, first shipped in October 1983, is limited
to 128 users and 16 megabyte of main memory as a single processor
machine. Like the 90x, the 90Mx uses the reduced instruction set
computer architecture (RISC)."
"OSx is Pyramid's dual-port, multi-processor implementation of
Unix System V from AT&T and 4.2BSD from the University of California,
Berkeley."
https://archive.org/details/Unix_Review_1985_Aug.pdf/page/n9/mode/2up
Unix Review Magazine Aug 1985
"One of the more impressive machines making its debut at the National
Computer Conference in Chicago July 16 was Pyramid Technology Corp’s
98x, a super minicomputer built with the idea of equal opportunity for
equal microprocessors. Pyramid calls the 98x an "isoprocessor" system;
there are two 32-bit RISC (reduced instruction set computer) processors
working as equal partners."
"The idea behind isoprocessing comes from Purdue’s dual processor
implementation, Krahling said. CPU balance is achieved through the use
of a proprietary semaphore system that protects critical sequences of
code and controls simultaneous access to kernel data structures."
"90Mx has a master-slave multiprocessor environment."
From alan at alanlee.org Tue Nov 29 21:33:19 2022
From: alan at alanlee.org (alan at alanlee.org)
Date: Tue, 29 Nov 2022 06:33:19 -0500
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
Message-ID: <b8bdbf58b789a49b3084918515b223f1@alanlee.org>
It would be nice to get more technical information on the 3B2s. As late
as 2016, I had reached out to Ed Eckart the archivist at Alcatel-Lucent
and Seth had contacted William Caughlin at AT&T archives for more
information. Both seemed to indicate the systems were still in use at
some customer sites and thus detailed technical info (eg. schematics,
theory of operation docs, etc) could not be shared with the public. But
that sort of information was preserved and safe.
If anyone has contacts into either organization, a gentile nudge would
be appreciated! :)
-Alan
On 2022-11-26 13:46, Seth Morabito wrote:
> Hello all,
>
> I'm giving a presentation on the AT&T 3B2 at a local makerspace next
> month, and while I've been preparing the talk I became curious about
> an aspect that I don't know has been discussed elsewhere.
>
> I'm well aware that the 3B2 was something of a market failure with not
> much penetration into the wider commercial UNIX space, but I'm very
> curious to know more about what the reaction was at Bell Labs. When
> AT&T entered the computer hardware market after the 1984 breakup, I
> get the impression that there wasn't very much interest in any of it
> at Bell Labs, is that true?
>
> Can anyone recall what the general mood was regarding the 3B2 (and the
> 7300 and the 6300, I suppose!)
>
> -Seth
From ron at ronnatalie.com Wed Nov 30 01:54:45 2022
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 29 Nov 2022 15:54:45 +0000
Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early
multiprocessor Unix)
In-Reply-To: <Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>
Message-ID: <em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com>
In 1982, I returned to BRL (having spent a year working for Martin
Marietta on project involving a dual process RSX-11M system. I did
spend some time setting up the PWB UNIX tools with the QA guys while
there).
BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor)
to build a MIMD system called the HEP, ostensibly to do fluid dynamics
problems. It was looking like the manufacturer wasn’t going to have a
useful OS for it so Mike Muss did his usual thing and suggested he could
put UNIX on it (he had done this twice previously with orphaned
machines: some 11/34 graphics stations that were supposed to be
connected to the CDC7600 and converting the University of Illinois
Arpanet Terminal Server (ANTS) to a host that could support long
leaders.
I was part of Mike’s team. We split up various aspects of the project.
Mike ported PCC. I ported ld, and F77 (as we figured the
“scientists†would probably want that). Mike did the core of the
kernel. I handled all the I/O system because I was the “device driverâ€
guy at JHU and continued on with this at BRL. Our initial work was
done by traveling out to Denelcor’s facility where our machine was
assembled on their floor. They had started their operating system work
(not UNIX), so we took the machine after hours. Amusingly, at BRL in
the room the HEP was going in, the cabinet layout was taped out on the
floor around a central pillar. The tape marked with the component that
went there. Out in the Denver machine room, the equipment was there
but there was a square taped out that said “BRL post†so they knew not
to put/route anything there.
The software being ported was 4BSD. I believe we started with the
George Gobels mods of the dual VAX (BRL already had built one of these).
In working on that I found there was a rather serious portability
problem. The kernel did what I refer to as “conversion by unionâ€
where they stuck a pointer of one type into one element of the union and
retrieved it by a different pointer type union element. Well, such is
all well and good on the VAX, but the HEP encoded the partial word size
into the low order bits of the pointer. This meant that you ended up
with pointers that would access the wrong size operand. I spent a few
days chasing down all these things and fixing them.
The HEP had an 11/34 as a control processor that allowed you to
configure the switch system that interconnected the memory in the
processors. It did this via a special feature called (aptly) “The Low
Speed Bus†(more on that later). But once running, everything was self
contained on the HEP hardware itself. Other amusing things about the
HEP is it had a lot of registers. It also had this stuff called “table
memory†which essentially were read-only registers. You could but a
variety of constants there (we had all the integers from 0-255 and then
powers of two after that). The rest of the memory had an extra bit
per 64-bit word called the “full empty†bit. While the thing was
capable of running the equivalent of 32 UNIX processes simultaneously,
it also had the ability within each of those to hardware schedule
threads. Many instructions had features that used the extra bit like
“WAIT FULL, READ, SET EMPTY†or “WRITE, SET FULLâ€.
The whole thing was built out of Motorola 10800 ECL. All hand
assembled. Quite impressive.
After we got the system up, and Mike tried to port his ray tracing
software to it, we found the I/O system was beastly slow. The I/O
system was a cute device. It had a bunch traditional memory (no
full/empty bits) connected to the main memory via the switch but also to
32 individual UNIBUSes. The only problem was that in order to whack
the registers on the UNIBUS you had to do it through the “Low Speed
Bus.†This was the performance bottleneck. The original designer
of this thing, Burton Smith and I sat down at the Golden Corral
Steakhouse in Aberdeen and worked on a new plan. The key was to allow
the kernel tasks to talk directly to the UNIBUS registers via the
regular memory switch. Fortunately, we had an extra switch node in
spare parts. We did however need software and another PDP-11 to
control the thing. Fortunately, I had spares from my building of the
early internet router: BRL-GATEWAY. I also used the little OS on it
(LOS) to write the control software. In a couple of days, we had
rebuilt the I/O system out of essentially spare parts and it flew.
Amusingly, this was the first of two UNIX ports I worked on that didn’t
use the standard ISR thing that most of the kernels those days did.
After the device driver on the HEP had started the IO up, that thread
just ended. When the UNIBUS interrupt came in, a new thread was
created to service it. I later did a similar strategy with the
message passing coprocessor on the Multibus II.
This was a fun waste of about a year. By the time we got this ready
for prime time, the Army had decided they didn’t have any supercomputers
(other than HEP) and immediately used defense priority to snag the next
Cray X/MP off the assembly line (which had been slated for Apple).
Mike got one run of his raytracer to make a movie: The artillery
shell’s view of collision with a tank. The HEP could generate the
frames about 60:1 (took a minute to make one second of movie time)
faster than anything else we had in the day. Of course, it pales
compared to your modern video games. After that, the HEP was
dismantled (Denelcor had gone out of business) to make room for the
Cray. I recently just found pictures of us all sitting on the “seatsâ€
of the Cray and one of me peering out from the core of the machine.
The Army went on for plans for multiple Cray 2 purchases. After a lot
of amusing “systems engineering†work that originally slated for all of
them to go in Oak Ridge Tennessee, and then all of them to go at BRL,
they decided to spread them around the country (what I told them they
should do in the first place). My last months at BRL, I signed my
name to the $25 million dollar Cray 2 procurement, but it got delivered
after I left (I visited it a few years later).
Somewhere I still have the name plates for the Denelcor HEP H1000.
They, in fact, were never actually installed on the machine,
From jon at fourwinds.com Wed Nov 30 03:00:01 2022
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 29 Nov 2022 09:00:01 -0800
Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early
multiprocessor Unix)
In-Reply-To: <em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>
<em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com>
Message-ID: <202211291700.2ATH01H82562743@darkstar.fourwinds.com>
Ron Natalie writes:
>
> BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor)
> to build a MIMD system called the HEP, ostensibly to do fluid dynamics
I remember the presentation on this at Usenix. My thought at the time was
that the HEP was a lot like what I saw when people started selling their
expensive California homes and moving to Oregon to spend that money on
mini-mansions. Well, in California I could only afford two columns, one
dormer, and a one-car garage but now I can have 8 columns, 6 dormers, a
10 car garage, and so on. I remember thinking at the time that the HEP
seemed like every piece of available hardware at the time glommed together.
I'm sure that more thought went in to it than that, but that was my
impression at the time.
Jon
From sjenkin at canb.auug.org.au Wed Nov 30 06:53:52 2022
From: sjenkin at canb.auug.org.au (steve jenkin)
Date: Wed, 30 Nov 2022 07:53:52 +1100
Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early
multiprocessor Unix)
In-Reply-To: <em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com>
References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl>
<Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>
<em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com>
Message-ID: <6B2EF7CF-5264-4B83-B69F-BC09256138EA@canb.auug.org.au>
Bitsavers has some files on the HEP, if anyone is interested.
The research papers are a collection of undated, probably published pieces.
<http://www.bitsavers.org/pdf/denelcor/>
> On 30 Nov 2022, at 02:54, Ron Natalie <ron at ronnatalie.com> wrote:
>
> BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) to build a MIMD system called the HEP, ostensibly to do fluid dynamics problems. It was looking like the manufacturer wasn’t going to have a useful OS for it so Mike Muss did his usual thing and suggested he could put UNIX on it (he had done this twice previously with orphaned machines: some 11/34 graphics stations that were supposed to be connected to the CDC7600 and converting the University of Illinois Arpanet Terminal Server (ANTS) to a host that could support long leaders.
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
From mah at mhorton.net Wed Nov 30 12:50:14 2022
From: mah at mhorton.net (Mary Ann Horton)
Date: Tue, 29 Nov 2022 18:50:14 -0800
Subject: [TUHS] Reaction to the 3B2 at Bell Labs
In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com>
Message-ID: <29be0075-e06e-0db9-1537-b8939fa019ed@mhorton.net>
You asked for the reaction of people in Bell Labs. I've seen reaction
from Research, but there was also the Development part of the labs.
I was in Columbus with a lot of OSS projects. Ours (Medis) was typical
in our reaction.
The 3B20 Duplex was designed for Telco central offices. It ran on 48V
and had Delco car batteries as a UPS. That was fine for the telcos.
The 3B20 Simplex was a less fault tolerant version, intended to compete
with the Vax 11/780. Nobody wanted it.
The 3B15 was chest freezer size, cheaper, to compete with the Vax
11/750. Nobody wanted it.
The 3B2 in its various sizes was a desktop micro, intended to compete
with a Sun server. It had possibilities. It had Datakit, and later
TCP/IP. You could connect a Blit to it, and later the 5620. We were told
to use it. "Eat your own dog food."Â None of us liked it, but we made do.
I was delighted when I transferred to the computer center and got to
order Suns for desktop use. We still ordered 3B2s for our "att" email
gateways.
Incidently, I won a 3B1 in a raffle in 1986. That was a different beast,
68K based, the UNIX PC built by Convergent. I used it for Stargate and
the UUCP Zone. It had a GUI but the screen and resolution were too small
to really be useful. I still have one in my garage.
Thanks,
/Mary Ann Horton/ (she/her/ma'am)
maryannhorton.com <https://maryannhorton.com>
"This is a great book" - Monica Helms
"Brave and Important" - Laura L. Engel
     Available on Amazon and bn.com!
<https://www.amazon.com/Trailblazer-Lighting-Transgender-Equality-Corporate-ebook/dp/B0B8F2BR9B>
On 11/26/22 10:46, Seth Morabito wrote:
> Hello all,
>
> I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere.
>
> I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true?
>
> Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!)
>
> -Seth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221129/abac3640/attachment.htm>
From rudi.j.blom at gmail.com Wed Nov 30 12:55:20 2022
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Wed, 30 Nov 2022 09:55:20 +0700
Subject: [TUHS] Early multiprocessor Unix
Message-ID: <CAMYpm86f85F1EKcqouyAxb_7kk44LsXqXrXBXOx=_Lc+WFsX7Q@mail.gmail.com>
Around 1985 the computer division of Philips Electronics had a Moterola
68010 based server running MPX (Multi Processor Unix) based on System 5.3
with modification. The 'Multi' part was related to the intelligent LAN and
WAN controllers each with their own 68010 processor and memory. A separate
system image would be downloaded at server boot-time. Truly Multi-Processor
:-)
Here an announcement of the latest (probably last) model, from 1988.
https://techmonitor.ai/technology/philips_ready_with_68030_models_for_its_p9000_unix_workstation_family
--
The more I learn the better I understand I know nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221130/d824982a/attachment.htm>