All,
I'm not 100% sure how best to ask this, but here goes...
I own a copy of the CSRG Archives CD Set that Kirk McKusick maintained.
I bought them ages and ages ago (BTW, they are now all available on
Archive.org) I dusted them off today because I had the brilliant idea
that with my significant growth in understanding related to all things
unix and ancient unix, that I might find them interesting and useful.
They are interesting, jury's out on useful beyond being a broweasable
historical archive of individual files. One of the CD's contains a 4.4
and 4.4BSD-Lite2 folder and is labeled releases (disk 3). I opened the
4.4 folder and it appears to be a set of folders and files I would
expect to find on a release tape, but unlike a tape, which one could
mount and boot from, I have no idea if this would be usable as install
media (if you do, please let me know how).
I googled about the two releases and although the same text appears all
over the place about how Berkeley released one version, then removed
some components, then re-released, and eventually wound up at
4.4BSD-Lite2, I could not figure out whether the word release meant
sourcecode, installable media, or what. I gather a lot of this made
sense back in the early 1990's but it's all a bit muddy to me in 2017.
In trying to figure it all out, I came across a webpage talking about
2.11BSD (maintained into this decade) and another about 4.3BSD
Quasijarus (also maintained in this decade?). Both descriptions
contained the text, "It is the release of 4.4BSD-Lite, and requires the
original UNIX license" (see http://damnsmallbsd.org/pub/BSD-UNIX) My
sense of things after reading and browsing and such is that with regards
to 4.4, 4.4BSD-Lite, and 4.4BSD-Lite2, they are either not released
(4.4), encumbered and retracted (4.4BSD-Lite), or not installable
(4.4BSD-Lite2)...
Dang, so confusing...
My interest is pretty much based on a strong desire to boot up a 4.4
system that as closely as possible maps to the one described in "The
Design and Implementation of the 4.4 BSD Operating System" that I can
experiment with as I'm going through the text. I think I understand the
version history as it is described in various places, but I just can't
figure how the last handful of versions relate to real media that is
available to enthusiasts.
Questions begging answers:
What is the last bootable and installable media, officially distributed
by Berkeley?
Is that image currently publicly accessible?
What is the closest version, that is currently available, that would
match the os described in "The Design and Implementation of the 4.4 BSD
Operating System"?
Many thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Dave Horsfall reported failures for the TUHS mirror at his site.
I've just looked at our TUHS mirror in Salt Lake City, Utah, USA, and
found that
% rsync rsync://rsync.math.utah.edu
produces the expected list.
I also checked the mirror cron job logs, and found that they all look
similar for every day this year, with no indication of connection
errors.
I then checked the TUHS filesystem tree, and found only two files
created in the last month (timestamps in UTC):
-rw-rw-r-- 1 mirror mirror 99565 Oct 20 17:27 UA_Documentation/TUHS/Mail_list/2017-October.txt.gz
-rw-rw-r-- 1 mirror mirror 400419 Sep 30 17:27 UA_Documentation/TUHS/Mail_list/2017-September.txt.gz
The first of those arrived here late last night (Oct 20 23:15 MDT, Oct
21 05:15 UTC).
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> sed *n l pathname
>
> The latter also has the advantage that its output is
> unambiguous, whereas the output of historical cat *etv is not.
>
> But mind you, in preparation of this email i found a bug in
> Busybox sed(1) which simply echoes nothing for the above.
I assume that * is a typo for - . If so, sed did just what
-n tells it to--no printing except as called for by p or P.
And speaking of sed anticipating other tools, the inclusion
of "head" in v7 as a complement to "tail" was a close call
because head is subsumed by sed q.
Doug
All, behind the scenes we have had Grant Taylor and Tom Ivar Helbekkmo
helping us find a solution to the TUHS list DKIM issues. We have been
running two separate lists (unmangled and mangled TUHS headers) for a
few weeks. It looks like we can now merge them all back together and
use the settings on one to avoid (most of) the DKIM problems.
So that's what I've done: merged back to a single TUHS mailing list.
I've restored the [TUHS] on the Subject line as well.
I'll monitor the logs for further bounces. Fingers crossed there won't
be any further unsubscriptions from the list due to bounce processing.
If there are, I'll manually put you back in.
Cheers all & thanks to Grant and Tom.
Warren
[I tried to send this earlier, but was thwarted by list shenanigans.
Apologies if it's a dup.]
On Thu, Oct 19, 2017 at 10:52 AM, Ron Natalie <ron(a)ronnatalie.com> wrote:
> My favorite reduction to absurdity was /bin/true. Someone decided we
> needed shell commands for true and false. Easy enough to add a script that
> said "exit 0" or exit 1" as its only line.
> Then someone realized that the "exit 0" in /bin true was superfluous, the
> default return was 0. /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved. We got a version of a packaged UNIX (I
> think it was Interactive Systems). Every shell script got twelve lines of
> copyright/license boilerplate. Including /bin true.
> The file had nothing but useless comment in it.
Gerard Holzmann has something on this that I think is great:
http://spinroot.com/gerard/pdf/Code_Inflation.pdf
- Dan C.
PS: A couple of thoughts.
The shell script hack on 7th Edition doesn't work if one tries to
'execl("/bin/true", "true", NULL);'. This is because the behavior of
re-interpreting an execution failure as a request to run a script is
done by the shell, not exec in the kernel. This implies that one could
not directly exec a shell script, but rather must exec the shell and
give the path to the script as the first argument. I vaguely recall we
had a discussion about the origin of the '#!' syntax and how this was
addressed about a year or so ago.
I tried to write a teeny-tiny '/bin/true' on my Mac. Dynamically
linked, the obvious "int main() { return 0; }" is still a little over
4KB. Most of that is zeros; padding for section alignment and the
like. I managed to create a 'statically' linked `true` binary by
writing the program in assembler:
% cat true.s
# /bin/true in x86_64 assembler for Mac OS X
.text
.globl start
start:
mov $0x2000001, %rax # BSD system call #1
mov $0, %rdi # Exit status: 0 = 'true'
syscall
# OS X requires a non-empty data segment.
.data
zero: .word 0 As I recall,
%
macOS requires you to have a data section aligned to 4K, even if you
don't use it. The resulting binary is a little over 8K; again, mostly
zeros.
There are parlor tricks people play to get binary sizes down to
incredibly small values, but I found the results interesting. Building
the obvious C program on a PDP-11 running 7th Edition yields a 136
byte executable, stripped. Still infinitely greater than /bin/true in
the limit, but still svelte by modern standards.
> How realistic would the experience be to actually running the system
> described in the Unix Programming Environment [v8] if it's actually
running > BSD 4.1... Thanks for any insights y'all might have on this.
This question bears on a recent thread about favorite flavors of Unix. My
favorite flavor is Universal Unix, namely the stuff that just works
everywhere. That's essentially what K&P is about.
That's also what allowed me to use a giant Cray with no instruction
whatsoever. And to do everyday "programmering" on the previously
inscrutable Macintosh, thanks to OS X.
The advent of non-typewriter input put a damper on Universal Unix. One has
to learn something to get started with a novel device. I am impressed,
though, by the breadth of Universal Unix that survives behind those
disparate facades.
> From: Larry McVoy
>>> I was told, by someone that I don't remember, that uwisc was the 11th
>>> node on the net. ... If anyone can confirm or deny that I'd love to know.
> I dunno.
I don't have any axe to grind here. I don't care if they were the first, or
the last. You asked "If anyone can confirm or deny that I'd love to know",
and all I'm trying to do is _accurately_ answer that.
> That 1985 map has uwisc in there
I have a large collection of ARPANET maps here:
http://www.chiappa.net/~jnc/tech/arpanet.html
and the first one on which UWisc shows up is the October, 1981 geographical
map - over ten years since the ARPANet went up (December, 1969 is the earliest
map I have there).
> I do know that prior to the net there was uucp
Which "net" are we talking about here? ARPANET? CSNET? Internet? The UUCP network
long post-dated the ARPANET - I think it was started in the late 70's, no?
The earliest Internet map I have is from 1982, here:
https://upload.wikimedia.org/wikipedia/commons/6/60/Internet_map_in_Februar…
and again UWisc is not on it. (Yes, I know it's on Wikipedia, but I'm the one
who uploaded it, so I can verify it.)
CSNET I don't know much about, that may have been what the comment referred
to.
Wikipedia (for what little we can trust it) says "By 1981, three sites were
connected: University of Delaware, Princeton University, and Purdue
University"; since Lawrence Landweber at UWis was the main driver of CSNET, I
doubt it would have been far behind.
Noel
> From: Grant Taylor
> Does anyone know of a good place to discuss networking history, routing,
> email, dns, etc. I'd like to avoid getting too far off topic for TUHS.
You could try the "Internet History mailing list":
http://www.postel.org/internet-history/
which covers all of networking, including pre-Internet stuff.
Noel
> From: Larry McVoy
> I was told, by someone that I don't remember, that uwisc was the 11th
> node on the net. ... If anyone can confirm or deny that I'd love to know.
There's a copy of the July '77 revision of the HOSTS.TXT file as an appendix
here:
http://www.walden-family.com/dave/archive/bbn-tip-man.txt
The IMPs are numbered in order of deployment; so UCLA is #1, SRI is #2, Utah
is #4, BBN is #5, etc.
I don't see Wisconsin in the list at all. Maybe the person meant CSNET?
Noel
Does anyone know why stty won't accept '^?' in v7? It will accept '^h',
but then the shell expects ^h to "backspace". I am trying to get the
delete key on my mac to do the backing up and it's '^?'. # isn't my
favorite since it's used in C programs, but pressing CTRL-h to backup is
a pain too. If you've read this far, I have three more questions:
1. How do you escape # in order to write a C program if # is the erase
character in the terminal?
2. How do you enter a literal character in the v7 shell (I am used to
CTRL-v CTRL-DEL to enter the delete character on other unices)?
3. Is there a way to echo the ascii value of a keypress in v7?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Dear THUS members,
An international conference on the history of Unix will be held in
Paris, Oct. 19th, at the Conservatoire National des Arts & Métiers. Here
is the link to the (bilingual) program :
http://technique-societe.cnam.fr/colloque-international-unix-en-france-et-a…
<http://technique-societe.cnam.fr/medias/fichier/programme-colloque-unix-bil…>
There will be audio recordings of the symposium available afterwards -
check the program page to know where and when.
It will be followed, the next day, by a kick-off meeting of the research
project “What is a computer program?”:
http://technique-societe.cnam.fr/table-ronde-qu-est-ce-qu-un-programme-info…
<http://technique-societe.cnam.fr/table-ronde-qu-est-ce-qu-un-programme-info…>
Please note that an active member of this list, Clem Cole, will be
giving a much awaited talk!
Best,
Camille Paloque-Bergès, for the orgazining committee(a THUS lurker !).
--
Institutional email address : camille.paloque_berges(a)cnam.fr
<mailto:camille.paloque_berges@cnam.fr>
*Laboratory for the History of Techno-Sciences (HT2S), Conservatoire
national des arts et métiers, 2 rue Conté, 75003 Paris, France
*Associate researcher at the Digital Paths cluster of CNRS' Institute
for Communication Sciences (ISCC)
I remember a thread on the mailing list a while back where Warren
announced the availability of the V8-V10 source code and being intrigued
at the possibility of running it. Then I recently came across a note by
dmr referring to V8 and further tweaking my interest:
http://minnie.tuhs.org/pipermail/tuhs/2003-June/002195.html
Here's what he said:
As for the system aspects: K&R 1 (1978) was done on
what would soon be 7th edition Unix, on 11/70;
K&R 2 (1988) using 9th edition on VAX 8550.
Kernighan and Pike's Unix Programming
Evironment (1984) used 8th edition
on VAX 11/750.
About the releases (or pseudo releases) that
Norman mentions: actually 8th edition was
somewhat real, in that a consistent tape
and captured, probably corresponds fairly
well with its manual, and was educationally
licensed for real, though not in large quantity.
9th and 10th were indeed more conceptual in that
we sent stuff to people (e.g. Norman) who asked,
but they weren't collected in complete and
coherent form.
This combined with my tinkering with V7 and working through K&R (1978)
got me hankering to go through K&P (1984) on a Vax running V8. Then, I
came across this:
https://virtuallyfun.com/2017/03/30/research-unix-v8/
and decided to jump in and start running V8. Then it hit me - is it even
possible to run a V8 instance (similarly to V5/V6/V7, from tape) or is
it as this note says, necessary to run the bits on a 4.1 BSD base? How
realistic would the experience be to actually running the system
described in the Unix Programming Environment if it's actually running
BSD 4.1... Thanks for any insights y'all might have on this.
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
> From: Will Senn
> All that cooked and raw stuff is gobbledegook that I'll have to read up
> on.
The raw/cooked stuff isn't the source of the worst hair in the TTY driver;
that would be delays (on the output side), and delimiter processing (on the
input side).
The delays are for mechanical terminals, because they need delays after a
motion command (e.g. NL, CR, etc) before the next printing character is sent;
differing for different motion control commands, further complexified by the
current print head position - a Carriage Return from column 70 taking a lot
longer than one from column 10. The driver keeps track of the current column,
so it can calculate this! It does the delays by putting in the output queue a
chacter with the high bit set, and the delay in the low bits; the output start
routine looks for these, and does the delay.
On the input side, every time it sees a delimiter (NL, EOF), it inserts a 0xFF
byte in the input queue, and increments a counter to keep track of how many it
has inserted. I _think_ this is so that any given read call on a 'cooked'
terminal will return at most one line of input (although I don't know why they
don't just parse the buffer contents at read time - although I guess they need
the delimiter count so the read call will wait if there is not a complete line
there yet).
I should look and see how the MIT TTY driver (which also supported 8-bit input
and output) dealt with these...
Noel
> From: Will Senn
> I didn't know that the delete key served a purpose, interrupt
At MIT, the PWB1 (effectively) system that was standard at Tech Sq had had its
teletype driver completely re-written by the time I started using it, and that
was changed, so I never saw this IRL.
Recently, I needed a Unix to run under Ersatz-11, to talk to physical QBUS
-11's and download them over their console line, so I went with V6 (since I
had not at that point managed to recover the MIT system). Wow. Talk about
a rude awakening!
That was one of the things that was, ah, problematic - and in V6, there's no
way to change the interrupt character. (And no, I didn't feel like switching
to a later version!)
An even bigger problem was that in vanilla V6, there's _no way_ to do 8-bit
input _and_ output. Sheesh. I managed to fix that too, after a certain amount
of pain. (I missed a code path, or something like that, and it took me quite a
while to figure out why my fixes didn't work.)
Noel
Many thanks for on and off list replies to my query.
I happened to stumble across a paper by Krik McKusick (right here in the THUS archives) that has some more background:
http://www.tuhs.org/Archive/Documentation/Unix_Review/Berkeley_Unix_History…
and in particular on page 38 of the magazine (page 6 of the PDF).
It says (with some reformatting for clarity):
"The contract called for major work to be done on the system so the
DARPA research community could better do its work. Based on the needs
of the DARPA community, goals were set and work began to define the
modifications to the system.
In particular, the new system:
- was expected to include a faster file system that would raise
throughput to the speed of available disk technology,
- would support processes with multi-gigabyte address space requirements,
- would provide flexible interprocess communication facilities that
would allow researchers to do work in distributed systems,
- would integrate networking support so that machines running the new
system could easily participate in the ARPAnet.”
So, IPC facilities to support distributed systems were apparently an explicit goal, and that helps explain the composition of the committee.
It continues:
"To assist in defining the new system, Duane Adams, Berkeley's contract
monitor at DARPA, formed a group known as the "steering committee” to
help guide the design work and ensure that the research community's needs
were addressed.
This committee met twice a year between April, 1981 and June, 1983, and
included [name list as before]. Beginning in 1984, these meetings were
supplanted by workshops that were expanded to include many more people.”
This shift in membership after 4.2BSD shipped had already been noted. The committee seems to have had a productive start:
"An initial document proposing facilities to be included in the new system
was circulated to the steering committee and other people outside Berkeley
in July, 1981, sparking many lengthy debates.”
I would assume that those initial discussions included debates on what would become the socket API. I’ve asked Kirk McKusick if he still remembered that initial discussion document. The reply was:
"The document to which you refer became known as the "BSD System
Manual". The earliest version that I could find was the one
distributed with 4.2BSD in July 1983 which I have attached.”
If anyone knows of earlier versions of that document (prior to 1982), I’d be highly interested.
The paper also notes:
"During the summer, Joy concentrated on implementing a prototype version
of the interprocess communication facilities.”
I’ll scan the early (partial) SCCS logs for remnants of that (a long shot, but worth a try).
Paul
> From: Will Senn
> 1. How do you escape # in order to write a C program if # is the erase
> character in the terminal?
"Use the source, Luke!" V7 is simple enough that it's pretty quick to find
the answers to things like this. E.g.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/dev/tty.c>
will answer this question (in "canon()").
> 3. Is there a way to echo the ascii value of a keypress in v7?
A quick look through tty.c suggests this doesn't exist in V7 - without running
a user program that puts the TTY in 'raw' mode and prints out what it
sees. Not sure if there is one off the rack, or if you'd have to whip up a
20-line program to do it.
Noel
After installing a fresh simh V7 instance with 2 RP06's and a TU10, I
tried building the kernel and running it. I got a panic. I didn't mess
with the defaults, so I'm at a loss as to how the stock kernel is
different from the one I built. I tried building as root, then sys, same
effect. Here's what I did:
nboot.ini contents:
set cpu 11/70
set cpu 2M
set cpu idle
set rp0 rp06
att rp0 rp06-0.disk
set rp1 rp06
att rp1 rp06-1.disk
boot rp0
pdp11 nboot.ini
boot
hp(0,0)unix (actually renamed hptmunix)
mem = 2020544
CTRL-D
login: root
cd /usr/sys/conf
make allsystems
... build stuff, no errors or warnings
mv hptmunix /
sync
sync
CTRL-E
quit the sim
pdp11 nboot.ini
boot
hp(0,0)hptmunix
mem = 2021696
err on dev 0/0
bn=1 er=100000,4507
err on dev 0/0
bn=1 er=100000,4521
err on dev 0/0
... etc.
Am I doing something wrong or missing an important configuration step. I
am just trying to rebuild the stock kernel before I try any
reconfigurations.
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Hi all,
I just finished creating an updated PDF version of a blog post I did a
couple of years back, describing how to install and use Unix v7 in SimH.
It's updated for 2017 and MacOS High Sierra 10.13. I started the update
because I was wanting to do some research in v7 and thought it would be
good to have a current set of instructions but really because I was
interested in learning a bit about LaTeX and creating prettier, more
useful documents. The notes still work fine as originally written, but I
organized things a little differently and tweaked some of the language.
I thought somebody else might like having a PDF version around so I
uploaded the result, call it revision 1.1, and made it publicly
accessible (the blog still needs updating, somebody oughta do something
about link impermanence, but that's all for another day). Feel free to
comment or complain. I added a section in honor of dmr at one
commenter's suggestion. Here's the link:
https://drive.google.com/open?id=0B1_Jn6Hlzym-Zmx1TjR3TENDQTA
Later,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
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