I personally lost two friends and former colleagues recently that these
list probably wants to know about.
I just heard from Lynne Jolitz, Bill's wife. It seems he passed away
about a month ago after a long illness. Most of you know he was the
original force behind the BSD 386 development. I know little more than
what I have just reported at this time, but will pass on any info as I
learn it.
Also in other news, not Unix related, but PDP-11 and the computer graphics
world. We lost Jack Burness a few weeks ago. Jack was the author of the
original "Moonlander" for the PDP-11 with which many of us wasted many
hours trying to pick up "a Big Mac with fries" at "Mare Assabet." [Note: There
was no WWW/Wikipedia in those days to find it, but to look up Assabet
River, so many people naively thought it was a legitimate lunar landmark -
its the River that the DEC Maynard bldg sits]. He was a larger than life
person [his joke's mailing list was a whos-who of the computer industry -
it was an honor to be on it]. We all have a passel of stories about Jack.
I have written separately about Jack a number of times and if you have
never looked at the source to Moonlander, you own it yourself to read it.
Remember he wrote it as a throw-away demo for the GT-40 for trade show [his
integer transcendental funcs are quite instructive]. As one of the folks
on the Masscomp Alumni list put it, 'Jack was someone that just does not
deserve to die.'
This is the announcement Maureen published in the DEC Alumni list.
************************** January 20, 2022 ********************************
Our sincere condolences to Maureen Burness and all friends in CXO and
elsewhere on the passing of her husband, *Jack Burness*, 75, Colorado
Springs, who left us on January 20, 2022. Maureen said: With his bigger
than life personality, humor, and intellect, he was loved and respected by
so many people, including his devoted family. Born in Brooklyn, NY in 1946,
he received his Engineering Degree from Brooklyn Polytechnic Institute and
was employed by DEC, Maynard in the early days and then here in Colorado
Springs. Many of you knew he had a huge appetite for the outdoors of
Colorado and Martha’s Vineyard and joined him in his sometimes-disastrous
adventures.
I came across this talk that, apparently, was meant to be part of a
documentary about timesharing systems at MIT:
https://www.youtube.com/watch?v=KZPYBDA6XVo
This "episode" features McCarthy, Corbato, Fano, Fredkin, and Philip Morse
talking about Multics.
Starting at ~12:15m they talk about the triumvirate of MIT, GE and Bell
Labs and some of the challenges with distributed work. Around the 14 minute
mark, they talk about Bell Labs exiting the project, and touch briefly on
the development of Unix. Interesting quotes include Fano talking about
different objectives from the different organizations, Corby saying, "they
[Bell Labs] dropped out three-quarters of the way through the race"
(referring to Multics), Fano asserting that BTL left after the _research_
part of the project was essentially completed, and Corbato talking about
the influence of Multics on Unix design (Corby refers to Multics as Ken and
Dennis's "prototype" and calls Unix a "second generation Multics"). This
was all shot in the early 1980s.
The rest is interesting, but mostly unrelated to Unix.
- Dan C.
(PS: As an aside, Fano lighting up a cigarette at about 19:20 was
particularly striking: my, how times have changed.)
> From: Clem Cole
> Not to put too fine a point on it, It seems like it would be fair to
> say Multics was 'complete' by the time Organick published his book
This is a pretty ill-judged claim, IMO - but not for any particulars about
the Organick book, etc. The problem is more global.
When was UNIX 'complete' - when the first people were able to do real work on
the PDP-7? When non-programmer clerks from the patent group were able to use
the assembler UNIX on the PDP-11 to format parent documents? When it was
re-written in C for the 4th Edition (since the _portability_ of UNIX was IMO
perhaps the greatest factor in its eventual domination)? Etc, etc, etc.
The exact same problem applies to the question of 'when was Multics
'complete''.
> don't know when it first appeared and can not seem to find it. ... I
> bet I have the 3rd printing. ... Anyone have a first edition around
> with the publication date?
The third printing _is_ the first edition. Anyway, it doesn't matter - see
above. And of course even if the book _wriring_ was finished at time T, it
wouldn't have been printed until some unknown time later. So that's really
pretty useless as a temporal marker; we have much better ones availablw.
> From: Dan Cross
> I can't see any indication that this is anything other than the first
> printing.
My 3rd printing says 3rd was 1980, 2nd in 1976, and copyright 1972.
> Organick's book is often said to describe an earlier version of the
> system
Yes; I'm not sure if the version described in it was ever available for
general usege (which could be my definition of 'complete') - or even usage my
Multics system programmers. I don't remember all the details of the
differences (it's been way too long since I read it, and I don't know the
details of the 'first operational' Multics well enough), but for instance:
ISTR that it describes a version which had a linkage segment (holding
intermediate locations in outbound links - since segment >a>b>c might well
have different segment numbers assigned to it in the address spaces of
processes X and Y, so one copy of >a>b>c, shared between X and Y, couldn't
contain direct outbound links) _per segment_ (data or code) - but operational
Multics (I don't know if this is from 'first available to users', or 'first
available to Multics system programmers', or what) collapsed all the linkage
info into a 'combined linkage segment', in which the linkage info from all
the segments in a process' address space were combined (by copying) into a
single linkage segment.
Etc, etc, etc.
> I understand that Multics got much better after the move to the 6180
I'm not sure that the 6180 made that big a difference to the environment the
average use saw. My understanding (not having been there) was that the big
_architectural_ difference was that cross-ring inter-segment references were
done and monitored in hardware, so a host of security holes caused by
insufficient checking of cross-ring inter-segment pointers were caught
automatically. (The 6180 was also built out of SSI chips, unlike the 645 which
was individual transistors, like a KA10.)
Noel
So this is weird. My publisher contacted me this week asking for permission
to send a copy of my book to these folks: https://archiveprogram.github.com/
Hadn't heard of them before. Looks like they're filling their archive with
stuff from github which means that most of the stuff being preserved by TUHS
is likely not there. Might be a good idea to see if it can be included. I
have no contact with these folks but can probably get a contact from my
publisher if this is something that y'all think is worth doing.
Jon
> Does {Reiser's bitblt replacement] exist for the rest of us to study?
A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c
It appears to be a pre-Reiser bitblt, not what was asked for. But
weighing in at over 800 lines of C, it vivifies the challenge that
Reiser met in half the space.
Doug
