When I was working at UniPress in New Jersey, we had an SGI Iris named pink on which we developed the 4Sight versions of NeWS Emacs (NeMACS).
Speaking of SGI leaks:
Those things are fucking heavy!
It was raining torrentially outside and the UniPress office started to flood, so we had to keep taking shelves down off the wall and wedging them underneath the Iris to jack it up above the water, as it kept getting deeper and deeper.
Ron will remember the emergency bailing technique MG and I developed of repeatedly filling the shop vac with water then flushing it down the toilet.
The Indigos were another story entirely: They couldn't touch the raw graphics performance of an Iris, since the rendering was all in software, but you could actually stuff one of them in the overhead compartment on an airplane!
And then there was the SGI Indy... They made up for being small on the outside, by being HUGE and BLOATED in the inside:
"Indy: an Indigo without the 'go'". -- Mark Hughes (?)
This legendary leaked SGI memo has become required reading for operating system and programming language design courses:
http://www.cs.virginia.edu/~cs415/reading/irix-bloat.txt <http://www.cs.virginia.edu/~cs415/reading/irix-bloat.txt>
-Don
> On 12 Oct 2017, at 15:16, Don Hopkins <SimHacker(a)gmail.com> wrote:
>
> https://www.youtube.com/watch?v=hLDnPiXyME0 <https://www.youtube.com/watch?v=hLDnPiXyME0>
>
>> On 12 Oct 2017, at 15:04, Michael-John Turner <mj(a)mjturner.net <mailto:mj@mjturner.net>> wrote:
>>
>> Hi,
>>
>> I came across this on Lobsters[1] today and thought it may be of interest to the list: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html <http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html>
>>
>> It appears to be an internal SGI memo that's rather critical of IRIX 5.1. Does anyone know if it's true?
>>
>> [1] https://lobste.rs/ <https://lobste.rs/>
>>
>> Cheers, MJ --
>> Michael-John Turner * mj(a)mjturner.net <mailto:mj@mjturner.net> * http://mjturner.net/ <http://mjturner.net/>
>
We lost co-inventor of Unix and sheer genius Dennis Ritchie on this day in
2011; there's not really much more that I can say...
Sic transit gloria mundi.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
According to the Unix Tree web pages, the development of 4.2BSD was at the request of DARPA guided by a steering committee consisting of:
Bob Fabry, Bill Joy and Sam Leffler from UCB
Alan Nemeth and Rob Gurwitz from BBN
Dennis Ritchie from Bell Labs
Keith Lantz from Stanford
Rick Rashid from Carnegie-Mellon
Bert Halstead from MIT
Dan Lynch from ISI
Gerald J. Popek of UCLA
Although I can place most people on the list, for some names I’m in the dark:
* Alan Nemeth - apparently the designer of the BBN C-series mini’s (I think the C30 was designed to replace the 316/516 as IMP). It is hard to find any info on the C-series, but I understand it to be a mini with 10 bit bytes, 20 bit words and 20 bit address space, more or less modeled after the PDP11 and an instruction set optimised to be an easy target for the C compilers of the day. Any other links to Unix?
* Keith Lantz - apparently specialised in distributed computing. No clear links to Unix that I can find.
* Rick Rashid - driving force behind message passing micro-kernels and the Accent operating systems. Evolved into Mach. Link to Unix seems to be that Accent was an influential design around 81/82
* Bert Halstead - seems to have built a shared memory multiprocessor around that time, “Concert”.
* Dan Lynch - ISI program manager for TCP/IP and the switch-over from NCP on Arpanet.
* Gerald Popek - worked on a secure version of (Arpanet enabled) Unix and on distributed systems (LOCUS) at the time.
Next to networking, the link between these people seems to have been distributed computing — yet I don’t think 4.2BSD had a goal of being multiprocessor ready.
All recollections about the steering committee, its goals and its members welcome.
Paul
> From: Paul Ruizendaal
> * Alan Nemeth - apparently the designer of the BBN C-series mini's
ISTR him from some other context at BBN; don't recall off the top of my
head, though.
> (I think the C30 was designed to replace the 316/516 as IMP).
They _did_ replace the Honeywell's. At MIT, they eventually came and took away
the 516 (I offered it to the MIT Museum, but they didn't want it, as the work
on it hadn't been done by MIT - idiots!), and replaced it with a
C/30. (Actually, we had a couple of C/30 IMPs - the start was adding a C/30,
to which the MIT Internet IP gateway was connected - the other two IMPs were
full, and the only way to get another port for the gateway was to get another
IMP - something which caused a very long delay in getting MIT connected to the
Internet, to my intense frustration. I seem to recall DARPA/DCVA had stopped
buying Honeywell machines, and the C/30 was late, or something like that.)
> It is hard to find any info on the C-series, but I understand it to be a
> mini with 10 bit bytes, 20 bit words and 20 bit address space, more or
> less modeled after the PDP11 and an instruction set optimised to be an
> easy target for the C compilers of the day.
Yes and no. It was a general microprogrammed machine, but supported a
daughter-board on the CPU to help with instruction decoding, etc; so the C/30
and C/70 had different daughter-boards, specific to their function.
There's a paper on the C/70, I don't recall if I have a copy - let me look.
> Any other links to Unix?
I think the C/70 was intended to run Unix, as a general-purpose timesharing
resource at BBN (and did).
> * Bert Halstead - seems to have built a shared memory multiprocessor
> around that time
He was, as a grad student, a member of Steve Ward's group at MIT, the ones who
did the Nu machine Unix 68K port. (He wrote the Unix V6/PWB1 driver for the
Diva controller for the CalChomps they had on their -11/70, the former of
which I eventually inherited.) After he got his PhD (I forget the topic; I
know he did a language called 'D', the origin of the name should be obvious),
he became a faculty member at MIT.
> * Dan Lynch - ISI program manager for TCP/IP and the switch-over from
> NCP on Arpanet.
He was actually their facilities manager (or some title to that effect; he was
in charge of all their TENEX/TWENEX machines, too). He was part of the early
Internet crowd - I vividly remember him at a bar with Phill Gross and I in the
DC suburbs, at a _very_ early IETF meeting, discussing how this Internet thing
was going to reallly take off, and the IETF had got to get itself organized to
be ready for that.
> Next to networking, the link between these people seems to have been
> distributed computing
That wasn't really the tie - the tie was they were all part of the
DARPA-funded circle. Now, as to why whomever at DARPA picked them - I think
they probably looked for people with recognized competence, who had a need for
a good VAX Unix for their research/organization.
Noel
I've just visited Slashdot and found this little gem at the bottom of the page:
Unix is a Registered Bell of AT&T Trademark Laboratories. -- Donn Seeley
Unix seems to have garnered witticisms: Salus throws in a few on the front cover
of his book. Has anyone made a collection of them?
Wesley Parish
"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar
"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn
Hi all. First up, it's TUHS so please no DKIM/email chatter here. Only a
few of you are involved and it's not relevant to Unix history.
Grant Taylor and Tom Ivar Helbekkmo having been working behind the scenes to
find a good solution. We are hoping to a) merge the two lists back together,
b) reinstate [TUHS] and non-mangled From: lines, and c) keep most MTAs
happy in the process.
With some luck, all of this will be resolved. So, let's get back to the
discussion of old Unix systems :)
Thanks, Warren
All, there are now two variants of the TUHS mailing list. E-mail sent
to tuhs(a)tuhs.org will propagate to both of them.
The main TUHS list now:
- doesn't strip incoming DKIM headers
- doesn't alter the From: line
- doesn't alter the Subject: line
and hopefully will keep most mail systems happy.
The alternative, "mangled", TUHS list:
- strips incoming DKIM headers
- alters the From: line
- alters the Subject: line to say [TUHS]
- puts in DKIM headers once this is done
and hopefully will keep most mail systems happy but in a different way.
You can choose to belong to either list, just send me an e-mail if
you want to be switched to the other one. But be patient to start with
as there will probably be quite a few wanting to change.
Cheers, Warren
And now, we bring the RMS/Gnu thread to a close :-)
To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc.
Cheers, Warren
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
NUMA is something that's been on my mind a lot lately. Partially in
seeding beastie ideas into Larry McVoy's brain.
I asked Paul McKenney for some history on what went down at Sequent
since that's before my time. He sent me this, which I think the group
will enjoy: http://www2.rdrop.com/users/paulmck/techreports/stingcacm3.1999.08.04a.pdf
It looks pretty nice. Not sure anyone's come as close as Irix to
solving and productizing "easy" NUMA but that's the one I have the
most hands on experience with. They can affine, place, migrate, and
even replicate many types of resources including vnodes. I'm actually
surprised all that code seems to have been spiked and it doesn't seem
like either Sequent née IBM nor SGI brought forward any of their
architecture to Linux. Paul did RCU which is a tour de force, but the
Linux topology and MM code looks like the product of sustaining
engineers instead of architectural decree. Maybe the SCO lawsuit
snubbed all of that?
HP has an out of date competitive analysis that's worth a look
http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5060289&docLoc….
I don't have enough seat time with Tru64 but maybe they had some good
ideas.
As open source, I do like Illumos' locality groups. I can't make much
sense of Linux on this, too much seems to be in arch/ vs a first class
concept like locality groups.
Regards,
Kevin
