From aek at bitsavers.org Thu Mar 7 01:14:18 2019
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 6 Mar 2019 07:14:18 -0800
Subject: [TUHS] 1983 UBC PDP-11 Unix tools distribution
Message-ID: <74e65b12-5b0f-64af-ed0f-c5036c28dc4f@bitsavers.org>
Today's tape recovery gem. UBC's PDP-11 UNIX tools distribution ca. 1983 which includes UBC BASIC and their RT-11
emulation. It has a couple of bad blocks, but I couldn't find another copy of this anywhere.
http://bitsavers.org/bits/UBC/
If anyone has a complete copy, it would be good to replace it, but most is better than none of it.
From aek at bitsavers.org Thu Mar 7 01:20:24 2019
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 6 Mar 2019 07:20:24 -0800
Subject: [TUHS] more/BSD
In-Reply-To: <CAK7dMtBLn7h6yHMQBUhbac91RWyAOsDEoYxMWfA=n9cRxyWTZA@mail.gmail.com>
References: <CAK7dMtBLn7h6yHMQBUhbac91RWyAOsDEoYxMWfA=n9cRxyWTZA@mail.gmail.com>
Message-ID: <0331e972-3dac-5281-f3db-81ad2f122f1a@bitsavers.org>
On 2/6/19 2:58 PM, Kevin Bowling wrote:
> I have a hungry hp300. Does anyone have Mt Xinu's creation, more/BSD, archived?
Not that I know of.
I assume you mean a 9000/300. The HP 300 (Amigo) is a VERY different computer.
Sadly, it was common practice to use the cheapest 9-track tape you could buy
(often the worst.. Memorex) for distributions.
The only copy of Mt Xinu Unix I've been able to find has tapes with the binder
so sticky that baking doesn't even help.
I have a whole stack of BSD tapes that I've never even bothered to try reading
because they are MRX.
From steve at quintile.net Thu Mar 7 17:56:18 2019
From: steve at quintile.net (Steve Simon)
Date: Thu, 7 Mar 2019 07:56:18 +0000
Subject: [TUHS] sticky tapes
Message-ID: <6DEFC287-6AC2-4F59-ABAA-4B85F1DDAD21@quintile.net>
i have worked in tv, developing systems for archive restoration for many years.
if you have valuable sticky tapes i suggest you try and contact a lical video archivist, there are other tricks than just baking that can help - old tapes can present complex problems.
<story>
there was a sticky valuable rolling stones 24 track master tape i heard of. it was sent for analysis, and they discovered the stickiness was “vodka and coke†:-).
</story>
-Steve
From doug at cs.dartmouth.edu Sun Mar 10 05:19:43 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 09 Mar 2019 14:19:43 -0500
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
Message-ID: <201903091919.x29JJhcw024911@tahoe.cs.Dartmouth.EDU>
Clem,
I think the "Algol machine" you have in mind is the RC-2000 (not quite sure
of the designation--could look it up in the attic if it matters) designed by
Per Brinch Hansen for Regencentralen (again, the name may not be quite right).
The manual used Algol as a hardware description language. The instruction
set was not unusual. It has come up before in TUHS. I have the manual
if you need more info.
Doug
From bakul at bitblocks.com Sun Mar 10 06:02:43 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 09 Mar 2019 12:02:43 -0800
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
In-Reply-To: Your message of "Sat, 09 Mar 2019 14:19:43 -0500."
<201903091919.x29JJhcw024911@tahoe.cs.Dartmouth.EDU>
References: <201903091919.x29JJhcw024911@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190309200250.BE1F0156E40C@mail.bitblocks.com>
On Sat, 09 Mar 2019 14:19:43 -0500 Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Clem,
>
> I think the "Algol machine" you have in mind is the RC-2000 (not quite sure
> of the designation--could look it up in the attic if it matters) designed by
> Per Brinch Hansen for Regencentralen (again, the name may not be quite right).
I believe he architected and wrote the OS for RC-4000.
> The manual used Algol as a hardware description language. The instruction
> set was not unusual. It has come up before in TUHS. I have the manual
> if you need more info.
This manual is at bitsavers.
From clemc at ccc.com Sun Mar 10 06:06:34 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 9 Mar 2019 15:06:34 -0500
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
In-Reply-To: <20190309200250.BE1F0156E40C@mail.bitblocks.com>
References: <201903091919.x29JJhcw024911@tahoe.cs.Dartmouth.EDU>
<20190309200250.BE1F0156E40C@mail.bitblocks.com>
Message-ID: <CAC20D2Oa72_-oaxfyDTqTgQUkNFs3Mr=Q_XPUDqQToyxV-koHw@mail.gmail.com>
Right, I had found it there right after Doug's refresh of my memory. Many
thanks to you both.
I grab a copy and put it in my own historic archives.
Clem
http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf
á§
On Sat, Mar 9, 2019 at 3:03 PM Bakul Shah <bakul at bitblocks.com> wrote:
> On Sat, 09 Mar 2019 14:19:43 -0500 Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
> > Clem,
> >
> > I think the "Algol machine" you have in mind is the RC-2000 (not quite
> sure
> > of the designation--could look it up in the attic if it matters)
> designed by
> > Per Brinch Hansen for Regencentralen (again, the name may not be quite
> right).
>
> I believe he architected and wrote the OS for RC-4000.
>
> > The manual used Algol as a hardware description language. The
> instruction
> > set was not unusual. It has come up before in TUHS. I have the manual
> > if you need more info.
>
> This manual is at bitsavers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190309/229d084b/attachment.html>
From beebe at math.utah.edu Sun Mar 10 08:29:11 2019
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sat, 9 Mar 2019 15:29:11 -0700
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
Message-ID: <CMM.0.95.0.1552170551.beebe@gamma.math.utah.edu>
The posting of the link
http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf
brought back old memories. When I moved to Aarhus University in
Denmark in December 1973, I found that the Department of Chemistry
where I worked had a Regnecentralen RC-4000 minicomputer with paper
tape input that was used to manage the department's accounting. It
had a dedicated operator who kept in running nicely until at least
after I left in 1977. It had too little physical memory to be
considered practical for the quantum chemistry work that I was then
engaged in, and may not even have had a Fortran compiler; instead, we
used the campus CDC 6400 for our research.
In memory of the RC-4000, and Per Brinch Hansen's (13 Nov
1938--31-Jul-2007) many contributions to the literature of computer
science, programming language design, and parallel computing, I
prepared an enhancement of its manual, available here:
http://www.math.utah.edu/~beebe/RC-4000/
The Web page that comes up gives a directory of the available files,
and documents the steps needed to produce them. The result is a
searchable document, with a single page image per PDF page, rather
than the mixed bitmap scan of 1-up and 2-up pages in the original PDF
file.
Despite my 40+ year engagement in the TeX community, I only recently
learned via the texhax mailing of some PDFTeX internals that allow one
to construct a file that can retypeset n-up files into 1-up format.
I therefore make this posting in the hope that someone else might be
encouraged to tackle similar document improvements in the bitsavers
archives. Although it takes a bit of experimentation, with the
exception of the OCR conversion, the entire operation can be done with
free software on pretty much any modern computing platform, thanks to
the portability of the needed software.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
From rudi.j.blom at gmail.com Sun Mar 10 14:39:43 2019
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 10 Mar 2019 11:39:43 +0700
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
Message-ID: <CAMYpm865ojd2zAq-ScSfVNRhYHQL3BKHWwNG7Z53R41geSXdww@mail.gmail.com>
>Date: Sat, 9 Mar 2019 15:29:11 -0700
>From: "Nelson H. F. Beebe" <beebe at math.utah.edu>
>To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
>Subject: Re: [TUHS] Failing Memory of an Algol Based System from years ago
>Message-ID: <CMM.0.95.0.1552170551.beebe at gamma.math.utah.edu>
... snip ...
> http://www.math.utah.edu/~beebe/RC-4000/
>
>The Web page that comes up gives a directory of the available files,
>and documents the steps needed to produce them. The result is a
>searchable document, with a single page image per PDF page, rather
>than the mixed bitmap scan of 1-up and 2-up pages in the original PDF
>file.
>Despite my 40+ year engagement in the TeX community, I only recently
>learned via the texhax mailing of some PDFTeX internals that allow one
>to construct a file that can retypeset n-up files into 1-up format.
>
>I therefore make this posting in the hope that someone else might be
>encouraged to tackle similar document improvements in the bitsavers.
>archives. Although it takes a bit of experimentation, with the
>exception of the OCR conversion, the entire operation can be done with
>free software on pretty much any modern computing platform, thanks to
>the portability of the needed software.
A bit off topic (sorry) but wondering about that PDF conversion. This
may be a dumb question but did you ever try the PDF conversion in
calibre ( https://calibre-ebook.com )?
I like the PDF to htmlz conversion even if mostly the result still
needs (a lot of) extra work.
Cheers,
uncle rubl
From bakul at bitblocks.com Sun Mar 10 15:16:11 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 09 Mar 2019 21:16:11 -0800
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
In-Reply-To: Your message of "Sat, 09 Mar 2019 15:29:11 -0700."
<CMM.0.95.0.1552170551.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1552170551.beebe@gamma.math.utah.edu>
Message-ID: <20190310051618.4AEF1156E40C@mail.bitblocks.com>
On Sat, 09 Mar 2019 15:29:11 -0700 "Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:
>
> I therefore make this posting in the hope that someone else might be
> encouraged to tackle similar document improvements in the bitsavers
> archives. Although it takes a bit of experimentation, with the
> exception of the OCR conversion, the entire operation can be done with
> free software on pretty much any modern computing platform, thanks to
> the portability of the needed software.
How about tesseract for OCR? https://github.com/tesseract-ocr/tesseract
From tuhs at ducky.net Sun Mar 10 17:31:35 2019
From: tuhs at ducky.net (Mike Haertel)
Date: Sat, 09 Mar 2019 23:31:35 -0800
Subject: [TUHS] a possible source for 4.1BSD tapes
Message-ID: <201903100731.x2A7VZJF033832@ducky.net>
I noticed that the TUHS archive does not include a 4.1BSD distribution.
Also, while poking around the net, I've found a number of purported
tape images of 4.1BSD dated 7/10/1981 that look to me to a little sketchy,
since most contain files dated well into 1982.
So it appears to me that 4.1BSD is semi-lost.
While googling all this, I discovered that the School of Computer Science
and Statistics at Trinity College Dublin has an online archive catalog
which lists a couple of 4.1BSD distribution tapes in the "John Gabriel Byrne
Computer Science Collection".
https://scss.tcd.ie/SCSSTreasuresCatalog/
Perhaps someone from TUHS who lives near Dublin could investigate and
see if images can be made of these tapes?
From arnold at skeeve.com Sun Mar 10 18:20:45 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 10 Mar 2019 01:20:45 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903100731.x2A7VZJF033832@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
Message-ID: <201903100820.x2A8KjsZ029408@freefriends.org>
Isn't 4.1 on Kirk McKusick's disks?
Mike Haertel <tuhs at ducky.net> wrote:
> I noticed that the TUHS archive does not include a 4.1BSD distribution.
>
> Also, while poking around the net, I've found a number of purported
> tape images of 4.1BSD dated 7/10/1981 that look to me to a little sketchy,
> since most contain files dated well into 1982.
>
> So it appears to me that 4.1BSD is semi-lost.
>
> While googling all this, I discovered that the School of Computer Science
> and Statistics at Trinity College Dublin has an online archive catalog
> which lists a couple of 4.1BSD distribution tapes in the "John Gabriel Byrne
> Computer Science Collection".
>
> https://scss.tcd.ie/SCSSTreasuresCatalog/
>
> Perhaps someone from TUHS who lives near Dublin could investigate and
> see if images can be made of these tapes?
From nw at retrocomputingtasmania.com Sun Mar 10 09:24:53 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 10 Mar 2019 10:24:53 +1100
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903100731.x2A7VZJF033832@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
Message-ID: <CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
On Sun, Mar 10, 2019 at 6:52 PM Mike Haertel <tuhs at ducky.net> wrote:
> Also, while poking around the net, I've found a number of purported
> tape images of 4.1BSD dated 7/10/1981 that look to me to a little sketchy,
> since most contain files dated well into 1982.
Thanks Mike, you've raised an interesting question as to whether there
is an original (untainted) 1981 4.1BSD release available? I see that
the easily found distribution has modifications running into 1982.
Berkeley 4.1 VAX/UNIX (Amnesia-Vax)
login: root
Last login: Sun Jan 21 18:57:55 on console
Welcome to Berkeley Vax/UNIX (4.1bsd revised 1 Sept. 1981)
Erase is delete
Kill is control-U
# ls -l /
total 795
-rw-r--r-- 1 root 57 Mar 18 1981 .cshrc
-rw-r--r-- 1 root 90 Mar 21 1981 .login
-rw-r--r-- 1 root 99 Apr 30 1981 .profile
drwxr-xr-x 2 root 32 Mar 15 1981 arch
drwxrwxrwx 2 root 160 May 10 1982 bill
...elided...
On this page: http://gunkies.org/wiki/4.1_BSD
the file references
http://bitsavers.trailing-edge.com/bits/UCB_CSRG/4.1_BSD_19810710.zip
and that has files from Feb-1982.
The Trinity College appears to be cataloguing many interesting
software artefacts. I would be interested in some of the other items
they show on their web-page.
From lars at nocrew.org Sun Mar 10 21:18:56 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 10 Mar 2019 11:18:56 +0000
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
(Nigel Williams's message of "Sun, 10 Mar 2019 10:24:53 +1100")
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
Message-ID: <7wpnqzj7tr.fsf@junk.nocrew.org>
Nigel Williams wrote:
> Mike Haertel wrote:
>> Also, while poking around the net, I've found a number of purported
>> tape images of 4.1BSD dated 7/10/1981 that look to me to a little sketchy
> http://bitsavers.trailing-edge.com/bits/UCB_CSRG/4.1_BSD_19810710.zip
That's what I have been using for testing the MIT Chaosnet patches.
If it's no good, I'd like to know.
From tuhs at ducky.net Mon Mar 11 01:50:36 2019
From: tuhs at ducky.net (Mike Haertel)
Date: Sun, 10 Mar 2019 08:50:36 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903100820.x2A8KjsZ029408@freefriends.org>
References: <201903100731.x2A7VZJF033832@ducky.net>
<201903100820.x2A8KjsZ029408@freefriends.org>
Message-ID: <201903101550.x2AFoaZp036647@ducky.net>
arnold at skeeve.com writes:
> Isn't 4.1 on Kirk McKusick's disks?
McKusick's disks look sketchy to me too:
# cd /mnt/CSRG/disk1
# diff --exclude=.MAP -r 4.0 4.1 | grep -v 'not a regular file or directory'
Only in 4.0: 4.0.boot.Z
Only in 4.1: 4.0.upgrade
Only in 4.1: TAPE
Only in 4.1: boot.file
Only in 4.0/dev: cua0
Only in 4.0/dev: cua1
Only in 4.1/tmp: x.f
Only in 4.1/tmp: x.s
Only in 4.0/usr/src/lib/libpc: RANDOM.c
Only in 4.0/usr/src/lib/libpc: RANG4.c
Only in 4.0/usr/src/lib/libpc: READ4.c
Only in 4.0/usr/src/lib/libpc: READ8.c
Only in 4.0/usr/src/lib/libpc: READC.c
Only in 4.0/usr/src/lib/libpc: READE.c
Only in 4.0/usr/src/lib/libpc: READLN.c
Only in 4.0/usr/src/lib/libpc: RELEQ.c
Only in 4.0/usr/src/lib/libpc: RELNE.c
Only in 4.0/usr/src/lib/libpc: RELSGE.c
Only in 4.0/usr/src/lib/libpc: RELSGT.c
Only in 4.0/usr/src/lib/libpc: RELSLE.c
Only in 4.0/usr/src/lib/libpc: RELSLT.c
Only in 4.0/usr/src/lib/libpc: RELTGE.c
Only in 4.0/usr/src/lib/libpc: RELTGT.c
Only in 4.0/usr/src/lib/libpc: RELTLE.c
So it appears to me the only 4.1 material in his 4.1 tree is under the
4.1/4.0.upgrade directory.
The 4.0 and 4.1 trees on his disks are otherwise basically the same,
except for a handful of /usr/src/lib/libpc/*.c source files that appear
only in the 4.0 tree.
Or, perhaps the 4.0 tree is misidentified and is really a 4.1 tree, and
what is lost is 4.0?
Anyway, there definitely seems to be a missing link somewhere.
Mike
From arnold at skeeve.com Mon Mar 11 05:54:45 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 10 Mar 2019 13:54:45 -0600
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903101550.x2AFoaZp036647@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
<201903100820.x2A8KjsZ029408@freefriends.org>
<201903101550.x2AFoaZp036647@ducky.net>
Message-ID: <201903101954.x2AJsjL7016848@freefriends.org>
Mike Haertel <tuhs at ducky.net> wrote:
> arnold at skeeve.com writes:
> > Isn't 4.1 on Kirk McKusick's disks?
>
> McKusick's disks look sketchy to me too:
So can "someone" ping Kirk about this?
From imp at bsdimp.com Mon Mar 11 06:33:05 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 10 Mar 2019 14:33:05 -0600
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903101954.x2AJsjL7016848@freefriends.org>
References: <201903100731.x2A7VZJF033832@ducky.net>
<201903100820.x2A8KjsZ029408@freefriends.org>
<201903101550.x2AFoaZp036647@ducky.net>
<201903101954.x2AJsjL7016848@freefriends.org>
Message-ID: <CANCZdfrK64EUDSbDbNiLc=qmmFCQf=7-D853kToswMQC-v3K-A@mail.gmail.com>
On Sun, Mar 10, 2019 at 1:55 PM <arnold at skeeve.com> wrote:
> Mike Haertel <tuhs at ducky.net> wrote:
>
> > arnold at skeeve.com writes:
> > > Isn't 4.1 on Kirk McKusick's disks?
> >
> > McKusick's disks look sketchy to me too:
>
> So can "someone" ping Kirk about this?
>
Keep in mind that BSD didn't really have releases. When you called up for a
tape, it wasn't made from some master tape, but rolled off from a system
that had right version on it. I know Kirk told me this once when I was
chatting with him about tapes, RMS and other things. Thje version control
wasn't quite as strict as things are today, so I'm not surprised there's
some variance in images from place to place around the net. We have SCCS,
and multiple images. I think the best we may be able to do is to do the
this was copied from that with these changes and produce a tree of
inheritance... IIRC, SCCS has issues with moved and removed files that
makes it hard to reconstruct things exactly with it. I know RCS and CVS had
these issues. The historical unix git repo has
remotes/origin/BSD-4-Snapshot-Development
remotes/origin/BSD-4_1_snap-Snapshot-Development
remotes/origin/BSD-4_1c_2-Snapshot-Development
branches. Also, version numbering was kinda hazy. Kirk has a big listing in
his house of 4.5 BSD. This is post the first 4BSD release, but not the 5BSD
release. They had thought they'd do a 5BSD, but they had all these
contracts with 4BSD in them, so they were basically forced to do 4.1BSD
instead, so the "4.5BSD" thing is basically an early version of what we
know know as 4.1BSD.... So between these two quirks, I'm not surprised
there's not an 'untainted' version of 4.1BSD around... I'm guessing the
tape that has the July 1981 date on it was made in early 1982 and the extra
files with the weird dates are just an artifact of when the tape was made
and that people had used the 'master image' system in the mean time, if for
nothing else than logging into and running the make tape script :)
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190310/d3181961/attachment.html>
From imp at bsdimp.com Mon Mar 11 06:55:15 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 10 Mar 2019 14:55:15 -0600
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <7wpnqzj7tr.fsf@junk.nocrew.org>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
Message-ID: <CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
On Sun, Mar 10, 2019 at 5:49 AM Lars Brinkhoff <lars at nocrew.org> wrote:
> Nigel Williams wrote:
> > Mike Haertel wrote:
> >> Also, while poking around the net, I've found a number of purported
> >> tape images of 4.1BSD dated 7/10/1981 that look to me to a little
> sketchy
> > http://bitsavers.trailing-edge.com/bits/UCB_CSRG/4.1_BSD_19810710.zip
>
> That's what I have been using for testing the MIT Chaosnet patches.
> If it's no good, I'd like to know.
>
There's also
http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
just noticed...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190310/acb38146/attachment.html>
From tuhs at ducky.net Mon Mar 11 08:53:46 2019
From: tuhs at ducky.net (Mike Haertel)
Date: Sun, 10 Mar 2019 15:53:46 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
Message-ID: <201903102253.x2AMrks8039290@ducky.net>
Warner Losh writes:
>There's also
>http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
>just noticed...
>
>Warner
That tape image is has 3 files in it:
The first consists of a bunch of 1024-byte records followed by a
single 512-byte record. It may be a boot loader.
The second is a file system dump. I haven't attempted to examine
its contents yet.
The third is a tar of /usr, with absolute pathnames for all files
in it.
The tar archive truncates abruptly in the middle of a Franz Lisp
manual source file, which it is trying to extract somewhere under
/usr/tape1/.
Some of the directories in the tar archive have modification times
in 1982, but all of the files in the tar archive are 1981 or earlier.
If you ignore /usr/tape1/* and look only at the earlier files in the
tar archive, it appears it might be a legitimate copy of 4.1BSD as
of Aug 31, 1981. In particular, there is a large cluster of files
with modification times of 7/9/1981, and fewer than 25 files newer
than that. The newest file (excluding the /usr/tape1 material)
is 8/31/1981.
From aek at bitsavers.org Mon Mar 11 10:25:45 2019
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 10 Mar 2019 17:25:45 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903102253.x2AMrks8039290@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
Message-ID: <de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
On 3/10/19 3:53 PM, Mike Haertel wrote:
> Warner Losh writes:
>> There's also
>> http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
>> just noticed...
Likely a Memorex sticky tape that stripped its oxide when I tried to read it.
These were read a long time before I had a tape oven.
I've not dug back into what I still have from the 4BSD days, or in the CHM
archives since I thought Kirk had this all covered.
From tuhs at ducky.net Mon Mar 11 11:15:18 2019
From: tuhs at ducky.net (Mike Haertel)
Date: Sun, 10 Mar 2019 18:15:18 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
Message-ID: <201903110115.x2B1FI0V040212@ducky.net>
Al Kossow writes:
> On 3/10/19 3:53 PM, Mike Haertel wrote:
> > Warner Losh writes:
> >> There's also
> >> http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
> >> just noticed...
>
> Likely a Memorex sticky tape that stripped its oxide when I tried to read it.
>
> These were read a long time before I had a tape oven.
>
> I've not dug back into what I still have from the 4BSD days, or in the CHM
> archives since I thought Kirk had this all covered.
I've double-checked, and disk1/4.1 from Kirk's archive is definitely 4.0,
(with the addition of a 4.0.upgrade directory taken from a 4.1 distribution).
As far as online 4.1 tape images are concerned, I did a bit more investigating:
AFAICT this file: http://bitsavers.org/bits/BSD/BSD4.1_bootable.tap.gz appears
to be the closest online thing to a 7/10/1981 version of 4.1.
This file: http://bitsavers.org/bits/UCB_CSRG/41bsd_7-10-81.tap contains files
with modification times up through June 1982.
Neither of these include the corresponding /usr/doc or /usr/ingres (which would
have been on the distribution tape #2). Those seem to be missing altogether.
From rudi.j.blom at gmail.com Mon Mar 11 15:45:05 2019
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Mon, 11 Mar 2019 12:45:05 +0700
Subject: [TUHS] Failing Memory of an Algol Based System from years ago
Message-ID: <CAMYpm875iEjweAgBQ4RP59Hy2bivxbmLQLkxcZGF2eczG8c71Q@mail.gmail.com>
>A bit off topic (sorry) but wondering about that PDF conversion. This
>may be a dumb question but did you ever try the PDF conversion in
>calibre ( https://calibre-ebook.com )?
To answer my own question. Yes, that was a dumb question. I completely
over looked the 'image' in Nelson's post
>The result is a
>searchable document, with a single page image per PDF page, rather
>than the mixed bitmap scan of 1-up and 2-up pages in the original PDF
>file.
Calibre's PDF to whatever conversion doesn't do anything worthwhile with images.
From jsteve at superglobalmegacorp.com Mon Mar 11 15:46:38 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Mon, 11 Mar 2019 05:46:38 +0000
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
Message-ID: <ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
I'm not blaming anyone, as a matter of fact I'm super grateful for all the hard work that is done to preserve what is there on these old tapes, but it's super frustrating that we don't have good historical artifacts. And that tapes are so seemingly useless.
I'm 100% out of my element, but is there a kyrolux like device for tapes? It seems so many 'cut short' and yet I image there is most certainly more tape on the spool.
I'm just a n00b, and apologize if it's a dumb thing to ask.
I linked to the bitsaver stuff when writing on the 4.1 stuff as they booted in simh and gave a seemingly working system, but clearly they are missing stuff. I guess I need to figure out the sccs and how to find the latest date on a tape and work from that date based on the CD archive.
But thanks again, Al for your bits that has me hooked on looking at the latest digital artifacts!!
I still have hope that more of TripOS eventually surfaces
On Mon, Mar 11, 2019 at 8:26 AM +0800, "Al Kossow" <aek at bitsavers.org> wrote:
On 3/10/19 3:53 PM, Mike Haertel wrote:
> Warner Losh writes:
>> There's also
>> http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
>> just noticed...
Likely a Memorex sticky tape that stripped its oxide when I tried to read it.
These were read a long time before I had a tape oven.
I've not dug back into what I still have from the 4BSD days, or in the CHM
archives since I thought Kirk had this all covered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190311/2dac85a1/attachment.html>
From tuhs at ducky.net Tue Mar 12 03:28:23 2019
From: tuhs at ducky.net (Mike Haertel)
Date: Mon, 11 Mar 2019 10:28:23 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
Message-ID: <201903111728.x2BHSNqG045196@ducky.net>
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).
From lm at mcvoy.com Tue Mar 12 03:38:45 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Mar 2019 10:38:45 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903111728.x2BHSNqG045196@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net>
Message-ID: <20190311173845.GU31834@mcvoy.com>
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
From lars at nocrew.org Tue Mar 12 04:33:40 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 11 Mar 2019 18:33:40 +0000
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <20190311173845.GU31834@mcvoy.com> (Larry McVoy's message of
"Mon, 11 Mar 2019 10:38:45 -0700")
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net>
<20190311173845.GU31834@mcvoy.com>
Message-ID: <7w8sxlgt17.fsf@junk.nocrew.org>
Larry McVoy wrote:
> Other than for history's sake, I don't see the value of 4.1, it wasn't
> a great release
It may have some value if you want to have 4BSD networked through
Chaosnet. MIT's Chaosnet patch applies on top of 4.1. I haven't
checked 4.2.
From clemc at ccc.com Tue Mar 12 04:41:50 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 11 Mar 2019 14:41:50 -0400
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <20190311173845.GU31834@mcvoy.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com>
Message-ID: <CAC20D2MgRF=r=2VvdnsPmSDf=WU=pv4htwXSOfqchXXSahhg4A@mail.gmail.com>
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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190311/b2ba40c4/attachment.html>
From aek at bitsavers.org Tue Mar 12 07:47:55 2019
From: aek at bitsavers.org (Al Kossow)
Date: Mon, 11 Mar 2019 14:47:55 -0700
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
Message-ID: <29db723b-91f8-c7fa-591e-5ac383bffab0@bitsavers.org>
On 3/10/19 10:46 PM, Jason Stevens wrote:
> is there a kyrolux like device for tapes?
The problem is dropouts from either tape surface contamination or oxide loss, tape skew, and tape stretch.
I've been working off and on with Len Shustek on analog digitization and recovery of 7 and 9 track tape
https://github.com/LenShustek/readtape
to try to deal with tape that has signal degradation
He and I use Saleae Pro Logic 16 USB 16-channel USB setups connected to the read amps of a tape drive
I have a Linux box set up with 128gb of memory for data capture.
It is a time-consuming process, and I only resort to that for high-value problem children.
From nw at retrocomputingtasmania.com Tue Mar 12 16:21:01 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Tue, 12 Mar 2019 17:21:01 +1100
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <20190311173845.GU31834@mcvoy.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com>
Message-ID: <CACCFpdwCG4khRgSgfG3nifoJMjUOa30t1dMFMbR-D9USRjLHHA@mail.gmail.com>
On Tue, Mar 12, 2019 at 4:39 AM Larry McVoy <lm at mcvoy.com> wrote:
> Other than for history's sake, I don't see the value of 4.1
On the history side, I found having 4.1 BSD important when we were
recovering the build of a programming language on this version. As we
had the binary we wanted to be sure that when we re-compiled we could
confirm that the result was identical to the original. This was to
ensure that we had recovered the build environment as it was
originally. For that reason, I would urge preservationists to always
try to recover as many incremental versions as possible.
From jsteve at superglobalmegacorp.com Tue Mar 12 16:32:24 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 12 Mar 2019 06:32:24 +0000
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <CACCFpdwCG4khRgSgfG3nifoJMjUOa30t1dMFMbR-D9USRjLHHA@mail.gmail.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com>
<CACCFpdwCG4khRgSgfG3nifoJMjUOa30t1dMFMbR-D9USRjLHHA@mail.gmail.com>
Message-ID: <ADFDF14544A65F35.2cccdb47-39d7-46c3-bbff-d01c7332b3c1@mail.outlook.com>
I would also add that 4.1 also ties into research UNIX v8.
On the VAX (via SIMH) its bootstrapped from a 4.1 system.
David du Colombier's guide uses the 4.1 image I found and modified with some 4.2 to get running on SIMH
http://9legacy.org/9legacy/doc/simh/v8
Not having 4.1 would have made this far more involved. 4.2 is no doubt a major Internet milestone on the way to SunOS & 4.3 while 4.0/4.1 are important in a pre-tcpip focused world.
Naturally I'm biased into thinking they are all important, but I know resources /time are limited.
On Tue, Mar 12, 2019 at 2:22 PM +0800, "Nigel Williams" <nw at retrocomputingtasmania.com> wrote:
On Tue, Mar 12, 2019 at 4:39 AM Larry McVoy wrote:
> Other than for history's sake, I don't see the value of 4.1
On the history side, I found having 4.1 BSD important when we were
recovering the build of a programming language on this version. As we
had the binary we wanted to be sure that when we re-compiled we could
confirm that the result was identical to the original. This was to
ensure that we had recovered the build environment as it was
originally. For that reason, I would urge preservationists to always
try to recover as many incremental versions as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190312/35d4a7a0/attachment.html>
From arnold at skeeve.com Tue Mar 12 22:44:09 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 12 Mar 2019 06:44:09 -0600
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <20190311173845.GU31834@mcvoy.com>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<de2eb3ea-a074-96bc-4910-91119f2c7e74@bitsavers.org>
<ADFDF14544A65F35.9f917bb9-1555-42a4-a4b7-828cb9d3df0b@mail.outlook.com>
<201903111728.x2BHSNqG045196@ducky.net>
<20190311173845.GU31834@mcvoy.com>
Message-ID: <201903121244.x2CCi99p020772@freefriends.org>
Larry McVoy <lm at 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.
I'm with Clem; we ran 4.1 at Georgia Tech and it was pretty solid.
The big changes in 4.2 were the fast file system, the networking, and
how signals worked.
The fast file system used more space on the disk for its metadata;
people who had nearly full disks on 4.1 didn't have enough room to
restore their filesystems with the change to 4.2!
Later on I ran two vaxen at the Emory U computing center with 4.2; they
were heavily (over)loaded. When 4.3 came out it had a huge amount of fixes
and performance tuning; when we switched to 4.3 + NFS from Mt. Xinu we
saw a big drop in the load. To this day I am convinced that the move to
4.3 kept us from having to buy more hardware.
Arnold
From crossd at gmail.com Wed Mar 13 02:02:50 2019
From: crossd at gmail.com (Dan Cross)
Date: Tue, 12 Mar 2019 12:02:50 -0400
Subject: [TUHS] Bell Labs data center in 1969/70.
Message-ID: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
TUHS related due to the BTL connection. This came across a mailing list at
work today (as a, "hey, this is cool!" thing; nothing work related) and I
thought some on this list might be interested.
http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/index.html
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190312/2a8501a3/attachment.html>
From clemc at ccc.com Wed Mar 13 03:14:58 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Mar 2019 13:14:58 -0400
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
Message-ID: <CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
Very cool. Takes me back when I used to do that ;-) As CMU of us all
system programmers had to do shifts as operators. The thinking was that
if we had do the crappy job too, we would fix things and not let the bugs
build. FWIW: I can not tell which model 360 it is. I think its a 65 or
67. It's not a 91 nor a 40 or 50.
BTW the 'bell' on the console was a fire alarm bell inside of the main CPU
cab. Also what those pics do not reveal is how noisy it was in the machine
rooms. The fans were constantly going.
Clem
á§
On Tue, Mar 12, 2019 at 12:04 PM Dan Cross <crossd at gmail.com> wrote:
> TUHS related due to the BTL connection. This came across a mailing list at
> work today (as a, "hey, this is cool!" thing; nothing work related) and I
> thought some on this list might be interested.
>
>
> http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/index.html
>
> - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190312/3042ea7a/attachment.html>
From jon at fourwinds.com Wed Mar 13 03:17:49 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Mar 2019 10:17:49 -0700
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
Message-ID: <201903121717.x2CHHnET014771@darkstar.fourwinds.com>
On Tue, Mar 12, 2019 at 12:04 PM Dan Cross <crossd at gmail.com> wrote:
>
> TUHS related due to the BTL connection. This came across a mailing list a=
t
> work today (as a, "hey, this is cool!" thing; nothing work related) and I
> thought some on this list might be interested.
>
>
> http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/index.html
>
> - Dan C.
Must be a different Bell. I wanted to take a picture of me in my lab for my
high school yearbook but no way no how could get permission to bring in a
camera.
Jon
From clemc at ccc.com Wed Mar 13 03:29:27 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Mar 2019 13:29:27 -0400
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <201903121717.x2CHHnET014771@darkstar.fourwinds.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
<201903121717.x2CHHnET014771@darkstar.fourwinds.com>
Message-ID: <CAC20D2OsZgLnH0LBtazc+3NpgSMyuKFQzEgX+mjmfdjm1CiqcQ@mail.gmail.com>
Jon - Dept Head vs. peon maybe ;-)
á§
On Tue, Mar 12, 2019 at 1:24 PM Jon Steinhart <jon at fourwinds.com> wrote:
> On Tue, Mar 12, 2019 at 12:04 PM Dan Cross <crossd at gmail.com> wrote:
> >
> > TUHS related due to the BTL connection. This came across a mailing list
> a=
> t
> > work today (as a, "hey, this is cool!" thing; nothing work related) and I
> > thought some on this list might be interested.
> >
> >
> >
> http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/index.html
> >
> > - Dan C.
>
> Must be a different Bell. I wanted to take a picture of me in my lab for
> my
> high school yearbook but no way no how could get permission to bring in a
> camera.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190312/e11f56cc/attachment.html>
From jon at fourwinds.com Wed Mar 13 03:31:25 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Mar 2019 10:31:25 -0700
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAC20D2OsZgLnH0LBtazc+3NpgSMyuKFQzEgX+mjmfdjm1CiqcQ@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
<201903121717.x2CHHnET014771@darkstar.fourwinds.com>
<CAC20D2OsZgLnH0LBtazc+3NpgSMyuKFQzEgX+mjmfdjm1CiqcQ@mail.gmail.com>
Message-ID: <201903121731.x2CHVPFq017936@darkstar.fourwinds.com>
Clem Cole writes:
>
> Jon - Dept Head vs. peon maybe ;-)
> =E1=90=A7
Could be, but both Joe Condon and Hank MacDonald asked on my behalf
and they weren't peons.
From paul.winalski at gmail.com Wed Mar 13 03:42:21 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 12 Mar 2019 13:42:21 -0400
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
Message-ID: <CABH=_VQp+8AM6bky5p=9Z3_rPnPCuDzhHCHuwHyc8tNsFdOR1g@mail.gmail.com>
On 3/12/19, Clem Cole <clemc at ccc.com> wrote:
> Very cool. Takes me back when I used to do that ;-) As CMU of us all
> system programmers had to do shifts as operators. The thinking was that
> if we had do the crappy job too, we would fix things and not let the bugs
> build. FWIW: I can not tell which model 360 it is. I think its a 65 or
> 67. It's not a 91 nor a 40 or 50.
>
That's definitely a S/360 model 50 that the operator is hiding in.
-Paul W.
From dot at dotat.at Wed Mar 13 08:15:30 2019
From: dot at dotat.at (Tony Finch)
Date: Tue, 12 Mar 2019 22:15:30 +0000
Subject: [TUHS] P J Plauger in popular culture
Message-ID: <F636E831-0082-4EDE-85F7-4A4B64F7809C@dotat.at>
An amusing Unix-related snippet from a science fiction site:
https://www.tor.com/2019/03/12/more-please-authors-we-wish-would-publish-more-often/
> Back when the world was young and a ten megabyte hard drive required a team of six sturdy workers to move, P. J. Plauger quite reliably delivered to the world a story or so per year—memorable tales like “Wet Blanket†and “Child of All Ages,†stories that won him a Campbell for Best New Writer and a Hugo nomination for Best Short Story. Tragedy struck when he was enticed away from science fiction by the seedy world of Unix, which offered its arcane practitioners unnecessary luxuries like indoor living, food, and even health care.
(The rest of the page is not relevant to this list)
Tony.
--
f.anthony.n.finch <dot at dotat.at> http://dotat.at
From grog at lemis.com Wed Mar 13 10:17:33 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 13 Mar 2019 11:17:33 +1100
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
Message-ID: <20190313001733.GA86164@eureka.lemis.com>
On Tuesday, 12 March 2019 at 13:14:58 -0400, Clem Cole wrote:
> Very cool. Takes me back when I used to do that ;-) As CMU of us
> all system programmers had to do shifts as operators. The thinking
> was that if we had do the crappy job too, we would fix things and
> not let the bugs build.
Clearly a different attitude from ours. We always felt honoured to be
let into the Holy of Holies (behind not one, but two armoured doors).
Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190313/7319a15b/attachment.sig>
From dave at horsfall.org Wed Mar 13 11:37:47 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 13 Mar 2019 12:37:47 +1100 (EST)
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1903131224110.69634@aneurin.horsfall.org>
On Tue, 12 Mar 2019, Clem Cole wrote:
> Very cool. Takes me back when I used to do that ;-) As CMU of us all
> system programmers had to do shifts as operators.  The thinking was
> that if we had do the crappy job too, we would fix things and not let
> the bugs build. FWIW: I can not tell which model 360 it is. I think
> its a 65 or 67. It's not a 91 nor a 40 or 50.Â
One of the best unpaid jobs I ever did was being a student 360/50 operator
on the night shift. Boy, the stories that I could tell, such as card
decks being sticky-taped together, paper tape stuck to the spool, etc...
And the time that I switched off the 029 keypunch printer to not print the
"PRI=6" JCL, thereby screwing up the operator's disk schedule... I got my
deck back, unsubmitted, with the job card torn into a neat spiral.
I actually met him at a DECUS conference, and he was most amiable about
it.
And no, it doesn't look like a /50 console to me.
-- Dave
From peter at rulingia.com Wed Mar 13 18:41:08 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 13 Mar 2019 19:41:08 +1100
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <alpine.BSF.2.21.9999.1903131224110.69634@aneurin.horsfall.org>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
<alpine.BSF.2.21.9999.1903131224110.69634@aneurin.horsfall.org>
Message-ID: <20190313084108.GF87064@server.rulingia.com>
On 2019-Mar-13 12:37:47 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>On Tue, 12 Mar 2019, Clem Cole wrote:
>> the bugs build. FWIW: I can not tell which model 360 it is. I think
>> its a 65 or 67. It's not a 91 nor a 40 or 50.Â
...
>And no, it doesn't look like a /50 console to me.
Well, the model number should be visible in
http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/slides/Bell_Labs__0003.html
but it's too blurred for me to make it out (even knowing that the first
2 digits are "20", I can't make them out).
I've looked through both the IBM history pages and the WP pages and I'm
reasonably confident it's a /50. Compare the above photo with
https://upload.wikimedia.org/wikipedia/commons/thumb/3/39/IBM_system_360-50_console_-_MfK_Bern.jpg/450px-IBM_system_360-50_console_-_MfK_Bern.jpg
or https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH2050.html
It's definitely not a /65 based on the leftmost subpanel - see
https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH2065C.html
The only /67 photos I can find show a similarly blank subpanel.
The other S360 models all had radically different front panels (much lower
on the low-end models and much wider on the high-end models).
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190313/855f5ed5/attachment.sig>
From doug at cs.dartmouth.edu Wed Mar 13 23:25:39 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 13 Mar 2019 09:25:39 -0400
Subject: [TUHS] Bell Labs data center in 1969/70
Message-ID: <201903131325.x2DDPds4028941@coolidge.cs.Dartmouth.EDU>
Strangely I have no recollection of a Bell Labs branch further
west than Denver. What did they do in Oakland?
Doug
From robpike at gmail.com Thu Mar 14 18:10:30 2019
From: robpike at gmail.com (Rob Pike)
Date: Thu, 14 Mar 2019 19:10:30 +1100
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <201903131325.x2DDPds4028941@coolidge.cs.Dartmouth.EDU>
References: <201903131325.x2DDPds4028941@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAKzdPgyTrz8u+mZFi8d_dOhrrfDcwWmQ2asd7tgXsyTJ3KCW=Q@mail.gmail.com>
Maybe it was the bizarro Bell Labs whose existence meant we couldn't have
the domain belllabs.com.
-rob
On Thu, Mar 14, 2019 at 12:26 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Strangely I have no recollection of a Bell Labs branch further
> west than Denver. What did they do in Oakland?
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190314/dd3dea2e/attachment.html>
From aek at bitsavers.org Fri Mar 15 08:12:55 2019
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 14 Mar 2019 15:12:55 -0700
Subject: [TUHS] Bell Labs data center in 1969/70.
In-Reply-To: <20190313084108.GF87064@server.rulingia.com>
References: <CAEoi9W62Ck5cB0rD1=ahaZVzfmp4=n3MMw6zLhb3ZVjnav+uuw@mail.gmail.com>
<CAC20D2N-mFP9Sx5ekFAMMBf3p964w9vPsJBEY6kCU4oqQ9vB3w@mail.gmail.com>
<alpine.BSF.2.21.9999.1903131224110.69634@aneurin.horsfall.org>
<20190313084108.GF87064@server.rulingia.com>
Message-ID: <9ac08f44-100e-83c8-4532-4a4a4cc7d00e@bitsavers.org>
On 3/13/19 1:41 AM, Peter Jeremy wrote:
> On 2019-Mar-13 12:37:47 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>> On Tue, 12 Mar 2019, Clem Cole wrote:
>>> the bugs build. FWIW: I can not tell which model 360 it is. I think
>>> its a 65 or 67. It's not a 91 nor a 40 or 50.Â
> ...
>> And no, it doesn't look like a /50 console to me.
http://infolab.stanford.edu/pub/voy/museum/pictures/display/IBM2050ConsoleRed_1965.jpg
From kevin.bowling at kev009.com Fri Mar 15 14:03:34 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 14 Mar 2019 21:03:34 -0700
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <CAKzdPgyTrz8u+mZFi8d_dOhrrfDcwWmQ2asd7tgXsyTJ3KCW=Q@mail.gmail.com>
References: <201903131325.x2DDPds4028941@coolidge.cs.Dartmouth.EDU>
<CAKzdPgyTrz8u+mZFi8d_dOhrrfDcwWmQ2asd7tgXsyTJ3KCW=Q@mail.gmail.com>
Message-ID: <CAK7dMtBM-X4yP8_GWsp9qWa7og-dO0VRaci-_JL57Dxso9-PMQ@mail.gmail.com>
I was amused last weekend after using that Bell Labs product to treat an
old AT&T Long Lines L-Carrier bunker.
Regards,
Kevin
On Thu, Mar 14, 2019 at 1:11 AM Rob Pike <robpike at gmail.com> wrote:
> Maybe it was the bizarro Bell Labs whose existence meant we couldn't have
> the domain belllabs.com.
>
> -rob
>
>
> On Thu, Mar 14, 2019 at 12:26 AM Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
>
>> Strangely I have no recollection of a Bell Labs branch further
>> west than Denver. What did they do in Oakland?
>>
>> Doug
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190314/83b4d502/attachment.html>
From doug at cs.dartmouth.edu Sat Mar 16 07:21:53 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 15 Mar 2019 17:21:53 -0400
Subject: [TUHS] [patch] do not strip mdoc macros
Message-ID: <201903152121.x2FLLrwW084445@tahoe.cs.Dartmouth.EDU>
>> But sed, awk, perl, python, ... lex and parse once into an AST or
>> bytecode, removing the recurring cost of comments, etc. that impact
>> groff. So I don't think it's an even comparison.
>
> Of course it's a valid comparison. Which sed or awk or shell script is
> distributed in a stripped/compressed form? Do they store their AST
> somewhere, so as to avoid recompilation? They do not. Just as
> with groff, every parse starts anew.
Comments inside of a macro definition get scanned each time it's called.
This justifies the first paragraph above.
In the wild, almost all comments occur outside macro definitions.
This justifies the second.
Thus comments are harmless in practice.
Doug
From scj at yaccman.com Sun Mar 17 07:30:14 2019
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 16 Mar 2019 14:30:14 -0700
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <CAKzdPgyTrz8u+mZFi8d_dOhrrfDcwWmQ2asd7tgXsyTJ3KCW=Q@mail.gmail.com>
Message-ID: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com>
For a long time, California was viewed as hostile to phone companies,
or at least AT&T, and I remember clearly people saying that Bell Labs
would never have a location in CA as a result.
----- Original Message -----
From: "Rob Pike" <robpike at gmail.com>
To:"Doug McIlroy" <doug at cs.dartmouth.edu>
Cc:<tuhs at tuhs.org>
Sent:Thu, 14 Mar 2019 19:10:30 +1100
Subject:Re: [TUHS] Bell Labs data center in 1969/70
Maybe it was the bizarro Bell Labs whose existence meant we couldn't
have the domain belllabs.com [1].
-rob
On Thu, Mar 14, 2019 at 12:26 AM Doug McIlroy <doug at cs.dartmouth.edu
[2]> wrote:
Strangely I have no recollection of a Bell Labs branch further
west than Denver. What did they do in Oakland?
Doug
Links:
------
[1] http://belllabs.com
[2] mailto:doug at cs.dartmouth.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190316/763ccfec/attachment.html>
From wpk at culm.net Sun Mar 17 08:10:11 2019
From: wpk at culm.net (Witold Krecicki)
Date: Sat, 16 Mar 2019 23:10:11 +0100
Subject: [TUHS] Early DNS software
Message-ID: <7dee0de4-5e56-006b-d8a7-e287c1dee09f@culm.net>
Hello,
I'm looking for old DNS software - servers, clients, libraries. The
oldest one I've found is BIND 4.3 from 4.3BSD (and it works as a
resolver on 2019 Internet), but there were earlier ones -
http://www.donelan.com/dnstimeline.html says that UCB released first
BIND in 1985, something was running on earlier servers. Any help would
be appreciated.
Witold Krecicki
From wpk at culm.net Sun Mar 17 08:20:42 2019
From: wpk at culm.net (Witold Krecicki)
Date: Sat, 16 Mar 2019 23:20:42 +0100
Subject: [TUHS] Early DNS software
Message-ID: <63f58b28-f7cd-6f7e-db71-2b862ca97cdd@culm.net>
Hello,
I'm looking for old DNS software - servers, clients, libraries. The
oldest one I've found is BIND 4.3 from 4.3BSD (and it works as a
resolver on 2019 Internet), but there were earlier ones -
http://www.donelan.com/dnstimeline.html says that UCB released first
BIND in 1985, something was running on earlier servers. Any help would
be appreciated.
Witold Krecicki
From dave at horsfall.org Sun Mar 17 11:02:39 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 17 Mar 2019 12:02:39 +1100 (EST)
Subject: [TUHS] In memoriam: John Backus
Message-ID: <alpine.BSF.2.21.9999.1903171159280.69634@aneurin.horsfall.org>
We lost computer pioneer John Backus on this day in 2007; amongst other things
he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because FORTRAN
has no syntax to speak of.
-- Dave
From lm at mcvoy.com Sun Mar 17 11:05:52 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 16 Mar 2019 18:05:52 -0700
Subject: [TUHS] In memoriam: John Backus
In-Reply-To: <alpine.BSF.2.21.9999.1903171159280.69634@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1903171159280.69634@aneurin.horsfall.org>
Message-ID: <20190317010552.GF1493@mcvoy.com>
Fortran is sort of yucky but as Clem has said, it continues to pay the bills.
That's some staying power.
I am with you that it is ironic that he gave us BNF as well. One wonders
if he did that as a result of doing Fortran.
On Sun, Mar 17, 2019 at 12:02:39PM +1100, Dave Horsfall wrote:
> We lost computer pioneer John Backus on this day in 2007; amongst other
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because
> FORTRAN has no syntax to speak of.
>
> -- Dave
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From bakul at bitblocks.com Sun Mar 17 12:16:32 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 16 Mar 2019 19:16:32 -0700
Subject: [TUHS] In memoriam: John Backus
In-Reply-To: Your message of "Sat, 16 Mar 2019 18:05:52 -0700."
<20190317010552.GF1493@mcvoy.com>
References: <alpine.BSF.2.21.9999.1903171159280.69634@aneurin.horsfall.org>
<20190317010552.GF1493@mcvoy.com>
Message-ID: <20190317021639.7E5D5156E40C@mail.bitblocks.com>
On Sat, 16 Mar 2019 18:05:52 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> Fortran is sort of yucky but as Clem has said, it continues to pay the bills.
> That's some staying power.
>
> I am with you that it is ironic that he gave us BNF as well. One wonders
> if he did that as a result of doing Fortran.
He did FP as a result of doing Fortran. In an interview by
Grady Booch he says
Well, it was just trying to be at a higher level so that
you didn't have to get into all those gory details and
stuff. Basically, the idea was to try to describe the
transformation that you wanted to take place, rather than
how to do it. It evolved very slowly and peculiarly.
But he said ultimately his effort failed because he couldn't see
how to deal with real time. Something he worked on for years.
> On Sun, Mar 17, 2019 at 12:02:39PM +1100, Dave Horsfall wrote:
> > We lost computer pioneer John Backus on this day in 2007; amongst other
> > things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because
> > FORTRAN has no syntax to speak of.
> >
> > -- Dave
From ralph at inputplus.co.uk Mon Mar 18 04:52:28 2019
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 17 Mar 2019 18:52:28 +0000
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com>
References: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com>
Message-ID: <20190317185228.06007214EF@orac.inputplus.co.uk>
Hi Steve,
> For a long time, California was viewed as hostile to phone companies,
> or at least AT&T, and I remember clearly people saying that Bell Labs
> would never have a location in CA as a result.
Here's what Larry Luckham told me in a private email that he's since
said could be copied to the list.
Larry wrote:
> Of the thousands of web pages that I have posted the one of the Bell
> Labs photos is the one that generates a dozen queries a year. Had no
> idea that would be the case when I posted it. The photos are also the
> most ripped off and reposted of anything I've ever done. But, to your
> points.
>
> The facility I set up in Oakland was temporary and for a specific
> experiment that ran for roughly 4 years. You may recall that
> beginning in the mid 60's the Bell System was experiencing a huge and
> unpredicted demand for 411, information operator services. The lead
> time to provide the trunking and other facilities for 411 operations
> was something like 25 years. The public facing response was the "$55
> million dollar phone call" ad campaign intended to point customers
> back to printed directories. The inward facing response was to figure
> out a way to handle each request for service faster so that the
> existing trunking and other facilities could meet the growing demand.
>
> At that time information operators relied on printed directories much
> the same as the customer's printed directory, except that theirs were
> loose leaf, reprinted monthly, and supplemented with a yellow daily
> addendum. They were also printed in a larger format to make reading
> easier. A division of the Labs called Business Information Systems
> Corp. out of the Raritan River Center was tasked with the project and
> given a very short timeline. A computer database and electronic
> display terminals driven by a very powerful search engine was the
> result. Special operator terminals were designed and built by Western
> Electric. The search engine was contracted out to Computer Corp. of
> America (CCA) which had been founded by some guys from Minsky's AI lab
> at MIT. Then the idea was to try it out in a live environment.
> The San Francisco Bay Area was selected as reasonably representative
> and that's where I came in. I was already managing the data center at
> the local Bell company, Pacific Telephone and Telegraph,
> San Francisco, so I was recruited to make it happen. I built the
> mainframe data center, PT&T provided space in an information operating
> room a few blocks away and CCA came onsite to do the programming.
>
> The testing ran roughly 4 years. I had moved on before it ended, but
> it was successful and was implanted, at least to some degree, but this
> shop was dismantled and everyone went home. Then technology did what
> it always does, it ran over everything and changed the world.
> Along came the PC, the Internet, smart phones, etc.
>
> It's been a very long time and I'm sure I've forgotten, or
> misremembered stuff, but that's kind of what I remember.
> Hope it sheds some light.
--
Cheers, Ralph.
From krewat at kilonet.net Mon Mar 18 05:39:37 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 17 Mar 2019 15:39:37 -0400
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <20190317185228.06007214EF@orac.inputplus.co.uk>
References: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com>
<20190317185228.06007214EF@orac.inputplus.co.uk>
Message-ID: <e4662baa-e275-905a-bc48-b9e619f4f865@kilonet.net>
This kind of telephone history always get my "phreak" up ;)
On 3/17/2019 2:52 PM, Ralph Corderoy wrote:
> Hi Steve,
>
>> For a long time, California was viewed as hostile to phone companies,
>> or at least AT&T, and I remember clearly people saying that Bell Labs
>> would never have a location in CA as a result.
> Here's what Larry Luckham told me in a private email that he's since
> said could be copied to the list.
>
> Larry wrote:
>> Of the thousands of web pages that I have posted the one of the Bell
>> Labs photos is the one that generates a dozen queries a year. Had no
>> idea that would be the case when I posted it. The photos are also the
>> most ripped off and reposted of anything I've ever done. But, to your
>> points.
>>
>> The facility I set up in Oakland was temporary and for a specific
>> experiment that ran for roughly 4 years. You may recall that
>> beginning in the mid 60's the Bell System was experiencing a huge and
>> unpredicted demand for 411, information operator services. The lead
>> time to provide the trunking and other facilities for 411 operations
>> was something like 25 years. The public facing response was the "$55
>> million dollar phone call" ad campaign intended to point customers
>> back to printed directories. The inward facing response was to figure
>> out a way to handle each request for service faster so that the
>> existing trunking and other facilities could meet the growing demand.
>>
>> At that time information operators relied on printed directories much
>> the same as the customer's printed directory, except that theirs were
>> loose leaf, reprinted monthly, and supplemented with a yellow daily
>> addendum. They were also printed in a larger format to make reading
>> easier. A division of the Labs called Business Information Systems
>> Corp. out of the Raritan River Center was tasked with the project and
>> given a very short timeline. A computer database and electronic
>> display terminals driven by a very powerful search engine was the
>> result. Special operator terminals were designed and built by Western
>> Electric. The search engine was contracted out to Computer Corp. of
>> America (CCA) which had been founded by some guys from Minsky's AI lab
>> at MIT. Then the idea was to try it out in a live environment.
>> The San Francisco Bay Area was selected as reasonably representative
>> and that's where I came in. I was already managing the data center at
>> the local Bell company, Pacific Telephone and Telegraph,
>> San Francisco, so I was recruited to make it happen. I built the
>> mainframe data center, PT&T provided space in an information operating
>> room a few blocks away and CCA came onsite to do the programming.
>>
>> The testing ran roughly 4 years. I had moved on before it ended, but
>> it was successful and was implanted, at least to some degree, but this
>> shop was dismantled and everyone went home. Then technology did what
>> it always does, it ran over everything and changed the world.
>> Along came the PC, the Internet, smart phones, etc.
>>
>> It's been a very long time and I'm sure I've forgotten, or
>> misremembered stuff, but that's kind of what I remember.
>> Hope it sheds some light.
From dugo at xs4all.nl Mon Mar 18 18:37:29 2019
From: dugo at xs4all.nl (Jacob Goense)
Date: Mon, 18 Mar 2019 09:37:29 +0100
Subject: [TUHS] Early DNS software
In-Reply-To: <63f58b28-f7cd-6f7e-db71-2b862ca97cdd@culm.net>
References: <63f58b28-f7cd-6f7e-db71-2b862ca97cdd@culm.net>
Message-ID: <eb12aef02f807c0acd70b26258a40907@xs4all.nl>
On 2019-03-16 23:20, Witold Krecicki wrote:
> I'm looking for old DNS software - servers, clients, libraries.
For TOPS-20, but here you are.
http://www.hactrn.net/hacks/jeeves/
http://www.hactrn.net/hacks/chives/
/Jacob
From jpl.jpl at gmail.com Tue Mar 19 01:04:31 2019
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Mon, 18 Mar 2019 11:04:31 -0400
Subject: [TUHS] Bell Labs data center in 1969/70
In-Reply-To: <e4662baa-e275-905a-bc48-b9e619f4f865@kilonet.net>
References: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com>
<20190317185228.06007214EF@orac.inputplus.co.uk>
<e4662baa-e275-905a-bc48-b9e619f4f865@kilonet.net>
Message-ID: <CAC0cEp-8c1Kp1SiBR8JXrwXvW-ae7jec588zGau+D=eWR1SnoQ@mail.gmail.com>
I can add an intolerable amount of detail to this story. I joined Business
Information Systems at the Labs in 1973, after completing my PhD at MIT. I
didn't like doing research: I wanted to write programs, not papers. (If I
had known what Bell Labs Research was about, I might well have applied
there). A small supervisory group, maybe 4 or 5 people, headed by someone
who had participated in the California test, was looking into
re-implementing the project. I don't know why the original didn't fly...
perhaps the way our effort died offers some insight.
"Information (411)" was a free service growing at an unsustainable rate.
The name was itself part of the problem. People would dial 411 to find out
about the weather. Changing the name to "Directory Assistance" helped. Just
talking about charging for calls helped even more. It cost AT&T nothing to
talk about it. But it was also clear that free paper-based search was
unsustainable. Operators got a daily "Frequently Called Numbers List
(FCNL)", things like hospitals and major retailers and IRS (in season).
Then there were the versions of the customer directories. These were
grouped by location, for which reason calls always started with "What City,
Please". If you didn't know the city, you were largely out of luck.
Operators couldn't plow through a stack of directories. The daily addenda
always struck me as bizarre. Operators were rated on call completion time,
so there wasn't much chance they'd take the time to check the addenda first
if the number showed up in the main directory. They probably served a
useful purpose for new numbers, which would be a logical reason for calling
411 to begin with. Typical calls were broken into three parts, getting the
information from the caller, searching for the number, and reporting the
number to the customer ("Oh, just a minute, I need to get a pencil.") Each
took about 10 seconds. Every second we could shave off a call was projected
to save the Bell System about a million dollars a year (back when 1 million
dollars was real money).
We had access to the directory information from the California trial, so we
did some analysis to suggest that 3 characters of Surname, plus 3 more of
City or of Street name, could be combined to produce a manageable list of
candidate numbers, and would shave several seconds off the search time.
(The approach would have mitigated the need to know City, and would have
consulted up-to-date information, which would have been regenerated daily).
A second phase, automated audio response to the customer, would have
eliminated the final phase of the calls. (It would also have eliminated
what little satisfaction the operators got from the job, which was already
well hated). It was easy to convince our department head that the project
was worth pursuing, and our director was also an easy convert. When we went
to our executive director, the final level of approval we needed to go
ahead, we expected an easy sell. Surprise! He was in charge of keeping
track of customer equipment, a huge and complicated effort. He told us, "In
Alabama, where I come from, we only hunt one rabbit at a time." He also
informed us that "micro-fiche had stolen the market". Our executive
director executed the fastest 180 I had ever seen, declaring that maybe the
project wasn't worth pursuing. I instantly lost all respect for him.
Two other notes. The executive director realized that by eliminating paper
directories, micro-fiche would save "the cost of glue for the binders". (I
and he were unaware that they were loose leaf, thanks, Ralph). He told my
supervisor to conduct a study of the cost of glue savings. My supervisor
(wisely) assigned the study to someone else in the group, knowing that I
would have walked before I wasted time on that. The executive director was
eventually promoted to "Vice President of Electronic Systems" at Western
Electric, possibly in recognition of his keen insight into the superiority
of micro-fiche over computers. With management like my director and
executive director, it's not too surprising that the original California
project folded.
On Sun, Mar 17, 2019 at 3:47 PM Arthur Krewat <krewat at kilonet.net> wrote:
> This kind of telephone history always get my "phreak" up ;)
>
>
> On 3/17/2019 2:52 PM, Ralph Corderoy wrote:
> > Hi Steve,
> >
> >> For a long time, California was viewed as hostile to phone companies,
> >> or at least AT&T, and I remember clearly people saying that Bell Labs
> >> would never have a location in CA as a result.
> > Here's what Larry Luckham told me in a private email that he's since
> > said could be copied to the list.
> >
> > Larry wrote:
> >> Of the thousands of web pages that I have posted the one of the Bell
> >> Labs photos is the one that generates a dozen queries a year. Had no
> >> idea that would be the case when I posted it. The photos are also the
> >> most ripped off and reposted of anything I've ever done. But, to your
> >> points.
> >>
> >> The facility I set up in Oakland was temporary and for a specific
> >> experiment that ran for roughly 4 years. You may recall that
> >> beginning in the mid 60's the Bell System was experiencing a huge and
> >> unpredicted demand for 411, information operator services. The lead
> >> time to provide the trunking and other facilities for 411 operations
> >> was something like 25 years. The public facing response was the "$55
> >> million dollar phone call" ad campaign intended to point customers
> >> back to printed directories. The inward facing response was to figure
> >> out a way to handle each request for service faster so that the
> >> existing trunking and other facilities could meet the growing demand.
> >>
> >> At that time information operators relied on printed directories much
> >> the same as the customer's printed directory, except that theirs were
> >> loose leaf, reprinted monthly, and supplemented with a yellow daily
> >> addendum. They were also printed in a larger format to make reading
> >> easier. A division of the Labs called Business Information Systems
> >> Corp. out of the Raritan River Center was tasked with the project and
> >> given a very short timeline. A computer database and electronic
> >> display terminals driven by a very powerful search engine was the
> >> result. Special operator terminals were designed and built by Western
> >> Electric. The search engine was contracted out to Computer Corp. of
> >> America (CCA) which had been founded by some guys from Minsky's AI lab
> >> at MIT. Then the idea was to try it out in a live environment.
> >> The San Francisco Bay Area was selected as reasonably representative
> >> and that's where I came in. I was already managing the data center at
> >> the local Bell company, Pacific Telephone and Telegraph,
> >> San Francisco, so I was recruited to make it happen. I built the
> >> mainframe data center, PT&T provided space in an information operating
> >> room a few blocks away and CCA came onsite to do the programming.
> >>
> >> The testing ran roughly 4 years. I had moved on before it ended, but
> >> it was successful and was implanted, at least to some degree, but this
> >> shop was dismantled and everyone went home. Then technology did what
> >> it always does, it ran over everything and changed the world.
> >> Along came the PC, the Internet, smart phones, etc.
> >>
> >> It's been a very long time and I'm sure I've forgotten, or
> >> misremembered stuff, but that's kind of what I remember.
> >> Hope it sheds some light.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190318/f705bd2e/attachment.html>
From dave at horsfall.org Thu Mar 21 09:29:54 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Mar 2019 10:29:54 +1100 (EST)
Subject: [TUHS] Happy birthday, NetBSD!
Message-ID: <alpine.BSF.2.21.9999.1903211026350.95755@aneurin.horsfall.org>
According to my (possibly inaccurate) notes:
NetBSD checked in 1993
Message-ID: <alpine.NEB.2.20.1803211456560.25928 at t1.m.reedmedia.net>
Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd
http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
"Today is commonly considered the birthday of NetBSD. As far as I know,
it is the oldest continuously-maintained complete open source operating
system. (It predates Slackware Linux, FreeBSD, and Debian Linux by some
months.)"
-- Dave
From ron at ronnatalie.com Fri Mar 22 04:01:36 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Thu, 21 Mar 2019 14:01:36 -0400
Subject: [TUHS] Another old DMR and Brian Redman story
Message-ID: <124301d4e010$205dbe20$61193a60$@ronnatalie.com>
Years ago just before one of the USENIX meetings in Atlanta Dennis made some
joke comment that nobody had ever asked for a plaster cast of his genitals.
A bunch of us thought it would be fun at the conference to hand out genital
casting kits to Dennis and certain others of note. We ran down to a
local art supply store and bought some plaster and portioned out into zone
ziplock bags We added some paper cups to use for molds and wooded sticks
to mix with. We needed a release agent. Vaseline would work, but I
couldn't figure out how we'd get small portions (I couldn't use the ziplock
bag idea practically). Fortunately, there was a little gift shop in the
hotel lobby and they had these travel size jars. Perfect.
Now the interesting thing was that concurrent with USENIX was the Southern
Baptist Conference meetings (this led to some odd events at local
restaurants).
Anyhow, I walk up to the cashier and plop down ten jars of Vaseline.
She looks at me and says, "I guess y'all aren't with the Baptists."
Oddly, most recipients took the gift in good spirit but Redman had a fit for
some reason. Babette suggested perhaps we made the kit too large for him.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190321/ea5f89c5/attachment.html>
From krewat at kilonet.net Fri Mar 22 04:42:04 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 21 Mar 2019 14:42:04 -0400
Subject: [TUHS] Another old DMR and Brian Redman story
In-Reply-To: <124301d4e010$205dbe20$61193a60$@ronnatalie.com>
References: <124301d4e010$205dbe20$61193a60$@ronnatalie.com>
Message-ID: <0a580260-171b-f41a-5743-8a70fa748cb8@kilonet.net>
On 3/21/2019 2:01 PM, ron at ronnatalie.com wrote:
>
> She looks at me and says, “I guess y’all aren’t with the Baptists.â€
>
Thank you for a huge laugh on a day when I could use one ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190321/238246c0/attachment.html>
From imp at bsdimp.com Fri Mar 22 04:56:30 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 21 Mar 2019 12:56:30 -0600
Subject: [TUHS] Another old DMR and Brian Redman story
In-Reply-To: <0a580260-171b-f41a-5743-8a70fa748cb8@kilonet.net>
References: <124301d4e010$205dbe20$61193a60$@ronnatalie.com>
<0a580260-171b-f41a-5743-8a70fa748cb8@kilonet.net>
Message-ID: <CANCZdfqp_9KxSTtVc1EO+4auDSi_-b2PPd0YekP0a-OWEz2z+g@mail.gmail.com>
On Thu, Mar 21, 2019 at 12:50 PM Arthur Krewat <krewat at kilonet.net> wrote:
> On 3/21/2019 2:01 PM, ron at ronnatalie.com wrote:
>
> She looks at me and says, “I guess y’all aren’t with the Baptists.â€
>
>
> Thank you for a huge laugh on a day when I could use one ;)
>
Yes.That was awesome...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190321/dd05fdfd/attachment.html>
From reed at reedmedia.net Sun Mar 24 03:50:55 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Sat, 23 Mar 2019 12:50:55 -0500 (CDT)
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <201903102253.x2AMrks8039290@ducky.net>
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
Message-ID: <alpine.NEB.2.21.1903231240210.16654@t1.m.reedmedia.net>
On Sun, 10 Mar 2019, Mike Haertel wrote:
> >http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
> >just noticed...
> That tape image is has 3 files in it:
...
What tool did you use to extract or look at this tape image?
(I tried a v6 ar, and a modern NetBSD ar, cpio, tar, and restore. Maybe
I need an ar or tar from ~1981 ... file(1) reports it as a Maple help
database.)
From lars at nocrew.org Sun Mar 24 14:19:13 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 24 Mar 2019 04:19:13 +0000
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: <alpine.NEB.2.21.1903231240210.16654@t1.m.reedmedia.net>
(reed@reedmedia.net's message of "Sat, 23 Mar 2019 12:50:55 -0500
(CDT)")
References: <201903100731.x2A7VZJF033832@ducky.net>
<CACCFpdzUEpKbm1nKkLs-bkEWYPkry4kEGbLwHKKR+gAeM19_sw@mail.gmail.com>
<7wpnqzj7tr.fsf@junk.nocrew.org>
<CANCZdfo4FF5FfkSrDoj-BAaEhqtmzLAWbpZb=HXx3_J4X62EnQ@mail.gmail.com>
<201903102253.x2AMrks8039290@ducky.net>
<alpine.NEB.2.21.1903231240210.16654@t1.m.reedmedia.net>
Message-ID: <7w7ecoyke6.fsf@junk.nocrew.org>
reed wrote:
> Mike Haertel wrote:
>> >http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz which I
>> >just noticed...
>> That tape image is has 3 files in it:
>
> What tool did you use to extract or look at this tape image?
"taperead" in http://github.com/brouhaha/tapeutils can extract files
from a tape image.
From richard at inf.ed.ac.uk Tue Mar 26 03:19:17 2019
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Mon, 25 Mar 2019 17:19:17 +0000 (GMT)
Subject: [TUHS] a possible source for 4.1BSD tapes
In-Reply-To: Lars Brinkhoff's message of Sun, 24 Mar 2019 04:19:13 +0000
Message-ID: <20190325171917.C193C24E8186@macaroni.inf.ed.ac.uk>
> "taperead" in http://github.com/brouhaha/tapeutils can extract files
> from a tape image.
The format is very simple: a 32-bit little-endian record length,
followed by that many bytes, followed by the length again for
integrity checking. A record length of zero is a file mark.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.