Dear PUPS/TUHS members,
I have just logged into minnie and diffed the files Tim Shoppa has just
uploaded against the 43reno.vax distribution in my home directory. They are
identical byte for byte, except that Tim's first file is severely
truncated. The first file contains the bootstraps and the standalone
programs, and for Reno it's about 140 KB. Tim's first file is only 512
bytes, although these bytes exactly match the first 512 bytes in the
correct first file.
Resolution: the files Tim has uploaded are completely superseded by the
authentic 4.3BSD-Reno/VAX distribution in /usr/home/msokolov/43reno.vax and
/usr/PUPS/Distributions/4bsd/43reno.vax.
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA13933
for pups-liszt; Sun, 22 Nov 1998 14:04:29 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Tim Shoppa <SHOPPA(a)trailing-edge.com> writes:
> Some further clues, for anyone who's following this bit or
> archeology:
This is clearly a 4.3BSD-Reno tape (for VAX). I'll look at it when it's
fully uploaded (you're saying it won't be until 19:00 EST, so it'll be
after the X-Files I guess), but I can bet that it's identical to the one in
/usr/home/msokolov/43reno.vax on minnie (read by Rick Copeland from the
CSRG master provided by Marshall Kirk McKusick).
> The second file on the tape has the following string in it:
>
> 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990
> trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot
The second file is the dd image of the miniroot filesystem. This string
appears in the /vmunix file inside (the kernel). kerberos.berkeley.edu was
a VAX. The tape in /usr/home/msokolov/43reno.vax has also been pressed from
kerberos.berkeley.edu.
> The third file has this string in it:
>
> 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990
> trent@kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax.
The third file is the dump of the full root filesystem. Again, this
string appears in the /vmunix file inside.
> Additionally, in the third file, there appears to be some printf-type
> strigns for configuring in the different possible CPU's supported:
>
> VAX 8600, serial# %d(%d), hardware level %d(%d)
> VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d
> VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d)
> VAX 11/750, hardware rev %d, ucode rev %d
> VAX 11/730, ucode rev %d
> MicroVAX-II-MicroVAX 3000, ucode rev %d
This is also obviously inside /vmunix. The set of supported CPUs is the
one for Reno.
> So the tape sticker says "Tahoe", the miniroot and Generic root claim
> to be Reno, and the fourth file (the tar archive) has the following
> mentions of Tahoe and Reno:
>
> [names on manpage directories mentioning tahoe]
It is Reno. Trust me. "tahoe" appears in the names of some manpage
directories because some manpages are architecture-specific (tahoe is the
name of a computer architecture, just like vax, hp300, i386, etc.). The
tape is mislabeled, that's all.
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA13713
for pups-liszt; Sun, 22 Nov 1998 12:47:28 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Some further clues, for anyone who's following this bit or
archeology:
The second file on the tape has the following string in it:
4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990
trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot
The third file has this string in it:
4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990
trent@kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax.
Additionally, in the third file, there appears to be some printf-type
strigns for configuring in the different possible CPU's supported:
VAX 8600, serial# %d(%d), hardware level %d(%d)
VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d
VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d)
VAX 11/750, hardware rev %d, ucode rev %d
VAX 11/730, ucode rev %d
MicroVAX-II-MicroVAX 3000, ucode rev %d
So the tape sticker says "Tahoe", the miniroot and Generic root claim
to be Reno, and the fourth file (the tar archive) has the following
mentions of Tahoe and Reno:
$ sear file4.tar_list tahoe
755 0 Jul 29 06:26:47 1990 share/man/cat4/tahoe/
444 2488 Jul 29 06:26:43 1990 share/man/cat4/tahoe/ace.0
444 3563 Jul 29 06:26:44 1990 share/man/cat4/tahoe/autoconf.0
444 1321 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cons.0
444 6446 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cy.0
444 4074 Jul 29 06:26:44 1990 share/man/cat4/tahoe/dr.0
444 2331 Jul 29 06:26:44 1990 share/man/cat4/tahoe/enp.0
444 4121 Jul 29 06:26:44 1990 share/man/cat4/tahoe/ik.0
444 2498 Jul 29 06:26:45 1990 share/man/cat4/tahoe/intro.0
444 386 Jul 29 06:26:45 1990 share/man/cat4/tahoe/lp.0
444 4427 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mtio.0
444 9321 Jul 29 06:26:45 1990 share/man/cat4/tahoe/vd.0
444 3816 Jul 29 06:26:46 1990 share/man/cat4/tahoe/vx.0
444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mem.0
444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/kmem.0
---> share/man/cat4/tahoe/mem.0
755 0 Jul 4 18:49:29 1990 share/man/cat6/tahoe/
$ sear file4.tar_list reno
%SEARCH-I-NOMATCHES, no strings matched
If someone who is more aware of the 4.3BSD histories than I am
(and I'm certain that I'm one of the least-aware folks around!)
can pinpoint where in the hierarchy this tape belongs, it'd help
settle a lot of my confusion!
In the meantime, the FTP connection to minnie seems to be holding
up admirably, and folks will be able to inspect the files for themselves
sometime around 7 PM EST tonight (Saturday here - that's either
tomorrow or yesterday in Australia, I can never remember which)
in the directory
/usr/home/shoppa/43bsd_tahoe
on minnie.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13145
for pups-liszt; Sun, 22 Nov 1998 10:13:57 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
> The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe
>tape with VAX binaries.
I think I *might* be able to provide part of the solution to this. I have
in my posession here a TK50 tape hand-labeled "4.3 Tahoe BSD". Let me upload
it to my directory on Minnie, and maybe with some help from you guys
we'll figure out what's in it.
It has been at least a year since I've looked at the contents of this
tape, but I was under the impression that it consisted mainly of binaries,
and had very little in the way of sources on it. I'll put images of
the tape files on Minnie (hmm - a full TK50 will probably be an overnight
job) and with a little luck we'll figure out how to
make the next step. (I didn't know that this was a sought-after tape
in the first place!)
I honestly don't know if this is a VAX Tahoe distribution or for something
else (MIPS, maybe?). It did fail to boot on my KA650 when I tried it, but
your notes indicate that this was to be expected because it wasn't a KA630.
And browsing through the contents of the tape does seem to indicate that it
might be for the VAX.
The tape has 4 files on it, about 50 Megabytes uncompressed, organized as
follows:
File 1: 1 record, 512 bytes.
File 2: 205 records, 10240 bytes each.
File 3: 320 records, 10240 bytes each.
File 4: 2135 records, 20480 bytes each.
The first block has no obvious text in it. Obvious guess is a boot block :-)
The second file appears to be an executable of some sort. Running
"strings" against it turns up evidence that this is some sort of standalone
utility that knows how to write to devices with names like "ra1", "hp3",
etc.
The third file is, I would guess, the dump of a root file system.
The string "/dev/ra1a" and machine name "kerberos.berkeley.edu" turn
up near the beginning, and the dump of what appears to be the "/dev"
directory has names such as tu0, tu1, hp0a-hp0g, rhp0a-rhp0g, etc.
The fourth file is a tar archive, and appears to contain mainly binaries,
with little in the way of sources. The are links in the tar archive
to things like "/sys/vaxuba", "/sys/vax", etc., but the /sys directory
itself isn't in the tar archive. (Would this possibly be in the third
file, which I guessed is a dump of the root filesystem? The other BSD-
derived distributions that I'm familiar with do not have "/sys" or
"/usr/src/sys" in the root filesystem!)
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA12866
for pups-liszt; Sun, 22 Nov 1998 08:41:48 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
SHOPPA(a)trailing-edge.com writes:
> I've been looking over the recent 4.3-ish BSD distributions
> now available from the PUPS archive. Thought I'd spin off
> a copy for booting on one of my spare uVax II's [...]
The most important thing here is to choose the right version of BSD.
Plain 4.3 CANNOT boot on a MicroVAX II. Later versions, starting with
Tahoe, can. The patches provided in 4.3_on_uVax_instructions are nothing
more than pieces taken out of Tahoe. If you are going to use those, you
might want to use the whole Tahoe system just as well, it has some very
nice improvements, such as disk labels, better man mechanism, and MX record
support in sendmail.
The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe
tape with VAX binaries. I'm not sure if CSRG ever bothered to even make
one, although it's as simple as executing one script on a running system
(which they obviously had). Thus in order to run Tahoe, one would have to
cross-compile it first. It's a pain and takes a lot of expertise, so I
would strongly advise you to avoid effort duplication and wait until I do
it and put the product up in my home directory on minnie.cs.adfa.edu.au.
Actually since KA650 is all I have right now and Tahoe doesn't support it
(but the support code appears later in the SCCS tree), I'll go directly
from Ultrix (my cross-compilation base) to Quasijarus1, my first release,
and won't bother with Tahoe. But for all practical purposes Quasijarus1
will be Tahoe plus KA650 support, shadow passwords, and bugfixes.
Hmm, maybe your have never heard of Quasijarus Project, so I'll explain
briefly what it is. I'm taking over UCB CSRG in terms of shepherding and
maintaining pure Berkeley UNIX(R). I will first re-create it by taking
their final SCCS tree and building my initial one, deciding piece by piece
what belongs to pure Berkeley UNIX(R) and should be kept, and what is POSIX
evil spirit or bloat and should be tossed. In general I draw the line right
around the Tahoe release (summer of 1988), but I'll include anything from
Reno and later code that's worth having, such as KA650 support and Reno's
DBM-based shadow password model. Basically, I want to create a system with
a classical (pre-Reno) look and feel which at the same time has all the
quality improvements and bugfixes ever made by Berkeley, even if they are
as late as 4.4BSD. The last classical release is Tahoe, so that's my base.
I will be using Tahoe to decide what should be included and what should the
look and feel be. Once I know from Tahoe that a given piece should be
included, I'll go to the SCCS file(s) for that piece and decide which post-
Tahoe deltas should be kept (because they are bugfixes or quality
improvements) and which deltas should be tossed (because they introduce the
evil spirit of POSIX or bloat).
How soon will this happen? I'm all ready to go, but unfortunately
hardware problems are holding me back. I have solved the KA650 problem I
was having, but now I'm stuck because neither of the two TQK50 boards I
have works. (The drive SEEMS to work, though.) Thus the sooner I find a
working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the
sooner will I make 4.3BSD-Quasijarus1.
> If there's a more appropriate forum for these questions, I'd
> appreciate being redirected to them!
Right now there isn't, because my main VAX farm is currently off the
net. When I get it back on the net (no time estimate, at least several more
months), I'll set up a set of mailing lists for Quasijarus Project and
Berkeley VAX UNIX in general.
> OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is:
Totally disregard these instructions, they are for plain 4.3 ONLY. If
you are using Tahoe or Quasijarus1, the distribution already supports
MicroVAXen as shipped. If you don't want to use Tahoe or Quasijarus1 and
want to use plain 4.3, you are on your own.
> Is this an actual limitation on the 43reno.vax distribution currently
> in the archive, or not?
Reno doesn't have any limitations, it already supports KA630 and KA650,
just like Quasijarus1. I personally don't use it, though, because it is not
really True UNIX any more. With the evil spirit of POSIX and a bloat by a
factor of 2 in both binaries and sources, Reno is the beginning of the
destructive process that eventually (and necessarily) culminated with the
disbanding of CSRG.
> what non-
> microvax machines will the 43reno.vax distribution boot on? 11/750?
> 11/730?
Of the big VAXen, plain 4.3 supports 11/780, 11/750, 11/730, and Venus
(should have been called 11/790, but was unfortunately named 8600). Tahoe
adds, and Quasijarus1 and Reno retain, the support for 8200.
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA12654
for pups-liszt; Sun, 22 Nov 1998 07:42:18 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
I've been looking over the recent 4.3-ish BSD distributions
now available from the PUPS archive. Thought I'd spin off
a copy for booting on one of my spare uVax II's, but I'm stuck
at (literally) before step one, and don't know where to go from here.
If there's a more appropriate forum for these questions, I'd
appreciate being redirected to them!
OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is:
YOU MUST ALREADY HAVE A WORKING VAX! These instructions are useless on
a cold machine. You must have a 4.3 machine and a working uVax (probably
Ultrix!) with a tk50 drive.
Apparently, this is because the distributions don't boot on a
Microvax, and the KA630 Microvax/MSCP/TMSCP patches must be installed
and many things rebuilt on a 4.3 machine before a distribution tape can
be built to put on a VAX.
Is this an actual limitation on the 43reno.vax distribution currently
in the archive, or not? If it is a real limitation, what non-
microvax machines will the 43reno.vax distribution boot on? 11/750?
11/730?
Tim. (shoppa(a)trailing-edge.com)
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA12354
for pups-liszt; Sun, 22 Nov 1998 06:15:56 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Dear Ladies and Gentlemen,
I'm trying to build my first release (4.3BSD-Quasijarus1), and I have
the following problem. I'm currently away from my main VAX farm, and so I
have rounded up a new VAX for this task from an independent source. It's a
KA650-based MicroVAX specially made for Xerox. The outer cabinet is made by
Xerox, but it has a BA23 mounted inside. There is no video, just a serial
terminal.
My first problem was that the beast refused to power up. I turn on the
power, but there is nothing on the console and the hex LED display on the
back says 9. I power-cycled it several times with zero effect, and then I
took the CPU board out to look at it. It looked perfectly normal, and I put
it back in. Then imagine my joy when I power up the VAX and this time it
works! After that I worked with it for a while, and in the process I turned
it on and off a couple of times and it didn't have any problem powering up.
My next step was installing Ultrix, which is the platform I have chosen
to use for putting together the initial Quasijarus SCCS tree and cross-
compiling the very first Quasijarus build. However, when I tried to boot
from the Ultrix tape, I got a "?4B CTRLERR" (after an _extremely_ long wait
with a lot of retries), which according to my docs means some hardware
error. I reasoned that it has to be either the TK50 drive or the TQK50
controller. I don't have any spare TK50s at this location, but I do have
one spare controller, and so I tried swapping it. I turned the machine off,
swapped the board, and turned it back on. And guess what, that ugly 9 came
back! I haven't been able to power up the VAX since then.
I started investigating. I don't have any docs for KA650, but I do have
some for KA655. According to these docs, the KA650 series CPUs have very
elaborate ROM diagnostics organized in the form of scripts, some of which
are executed at power-up. The manual lists all scripts, indicating the
order of the tests and the hex LED display codes. According to this manual,
the only tests which display a 9 are fairly late in the sequence and are
fairly benign (shouldn't stall the power-up even if failed). The problem
I'm seeing, OTOH, appears to be very early. For example, the console line
loopback test appears to be one of the very first, and yet my VAX always
stalls on the 9, even if I put the switch in the T-in-the-circle position.
I have also watched the hex LED display very carefully right as I flip the
power switch, and as far as I can tell it goes directly from F (waiting for
DCOK) to 9. Finally, disconnecting the bulkhead and the memory interconnect
produces absolutely no effect, suggesting that the culprit is the CPU board
and nothing else. Also pushing the RESTART button on the front panel
produces absolutely no effect, if the 9 was there it just stays there,
there is no F appearing for a short time or anything like that. What does
the RESTART button do, anyway?
Does anyone here have a clue as to what's going on? Does anyone have a
KA650 manual? Can anyone tell what the hell does the 9 stand for? Any ideas
on how this can be fixed (other than replacing the CPU board)? TIA.
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA06383
for pups-liszt; Fri, 20 Nov 1998 19:08:01 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Brian D Chase <bdc(a)world.std.com> Fri Nov 20 18:07:44 1998
Received: from europe.std.com (europe.std.com [199.172.62.20])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id TAA06373
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 20 Nov 1998 19:07:51 +1100 (EST)
(envelope-from bdc(a)world.std.com)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0)
id DAA11514; Fri, 20 Nov 1998 03:07:45 -0500 (EST)
Received: from localhost by world.std.com (TheWorld/Spike-2.0)
id AA01332; Fri, 20 Nov 1998 00:07:44 -0800
Date: Fri, 20 Nov 1998 00:07:44 -0800 (PDT)
From: Brian D Chase <bdc(a)world.std.com>
To: PUPS Mailing List <pups(a)minnie.cs.adfa.oz.au>
Cc: NetBSD/vax Mailing List <port-vax(a)netbsd.org>
Subject: Loads of PDP-11 docs on Ebay.
Message-Id: <Pine.SGI.3.95.981120000517.28198A-100000(a)world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Just an FYI for all you PDP-11 collectors out there. A search for "DEC"
under the Computers section of Ebay yields an impressive number of PDP-11
docs.
-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA09000
for pups-liszt; Sat, 21 Nov 1998 09:58:30 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Greg Lehey <grog(a)lemis.com> Sat Nov 21 08:57:40 1998
Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA08995
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 21 Nov 1998 09:58:21 +1100 (EST)
(envelope-from grog(a)freebie.lemis.com)
Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137])
by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA27497;
Sat, 21 Nov 1998 09:27:46 +1030 (CST)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.1/8.9.0) id JAA05923;
Sat, 21 Nov 1998 09:27:40 +1030 (CST)
Message-ID: <19981121092740.F1005(a)freebie.lemis.com>
Date: Sat, 21 Nov 1998 09:27:40 +1030
From: Greg Lehey <grog(a)lemis.com>
To: Brian D Chase <bdc(a)world.std.com>,
PUPS Mailing List <pups(a)minnie.cs.adfa.oz.au>
Cc: NetBSD/vax Mailing List <port-vax(a)netbsd.org>
Subject: Re: Loads of PDP-11 docs on Ebay.
References: <Pine.SGI.3.95.981120000517.28198A-100000(a)world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <Pine.SGI.3.95.981120000517.28198A-100000(a)world.std.com>; from Brian D Chase on Fri, Nov 20, 1998 at 12:07:44AM -0800
WWW-Home-Page: http://www.lemis.com/~grog
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote:
> Just an FYI for all you PDP-11 collectors out there. A search for "DEC"
> under the Computers section of Ebay yields an impressive number of PDP-11
> docs.
What's Ebay?
Greg
--
See complete headers for address, home page and phone numbers
finger grog(a)lemis.com for PGP public key
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA09072
for pups-liszt; Sat, 21 Nov 1998 10:32:18 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Brian D Chase <bdc(a)world.std.com> Sat Nov 21 09:31:51 1998
Received: from europe.std.com (europe.std.com [199.172.62.20])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA09067
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 21 Nov 1998 10:32:10 +1100 (EST)
(envelope-from bdc(a)world.std.com)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0)
id SAA23532; Fri, 20 Nov 1998 18:31:51 -0500 (EST)
Received: from localhost by world.std.com (TheWorld/Spike-2.0)
id AA16761; Fri, 20 Nov 1998 15:31:51 -0800
Date: Fri, 20 Nov 1998 15:31:51 -0800 (PDT)
From: Brian D Chase <bdc(a)world.std.com>
To: Greg Lehey <grog(a)lemis.com>
Cc: PUPS Mailing List <pups(a)minnie.cs.adfa.oz.au>,
NetBSD/vax Mailing List <port-vax(a)netbsd.org>
Subject: Re: Loads of PDP-11 docs on Ebay.
In-Reply-To: <19981121092740.F1005(a)freebie.lemis.com>
Message-Id: <Pine.SGI.3.95.981120153054.16667A-100000(a)world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
On Sat, 21 Nov 1998, Greg Lehey wrote:
> On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote:
> > Just an FYI for all you PDP-11 collectors out there. A search for "DEC"
> > under the Computers section of Ebay yields an impressive number of PDP-11
> > docs.
>
> What's Ebay?
Sorry about that... I'd thought everybody knew by now. It's the world's
largest and most popular on-line auction service. http://www.ebay.com/
-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA12024
for pups-liszt; Sun, 22 Nov 1998 04:51:52 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Dear PUPS/TUHS members,
I have just uploaded the images from the 4.3BSD tapes I had read on
CWRU's MVS mainframe back in June. They are perfect (the 1600 BPI tapes
were read without any errors and the format is absolutely correct). Note,
though, that this is the June 1986 4.3BSD release, and I remember Kirk
saying that among the tapes Rick is reading there is one with 4.3BSD
revision 2, which is presumably 4.3BSD with some bugs fixed.
I have also put an honest effort into reconstructing the 4.2BSD tape
images from the files in Distributions/4bsd/Per_Andersson_4.2. The latter
have the boot/standalone system file (1st on the tape) broken, the tarball
with /usr/src also broken, and the tarball with /usr/lib/vfont simply
missing. I have manually repaired the boot/standalone system file (using my
brain and a hex editor), but unfortunately /usr/src is broken beyond repair
(so I didn't include it in my repackaging). I see no reason for the
Varian/Versatec fonts to change between BSD releases, so /usr/lib/vfont
from 4.3BSD will probably do fine. It would still be nice if Rick could
read Kirk's 4.2BSD tapes, though. For practical use 4.3BSD completely
supersedes it, but for historical purposes we should preserve 4.2BSD as
well.
This stuff is in:
/usr/home/msokolov/42.vax (4.2BSD)
/usr/home/msokolov/43.vax (4.3BSD)
on minnie.cs.adfa.oz.au. (Warren, if you want to put this in the main
PUPS archive, go ahead and do it for 43.vax, as it should be ready to be
frozen, but I would hold on with 42.vax. Hopefully Rick will have some luck
reading Kirk's tapes, and then I'll update the 42.vax directory by filling
the missing pieces.)
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA15543
for pups-liszt; Tue, 17 Nov 1998 06:04:29 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Rick Copeland <rickgc(a)calweb.com> Tue Nov 17 05:14:44 1998
Received: from mail.calweb.com (mail.calweb.com [208.131.56.12])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA15538
for <pups(a)minnie.cs.adfa.oz.au>; Tue, 17 Nov 1998 06:04:19 +1100 (EST)
(envelope-from rickgc(a)calweb.com)
Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id LAA06615;
Mon, 16 Nov 1998 11:04:05 -0800 (PST)
X-SMTP: helo rgc from rickgc(a)calweb.com server @12.22.0.83 ip 12.22.0.83
Message-Id: <3.0.32.19981116111440.00922460(a)pop.calweb.com>
X-Sender: rickgc(a)pop.calweb.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 16 Nov 1998 11:14:44 -0800
To: wkt(a)cs.adfa.oz.au
From: Rick Copeland <rickgc(a)calweb.com>
Subject: Re: 4.3BSD-Tahoe and 4.3BSD-Reno
Cc: pups(a)minnie.cs.adfa.oz.au
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Warren,
I am unable to login to minnie, I keep getting back "user rickgc access
denied!". Why?
Thanks,
Rick Copeland
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA05416
for pups-liszt; Fri, 20 Nov 1998 12:57:22 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Dear PUPS/TUHS members,
I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently
uploaded into a more convenient format. I haven't changed anything in the
images themselves, I have simply repacked them from a single .zip into a
collection of .gz's, one per tape file. I have also prepared a listing for
every tarball. This stuff is in:
/usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries)
/usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries)
That's on minnie.cs.adfa.oz.au. The permissions are set up so that pupsarc
group members (UNIX source license holders) can read them, but no one else can.
With Warren's permission, I would like to keep this stuff there until I set up
my own FTP site, at which time I'll announce its location.
The Reno images are perfect, but for Tahoe usr.tar.gz and src.tar.gz are bad
(everything else is fine). Apparently Rick wasn't able to read past a tape
defect (we are handling this in private E-mail).
Have fun with this stuff!
Sincerely,
Michael Sokolov
Phone: 440-449-0299 (Home) 216-217-2579 (Cellular)
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04992
for pups-liszt; Thu, 12 Nov 1998 14:37:26 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Thu Nov 12 14:51:32 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id OAA04987
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 12 Nov 1998 14:36:57 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id PAA05125 for pups(a)minnie.cs.adfa.oz.au; Thu, 12 Nov 1998 15:51:32 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811120451.PAA05125(a)henry.cs.adfa.oz.au>
Subject: Re: 4.3BSD-Tahoe and 4.3BSD-Reno
Date: Thu, 12 Nov 1998 15:51:32 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au
In-Reply-To: <199811120455.XAA09098(a)skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 11, 98 11:55:23 pm"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
In article by Michael Sokolov:
>I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently
> uploaded into a more convenient format. I haven't changed anything in the
> images themselves, I have simply repacked them from a single .zip into a
> collection of .gz's, one per tape file. I have also prepared a listing for
> every tarball. This stuff is in:
>
> /usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries)
> /usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries)
I'll move copies of Michael's 43tahoe.cci and 43reno.vax directories
into the main PUPS archive area, in the Distributions/4bsd area.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id WAA01355
for pups-liszt; Fri, 13 Nov 1998 22:58:33 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
Warren Toomey <wkt(a)henry.cs.adfa.oz.au> writes:
> Unfortunately, Michael's email address has stopped working i.e whatever
> machine holds the MX record isn't taking incoming mail messages.
Actually there is no MX record. blackwidow.CWRU.Edu is an alias (CNAME
record) for blackwidow.SOML.CWRU.Edu, which has IP address 129.22.50.4.
This IP address belongs to my VAX running Ultrix. Some time last week it
stopped responding to ping, and because I'm off-campus since 3-AUG-1998 I
can't do anything about it right now. If everything works out OK, I should
be able to come back to campus and get my machine back up the coming
Monday, 17-AUG-1998.
Sincerely,
Michael Sokolov
Cellular Phone: 216-217-2579
*TEMPORARY* ARPA Internet SMTP mail: gq696(a)cleveland.freenet.edu
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id IAA04850
for pups-liszt; Fri, 14 Aug 1998 08:54:26 +1000 (EST)
>From Rick Copeland <rickgc(a)calweb.com> Fri Aug 14 09:03:04 1998
Received: from mail.calweb.com (mail.calweb.com [208.131.56.12])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id IAA04845
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 14 Aug 1998 08:54:20 +1000 (EST)
Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id PAA28451
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 13 Aug 1998 15:54:12 -0700 (PDT)
X-SMTP: helo isd from rickgc(a)calweb.com server @sac12-81.calweb.com ip 207.211.93.81 user=rickgc
Message-Id: <3.0.32.19980813160254.0091bbe0(a)pop.calweb.com>
X-Sender: rickgc(a)pop.calweb.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 13 Aug 1998 16:03:04 -0700
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
From: Rick Copeland <rickgc(a)calweb.com>
Subject: PDP-1103
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Dear List,
I am trying to work with a PDP 1103 that has been removed from a Vax
11/785. The goal is to be able to write RX01's with the required boot
blocks required by NetBSD Vax to boot the 11/785. I figured that since I
had several of these 1103's that I could set one up specifically to write
RX01's by running some kind of operating system on one that would talk to
one of my other machines(Sun 3/80 running NetBSD, Sparc 2 running Solarus
2.51, Vax 3600 running NetBSD, i86's running FreeBSD, NetBSD, Windows 95)
via rs232 or what ever.
Anyone got any ideas how I might do this?
Thanks,
Rick Copeland
Information Systems Manager
InterMag, Inc.
(916) 568-6744 x36
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id AAA28571
for pups-liszt; Wed, 19 Aug 1998 00:32:06 +1000 (EST)
>From Tim Bradshaw <tfb(a)aiai.ed.ac.uk> Wed Aug 19 00:31:38 1998
Received: from aiai.ed.ac.uk (eigg.aiai.ed.ac.uk [129.215.41.7])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id AAA28566
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 19 Aug 1998 00:31:54 +1000 (EST)
Received: from todday.aiai.ed.ac.uk (todday.aiai.ed.ac.uk [129.215.105.40])
by aiai.ed.ac.uk (8.8.7/8.8.7) with ESMTP id PAA03051;
Tue, 18 Aug 1998 15:31:39 +0100 (BST)
Received: (tfb@localhost) by todday.aiai.ed.ac.uk (8.6.13/8.6.12) id PAA19142; Tue, 18 Aug 1998 15:31:38 +0100
Date: Tue, 18 Aug 1998 15:31:38 +0100
Message-Id: <199808181431.PAA19142(a)todday.aiai.ed.ac.uk>
From: Tim Bradshaw <tfb(a)aiai.ed.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Bill/Carolyn Pechter <pechter(a)shell.monmouth.com>
Cc: pups(a)minnie.cs.adfa.oz.au
Subject: Re: Old Unix Preservation -- How to save the SysV varients
In-Reply-To: <199808052115.RAA12664(a)shell.monmouth.com>
References: <199808052115.RAA12664(a)shell.monmouth.com>
X-Mailer: VM 6.32 under 19.14 XEmacs Lucid
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
* Carolyn Pechter wrote:
> One example is Masscomp/Concurrent's early RTU which had dual
> universes (SysIII-SysV/BSD libraries), DEC-like ASTs and real-time processes.
> Concurrent (originally Interdata, Perkin-Elmer) also had a very nice
> non virtual memory SysVRel2 called Xelos as well as Edition VII.
I may well have acces to tapes for RTUs of 1988-89 vintage, as there
were several masscomps here (in fact there still is at least one in
the basement, not working). No source though of course, and without
source they are probably less interesting. I remember RTU as being
deeply unpleasant, but that may have been more due to the HW which was
extremely flaky, at least on the bigger of our machines.
--tim
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id NAA01833
for pups-liszt; Wed, 19 Aug 1998 13:04:43 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Wed Aug 19 13:06:45 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id NAA01828
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 19 Aug 1998 13:04:39 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA12804 for pups(a)minnie.cs.adfa.oz.au; Wed, 19 Aug 1998 13:06:45 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199808190306.NAA12804(a)henry.cs.adfa.oz.au>
Subject: Yet More SCO Licenses
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Wed, 19 Aug 1998 13:06:45 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
A whole bunch of SCO licenses have arrived on my desk, bringing the total
of Ancient UNIX licenses to 67.
Joseph Bickel, Atindra Chaturvedi, Peter Chubb, J. D. Knaebel, Eric Delgado,
Hendrik Dykstra, Glenn Geers, Michael Homsey, Michael J. Haertel, Andrew Lynch,
Keizo Maeda, Giegrich Michael, Lyndon Nerenberg, and Jim Williams
are all now licensed.
Cheers all,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id AAA24019
for pups-liszt; Wed, 2 Sep 1998 00:47:31 +1000 (EST)
>From "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Wed Sep 2 00:42:20 1998
Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id AAA24014
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 00:47:24 +1000 (EST)
Received: (from rdkeys@localhost)
by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id KAA15214;
Tue, 1 Sep 1998 10:42:23 -0400 (EDT)
(envelope-from rdkeys)
From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Message-Id: <199809011442.KAA15214(a)seedlab1.cropsci.ncsu.edu>
Subject: Looking for rationale of fs naming conventions
To: pups(a)minnie.cs.adfa.oz.au
Date: Tue, 1 Sep 1998 10:42:20 -0400 (EDT)
Cc: rdkeys(a)seedlab1.cropsci.ncsu.edu (User RDKEYS Robert D. Keys),
bsdbob(a)seedlab1.cropsci.ncsu.edu (Robert D. Keys)
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
I am curious as to the rationale and reasoning behind:
1) fs naming conventions
2) fs space allocation conventions
3) fs to partition mapping conventions
4) partition conventions
historically in unix (particularly the BSD's).
Why the differences between 4.3 and 4.4 as relates to var?
Why the differences between 4.3 and 4.4 as relates to the contrib sections?
Why the convention of hd0a/b/c/d/e/f/g/h for the various fs? I understand
the reasoning of a/b/c, but after that the rhyme and reason goes wild,
with everyone seemingly doing their own thing. What was the logic of it,
originally?
Why the sizes of the various fs?
I am trying to understand historically the hows and whys things developed
as they did. The SMM's don't really cover it very well.
Thanks
Bob Keys
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id DAA24452
for pups-liszt; Wed, 2 Sep 1998 03:20:52 +1000 (EST)
>From Eric Fischer <eric(a)fudge.uchicago.edu> Wed Sep 2 03:19:07 1998
Received: from fudge.uchicago.edu (fudge.uchicago.edu [128.135.136.68])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id DAA24447
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 03:20:40 +1000 (EST)
Received: (from eric@localhost) by fudge.uchicago.edu (8.7.5/8.7.3) id MAA15499; Tue, 1 Sep 1998 12:19:07 -0500 (CDT)
Date: Tue, 1 Sep 1998 12:19:07 -0500 (CDT)
Message-Id: <199809011719.MAA15499(a)fudge.uchicago.edu>
From: Eric Fischer <eric(a)fudge.uchicago.edu>
To: rdkeys(a)seedlab1.cropsci.ncsu.edu
Subject: Re: Looking for rationale of fs naming conventions
In-Reply-To: <199809011442.KAA15214(a)seedlab1.cropsci.ncsu.edu>
References: <199809011442.KAA15214(a)seedlab1.cropsci.ncsu.edu>
Organization: The University of Chicago
Cc: pups(a)minnie.cs.adfa.oz.au
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
I don't think I really have all the background necessary to answer
these questions, but I'll give it a shot anyway:
> Why the differences between 4.3 and 4.4 as relates to var?
I believe /var originated in SunOS at a time when Sun was heavily
promoting network-mounted file systems. In order to allow /usr to be
mounted read-only across the network from a shared server, it was
necessary to move all the files that would need to be modified by a
running system from their traditional locations in /usr onto a file
system that would be writable (and probably not shared with other
systems). The rearrangement was then widely copied by other systems,
including 4.4BSD.
> Why the convention of hd0a/b/c/d/e/f/g/h for the various fs? I understand
> the reasoning of a/b/c, but after that the rhyme and reason goes wild,
> with everyone seemingly doing their own thing. What was the logic of it,
> originally?
It looks like this one really originated with the Seventh Edition,
where "hp" disks were permanently partitioned as follows:
partition start length
0 0 23 -> a
1 23 21 -> b
2 0 0 -> c
3 0 0 -> d
4 44 386 -> e
5 430 385 -> f
6 44 367 -> g
7 44 771 -> h
(the start and length are in cylinders of 418 blocks apiece)
A generic installation, according to the manual, would put root on
partition 0, swap on partition 1, and /usr on partition 4 or 7.
Partitions 2 or 3 could be used to access an entire disk.
Clearly if partition 4 was used for /usr then partition 5 could be used
for something else, while if 7 was used it would take up the entire
rest of the disk. I'm not sure what the motivation was for the size of
partition 6, even though partition g now seems to be the standard one
for /usr, but presumably the space between cylinders 411 and 430 could
be put to use somehow.
The Sixth Edition also had fixed-size partitions, but of different
sizes than the Seventh Edition used:
partition start length
0 0 9614 -> a
1 18392 65535 -> b
2 48018 65535 -> c
3 149644 20900 -> d
4 0 40600 -> e
5 41800 40600 -> f
6 83600 40600 -> g
7 125400 40600 -> h
(these numbers are in blocks, not cylinders). The manual explains
the motivation for partitioning:
This is done since the size of a full RP drive is 170,544 blocks
and internally the system is only capable of addressing 65,536
blocks. Also since the disk is so large, this allows it to be
broken up into more managable pieces.
I don't understand why these particular sizes were chosen, though,
because they don't seem to add up in any sensible way without wasting
space or overlapping.
> Why the sizes of the various fs?
The original reason for root to be small and /usr to be large was, I
believe, so that the most commonly-used files could be kept on a small,
fast, and expensive, head-per-track disk, while the less-frequently used
files would be on the larger, slower, but cheaper conventional disk,
and the division was maintained even when systems put both file systems
on the same disk. As for the exact sizes chosen, I don't know.
eric
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id EAA24641
for pups-liszt; Wed, 2 Sep 1998 04:21:24 +1000 (EST)
>From "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Wed Sep 2 04:16:04 1998
Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id EAA24636
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 04:21:18 +1000 (EST)
Received: (from rdkeys@localhost)
by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id OAA15796;
Tue, 1 Sep 1998 14:16:06 -0400 (EDT)
(envelope-from rdkeys)
From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Message-Id: <199809011816.OAA15796(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions
In-Reply-To: <199809011719.MAA15499(a)fudge.uchicago.edu> from Eric Fischer at "Sep 1, 98 12:19:07 pm"
To: eric(a)fudge.uchicago.edu (Eric Fischer)
Date: Tue, 1 Sep 1998 14:16:04 -0400 (EDT)
Cc: rdkeys(a)seedlab1.cropsci.ncsu.edu (User RDKEYS Robert D. Keys),
pups(a)minnie.cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Thanks Eric.... that sort of discussion makes my day, and feeds my
woefully short history folder, nicely! Does anything in print cover
this sort of thing in one place?
So much to learn....
Bob Keys
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id FAA24730
for pups-liszt; Wed, 2 Sep 1998 05:02:01 +1000 (EST)
>From "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Wed Sep 2 04:56:49 1998
Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id FAA24725
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 05:01:55 +1000 (EST)
Received: (from rdkeys@localhost)
by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id OAA15872;
Tue, 1 Sep 1998 14:56:51 -0400 (EDT)
(envelope-from rdkeys)
From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Message-Id: <199809011856.OAA15872(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <199809011719.MAA15499(a)fudge.uchicago.edu> from Eric Fischer at "Sep 1, 98 12:19:07 pm"
To: eric(a)fudge.uchicago.edu (Eric Fischer)
Date: Tue, 1 Sep 1998 14:56:49 -0400 (EDT)
Cc: pups(a)minnie.cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> > From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
> > Why the differences between 4.3 and 4.4 as relates to var?
>
> I believe /var originated in SunOS at a time when Sun was heavily
> promoting network-mounted file systems. In order to allow /usr to be
> mounted read-only across the network from a shared server, it was
> necessary to move all the files that would need to be modified by a
> running system from their traditional locations in /usr onto a file
> system that would be writable (and probably not shared with other
> systems). The rearrangement was then widely copied by other systems,
> including 4.4BSD.
OK. Now it is beginning to make sense.
IF one is putting together a small system, where things like remote mounting
or large numbers of users are NOT going to be present, are there any sorts
of particular reasons to even have a /var fs? For example, on my FBSD
boxes (yeah, I know new stuff and not Ancient Unixes, but I have to run
it at the office --- at home is another story), I find that I use var
mostly for temp stuff, spooling prints and mail, and little else.
The ftp user is off on another fs with regular users, where space is
not critical (since my ftp archives can vary widely, across time) and
I don't want to take up a lot of space with a mostly empty var.
That leads to the question of whether or not it is workable to put
var as a tree within the root fs? And, then, what did the earlier
systems like 32V or V7 use as the mail or print spooling areas?
I don't have much info on the earlier systems, except for bits and
pieces that I have run across. Sadly, our library here at MOO U,
has little from earlier days. Is any of this around on-line?
> > Why the convention of hd0a/b/c/d/e/f/g/h for the various fs? I understand
> > the reasoning of a/b/c, but after that the rhyme and reason goes wild,
> > with everyone seemingly doing their own thing. What was the logic of it,
> > originally?
>
> It looks like this one really originated with the Seventh Edition,
> where "hp" disks were permanently partitioned as follows:
>
> partition start length
> 0 0 23 -> a
> 1 23 21 -> b
> 2 0 0 -> c
> 3 0 0 -> d
> 4 44 386 -> e
> 5 430 385 -> f
> 6 44 367 -> g
> 7 44 771 -> h
>
> (the start and length are in cylinders of 418 blocks apiece)
Does this imply that the permanent partitions were pdp-hardware related,
or due to limitations in fs addressing schemes due to processor or
code design limits?
> A generic installation, according to the manual, would put root on
> partition 0, swap on partition 1, and /usr on partition 4 or 7.
> Partitions 2 or 3 could be used to access an entire disk.
Is the 2 and 3 partition ever used, or was that just something
that came along for the ride with the hardware, and not used by
unix?
> Clearly if partition 4 was used for /usr then partition 5 could be used
> for something else, while if 7 was used it would take up the entire
> rest of the disk. I'm not sure what the motivation was for the size of
> partition 6, even though partition g now seems to be the standard one
> for /usr, but presumably the space between cylinders 411 and 430 could
> be put to use somehow.
>
> The Sixth Edition also had fixed-size partitions, but of different
> sizes than the Seventh Edition used:
>
> partition start length
> 0 0 9614 -> a
> 1 18392 65535 -> b
> 2 48018 65535 -> c
> 3 149644 20900 -> d
> 4 0 40600 -> e
> 5 41800 40600 -> f
> 6 83600 40600 -> g
> 7 125400 40600 -> h
>
> (these numbers are in blocks, not cylinders). The manual explains
> the motivation for partitioning:
>
> This is done since the size of a full RP drive is 170,544 blocks
> and internally the system is only capable of addressing 65,536
> blocks. Also since the disk is so large, this allows it to be
> broken up into more managable pieces.
OK, now it is beginning to make some sense. It would seem to be due
to addressing limits in the machine (drive? processor? code?).
It is interesting that here it seems that partitions 1 and 2 were
co-addressed, or overlapping, while 4/5/6/7 were sequentially laid
out across the disk, perhaps. It would seem that 4/5/6/7 were just
simple divisions of the disk into 4 pieces. Was something like this
done to accommodate whether the drive was used a a boot drive or
a secondary drive?
> I don't understand why these particular sizes were chosen, though,
> because they don't seem to add up in any sensible way without wasting
> space or overlapping.
>
> > Why the sizes of the various fs?
>
> The original reason for root to be small and /usr to be large was, I
> believe, so that the most commonly-used files could be kept on a small,
> fast, and expensive, head-per-track disk, while the less-frequently used
> files would be on the larger, slower, but cheaper conventional disk,
> and the division was maintained even when systems put both file systems
> on the same disk. As for the exact sizes chosen, I don't know.
Interesting. What sizes, relatively, were such drives from that era
of the high-speed type, and by what manufacture?
> eric
Again... Thanks!
Bob Keys
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id FAA24871
for pups-liszt; Wed, 2 Sep 1998 05:46:21 +1000 (EST)
>From Eric Fischer <eric(a)fudge.uchicago.edu> Wed Sep 2 05:45:53 1998
Received: from fudge.uchicago.edu (fudge.uchicago.edu [128.135.136.68])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id FAA24866
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 05:46:14 +1000 (EST)
Received: (from eric@localhost) by fudge.uchicago.edu (8.7.5/8.7.3) id OAA16702; Tue, 1 Sep 1998 14:45:53 -0500 (CDT)
Date: Tue, 1 Sep 1998 14:45:53 -0500 (CDT)
Message-Id: <199809011945.OAA16702(a)fudge.uchicago.edu>
From: Eric Fischer <eric(a)fudge.uchicago.edu>
To: rdkeys(a)seedlab1.cropsci.ncsu.edu
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <199809011856.OAA15872(a)seedlab1.cropsci.ncsu.edu>
References: <199809011856.OAA15872(a)seedlab1.cropsci.ncsu.edu>
Organization: The University of Chicago
Cc: pups(a)minnie.cs.adfa.oz.au
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
[snip]
> IF one is putting together a small system, where things like remote mounting
> or large numbers of users are NOT going to be present, are there any sorts
> of particular reasons to even have a /var fs?
There's no urgent need for it if you don't mind having it as part of
root or /usr. On some systems it's nice to have /var on a separate
partition so that large mail spools or log files that fill up the /var
partition won't also break root or /usr, but this works both ways,
because if you had allowed it to be part of a larger partition it might
not have filled up in the first place.
> That leads to the question of whether or not it is workable to put
> var as a tree within the root fs?
Lots of systems set it up as just a regular directory within the
root directory. Others (like SGIs) make it really be /usr/var
and put a symlink from /var to there.
> And, then, what did the earlier systems like 32V or V7 use as the
> mail or print spooling areas?
V7 mail keeps files in /usr/spool/mail; earlier systems did not have an
equivalent directory and delivered mail files directly to users' home
directories. UUCP in v7 spooled files to /usr/spool/uucp. The v6
manual (in the manpage for opr) refers to printer spool directories
/lib/dpr, /lib/lpr, and /lib/npr; the lpd manpage also lists /usr/lpd.
> I don't have much info on the earlier systems, except for bits and
> pieces that I have run across. Sadly, our library here at MOO U,
> has little from earlier days. Is any of this around on-line?
The v1 manual (as TIFF-format scans and OCRed PostScript), as well as
much other historical material, is available from Dennis Ritchie's web
page,
http://plan9.bell-labs.com/who/dmr/
The v7 manual is also at the same site but in
http://plan9.bell-labs.com/7thEdMan/
The v6 manual can be extracted from the binary v6 distribution that you
can run on a PDP-11 emulator, though troff changed a bit between v6 and
v7 so you have to work a bit to get it to format with a modern ditroff.
> Does this imply that the permanent partitions were pdp-hardware related,
> or due to limitations in fs addressing schemes due to processor or
> code design limits?
I think they were specifically there for convenience. The smaller
disks that were also supported did not all have partitions.
> Is the 2 and 3 partition ever used, or was that just something
> that came along for the ride with the hardware, and not used by
> unix?
I imagine it would be used if you devoted an entire disk to a single
file system, or as a way of copying the entire contents of the disk
regardless of the partitioning to another device for backup.
> OK, now it is beginning to make some sense. It would seem to be due
> to addressing limits in the machine (drive? processor? code?).
The v6 C compiler does not have long integers and the PDP-11 is a 16-bit
machine, so that's why everything was limited to 65536 blocks. If you
want *real* weirdness, check out the v1 manual, in which the seek call
had not yet been made to deal with anything over 65536 *bytes*, so seeking
on disks worked very strangely.
> Interesting. What sizes, relatively, were such drives from that era
> of the high-speed type, and by what manufacture?
If I'm reading the First Edition manual right, the fixed-head disk was
the DEC RF11, with 1024 256-byte blocks -- yes, 256K bytes for the
entire hard disk. Dennis Ritchie's paper "The Evolution of the Unix
Time-sharing System" refers to a 512K disk, though, so I don't know
which to believe.
eric
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA24981
for pups-liszt; Wed, 2 Sep 1998 06:29:54 +1000 (EST)
>From Pat Barron <pat(a)transarc.com> Wed Sep 2 06:28:24 1998
Received: from mailhost2.transarc.com (mailhost2.transarc.com [158.98.14.14])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id GAA24976
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 2 Sep 1998 06:29:48 +1000 (EST)
Received: from smithfield.transarc.com (smithfield.transarc.com [158.98.16.10]) by mailhost2.transarc.com (8.8.0/8.8.0) with SMTP id QAA01769; Tue, 1 Sep 1998 16:28:26 -0400 (EDT)
Date: Tue, 1 Sep 1998 16:28:24 -0400 (EDT)
From: Pat Barron <pat(a)transarc.com>
Reply-To: Pat Barron <pat(a)transarc.com>
To: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
cc: pups(a)minnie.cs.adfa.oz.au
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <199809011856.OAA15872(a)seedlab1.cropsci.ncsu.edu>
Message-ID: <Pine.GSO.3.96.980901155532.16237I-100000(a)smithfield.transarc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
On Tue, 1 Sep 1998, User Rdkeys Robert D. Keys wrote:
> IF one is putting together a small system, where things like remote mounting
> or large numbers of users are NOT going to be present, are there any sorts
> of particular reasons to even have a /var fs?
Sure, as long as you make the root filesystem large enough, you can just
have /var be part of the root filesystem (or do like small SunOS/Slowaris
systems do, and have /var be a symbolic link to /usr/var - reasonably
safe, since SunOS and Slowaris both tend to assume that /usr is always
mounted).
> [...] And, then, what did the earlier
> systems like 32V or V7 use as the mail or print spooling areas?
Mail is dropped into /usr/spool/mail, or /usr/mail, depending on what
system you're talking about. Don't remember where printing went (I
actually don't remember if V7 even had a print-spooling system; I did a
lot of printing by doing "pr filename > /dev/lp"....
> Does this imply that the permanent partitions were pdp-hardware related,
> or due to limitations in fs addressing schemes due to processor or
> code design limits?
The partition sizes were compiled into the driver, not stored in a disk
label such as with more modern Unixes (and that was actually the case
until fairly recently - I don't think that disk labels made it into the
Berkeley code until at least the 4.3BSD-Tahoe release). If you wanted to
change a partition boundary, you had to edit some constants in the driver
and recompile your kernel (or do what I used to do a lot - use "adb -w"
to change the driver tables on-the-fly, and then try to remember to make
the same changes to the source code so you didn't get a surprise next time
you rebuilt the kernel.....).
> > This is done since the size of a full RP drive is 170,544 blocks
> > and internally the system is only capable of addressing 65,536
> > blocks. Also since the disk is so large, this allows it to be
> > broken up into more managable pieces.
>
> OK, now it is beginning to make some sense. It would seem to be due
> to addressing limits in the machine (drive? processor? code?).
This was a filesystem limitation; the filesystem code could not handle
more than 64K blocks in a filesystem, probably because it was using 16 bit
unsigned integers internally.
--Pat.
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA02145
for pups-liszt; Thu, 3 Sep 1998 06:45:08 +1000 (EST)
>From Tom Ivar Helbekkmo <tih(a)Hamartun.Priv.NO> Thu Sep 3 06:14:56 1998
Received: from hesiod.nhh.no (root(a)hesiod.nhh.no [158.37.96.15])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id GAA02122
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 3 Sep 1998 06:44:57 +1000 (EST)
Received: from athene.nhh.no (root(a)athene.nhh.no [158.37.96.16])
by hesiod.nhh.no (8.8.8/8.8.5) with ESMTP id WAA21643;
Wed, 2 Sep 1998 22:43:36 +0200 (CEST)
Received: from Hamartun.Priv.NO (Uhamartu@localhost)
by athene.nhh.no (8.8.8/8.8.8) with UUCP id WAA04031;
Wed, 2 Sep 1998 22:20:17 +0200 (CEST)
Received: (from tih@localhost)
by barsoom.Hamartun.Priv.NO (8.8.8/8.8.8) id WAA14724;
Wed, 2 Sep 1998 22:14:58 +0200 (CEST)
To: Eric Fischer <eric(a)fudge.uchicago.edu>
Cc: rdkeys(a)seedlab1.cropsci.ncsu.edu, pups(a)minnie.cs.adfa.oz.au
Subject: Re: Looking for rationale of fs naming conventions (more????)
References: <199809011856.OAA15872(a)seedlab1.cropsci.ncsu.edu> <199809011945.OAA16702(a)fudge.uchicago.edu>
From: Tom Ivar Helbekkmo <tih(a)Hamartun.Priv.NO>
Date: 02 Sep 1998 22:14:56 +0200
In-Reply-To: Eric Fischer's message of "Tue, 1 Sep 1998 14:45:53 -0500 (CDT)"
Message-ID: <8690k2z2yn.fsf(a)barsoom.Hamartun.Priv.NO>
X-Mailer: Gnus v5.6.4/Emacs 19.34
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Eric Fischer <eric(a)fudge.uchicago.edu> writes:
> There's no urgent need for it if you don't mind having it as part of
> root or /usr. On some systems it's nice to have /var on a separate
> partition so that large mail spools or log files that fill up the
> /var partition won't also break root or /usr, [...]
Another good reason to keep /var (and, for that matter, /tmp) off the
root partition is to keep that file system mostly quiescent. You
really don't want more writing activity than is absolutely necessary
on the file system you have to have intact to even get to single user
to run 'fsck', 'restore' and friends.
On some systems, having the root file system mounted read-only during
normal operation would be a nice security improvement.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA05528
for pups-liszt; Fri, 4 Sep 1998 06:46:06 +1000 (EST)
>From Johnny Billquist <bqt(a)Update.UU.SE> Fri Sep 4 06:45:37 1998
Received: from Zeke.Update.UU.SE (2026(a)Zeke.Update.UU.SE [130.238.11.14])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id GAA05520
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 4 Sep 1998 06:45:57 +1000 (EST)
Received: from localhost (bqt@localhost)
by Zeke.Update.UU.SE (8.8.8/8.8.8) with SMTP id WAA29001;
Thu, 3 Sep 1998 22:45:39 +0200
Date: Thu, 3 Sep 1998 22:45:37 +0200 (MET DST)
From: Johnny Billquist <bqt(a)Update.UU.SE>
To: Eric Fischer <eric(a)fudge.uchicago.edu>
cc: rdkeys(a)seedlab1.cropsci.ncsu.edu, pups(a)minnie.cs.adfa.oz.au
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <199809011945.OAA16702(a)fudge.uchicago.edu>
Message-ID: <Pine.VUL.3.93.980903224315.28685A-100000(a)Zeke.Update.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
On Tue, 1 Sep 1998, Eric Fischer wrote:
> > Interesting. What sizes, relatively, were such drives from that era
> > of the high-speed type, and by what manufacture?
>
> If I'm reading the First Edition manual right, the fixed-head disk was
> the DEC RF11, with 1024 256-byte blocks -- yes, 256K bytes for the
> entire hard disk. Dennis Ritchie's paper "The Evolution of the Unix
> Time-sharing System" refers to a 512K disk, though, so I don't know
> which to believe.
Are you sure that was 256-byte blocks? DEC usually talked about words when
it came to the pdp-11, and one word is 2 bytes, meaning the block is 512
bytes. Almost all DEC disks have 512 byte blocks on the pdp-11. Anybody
know any exceptions? (Is the RF-11? That disk is before my time...)
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id HAA05772
for pups-liszt; Fri, 4 Sep 1998 07:50:42 +1000 (EST)
>From Eric Fischer <eric(a)fudge.uchicago.edu> Fri Sep 4 07:50:11 1998
Received: from fudge.uchicago.edu (fudge.uchicago.edu [128.135.136.68])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id HAA05767
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 4 Sep 1998 07:50:35 +1000 (EST)
Received: (from eric@localhost) by fudge.uchicago.edu (8.7.5/8.7.3) id QAA09714; Thu, 3 Sep 1998 16:50:11 -0500 (CDT)
Date: Thu, 3 Sep 1998 16:50:11 -0500 (CDT)
Message-Id: <199809032150.QAA09714(a)fudge.uchicago.edu>
From: Eric Fischer <eric(a)fudge.uchicago.edu>
To: bqt(a)Update.UU.SE
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <Pine.VUL.3.93.980903224315.28685A-100000(a)Zeke.Update.UU.SE>
References: <Pine.VUL.3.93.980903224315.28685A-100000(a)Zeke.Update.UU.SE>
Organization: The University of Chicago
Cc: pups(a)minnie.cs.adfa.oz.au
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> From: Johnny Billquist <bqt(a)Update.UU.SE>
> Are you sure that was 256-byte blocks? DEC usually talked about words when
> it came to the pdp-11, and one word is 2 bytes, meaning the block is 512
> bytes. Almost all DEC disks have 512 byte blocks on the pdp-11. Anybody
> know any exceptions? (Is the RF-11? That disk is before my time...)
Oh! You're right -- I looked at the line in the manual that says
The disk contains 1024 256-word blocks, numbered 0 to 1023 ...
and misread 256-word as 256-byte because it was such a strange concept
that Unix would ever be doing word-oriented I/O. That makes a lot
more sense.
eric
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id LAA06405
for pups-liszt; Fri, 4 Sep 1998 11:01:49 +1000 (EST)
>From Kirk McKusick <mckusick(a)mckusick.com> Fri Sep 4 10:25:15 1998
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id LAA06400
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 4 Sep 1998 11:01:43 +1000 (EST)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id RAA11780;
Thu, 3 Sep 1998 17:25:16 -0700 (PDT)
Message-Id: <199809040025.RAA11780(a)flamingo.McKusick.COM>
To: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions
cc: eric(a)fudge.uchicago.edu (Eric Fischer), pups(a)minnie.cs.adfa.oz.au
In-reply-to: Your message of "Tue, 01 Sep 1998 14:16:04 EDT."
<199809011816.OAA15796(a)seedlab1.cropsci.ncsu.edu>
Date: Thu, 03 Sep 1998 17:25:15 -0700
From: Kirk McKusick <mckusick(a)mckusick.com>
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions
In-Reply-To: <199809011719.MAA15499(a)fudge.uchicago.edu>
from Eric Fischer at "Sep 1, 98 12:19:07 pm"
To: eric(a)fudge.uchicago.edu (Eric Fischer)
Date: Tue, 1 Sep 1998 14:16:04 -0400 (EDT)
Cc: rdkeys(a)seedlab1.cropsci.ncsu.edu (User RDKEYS Robert D. Keys),
pups(a)minnie.cs.adfa.oz.au
Thanks Eric.... that sort of discussion makes my day, and feeds my
woefully short history folder, nicely! Does anything in print cover
this sort of thing in one place?
So much to learn....
Bob Keys
The `diskpart' utility was used in 4.4BSD to organize disk partitions.
Its manual page tries to rationalize the use of partitions. I enclose
it below in case you do not have access to it.
Kirk McKusick
=-=-=-=-=-=-=-=-=-=-=
DISKPART(8) BSD System Manager's Manual DISKPART(8)
NAME
diskpart - calculate default disk partition sizes
SYNOPSIS
diskpart [-p] [-d] [-s size] disk-type
DESCRIPTION
Diskpart is used to calculate the disk partition sizes based on the de-
fault rules used at Berkeley.
Available options and operands:
-p Tables suitable for inclusion in a device driver are pro-
duced.
-d An entry suitable for inclusion in the disk description file
/etc/disktab is generated; for example, disktab(5).
-s size The size of the disk may be limited to size with the -s op-
tion.
On disks that use bad144(8) type of bad-sector forwarding, space is nor-
mally left in the last partition on the disk for a bad sector forwarding
table, although this space is not reflected in the tables produced. The
space reserved is one track for the replicated copies of the table and
sufficient tracks to hold a pool of 126 sectors to which bad sectors are
mapped. For more information, see bad144(8). The -s option is intended
for other controllers which reserve some space at the end of the disk for
bad-sector replacements or other control areas, even if not a multiple of
cylinders.
The disk partition sizes are based on the total amount of space on the
disk as given in the table below (all values are supplied in units of
sectors). The `c' partition is, by convention, used to access the entire
physical disk. The device driver tables include the space reserved for
the bad sector forwarding table in the `c' partition; those used in the
disktab and default formats exclude reserved tracks. In normal opera-
tion, either the `g' partition is used, or the `d', `e', and `f' parti-
tions are used. The `g' and `f' partitions are variable-sized, occupying
whatever space remains after allocation of the fixed sized partitions.
If the disk is smaller than 20 Megabytes, then diskpart aborts with the
message ``disk too small, calculate by hand''.
Partition 20-60 MB 61-205 MB 206-355 MB 356+ MB
a 15884 15884 15884 15884
b 10032 33440 33440 66880
d 15884 15884 15884 15884
e unused 55936 55936 307200
h unused unused 291346 291346
If an unknown disk type is specified, diskpart will prompt for the re-
quired disk geometry information.
SEE ALSO
disktab(5), bad144(8)
BUGS
Most default partition sizes are based on historical artifacts (like the
RP06), and may result in unsatisfactory layouts.
When using the -d flag, alternate disk names are not included in the out-
put.
HISTORY
The diskpart command appeared in 4.2BSD.
4th Berkeley Distribution June 6, 1993 2
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id LAA06477
for pups-liszt; Fri, 4 Sep 1998 11:18:48 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Sep 4 11:19:01 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id LAA06472
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 4 Sep 1998 11:18:44 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id LAA04168 for pups(a)minnie.cs.adfa.oz.au; Fri, 4 Sep 1998 11:19:01 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199809040119.LAA04168(a)henry.cs.adfa.oz.au>
Subject: Re: Looking for rationale of fs naming conventions
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Fri, 4 Sep 1998 11:19:01 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> Thanks Eric.... that sort of discussion makes my day, and feeds my
> woefully short history folder, nicely! Does anything in print cover
> this sort of thing in one place?
>
> Bob Keys
As with much of early Unix, you have to Use the Source, Luke. Small disks
like the RK05s and RL02 were not typically partitioned, except to put a
swap space at one end. However, bigger disks like the RP04s were. In V6
and V7, this was done by the device driver, and the device minor number
represented the particular partition, e.g from v6 hp.c
struct {
char *nblocks;
int cyloff;
} hp_sizes[] {
9614, 0, /* cyl 0 thru 23 */
/* cyl 24 thru 43 available */
-1, 44, /* cyl 44 thru 200 */
-1, 201, /* cyl 201 thru 357 */
20900, 358, /* cyl 358 thru 407 */
/* cyl 408 thru 410 blank */
40600, 0,
40600, 100,
40600, 200,
40600, 300,
};
. . .
hpstrategy(abp)
struct buf *abp;
{
register struct buf *bp;
register char *p1, *p2;
bp = abp;
p1 = &hp_sizes[bp->b_dev.d_minor&07];
Here, each of the 8 minor device numbers selected a different set of
cylinders on the disk, and note also that some of the sets overlapped.
The V6 manual on hp(4) says:
Since the disk is so large, this allows it to be broken
up into more manageable pieces. The origin and size of the
pseudo-disks on each drive are as follows:
disk start length
0 0 9614
1 18392 65535
2 48018 65535
3 149644 20900
4 0 40600
5 41800 40600
6 83600 40600
7 125400 40600
It is unwise for all of these files to be present in one
installation, since there is overlap in addresses and
protection becomes a sticky matter.
Early versions of BSD followed this compile-time partition selection.
I'm note sure when disklabels appeared, perhaps in 4.2BSD. Kirk or
Steven might be able to tell us.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id EAA19059
for pups-liszt; Tue, 8 Sep 1998 04:16:01 +1000 (EST)
>From "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Tue Sep 8 04:10:42 1998
Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id EAA19054
for <pups(a)minnie.cs.adfa.oz.au>; Tue, 8 Sep 1998 04:15:54 +1000 (EST)
Received: (from rdkeys@localhost)
by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id OAA29122;
Mon, 7 Sep 1998 14:10:45 -0400 (EDT)
(envelope-from rdkeys)
From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Message-Id: <199809071810.OAA29122(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions
In-Reply-To: <199809040025.RAA11780(a)flamingo.McKusick.COM> from Kirk McKusick at "Sep 3, 98 05:25:15 pm"
To: mckusick(a)mckusick.com (Kirk McKusick)
Date: Mon, 7 Sep 1998 14:10:42 -0400 (EDT)
Cc: pups(a)minnie.cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
> The `diskpart' utility was used in 4.4BSD to organize disk partitions.
> Its manual page tries to rationalize the use of partitions. I enclose
> it below in case you do not have access to it.
>
> Kirk McKusick
Thanks!
A couple of more questions, so I get the entire picture.....since you
were there.... as the old TV show went.....
> In normal opera-
> tion, either the `g' partition is used, or the `d', `e', and `f' parti-
> tions are used. The `g' and `f' partitions are variable-sized, occupying
> whatever space remains after allocation of the fixed sized partitions.
What are d,e, and f partititions typically used for or originally designed
for, as opposed to g? I see some of the historical carryovers in how they
were arrived at, but I sense there was probably some reasoning or design
advantages one way over another, back in time, or else there would not
have been the distinctions.
> Partition 20-60 MB 61-205 MB 206-355 MB 356+ MB
> a 15884 15884 15884 15884
> b 10032 33440 33440 66880
> d 15884 15884 15884 15884
d is a small partition, so what would it have been designed to be used for?
It seems the same as root in size, so would it have been, for example, a
spare root copy?
> e unused 55936 55936 307200
e is variable in size, and the only use I have seen of it is for the /var fs,
so, what was e designed for, or typically used as?
> h unused unused 291346 291346
Likewise for h.
In my limited exposure, I have seen in 4.3BSD that g was typically used for
the /usr partition as the rest of the disk. On 4.4BSD, /var was hung on e
and g was the usr partition for the rest of the disk, on one setup, and on
another things were really confused and var was hung on h, with all different
kinds of other fs hung out here and there across the disks. The rationale
for it was, at best, confusing to the newbie.
Is it particularly important to worry about how it is laid out, or in the
Berkeley tradition, are there particular advantages or economies to laying
it out with d/e/f/ as opposed to just g? I see the fs loading table in
the 4.4 install guide, but was wondering if there was more to it than that.
> BUGS
> Most default partition sizes are based on historical artifacts (like the
> RP06), and may result in unsatisfactory layouts.
This is what I am seeing, it would appear.
Maybe the advantages of earlier layouts vs disks are becoming lost with the
modern megadisks, in many instances. Also, I tend to see things from the
point of view of a single user workstation as opposed to a big multiuser
server of some kind. Thus, my frame of refernce is a little skewed.
Thanks
Bob Keys
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id LAA24382
for pups-liszt; Wed, 9 Sep 1998 11:27:21 +1000 (EST)
>From Kirk McKusick <mckusick(a)mckusick.com> Wed Sep 9 07:16:11 1998
Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.160])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id LAA24376
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 9 Sep 1998 11:27:15 +1000 (EST)
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by knecht.Sendmail.ORG (8.9.1/8.9.1) with ESMTP id SAA14038;
Tue, 8 Sep 1998 18:27:08 -0700 (PDT)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id OAA19252;
Tue, 8 Sep 1998 14:16:11 -0700 (PDT)
Message-Id: <199809082116.OAA19252(a)flamingo.McKusick.COM>
To: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu>
Subject: Re: Looking for rationale of fs naming conventions
cc: pups(a)minnie.cs.adfa.oz.au
In-reply-to: Your message of "Mon, 07 Sep 1998 14:10:42 EDT."
<199809071810.OAA29122(a)seedlab1.cropsci.ncsu.edu>
Date: Tue, 08 Sep 1998 14:16:11 -0700
From: Kirk McKusick <mckusick(a)mckusick.com>
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Most commonly, d was used for /tmp (before the days of
memory-based filesystems). The e partition was used for
/var, and f was used for /usr. The e partition was the
same size as the root filesystem so that it could be used
as a backup root filesystem.
Kirk McKusick
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id JAA03259
for pups-liszt; Fri, 11 Sep 1998 09:54:53 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Sep 11 09:54:51 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id JAA03253
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 11 Sep 1998 09:54:48 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA02038 for pups(a)minnie.cs.adfa.oz.au; Fri, 11 Sep 1998 09:54:51 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199809102354.JAA02038(a)henry.cs.adfa.oz.au>
Subject: CSRG CDs now available
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Fri, 11 Sep 1998 09:54:51 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
All,
Kirk McKusick is back from his 3-week trip and is now shipping
the 4CD set of BSD releases from the Computer Systems Research group.
It covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not
2.11BSD, unfortunately). As well, the last disk holds the final sources
plus the SCCS files.
Details at http://www.mckusick.com/csrg/
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id VAA12474
for pups-liszt; Sat, 19 Sep 1998 21:23:59 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Sat Sep 19 21:12:17 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id VAA12469
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 19 Sep 1998 21:23:55 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id VAA01670 for pups(a)minnie.cs.adfa.oz.au; Sat, 19 Sep 1998 21:24:03 +1000 (EST)
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id VAA12438
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 19 Sep 1998 21:12:10 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id VAA01633 for pups(a)minnie.cs.adfa.oz.au; Sat, 19 Sep 1998 21:12:17 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199809191112.VAA01633(a)henry.cs.adfa.oz.au>
Subject: Help Save 4BSD Boot Tapes!
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Sat, 19 Sep 1998 21:12:17 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Many kudos to Kirk McKusick for making the entire BSD releases from the
Computer Systems Research Group available on CD. However, many people are
going to buy the CD set so they can install 4.3BSD on their personal Vax.
Unfortunately, the 4CD set from Kirk does not contain any tape images
(bootable or otherwise) which would allow any of the 4BSDs to be installed.
Therefore, I'm asking anybody who might have old 4BSD tapes lying in a
corner, or knows someone who might have old 4BSD tapes (or has heard a
rumor about old 4BSD tapes etc.) to e-mail me with the details.
If we can unearth any old 4BSD tapes, then I am sure there will be
volunteers around who will be very happy to read the tapes, and I will
make space for them alongside the other files and tape images in the
PUPS archive.
While I'm here, I might as well say that I'm still looking for any old
PDP-11 versions of UNIX, or any applications written for early versions
of UNIX, or anything machine-readable which is generally related to
early versions of UNIX. Debbie Scherrer has just donated the Software Tools,
and both Dennis Ritchie and Norman Wilson are slowly scanning in their
paper copies of man pages for UNIX Editions 1 to 5.
Many thanks in advance for your help in preserving the history of Unix.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id EAA04014
for pups-liszt; Sat, 3 Oct 1998 04:14:38 +1000 (EST)
>From Brian D Chase <bdc(a)world.std.com> Sat Oct 3 04:14:22 1998
Received: from europe.std.com (europe.std.com [199.172.62.20])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id EAA04009
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 3 Oct 1998 04:14:31 +1000 (EST)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0)
id OAA14142; Fri, 2 Oct 1998 14:14:26 -0400 (EDT)
Received: from localhost by world.std.com (TheWorld/Spike-2.0)
id AA24749; Fri, 2 Oct 1998 11:14:22 -0700
Date: Fri, 2 Oct 1998 11:14:22 -0700 (PST)
From: Brian D Chase <bdc(a)world.std.com>
To: PDP Unix Preservation <pups(a)minnie.cs.adfa.oz.au>
Subject: Re: CSRG CDs now available
In-Reply-To: <199809102354.JAA02038(a)henry.cs.adfa.oz.au>
Message-Id: <Pine.SGI.3.95.981002111200.28977B-100000(a)world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
On Fri, 11 Sep 1998, Warren Toomey wrote:
> Kirk McKusick is back from his 3-week trip and is now shipping
> the 4CD set of BSD releases from the Computer Systems Research group.
> It covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not
> 2.11BSD, unfortunately). As well, the last disk holds the final sources
> plus the SCCS files.
>
> Details at http://www.mckusick.com/csrg/
FYI, these are a *really* nice set of CDs. I was completely amazed at how
professionally they'd been put together.
Any progress on the BSD binary images for VAX?
-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id IAA26021
for pups-liszt; Thu, 8 Oct 1998 08:54:33 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Thu Oct 8 08:55:04 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id IAA26016
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 8 Oct 1998 08:54:29 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id IAA22782 for pups(a)minnie.cs.adfa.oz.au; Thu, 8 Oct 1998 08:55:04 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199810072255.IAA22782(a)henry.cs.adfa.oz.au>
Subject: Found 4BSD tapes at last
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Thu, 8 Oct 1998 08:55:04 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
----- Forwarded message from Kirk McKusick -----
To: "J.S. Havard", Warren Toomey
Subject: Found at Last
My excavations on campus turned up six boxes of 9-track tapes
containing most of the BSD distributions. In particular, I have
found one labelled "4.3BSD Revision 2, Domestic Master" 6250bpi
3/4/87. There is also a similar tape (presumably revision 1) from
about six months earlier. I do not have access to a 9-track tape
drive, so I have no idea if the tape is even readable, but I am
willing to mail it to someone who does have a 6250bpi drive that
wants to take a crack at it.
~Kirk
----- End of forwarded message from Kirk McKusick -----
Would anybody near Kirk be prepared to read these tapes, gzip the
tape records, type in any tape labels glued to the reels, and send
the whole lot in to the PUPS archive?!
Many thanks in advance for the help.
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id AAA03040
for pups-liszt; Fri, 9 Oct 1998 00:37:56 +1000 (EST)
>From Rick Copeland <rickgc(a)calweb.com> Fri Oct 9 00:46:54 1998
Received: from mail.calweb.com (mail.calweb.com [208.131.56.12])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id AAA03035
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 9 Oct 1998 00:37:50 +1000 (EST)
Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id HAA10516;
Thu, 8 Oct 1998 07:37:34 -0700 (PDT)
X-SMTP: helo rgc from rickgc(a)calweb.com server @sac12-67.calweb.com ip 207.211.93.67 user=rickgc
Message-Id: <3.0.32.19981008074651.008fe690(a)pop.calweb.com>
X-Sender: rickgc(a)pop.calweb.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 08 Oct 1998 07:46:54 -0700
To: wkt(a)cs.adfa.oz.au, pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
From: Rick Copeland <rickgc(a)calweb.com>
Subject: Re: Found 4BSD tapes at last
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Where is Kirk located? If it is near California, I can do the work.
Rick Copeland
Information Systems Manager
InterMag, Inc.
At 08:55 AM 10/8/98 +1000, Warren Toomey wrote:
>----- Forwarded message from Kirk McKusick -----
>
>To: "J.S. Havard", Warren Toomey
>Subject: Found at Last
>
>My excavations on campus turned up six boxes of 9-track tapes
>containing most of the BSD distributions. In particular, I have
>found one labelled "4.3BSD Revision 2, Domestic Master" 6250bpi
>3/4/87. There is also a similar tape (presumably revision 1) from
>about six months earlier. I do not have access to a 9-track tape
>drive, so I have no idea if the tape is even readable, but I am
>willing to mail it to someone who does have a 6250bpi drive that
>wants to take a crack at it.
>
> ~Kirk
>
>----- End of forwarded message from Kirk McKusick -----
>
>Would anybody near Kirk be prepared to read these tapes, gzip the
>tape records, type in any tape labels glued to the reels, and send
>the whole lot in to the PUPS archive?!
>
>Many thanks in advance for the help.
>
>Cheers,
> Warren
>
>
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id BAA03308
for pups-liszt; Fri, 9 Oct 1998 01:54:18 +1000 (EST)
>From Rick Copeland <rickgc(a)calweb.com> Fri Oct 9 02:03:21 1998
Received: from mail.calweb.com (mail.calweb.com [208.131.56.12])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id BAA03303
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 9 Oct 1998 01:54:12 +1000 (EST)
Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id IAA02188;
Thu, 8 Oct 1998 08:54:01 -0700 (PDT)
X-SMTP: helo rgc from rickgc(a)calweb.com server @sac15-90.calweb.com ip 207.211.87.90 user=rickgc
Message-Id: <3.0.32.19981008090318.0090f520(a)pop.calweb.com>
X-Sender: rickgc(a)pop.calweb.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 08 Oct 1998 09:03:21 -0700
To: wkt(a)cs.adfa.oz.au, pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
From: Rick Copeland <rickgc(a)calweb.com>
Subject: Re: Found 4BSD tapes at last
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Warren,
Apparently Kirk is only 60 to 70 miles away from me, so shipping or pickup
on the week end is not a problem. Please contact Kirk and have him contact
me.
Rick Copeland
Information Systems Manager
InterMag, Inc.
(916) 568-6744 x36
At 08:55 AM 10/8/98 +1000, Warren Toomey wrote:
>----- Forwarded message from Kirk McKusick -----
>
>To: "J.S. Havard", Warren Toomey
>Subject: Found at Last
>
>My excavations on campus turned up six boxes of 9-track tapes
>containing most of the BSD distributions. In particular, I have
>found one labelled "4.3BSD Revision 2, Domestic Master" 6250bpi
>3/4/87. There is also a similar tape (presumably revision 1) from
>about six months earlier. I do not have access to a 9-track tape
>drive, so I have no idea if the tape is even readable, but I am
>willing to mail it to someone who does have a 6250bpi drive that
>wants to take a crack at it.
>
> ~Kirk
>
>----- End of forwarded message from Kirk McKusick -----
>
>Would anybody near Kirk be prepared to read these tapes, gzip the
>tape records, type in any tape labels glued to the reels, and send
>the whole lot in to the PUPS archive?!
>
>Many thanks in advance for the help.
>
>Cheers,
> Warren
>
>
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id CAA03360
for pups-liszt; Fri, 9 Oct 1998 02:15:10 +1000 (EST)
>From "J. Joseph Max Katz" <jkatz(a)cpio.net> Fri Oct 9 02:21:56 1998
Received: from corinne.cpio.org (corinne.cpio.org [209.218.145.10])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with SMTP id CAA03355
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 9 Oct 1998 02:15:05 +1000 (EST)
Received: (qmail 9126 invoked by uid 1000); 8 Oct 1998 16:21:56 -0000
Date: Thu, 8 Oct 1998 09:21:56 -0700 (PDT)
From: "J. Joseph Max Katz" <jkatz(a)cpio.net>
X-Sender: jkatz(a)corinne.cpio.org
To: Rick Copeland <rickgc(a)calweb.com>
cc: wkt(a)cs.adfa.oz.au, PDP Unix Preservation <pups(a)minnie.cs.adfa.oz.au>
Subject: Re: Found 4BSD tapes at last
In-Reply-To: <3.0.32.19981008090318.0090f520(a)pop.calweb.com>
Message-ID: <Pine.NEB.4.02.9810080921230.16361-100000(a)corinne.cpio.org>
X-Silly-Sender: Mr. Potatoe Head
Organization: CPIO Networks
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
We may have some equipment at my workplace we can use. We're in
San Jose, he's in Berkeley, 50-70 miles in the other direction. I
need to get clearence from the boss, first, though.
-Jon
Jonathan Katz, CEO CPIO Networks, Inc.
(408) 569-7092 [ ] jkatz(a)cpio.net
http://www.cpio.net [ ] "offering OpenBSD
technical support, on-site Unix and
network security services and training."
On Thu, 8 Oct 1998, Rick Copeland wrote:
:Date: Thu, 08 Oct 1998 09:03:21 -0700
:From: Rick Copeland <rickgc(a)calweb.com>
:To: wkt(a)cs.adfa.oz.au,
PDP Unix Preservation <pups(a)minnie.cs.adfa.oz.au>
:Subject: Re: Found 4BSD tapes at last
:
:Warren,
:
:Apparently Kirk is only 60 to 70 miles away from me, so shipping or pickup
:on the week end is not a problem. Please contact Kirk and have him contact
:me.
:
:Rick Copeland
:Information Systems Manager
:InterMag, Inc.
:(916) 568-6744 x36
:
:
:At 08:55 AM 10/8/98 +1000, Warren Toomey wrote:
:>----- Forwarded message from Kirk McKusick -----
:>
:>To: "J.S. Havard", Warren Toomey
:>Subject: Found at Last
:>
:>My excavations on campus turned up six boxes of 9-track tapes
:>containing most of the BSD distributions. In particular, I have
:>found one labelled "4.3BSD Revision 2, Domestic Master" 6250bpi
:>3/4/87. There is also a similar tape (presumably revision 1) from
:>about six months earlier. I do not have access to a 9-track tape
:>drive, so I have no idea if the tape is even readable, but I am
:>willing to mail it to someone who does have a 6250bpi drive that
:>wants to take a crack at it.
:>
:> ~Kirk
:>
:>----- End of forwarded message from Kirk McKusick -----
:>
:>Would anybody near Kirk be prepared to read these tapes, gzip the
:>tape records, type in any tape labels glued to the reels, and send
:>the whole lot in to the PUPS archive?!
:>
:>Many thanks in advance for the help.
:>
:>Cheers,
:> Warren
:>
:>
:
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id CAA03449
for pups-liszt; Fri, 9 Oct 1998 02:50:07 +1000 (EST)
>From Kirk McKusick <mckusick(a)mckusick.com> Fri Oct 9 02:34:48 1998
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id CAA03444
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 9 Oct 1998 02:50:02 +1000 (EST)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id JAA09797;
Thu, 8 Oct 1998 09:34:53 -0700 (PDT)
Message-Id: <199810081634.JAA09797(a)flamingo.McKusick.COM>
To: Rick Copeland <rickgc(a)calweb.com>
Subject: Re: Found 4BSD tapes at last
cc: wkt(a)cs.adfa.oz.au, pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
In-reply-to: Your message of "Thu, 08 Oct 1998 09:03:21 PDT."
<3.0.32.19981008090318.0090f520(a)pop.calweb.com>
Date: Thu, 08 Oct 1998 09:34:48 -0700
From: Kirk McKusick <mckusick(a)mckusick.com>
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Date: Thu, 08 Oct 1998 09:03:21 -0700
To: wkt(a)cs.adfa.oz.au, pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
From: Rick Copeland <rickgc(a)calweb.com>
Subject: Re: Found 4BSD tapes at last
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Warren,
Apparently Kirk is only 60 to 70 miles away from me, so
shipping or pickup on the week end is not a problem. Please
contact Kirk and have him contact me.
Rick Copeland
Information Systems Manager
InterMag, Inc.
(916) 568-6744 x36
Hi,
I am located at:
Kirk McKusick
1614 Oxford Street
Berkeley, CA 94709-1608
I could mail you the tape, but I would prefer to find a way to get it
to you that would minimize its being bounced around. Any ideas?
Kirk McKusick
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id IAA04624
for pups-liszt; Fri, 9 Oct 1998 08:42:10 +1000 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Oct 9 08:42:46 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) with ESMTP id IAA04619
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 9 Oct 1998 08:42:05 +1000 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id IAA24785 for pups(a)minnie.cs.adfa.oz.au; Fri, 9 Oct 1998 08:42:46 +1000 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199810082242.IAA24785(a)henry.cs.adfa.oz.au>
Subject: 4BSD tapes to be read
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Fri, 9 Oct 1998 08:42:46 +1000 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
All,
Rick Copeland has arranged to pick the 4BSD tapes up from Kirk
and read them this or next week. Thanks to all the people who volunteered,
and hopefully copies of the tapes will be in the archive soon.
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA00493
for pups-liszt; Thu, 12 Nov 1998 12:51:20 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Thu Nov 12 12:57:45 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id MAA00382
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 12 Nov 1998 12:43:07 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA04829 for pups(a)minnie.cs.adfa.oz.au; Thu, 12 Nov 1998 13:57:46 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811120257.NAA04829(a)henry.cs.adfa.oz.au>
Subject: Upgrade of PUPS List server
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Thu, 12 Nov 1998 13:57:45 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
All, I have just upgraded the server where the PUPS mailing list resides, to
a newer operating system version. This email is just to test that the
MajorDomo software is still working.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04919
for pups-liszt; Thu, 12 Nov 1998 14:28:57 +1100 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
