The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: The Unix Heritage Society <tuhs@tuhs.org>
Subject: Re: [TUHS] a possible source for 4.1BSD tapes
Date: Mon, 11 Mar 2019 14:41:50 -0400	[thread overview]
Message-ID: <CAC20D2MgRF=r=2VvdnsPmSDf=WU=pv4htwXSOfqchXXSahhg4A@mail.gmail.com> (raw)
In-Reply-To: <20190311173845.GU31834@mcvoy.com>

[-- Attachment #1: Type: text/plain, Size: 6186 bytes --]

I think I have a true 4.1 tape in my archives but ... I'm not sure it's on
3M (Scotch media).   Those are in sealed 3M tape boxes in the basement 10
tapes to a box, and difficult to get too.   They have been kept reasonable
dry and mostly stable climate, which is why I keep them there not the
attic.   So far every tape, I have pulled from there we have succeeded in
reading .. but I have not tried in a while because my triple density drive
has load issues which I have not had the time to chase.  I also do not have
a tape oven [@Alan K . - I assume you made one.   I'd love to hear your
experiences with it].

As for BSD 4.1 kernel really was 4.0 plus a ton of small changes #ifdef
FASTVAX   [4.5 stuff is a little different than was reported the other day
-- close but not quite].   This was the work wnj did to demonstrate that
UNIX was within epsilon of VMS from a performance standpoint (i.e. the
beginning of the UCB/Stanford war of what was going to be the supported
system for Arpa).    I'm 99.999% sure that the user level APIs are the
same, the difference is he dropped into assembler in places, rewrote a
number of internal routines etc.    Basically, it tuned the c**p out of the
4.0 release to prove to DARPA that UNIX was just as fast or faster than
VMS.

Note that the userspace code between the two released were different
because time had marched on and more and more stuff was available and had
been placed in /usr/ucb; plus more and more of the original v7 commands had
been hacked/expanded.  There really was not a lot of control of the
userspace at this point and CSRG did not yet exist.  As a for instance, the
compilers and libraries had been hacked a great deal by a lot different
people so even if the foo.c was the same chances are the /bin/foo was
different binaries between the two systems [hey I wasn't a compiler person
and I had hacked on libc to fix a stdio bug was causing my thesis to go in
the toilet].

That said, 4.1BSD was the first really stable Vax code base and what a lot
of people ran.  It was formal release a lot of people outside of BSD had it
both universities and commercial. There were copies at MIT, CMU, Standford,
Harvard, much less some of the big public school likes Michigan, Wisconson,
and Purdue.  For instance, this is the kernel George Goble hacked on to
create the Purdue Dual processor Vax.   We had it a Tektronix, I know HP
and IBM had it, and the original Marx brothers machines at AT&T Whippany
ran it.  Dale's folks in Columbus had and I think ihnp4 [Indian Hill New
Products group] was a BSD 4.1 system.     Plus, of course by the time I was
at Masscomp, that was what they had had.  [Sun did too, but I don't think
they ever shipped anything with 4.1 BSD base.  The original Sun OS was done
for them by Asa Romberger's folks and was based on V7/System III.  Joy had
not come there yet].

As was reported the follow on to 4.1 BSD was to be supposed to 5.0 etc....
 the naming stuff was described correctly in earlier email here.  But all
of that was >>post<< 4.1BSD.  Post 4.1BSD shipping, CSRG had been
formalized and now a project from the DARPA to support UNIX on new Vax
hardware and to add extensions.    As was described they ended up using a
different naming scheme.  Remember until that time, there was no formal
CSRG project.  It was like ever other University, a group of people hacking
and swapping code changes with the reset of the Unix community.

So when the became a project and started to release things for DARPA is
when formal tracking started.   CSRG's Alpha's [or release candidates in
today's terms] for these were called 4.1A, 4.1B, and 4.1C.   4.1A was
pretty stable, but IIRC was not quite as radical is 4.1B (their's were
signals got hacked and a number of new system calls added).  4.1B was not
particularly stable and as Larry suggested 4.1C actually was usable and did
not crash every day.  IIRC The actual 4.2 BSD release took about a 9-12
months after 4.1C before Sam finally pushed it out the door [and I think
wnj had left for Sun by then].

As Larry's comments about  Masscomp, the original RTU 1.0 used a 4.1BSD
kernel with a bunch of System III as the base (which really was an Alpha
release for MSCP).  It shipped to a handful of customers, but it was easy
to crash (But we got it out the door and people loved it actually).  The
first version that actually was fairly stable was RTU 1.0A which was a
mash-up of the earlier work using 4.1 plus tjt and I applying a lot of 4.1C
to it (as I had brought 4.1C with me from UCB).   RTU 1.1 or maybe 1.2 was
when 4.2BSD was finally added.   I created conditional symbolic links
before that because we used them to create the Universe stuff and I've
forgotten when that shipped.

Clem


ᐧ

On Mon, Mar 11, 2019 at 1:39 PM Larry McVoy <lm@mcvoy.com> wrote:

> Other than for history's sake, I don't see the value of 4.1, it wasn't
> a great release (even though Masscomp did their changes to 4.1c if I
> remember correctly.  Clem?).  4.2 was the first release that I remember
> being pretty solid and 4.3 improved on that.
>
> On Mon, Mar 11, 2019 at 10:28:23AM -0700, Mike Haertel wrote:
> > I contacted Kirk.  He was surprised to learn that the copy of 4.1 in
> > his CSRG archive is not, in fact, 4.1.
> >
> > Also he says that the contents of the existing CSRG archive disks
> > are all he has; apparently the dumps of old distribution tapes to
> > disk were hastily done on the way out the door as CSRG was being
> > shut down.
> >
> > He suggested I inquire with TUHS for a copy, so evidently he does not
> > read this list.  His other suggestion was to reconstruct from SCCS files.
> >
> > I think at this point the preservation community has essentially all
> > the bits from tape 1 of the 7/10/81 release (in somewhat scattered
> > form needing to be reassembled into a usable distribution tape image).
> >
> > The contents of tape 2 seem to be altogether lost (unless someone is
> > able to recover it from surviving media).
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>

[-- Attachment #2: Type: text/html, Size: 8483 bytes --]

  parent reply	other threads:[~2019-03-11 18:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-10  7:31 Mike Haertel
2019-03-09 23:24 ` Nigel Williams
2019-03-10 11:18   ` Lars Brinkhoff
2019-03-10 20:55     ` Warner Losh
2019-03-10 22:53       ` Mike Haertel
2019-03-11  0:25         ` Al Kossow
2019-03-11  1:15           ` Mike Haertel
2019-03-11  5:46           ` Jason Stevens
2019-03-11 17:28             ` Mike Haertel
2019-03-11 17:38               ` Larry McVoy
2019-03-11 18:33                 ` Lars Brinkhoff
2019-03-11 18:41                 ` Clem Cole [this message]
2019-03-12  6:21                 ` Nigel Williams
2019-03-12  6:32                   ` Jason Stevens
2019-03-12 12:44                 ` arnold
2019-03-11 21:47             ` Al Kossow
2019-03-23 17:50         ` reed
2019-03-24  4:19           ` Lars Brinkhoff
2019-03-10  8:20 ` arnold
2019-03-10 15:50   ` Mike Haertel
2019-03-10 19:54     ` arnold
2019-03-10 20:33       ` Warner Losh
2019-03-25 17:19 Richard Tobin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2MgRF=r=2VvdnsPmSDf=WU=pv4htwXSOfqchXXSahhg4A@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=lm@mcvoy.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).