TUHS

tuhs@tuhs.org

43 participants
6501 discussions

by mxs46＠k2.scl.cwru.edu

Steven M. Schultz <sms(a)moe.2bsd.com> writes: > GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good > thing" ;) It's _ALWAYS_ a good thing, because it's DIVINE (written by Bell Labs Gods themselves), while gcc and others are mere mortals. Actually, gcc is even worse than a mere mortal, since it's GNU. It comes directly from the Inferno. 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 FAA04343 for pups-liszt; Tue, 24 Nov 1998 05:09:07 +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

26 years, 5 months

Re: 4.3/4.4 IBM distributions (need history)

by mxs46＠k2.scl.cwru.edu

"User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> writes: > I am curious, though, about the releases of BSD for the old RT. The University of California at Berkeley has never made any releases for IBM RT and nor will I, so there are no BSD releases for IBM RT. > There really is > a large bloat between the 4.3 and 4.4 levels in my stuff, too. What > is responsible for the differences in the bloat? I have heard jokes that CSRG got Microsoft to rewrite 90% of the code for them. Seriously, though, the bloat starts in Reno and really gets out of hand in 4.4. The sources are bloated just as much as the binaries, so I wouldn't blame it just on the compiler or the libraries. 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 FAA04299 for pups-liszt; Tue, 24 Nov 1998 05:06:39 +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 Pat Barron <pat(a)transarc.com> Tue Nov 24 04:05:13 1998 Received: from mailhost2.transarc.com (mailhost2.transarc.com [158.98.14.14]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id FAA04294 for <pups(a)MINNIE.CS.ADFA.EDU.AU>; Tue, 24 Nov 1998 05:06:23 +1100 (EST) (envelope-from pat(a)transarc.com) Received: from grant.transarc.com (grant.transarc.com [158.98.16.11]) by mailhost2.transarc.com (8.8.0/8.8.0) with SMTP id NAA05380; Mon, 23 Nov 1998 13:05:14 -0500 (EST) Date: Mon, 23 Nov 1998 13:05:13 -0500 (EST) From: Pat Barron <pat(a)transarc.com> To: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> cc: pups(a)MINNIE.CS.ADFA.EDU.AU Subject: Re: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811231709.MAA09886(a)seedlab1.cropsci.ncsu.edu> Message-ID: <Pine.GSO.3.96.981123125810.17938D-100000(a)grant.transarc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk I think there were some additional licensing restrictions on AOS (e.g., only available to educational institutions), so it might not be includable in the archive. I can probably track down folks in Palo Alto who worked AOS, and find out. As far as I know, there was never an "official" ACIS release beyond the 1988 4.3BSD release. I have actual distribution tapes around somewhere, and could probably make tape images available if it's determined that that's OK. --Pat. P.S. We just dumpster-ized about 6 or 8 RTs from our storage facility in the last couple of weeks - I had tried to give them away, but the person who was lined up to take them didn't move quite fast enough, and the person assigned to storage clean-up got tired of having them around ... :-( Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04329 for pups-liszt; Tue, 24 Nov 1998 05:08: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

26 years, 6 months

Reno (was Re: What *was* the Tahoe?)

by SHOPPA＠trailing-edge.com

