From tuhs at tuhs.org Thu Jan 1 01:26:50 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Wed, 31 Dec 2025 16:26:50 +0100 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: And i gave a lightning talk at 39c3: https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 aap On 20/12/25, Angelo Papenhoff via TUHS wrote: > It's booting too! added info to the readme. > > =uboot > k > unix > > login: root > # ls > bin > dev > etc > lib > mnt > tmp > unix > usr > # > > > aap > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > I extracted it: http://squoze.net/UNIX/v4/ > > > > aap > > > > On 19/12/25, Matt Day via TUHS wrote: > > > Rob Ricci updated today on his Mastodon page: > > > > The attempt to read the UNIX V4 tape is underway! > > > > I'm told "there is data" but I honestly don't know what that means yet. > > > -- https://discuss.systems/@ricci/115747843169814700 > > > The process is being filmed by a TV news crew and some footage is already > > > available. > > > > > > > > > On Thu, Nov 6, 2025 at 3:42 PM Rob Pike via TUHS wrote: > > > > > > > https://phanpy.social/#/hachyderm.io/s/115504720323483804 > > > > > > > > From mastodon: > > > > > > > > > > > > Rob Ricci > > > > ricci at discuss.systems > > > > > > > > While cleaning a storage room, our staff found this tape containing #UNIX > > > > v4 from Bell Labs, circa 1973 > > > > > > > > Apparently no other complete copies are known to exist: > > > > gunkies.org/wiki/UNIX_Fourth_E > > > > > > > > > > > > We have arranged to deliver it to the Computer History Museum > > > > From tuhs at tuhs.org Thu Jan 1 01:33:06 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 31 Dec 2025 08:33:06 -0700 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: Sweet talk. Thanks for sharing. Warner On Wed, Dec 31, 2025, 8:27 AM Angelo Papenhoff via TUHS wrote: > And i gave a lightning talk at 39c3: > https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 > > aap > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > It's booting too! added info to the readme. > > > > =uboot > > k > > unix > > > > login: root > > # ls > > bin > > dev > > etc > > lib > > mnt > > tmp > > unix > > usr > > # > > > > > > aap > > > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > > I extracted it: http://squoze.net/UNIX/v4/ > > > > > > aap > > > > > > On 19/12/25, Matt Day via TUHS wrote: > > > > Rob Ricci updated today on his Mastodon page: > > > > > The attempt to read the UNIX V4 tape is underway! > > > > > I'm told "there is data" but I honestly don't know what that means > yet. > > > > -- https://discuss.systems/@ricci/115747843169814700 > > > > The process is being filmed by a TV news crew and some footage is > already > > > > available. > > > > > > > > > > > > On Thu, Nov 6, 2025 at 3:42 PM Rob Pike via TUHS > wrote: > > > > > > > > > https://phanpy.social/#/hachyderm.io/s/115504720323483804 > > > > > > > > > > From mastodon: > > > > > > > > > > > > > > > Rob Ricci > > > > > ricci at discuss.systems > > > > > > > > > > While cleaning a storage room, our staff found this tape > containing #UNIX > > > > > v4 from Bell Labs, circa 1973 > > > > > > > > > > Apparently no other complete copies are known to exist: > > > > > gunkies.org/wiki/UNIX_Fourth_E > > > > > > > > > > > > > > > We have arranged to deliver it to the Computer History Museum > > > > > > From tuhs at tuhs.org Thu Jan 1 08:01:38 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 31 Dec 2025 22:01:38 +0000 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: <3Pz-Il9LcgBA9p70FPQFM2N8dGdwdQ8LH2PtHbHf5-RvaT2JjQ-LmNcey7neDQuJxrWOedl6P4nTkSSLO6mhUQcsDzFPAIXIRM-0i5qu00Y=@protonmail.ch> Great talk, Angelo, Shame it had to be only 5 minutes and not 5 hours. That would freak me out, going up on stage and knowing I only had 300 seconds to make some kind of sense. Thank you also for the links, at the end of your talk, they were super useful. Frohes neues Jahr! / Joyous New Year to everyone! Cameron -------- Original Message -------- On Wednesday, 12/31/25 at 15:27 Angelo Papenhoff via TUHS wrote: And i gave a lightning talk at 39c3: https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 aap From tuhs at tuhs.org Fri Jan 2 09:27:34 2026 From: tuhs at tuhs.org (=?utf-8?q?Martin_Schr=C3=B6der_via_TUHS?=) Date: Fri, 2 Jan 2026 00:27:34 +0100 Subject: [TUHS] HP-UX is EOL Message-ID: Hi, happy new year. HP-UX went EOL on 2025-12-31: https://www.osnews.com/story/144094/hp-ux-hits-end-of-life-today-and-im-sad/ Best Martin From tuhs at tuhs.org Fri Jan 2 19:14:01 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 2 Jan 2026 20:14:01 +1100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS wrote: > On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: > > First image is V6 (+BTL Lions Commentary) > > I thought that Lions’ Commentary wasn’t distributed after BTL took over distribution? > Do you know whether there’s a scan of that version anywhere? > > The BTL takeover was announced in the March 1978 issue of ;login:. > https://archive.org/details/login_march-1978/page/n1/mode/1up > > Thalia Licensees were allowed to have one copy from BTL. https://archive.org/details/login_nov84_issue/page/n25/mode/1up https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html From tuhs at tuhs.org Sat Jan 3 04:39:41 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Fri, 2 Jan 2026 10:39:41 -0800 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: Message-ID: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> May I suggest that the following is a good read for V6 internals. Without source, and a well written description of functions. David https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up UNIX Program Description : Bell Telephone Laboratiories, Incorporated : Free Download, Borrow, and Streaming : Internet Archive archive.org > On Jan 2, 2026, at 1:14 AM, Jonathan Gray via TUHS wrote: > > On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS wrote: >> On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: >>> First image is V6 (+BTL Lions Commentary) >> >> I thought that Lions’ Commentary wasn’t distributed after BTL took over distribution? >> Do you know whether there’s a scan of that version anywhere? >> >> The BTL takeover was announced in the March 1978 issue of ;login:. >> https://archive.org/details/login_march-1978/page/n1/mode/1up >> >> Thalia > > Licensees were allowed to have one copy from BTL. > > https://archive.org/details/login_nov84_issue/page/n25/mode/1up > https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html > https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html From tuhs at tuhs.org Sat Jan 3 04:52:50 2026 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Fri, 2 Jan 2026 11:52:50 -0700 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: Thanks, that's actually very interesting. One the second page, update() is described as including a lock to prevent it being called a second time before the first call is completed. That explained to me the lore I picked up at UC Berkeley about typing "sync;sync". I wondered why it was necessary to use sync twice, and the answer is that it's not: the first invocation appears to return immediately but invoked sync the second time waits until the first finishes--so you can tell updating of inodes and superblocks has completed. I'd heard that VAX systems running Unix were slow enough that experienced users could tell the system was becoming unstable and type sync. There was also a 'sync' user account, so typing 'sync' as a username would fire off update(). Rik On Fri, Jan 2, 2026 at 11:40 AM David Barto via TUHS wrote: > May I suggest that the following is a good read for V6 internals. Without > source, and a well written description of functions. > > David > > > https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up >  > UNIX Program Description : Bell Telephone Laboratiories, Incorporated : > Free Download, Borrow, and Streaming : Internet Archive > archive.org > > > > On Jan 2, 2026, at 1:14 AM, Jonathan Gray via TUHS > wrote: > > > > On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS > wrote: > >> On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: > >>> First image is V6 (+BTL Lions Commentary) > >> > >> I thought that Lions’ Commentary wasn’t distributed after BTL took over > distribution? > >> Do you know whether there’s a scan of that version anywhere? > >> > >> The BTL takeover was announced in the March 1978 issue of ;login:. > >> https://archive.org/details/login_march-1978/page/n1/mode/1up > >> > >> Thalia > > > > Licensees were allowed to have one copy from BTL. > > > > https://archive.org/details/login_nov84_issue/page/n25/mode/1up > > https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html > > https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html > > From tuhs at tuhs.org Sat Jan 3 05:33:11 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 02 Jan 2026 19:33:11 +0000 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: On Friday, January 2nd, 2026 at 10:53, Rik Farrow via TUHS wrote: > Thanks, that's actually very interesting. One the second page, update() is > described as including a lock to prevent it being called a second time > before the first call is completed. That explained to me the lore I picked > up at UC Berkeley about typing "sync;sync". I wondered why it was necessary > to use sync twice, and the answer is that it's not: the first invocation > appears to return immediately but invoked sync the second time waits until > the first finishes--so you can tell updating of inodes and superblocks has > completed. > > Rik I've seen this sort of thing in plenty of places, an operation that is gated by itself, run it twice in case the gate was closed the first time or otherwise you need to be sure the first one finished. On the NES, this is done to synchronize the PPU chip in software by awaiting v blank twice. The first is actually to erase any potential spurious interrupt flag and the second to then poll knowing you started with the flag down. Is there a name for this? I want to just call this sempahoring but it may be that a binary semaphore is a case of this larger thing. > On Fri, Jan 2, 2026 at 11:40 AM David Barto via TUHS tuhs at tuhs.org wrote: > > > May I suggest that the following is a good read for V6 internals. Without > > source, and a well written description of functions. > > > > David > > > > https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up > >  > > UNIX Program Description : Bell Telephone Laboratiories, Incorporated : > > Free Download, Borrow, and Streaming : Internet Archive > > archive.org > > For those following along at home, this specifically describes the USG Program Generic II kernel, so may have slight differences regarding stock V6 (and/or stock PDP-11/45 C kernel ). Does anyone on-list know the providence of this document by the way? The scan edges indicate it came from a comb-bound volume, I'd be curious if these were the only pages, if that volume contained other UNIX stuff, and especially if this implies other comb-binding of manuals at the time. Reason I ask is I seem to recall reading a post here or on a Usenet list by Ted Dolotta I believe detailing that the Release 3.0 manuals got approval to be printed on the same comb-bound stock used for internal phone directories, and that it was the first time USG had "published" a manual so formally. Seeing the comb-binding holes in the scan casts some doubt on this. - Matt G. From tuhs at tuhs.org Sat Jan 3 06:33:51 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 2 Jan 2026 15:33:51 -0500 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: below On Fri, Jan 2, 2026 at 2:33 PM segaloco via TUHS wrote: > ... > > > For those following along at home, this specifically describes the USG > Program Generic II kernel, I believe (as I was told at the time the kernel that Armando Stettner and the late Ted Kowalski worked on at Summit in the Unix Support Group (USG) was supposed to be called UNIX/TS. There is a note I wrote in pencil in my copy, to use this over Lion's in the future. Ted always talked about UNIX/TS as if it were going to be the official thing. > so may have slight differences regarding stock V6 (and/or stock PDP-11/45 > C kernel ). And V7 for that matter. Without looking at it again, my >>memory<< is that this document defines the kernel that Research took back. There was a push tio to unify the different flavors (CB/Unix, PWB, Risner's kernel, et al). USG was chartered by folks fairly high up in the AT&T food chain (similarly to how CSRG was chartered by DARPA); to create and support UNIX for the Bell System at large. I always understood that the action of importing the Summit kernel at that time was that Al Arms was starting the V7 licensing. As I understand it, Dennis did not want to be the "release engineer" for V7 (I believe srb put it together), but since V7 was going to go outside of Bell to the "general population" in the CS research community, it seemed like that was a good time to take back some it (by V8 they stopped trying and Research and Summit diverged). > Does anyone on-list know the providence of this document by the way? It was written at USG. I do not know by whom. That would be a good question to ask aps, as he and Ted were officemates at Summit. He might not. I have no idea if they had professional tech writers or if it was a new "product" from USG for the operating companies. BTW: the scan that archive.org has is missing at least the last 6 pages. > The scan edges indicate it came from a comb-bound volume, I'd be curious > if these were the only pages, Ted's copy was bound withg both holes the funky 2 pin standard AT&T binder, as well as industry standard 3 hole. > if that volume contained other UNIX stuff, no > and especially if this implies other comb-binding of manuals at the time. > GBC-style binding was used for things like the core UNIX manual set. In fact, Brian Redman (*a.k.a.* ber) took his 8.5 x 11 master for 4.1BSD, the same printer that USG was using, to make the first set of 6" x 9" GBC-bound BSD manuals. I've forgotten the details, but USENIX eventually took over get those printed (and offering them for sale to USENIX members). By the time of 4.3BSD, it had become a standard practice. > > Reason I ask is I seem to recall reading a post here or on a Usenet list > by Ted Dolotta I believe detailing that the Release 3.0 manuals got > approval to be printed on the same comb-bound stock used for internal phone > directories, and that it was the first time USG had "published" a manual so > formally. Hmmm - I'm not so sure of this. I thought PWB 1 and PWB 2 had 6" x 9" GBC-bound. Since Ted was part of PWB, it is likely that PWB 1.0, which Dolotta created, was the 6" x 9" GBC-bound "standard" for UNIX. I do know this: when 4.4 BSD was released, USENIX transferred the publishing task over to Tim O'Reilly. I remember having a conversation with him about the GBC binding. If he continued it, it would significantly increase the cost of each book, compared with the perfect-binding scheme he would eventually use for his 4.4BSD series. > Seeing the comb-binding holes in the scan casts some doubt on this. > I suspect someone xeroxgraphicly copied the original and put the result through a GBC punch From tuhs at tuhs.org Sat Jan 3 06:42:53 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Fri, 2 Jan 2026 12:42:53 -0800 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS wrote: > > BTW: the scan that archive.org has is missing at least the last 6 pages. Does anyone know/have any idea where a complete version of this document may be? I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” David From tuhs at tuhs.org Sat Jan 3 06:56:31 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 02 Jan 2026 20:56:31 +0000 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: On Friday, January 2nd, 2026 at 12:43, David Barto via TUHS wrote: > > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS tuhs at tuhs.org wrote: > > > > BTW: the scan that archive.org http://archive.org/ has is missing at least the last 6 pages. > > > Does anyone know/have any idea where a complete version of this document may be? > > I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” > > David This same document is in the archive: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf Unfortunately it appears to be the same scan missing the tail end. Looks like Lubomir Rintel did a troff restoration: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-troffsrc.tar.gz Given that this is based on the scan, it is also incomplete. - Matt G. From tuhs at tuhs.org Sat Jan 3 08:04:49 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 2 Jan 2026 16:04:49 -0600 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: <1b110c8e-426c-4e92-8a05-93e3f663bd6e@gmail.com> old thread - mel might have the physical copy? Warren Toomey > wrote: >/All, I've just received the following e-mail. I am not able to physically />/get these documents, but if you are interested in them, feel free to contact />/Mel yourself. />//>/Cheers, Warren />//>/----- Forwarded message from meljmel-unix at yahoo.com ----- />//>/Date: Wed, 23 May 2018 13:30:09 +1000 (AEST) />/From: meljmel-unix at yahoo.com />/To: Warren T > />/Subject: Old Unix manuals, TMs, etc />//>//>/Hi, />//>/I started working at Bell Labs in 1971 and although />/not in the computing science research department, I />/was in another department down the hall. As a result />/I have many old Unix manuals, TM's and other papers />/that I wish to dispose of. I found you when I did a />/search to see if there was anyone who might want them. />/Appended below is a list of what I have. If you are />/interested in any of it or know who else might be, please />/let me know. If I can't find anyone to take them I guess />/I'll just throw them out. />//>/Mel />/meljmel-unix at yahoo.com />//>/========== />/These are the old Unix Manuals I have: />//>/UNIX PROGRAMMER'S MANUAL />/Program Generic PG-1C300 Issue 2 />/Published by the UNIX Support Group />/January, 1976 />//>/UNIX PROGRAMMER'S MANUAL />/Program Generic PG-1C300 Issue 3 />/Published by the UNIX Support Group />/March, 1977/ On 1/2/26 14:56, segaloco via TUHS wrote: > On Friday, January 2nd, 2026 at 12:43, David Barto via TUHS wrote: > >>> On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHStuhs at tuhs.org wrote: >>> >>> BTW: the scan that archive.orghttp://archive.org/ has is missing at least the last 6 pages. >> >> Does anyone know/have any idea where a complete version of this document may be? >> >> I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” >> >> David > This same document is in the archive: > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > Unfortunately it appears to be the same scan missing the tail end. > Looks like Lubomir Rintel did a troff restoration: > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-troffsrc.tar.gz > > Given that this is based on the scan, it is also incomplete. > > - Matt G. From tuhs at tuhs.org Sat Jan 3 09:32:06 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Fri, 2 Jan 2026 15:32:06 -0800 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: References: Message-ID: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> On 12/29/25 13:10, Clem Cole via TUHS wrote: > - Initial Internal Release: Some sources indicate an initial release in > 1980. This was likely a pre-commercial version known internally by names > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > - Official Commercial Release: AT&T formally announced System III in > late 1981, and it was first made publicly (commercially) > available outside > of the Bell System in 1982. My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My understanding is that this eventually turned into System III. > AT&T's UNIX System V had major releases starting with the initial System V 1983, My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell Labs Division 452 (the computer centers). I understand this turned into System V. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com From tuhs at tuhs.org Sat Jan 3 10:18:32 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 2 Jan 2026 17:18:32 -0700 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> References: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> Message-ID: On Fri, Jan 2, 2026 at 4:32 PM Mary Ann Horton via TUHS wrote: > On 12/29/25 13:10, Clem Cole via TUHS wrote: > > - Initial Internal Release: Some sources indicate an initial release in > > 1980. This was likely a pre-commercial version known internally > by names > > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > > - Official Commercial Release: AT&T formally announced System III > in > > late 1981, and it was first made publicly (commercially) > > available outside > > of the Bell System in 1982. > My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, > olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it > (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My > understanding is that this eventually turned into System III. > > AT&T's UNIX System V had major releases starting with the initial System > V 1983, > > My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell > Labs Division 452 (the computer centers). I understand this turned into > System V. > 4.1BSD was July 1981 4.1aBSD was April 1982 4.1cBSD was Late 1982 This leaves us with Kirk's story lining up in two possible ways: 1. If the reason is System V, then the dates line up well to 4.1->5.0 plans changing to 4.1->4.2. 2. If the reason is Unix 5.0 plans that were hatched when 3.0 was released, then it does line up with the 4->5BSD plans vs 4BSD -> 4.1BSD actual. I'll see if I can get a peek at the dates of the printouts next time I'm at Kirk's house which would tell us for sure. He's quite sure the reason was AT&T. I see now that I didn't ask this detail... I'll follow up with him. Warner From tuhs at tuhs.org Sat Jan 3 11:49:59 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 2 Jan 2026 20:49:59 -0500 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: On Fri, Jan 2, 2026 at 3:43 PM David Barto wrote: > > > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS wrote: > > BTW: the scan that archive.org has is missing at least the last 6 pages. > > > Does anyone know/have any idea where a complete version of this document > may be? > Yes, sitting in a binder in front of me. > > I’ve had this one for a while, incomplete though it may be. A complete > version would be "nice to have.” > > David > > From tuhs at tuhs.org Sat Jan 3 15:56:01 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 03 Jan 2026 05:56:01 +0000 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: References: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> Message-ID: On Friday, January 2nd, 2026 at 16:18, Warner Losh via TUHS wrote: > On Fri, Jan 2, 2026 at 4:32 PM Mary Ann Horton via TUHS tuhs at tuhs.org > > wrote: > > > On 12/29/25 13:10, Clem Cole via TUHS wrote: > > > > > - Initial Internal Release: Some sources indicate an initial release in > > > 1980. This was likely a pre-commercial version known internally > > > by names > > > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > > > - Official Commercial Release: AT&T formally announced System III > > > in > > > late 1981, and it was first made publicly (commercially) > > > available outside > > > of the Bell System in 1982. > > > My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, > > > olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it > > > (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My > > > understanding is that this eventually turned into System III. > > > AT&T's UNIX System V had major releases starting with the initial System > > > V 1983, > > > > My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell > > Labs Division 452 (the computer centers). I understand this turned into > > System V. > > > 4.1BSD was July 1981 > 4.1aBSD was April 1982 > 4.1cBSD was Late 1982 > > This leaves us with Kirk's story lining up in two possible ways: > 1. If the reason is System V, then the dates line up well to 4.1->5.0 plans > > changing to 4.1->4.2. > > 2. If the reason is Unix 5.0 plans that were hatched when 3.0 was released, > then it does line up with the 4->5BSD plans vs 4BSD -> 4.1BSD actual. > > > I'll see if I can get a peek at the dates of the printouts next time I'm at > Kirk's > house which would tell us for sure. He's quite sure the reason was AT&T. > I see now that I didn't ask this detail... I'll follow up with him. > > Warner Bill Joy gives November 1980 as the distribution date of 4BSD, and then April 1981 as the date of the initial 4.1BSD revision[1]. This is the earliest date I can find given for anything named 4.1BSD. - Matt G. [1] - https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man0/changes.4-81 From tuhs at tuhs.org Sun Jan 4 13:09:18 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Sat, 3 Jan 2026 22:09:18 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: I don't remember how it was decided that the time had come for another edition. I volunteered to edit volume 1 of the manual. Andrew Hume took on volume 2, which ultimately split into 2A and 2B. We exercised some judgment about what should be in userland, wheedled contributions to the manual out of folks, and prodded fixes that would minimize the man-page BUGS sections. Maybe we rated the title of release provocateurs. As always in Unix, no one had ultimate authority. The most vivid example in v7 is that I didn't want uucp with its known security holes, but Mike Lesk could not be persuaded to work on closing them. It finally was included on the premise that it posed no new danger since it was already in widespread use. ---------- Forwarded message --------- From: Clem Cole Date: Sat, Jan 3, 2026 at 11:08 AM Subject: Re: V7 RE To: srb gmail Cc: Douglas McIlroy Thank you. Fair enough. I was sure you had been heavily involved. Doug, your memory? On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > "As I understand it, Dennis did not want to be the "release > engineer" for V7 (I believe srb put it together), but since V7 was going to > go outside of Bell to the "general population" in the CS research > community, it seemed like that was a good time to take back some it (by V8 > they stopped trying and Research and Summit diverged)." > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to make sure the release tree had > src, bin and man pages and some other cleanup and checks. Doug I think was the official RE but he would > probably remember better than me. > > Steve From tuhs at tuhs.org Sun Jan 4 13:21:42 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 3 Jan 2026 22:21:42 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: Thank you. Funny your story about uucp. In the end, it was probably the most significant new tool out side of the Bell system that came from Seventh Edition. Clem Sent from a handheld expect more typos than usual On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS wrote: > I don't remember how it was decided that the time had come for another > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > took on volume 2, which ultimately split into 2A and 2B. We exercised > some judgment about what should be in userland, wheedled contributions > to the manual out of folks, and prodded fixes that would minimize the > man-page BUGS sections. Maybe we rated the title of release > provocateurs. > > As always in Unix, no one had ultimate authority. The most vivid > example in v7 is that I didn't want uucp with its known security > holes, but Mike Lesk could not be persuaded to work on closing them. > It finally was included on the premise that it posed no new danger > since it was already in widespread use. > > ---------- Forwarded message --------- > From: Clem Cole > Date: Sat, Jan 3, 2026 at 11:08 AM > Subject: Re: V7 RE > To: srb gmail > Cc: Douglas McIlroy > > > Thank you. Fair enough. I was sure you had been heavily involved. > Doug, your memory? > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > "As I understand it, Dennis did not want to be the "release > > engineer" for V7 (I believe srb put it together), but since V7 was going > to > > go outside of Bell to the "general population" in the CS research > > community, it seemed like that was a good time to take back some it (by > V8 > > they stopped trying and Research and Summit diverged)." > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > make sure the release tree had > > src, bin and man pages and some other cleanup and checks. Doug I think > was the official RE but he would > > probably remember better than me. > > > > Steve > From tuhs at tuhs.org Sun Jan 4 14:41:50 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 4 Jan 2026 15:41:50 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > Also, while looking for the vi cards, I turned up two wonderful artifacts > that I'll try to get scanned and added to TUHS at some point. When you > purchased V7 from AT&T, you got one copy of the printed docs and a small > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > similar but different. Was the first edition also distributed to V6 licensees? -- UNIX Reference Card - First Edition L. L. Cherry September, 1975 A handy guide to UNIX commands and syntax. mentioned in: tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 v10/doc/bibliog.a unpm-docs -- UNIX Reference Card distributed by Computing Information Service BELL LABORATORIES Murray Hill, N. J. 07974 compiled by Lorinda Cherry Second Edition, March 1979 incomplete scan, some pages missing: http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm CHM has a copy, not currently scanned https://www.computerhistory.org/collections/catalog/102632799/ spiral bound https://www.flickr.com/photos/n1kdo/53136436051 comb bound https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Sun Jan 4 18:28:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 04 Jan 2026 08:28:41 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > that I'll try to get scanned and added to TUHS at some point. When you > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- > > UNIX Reference Card > distributed by > Computing Information Service > BELL LABORATORIES > Murray Hill, N. J. 07974 > compiled by Lorinda Cherry > Second Edition, March 1979 > > incomplete scan, some pages missing: > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > CHM has a copy, not currently scanned > https://www.computerhistory.org/collections/catalog/102632799/ > > spiral bound > https://www.flickr.com/photos/n1kdo/53136436051 > comb bound > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 Ah shoot, I actually have an unknown-generations-removed photocopy of this V6 flipbook, I should scan that. For the record, among the Release 4.0 documents I scanned for Arnold Robbins is that release's issue of this flipbook (I think they're genetically linked anyway): https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Reference_Guide.pdf - Matt G. From tuhs at tuhs.org Mon Jan 5 01:17:52 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Sun, 4 Jan 2026 07:17:52 -0800 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: <20260104151752.GA4609@mcvoy.com> To the extent that uucp enabled usenet, yeah, huge impact. He says with full knowledge that uucp always seemed to need baby sitting. Honey Danber was better but I seem to recall it needed baby sitting as well. I'm most definitely not complaining, uucp/usenet gave us a sense of community that was awesome. On Sat, Jan 03, 2026 at 10:21:42PM -0500, Clem Cole via TUHS wrote: > Thank you. Funny your story about uucp. In the end, it was probably the > most significant new tool out side of the Bell system that came from > Seventh Edition. > > Clem > > Sent from a handheld expect more typos than usual > > > On Sat, Jan 3, 2026 at 10:09???PM Douglas McIlroy via TUHS > wrote: > > > I don't remember how it was decided that the time had come for another > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > some judgment about what should be in userland, wheedled contributions > > to the manual out of folks, and prodded fixes that would minimize the > > man-page BUGS sections. Maybe we rated the title of release > > provocateurs. > > > > As always in Unix, no one had ultimate authority. The most vivid > > example in v7 is that I didn't want uucp with its known security > > holes, but Mike Lesk could not be persuaded to work on closing them. > > It finally was included on the premise that it posed no new danger > > since it was already in widespread use. > > > > ---------- Forwarded message --------- > > From: Clem Cole > > Date: Sat, Jan 3, 2026 at 11:08???AM > > Subject: Re: V7 RE > > To: srb gmail > > Cc: Douglas McIlroy > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > Doug, your memory? > > > > On Sat, Jan 3, 2026 at 9:53???AM srb gmail wrote: > > > > > > "As I understand it, Dennis did not want to be the "release > > > engineer" for V7 (I believe srb put it together), but since V7 was going > > to > > > go outside of Bell to the "general population" in the CS research > > > community, it seemed like that was a good time to take back some it (by > > V8 > > > they stopped trying and Research and Summit diverged)." > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > > make sure the release tree had > > > src, bin and man pages and some other cleanup and checks. Doug I think > > was the official RE but he would > > > probably remember better than me. > > > > > > Steve > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Mon Jan 5 03:17:24 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 4 Jan 2026 12:17:24 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: <20260104151752.GA4609@mcvoy.com> References: <20260104151752.GA4609@mcvoy.com> Message-ID: Yes, uucp, usenet, net news et al demonstrated MetCalf’s Law. But it came at a heavy user admin price too. I suspect much of that was due to traffic volume of news systems on top of the uucp routing scheme. Sent from a handheld expect more typos than usual On Sun, Jan 4, 2026 at 10:17 AM Larry McVoy wrote: > To the extent that uucp enabled usenet, yeah, huge impact. He says with > full knowledge that uucp always seemed to need baby sitting. Honey > Danber was better but I seem to recall it needed baby sitting as well. > > I'm most definitely not complaining, uucp/usenet gave us a sense of > community that was awesome. > > On Sat, Jan 03, 2026 at 10:21:42PM -0500, Clem Cole via TUHS wrote: > > Thank you. Funny your story about uucp. In the end, it was probably the > > most significant new tool out side of the Bell system that came from > > Seventh Edition. > > > > Clem > > > > Sent from a handheld expect more typos than usual > > > > > > On Sat, Jan 3, 2026 at 10:09???PM Douglas McIlroy via TUHS < > tuhs at tuhs.org> > > wrote: > > > > > I don't remember how it was decided that the time had come for another > > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > > some judgment about what should be in userland, wheedled contributions > > > to the manual out of folks, and prodded fixes that would minimize the > > > man-page BUGS sections. Maybe we rated the title of release > > > provocateurs. > > > > > > As always in Unix, no one had ultimate authority. The most vivid > > > example in v7 is that I didn't want uucp with its known security > > > holes, but Mike Lesk could not be persuaded to work on closing them. > > > It finally was included on the premise that it posed no new danger > > > since it was already in widespread use. > > > > > > ---------- Forwarded message --------- > > > From: Clem Cole > > > Date: Sat, Jan 3, 2026 at 11:08???AM > > > Subject: Re: V7 RE > > > To: srb gmail > > > Cc: Douglas McIlroy > > > > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > > Doug, your memory? > > > > > > On Sat, Jan 3, 2026 at 9:53???AM srb gmail wrote: > > > > > > > > "As I understand it, Dennis did not want to be the "release > > > > engineer" for V7 (I believe srb put it together), but since V7 was > going > > > to > > > > go outside of Bell to the "general population" in the CS research > > > > community, it seemed like that was a good time to take back some it > (by > > > V8 > > > > they stopped trying and Research and Summit diverged)." > > > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote > scripts to > > > make sure the release tree had > > > > src, bin and man pages and some other cleanup and checks. Doug I > think > > > was the official RE but he would > > > > probably remember better than me. > > > > > > > > Steve > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Mon Jan 5 04:37:33 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 04 Jan 2026 18:37:33 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Sunday, January 4th, 2026 at 00:29, segaloco via TUHS wrote: > On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS tuhs at tuhs.org wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > > > UNIX Reference Card > > distributed by > > Computing Information Service > > BELL LABORATORIES > > Murray Hill, N. J. 07974 > > compiled by Lorinda Cherry > > Second Edition, March 1979 > > > > incomplete scan, some pages missing: > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > CHM has a copy, not currently scanned > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > spiral bound > > https://www.flickr.com/photos/n1kdo/53136436051 > > comb bound > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > > > Ah shoot, I actually have an unknown-generations-removed photocopy of this V6 flipbook, I should scan that. > > For the record, among the Release 4.0 documents I scanned for Arnold Robbins is that release's issue of this flipbook (I think they're genetically linked anyway): https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Reference_Guide.pdf > > - Matt G. Found it, my copy appears to be the first issue (V6 era rather than V7), predating the scan above. Two standard punch holes are visible in the top edge of the printout, presumably the original was bound with a couple of brads in a flipbook. I'll plan on scanning this in the coming weeks. Unfortunately the cover and title page aren't in this copy, but I think everything else is there, the page numbers are sequential except one that coincides with what was probably a blank page in the original. More to come. - Matt G. From tuhs at tuhs.org Mon Jan 5 06:07:07 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Sun, 4 Jan 2026 12:07:07 -0800 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> I also have a copy of Cherry's booklet (spiral bound, 1979) in my collection. Comparing it with the incompete chilton scan, it's only missing pages 4 and 22. The other missing pages are blank. I gather this is the same one Clem has? If not, let me know and I'll scan it. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: >> Also, while looking for the vi cards, I turned up two wonderful artifacts >> that I'll try to get scanned and added to TUHS at some point. When you >> purchased V7 from AT&T, you got one copy of the printed docs and a small >> "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry >> compiled. Also, when DEC released V7M-11, they printed a small flip-binding >> 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is >> similar but different. > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- > > UNIX Reference Card > distributed by > Computing Information Service > BELL LABORATORIES > Murray Hill, N. J. 07974 > compiled by Lorinda Cherry > Second Edition, March 1979 > > incomplete scan, some pages missing: > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > viahttp://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > CHM has a copy, not currently scanned > https://www.computerhistory.org/collections/catalog/102632799/ > > spiral bound > https://www.flickr.com/photos/n1kdo/53136436051 > comb bound > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Mon Jan 5 20:17:22 2026 From: tuhs at tuhs.org (Liam Proven via TUHS) Date: Mon, 5 Jan 2026 10:17:22 +0000 Subject: [TUHS] unix v4 tape found In-Reply-To: <37A35DF4-FC08-4702-AE71-3E707E57707F@canb.auug.org.au> References: <37A35DF4-FC08-4702-AE71-3E707E57707F@canb.auug.org.au> Message-ID: On Wed, 24 Dec 2025 at 01:23, steve jenkin via TUHS wrote: > > Liam Proven has written a nice piece in ’The Register’, includes history, why finding this piece is important & more. > > Links to videos and many CHM and other sources, including Oral Histories. > > LP wonders “Is this a Christmas Miracle?” > It’s certainly the original CSRC spirit of “Cooperation and Collegiality” alive & well. > > Link & extract at end. Oh, hey, that's me! Thank you Steve, and for the heads-up as well. I have a fairly significant backlog on some of my mailing lists and this is one of them. :-( Both the original article and the follow-up on the recovery seem to have gone down very well judging by the number of comments -- one of the few metrics that I can see as a mere reporter. (Dates embedded in the URLs.) https://www.theregister.com/2025/11/07/unix_fourth_edition_tape_rediscovered/ https://www.theregister.com/2025/12/23/unix_v4_tape_successfully_recovered/ -- Liam Proven ~ Profile: https://about.me/liamproven ~ LinkedIn/X/FB: lproven Email: lproven at cix.co.uk ~ Google: lproven at gmail.com IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From tuhs at tuhs.org Tue Jan 6 00:12:07 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Mon, 5 Jan 2026 09:12:07 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) Message-ID: From the "crytography" mailing list: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ From tuhs at tuhs.org Tue Jan 6 01:19:52 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 5 Jan 2026 10:19:52 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) Message-ID: So somebody spotted a buffer overflow in v4.5, ironically in su. Overflowable buffers were common in those days. It was all too easy when programming to shrug one's shoulders and opine that nobody would ever want to input a 200-character line, say, so why bother writing the extra code to catch it? We did gradually learn that automatically generated input lines--particularly lines of code--could be much longer than any person would write, so buffer overflows that actually happened gradually got fixed. Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what? Wasn't a crash just an ungraceful way for a program to say "I can't handle this"? Not until the Morris worm (1988) did folks wake up to the real danger of overflows. Sometime after Dennis's casual experiment, a paper that announced the same results got the reaction, "So what else is new?" from the Unix room. It would be interesting to find the paper and compare its "shocked, shocked" presentation to that of the rediscovery posted on the cryptography mailing list. Doug From tuhs at tuhs.org Tue Jan 6 01:40:48 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 10:40:48 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS wrote: > > Overflowable buffers were common in those days. It was all too easy > when programming to shrug one's shoulders and opine that nobody would > ever want to input a 200-character line, say, so why bother writing > the extra code to catch it? We did gradually learn that automatically > generated input lines--particularly lines of code--could be much > longer than any person would write, so buffer overflows that actually > happened gradually got fixed. > > There was another consideration. Machines in those days were slow and had tiny memory capacity. Was it really worth wasting the extra memory space and CPU time for buffer overflow checking in cases where it was extremely unlikely to occur? -Paul W. From tuhs at tuhs.org Tue Jan 6 01:51:11 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 5 Jan 2026 08:51:11 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 8:41 AM Paul Winalski via TUHS wrote: > On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS > wrote: > > > > > Overflowable buffers were common in those days. It was all too easy > > when programming to shrug one's shoulders and opine that nobody would > > ever want to input a 200-character line, say, so why bother writing > > the extra code to catch it? We did gradually learn that automatically > > generated input lines--particularly lines of code--could be much > > longer than any person would write, so buffer overflows that actually > > happened gradually got fixed. > > > There was another consideration. Machines in those days were slow and had > tiny memory capacity. Was it really worth wasting the extra memory space > and CPU time for buffer overflow checking in cases where it was extremely > unlikely to occur? > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer overflows only mattered if they crashed the program and even then they were often ignored due to execution time and/or code bloat considerations. One of the trade offs we were taught in my OS class was when to check: Crashing the kernel is bad, so check there, but make the check as cheap as you can. In userland, just let the program crash: that's zero cost feedback. Almost[*] everybody was going around, like in the princess bride, saying problems from this attitude were "Inconceivable" but the morris worm was the "You keep on using that word, I don't think it means what you think it means" moment that changed everything. Warner [*] We all know the classic papers that were ignored pre-worm... From tuhs at tuhs.org Tue Jan 6 02:15:00 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 11:15:00 -0500 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) Message-ID: Does anyone have a copy of the paper mentioned in the subject? From tuhs at tuhs.org Tue Jan 6 02:21:56 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Mon, 5 Jan 2026 11:21:56 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: As I understand what Michael Lesk has said about UUCP, it was created to bridge a three week gap before a full-fledged networking product was due to be released by the product folks. Somehow that sounds incredibly familiar. ===== mindthegapdialogs.com north-fork.info On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS wrote: > I don't remember how it was decided that the time had come for another > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > took on volume 2, which ultimately split into 2A and 2B. We exercised > some judgment about what should be in userland, wheedled contributions > to the manual out of folks, and prodded fixes that would minimize the > man-page BUGS sections. Maybe we rated the title of release > provocateurs. > > As always in Unix, no one had ultimate authority. The most vivid > example in v7 is that I didn't want uucp with its known security > holes, but Mike Lesk could not be persuaded to work on closing them. > It finally was included on the premise that it posed no new danger > since it was already in widespread use. > > ---------- Forwarded message --------- > From: Clem Cole > Date: Sat, Jan 3, 2026 at 11:08 AM > Subject: Re: V7 RE > To: srb gmail > Cc: Douglas McIlroy > > > Thank you. Fair enough. I was sure you had been heavily involved. > Doug, your memory? > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > "As I understand it, Dennis did not want to be the "release > > engineer" for V7 (I believe srb put it together), but since V7 was going > to > > go outside of Bell to the "general population" in the CS research > > community, it seemed like that was a good time to take back some it (by > V8 > > they stopped trying and Research and Summit diverged)." > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > make sure the release tree had > > src, bin and man pages and some other cleanup and checks. Doug I think > was the official RE but he would > > probably remember better than me. > > > > Steve > From tuhs at tuhs.org Tue Jan 6 02:22:19 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 11:22:19 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:51 AM Warner Losh via TUHS wrote: > On Mon, Jan 5, 2026 at 8:41 AM Paul Winalski via TUHS wrote: > > On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS wrote: > > > Overflowable buffers were common in those days. It was all too easy > > > when programming to shrug one's shoulders and opine that nobody would > > > ever want to input a 200-character line, say, so why bother writing > > > the extra code to catch it? We did gradually learn that automatically > > > generated input lines--particularly lines of code--could be much > > > longer than any person would write, so buffer overflows that actually > > > happened gradually got fixed. > > > > > There was another consideration. Machines in those days were slow and had > > tiny memory capacity. Was it really worth wasting the extra memory space > > and CPU time for buffer overflow checking in cases where it was extremely > > unlikely to occur? > > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > overflows only mattered if they crashed the program and even then > they were often ignored due to execution time and/or code bloat > considerations. One of the trade offs we were taught in my OS class > was when to check: Crashing the kernel is bad, so check there, > but make the check as cheap as you can. Indeed. My invariant has always been, "user programs should not be able to (directly) crash the kernel." I say, "directly" because there's an argument that some action taken by a user program might tickle a different problem (say, a faulty hardware device) that causes a crash and there may be little one can do about it, but it should never be the case that just giving a bad pointer or number to the kernel should result in a panic. > In userland, just let the program crash: that's zero cost feedback. > Almost[*] everybody was going around, like in the princess bride, > saying problems from this attitude were "Inconceivable" but the > morris worm was the "You keep on using that word, I don't think it > means what you think it means" moment that changed everything. Funny, I just watched that movie with my kids over the weekend.... But I'm not sure that was actually the turning point. I think it was the, "smashing the stack for fun and profit" paper that really got things going with respect to people being serious about buffer overruns and the like, at least locally. I rather got the impression that the Morris worm was seen as an interesting example of a category of problem, but mostly treated as a one-off. > [*] We all know the classic papers that were ignored pre-worm... I'm actually afraid that I do not, but it sounds like an interesting list. Any pointers to the top few? - Dan C. From tuhs at tuhs.org Tue Jan 6 02:23:19 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 5 Jan 2026 09:23:19 -0700 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: Do you know which product and what happened to it? Warner On Mon, Jan 5, 2026 at 9:22 AM Marc Donner via TUHS wrote: > As I understand what Michael Lesk has said about UUCP, it was created to > bridge a three week gap before a full-fledged networking product was due to > be released by the product folks. Somehow that sounds incredibly familiar. > ===== > mindthegapdialogs.com > north-fork.info > > > On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS > wrote: > > > I don't remember how it was decided that the time had come for another > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > some judgment about what should be in userland, wheedled contributions > > to the manual out of folks, and prodded fixes that would minimize the > > man-page BUGS sections. Maybe we rated the title of release > > provocateurs. > > > > As always in Unix, no one had ultimate authority. The most vivid > > example in v7 is that I didn't want uucp with its known security > > holes, but Mike Lesk could not be persuaded to work on closing them. > > It finally was included on the premise that it posed no new danger > > since it was already in widespread use. > > > > ---------- Forwarded message --------- > > From: Clem Cole > > Date: Sat, Jan 3, 2026 at 11:08 AM > > Subject: Re: V7 RE > > To: srb gmail > > Cc: Douglas McIlroy > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > Doug, your memory? > > > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > > > "As I understand it, Dennis did not want to be the "release > > > engineer" for V7 (I believe srb put it together), but since V7 was > going > > to > > > go outside of Bell to the "general population" in the CS research > > > community, it seemed like that was a good time to take back some it (by > > V8 > > > they stopped trying and Research and Summit diverged)." > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts > to > > make sure the release tree had > > > src, bin and man pages and some other cleanup and checks. Doug I think > > was the official RE but he would > > > probably remember better than me. > > > > > > Steve > > > From tuhs at tuhs.org Tue Jan 6 02:24:40 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Mon, 5 Jan 2026 11:24:40 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: I don't remember, but as I recall it never was actually released. Next time I see him I'll try to remember to ask. ===== mindthegapdialogs.com north-fork.info On Mon, Jan 5, 2026 at 11:23 AM Warner Losh wrote: > Do you know which product and what happened to it? > > Warner > > On Mon, Jan 5, 2026 at 9:22 AM Marc Donner via TUHS wrote: > >> As I understand what Michael Lesk has said about UUCP, it was created to >> bridge a three week gap before a full-fledged networking product was due >> to >> be released by the product folks. Somehow that sounds incredibly >> familiar. >> ===== >> mindthegapdialogs.com >> north-fork.info >> >> >> On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS >> wrote: >> >> > I don't remember how it was decided that the time had come for another >> > edition. I volunteered to edit volume 1 of the manual. Andrew Hume >> > took on volume 2, which ultimately split into 2A and 2B. We exercised >> > some judgment about what should be in userland, wheedled contributions >> > to the manual out of folks, and prodded fixes that would minimize the >> > man-page BUGS sections. Maybe we rated the title of release >> > provocateurs. >> > >> > As always in Unix, no one had ultimate authority. The most vivid >> > example in v7 is that I didn't want uucp with its known security >> > holes, but Mike Lesk could not be persuaded to work on closing them. >> > It finally was included on the premise that it posed no new danger >> > since it was already in widespread use. >> > >> > ---------- Forwarded message --------- >> > From: Clem Cole >> > Date: Sat, Jan 3, 2026 at 11:08 AM >> > Subject: Re: V7 RE >> > To: srb gmail >> > Cc: Douglas McIlroy >> > >> > >> > Thank you. Fair enough. I was sure you had been heavily involved. >> > Doug, your memory? >> > >> > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: >> > > >> > > "As I understand it, Dennis did not want to be the "release >> > > engineer" for V7 (I believe srb put it together), but since V7 was >> going >> > to >> > > go outside of Bell to the "general population" in the CS research >> > > community, it seemed like that was a good time to take back some it >> (by >> > V8 >> > > they stopped trying and Research and Summit diverged)." >> > > >> > > Hi Clem, I did some of the release engineering for V7. Wrote scripts >> to >> > make sure the release tree had >> > > src, bin and man pages and some other cleanup and checks. Doug I >> think >> > was the official RE but he would >> > > probably remember better than me. >> > > >> > > Steve >> > >> > From tuhs at tuhs.org Tue Jan 6 03:08:14 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 12:08:14 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:51 AM Warner Losh wrote: > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > overflows only > mattered if they crashed the program and even then they were often ignored > due to execution time and/or code bloat considerations. > The problem with that philosophy is that a buffer overflow doesn't necessarily lead to a program crash. A program crash is the lucky outcome. If you're unlucky you will silently get the wrong answer, or other misbehavior. -Paul W. From tuhs at tuhs.org Tue Jan 6 03:12:46 2026 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Mon, 5 Jan 2026 12:12:46 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: We know a lot more now than we knew 50 years ago. That is a good thing. On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > > On Mon, Jan 5, 2026 at 10:51 AM Warner Losh wrote: > > > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > > overflows only > > mattered if they crashed the program and even then they were often ignored > > due to execution time and/or code bloat considerations. > > > > The problem with that philosophy is that a buffer overflow doesn't > necessarily lead to a program crash. A program crash is the lucky > outcome. If you're unlucky you will silently get the wrong answer, or > other misbehavior. > > -Paul W. From tuhs at tuhs.org Tue Jan 6 03:27:30 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 5 Jan 2026 12:27:30 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > The problem with that philosophy is that a buffer overflow doesn't > necessarily lead to a program crash. A program crash is the lucky > outcome. If you're unlucky you will silently get the wrong answer, or > other misbehavior. > Right - which is why it took something catastrophic like the Morris Worm and shortly thereafter, the infamous smash the stack paper: ( https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for people to wake up to the fact that it really was an issue for many programs. I recall that some of the language folks (particularly those heavily involved in the Pascal *vs.* C war) like to say things like: *"See, the compiler should have general bounds-checking code." *I can't say I agreed on the general topic (there were too many things Pascal got wrong), but note that today both Go and Rust provide automatic bounds checking for all array and slice accesses at runtime. From tuhs at tuhs.org Tue Jan 6 03:44:06 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 05 Jan 2026 10:44:06 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <202601051744.605Hi6ga025548@freefriends.org> Clem Cole via TUHS wrote: > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. You can thank Moore's Law for that. We can afford the "penalty" on today's hardware. On yesterday's it was a *much* more painful decision. Arnold From tuhs at tuhs.org Tue Jan 6 03:46:50 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 5 Jan 2026 09:46:50 -0800 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Jan 5, 2026, at 9:27 AM, Clem Cole via TUHS wrote: > > On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS > wrote: > >> The problem with that philosophy is that a buffer overflow doesn't >> necessarily lead to a program crash. A program crash is the lucky >> outcome. If you're unlucky you will silently get the wrong answer, or >> other misbehavior. >> > Right - which is why it took something catastrophic like the Morris Worm > and shortly thereafter, the infamous smash the stack paper: ( > https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for > people to wake up to the fact that it really was an issue for many > programs. > > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. Actually Pascal got a lot of things right. Coming from being intimately familiar with Pascal and its orig. compiler, I disliked these things in C: 1. poor array support, no multi-dim arrays 2. C's union type vs Pascal's variant records 3. no subrange type 4. C's poor type system 5. C's enum type which are essentiall integers vs Pascal's strict enumeration type 6. No nested functions. [Of course, there were many things to like in C as well.] Granted, it was not as clean and orthogonal as Algol68 (whose popularity suffered from surface issues such as use of vW grammar od choice of keywords etc.). Also note that pretty much all non-C compilers pre-1988 generate code to do bounds check -- at least as an option but more often the option was to turn *off* bounds check! Now that we are aware of the danger of no bounds check, we seem to have gone to other extreme of using complicated languages like Rust.... From tuhs at tuhs.org Tue Jan 6 03:46:36 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 12:46:36 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 12:28 PM Clem Cole via TUHS wrote: > On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > > The problem with that philosophy is that a buffer overflow doesn't > > necessarily lead to a program crash. A program crash is the lucky > > outcome. If you're unlucky you will silently get the wrong answer, or > > other misbehavior. > > Right - which is why it took something catastrophic like the Morris Worm > and shortly thereafter, the infamous smash the stack paper: ( > https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for > people to wake up to the fact that it really was an issue for many > programs. > > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. Sadly, Rust turns it off for optimized ("Release") builds. Personally, I think that's a mistake; it ought to be an _explicit_ opt-out via a dedicated compiler option. I used to work with a former Microsofty who had worked on Midori, and who told me that M# (the variant of C# they used) did bounds checking for _all_ array accesses). At one point they tried to measure the cost of doing that, and realized it was down in the noise floor. - Dan C. From tuhs at tuhs.org Tue Jan 6 04:13:58 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Mon, 5 Jan 2026 11:13:58 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> I think in the beginning it just wasn't considered, that we had to protect against programs intentionally doing harm. Who would do that ? But now we know. On 01/05/2026 10:46 AM, Bakul Shah via TUHS wrote: > On Jan 5, 2026, at 9:27 AM, Clem Cole via TUHS wrote: >> On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS >> wrote: >> >>> The problem with that philosophy is that a buffer overflow doesn't >>> necessarily lead to a program crash. A program crash is the lucky >>> outcome. If you're unlucky you will silently get the wrong answer, or >>> other misbehavior. >>> >> Right - which is why it took something catastrophic like the Morris Worm >> and shortly thereafter, the infamous smash the stack paper: ( >> https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for >> people to wake up to the fact that it really was an issue for many >> programs. >> >> I recall that some of the language folks (particularly those heavily >> involved in the Pascal *vs.* C war) like to say things like: *"See, the >> compiler should have general bounds-checking code." *I can't say I agreed >> on the general topic (there were too many things Pascal got wrong), but >> note that today both Go and Rust provide automatic bounds checking for all >> array and slice accesses at runtime. > Actually Pascal got a lot of things right. Coming from being intimately > familiar with Pascal and its orig. compiler, I disliked these things in C: > 1. poor array support, no multi-dim arrays > 2. C's union type vs Pascal's variant records > 3. no subrange type > 4. C's poor type system > 5. C's enum type which are essentiall integers vs Pascal's strict enumeration type > 6. No nested functions. > > [Of course, there were many things to like in C as well.] > > Granted, it was not as clean and orthogonal as Algol68 (whose popularity > suffered from surface issues such as use of vW grammar od choice of keywords > etc.). > > Also note that pretty much all non-C compilers pre-1988 generate code to > do bounds check -- at least as an option but more often the option was to > turn *off* bounds check! > > Now that we are aware of the danger of no bounds check, we seem to have gone > to other extreme of using complicated languages like Rust.... From tuhs at tuhs.org Tue Jan 6 04:16:44 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 5 Jan 2026 13:16:44 -0500 Subject: [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) Message-ID: Moving to COFF, bcc TUHS On Mon, Jan 5, 2026 at 12:47 PM Bakul Shah wrote: > Actually Pascal got a lot of things right. Coming from being intimately > familiar with Pascal and its orig. compiler, I disliked these things in C: > 1. poor array support, no multi-dim arrays > 2. C's union type vs Pascal's variant records > 3. no subrange type > 4. C's poor type system > 5. C's enum type which are essentiall integers vs Pascal's strict > enumeration type > 6. No nested functions. > > [Of course, there were many things to like in C as well.] > > Granted, it was not as clean and orthogonal as Algol68 (whose popularity > suffered from surface issues such as use of vW grammar od choice of > keywords > etc.). > > Also note that pretty much all non-C compilers pre-1988 generate code to > do bounds check -- at least as an option but more often the option was to > turn *off* bounds check! > > Now that we are aware of the danger of no bounds check, we seem to have > gone > to other extreme of using complicated languages like Rust.... I, too, don't "hate" Pascal and don't argue with the strengths it demonstrated. But I have one primary issue: *"Which Pascal do you mean?" *When I worked at Tektronix, Ward Cunningham and I counted 14 different "Tek Pascals" in use at the time. The paper "*Why Pascal is not my Favorite Programming Language*" [ https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz ] offers up the fundamental issues. I suggest looking at Ward's Wiki [ https://wiki.c2.com/?WhyPascalIsNotMyFavoriteProgrammingLanguage ] as there are some interesting comments. I think this observation is also important: > "Interestingly, many of Kernighan's objections to Pascal are things that > Knuth also found it necessary to address in his LiterateProgramming > tool "Web", which he used in > the development of TexTheProgram and > Metafont. It is fair to say that the Web system is only half about > LiterateProgramming ; the other > half is just workarounds for the shortcomings of the Pascal dialects of its > day. Most notably, Web provides a mechanism to allow the use of > variable-length strings in things like error messages." From tuhs at tuhs.org Tue Jan 6 04:40:59 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 13:40:59 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> References: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> Message-ID: On Mon, Jan 5, 2026 at 1:14 PM Luther Johnson via TUHS wrote: [regarding buffer overflow checking] > I think in the beginning it just wasn't considered, that we had to > protect against programs intentionally doing harm. Who would do that ? > But now we know. > > With the good ole card-fed, raised floor mainframes, both the programs being run and their inputs were generally under strict, centralized control. Malicious code did still happen even then. Consider this story: The audit department at one of Hartford's major insurance companies received a phone call. It was from the head of the local BMW dealership. He told them, "One of your IT workers just paid cash for a top-of-the-line BMW. We thought you'd like to know that." It turns out that the IT worker was the programmer responsible for maintaining the program that prints the paychecks. The weekly pay calculation often yielded amounts in fractions of pennies. These were either rounded up or down to the nearest cent. The fractional pennies were tracked in an account called the breakage account. This programmer had created a fake employee in the company's computer records and had a check printed for that "person" containing the amount of money in the breakage account. He had been doing this for some time and had embezzled enough money to pay cash for a top-end Beemer. Malicious programming has always been with us. -Paul W. From tuhs at tuhs.org Tue Jan 6 05:05:58 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Mon, 05 Jan 2026 20:05:58 +0100 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Dan Cross via TUHS wrote in : |On Mon, Jan 5, 2026 at 12:28 PM Clem Cole via TUHS wrote: |> On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS \ |> wrote: |>> The problem with that philosophy is that a buffer overflow doesn't |>> necessarily lead to a program crash. A program crash is the lucky |>> outcome. If you're unlucky you will silently get the wrong answer, or |>> other misbehavior. |> |> Right - which is why it took something catastrophic like the Morris Worm |> and shortly thereafter, the infamous smash the stack paper: ( |> https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for |> people to wake up to the fact that it really was an issue for many |> programs. |> |> I recall that some of the language folks (particularly those heavily |> involved in the Pascal *vs.* C war) like to say things like: *"See, the |> compiler should have general bounds-checking code." *I can't say \ |> I agreed |> on the general topic (there were too many things Pascal got wrong), but |> note that today both Go and Rust provide automatic bounds checking \ |> for all |> array and slice accesses at runtime. | |Sadly, Rust turns it off for optimized ("Release") builds. Personally, |I think that's a mistake; it ought to be an _explicit_ opt-out via a |dedicated compiler option. Sadly is -- to me -- that this "memory safe" storm blows away any factualities. Furthermore, it seems anyone is willing to join into this choir, and as always i do not know why. Maybe an outcome of some "boring company" (and hoping the term is not trademarketed beyond usability). |I used to work with a former Microsofty who had worked on Midori, and |who told me that M# (the variant of C# they used) did bounds checking |for _all_ array accesses). At one point they tried to measure the cost |of doing that, and realized it was down in the noise floor. ..and fact is that any language i know supports bound-checked array accesses. You only have to code it. And have the discipline to use that interface, and that interface alone. This argument extends to more things. In early September 2024 there was a very long thread on some FreeBSD list where a long time contributor and kernel hacker jumped into the at that time "hot" (there was that Linux filesystem discussion thing where a Rust promoter stepped down not back after claiming that ~"blocking Rust" is "non-technical nonsense" (Google says for "linux rust non-techincal nonsense"). And he said |> In fact, of all the C bug fixes that I've been involved with (as |> either author or reviewer) since May, about three quarters could've |> been avoided just by using a better language. |... |> To summarize, here's the list of this week's security advisories, and |> also some other recent C bug fixes of my own involvement That really interested me, and i looked over them [1], likely not longer than a minute code-looking for each one (claiming t"he ones from OpenSSL and ctld are more complex" instead of looking more deeply), and i ended up saying Examples. I find the absolute opposite after checking four. Later in the thread one developer of a patch i did not look further into because of complexity stated his was ~"not a C error" either. So that is that. And then, how could any language help when, as i say in [1], "a byte buffer of reality matches a structure of a language abstraction". More than C? And things often seen in C, beyond that struct{x;y;char flex[];}, where a larger buffer is allocated to store some structure at the bottom and a buffer thereafter, in one hot memory chunk. You can create an interface that accesses memory within "flex" safely, even then. And then you can use a string object that knows its length. And all that -- you all know that, better than i do. In the non-mellow sphere of programmers lots of sledgehammerheads bang into this "memory safe" notch, as if they were the "king of the bongo .. bong!". Whereas i think it is beneficial to create a wider context so that at least in certain forums different realities can be heard. Not that it all ends up with AI rewriting any C or C++ code in Rust, without any little human programmer getting paid for anything of that rewrite, which does not fix just one logic error. [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2 Array bound checking, i mean, come on. Cheech and Chong are beaners without that. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Tue Jan 6 06:20:34 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Mon, 05 Jan 2026 12:20:34 -0800 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: Rich Salz via TUHS writes: > From the "crytography" mailing list: > https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ I can't wait for the flood of V4-related CVEs :-P --lyndon From tuhs at tuhs.org Tue Jan 6 06:39:22 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 15:39:22 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: [Note: TUHS to Bcc: and Cc: to COFF. This has nothing to do with Unix] On Mon, Jan 5, 2026 at 2:16 PM Steffen Nurpmeso via TUHS wrote: > [snip] > ..and fact is that any language i know supports bound-checked > array accesses. You only have to code it. And have the > discipline to use that interface, and that interface alone. > This argument extends to more things. Note: you took a note about what Rust does with bounds checking, and turned it into a rant about how you don't see value in memory safety. My experience is that people tend to react to languages things like Rust in one of three ways: 1) they are unabashed fan boys who suggest that anyone not programming in Rust is an idiot, 2) they acknowledge the strengths and potential benefits and can appreciate the positives of programming at a higher level of abstraction, while still pointing out flaws and being cautious about potential pitfalls (tooling, complexity, training, whatever; you name it), or 3) they assert that there's nothing useful here and anyone who's programming in Rust is an idiot desperately looking for tools to cover up their incompetence, and that the real solution is to just be a Better Programmer. Of course, Rust is just an example here; these broad categories of reactions are true of any number of technologies. Of the three, I've found that those falling into the first camp basically never write software but spend an awful lot of time writing blogs or commenting on hacker news. Those in the third category are similar, though they've likely _stopped_ writing lots of code. Those in the second category, who can appreciate nuance and weigh tradeoffs objectively, tend to be the best engineers. My own take here is your argument defeats itself in the above paragraph: 60 years of professional programming history have shown that those "only have to code it" and "having the discipline" things don't hold up at scale. Sure, we can all belly up to the bar and complain about how the kids these days just don't have the skill, intelligence, or intestinal fortitude to write competent C code, but professionals understand that tools evolve and defense-in-depth and automation are good when it comes to writing reliable software. If you think it's just a matter of discipline, well...good luck with that. History and available evidence disagree. > In early September 2024 there was a very long thread on some > FreeBSD list where a long time contributor and kernel hacker > jumped into the at that time "hot" (there was that Linux > filesystem discussion thing where a Rust promoter stepped down > not back after claiming that ~"blocking Rust" is "non-technical > nonsense" (Google says for "linux rust non-techincal nonsense"). > And he said > > |> In fact, of all the C bug fixes that I've been involved with (as > |> either author or reviewer) since May, about three quarters could've > |> been avoided just by using a better language. > |... > |> To summarize, here's the list of this week's security advisories, and > |> also some other recent C bug fixes of my own involvement > > That really interested me, and i looked over them [1], likely not > longer than a minute code-looking for each one (claiming t"he ones > from OpenSSL and ctld are more complex" instead of looking more > deeply), and i ended up saying > > Examples. I find the absolute opposite after checking four. I don't see how this can be claimed to be the "opposite." It may be that you aren't convinced that Rust has any advantages over C for the examples given that you looked at, but that is very different than claiming that Rust makes the code _worse_ and unsafe (which is what the opposite claim implies). > Later in the thread one developer of a patch i did not look > further into because of complexity stated his was ~"not a C error" > either. So that is that. > > And then, how could any language help when, as i say in [1], > "a byte buffer of reality matches a structure of a language > abstraction". More than C? > And things often seen in C, beyond that struct{x;y;char flex[];}, > where a larger buffer is allocated to store some structure at > the bottom and a buffer thereafter, in one hot memory chunk. > You can create an interface that accesses memory within "flex" > safely, even then. > And then you can use a string object that knows its length. > And all that -- you all know that, better than i do. > > In the non-mellow sphere of programmers lots of sledgehammerheads > bang into this "memory safe" notch, as if they were the "king of > the bongo .. bong!". > > Whereas i think it is beneficial to create a wider context so that > at least in certain forums different realities can be heard. > Not that it all ends up with AI rewriting any C or C++ code in > Rust, without any little human programmer getting paid for > anything of that rewrite, which does not fix just one logic error. > > [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2 > > Array bound checking, i mean, come on. Cheech and Chong are > beaners without that. That's a racial slur. Not cool. - Dan C. From tuhs at tuhs.org Tue Jan 6 13:52:53 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 06 Jan 2026 03:52:53 +0000 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: References: Message-ID: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> On Jan 5, 2026, at 09:15, Dan Cross wrote: > Does anyone have a copy of the paper mentioned in the subject? Wiley has the authoritative online copy (accessible via Sci-Hub) https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 and Erica Fischer uploaded a scan to the Internet Archive https://archive.org/details/tale-of-two-greps Thalia From tuhs at tuhs.org Tue Jan 6 17:51:29 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 06 Jan 2026 00:51:29 -0700 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> Message-ID: <202601060751.6067pTMI079021@freefriends.org> Thalia Archibald via TUHS wrote: > On Jan 5, 2026, at 09:15, Dan Cross wrote: > > Does anyone have a copy of the paper mentioned in the subject? > > > Wiley has the authoritative online copy (accessible via Sci-Hub) > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > and Erica Fischer uploaded a scan to the Internet Archive > https://archive.org/details/tale-of-two-greps > > Thalia > Thanks, that was an interesting read. Doug / Andrew -- is the fio library mentioned in the paper around anywhere? Or did it evolve into Plan 9's Bio library? Thanks, Arnold From tuhs at tuhs.org Tue Jan 6 18:32:13 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Tue, 6 Jan 2026 17:32:13 +0900 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <202601060751.6067pTMI079021@freefriends.org> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> Message-ID: You will find source in research editions from Eighth Edition on. It does seem that the bio library in Plan9 is an elaboration of fio. 2026年1月6日(火) 16:51 Arnold Robbins via TUHS : > Thalia Archibald via TUHS wrote: > > > On Jan 5, 2026, at 09:15, Dan Cross wrote: > > > Does anyone have a copy of the paper mentioned in the subject? > > > > > > Wiley has the authoritative online copy (accessible via Sci-Hub) > > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > > and Erica Fischer uploaded a scan to the Internet Archive > > https://archive.org/details/tale-of-two-greps > > > > Thalia > > > > Thanks, that was an interesting read. > > Doug / Andrew -- is the fio library mentioned in the paper around > anywhere? Or did it evolve into Plan 9's Bio library? > > Thanks, > > Arnold > From tuhs at tuhs.org Tue Jan 6 21:48:33 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Tue, 6 Jan 2026 12:48:33 +0100 Subject: [TUHS] Yacc binary on 4th edition tape Message-ID: Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). First on the timeline: - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. Now for the questions: - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? From tuhs at tuhs.org Wed Jan 7 02:31:55 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 06 Jan 2026 16:31:55 +0000 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: References: Message-ID: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Hi Paul, Excellent history on yacc and Waterloo! I’ll be adding your sources to my early UNIX history project :). I was aware of Wes Graham’s work on WATFOR at Waterloo and that the Computer Systems Group acquired UNIX in 1976 (which wasn’t necessarily the first group at Waterloo to do so), but I didn’t know of anything earlier. I found some interesting UNIX documents in the University of Waterloo archives and have uploaded them. https://archive.org/search?query=subject%3A%22University+of+Waterloo+Archives%22 Also, there are some items in the University of Waterloo Computer Museum that I’m hoping to get more information on, once I follow up with the curator. https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md > All this makes the Yacc binary on the 4th edition tape interesting to me, as it > gives a window on the state of Yacc late in 1973 when Johnson returned to Bell > Labs. The binary appears truncated at the 16kb mark If you’re using Angelo’s tar, you should fetch it again. He’s fixed some bugs that truncated several files, including yacc. http://squoze.net/UNIX/v4/unix_v4.tar Also you should know the tape dates to 12 June 1974, but the manual received was V4, so it’s V5 minus a week or so (though I only know that the V5 manual dates to the month of June). Although you could consider it a near-clean V5, I still call it V4, since the system was versioned by its manual. Thalia > On Jan 6, 2026, at 04:48, Paul Ruizendaal via TUHS wrote: > > > Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. > > I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. > > For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). > > First on the timeline: > > - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that > translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). > > - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. > > - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. > > - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. > > - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. > > - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. > > - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. > > - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. > > - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. > > I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc > > - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. > > - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. > > - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. > > Now for the questions: > > - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? > > - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? > > - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? > > > > From tuhs at tuhs.org Wed Jan 7 02:32:56 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 06 Jan 2026 16:32:56 +0000 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: Years ago when working at Johns Hopkins where finding ways to crash or otherwise compromise the UNIX system was sport, I spent a lot of time on the student staff there finding things and fixing them. Buffer overruns were a frequent cause of crashes. And it wasn’t even just user programs that were the problem. There’s a quaint bug in the PDP-11 where that if you fill up your entire 64K user address space with spl instructions, you lock up the machine. Now it was a quaint exercise to the student, to write a program that would fill up your program (complete with overwriting the stack) to make that happen. Being a lazy sort, I looked for a different solution. Well, our kernel had this system call called “nostack” which was used to get rid of UNIX’s idea of stack managment (this was done so we could emulate RSTS and run RSTS Basic under UNIX, the one condition that the department leveled on us to switch away from RSTS). So, I turned off the UNIX stack and then tried to change the break to 64K. This worked … for a few minutes. Then the machine crashed with a kernel panic with hardware errors. This wasn’t the crash I was expecting (the spl gambit just locks the mahcine so that not even the halt key works) and I’d not even started writing the data. Of course, now I had to deal with fixing the bug. Turns out that the error came from the SWAP DEVICE (an RF-11 fixed head disk in our case). Turns out it had found zero bytes of memory somewhere that didn’t exist and tried to swap 64K bytes into it. Since the RF-11 does NPR (what PDP-11s call DMA), the failure is reported by the disk controller. But more fun was had by using up other resources other than memory. An early UNIX security exploit was to open up all the file descriptors allowed and then invoke “su.” Su figured that something must really be wrong if it failed to open /etc/passwd and just gave you a root shell anyhow. Another fd exploit was to close certain file descriptors before invoking setuid programs. I found this when fixing a user’s mounted diskpack which I found had the output of mount written over the superblock. Turns out he wanted to get rid of the message mount printed, so he just closed file descriptor 1. Our mount program opened up the raw disk to read the pack labels (it hadn’t yet been moved to the kernel), and so his output got written there. Why the disk wasn’t opened RO was just sloppiness. Having found this, I launched into trying other user-executable set uid programs for similar bugs. Found a efw, but late in the night decided to give it up and go home. Coming in the next day I perused the (paper) logbook we kept of all crashes/reboot. I found an entry that said the system was shutdown to restoree the accounting file that had the first 8 bytes corrupted. Hmm… I say. I think I know how that happened. The other system admin said, “I figured you did. It was your user name that was the corrupting data (plus a colon). -Ron From tuhs at tuhs.org Wed Jan 7 03:46:56 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Tue, 6 Jan 2026 09:46:56 -0800 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> References: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Message-ID: <431a6d9d-f1e4-c356-28ec-f87bb6abf3f2@bitsavers.org> On 1/6/26 8:31 AM, Thalia Archibald via TUHS wrote: > Also, there are some items in the University of Waterloo Computer Museum that > I’m hoping to get more information on, once I follow up with the curator. > https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md I would really be interested if any of Thoth software has survived there. Nothing is known to exist of Cheriton's UBC version From tuhs at tuhs.org Wed Jan 7 05:17:14 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 6 Jan 2026 14:17:14 -0500 Subject: [TUHS] salami slicing, was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> Message-ID: <20260106191714.4E993EF3CBE8@ary.qy> It appears that Paul Winalski via TUHS said: >The audit department at one of Hartford's major insurance companies >received a phone call. It was from the head of the local BMW dealership. >He told them, "One of your IT workers just paid cash for a top-of-the-line >BMW. We thought you'd like to know that." It turns out that the IT worker >was the programmer responsible for maintaining the program that prints the >paychecks. The weekly pay calculation often yielded amounts in fractions >of pennies. These were either rounded up or down to the nearest cent. The >fractional pennies were tracked in an account called the breakage account. >This programmer had created a fake employee in the company's computer >records and had a check printed for that "person" containing the amount of >money in the breakage account. He had been doing this for some time and >had embezzled enough money to pay cash for a top-end Beemer. It's a swell story, but it's an urban legend told in many different varieties. https://www.snopes.com/fact-check/the-salami-technique/ R's, John From tuhs at tuhs.org Thu Jan 1 01:54:43 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 31 Dec 2025 10:54:43 -0500 Subject: [TUHS] Photo of old Unix manuals Message-ID: Attached is a photo of all the Research manuals. Top row v1-v5 (note the original owner's name on v1 and v2) Middle row v6 (2 vols), v7 (3 vols) Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) Doug From tuhs at tuhs.org Wed Jan 7 08:59:21 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Tue, 06 Jan 2026 23:59:21 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <20260106225921.HccRTfPk@steffen%sdaoden.eu> Douglas McIlroy via TUHS wrote in : |Attached is a photo of all the Research manuals. |Top row v1-v5 (note the original owner's name on v1 and v2) |Middle row v6 (2 vols), v7 (3 vols) |Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) TUHS does not let images pass. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Jan 7 09:25:32 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Wed, 07 Jan 2026 00:25:32 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: <20260106225921.HccRTfPk@steffen%sdaoden.eu> References: <20260106225921.HccRTfPk@steffen%sdaoden.eu> Message-ID: <20260106232532.eU6Q3FYy@steffen%sdaoden.eu> Steffen Nurpmeso via TUHS wrote in <20260106225921.HccRTfPk at steffen%sdaoden.eu>: |Douglas McIlroy via TUHS wrote in | : ||Attached is a photo of all the Research manuals. ||Top row v1-v5 (note the original owner's name on v1 and v2) ||Middle row v6 (2 vols), v7 (3 vols) ||Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) | |TUHS does not let images pass. However i am very unfriendly, and even stupid, as it was meant as a quick note in private as opposed to what actually happened. For a very quick shot https://pasteboard.co/ seems to be a freely available and working share service for images (via browser) that i now quicky discovered as the one i had used several times in the past seems to go offline. Select a file on the local disc from within the browser, and they give an URL under which the image can be accessed. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Jan 7 09:54:06 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 10:54:06 +1100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: References: Message-ID: On Tue, Jan 06, 2026 at 12:48:33PM +0100, Paul Ruizendaal via TUHS wrote: > - The DMR history paper then goes on to say that Johnson had a > sabbatical at the University of Waterloo in 1972, but I think this > might be a slip of the pen. A Uni of Waterloo retrospective says > that he arrived late in 1972 (“In August 1972, […] a new arrival > was causing a stir in the Math & Computer building at University > of Waterloo – a brand new Honeywell 6050 mainframe size computer. > […] Shortly after the arrival of the Honeywell, Steve Johnson came > to the Math Faculty on sabbatical from Bell Labs.”). He brought B > and Yacc with him ("I suspect that few people realize his key role > in introducing Bell Labs culture to University of Waterloo so early, > including B Programming Language, getchar(), putchar(), the beginnings > of the notion of software portability and, of course, yacc.”). > https://randalljhoward.com/tag/dead-whale/ The year 1973 is also > supported by a resume from 1982 ("I spent a 9-month Sabbatical in > 1973 at the University of Waterloo, where I taught courses in > Advanced Applications Techniques and Algebraic Manipulation.” — > https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). > 1973 is also a better match with the internship of Alan Snyder in > that year. "sabbatical in 1973, from January to September" Steve Johnson in: Salus - A Quarter Century of UNIX, p 100 From tuhs at tuhs.org Wed Jan 7 10:32:48 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 10:32:48 +1000 Subject: [TUHS] Unix 4.0? Message-ID: Strangely, I was just browsing through the Unix Archive here and came cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ For those looking for a reference guide, there is one here which is a flip book with six holes for binding at the top. It names itself "UNIX Reference Guide Release 4.0" and is dated April 1981. So this isn't 4th Edition :-) Is this release 4.0 of the reference guide, or does the 4.0 refer the version of Unix. I'm confused! Cheers, Warren From tuhs at tuhs.org Wed Jan 7 10:35:57 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 11:35:57 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: Thanks, I hadn't considered blank pages. Of the missing pages in the scan (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. The reference card is not often discussed, but as far as I can tell there was only one edition in 1979. So it seems likely you have the same one as Clem. On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > collection. > > Comparing it with the incompete chilton scan, it's only missing pages 4 and > 22. The other missing pages are blank. > > I gather this is the same one Clem has? If not, let me know and I'll scan > it. > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) >       Award Winning Author > maryannhorton.com > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > > > UNIX Reference Card > > distributed by > > Computing Information Service > > BELL LABORATORIES > > Murray Hill, N. J. 07974 > > compiled by Lorinda Cherry > > Second Edition, March 1979 > > > > incomplete scan, some pages missing: > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > viahttp://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > CHM has a copy, not currently scanned > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > spiral bound > > https://www.flickr.com/photos/n1kdo/53136436051 > > comb bound > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Wed Jan 7 10:37:31 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 10:37:31 +1000 Subject: [TUHS] Unix 4.0? In-Reply-To: References: Message-ID: On Wed, Jan 07, 2026 at 10:32:48AM +1000, Warren Toomey via TUHS wrote: > Strangely, I was just browsing through the Unix Archive here and came > cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ Ah, I should read the README. And a Google search found this: https://wiki.tuhs.org/doku.php?id=systems:unixts4 Apologies for the false alarm :-) Warren From tuhs at tuhs.org Wed Jan 7 11:41:13 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 6 Jan 2026 20:41:13 -0500 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: Agreed I’ll try to push doing some scans up onto the TUHS archived a big farther up my ToDo list. Sent from a handheld expect more typos than usual On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > Thanks, I hadn't considered blank pages. Of the missing pages in the scan > (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. > > The reference card is not often discussed, but as far as I can tell there > was > only one edition in 1979. So it seems likely you have the same one as > Clem. > > On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > > collection. > > > > Comparing it with the incompete chilton scan, it's only missing pages 4 > and > > 22. The other missing pages are blank. > > > > I gather this is the same one Clem has? If not, let me know and I'll scan > > it. > > > > Thanks, > > > > /Mary Ann Horton/ (she/her/ma'am) > > Award Winning Author > > maryannhorton.com > > > > > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > Also, while looking for the vi cards, I turned up two wonderful > artifacts > > > > that I'll try to get scanned and added to TUHS at some point. When > you > > > > purchased V7 from AT&T, you got one copy of the printed docs and a > small > > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > > compiled. Also, when DEC released V7M-11, they printed a small > flip-binding > > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > > > > > -- > > > > > > UNIX Reference Card - First Edition > > > L. L. Cherry > > > September, 1975 > > > A handy guide to UNIX commands and syntax. > > > > > > mentioned in: > > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > > v10/doc/bibliog.a unpm-docs > > > > > > -- > > > > > > UNIX Reference Card > > > distributed by > > > Computing Information Service > > > BELL LABORATORIES > > > Murray Hill, N. J. 07974 > > > compiled by Lorinda Cherry > > > Second Edition, March 1979 > > > > > > incomplete scan, some pages missing: > > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > > viahttp:// > www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > > > CHM has a copy, not currently scanned > > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > > > spiral bound > > > https://www.flickr.com/photos/n1kdo/53136436051 > > > comb bound > > > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > From tuhs at tuhs.org Wed Jan 7 11:59:06 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Tue, 6 Jan 2026 20:59:06 -0500 Subject: [TUHS] Photo of old Unix manuals Message-ID: Sorry, I thought the referenced attachment would be replaced by a link to a saved copy as happens with some attachments, but it turns out to exceed the tuhs size limit. it's now at https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. In case anyone is wondering, the only printed form of v10 was the trade binding. Only v6, v7 (non-trade), and v10 included extra volumes of companion documents. Doug. Date: Wed, 31 Dec 2025 10:54:43 -0500 From: Douglas McIlroy Subject: [TUHS] Re: Photo of old Unix manuals To: TUHS main list Attached is a photo of all the Research manuals. Top row v1-v5 (note the original owner's name on v1 and v2) Middle row v6 (2 vols), v7 (3 vols) Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Wed Jan 7 12:03:08 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 07 Jan 2026 02:03:08 +0000 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <92221366-C4F4-40F2-BBDA-7C8FD2B67157@archibald.dev> Douglas McIlroy wrote: > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) And with Bob Morris’ “V0” manual, you have that too :) Thalia From tuhs at tuhs.org Wed Jan 7 12:39:54 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 02:39:54 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > that I'll try to get scanned and added to TUHS at some point. When you > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- This is now scanned, albeit from a photocopy unknown generations removed and without covers or title page. It ain't great but should be good enough until a real one gets scanned without generational fuzz. https://archive.org/details/unix-reference-card-first-edition Page 23 (22 in PDF) concerns site dependent commands, most of which concern networking with other systems like IBM and GE/Honeywell stuff. The references in the end date this to the Sixth Edition. There is a blacked-out bit in the TROFF User's Manual reference, I can't quite make it out, it was in previous generations of whatever scan this came from but I can make out a 127 and a 4 I believe, it's probably a crossed out memorandum number. With the Second Edition distributed with V7, and another issue produced for Release 4.0, I now wonder how many other variations on this were made. There is a yellow fan-fold "Quick Guide" from 1982 by, like the yellow-covered comb-bound handbooks, Morris Bolsky. A later edition then appears in 1987, same by-line. Speaking of the ex/vi card that spurred this conversation, AT&T had their own variant, issue 2 here: https://archive.org/details/unix-system-v-visual-editor-quick-reference-issue-2 - Matt G. From tuhs at tuhs.org Wed Jan 7 13:10:55 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 13:10:55 +1000 Subject: [TUHS] UNIX Reference Card In-Reply-To: References: Message-ID: On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > Also, while looking for the vi cards, I turned up two wonderful artifacts > that I'll try to get scanned and added to TUHS at some point. When you > purchased V7 from AT&T, you got one copy of the printed docs and a small > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > similar but different. On Wed, Jan 07, 2026 at 02:39:54AM +0000, segaloco via TUHS wrote: > This is now scanned, albeit from a photocopy unknown generations removed > and without covers or title page. It ain't great but should be good > enough until a real one gets scanned without generational fuzz. > > https://archive.org/details/unix-reference-card-first-edition > > The references in the end date this to the Sixth Edition. There is a > blacked-out bit in the TROFF User's Manual reference, I can't quite make > it out, it was in previous generations of whatever scan this came from > but I can make out a 127 and a 4 I believe, it's probably a crossed out > memorandum number. I've just added it to the Archive here: https://www.tuhs.org/Archive/Documentation/Cards/ Thanks! Warren From tuhs at tuhs.org Wed Jan 7 13:27:59 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 14:27:59 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Wed, Jan 07, 2026 at 02:39:54AM +0000, segaloco via TUHS wrote: > On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > > > > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > This is now scanned, albeit from a photocopy unknown generations removed > and without covers or title page. It ain't great but should be good > enough until a real one gets scanned without generational fuzz. > > https://archive.org/details/unix-reference-card-first-edition > > Page 23 (22 in PDF) concerns site dependent commands, most of which > concern networking with other systems like IBM and GE/Honeywell stuff. > > The references in the end date this to the Sixth Edition. There is a > blacked-out bit in the TROFF User's Manual reference, I can't quite make > it out, it was in previous generations of whatever scan this came from > but I can make out a 127 and a 4 I believe, it's probably a crossed out > memorandum number. Thanks for the scan. I wonder if the cover was as fun as the 1979 one. It isn't quite Sixth Edition as distributed externally. It mentions man, troff and even sed. Also access() and alarm() system calls which were part of the "50 changes" tape. From tuhs at tuhs.org Wed Jan 7 16:24:02 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 06 Jan 2026 23:24:02 -0700 Subject: [TUHS] Unix 4.0? In-Reply-To: References: Message-ID: <202601070624.6076O2j1078296@freefriends.org> Hi Warren, Warren Toomey via TUHS wrote: > Strangely, I was just browsing through the Unix Archive here and came > cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ > > For those looking for a reference guide, there is one here which is a > flip book with six holes for binding at the top. It names itself > "UNIX Reference Guide Release 4.0" and is dated April 1981. > > So this isn't 4th Edition :-) Is this release 4.0 of the reference > guide, or does the 4.0 refer the version of Unix. I'm confused! > > Cheers, Warren It refers to Unix 4.0. This version was between System III and System V and wasn't released externally. I've told this story before, but I guess telling it again once every few years doesn't hurt. ;-) In 1981 I did some contract C programming at Southern Bell on a PDP-11/70 running Unix 4.0; that scan is from my copy. The other Unix 4.0 docs are from photocopies I made of the docs over the course of that summer. When I asked about the difference between System III and Unix 4.0, I was told that AT&T publicly released one version behind what they were running internally. With System V, they decided to change that policy, which is why there never was a System IV. They did not do a separate Reference Manual (Sections 1-8) for Unix 4.0; they gave me the manual for Unix 3.0 (comb bound) and there was a doc that summarized the differences. One of the things that still sticks out in my mind is the statement The "destroy your input file" feature of sort is now gone. Apparently, if you had done sort -o file-x file-x file-y file-z sort would have opened and truncated file-x for output before opening it for input. Ooops! :-) HTH, Arnold From tuhs at tuhs.org Wed Jan 7 17:44:05 2026 From: tuhs at tuhs.org (William H. Mitchell via TUHS) Date: Wed, 7 Jan 2026 00:44:05 -0700 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: I see "Ossanna" on the first and second edition manuals; perhaps those were his copies. I remember Ralph Griswold reverently talking about Joe Ossanna. > On Jan 6, 2026, at 6:59 PM, Douglas McIlroy via TUHS wrote: > > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. > > Date: Wed, 31 Dec 2025 10:54:43 -0500 > From: Douglas McIlroy > Subject: [TUHS] Re: Photo of old Unix manuals > To: TUHS main list > > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Wed Jan 7 18:48:57 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 07 Jan 2026 01:48:57 -0700 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <202601070848.6078mvHu097827@freefriends.org> Hi Doug. Douglas McIlroy via TUHS wrote: > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. Are there any manuals that you have that have not been scanned? v2? v3? The trade pub V7 was in a local bookstore for a while, but expensive. I'm sorry now that I didn't buy it. Courtesy of BWK I have a V8 manual, and I bought a V9 manual from Bell Labs sometime in the early 90s. I remember you sending me an email that you had to check if you could sell one to me. It was like $50. I bought the V10 manuals when they came out, and I also have the published Plan 9 manuals. :-) Arnold From tuhs at tuhs.org Wed Jan 7 19:00:07 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 07 Jan 2026 02:00:07 -0700 Subject: [TUHS] [off topic] Advocating for free information Message-ID: <202601070900.607907wn098699@freefriends.org> [ Sent to TUHS and bcc'ed to a number of friends. ] Hi All. This may be of interest to the list. I ask Warren's forgiveness for posting something off topic, and I respectfully request that we DON'T start a discussion about it. Thanks, Arnold > Date: Tue, 6 Jan 2026 20:32:47 -0500 (EST) > From: Terence Kelly > To: Arnold Robbins > Subject: advocating for free information > > Hi Arnold, > > [...] > > Briefly, the ACM Digital Library (DL) celebrated the holidays by revoking > public access to crucial facilities that have long been freely available > to all. Anyone not affiliated with a posh institution is locked out. > Free Software developers, scrappy startup coders, and penniless students > at nearly every community college in the US are locked out. > > To date, academics have spoken out against the new DL paywall... > > https://www.ipetitions.com/petition/restore-fully-free-and-open-access > > ...but news of the paywall has not yet reached the Free Software > community. > > I'd be grateful if you could forward the above petition URL to friends in > the Free Software world. Samizdat is the best way to spread news like > this. And of course, I and like-minded people would be honored if you > signed. > > Thanks & Happy New Year! > > -- Terence From tuhs at tuhs.org Wed Jan 7 19:14:05 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 7 Jan 2026 10:14:05 +0100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> References: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Message-ID: <03F70796-1BB5-44DD-AAD1-1D56B9A2FEEA@planet.nl> Thank you for these clarifications. Refetching the v4 archive indeed brings a complete yacc binary, and it is unstripped. I guess at some point I need to find a tool that can disassemble a PDP-11 a.out file, taking into account the symbols. Indeed, the tape is from 1974, not 1973 — which makes quite a difference as things were moving fast in that era — but still closer to the B version than the yacc sources in v6. Thank you for highlighting this. Paul > On 6 Jan 2026, at 17:31, Thalia Archibald wrote: > > Hi Paul, > > Excellent history on yacc and Waterloo! I’ll be adding your sources to my early > UNIX history project :). > > I was aware of Wes Graham’s work on WATFOR at Waterloo and that the Computer > Systems Group acquired UNIX in 1976 (which wasn’t necessarily the first group at > Waterloo to do so), but I didn’t know of anything earlier. I found some > interesting UNIX documents in the University of Waterloo archives and have > uploaded them. > https://archive.org/search?query=subject%3A%22University+of+Waterloo+Archives%22 > > Also, there are some items in the University of Waterloo Computer Museum that > I’m hoping to get more information on, once I follow up with the curator. > https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md > >> All this makes the Yacc binary on the 4th edition tape interesting to me, as it >> gives a window on the state of Yacc late in 1973 when Johnson returned to Bell >> Labs. The binary appears truncated at the 16kb mark > > > If you’re using Angelo’s tar, you should fetch it again. He’s fixed some bugs > that truncated several files, including yacc. > http://squoze.net/UNIX/v4/unix_v4.tar > > Also you should know the tape dates to 12 June 1974, but the manual received was > V4, so it’s V5 minus a week or so (though I only know that the V5 manual dates > to the month of June). Although you could consider it a near-clean V5, I still > call it V4, since the system was versioned by its manual. > > Thalia > >> On Jan 6, 2026, at 04:48, Paul Ruizendaal via TUHS wrote: >> >> >> Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. >> >> I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. >> >> For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). >> >> First on the timeline: >> >> - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that >> translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). >> >> - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. >> >> - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. >> >> - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. >> >> - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. >> >> - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. >> >> - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. >> >> - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. >> >> - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. >> >> I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc >> >> - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. >> >> - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. >> >> - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. >> >> Now for the questions: >> >> - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? >> >> - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? >> >> - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? >> >> >> >> > > From tuhs at tuhs.org Thu Jan 8 04:52:50 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 7 Jan 2026 13:52:50 -0500 Subject: [TUHS] pic macros Message-ID: I haven't found pic in the TUHS v7 source tree. Does anyone have a running version of it? My reason for asking is that there is no detailed spec for pic's macro facility. I've found some surprises in the Gnu implementation and wonder whether they are inherited from the original. Thanks, Doug From tuhs at tuhs.org Thu Jan 8 05:04:30 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 19:04:30 +0000 Subject: [TUHS] pic macros In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 10:53, Douglas McIlroy via TUHS wrote: > I haven't found pic in the TUHS v7 source tree. Does anyone have a > running version of it? > > My reason for asking is that there is no detailed spec for pic's macro > facility. I've found some surprises in the Gnu implementation and > wonder whether they are inherited from the original. > > Thanks, > Doug There is one in the V8 source tree: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pic This version has a changelog from 1980 to 1985 as well. - Matt G. From tuhs at tuhs.org Thu Jan 8 05:34:39 2026 From: tuhs at tuhs.org (Marc Haber via TUHS) Date: Wed, 7 Jan 2026 20:34:39 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow Message-ID: Hi, pardon me for jumping into this mailinglist that is so full of famous and knowledgeable people. I am the maintainer of adduser in Debian and am trying to make as much sense as possible in modern Unixoid systems. I am wondering about the difference between ! and * in the password field of /etc/shadow and before its invention in /etc/passwd. I think that until some ten years ago, there was still a difference between both, with one of the versions preventing login via password (but keeping it possible to use, for example, an ssh key to log in) and the other also making it impossible to use an ssh key to log in. I think that one also prevented su'ing to that account. This has been given up at least in GNU/Linux system a while ago with ! and * being kind of synonymous. It is common to put ! in front of a password hash to temporary lock an account while being able to restore the old password when the account is being unlocked. In Debian, the accounts that we deliver in a basic installation have "*" for a password, while useradd (from the shadow suite by Julianne Frances Haugh and Serge Hallyn, nowadays maintained on github) puts a ! in the password field when one does not set a password for a newly created account. Reading historic documents suggestst that ! used to be a notion for "temporarily locked" while * is the notation for "this account never had a password since it was created". The mixture of * and ! in the /etc/shadow field in Debian systems is kind of bothering my inner Adrian Monk, and I would like to either suggest that we (Debian) change to ! for the accounts in our default /etc/passwd or pester src:shadow to use * for newly created accounts. That being said, I'd like to solicit your opinion and historical knowledge about what ! and * in password fields were really meant to say in the beginning. Thank you very much. It is an honor to be allowed on thie Maiing List. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From tuhs at tuhs.org Thu Jan 8 05:40:11 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Wed, 07 Jan 2026 19:40:11 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: Back when the (encrypted) passwords were in /etc/password, a * was a common way to make accounts that could not be logged into. This goes back forwever (putting a blank password field in just meant there was no password required to log in). This predated /etc/shaddow and even the inclusion of the “salt” characters at the beginning of the passwords. The ! to disable wasn’t something I saw. It must have come later (but before people started using programs to manipulate these things). From tuhs at tuhs.org Thu Jan 8 06:19:13 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 7 Jan 2026 15:19:13 -0500 Subject: [TUHS] pic macros In-Reply-To: References: Message-ID: below On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS wrote: > I haven't found pic in the TUHS v7 source tree. Does anyone have a > running version of it? > That's because it was not released in V7. pic left the labs as an unbundled component/tool, like the Korn shell, asd, mk, nawk, and nmake (ditroff was part of the later "toolchest" ditroff distributions; it might have been part of the original ditroff for the v6/v7 release that included the new C compiler). IIRC, the toolchest version was enhanced. That said, the entire ditroff system was part of V8, and pic can be found in /usr/src/cmd/pic. I think that should be close to what was in the toolchest version. > > My reason for asking is that there is no detailed spec for pic's macro > facility. I've found some surprises in the Gnu implementation and > wonder whether they are inherited from the original. > > Thanks, > Doug > From tuhs at tuhs.org Thu Jan 8 07:13:39 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 21:13:39 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > Back when the (encrypted) passwords were in /etc/password, a * was a > common way to make accounts that could not be logged into. This goes > back forwever (putting a blank password field in just meant there was no > password required to log in). This predated /etc/shaddow and even the > inclusion of the “salt” characters at the beginning of the passwords. > The ! to disable wasn’t something I saw. It must have come later (but > before people started using programs to manipulate these things). The passwd(5) (or 4 for USG stream) manpage should give some pointers. As of the initial System V release (pre shadow), the only defined behaviors of this field are either an encrypted (via crypt(3)) string or an empty (null) string for no password. Additionally, a password can be followed by a comma and then aging information. I don't see any explicit handling of * or !. Presumably using * just means that the expected output of crypt(3) is *, an unlikely if not impossible scenario, leading to the behavior of no login available. I'll have to check the passwd(4) page in my SVR4 manuals at home. In any case, that's where I'd suggest looking. If it's not in the manuals, it may qualify as unintended behavior or something like that, meaning even if there is any handling for these characters specially (which I couldn't find in login(1), su(1), or any of the libc passwd stuff), that handling was never publicized. - Matt G. From tuhs at tuhs.org Thu Jan 8 07:26:08 2026 From: tuhs at tuhs.org (Hauke Fath via TUHS) Date: Wed, 7 Jan 2026 22:26:08 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> On Wed, 7 Jan 2026 20:34:39 +0100, Marc Haber via TUHS wrote: > Reading historic documents suggestst that ! used to be a notion for > "temporarily locked" while * is the notation for "this account never > had a password since it was created". A while back, I looked into how various OSes set up shadow passwords, in a vain attempt to run YP with shadow passwords. AFAIR, neither the 4.4BSD derived OSes (NetBSD, FreeBSD), nor Solarish (Solaris*, OmniOS) use an exclamation mark in the shadow file's password field. > The mixture of * and ! in the /etc/shadow field in Debian systems is > kind of bothering my inner Adrian Monk, and I would like to either > suggest that we (Debian) change to ! for the accounts in our default > /etc/passwd or pester src:shadow to use * for newly created accounts. Given that Linuxen put an 'x' into the /etc/passwd password field, when all other OSes I looked at use a '*', I am inclined to see the '!' as a Linuxism. Cheerio, Hauke * -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany From tuhs at tuhs.org Thu Jan 8 07:34:59 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Thu, 8 Jan 2026 08:34:59 +1100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <0AC42BE9-9F3F-4953-BD14-9CA401890031@gmail.com> Hi, I found this on the interweb and it corresponds to my memories from my sysadmin days... "If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means)." > On 8 Jan 2026, at 8:13 am, segaloco via TUHS wrote: > > On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > >> Back when the (encrypted) passwords were in /etc/password, a * was a >> common way to make accounts that could not be logged into. This goes >> back forwever (putting a blank password field in just meant there was no >> password required to log in). This predated /etc/shaddow and even the >> inclusion of the “salt” characters at the beginning of the passwords. >> The ! to disable wasn’t something I saw. It must have come later (but >> before people started using programs to manipulate these things). > > The passwd(5) (or 4 for USG stream) manpage should give some pointers. > As of the initial System V release (pre shadow), the only defined > behaviors of this field are either an encrypted (via crypt(3)) string > or an empty (null) string for no password. Additionally, a password can > be followed by a comma and then aging information. I don't see any > explicit handling of * or !. Presumably using * just means that the > expected output of crypt(3) is *, an unlikely if not impossible > scenario, leading to the behavior of no login available. > > I'll have to check the passwd(4) page in my SVR4 manuals at home. In > any case, that's where I'd suggest looking. If it's not in the manuals, > it may qualify as unintended behavior or something like that, meaning > even if there is any handling for these characters specially (which I > couldn't find in login(1), su(1), or any of the libc passwd stuff), that > handling was never publicized. > > - Matt G. .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Thu Jan 8 07:43:32 2026 From: tuhs at tuhs.org (Erik E. Fair via TUHS) Date: Wed, 07 Jan 2026 13:43:32 -0800 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <18807.1767822212@cesium.clock.org> Fundamentally, the question is whether the cryptographic hash of an input password can produce "*" or "!" or any other arbitrary string you put in the password field of /etc/passwd, /etc/master.passwd, etc., for matching & thus authentication. If it cannot without regard to any input string given to login(1) and subsequently hashed, then the account is disabled - no special casing required. No match, no login. Anything else (like password comparison being bypassed if the /etc/passwd string is null) is going to be an explicit exception case found in login(1)'s source code or anything else that processes passwords for authentication (e.g., ftpd(8), pppd(8)). Any string used for disabling accounts (other than traditional "*") could be processed by other (e.g., account management) software for its own purposes, so long as those strings cannot be produced by handing some other string to login(1) and hashed using the standard methods to produce an unwanted match (and thus unwanted successful authentication). Erik From tuhs at tuhs.org Thu Jan 8 07:50:39 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 08 Jan 2026 07:50:39 +1000 Subject: [TUHS] pic macros In-Reply-To: <20260107211438.pkzopkmtfruejp34@illithid> References: <20260107211438.pkzopkmtfruejp34@illithid> Message-ID: -------- Original Message -------- From: "G. Branden Robinson" Sent: 8 January 2026 7:14:38 am AEST To: tuhs at tuhs.org Cc: wkt at tuhs.org Subject: Re: [TUHS] Re: pic macros [CCing Warren so he can forward if necessary; as far as I know the Gmail->TUHS relationship is still sour, at least for me] At 2026-01-07T15:19:13-0500, Clem Cole via TUHS wrote: > On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS > wrote: > > I haven't found pic in the TUHS v7 source tree. Does anyone have a > > running version of it? > > > That's because it was not released in V7. As someone who definitely Wasn't There but has done a little research, I'd venture that pic wasn't yet _finished_ in time for V7. CSTR #97, "A Typesetter-Independent TROFF", by Kernighan, documents the process of creating same. See §7, "Graphics Commands", where he introduces the `\D` troff escape sequence upon which pic relies as a translation target. Writing in 1982, Kernighan says: "Since actual output is done by a post-processor, not TROFF, new capabilities for graphics have been easy to add. TROFF now recognizes commands for drawing diagonal lines, circles, ellipses, circular arcs, and quadratic B-splines; these are used in the PIC[...] and IDEAL[...] languages." (p. 2; PS/PDF p. 4) > (ditroff was part of the later "toolchest" ditroff distributions; it > might have been part of the original ditroff for the v6/v7 release > that included the new C compiler) If I understand the history correctly, it would certainly have had to have been backported to those Unices; V7 is dated 1979, and Kernighan reports his work on what came to be known as "ditroff" in "early 1979" per CSTR #97. Regards, Branden -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Thu Jan 8 08:11:40 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Thu, 8 Jan 2026 08:11:40 +1000 Subject: [TUHS] pic macros In-Reply-To: References: <20260107211438.pkzopkmtfruejp34@illithid> Message-ID: We got the ditroff tape distinct from our 4.2bsd tape for Leeds uni, 1982-3 time frames. Somebody local did driver work for a versatec printer we had. Odd wet xerography style printing on continuous paper with cut marks printed in as it did pages. I think it was 200dpi or worse, I have a printout somewhere set on it in old English font. (The solvent evaporated as you walked up to get your printout) G On Thu, 8 Jan 2026, 7:50 am Warren Toomey via TUHS, wrote: > > > > -------- Original Message -------- > From: "G. Branden Robinson" > Sent: 8 January 2026 7:14:38 am AEST > To: tuhs at tuhs.org > Cc: wkt at tuhs.org > Subject: Re: [TUHS] Re: pic macros > > [CCing Warren so he can forward if necessary; as far as I know the > Gmail->TUHS relationship is still sour, at least for me] > > At 2026-01-07T15:19:13-0500, Clem Cole via TUHS wrote: > > On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS > > wrote: > > > I haven't found pic in the TUHS v7 source tree. Does anyone have a > > > running version of it? > > > > > That's because it was not released in V7. > > As someone who definitely Wasn't There but has done a little research, > I'd venture that pic wasn't yet _finished_ in time for V7. > > CSTR #97, "A Typesetter-Independent TROFF", by Kernighan, documents the > process of creating same. See §7, "Graphics Commands", where he > introduces the `\D` troff escape sequence upon which pic relies as a > translation target. Writing in 1982, Kernighan says: > > "Since actual output is done by a post-processor, not TROFF, new > capabilities for graphics have been easy to add. TROFF now recognizes > commands for drawing diagonal lines, circles, ellipses, circular arcs, > and quadratic B-splines; these are used in the PIC[...] and IDEAL[...] > languages." (p. 2; PS/PDF p. 4) > > > (ditroff was part of the later "toolchest" ditroff distributions; it > > might have been part of the original ditroff for the v6/v7 release > > that included the new C compiler) > > If I understand the history correctly, it would certainly have had to > have been backported to those Unices; V7 is dated 1979, and Kernighan > reports his work on what came to be known as "ditroff" in "early 1979" > per CSTR #97. > > Regards, > Branden > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Thu Jan 8 08:31:58 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 7 Jan 2026 14:31:58 -0800 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> References: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> Message-ID: <8747fd08-eff9-4d43-9f52-b31581e85ae5@oracle.com> On 1/7/26 13:26, Hauke Fath via TUHS wrote: > On Wed, 7 Jan 2026 20:34:39 +0100, Marc Haber via TUHS wrote: >> Reading historic documents suggestst that ! used to be a notion for >> "temporarily locked" while * is the notation for "this account never >> had a password since it was created". > > A while back, I looked into how various OSes set up shadow passwords, > in a vain attempt to run YP with shadow passwords. AFAIR, neither the > 4.4BSD derived OSes (NetBSD, FreeBSD), nor Solarish (Solaris*, OmniOS) > use an exclamation mark in the shadow file's password field. > > * The web hosted version of the man page is a little out of date now - the version shipped in the latest updates documents the following lock strings as options for the password field - but none have a ! in: *LK* The lock string is defined as *LK* in the first four (or only four) characters of the password field if the account was manually locked, by an ad- min running passwd -l. *AL* Prefix on the password hash when the account was automatically locked due to the number of authenti- cation failures reaching the configured maximum al- lowed. See policy.conf(5) and user_attr(5). NP Used to indicate an account is active but not par- ticipating in password authentication. It can run cron jobs and may be able to authenticate using a method other than a password hash stored in the nameservice, for example SSH publickey or with Ker- beros. Exempt from automatic lock out due to failed pass- word authentication attempts. Useful for system/ap- pliication accounts and Roles when roleauth=user is set in user_attr(5). The NP value can be set by passwd -N or delivered as the value in a pkg(7) user action. UP Set by useradd(8) when the account is initially created, and has yet to have a password set. Users in the UP state can not authenticate to the system. When an account is delivered via a pkg(7) action UP should be used if the user is intended to have a password assigned later using passwd(1). -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Thu Jan 8 08:43:33 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Wed, 07 Jan 2026 22:43:33 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: I was going way back before System V. We moved our passwords out of public view in /etc/passwd back in our version 6 variants. Yes, * worked fine because it could never match the encrypted password. The V6 manual doesn’t mention this “hack.” It still talks about GCOS (which is where most people had started putting information like the user’s real name. Amusingly at BRL, we put the user name in an email-complaint format such as: ron::58:33:Ron Natalie :/sys1/ron: This bit one of our admins once. He wanted to find his entry in the file and typed: grep /etc/passwd Alas, he was root at the time. ------ Original Message ------ >From "segaloco via TUHS" To "The Eunuchs Hysterical Society" Date 1/7/2026 4:13:39 PM Subject [TUHS] Re: Questions about * and ! in the password field of passwd and shadow >On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > >> Back when the (encrypted) passwords were in /etc/password, a * was a >> common way to make accounts that could not be logged into. This goes >> back forwever (putting a blank password field in just meant there was no >> password required to log in). This predated /etc/shaddow and even the >> inclusion of the “salt” characters at the beginning of the passwords. >> The ! to disable wasn’t something I saw. It must have come later (but >> before people started using programs to manipulate these things). > >The passwd(5) (or 4 for USG stream) manpage should give some pointers. >As of the initial System V release (pre shadow), the only defined >behaviors of this field are either an encrypted (via crypt(3)) string >or an empty (null) string for no password. Additionally, a password can >be followed by a comma and then aging information. I don't see any >explicit handling of * or !. Presumably using * just means that the >expected output of crypt(3) is *, an unlikely if not impossible >scenario, leading to the behavior of no login available. > >I'll have to check the passwd(4) page in my SVR4 manuals at home. In >any case, that's where I'd suggest looking. If it's not in the manuals, >it may qualify as unintended behavior or something like that, meaning >even if there is any handling for these characters specially (which I >couldn't find in login(1), su(1), or any of the libc passwd stuff), that >handling was never publicized. > >- Matt G. From tuhs at tuhs.org Thu Jan 8 11:09:20 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 Jan 2026 01:09:20 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 14:43, Ron Natalie via TUHS wrote: > > This bit one of our admins once. He wanted to find his entry in the > file and typed: > > grep /etc/passwd > My next door neighbors could probably hear how loud of a "oh nooooooo" I said reading that.... So SVR4 says: > The password field consists of the character x. This field remains only for > compatibility reasons. Password information is contained in the file > /etc/shadow; see shadow(4). Then in shadow(4) the password field is so described: > A 13-character encrypted password for the user, > a lock string to indicate that the login is not accessible, > or no string to show that there is no password for the login. These lock strings are then things as described earlier in the thread like "*LK*" in the password field to indicate a lock. Unfortunately I'm not quickly finding a list of known lock strings in the documentation, they can probably be found in the sources of the passwd(1) command if nothing else. I also checked the 4.4BSD and Research V10 manuals, neither indicate anything other than an encrypted string or null can be used, the latter resulting in a password-less login. No mention of special meaning in other characters. I suspect if there ever was any difference between * and ! as representations of a special case, those may not have been all that widespread. So all in all, the password field has formally accumulated the following features from what I can tell: - encrypted string - null (no password) - comma plus aging info (USG stream) - x (for shadow, later USG) - *..* (later USG, .. includes "LK" for locked) The consensus here thus far is that * (or !) were simply taking advantage of the fact that neither would be valid crypt(3) output so no user password should compare true. I haven't come across any historic documentation describing these as having any special meaning otherwise. - Matt G. From tuhs at tuhs.org Thu Jan 8 11:24:13 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Wed, 7 Jan 2026 17:24:13 -0800 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> I had some extra time today, so I went ahead and scanned the Cherry card and the Bolsky card. The Cherry card is unique in that the pages aren't all the same length. Each section has slightly longer pages, with a "tab" heading at the bottom of the first page of each section. See the 3rd page of the PDF for the full effect. https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 1/6/26 17:41, Clem Cole via TUHS wrote: > Agreed I’ll try to push doing some scans up onto the TUHS archived a big > farther up my ToDo list. > > Sent from a handheld expect more typos than usual > > > On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > >> Thanks, I hadn't considered blank pages. Of the missing pages in the scan >> (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. >> >> The reference card is not often discussed, but as far as I can tell there >> was >> only one edition in 1979. So it seems likely you have the same one as >> Clem. >> >> On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: >>> I also have a copy of Cherry's booklet (spiral bound, 1979) in my >>> collection. >>> >>> Comparing it with the incompete chilton scan, it's only missing pages 4 >> and >>> 22. The other missing pages are blank. >>> >>> I gather this is the same one Clem has? If not, let me know and I'll scan >>> it. >>> >>> Thanks, >>> >>> /Mary Ann Horton/ (she/her/ma'am) >>> Award Winning Author >>> maryannhorton.com >>> >>> >>> >>> On 1/3/26 20:41, Jonathan Gray via TUHS wrote: >>>> On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: >>>>> Also, while looking for the vi cards, I turned up two wonderful >> artifacts >>>>> that I'll try to get scanned and added to TUHS at some point. When >> you >>>>> purchased V7 from AT&T, you got one copy of the printed docs and a >> small >>>>> "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry >>>>> compiled. Also, when DEC released V7M-11, they printed a small >> flip-binding >>>>> 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is >>>>> similar but different. >>>> Was the first edition also distributed to V6 licensees? >>>> >>>> -- >>>> >>>> UNIX Reference Card - First Edition >>>> L. L. Cherry >>>> September, 1975 >>>> A handy guide to UNIX commands and syntax. >>>> >>>> mentioned in: >>>> tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 >>>> v10/doc/bibliog.a unpm-docs >>>> >>>> -- >>>> >>>> UNIX Reference Card >>>> distributed by >>>> Computing Information Service >>>> BELL LABORATORIES >>>> Murray Hill, N. J. 07974 >>>> compiled by Lorinda Cherry >>>> Second Edition, March 1979 >>>> >>>> incomplete scan, some pages missing: >>>> http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf >>>> viahttp:// >> www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm >>>> CHM has a copy, not currently scanned >>>> https://www.computerhistory.org/collections/catalog/102632799/ >>>> >>>> spiral bound >>>> https://www.flickr.com/photos/n1kdo/53136436051 >>>> comb bound >>>> >> https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 >> From tuhs at tuhs.org Thu Jan 8 21:32:16 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Thu, 8 Jan 2026 12:32:16 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: Oh, this is really good. I do wonder if the old manuals match the scans or t?roff files we have! having scans of those would be neat. aap On 06/01/26, Douglas McIlroy via TUHS wrote: > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. > > Date: Wed, 31 Dec 2025 10:54:43 -0500 > From: Douglas McIlroy > Subject: [TUHS] Re: Photo of old Unix manuals > To: TUHS main list > > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Thu Jan 8 23:25:02 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 08 Jan 2026 06:25:02 -0700 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development Message-ID: <202601081325.608DP2jC096157@freefriends.org> https://www.youtube.com/watch?v=5Zsk5L225Zs From tuhs at tuhs.org Fri Jan 9 07:21:22 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 9 Jan 2026 07:21:22 +1000 Subject: [TUHS] Fwd: Amdahl UTS Source Code Message-ID: All, I received this e-mail from Andrew Gadsby: Hello Warren In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I found the UTS system at https://www.tuhs.org/Archive/Distributions/IBM/370/ I booted it up and got it running, which was great fun. Anyway, as I explored this release I realised that it is complete and includes all of the utility and kernel source code -is also builds within the booted system. This was a complete surprise to me and bought back many memories of those early days. I have extracted the source code and am working on some notes on using this beast. Would you be interested in adding this material to the site? If so I’ll pull my notes and the code together over the next few days and send you a link so you can take a look. Andrew has some concerns about the copyright on the modifications. He adds: The more I look at this the more it looks like a V7 research Unix, as per your existing PDP11 source code but with modifications to make it run on the 370 - not complete as for example the sys/sched() code is empty so there’s no paging or swapping. Some of the documentation is by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in 1981. I also think “Pugs” may have been doing something on it as well, as there’s an old mail entry for him from c. 1980. If he’s on your mailing list maybe he can give some input? I’ve still not found any copyright notices. Does any of this help with copyright concerns? I will get you a fuller set of files to you when I’ve figured out more about the kernel rebuild and disk formatting process. That’ll help me get a starter guide written - the included 3270 driver is a pain but I’m beating it into submission- who needs a backslash character anyway! I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could provide any insights that would be wonderful :-) Thanks, Warren From tuhs at tuhs.org Fri Jan 9 07:36:09 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 8 Jan 2026 13:36:09 -0800 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: This has been "known" for a while. It's definitely the V7 port to Amdahl, known internally as "Au". There's no swapping or paging because the underlying VM system provided virtual memory. Being V7, there's no problem with the UNIX license, but Fujitsu owns the Amdahl IP now. I have a hard time believing anyone would care. I've toyed with it, but the folks who have done a lot more hang out on Discord: "Mainframe Enthusiasts" # uts-and-all-nixes: https://discord.com/channels/423767742546575361/871957791923920967 Sadly, I don't remember how to do the kernel build and disk formatting. I'm curious - how did you extract the source code? On Thu, Jan 8, 2026 at 1:21 PM Warren Toomey via TUHS wrote: > All, I received this e-mail from Andrew Gadsby: > > Hello Warren > > In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I > found the UTS system at > https://www.tuhs.org/Archive/Distributions/IBM/370/ > > I booted it up and got it running, which was great fun. Anyway, as I > explored this release I realised that it is complete and includes all > of the utility and kernel source code -is also builds within the booted > system. This was a complete surprise to me and bought back many > memories of those early days. > > I have extracted the source code and am working on some notes on using > this beast. Would you be interested in adding this material to the > site? If so I’ll pull my notes and the code together over the next few > days and send you a link so you can take a look. > > Andrew has some concerns about the copyright on the modifications. He adds: > > The more I look at this the more it looks like a V7 research Unix, as > per your existing PDP11 source code but with modifications to make it > run on the 370 - not complete as for example the sys/sched() code is > empty so there’s no paging or swapping. Some of the documentation is > by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in 1981. > > I also think “Pugs” may have been doing something on it as well, > as there’s an old mail entry for him from c. 1980. If he’s on your > mailing list maybe he can give some input? I’ve still not found > any copyright notices. > > Does any of this help with copyright concerns? > > I will get you a fuller set of files to you when I’ve figured out > more about the kernel rebuild and disk formatting process. That’ll > help me get a starter guide written - the included 3270 driver is > a pain but I’m beating it into submission- who needs a backslash > character anyway! > > I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could > provide any insights that would be wonderful :-) > > Thanks, Warren > From tuhs at tuhs.org Fri Jan 9 09:57:52 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Thu, 8 Jan 2026 16:57:52 -0700 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: I had no trouble installing it under VM/370. And, yeah, the video I saw from ... maybe Moshix? ... claimed it was v6 but playing with it, it's very much closer to v7. Dumping the source ought to be a pretty simple matter of mounting an emulated tape to hercules, dumping the files with tar, and then using the herc utils to extract them out again (or indeed, create a .tar file, dump THAT to awstape, extract the tar, and then use Unix tar to deal with the contents, which is actually probably easier than roundtripping the files through EBCDIC again). On Thu, Jan 8, 2026 at 2:36 PM Tom Lyon via TUHS wrote: > This has been "known" for a while. > > It's definitely the V7 port to Amdahl, known internally as "Au". > There's no swapping or paging because the underlying VM system provided > virtual memory. > Being V7, there's no problem with the UNIX license, but Fujitsu owns the > Amdahl IP now. I have a hard time believing anyone would care. > > I've toyed with it, but the folks who have done a lot more hang out on > Discord: > "Mainframe Enthusiasts" # uts-and-all-nixes: > https://discord.com/channels/423767742546575361/871957791923920967 > > Sadly, I don't remember how to do the kernel build and disk formatting. > I'm curious - how did you extract the source code? > > > > On Thu, Jan 8, 2026 at 1:21 PM Warren Toomey via TUHS > wrote: > > > All, I received this e-mail from Andrew Gadsby: > > > > Hello Warren > > > > In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I > > found the UTS system at > > https://www.tuhs.org/Archive/Distributions/IBM/370/ > > > > I booted it up and got it running, which was great fun. Anyway, as I > > explored this release I realised that it is complete and includes all > > of the utility and kernel source code -is also builds within the > booted > > system. This was a complete surprise to me and bought back many > > memories of those early days. > > > > I have extracted the source code and am working on some notes on using > > this beast. Would you be interested in adding this material to the > > site? If so I’ll pull my notes and the code together over the next few > > days and send you a link so you can take a look. > > > > Andrew has some concerns about the copyright on the modifications. He > adds: > > > > The more I look at this the more it looks like a V7 research Unix, as > > per your existing PDP11 source code but with modifications to make it > > run on the 370 - not complete as for example the sys/sched() code is > > empty so there’s no paging or swapping. Some of the documentation is > > by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in > 1981. > > > > I also think “Pugs” may have been doing something on it as well, > > as there’s an old mail entry for him from c. 1980. If he’s on your > > mailing list maybe he can give some input? I’ve still not found > > any copyright notices. > > > > Does any of this help with copyright concerns? > > > > I will get you a fuller set of files to you when I’ve figured out > > more about the kernel rebuild and disk formatting process. That’ll > > help me get a starter guide written - the included 3270 driver is > > a pain but I’m beating it into submission- who needs a backslash > > character anyway! > > > > I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could > > provide any insights that would be wonderful :-) > > > > Thanks, Warren > > > From tuhs at tuhs.org Fri Jan 9 16:59:19 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 8 Jan 2026 22:59:19 -0800 Subject: [TUHS] UNIX on Tandem Message-ID: Ran across this citation today. Anyone ever seen this paper? Known of the system? I'm pretty sure they're talking about Tandem(TM), not just generic tandem. A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl Electron Conf, 34 (October 1980), pp 16-8. From tuhs at tuhs.org Fri Jan 9 18:58:26 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 9 Jan 2026 19:58:26 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> Message-ID: Thank you. I see Warren has also added these to the archive. https://www.tuhs.org/Archive/Documentation/Cards/ On Wed, Jan 07, 2026 at 05:24:13PM -0800, Mary Ann Horton via TUHS wrote: > I had some extra time today, so I went ahead and scanned the Cherry card and > the Bolsky card. > > The Cherry card is unique in that the pages aren't all the same length. Each > section has slightly longer pages, with a "tab" heading at the bottom of the > first page of each section. See the 3rd page of the PDF for the full effect. > > https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf > > https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) >       Award Winning Author > maryannhorton.com > > > > On 1/6/26 17:41, Clem Cole via TUHS wrote: > > Agreed I’ll try to push doing some scans up onto the TUHS archived a big > > farther up my ToDo list. > > > > Sent from a handheld expect more typos than usual > > > > > > On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > > > > > Thanks, I hadn't considered blank pages. Of the missing pages in the scan > > > (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. > > > > > > The reference card is not often discussed, but as far as I can tell there > > > was > > > only one edition in 1979. So it seems likely you have the same one as > > > Clem. > > > > > > On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > > > > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > > > > collection. > > > > > > > > Comparing it with the incompete chilton scan, it's only missing pages 4 > > > and > > > > 22. The other missing pages are blank. > > > > > > > > I gather this is the same one Clem has? If not, let me know and I'll scan > > > > it. > > > > > > > > Thanks, > > > > > > > > /Mary Ann Horton/ (she/her/ma'am) > > > > Award Winning Author > > > > maryannhorton.com > > > > > > > > > > > > > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > > Also, while looking for the vi cards, I turned up two wonderful > > > artifacts > > > > > > that I'll try to get scanned and added to TUHS at some point. When > > > you > > > > > > purchased V7 from AT&T, you got one copy of the printed docs and a > > > small > > > > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > > > > compiled. Also, when DEC released V7M-11, they printed a small > > > flip-binding > > > > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > > > > similar but different. > > > > > Was the first edition also distributed to V6 licensees? > > > > > > > > > > -- > > > > > > > > > > UNIX Reference Card - First Edition > > > > > L. L. Cherry > > > > > September, 1975 > > > > > A handy guide to UNIX commands and syntax. > > > > > > > > > > mentioned in: > > > > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > > > > v10/doc/bibliog.a unpm-docs > > > > > > > > > > -- > > > > > > > > > > UNIX Reference Card > > > > > distributed by > > > > > Computing Information Service > > > > > BELL LABORATORIES > > > > > Murray Hill, N. J. 07974 > > > > > compiled by Lorinda Cherry > > > > > Second Edition, March 1979 > > > > > > > > > > incomplete scan, some pages missing: > > > > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > > > > viahttp:// > > > www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > > CHM has a copy, not currently scanned > > > > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > > > > > > > spiral bound > > > > > https://www.flickr.com/photos/n1kdo/53136436051 > > > > > comb bound > > > > > > > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > > > From tuhs at tuhs.org Fri Jan 9 19:06:48 2026 From: tuhs at tuhs.org (Marc Haber via TUHS) Date: Fri, 9 Jan 2026 10:06:48 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: Hello Everybody, On Wed, Jan 07, 2026 at 08:34:39PM +0100, Marc Haber wrote: >I am wondering about the difference between ! and * in the password >field of /etc/shadow and before its invention in /etc/passwd. I think >that until some ten years ago, there was still a difference between >both, with one of the versions preventing login via password (but >keeping it possible to use, for example, an ssh key to log in) and the >other also making it impossible to use an ssh key to log in. I think >that one also prevented su'ing to that account. Thank you for this fruitful discussion that has taught me that this has never been formally specified, and that the different flavours of Unixoid operating systems are doing their own thing in their /etc/passwd. Short research also told me that the format of /etc/passwd or other backing stores for the user account database are nowadays neither part of POSIX nor of SuS. I have learned something. Your answers are appreciated. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From tuhs at tuhs.org Fri Jan 9 20:07:58 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 9 Jan 2026 21:07:58 +1100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: On Thu, Jan 08, 2026 at 10:59:19PM -0800, Tom Lyon via TUHS wrote: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. Didn't find the paper, but did find: "The UNIX operating system environment has found wide use in a variety of time sharing, word processing, and data processing applications. Until recently, it was only available on single processor computer systems but now has been successfully emulated by D. L. Bayer and A. M. Usas on a nonstop multiprocessor computer system built by the Tandem Computer Company" G. Bergland, "An Experimental Telecommunications Test Bed" IEEE Journal on Selected Areas in Communications, vol. 1, no. 2, pp 322-326 February 1983, doi: 10.1109/JSAC.1983.1145923 https://ieeexplore.ieee.org/document/1145923 https://ptacts.uspto.gov/ptacts/public-informations/petitions/1466094/download-documents?artifactId=rWIj0W0HCvPrieJC6vvVEuPvLJcNtW8P3UfHNTXqn4Kq5QZxf_KBc44 more papers mentioned in BSTJ: C on the Tandem 16. A. M. Usas, Proc Tandem Users Group Convention, San Diego, California, September 15-17, 1980 A Model for a Tandem Software Development System. A. M. Usas, Proc Tandem Users Group Convention, San Diego, California, September 15-17, 1980. from 'Bell Laboratories Talks and Papers, 1979', snippets on Google Books: Bayer DL, The Tandem 16 Computer System and the Tandem/Unix Project Usas AM, Emulation of Unix on a Tandem 16 https://cs.brown.edu/people/faculty/ausas/ mentions Alan worked at Tandem after Bell Labs "the list of versions of the Portable C Compiler (as of April 1979) includes: Data General Nova Honeywell 6000 IBM System /360 and /370 Intel 8086 Interdata 8/32 PDP11 Tandem 16 VAX11/780" from tuhs Documentation/Papers/lions_PCCpass2_jun1979.pdf From tuhs at tuhs.org Fri Jan 9 21:17:17 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 09 Jan 2026 04:17:17 -0700 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <202601091117.609BHH4s090682@freefriends.org> Marc Haber via TUHS wrote: > Short research also told me that the format of /etc/passwd > or other backing stores for the user account database are nowadays > neither part of POSIX nor of SuS. This is on purpose, IIUC. What is standardized is the C level routines getpwent() et al. This makes a lot of sense given that networked password and group databases have been around for a long time (Sun's NIS [nee YP], NIS+, and others.) Thus a local password file need not give the full story about all of the users who can login to a system. HTH, Arnold From tuhs at tuhs.org Fri Jan 9 21:56:31 2026 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Fri, 09 Jan 2026 06:56:31 -0500 Subject: [TUHS] UNIX on Tandem In-Reply-To: (message from Tom Lyon via TUHS on Thu, 8 Jan 2026 22:59:19 -0800) Message-ID: Tom Lyon via TUHS writes: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. I don't know if my experiences with the Tandem are what is being talked about in that paper, but given its apparent date, I suspect I was after it, but here is what I remember about using a Tandem. Some version of the Tandem was white boxed at AT&T as the Starserver (or Star Server or some such) in the late 1990s time frame. I believe that it came to be used in the product I was on for possibly two reasons, the first was it might have been mandated from higher up and the second is that the RBOC customers wanted "fault tolerance" or at least some computer system that behaved a bit like some of the switching gear. The Tandem that was used was certainly FT in most ways. The backplane was an active beast where boards could be pulled out and replaced while the system was running and it would continue to run. Nearly every board type, from CPU, to memory to disk controllers to power supplies had at at least one spare and the load would be moved to a spare if the system detected a fault. All that you saw was a console message indicating that a board was removed or failed or whatever. The Unix that ran on it was a modified SVR3, I believe, and the processor was some sort of MIPS, if my memory is still correct. The group I was in had mostly the white boxed Starserver version which was a 120v / 240v sort of thing. But Tandem did make a central office version that ran on DC and we did have one of those because one of the RBOC customers wanted to put our system in a real central office which ran on DC mostly. The systems continued to be reliable until they got very old and the complicated backplane started to get quirks in it. The backplane was one component that really didn't have a fault tolerate part to it, or at least not enough of one and when the backplane got bad enough the system was pretty much done and over with. A lot of the software groups at 6200 Broad St. used the Starserver / Tandem for the products that they worked on in the same time frame. Later, the RBOC customers decided that FT wasn't worth the cost of the systems and we moved the product to HP with a brief diversion over to NCR (or GIS or whatever NCR was called after it was bought) for a bit. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Fri Jan 9 23:58:35 2026 From: tuhs at tuhs.org (Arrigo Triulzi Lampugnani via TUHS) Date: Fri, 9 Jan 2026 14:58:35 +0100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: On 9 Jan 2026, at 12:56, Brad Spencer via TUHS wrote: > > Tom Lyon via TUHS writes: > >> Ran across this citation today. Anyone ever seen this paper? Known of the >> system? I'm pretty sure they're talking about Tandem(TM), not just >> generic tandem. >> >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >> Electron Conf, 34 (October 1980), pp 16-8. > Some version of the Tandem was white boxed at AT&T as the Starserver (or > Star Server or some such) in the late 1990s time frame. I believe that As a lapsed Tandem hand: in the late 90s it would have been an S-series which would indeed have been a MIPS processor. Before then Tandem had its own processor, the Cyclone, which survived into the K series of the mid-90s. It was a processor designed to work in lockstep, which is why they had modified MIPS w/o speculative execution for the S-series. In the ‘90s the “Unix” on NonStop Kernel (aka NSK) was USS, i.e. “Unix System Services”, which ran as a process over NSK and was used to run Java… I ported BIND to work under USS for my startup back then… I also destroyed the first iteration of the Parallel TCP/IP stack in their labs in Cupertino causing a huge testing Tandem to dump core to tape for a rather long time… oops. Arrigo From tuhs at tuhs.org Sat Jan 10 00:34:50 2026 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Fri, 9 Jan 2026 15:34:50 +0100 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: <4f45816f-4737-49e9-a950-efa33b734e9c@Julf.com> On 08/01/2026 10:36 pm, Tom Lyon via TUHS wrote: > the folks who have done a lot more hang out on Discord The curse of the modern internet - total community fragmentation. I miss the days of listserv, USENET and (perhaps) IRC. Julf From tuhs at tuhs.org Sat Jan 10 02:31:40 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Fri, 9 Jan 2026 11:31:40 -0500 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: FWIW, I ported the Software Tools tape (in Ratfor) to Guardian, Tandem's original OS, in the late 70s using their Fortran compiler. I also wrote an implementation of pipes on top of Tandem's proprietary IPC, a shell called Quadpoint (because the prompt was "::"), and a Lisp interpreter. All three were written in Tandem Application Language, a derivative of HP SPL/3000 with C-ish senantics but a syntax closer to Pascal. Unfortunately, none of this escaped $EMPLOYER, so it is lost. On Fri, Jan 9, 2026, 8:58 AM Arrigo Triulzi Lampugnani via TUHS < tuhs at tuhs.org> wrote: > On 9 Jan 2026, at 12:56, Brad Spencer via TUHS wrote: > > > > Tom Lyon via TUHS writes: > > > >> Ran across this citation today. Anyone ever seen this paper? Known of > the > >> system? I'm pretty sure they're talking about Tandem(TM), not just > >> generic tandem. > >> > >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > >> Electron Conf, 34 (October 1980), pp 16-8. > > Some version of the Tandem was white boxed at AT&T as the Starserver (or > > Star Server or some such) in the late 1990s time frame. I believe that > > As a lapsed Tandem hand: in the late 90s it would have been an S-series > which would indeed have been a MIPS processor. > > Before then Tandem had its own processor, the Cyclone, which survived into > the K series of the mid-90s. > > It was a processor designed to work in lockstep, which is why they had > modified MIPS w/o speculative execution for the S-series. > > In the ‘90s the “Unix” on NonStop Kernel (aka NSK) was USS, i.e. “Unix > System Services”, which ran as a process over NSK and was used to run Java… > > I ported BIND to work under USS for my startup back then… I also > destroyed the first iteration of the Parallel TCP/IP stack in their labs in > Cupertino causing a huge testing Tandem to dump core to tape for a rather > long time… oops. > > > Arrigo > > From tuhs at tuhs.org Sat Jan 10 02:40:40 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Fri, 9 Jan 2026 17:40:40 +0100 Subject: [TUHS] Updated installation instructions for v4 and v5, including B Message-ID: compiler Reply-To: Hi everyone, I have expanded my installation guide for UNIX v4 and wrote a similar one for v5 as well. While I was at it I also got my reconstructed B compiler running on both systems, there are instructions for that as well http://squoze.net/UNIX/v4/README http://squoze.net/UNIX/v5/README http://squoze.net/B/install Have fun, aap From tuhs at tuhs.org Sat Jan 10 02:57:44 2026 From: tuhs at tuhs.org (Michael Stiller via TUHS) Date: Fri, 9 Jan 2026 17:57:44 +0100 Subject: [TUHS] Updated installation instructions for v4 and v5, including B In-Reply-To: References: Message-ID: <3E80D069-E6AF-4B9D-9062-94DEE6AEF27B@me.com> Very cool Angelo. Kudos. Best regards, Michael > On 9. Jan 2026, at 17:40, Angelo Papenhoff via TUHS wrote: > > compiler > Reply-To: > > Hi everyone, > I have expanded my installation guide for UNIX v4 and wrote a similar one > for v5 as well. While I was at it I also got my reconstructed B compiler > running on both systems, there are instructions for that as well > > http://squoze.net/UNIX/v4/README > http://squoze.net/UNIX/v5/README > http://squoze.net/B/install > > Have fun, > aap From tuhs at tuhs.org Sat Jan 10 03:20:37 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Fri, 9 Jan 2026 09:20:37 -0800 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <202601060751.6067pTMI079021@freefriends.org> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> Message-ID: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> the fio stuff has been reimplemented many times over. the marginal improvement it made was mostly in how the normal API was tweaked. what struck me in rereading the paper was a refererral to large files beng greater than 10MB. hahahahahaha > On Jan 5, 2026, at 11:51 PM, Arnold Robbins via TUHS wrote: > > Thalia Archibald via TUHS wrote: > >> On Jan 5, 2026, at 09:15, Dan Cross wrote: >>> Does anyone have a copy of the paper mentioned in the subject? >> >> >> Wiley has the authoritative online copy (accessible via Sci-Hub) >> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 >> and Erica Fischer uploaded a scan to the Internet Archive >> https://archive.org/details/tale-of-two-greps >> >> Thalia >> > > Thanks, that was an interesting read. > > Doug / Andrew -- is the fio library mentioned in the paper around > anywhere? Or did it evolve into Plan 9's Bio library? > > Thanks, > > Arnold From tuhs at tuhs.org Sat Jan 10 03:38:43 2026 From: tuhs at tuhs.org (Heinz Lycklama via TUHS) Date: Fri, 9 Jan 2026 09:38:43 -0800 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <64e283d8-d093-4891-be23-366360a921ae@osta.com> I do remember that Doug Bayer and Alan Usas worked on the UNIX system on the Tandem computer system in the late 1970's at BTL after I had left BTL to join ISC in mid-1978, but I do not recall all the details of that system. Doug and I developed the MERT system at BTL in the mid 1970's. I also had occasion to re-acquaint with Alan during his time at Tandem in the mid 1990's where he had continued to develop UNIX software on the latest Tandem hardware and software at the time, and I was involved in various consulting projects for Tandem. Heinz On 1/9/2026 2:07 AM, Jonathan Gray via TUHS wrote: > On Thu, Jan 08, 2026 at 10:59:19PM -0800, Tom Lyon via TUHS wrote: >> Ran across this citation today. Anyone ever seen this paper? Known of the >> system? I'm pretty sure they're talking about Tandem(TM), not just >> generic tandem. >> >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >> Electron Conf, 34 (October 1980), pp 16-8. > Didn't find the paper, but did find: > > "The UNIX operating system environment has found wide use in a variety > of time sharing, word processing, and data processing applications. > Until recently, it was only available on single processor computer > systems but now has been successfully emulated by D. L. Bayer and > A. M. Usas on a nonstop multiprocessor computer system built by the Tandem > Computer Company" > > G. Bergland, "An Experimental Telecommunications Test Bed" > IEEE Journal on Selected Areas in Communications, vol. 1, no. 2, pp 322-326 > February 1983, doi: 10.1109/JSAC.1983.1145923 > https://ieeexplore.ieee.org/document/1145923 > https://ptacts.uspto.gov/ptacts/public-informations/petitions/1466094/download-documents?artifactId=rWIj0W0HCvPrieJC6vvVEuPvLJcNtW8P3UfHNTXqn4Kq5QZxf_KBc44 > > more papers mentioned in BSTJ: > C on the Tandem 16. A. M. Usas, > Proc Tandem Users Group Convention, San Diego, California, > September 15-17, 1980 > > A Model for a Tandem Software Development System. A. M. Usas, > Proc Tandem Users Group Convention, San Diego, California, > September 15-17, 1980. > > from 'Bell Laboratories Talks and Papers, 1979', snippets on Google Books: > Bayer DL, The Tandem 16 Computer System and the Tandem/Unix Project > Usas AM, Emulation of Unix on a Tandem 16 > > https://cs.brown.edu/people/faculty/ausas/ > mentions Alan worked at Tandem after Bell Labs > > "the list of versions of the Portable C Compiler (as of April 1979) includes: > Data General Nova > Honeywell 6000 > IBM System /360 and /370 > Intel 8086 > Interdata 8/32 > PDP11 > Tandem 16 > VAX11/780" > from tuhs Documentation/Papers/lions_PCCpass2_jun1979.pdf From tuhs at tuhs.org Sat Jan 10 03:49:06 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 09 Jan 2026 17:49:06 +0000 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: Interesting. Having been around a bunch of odd-ball paralel systems (built a Purdue Dual-VAX, ported UNIX to the Denelcor HEP and designed its I/O system, worked wth 3B20s, etc) I always looked at other architectures. Tandem’s architecture was an interesting one, but I had not heard of a UNIX port to it. Had it’s own, unlike anything else, OS called TOS or something. Parallelism on the Tandem was really designed for reliability as opposed to outright multiplication of computer power (sort of like some of the Western stuff). It’s kind of the predecessor to some of the large scale cloud stuff today. I’d be interested in the paper if anybody can dig it up. ------ Original Message ------ >From "Tom Lyon via TUHS" To "TUHS main list" Date 1/9/2026 1:59:19 AM Subject [TUHS] UNIX on Tandem >Ran across this citation today. Anyone ever seen this paper? Known of the >system? I'm pretty sure they're talking about Tandem(TM), not just >generic tandem. > >A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >Electron Conf, 34 (October 1980), pp 16-8. From tuhs at tuhs.org Sat Jan 10 03:52:00 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Fri, 9 Jan 2026 09:52:00 -0800 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: On 1/9/26 09:20, andrew--- via TUHS wrote: > what struck me in rereading the paper was a refererral to large files beng greater than 10MB. > hahahahahaha When we were going through all the programs in Solaris to port them to 64-bit as the first step in our Y2038-readiness, we decided that we could EOL the bfs command, as we no longer needed a special read only version of ed for which "Files can be up to 1024K bytes and 32K lines, with up to 512 characters, including new-line, per line (255 for 16-bit machines)." https://docs.oracle.com/cd/E86824_01/html/E54763/bfs-1.html We seem to have inherited it from SVR4, and I see a copy in the SVR3 source tree - I'm not sure how far back before that it was created. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Sat Jan 10 04:38:12 2026 From: tuhs at tuhs.org (Paul McJones via TUHS) Date: Fri, 9 Jan 2026 10:38:12 -0800 Subject: [TUHS] UNIX on Tandem In-Reply-To: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> Message-ID: <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> > Tandem’s architecture was an interesting one, but I had > not heard of a UNIX port to it. Had it’s own, unlike anything else, OS > called TOS or something. The operating system was called GUARDIAN. The manuals are available here: https://bitsavers.org/pdf/tandem/ And this is an SOSP’81 paper about the design of the operating system: https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 04:39:58 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 09 Jan 2026 18:39:58 +0000 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: On Friday, January 9th, 2026 at 09:52, Alan Coopersmith via TUHS wrote: > On 1/9/26 09:20, andrew--- via TUHS wrote: > > > what struck me in rereading the paper was a refererral to large files beng greater than 10MB. > > hahahahahaha > > > When we were going through all the programs in Solaris to port them to 64-bit > as the first step in our Y2038-readiness, we decided that we could EOL the > bfs command, as we no longer needed a special read only version of ed > for which "Files can be up to 1024K bytes and 32K lines, with up to > 512 characters, including new-line, per line (255 for 16-bit machines)." > > https://docs.oracle.com/cd/E86824_01/html/E54763/bfs-1.html > > We seem to have inherited it from SVR4, and I see a copy in the SVR3 source > tree - I'm not sure how far back before that it was created. > > -- > -Alan Coopersmith- alan.coopersmith at oracle.com > Oracle Solaris Engineering - https://blogs.oracle.com/solaris Earliest bfs(1) I can find is in PWB: https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/man/man1/bfs.1 This cemented it in the PWB-to-commercial line from 1977 on. For the record, bfs(1) is not in USG PG-II or PG-III so is likely squarely from PWB. - Matt G. From tuhs at tuhs.org Sat Jan 10 04:42:16 2026 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Fri, 9 Jan 2026 12:42:16 -0600 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> On 1/9/2026 12:59 AM, Tom Lyon via TUHS wrote: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. Doug Jewett and other people instrumental in the early days of AIX went on to Tandem in Austin to create the Tandem S2 (MIPS-based) hardware and a fault-tolerant reworked version of SVR3 for that hardware. Doug suggests that Peter Norwood's paper at https://archive.org/details/tandemsr7-1/page/n11/mode/2up is likely the best introduction. Doug also suggests "This paper touches on some of the hardware and the software aspects of S2: D. Jewett, "Integrity S2: A Fault-Tolerant Unix Platform," Proc. 21st International Symposium Fault-Tolerant Computing, July 1991." However, I don't know of an accessible version of that reference. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Sat Jan 10 05:34:20 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Fri, 9 Jan 2026 14:34:20 -0500 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: Is that 10MB per record, Andrew? :-) ===== mindthegapdialogs.com north-fork.info On Fri, Jan 9, 2026 at 12:20 PM andrew--- via TUHS wrote: > the fio stuff has been reimplemented many times over. > the marginal improvement it made was mostly in how the normal API was > tweaked. > > what struck me in rereading the paper was a refererral to large files beng > greater than 10MB. > hahahahahaha > > > > On Jan 5, 2026, at 11:51 PM, Arnold Robbins via TUHS > wrote: > > > > Thalia Archibald via TUHS wrote: > > > >> On Jan 5, 2026, at 09:15, Dan Cross wrote: > >>> Does anyone have a copy of the paper mentioned in the subject? > >> > >> > >> Wiley has the authoritative online copy (accessible via Sci-Hub) > >> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > >> and Erica Fischer uploaded a scan to the Internet Archive > >> https://archive.org/details/tale-of-two-greps > >> > >> Thalia > >> > > > > Thanks, that was an interesting read. > > > > Doug / Andrew -- is the fio library mentioned in the paper around > > anywhere? Or did it evolve into Plan 9's Bio library? > > > > Thanks, > > > > Arnold > > From tuhs at tuhs.org Sat Jan 10 06:22:22 2026 From: tuhs at tuhs.org (Ronald Natalie via TUHS) Date: Fri, 09 Jan 2026 20:22:22 +0000 Subject: [TUHS] UNIX on Tandem In-Reply-To: <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> Message-ID: I guess T/TOS was the original name (Tandem / Transaction Operating System) but they tossed it for Guradian. ------ Original Message ------ From "Paul McJones" To "Ron Natalie" Cc tuhs at tuhs.org Date 1/9/2026 1:38:12 PM Subject Re: [TUHS] Re: UNIX on Tandem >>Tandem’s architecture was an interesting one, but I had >>not heard of a UNIX port to it. Had it’s own, unlike anything else, >>OS >>called TOS or something. > >The operating system was called GUARDIAN. The manuals are available >here: > >https://bitsavers.org/pdf/tandem/ > >And this is an SOSP’81 paper about the design of the operating system: > >https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 06:41:28 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 9 Jan 2026 13:41:28 -0700 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> Message-ID: I thought it was NONSTOP at one point... Warner On Fri, Jan 9, 2026 at 1:22 PM Ronald Natalie via TUHS wrote: > I guess T/TOS was the original name (Tandem / Transaction Operating > System) but they tossed it for Guradian. > > > ------ Original Message ------ > From "Paul McJones" > To "Ron Natalie" > Cc tuhs at tuhs.org > Date 1/9/2026 1:38:12 PM > Subject Re: [TUHS] Re: UNIX on Tandem > > >>Tandem’s architecture was an interesting one, but I had > >>not heard of a UNIX port to it. Had it’s own, unlike anything else, > >>OS > >>called TOS or something. > > > >The operating system was called GUARDIAN. The manuals are available > >here: > > > >https://bitsavers.org/pdf/tandem/ > > > >And this is an SOSP’81 paper about the design of the operating system: > > > >https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 07:05:40 2026 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Fri, 9 Jan 2026 22:05:40 +0100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <7FB2195E-E052-4EA1-9F6E-1AF38ECE31F7@alchemistowl.org> > On 9 Jan 2026, at 21:42, Warner Losh via TUHS wrote: > > I thought it was NONSTOP at one point... It was NONSTOP KERNEL (abbreviated NSK) in the ‘90 when Compaq/Digital bought them. Then HP bought them and it was all over. GUARDIAN was still there as was TACL. They were porting from MIPS to Alpha and then they were in the process of going to … Itanium (enter obligatory scream). Arrigo From tuhs at tuhs.org Sat Jan 10 08:42:04 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Sat, 10 Jan 2026 08:42:04 +1000 Subject: [TUHS] UNIX on Tandem In-Reply-To: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> References: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> Message-ID: I worked briefly with a non-stop set-up long after this. What sold them to corporates was (in my opinion) both fault tolerant design and an SLA. An australian engineer in telecommunications of that era told me they ran their metropolitan area network as a fault tolerant dual ring, and like tandem had to tell Sales droids to STOP pulling line cards (CPU cards for tandem) in front of prospective buyers, because it triggered an automatic fault report and spares shipment cross country. It's probably urban myth with an element of maybe true. Yes, the design was about redundancy but the sell was gold era IBM managed services: you bought a package. G On Sat, 10 Jan 2026, 4:42 am Charles H Sauer (he/him) via TUHS, < tuhs at tuhs.org> wrote: > On 1/9/2026 12:59 AM, Tom Lyon via TUHS wrote: > > Ran across this citation today. Anyone ever seen this paper? Known of > the > > system? I'm pretty sure they're talking about Tandem(TM), not just > > generic tandem. > > > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > > Electron Conf, 34 (October 1980), pp 16-8. > > Doug Jewett and other people instrumental in the early days of AIX went > on to Tandem in Austin to create the Tandem S2 (MIPS-based) hardware and > a fault-tolerant reworked version of SVR3 for that hardware. > > Doug suggests that Peter Norwood's paper at > https://archive.org/details/tandemsr7-1/page/n11/mode/2up is likely the > best introduction. > > Doug also suggests "This paper touches on some of the hardware and the > software aspects of S2: D. Jewett, "Integrity S2: A Fault-Tolerant Unix > Platform," Proc. 21st International Symposium Fault-Tolerant Computing, > July 1991." However, I don't know of an accessible version of that > reference. > > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/mas.to > : > CharlesHSauer > >