> 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
> From: Don Hopkins
> Solaris: so bad I left the company.
Why was Solaris so much worse than SunOS?
I guess the Sun management didn't understand that was the case? Or were they
so hot for the AT+T linkup that they were willing to live with it?
Noel
As I've said elsewhere, Sun was out of money. AT&T bought $200m of Sun
stock at 35% over market but Sun had to dump SunOS and got to SVR4.
I don't know if Scooter knew what he was dumping or not, I suspect not
but all those late nights when he came over to egg us kernel geeks on,
maybe he did know. I don't think he had a choice.
On Sun, Oct 01, 2017 at 12:59:42PM -0400, Arthur Krewat via TUHSmangle wrote:
> From Sun's point of view, what was the REAL reason to move from SunOS to
> Solaris?
>
> I don't think I've read anything anywhere as to a real technical reason. Was
> it just some stuffed-shirt's "great idea"?
>
> Or was it really a standards-based or other reality-based reason?
>
> As of SunOS 4.1.4, it seemed ready to go whole-hog into SMP, so that wasn't
> the sole reason.
>
> thanks!
> art k.
>
>
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
I’m an HPC guy. The only good OS is one that is not executing any instructions except mine. No daemons, no interrupts, nothing. Load my code, give me all physical memory, give me direct access to the interconnect and then get out of the way. If I want anything, I will let you know, but don’t wait up.
When I put on an educator’s hat I still have a soft spot for V6 and V7. Those were my first exposure to Unix and the Unix Way. One could actually learn style by reading code and writing device drivers. These days kernels (Linux at least) are too complicated and too cluttered up with ifdefs to learn much. The real recent innovations like RCU and queuing locks and NUMA affinity are buried pretty deep, and actual reliable file systems like ZFS and BTRFS are just too complicated for mortals.
As a user, what I really want are reliability, the commands and utilities, and stable APIs. I don’t like a lot of things about Posix, but it is at least a little stable and a little portable. For myself, I use MacOS and Debian Linux, and open, close, read, write.
-Larry