>Tahoe was the internal "code" name that Computer Consoles Inc used >for their Power 6/32 processor. That's useful. The Tahoe-specific documentation also mentions the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were these in any way compatible with the Tahoe, or just "other" ports? And where does "Reno" come from, while we're at it? Tim. (shoppa(a)trailing-edge.com) Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04103 for pups-liszt; Tue, 24 Nov 1998 04:15:51 +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 "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Tue Nov 24 03:09:28 1998 Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id EAA04098 for <pups(a)MINNIE.CS.ADFA.EDU.AU>; Tue, 24 Nov 1998 04:15:43 +1100 (EST) (envelope-from rdkeys(a)seedlab1.cropsci.ncsu.edu) Received: (from rdkeys@localhost) by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id MAA09886; Mon, 23 Nov 1998 12:09:28 -0500 (EST) (envelope-from rdkeys) From: "User Rdkeys Robert D. Keys" <rdkeys(a)seedlab1.cropsci.ncsu.edu> Message-Id: <199811231709.MAA09886(a)seedlab1.cropsci.ncsu.edu> Subject: Re: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811220509.AAA16197(a)skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 22, 98 00:09:52 am" To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 12:09:28 -0500 (EST) Cc: pups(a)MINNIE.CS.ADFA.EDU.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 > > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > > It's the most reasonable approach I can think of at the moment. > > That's close to what I'm doing. There are two differences, though. > First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > between Tahoe and Reno. The latter is really huge, it's a gap between True > UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be > building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus > KA650 support and shadow passwords from Reno and other improvements from > both later CSRG code and my own brain. SCCS will be the #1 tool in the > process. Speaking of crusades.....(:+}}.... I sometimes feel like the orphan child running BSD on the old IBM RT (I know, not a biggie vaxen iron, but that is what I have and the cap that I don). It is not too bad running 16M ram and a 20'' megapel color monitor, but the RISC processor is running around 12mhz on an ISA bus which is not very fast. I am curious, though, about the releases of BSD for the old RT. Few on the net know anything about them anymore, and docs are nil. I asked around IBM, and sort of drew dumb quizzled looks, as if it had vaporized long ago. I have uncovered three discrete distributions, one labelled IBM, and two non-labelled, but which were apparently out of IBM or related to IBM in some way, maybe after IBM dropped AOS, but I am not sure. The background of it all is a mystery. The first is a ``build 0'' thing called AOS or AOS/4.3, and it appears to be a somewhat vanilla 4.3BSD, or possibly might be as late as Tahoe. It has pcc and a Metaware C compiler, and is not very strange. Other than the compilers being somewhat broken and the time never correct, it runs well, and feels like 4.3. The second is a ``build 16'' and labelled Reno, but is running gcc and related things. My suspicion is that it is a 4.4, but I am not sure. It seems fairly plain and following the 4.4 docs pretty well. I don't think it is really Reno, but was named that by someone back in time for some developmental reason maybe having been started from a Reno tree, although I am not sure. The third is a ``build 433'' and labelled Lite, and seems to be somewhat straight 4.4 and somethat Lite (has two intermixed source trees), and is gigabyte in size, and rather strangely laid out. It may have been the last build for the RT. Unfortunately, original tapes and documents for these are long gone, and I have only been able to pick up bits and pieces here and there. I don't find mention of these ports anywhere in the usual docs, other than a slight hint that they existed at one time. Supposedly, bits are on a mystical CD that is reputed to exist, and I have heard of two actual CD's that may have survived. I have spent the last 6 months resurrecting the ports, and basically have a reliable 4.3 running, a running but somewhat broken ``Reno'' or whatever it is (of all things vi is only 99% operational because of terminal driver problems), and a broken but somewhat running ``4.4/4.4Lite'' or whatever that really is (it boots and barely stays up, but I have been working on making it stay up). Does anyone on the PUPS list remember what these things actually are, and what level they are actually at? My historical curiosity is getting the better of me, and like Michael, I tend to like the plain model-T spartan simplicity of a 4.3 style machine. There really is a large bloat between the 4.3 and 4.4 levels in my stuff, too. What is responsible for the differences in the bloat? I get binaries about half the size in 4.3 compared to the 4.4whatevers I have. Is that just a function of gcc and how it codes things or libraries? Anyway, it has been a most refreshing learning experience getting these things up and running again. Is there any interest on the list to archive the ports that I have? Warren? Out of curiosity, again, anyone else on the PUPS list running RT iron or am I the last holdout? The few RT folks that I am familiar with are all running AIX still, although they remember the BSDs. So much seems to have been lost, already, or most of the machines have become dumpster fodder. Any insights, history, or horror stories about the old RT BSD ports are most welcome. Thanks Bob Keys Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04175 for pups-liszt; Tue, 24 Nov 1998 04:35: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

