Don't know if this is of interest to anybody out there, but I was
just looking for something else in the basement and came across
two notebooks that look like a UNIX System Internals course. Appears
to cover version 6, version 7, PWB, 32V, System III, and System V.
Has the Western Electric seal of disapproval on the front.
Jon
I'd love to see this stuff. Were I not so far away I'd offer
to scan them for you, but it shouldn't be hard to find someone
who can in the Bay Area. (Attention USENIX Association, I
approve use of my membership dues to support this!)
Norman Wilson
Toronto ON
This email is two parts. I am researching 1970's symbolic name to
network address mapping routines.
1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since
this is Unix list, for Unix is fine :)
RFC 597 (12 December 1973) says a hostname list will be maintained at
the NIC with the location to be announced. (Interestingly NIC as in
FEINLER@NIC is probably a nickname as it is not listed in the host
status list. I am guessing it is a nickname for SRI-ARC or OFFICE-1.)
RFC 606 (December 1973) says there are different hosts lists, but "now"
there is "the official list of host names". It proposed that it should
be maintained online in machine-readable form. It proposes a format and
suggested attributes.
RFC 607 (January 10, 1974) the NIC agrees that NIC maintain a text file
of hostnames, addresses, and attributes. (It has also been suggested
separately.) The source is maintained in NLS format with multiple
attributes. (What is this NLS format?) A program could be written to
generate a weekly ASCII file. They will write the program and the
generated file will be at OFFICE-1 (IMP #43?) with pathname of
<NETINFO>HOSTS.TXT (It's not Unix. It's TENEX I think. The ">" is the
directory delimiter, but what is "<"?)
I have found a few copies of a hostname table, like
https://emaillab.jp/pub/hosts/1974/host_names_1974.pdf and
https://www.bortzmeyer.org/files/hosts.txt-1982-1.pdf But these don't
appear to be the machine parseable files as defined in the RFC 608
format. These are just printed formats. (I have also found many of the
host status reports.)
Well I cannot find a copy of the HOSTS.TXT file anywhere. I am not
looking for the RFC 810 (1 March 1982) or later format (which is easily
found).
http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_3_19910112/01/utility/ps-p…
may have copies of it (old format is OHOSTS.TXT). But I cannot figure
out if or where there are individual file downloads there. Any ideas?)
That leads me to my question ... does anyone know where parser code for
the HOSTS.TXT file is at?
2) I skimmed through some C code (for Unix) for sendmsg, mmdf, srvrftp,
mailer.c, telnet.c that use /dev/net/ followed by up to 14-character
hostname. I am trying to find the kernel code or routines that enable
device driver named with a hostname. Any ideas? (In particular I'd like
to know how those names map to a remote host's address.)
I am researching 1970's symbolic name to network address mapping
routines, but the only ones I have found are primitive: Purdue's "modest
UNIX network" using mx and Berkeley's Berknet (single letter hostnames).
But both use simple compiled-in name-to-address tables. (The Purdue
implementation looks interesting as it has some design to connect
between IMPs too, but I don't see any code for finding IMP numbers via
names. By the way, their "csh" tool was their "connected shell" to run a
shell on a remote host. The manual had the list of hostnames in it. See
the Purdue usenix tape.)
Thanks,
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
Long ago, I could swear I'd read a paper (or a TM, or something) that
described the process of a Unix system booting. It presented a timeline
describing the sequence of how the boot blocks are loaded, the kernel
is loaded, MMU turned on, etc.
However, other than that, I can't recall a thing about it - can't remember
the title, the author, or where I found it. I don't remember if it talked
about this process on a Bell Labs Unix system, or a BSD system (though it
had to be one of those - either 7th Edition or BSD). The timeframe was
probably mid to late 1980's, though I could be wrong about that.
Does this ring a bell with anyone? I really wish I could find it again...
--Pat.
What is Dennis's character? Is he very humorous? Thank you.
He was more humorous when he was still alive, but I think
he would have appreciated this joke.
Norman Wilson
Toronto ON
> From: Charles Anthony
> The Multics System Initialization Program Logic Manual. 139 pages of
> somewhat detailed information.
I was going to mention the Multics init PLM! :-) Needless to say, it's
probably not a good candidate for the original goal - a document describing
how an OS boots - it's simply too complicated for ordinary mortals! (Reading
it makes _my_ head hurt!) There are a couple of reasons it's so complex.
Multics is not a monolitic OS, the way most versions of Unix are (although I
gather this is no longer quite true of Linux); the OS isn't this large blob
of bits you load into memory and start. Its structure makes heavy use of the
segmentation model supported by the hardware. Moreover, although the first
segments loaded aren't paged, many of the later ones are. (This makes sense
in the context of the times; with limited core main memory, you wouldn't want
to devote massive chunks of main memory to have the entire OS always
resident.)
However, this all makes for a more complex booting process; the standard
Multics boot tape (a Multics System Tape) contains many modules, which get
linked in individually at boot time. (In V6 terms - the version I'm most
familiar with - it's as if a Unix boot tape contained 'lib1' and 'lib2', and
the bootstrap included a linker to build the OS binary in memory.) And in fact
the modules come in in tranches, and some of the earlier one are available for
use in loading later tranches (e.g. paging).
This does have some advantages, though; e.g. the MST is the same for all
Multics machines (including the initial boot of a new machine); the system is
customized to the particular configuration during the bootstrap process. This
is actually not too crazy, there are reasons this makes sense.
For one, the whole 'information utility' concept (where Multics admittedly
went down the wrong path, in terms of the future of computers); a single
giant machine (multi-processor, multi-memory bank, multi-I/O controller). The
thing is that any of these could be switched out if it developed a fault, but
then you have to be able to boot that new configuration. (In particular,
Multics wasn't a master-slave multi-processor system, they're all the same;
but only one CPU runs for most of booting, the others are started and added
once the system is running. But the 'bootstrap CPU' might change if the
original bootstrap CPU develops a fault...)
Noel
> From: Warren Toomey <wkt(a)tuhs.org>
> That's all I knew at the time :-)
:-) I used nroff/troff for a bit, but I didn't like it; I don't recall why,
but I suspect I wasn't using people's macro packages, which probably made it
more difficult to use. My favourite was SCRIBE, but it alas seems to have
died.
> From: Dan Cross <crossd(a)gmail.com>
>> the original Western Electric copies are not troff'ed and run through
>> a typesetter ...
> Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be,
> roughly, a facsimile of line printer output. ...
> Interestingly, the title page appears to be approximately original and
> is typeset.
I finally located my copy of the reprint (I'd been using it to help Fritz
Mueller find a problem in his RK11C, and it wasn't in its normal place), and
comparing it with my 'samizdat' set (which came from a set owned by
Lincoln-Sudbury High School - they actually had an -11 running V6, I helped
their computer person, I forget his name now, with it), I can confirm that:
- The reprint does mostly reproduce the exact page images from the original
(which was indeed, mostly line-printer out), except that the original does not
have the typeset chapter/section header pages. It's possible that the pages in
the reprint are a new printing, but if so, they have exactly matched not only
the layout (not too hard) of the original, but also the font.
- In a couple of places (e.g. Contents, pg. 1; Preface, pg. 1; Chapter One,
pg. 1) "UNIX" has been replaced by "UNIX*" (different font), and at the bottom
of the page has been added "* UNIX is a Trademark of Bell Laboratories", again
in a different font.
- The typeset 'Source Code' title page is in the original; the copy in the
reprint is an exact image, except that the upper-case "This information ...
Written permission of Bell Laboratories" section is not in the original,
which says instead at that place: "This document may contain information
covered by one or more licenses, copyrights and non-disclosure agreements.
Circulation of this document is restricted to holders of a license for the
UNIX Software System from Western Electric. All other circulation or
reproduction is prohibited."
- The typeset 'Commentary' title page is different in my samizdat First
Edition original; it's a copy of the other title page, except that the
second para is replaced by the first sentence of the 'Commentary' title
page of the reprint, and of course the title is different from the other
volume.
Noel