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: References: 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. 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” :-). -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 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: 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 wrote: > On Sat, 09 Mar 2019 14:19:43 -0500 Doug McIlroy > 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: 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: 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: >Date: Sat, 9 Mar 2019 15:29:11 -0700 >From: "Nelson H. F. Beebe" >To: The Eunuchs Hysterical Society >Subject: Re: [TUHS] Failing Memory of an Algol Based System from years ago >Message-ID: ... 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." References: Message-ID: <20190310051618.4AEF1156E40C@mail.bitblocks.com> On Sat, 09 Mar 2019 15:29:11 -0700 "Nelson H. F. Beebe" 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 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: On Sun, Mar 10, 2019 at 6:52 PM 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, > 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: (Nigel Williams's message of "Sun, 10 Mar 2019 10:24:53 +1100") References: <201903100731.x2A7VZJF033832@ducky.net> 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 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: On Sun, Mar 10, 2019 at 1:55 PM wrote: > Mike Haertel 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: 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> <7wpnqzj7tr.fsf@junk.nocrew.org> Message-ID: On Sun, Mar 10, 2019 at 5:49 AM Lars Brinkhoff 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: 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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> 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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> Message-ID: 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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> 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: >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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> Message-ID: 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" 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: 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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> 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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com> Message-ID: 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 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: 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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> 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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com> Message-ID: 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. 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: References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com> Message-ID: 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" 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: 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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> <201903111728.x2BHSNqG045196@ducky.net> <20190311173845.GU31834@mcvoy.com> Message-ID: <201903121244.x2CCi99p020772@freefriends.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 (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: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: <201903121717.x2CHHnET014771@darkstar.fourwinds.com> On Tue, Mar 12, 2019 at 12:04 PM Dan Cross 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: <201903121717.x2CHHnET014771@darkstar.fourwinds.com> Message-ID: Jon - Dept Head vs. peon maybe ;-) ᐧ On Tue, Mar 12, 2019 at 1:24 PM Jon Steinhart wrote: > On Tue, Mar 12, 2019 at 12:04 PM Dan Cross 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: 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: References: <201903121717.x2CHHnET014771@darkstar.fourwinds.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: References: Message-ID: On 3/12/19, 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. > 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: 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 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: References: 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: 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: References: Message-ID: 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: References: Message-ID: <20190313084108.GF87064@server.rulingia.com> On 2019-Mar-13 12:37:47 +1100, Dave Horsfall 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: 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: 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 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: 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: <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 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: References: <201903131325.x2DDPds4028941@coolidge.cs.Dartmouth.EDU> Message-ID: 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 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 > 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: 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: 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" To:"Doug McIlroy" Cc: 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 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: 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: 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: References: 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: <20190317010552.GF1493@mcvoy.com> Message-ID: <20190317021639.7E5D5156E40C@mail.bitblocks.com> On Sat, 16 Mar 2019 18:05:52 -0700 Larry McVoy 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: 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: 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: References: <837973bfe43d298115dd0429f0aa514a07499fd7@webmail.yaccman.com> <20190317185228.06007214EF@orac.inputplus.co.uk> Message-ID: 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 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: 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: According to my (possibly inaccurate) notes: NetBSD checked in 1993 Message-ID: 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: 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: 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: On Thu, Mar 21, 2019 at 12:50 PM Arthur Krewat 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: 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> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.net> Message-ID: 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: (reed@reedmedia.net's message of "Sat, 23 Mar 2019 12:50:55 -0500 (CDT)") References: <201903100731.x2A7VZJF033832@ducky.net> <7wpnqzj7tr.fsf@junk.nocrew.org> <201903102253.x2AMrks8039290@ducky.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.