26 years, 6 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Steven M. Schultz <sms(a)moe.2bsd.com> writes: > Reno came with GCC though. Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included in the Reno distribution _as a compressed tarball_, and it's used only for the experimental and unsupported hp300 port, and that's only because there is no pcc support for it. 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 NAA01241 for pups-liszt; Mon, 23 Nov 1998 13:40:15 +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 "Steven M. Schultz" <sms(a)moe.2bsd.com> Mon Nov 23 12:26:14 1998 Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id NAA01235 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 13:40:05 +1100 (EST) (envelope-from sms(a)moe.2bsd.com) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id SAA20820 for pups(a)minnie.cs.adfa.edu.au; Sun, 22 Nov 1998 18:26:14 -0800 (PST) Date: Sun, 22 Nov 1998 18:26:14 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811230226.SAA20820(a)moe.2bsd.com> To: pups(a)minnie.cs.adfa.edu.au Subject: Re: 4.3-VAX distributions Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk Hi - > From: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) > Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like > 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included Oops - I actually fired up the uVax-II (first time in almost 3 years) and typed 'gcc' and it told me 2.5.8 But as it turns out that was something I'd added later (with much work). GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good thing" ;) Steven Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02007 for pups-liszt; Mon, 23 Nov 1998 18:05:00 +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 Kirk McKusick <mckusick(a)mckusick.com> Mon Nov 23 16:05:13 1998 Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.160]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id SAA02001 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 18:04:51 +1100 (EST) (envelope-from mckusick(a)flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178]) by knecht.Sendmail.ORG (8.9.2.Alpha2/8.9.2.Alpha2) with ESMTP id XAA28300; Sun, 22 Nov 1998 23:04:48 -0800 (PST) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id WAA03948; Sun, 22 Nov 1998 22:05:14 -0800 (PST) Message-Id: <199811230605.WAA03948(a)flamingo.McKusick.COM> To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) Subject: Re: What *was* the Tahoe? cc: pups(a)minnie.cs.adfa.edu.au In-reply-to: Your message of "Sun, 22 Nov 1998 20:14:04 EST." <199811230114.UAA16563(a)skybridge.scl.cwru.edu> Date: Sun, 22 Nov 1998 22:05:13 -0800 From: Kirk McKusick <mckusick(a)mckusick.com> Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk Date: Sun, 22 Nov 1998 20:14:04 -0500 From: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) To: pups(a)minnie.cs.adfa.edu.au Subject: Re: What *was* the Tahoe? Sender: owner-pups(a)minnie.cs.adfa.oz.au Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Tahoe was the internal "code" name that Computer Consoles Inc used for their Power 6/32 processor. Many of their early changes to BSD were labelled: #ifdef tahoe to identify the 6/32 specific code. So, when we did the port we just called it Tahoe because its prime purpose was to add support for the CCI 6/32 machine. Kirk McKusick Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02069 for pups-liszt; Mon, 23 Nov 1998 18:19:19 +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 Dave Horsfall <dave(a)fgh.geac.com.au> Mon Nov 23 17:16:50 1998 Received: from caveman.geac.com.au (caveman.geac.com.au [203.30.73.2]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id SAA02064 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 18:19:11 +1100 (EST) (envelope-from dave(a)fgh.geac.com.au) Received: (qmail 4403 invoked from network); 23 Nov 1998 06:22:48 -0000 Received: from brane.geac.com.au (202.6.67.115) by caveman.geac.com.au with SMTP; 23 Nov 1998 06:22:48 -0000 Received: from fgh.geac.com.au by brane.geac.com.au with smtp\n (Smail3.1.29.1 #3) id m0zhqEJ-00002RC; Mon, 23 Nov 98 18:16 AEDT Received: from localhost (dave@localhost) by fgh.geac.com.au (SMI-8.X/SVR4) with ESMTP id SAA05724 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 18:16:50 +1100 Date: Mon, 23 Nov 1998 18:16:50 +1100 (EST) From: Dave Horsfall <dave(a)fgh.geac.com.au> X-Sender: dave@fgh cc: pups(a)minnie.cs.adfa.edu.au Subject: Re: What *was* the Tahoe? In-Reply-To: <199811230605.WAA03948(a)flamingo.McKusick.COM> Message-ID: <Pine.GSO.4.03.9811231813070.22354-100000@fgh> X-No-Archive: Yes X-Witty-Saying: "Tesseract - Enter at own risk" X-Disclaimer: "Me, speak for us?" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk On Sun, 22 Nov 1998, Kirk McKusick wrote: > Tahoe was the internal "code" name that Computer Consoles Inc used > for their Power 6/32 processor. Many of their early changes to BSD > were labelled: > #ifdef tahoe > to identify the 6/32 specific code. So, when we did the port we > just called it Tahoe because its prime purpose was to add support > for the CCI 6/32 machine. And, as I recall (I used to work for STC Australia who sold 'em) it had the instruction set of a Vax, but backwards, if you know what I mean... The CPU was five boards, something like integer card plus FPU card plus priority arbitrator card etc. -- Dave Horsfall VK2KFU dave(a)geac.com.au Ph: +61 2 9978-7493 Fx: +61 2 9978-7422 Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA03974 for pups-liszt; Tue, 24 Nov 1998 03:38:04 +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

26 years, 6 months

Re: What *was* the Tahoe?

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? 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 MAA01021 for pups-liszt; Mon, 23 Nov 1998 12:01:58 +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

26 years, 6 months

Re: booting 4.3-reno without a tape drive

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > For a quick work-around to make a bootable 4.3 miniroot without a > tape drive, Michael, you might consider the following (similar > tricks will work on NetBSD distributions too): > > Ingredients: > [...] > Some other operating system to write the disk from > (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, > RT-11 and any PDP-11 CPU, etc.) The last part is the problem. At this location I have only one DEC machine, and that's the KA650 I'm trying to get Ultrix on. The guy with the MV3400 (and the TK70/TQK70 pair inside it) is still out for the weekend, should hear something later this evening. If that falls through and no one helps me with a spare TQK50, I'll have to come up with another disk for this PC I'm typing this on, install FreeBSD on it, netboot NetBSD/vax, and use that to load Reno over the net onto another disk (the VAX has 5 of them). Much more painful, but still better than nothing. 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 KAA00612 for pups-liszt; Mon, 23 Nov 1998 10:30:19 +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

26 years, 6 months

Re: Minnie's new domain name

by mxs46＠k2.scl.cwru.edu

Warren Toomey <wkt(a)henry.cs.adfa.oz.au> writes: > Over the summer break [...] I was first thrown off by this (yesterday was officially the first snow day here in Cleveland), but then I remembered that Australia is in the southern hemisphere, so your summer is our winter, right? > I'll add some smarts to > minnie's web server and other services to remind people to make the > switch in their bookmarks, hotlinks etc. OK, will change the HostName line in my .ssh/config. I'm already using the new domain name when posting. > P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's > back now. I hate PC hardware. Then why do you use it? Why not run the PUPS/TUHS server on a VAX running 4.3BSD-Quasijarus (or 4.3BSD or 4.3BSD-Reno if you can't wait), or maybe a PDP-11 running 2.11BSD? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu P.S. Your Sendmail is still putting .oz.au in the outgoing mail headers. Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00720 for pups-liszt; Mon, 23 Nov 1998 10:40:08 +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 "Steven M. Schultz" <sms(a)moe.2bsd.com> Mon Nov 23 09:31:04 1998 Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA00713 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 10:40:00 +1100 (EST) (envelope-from sms(a)moe.2bsd.com) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id PAA18529 for pups(a)minnie.cs.adfa.edu.au; Sun, 22 Nov 1998 15:31:04 -0800 (PST) Date: Sun, 22 Nov 1998 15:31:04 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811222331.PAA18529(a)moe.2bsd.com> To: pups(a)minnie.cs.adfa.edu.au Subject: Re: 4.3-VAX distributions Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk Hi - > The lifting of the filesystem limits is in Tahoe, not in Reno. When you > talk about the speed of Reno's binaries, what are you comparing it to? I > know for sure that there are no significant changes in the C compiler > between plain 4.3, Tahoe, and Reno. UH, not quite so. Unless 4.3 and Tahoe used GCC (which they did not). I'd say that there is a big difference between the 4.3 C compiler (pcc or whatever it started out as) and GCC. Tahoe, while adding support for the CCI line of computers (tried to get folks to buy one but they wouldn't go for it) did NOT use GCC (which wasn't out yet or if it was had just started making an appearance). Reno came with GCC though. The older pre-Reno compilers (being straight K&R) didn't handle prototypes - that's what you had "lint" for. Steven Schultz sms(a)Moe.2bsd.com Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00729 for pups-liszt; Mon, 23 Nov 1998 10:41:02 +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

26 years, 6 months

Re: Minnie's new domain name

by norman＠nose.cita.utoronto.ca

Re Warren's postscript: P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Perhaps it's time to dig up an old PDP-11? Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00626 for pups-liszt; Mon, 23 Nov 1998 10:31:02 +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

26 years, 6 months

booting 4.3-reno without a tape drive

by SHOPPA＠trailing-edge.com

Michael Sokolov wrote: > 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. For a quick work-around to make a bootable 4.3 miniroot without a tape drive, Michael, you might consider the following (similar tricks will work on NetBSD distributions too): Ingredients: Microvax II Honest-to-goodness DEC disk or *fully* compatible 3rd-party disk. *Fully* compatible means that it must have the same MSCP media ID code and same number of tracks, sectors, and cylinders as a drive already hardwired into vaxuba/uda.c. These are the ones hardwired in: { MSCP_MKDRIVE2('R', 'A', 60), "ra60", ra60_sizes, 42, 4, 2382 }, { MSCP_MKDRIVE2('R', 'A', 70), "ra70", ra70_sizes, 33, 11, 1507 }, { MSCP_MKDRIVE2('R', 'A', 80), "ra80", ra80_sizes, 31, 14, 559 }, { MSCP_MKDRIVE2('R', 'A', 81), "ra81", ra81_sizes, 51, 14, 1248 }, { MSCP_MKDRIVE2('R', 'A', 82), "ra82", ra82_sizes, 57, 14, 1423 }, { MSCP_MKDRIVE2('R', 'C', 25), "rc25-removable", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE3('R', 'C', 'F', 25), "rc25-fixed", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE2('R', 'D', 52), "rd52", rd52_sizes, 18, 7, 480 }, { MSCP_MKDRIVE2('R', 'D', 53), "rd53", rd53_sizes, 18, 8, 963 }, { MSCP_MKDRIVE2('R', 'X', 50), "rx50", rx50_sizes, 10, 1, 80 }, Note that "rd54" is conspicuously missing, and I think the tabulated rd52/53 sizes are as appropriate on a RQDX2, *not* a RQDX3. Some other operating system to write the disk from (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, RT-11 and any PDP-11 CPU, etc.) The tape distribution of 43reno_vax from the PUPS archive. Specifically, you need these files: miniroot mdec/rdboot, from usr.tar mdec/bootra, from usr.tar etc/etc.tahoe/disktab, from src.tar Cooking directions: The miniroot wants to live in the swap ("b") partition of the drive. So your first task is to find the starting block number of the swap partition from the extracted "disktab". For example, for an RA81, the offset ("ob=") for an RA81 is 16422 blocks. So copy the miniroot onto the target drive starting at block 16422 (i.e. if you're under 2.11 BSD and you've partitioned the target drive, ra0, so that partition a covers the entire disk, do a "dd if=miniroot of=/dev/rra0a seek=16422 bs=512") In the "a" partition of the output drive you need a copy of "boot". The miniroot already has a filesystem with this in it, so the lazy thing to do is to just plop another copy of the miniroot, starting at block 0 on the output disk (i.e. "dd if=miniroot of=/dev/rra0a") You need the secondary bootstrap in blocks 1-15 of the target disk. Put this down with "dd if=bootra of=/dev/rra0a seek=1 bs=512" You need a block-0 boot block on the output disk. For a Microvax, this is rdboot. (I believe raboot is appropriate on a Unibus or BI-bus VAX). Lay this down with "dd if=rdboot of=/dev/rra0a" Now move the output disk to your Microvax II configuration, and boot: >>> b dua0/r5:1 2..1..0.. loading boot ra0: unlabeled Boot : ra(0,0,1)vmunix ra0: unlabeled 338756+108644+131004 start 0x238c 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 1998 PDT trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot REAL MEM=16773120 und so weiter. Now, one obvious improvement to this would be to lay down a fake 4.3-ish disk label at the start of the output disk as well. This way the reliance on a fully-geometry-compatible disk might be avoided. I'll work on this in my Copious Free Time (TM). -- 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 KAA00512 for pups-liszt; Mon, 23 Nov 1998 10:14:17 +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

26 years, 6 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Steven M. Schultz <sms(a)moe.2bsd.com> writes: > All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't > know there were any left :-) :-) I'm sure you know that domain names are case-insensitive. Also note that in the InterNIC records everything is all uppercase. As far as the mail user names go, they CAN be case-sensitive, but most OSes, even UNIX (Sendmail), try to be on the safe side and ignore the case in this context. > the base 4.3 system up to and including Tahoe couldn't be cold started > on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ > to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel > had uVax support in it but the boot stuff did not. > > With 4.3-Reno that changed but... As others have noticed the > cold start kit didn't create tapes suitable for a uVax. This change occurred in Tahoe, NOT in Reno. Trust me. If you don't, look at /usr/home/msokolov/43tahoe.cci/srcsys.tar.gz and see for yourself. > 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the > standalone programs still had compiled in partitions. The disk label support first appears in Tahoe. Again, if you don't believe me, look at /usr/home/msokolov/43tahoe.cci. > At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD [...] Ultrix v4.00, which I used to run on my main production VAX when my farm was on the net, has _ALL_ enhancements from 4.3BSD (including DNS and DBM passwd files) and most enhancements from Tahoe (including MX record support in Sendmail). Its disk label mechanism is rumored to be incompatible with Tahoe's, though (haven't had a chance to test this for myself). > [...] that DEC had corrupted > with System V(anilla) bolted on contamination. Here I agree wholeheartedly! But hey, just ignore all SysVile and DEC additions and pretend it's 4.3BSD! That's what I did. > 4.3-Reno was a transitional experiment that happened just as the CSRG > and DEC had a serious falling out - and DEC support (Vaxen) vanished > at that point. Any further work (4.4BSD) totally and completely > ignored all DEC machines. This pulled the thread that was holding everything together. Reno was the beginning of the destructive process that eventually and inevitably led to the disbanding of CSRG. Reno is the beginning of the end. One of the main reasons I don't do Reno. > Yep - you get NFS (which no 4BSD had prior to Reno). True. I will have to hack NFS into Quasijarus somehow at some point. This is not for Quasijarus1, though. 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 JAA00216 for pups-liszt; Mon, 23 Nov 1998 09:30:34 +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

26 years, 6 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" > prompt, from which you can execute the standalone images. I know this. > "format" seems to crash badly [...] Of course! The documentation says clearly that it's for hp (780/750/8600 MASSBUS and clones) and up (RH-11 and clones) disks. > [...] but one probably doesn't need that on a Q-bus > machine :-). Has nothing to do with Q-bus, it's the distinction between SMDish disks and MSCP. But yes, for MSCP you are supposed to use the controller-specific diagnostics for formatting. For DEC ones it's a pain, but most (all?) third-party MSCP controllers have formatting utilities in their ROMs. > There are other ways to start it up. For example, using an already- > running OS (some other Unix or VMS) and copying the miniroot from tape > to the swap area of an unused disk. Here is my preferred way. It requires at least two disks. First boot from an Ultrix tape. That's the easiest thing in the world probably (assuming working hardware, of course, which I don't have right now). When you get a choice between quick installation, custom installation, and maintenance, choose the last one. This will drop you into the shell. Now you have Ultrix running in a RAM disk, you can do anything you want with your disks, and you can pull the Ultrix tape out and do anything you want with the tape drive. Then you put the BSD tape in, advance to the second file (the miniroot) with mt fsf, and dd it to partition c on one of the disks. Why partition c and not partition b? Why need two disks in the first place? Because I can bet that Ultrix and BSD will have different ideas about the default location of partition b. Then extract mdec/rdboot and mdec/bootra from the /usr tar image on the tape, cat them together, and dd them to the beginning of partition c (the miniroot as shipped doesn't have a bootblock). Then reboot from that disk. Now you have BSD running! Disklabel the other disk the way you want. This will put the bootblocks on it automatically. Then create the root and /usr filesystems on it and restore them from the tape. You are all set! True, this method imposes additional requirements (two disks and an Ultrix tape). It's also a little cumbersome (the part about the miniroot bootblocks). However, it has two advantages over the method with the tmscpboot tape. First, you can use the stock BSD tape, not a hacked one. Second, even in Reno tmscpboot supports only KA630 and not KA650. If you know VAX assembly language (I don't yet) and have a machine where you can rebuild it, you can fix this, but again you have extra requirements. Of course, the proper solution is to significantly redesign BSD's installation mechanism and make it a little more like Ultrix's. That's my plan for Quasijarus2, although Quasijarus1 will still be like Tahoe/Reno. > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) I agree wholeheartedly! A standalone disklabel program is part of my plan for Quasijarus2. Again, Quasijarus1 will still be like Tahoe/Reno. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled > code. The lifting of the filesystem limits is in Tahoe, not in Reno. When you talk about the speed of Reno's binaries, what are you comparing it to? I know for sure that there are no significant changes in the C compiler between plain 4.3, Tahoe, and Reno. 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 JAA00292 for pups-liszt; Mon, 23 Nov 1998 09:40: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 Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Mon Nov 23 08:41:31 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 JAA00282 for <pups(a)minnie.cs.adfa.oz.au>; Mon, 23 Nov 1998 09:40:08 +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 JAA29811; Mon, 23 Nov 1998 09:41:31 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199811222241.JAA29811(a)henry.cs.adfa.oz.au> Subject: Re: Minnie's new domain name To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 09:41:31 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation) In-Reply-To: <199811220300.WAA16161(a)skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 21, 98 10:00:59 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: > Dear Warren, > > I see you started changing *.adfa.oz.au to *.adfa.edu.au. Should we all > start changing this in our notes, aliases, links, etc? And just out of > curiosity, what's changing? What did OZ.AU mean? Did it mean Australian > universities or what? Are you changing to EDU because that's what everyone > else uses? > > And while we are at it, what's ADFA? I thought the school's name is > UNSW, isn't it? Hi Michael, yes I should put some email out. History lesson following.... Before the Internet reached Australia, the universities had a UUCP-based mail/news system called ACSnet, where addresses were not bang-paths but @-based. The ACSnet software did the route lookups. Anyway, all ACSnet computers had a `domain' name ending in .oz, e.g kre(a)munnari.oz was a valid email address. When we finally got Internet-connected, our country suffix was .au. To make the transition easier, we just tacked it on to the end of the existing domain names, thus kre(a)munnari.oz became kre(a)munnari.oz.au More recently, to bring Australia in line with Internet conventions, .oz.au became .edu.au. Unfortunately, ADFA never bothered to do this switch until mid-way through this year. Over the summer break, I'll add some smarts to minnie's web server and other services to remind people to make the switch in their bookmarks, hotlinks etc. I'll keep it running indefinitely. ADFA is the Australian Defense Force Academy: it has military cadets as undergrads and civilians as postgrads. One half is run by the University of New South Wales and teaches normal civilian university stuff. I belong to this half. The other half is run by Defence, and teaches military history, how to shoot with guns etc. I'm not involved with that side at all :-) Cheers all, Warren P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00331 for pups-liszt; Mon, 23 Nov 1998 09:49: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

26 years, 6 months

What *was* the Tahoe?

by SHOPPA＠trailing-edge.com

I've been looking over the 4.3BSD Tahoe and Reno distributions available in the PUPS archive, and have (what I hope) is a rather simple question: What is the "Tahoe"? It seems - based on the documentation supplied in the Tahoe-specific installation docs - that "Tahoe" generically refers to any of several VERSAbus machines in the Berkeley EECS department. The CCI (Computer Consoles Inc.) Power 6/32 is frequently mentioned as the CPU, but the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 are also mentioned. Are these all the same architecture and instruction set, or are they different? How was the CPU implemented - on a chip? On a chipset? On a board? On multiple boards? The information regarding peripherals is a bit clearer. There appear to be many different supported VERSABus SMD-drive controllers and at least one supported VERSABus 9-track controller. Are any of the Berkeley EECS Tahoe machines still up and running? How many were there? How many were outside Berkeley? Tim. (shoppa(a)trailing-edge.com) Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01013 for pups-liszt; Mon, 23 Nov 1998 12:01:32 +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

26 years, 6 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > That would explain why I couldn't boot it, yep. Partially. You wouldn't be able to boot it on a MicroVAX by typing "B MUA0" even if it were complete. The reason is that the standard tape-making script writes the VAX-11 bootstraps on the tape, not the MicroVAX ones. The two are completely different. The big VAXen with front-end processors, microcode consoles and such can't boot from a tape by themselves. The bootstraps that appear on standard BSD distributions are designed to be loaded by manually typing in a little program from the console in hex and manually transferring control to it. The hex codes for 4 such programs (for different tape drives and controllers) appear in the installation docs. They cannot be ported to MicroVAXen, however, because they use some features that exist only on big VAXen. MicroVAXen, however, have tape boot capabilities built right into their ROMs. Much easier for the installer, needless to say. Also needless to say, the protocol the ROM tape boot code uses is completely different from the one the BSD developers have crafted for their very special purpose. Therefore, a tape needs a completely different bootstrap in order to be directly bootable on a MicroVAX. One was written for 4.3BSD-Tahoe, and it appears in the distributed /usr/mdec. There are two problems, however. First, the standard tape-making scripts don't put it on the tape. Second, it only supports KA630. When KA650 support was added, everything else was updated accordingly, but this one was apparently forgotten. In theory, the code looks generic enough to run on KA650 out of the box, but in practice it has a check for SID and refuses to run if it's not 08 (MicroVAX ii). Right now I don't know enough VAX assembly language to remove this check or extend to accept 0A (CVAX) as well. > In any event, I am now very happy to now have a bootable copy of > 4.3-Reno. (Installing as I type, AAMAF.) Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball and make a MicroVAX boot tape? > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > It's the most reasonable approach I can think of at the moment. That's close to what I'm doing. There are two differences, though. First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than between Tahoe and Reno. The latter is really huge, it's a gap between True UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus KA650 support and shadow passwords from Reno and other improvements from both later CSRG code and my own brain. SCCS will be the #1 tool in the process. > And what stands in the way of reading around the bad blocks on Kirk > McKusick's 43tahoe_cci distribution? Even though I know that Rick > Copeland doesn't have all the fancy tape recovery equipment I have in my > lab, is there some fundamental problem preventing the use of "mt fsr" > commands to skip the bad block(s) and recover the rest of the "src" and > "usr" tree? If you do this you will still miss something. OTOH, if you go to the 4.3tahoe directory on Kirk's 2nd CD-ROM, you won't miss anything, since all of /usr and /usr/src is there. I can bet that the files on that CD-ROM match the ones on the tape byte for byte. 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 RAA14402 for pups-liszt; Sun, 22 Nov 1998 17:04:17 +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

26 years, 6 months

Re: 4.3-VAX distributions

by SHOPPA＠trailing-edge.com

>> In any event, I am now very happy to now have a bootable copy of >> 4.3-Reno. (Installing as I type, AAMAF.) > Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it >to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball >and make a MicroVAX boot tape? Exactly. The details are all in tmscpboot.c. Prepend this to the "tape directory", write it to TK50, B MUA0, and you're at the "=" prompt, from which you can execute the standalone images. "format" seems to crash badly, but one probably doesn't need that on a Q-bus machine :-). There are other ways to start it up. For example, using an already- running OS (some other Unix or VMS) and copying the miniroot from tape to the swap area of an unused disk. The compiled-in partition tables used during an install are a real pain compared to, say, a 2.11BSD installation, where disklabel is a standalone utility! (That's a real win, Steven!) >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than >between Tahoe and Reno. The latter is really huge, it's a gap between True >UNIX(R) and a bloated and POSIXized fallen one.) Gees, looking at the install docs there are some very real improvements in Reno, especially in the filesystem and the speed of recompiled code. I'm willing to live with a bit more disk space usage, especially for the promised speed benefits. It's not like KA630's or KA650's are speed demons, and big cheap disks are readily available these days. -- 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 UAA14819 for pups-liszt; Sun, 22 Nov 1998 20:10:10 +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 "Steven M. Schultz" <sms(a)moe.2bsd.com> Sun Nov 22 19:00:06 1998 Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id UAA14808 for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Sun, 22 Nov 1998 20:10:00 +1100 (EST) (envelope-from sms(a)moe.2bsd.com) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id BAA06484 for PUPS(a)MINNIE.CS.ADFA.EDU.AU; Sun, 22 Nov 1998 01:00:06 -0800 (PST) Date: Sun, 22 Nov 1998 01:00:06 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811220900.BAA06484(a)moe.2bsd.com> To: PUPS(a)MINNIE.CS.ADFA.EDU.AU Subject: Re: 4.3-VAX distributions Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk Hi - > From: SHOPPA(a)trailing-edge.com > To: PUPS(a)MINNIE.CS.ADFA.EDU.AU All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't know there were any left :-) :-) > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" Since PUPS is on a uVax kick at the moment I'll chime in with my (not so fond) memories of trying to jack 4.3-Reno onto a uVax-II. It was a perverse sort of fun but not something I'd willingly do again. Burnout? Perhaps. the base 4.3 system up to and including Tahoe couldn't be cold started on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel had uVax support in it but the boot stuff did not. With 4.3-Reno that changed but... As others have noticed the cold start kit didn't create tapes suitable for a uVax. > prompt, from which you can execute the standalone images. "format" > seems to crash badly, but one probably doesn't need that on a Q-bus > machine :-). What I ended up doing was using my 2.11BSD 11/73 to create a bootable 4.3-Reno tape for the uVax - all the pieces are there, just need a system to 'dd' the files out with the right blocking factors, usw. Then the fun really began. The SPL "probing" logic in the kernel had a small problem when probing for MSCP controllers. As I recall (and this is going back quite a few years) some 3rd party adaptors ran at a different (lower) SPL than the probing logic expected - thus the autoconfig routines raised the SPL higher than the interrupt of the (Dilog I think) controller and the whole system hung. So, to install the system you HAD to use DEC controllers - ok, I had a RQDX3 and a couple RD53 drives present (the Dilog had a 319mb Miniscribe disk). BUT 4.3-Reno had a bug in the MSCP driver and would not recognize an honest to DEC RD53 drive! This was rapidly getting to be unfun. I think the workaround (it's been a __long__ time so memory is fuzzy) was to lie and call the drive an RA60 and then correct the problem later. But to get the lie thru to the kernel I had to use the standalone 'copy' program to copy a file (created on a PDP-11) to the first couple sectors of the uVax's RD53. Sheesh! > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) You're quite welcome. Actually 4.3-Reno served as inspiration and reminder of pain to avoid when it came time to implement 2.11BSD's disklabel capabilities. I swore I'd never go thru the pain of the kernel having labels but the standalone utilities lacking them 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the standalone programs still had compiled in partitions. > >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > >between Tahoe and Reno. The latter is really huge, it's a gap between True Can't be any version of Ultrix I ever used. At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD that DEC had corrupted with System V(anilla) bolted on contamination. Affectionately known as Buglix ;-) That was the same era that DEC had Ultrix-11 and that was a mucked up 2.9BSD. Of course you have to realize DEC had "Mr. Ken (Unix is Snake Oil) Olsen" around at the time 8-) UNIX is still around - but DEC? No, I don't like Compaq confusers thank you ;) 4.3-Reno was a transitional experiment that happened just as the CSRG and DEC had a serious falling out - and DEC support (Vaxen) vanished at that point. Any further work (4.4BSD) totally and completely ignored all DEC machines. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled Yep - you get NFS (which no 4BSD had prior to Reno). NFS doubles the size of the kernel though (at least) so there's a memory penalty to pay. It also brought many of the POSIX features (termios for example). > code. I'm willing to live with a bit more disk space usage, especially > for the promised speed benefits. It's not like KA630's or KA650's are speed > demons, and big cheap disks are readily available these days. Disk is cheap. Especially for older drives (but you run the risk that an old drive will die soon ;-(). Best to invest in a modern SCSI<->MSCP adaptor and use current drives (that's what I did for my 11/73 - adaptor is $$$ but the drives are cheap). Boy, you're not just whistling Dixie (apologies to those outside the US for which the reference is obscure). "Not a speed demon" doesn't begin to describe it. I went, believe it or not, thru the work of getting a newer GCC-2 (at the time I think 2.3.x was "new") to build and run on a uVax-II under 4.3-Reno. The biggest problem was that 4.3-Reno was neither "old" (V7ish) Unix or "POSIX" (just getting off the standard's writers desks). Getting GCC to build was a stop/go effort for several days but in the end the build would work: about 23 hours (or so)!! Sheesh - a 11/73 can *completely* regenerate itself from sources (all programs, manpages, etc) in about 28 hours. It was an interesting experiment but the uVax-II has sat here for 2+ years without being powered up. At one time the thought was to port 4.4BSD over but everyone that _could_ do the work lost interest - I've my PDP-11s and PPro systems to keep me busy so I haven't the time or inclination to do much with a KA630 system. For "slow" I have a PDP-11 (lots of fun, keeps you humble with the address space limits ;)). For 'fast' I have a couple dual cpu PPro systems (running BSD/OS) that can give a quad processor SUN Enterprise Server-4500 a run for their money. I have no need of a "slow" computer that attempts to run current day (bloated) software. I've toyed with the idea of swapping the innards of the 11/93 and the uVax. The KDJ11E would be a lot happier in a BA-123 than a BA-23;) But that's as far as it's gone (thinking about it). So - if anyone out there wants a uVax-II (9mb of memory but lots of disks and a 9-track tape drive to go with) drop by my place (shipping's out of the question). If you're more hardware capable than I perhaps we could swap the stuff into a BA23 (smaller enclosure to drive home, ...). Yikes and gadzooks - I was a bit verbose tonight (but my typing skills are much improved! ;-)). Steven Schultz sms(a)moe.2bsd.com Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14865 for pups-liszt; Sun, 22 Nov 1998 20:31:53 +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

26 years, 6 months

4.3-VAX distributions (was Re: The files Tim Shoppa has just uploaded)

by SHOPPA＠trailing-edge.com

> 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, Darn. And the label said it was a Tahoe distribution :-). You'll also remember that I'm the one who found the V6 RL02 packs at UBC which, despite all indications, are actually some sort of V7 system that has all the internal labels reading "V6"! > except that Tim's first file is severely >truncated. That would explain why I couldn't boot it, yep. In any event, I am now very happy to now have a bootable copy of 4.3-Reno. (Installing as I type, AAMAF.) We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? It's the most reasonable approach I can think of at the moment. And what stands in the way of reading around the bad blocks on Kirk McKusick's 43tahoe_cci distribution? Even though I know that Rick Copeland doesn't have all the fancy tape recovery equipment I have in my lab, is there some fundamental problem preventing the use of "mt fsr" commands to skip the bad block(s) and recover the rest of the "src" and "usr" tree? -- 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 PAA14239 for pups-liszt; Sun, 22 Nov 1998 15:57:23 +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

26 years, 6 months

The files Tim Shoppa has just uploaded

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

Re: 4.3BSD Tahoe binaries for uVax

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

Re: 4.3BSD Tahoe binaries for uVax

by SHOPPA＠trailing-edge.com

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

26 years, 6 months

Re: 4.3BSD Tahoe binaries for uVax

by SHOPPA＠trailing-edge.com

> 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

26 years, 6 months

Re: 4.3BSD Installation (probably off-topic)

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

4.3BSD Installation (probably off-topic)

by SHOPPA＠trailing-edge.com

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

26 years, 6 months

KA650 problem

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

4.2BSD and 4.3BSD

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

4.3BSD-Tahoe and 4.3BSD-Reno

by mxs46＠k2.scl.cwru.edu

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

26 years, 6 months

Re: Thoughts...

by gq696＠cleveland.Freenet.Edu

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

26 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS