From tuhs at tuhs.org Sun Feb 1 11:54:53 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 1 Feb 2026 11:54:53 +1000 Subject: [TUHS] Boston Children's Museum RK05 Driver: Questions Message-ID: Hi all, for some reason I thought about the RK05 driver written by Bill Mayhew and Brent Byer at the Boston Children's Museum. Based on the minor device number, it remaps blocks 1 to 2435 as blocks 2436 to 4871, and remaps blocks 2436 to 4871 down to blocks 1 to 2435. According to the notes in the driver (see dmr/rk.c in https://www.tuhs.org/Archive/Distributions/UNSW/1/record0.tar.gz): The effect of this mapping is to centralize disk head motion about the center of the disk. The optimization is ideal for those RK's which serve as both root device and swap device. It is less than ideal, although probably still an improvement over traditional form, for RK's used exclusively as mounted file systems. Question: how much of a win was this, and why was the idea of moving (some/all) of the i-nodes to the centre of the disk not used until we got the fast filesystem? Cheers, Warren From tuhs at tuhs.org Sun Feb 1 14:03:19 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 1 Feb 2026 15:03:19 +1100 Subject: [TUHS] Mix Utah V4 and the V4 Man Pages In-Reply-To: References: Message-ID: On Sat, Jan 31, 2026 at 07:52:22AM +1000, Warren Toomey via TUHS wrote: > On 1/29/26 9:57 PM, Warren Toomey via TUHS wrote: > > Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: > > > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > > > > And it's also now in the Unix Tree at > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 > > On Fri, Jan 30, 2026 at 06:08:30PM +0000, segaloco via TUHS wrote: > > Regarding the V4 manpage sources, would it be appropriate to merge those > > with this entry in the tree at /usr/man? At the very least the blurb on > > the root directory should then probably mention the providence of the > > two pieces and their being amalgamated for tree reasons. > > I wasn't sure if I should mix the V4 manuals from > https://www.tuhs.org/Archive/Distributions/Research/Dennis_v4/ > with the Utah tape as there is no nroff on the Utah tape but > the man pages are written in nroff. > > But, yes, I can add some blurb that explains the amalgamation. > > So, a related question, does anybody know why nroff was _not_ on the > Utah V4 tape, especially as it was a late snapshot of V4? Documented as not being on the tape: "The following programs out of the programmer's manual are not provided: catsim(I), man(I), nroff(I), opr(I), plot(I), speak(I), troff(I), tss(I), gerts(III), vt(III), azel(VI), m6(VI), maze(VI), ov(VI), sky(VI), spline(VI), tmg(VI), yacc(VI), dpd(VII), tmheader(VII), vs(VII), 20boot(VIII) and update(VIII). The source of the following programs from the manual is not provided: cref(I), proof(I), bj(VI), chess(VI), cubic(VI), moo(VI), ttt(VI) and wump(VI)." https://www.tuhs.org/Archive/Applications/Dennis_Tapes/Gao_Analysis/v4_dist/setup.pdf Though the Utah tape has a yacc binary and update. From tuhs at tuhs.org Sun Feb 1 15:59:55 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 01 Feb 2026 05:59:55 +0000 Subject: [TUHS] Mix Utah V4 and the V4 Man Pages In-Reply-To: References: Message-ID: On Saturday, January 31st, 2026 at 20:03, Jonathan Gray via TUHS wrote: > On Sat, Jan 31, 2026 at 07:52:22AM +1000, Warren Toomey via TUHS wrote: > > > On 1/29/26 9:57 PM, Warren Toomey via TUHS wrote: > > > > > Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: > > > > > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > > > > > > And it's also now in the Unix Tree at > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 > > > > On Fri, Jan 30, 2026 at 06:08:30PM +0000, segaloco via TUHS wrote: > > > > > Regarding the V4 manpage sources, would it be appropriate to merge those > > > with this entry in the tree at /usr/man? At the very least the blurb on > > > the root directory should then probably mention the providence of the > > > two pieces and their being amalgamated for tree reasons. > > > > I wasn't sure if I should mix the V4 manuals from > > https://www.tuhs.org/Archive/Distributions/Research/Dennis_v4/ > > with the Utah tape as there is no nroff on the Utah tape but > > the man pages are written in nroff. > > > > But, yes, I can add some blurb that explains the amalgamation. > > > > So, a related question, does anybody know why nroff was not on the > > Utah V4 tape, especially as it was a late snapshot of V4? > > > Documented as not being on the tape: > > "The following programs out of the programmer's manual are not > provided: catsim(I), man(I), nroff(I), opr(I), plot(I), speak(I), > troff(I), tss(I), gerts(III), vt(III), azel(VI), m6(VI), > maze(VI), ov(VI), sky(VI), spline(VI), tmg(VI), yacc(VI), > dpd(VII), tmheader(VII), vs(VII), 20boot(VIII) and update(VIII). > > The source of the following programs from the manual is not > provided: cref(I), proof(I), bj(VI), chess(VI), cubic(VI), > moo(VI), ttt(VI) and wump(VI)." > > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/Gao_Analysis/v4_dist/setup.pdf > > Though the Utah tape has a yacc binary and update. Actually, what is the "man.tap" available here? https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ I'm not somewhere I can dig around more than with od, certainly looks like there are manpage sources in there. >From the looks of it, nroff was missing from other, earlier versions as well. For instance, the s1/s2 bits tapes don't appear to have nroff present despite it being in the V2 manual. Is it known whether nroff was primarily developed on the "trunk" MH PDP-11 or if it might have lived elsewhere, leading to it not getting swept along for the tapes cut for external users? - Matt G. From tuhs at tuhs.org Sun Feb 1 21:09:00 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Sun, 1 Feb 2026 12:09:00 +0100 Subject: [TUHS] Mix Utah V4 and the V4 Man Pages In-Reply-To: References: Message-ID: That would be the Dennis_V4 manual source which i've put onto a tape so you can load it on V4 and have a usable manual (i included nroff from v6 in my "distro" too), see my expanded guide at http://squoze.net/UNIX/v4/README aap > Actually, what is the "man.tap" available here? > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > > I'm not somewhere I can dig around more than with od, certainly looks > like there are manpage sources in there. > > From the looks of it, nroff was missing from other, earlier versions > as well. For instance, the s1/s2 bits tapes don't appear to have nroff > present despite it being in the V2 manual. Is it known whether nroff > was primarily developed on the "trunk" MH PDP-11 or if it might have > lived elsewhere, leading to it not getting swept along for the tapes cut > for external users? > > - Matt G. From tuhs at tuhs.org Mon Feb 2 02:43:16 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Sun, 1 Feb 2026 11:43:16 -0500 Subject: [TUHS] Boston Children's Museum RK05 Driver: Questions In-Reply-To: References: Message-ID: On Sat, Jan 31, 2026 at 9:01 PM Warren Toomey via TUHS wrote: > > Question: how much of a win was this, and why was the idea of moving > (some/all) of the i-nodes to the centre of the disk not used until > we got the fast filesystem? > > It was not uncommon to have unconventional data placement schemes on disk files to minimize head movement. IBM's compilers used something called split cylinder allocation for their compilers' three scratch files. Instead of having a contiguous set of cylinders for each file, each cylinder was split between the three scratch files (for example, file #1 using heads 1-3, file #2 heads 5-7, etc.). This allowed the compiler to use the three files simultaneously with little or no head movement. I imagine that by the time the fast filesystem came along memory was cheap and plentiful enough to allow sufficient caching (both in the disk controller and by the driver) to mitigate most head motion delays for frequently accessed data structures such as inodes. -Paul W. From tuhs at tuhs.org Tue Feb 3 08:23:58 2026 From: tuhs at tuhs.org (Diomidis Spinellis via TUHS) Date: Tue, 3 Feb 2026 00:23:58 +0200 Subject: [TUHS] Unix v4 tape FOSDEM talk Message-ID: I gave a short talk at FOSDEM 2026 on integrating the v4 tape into the GitHub Unix history repository. It's now available online at https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/DCDAUY-the_v4_tape_in_the_unix_history_repo.av1.webm Diomidis - https://www.spinellis.gr From tuhs at tuhs.org Tue Feb 3 09:22:16 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 2 Feb 2026 16:22:16 -0700 Subject: [TUHS] Unix v4 tape FOSDEM talk In-Reply-To: References: Message-ID: Thanks for posting this. This was an awesome presentation. Warner On Mon, Feb 2, 2026, 3:24 PM Diomidis Spinellis via TUHS wrote: > I gave a short talk at FOSDEM 2026 on integrating the v4 tape into the > GitHub Unix history repository. It's now available online at > > https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/DCDAUY-the_v4_tape_in_the_unix_history_repo.av1.webm > > > Diomidis - https://www.spinellis.gr > From tuhs at tuhs.org Wed Feb 4 22:32:05 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 04 Feb 2026 12:32:05 +0000 Subject: [TUHS] Unix v4 tape FOSDEM talk In-Reply-To: References: Message-ID: Διομήδης, I second Warner's comment. I finally got a chance to sit down and watch your presentation. It was perfect. Thank you for sharing it. Με εκτίμηση, Cameron -------- Original Message -------- On Monday, 02/02/26 at 23:22 Warner Losh via TUHS wrote: Thanks for posting this. This was an awesome presentation. Warner On Mon, Feb 2, 2026, 3:24 PM Diomidis Spinellis via TUHS wrote: > I gave a short talk at FOSDEM 2026 on integrating the v4 tape into the > GitHub Unix history repository. It's now available online at > > https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/DCDAUY-the_v4_tape_in_the_unix_history_repo.av1.webm > > > Diomidis - https://www.spinellis.gr > From tuhs at tuhs.org Wed Feb 4 23:18:26 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Wed, 4 Feb 2026 14:18:26 +0100 Subject: [TUHS] Unix v4 tape FOSDEM talk In-Reply-To: References: Message-ID: Thanks for the talk Diomidis! only one thing was weird: the v4 kernel was not written in New B, already the language of the last1120c compiler was called C. >From (what i claim is) New B we only have a few binary commands in a threaded code that deals with bytes, so very early-C-like semantics. See http://squoze.net/NB/ cheers, aap On 03/02/26, Diomidis Spinellis via TUHS wrote: > I gave a short talk at FOSDEM 2026 on integrating the v4 tape into the > GitHub Unix history repository. It's now available online at > https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/DCDAUY-the_v4_tape_in_the_unix_history_repo.av1.webm > > > Diomidis - https://www.spinellis.gr From tuhs at tuhs.org Fri Feb 6 02:00:58 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Thu, 5 Feb 2026 11:00:58 -0500 Subject: [TUHS] Unix v4 tape FOSDEM talk In-Reply-To: References: Message-ID: <8e16d2f1-ff73-4a3c-a6e4-f8f74a6a982c@gmail.com> Diomidis, Amazing talk! Still in the process of watching, but I wanted to send you a note to thank you for the call out! Excellent and informative presentation! -- Briam R. On 2/2/26 5:23 PM, Diomidis Spinellis via TUHS wrote: > I gave a short talk at FOSDEM 2026 on integrating the v4 tape into the > GitHub Unix history repository.  It's now available online at > https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/DCDAUY-the_v4_tape_in_the_unix_history_repo.av1.webm > > > Diomidis - https://www.spinellis.gr From tuhs at tuhs.org Fri Feb 6 22:10:44 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 06 Feb 2026 14:10:44 +0200 Subject: [TUHS] "A Supplemental Document For Awk" - now on github Message-ID: <202602061210.616CAmdV040391@freefriends.org> Hi All. In the mid-1980s, John W. Pierce's "A Supplementatl Document For Awk" circulated on USENET. I decided to put this document up on USENET for its historical interest. It formats just fine with groff. See https://github.com/arnoldrobbins/awksupp if you're interested. Arnold From tuhs at tuhs.org Fri Feb 6 22:11:28 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 06 Feb 2026 14:11:28 +0200 Subject: [TUHS] "A Supplemental Document For Awk" - now on github Message-ID: <202602061211.616CBVP0040442@freefriends.org> > I decided to put this document up on USENET ... s/USENET/GitHub/ Sorry, Arnold From tuhs at tuhs.org Sat Feb 7 02:01:46 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Fri, 6 Feb 2026 08:01:46 -0800 Subject: [TUHS] inodes, inumbers, and versions Message-ID: At some point there was an issue around inumbers being recycled, such that a file might be opened, have an inumber that had been used, and confusion followed. IIRC, there was a version field that was added to the inode (?), so protect against this. I'm sure I've got lots of this wrong. It was a long time ago and the neurons are dead. My question: in our modern era :-), I assume all inumbers are 64 bits, and, for a given file system, never reused? Is that a safe assumption? This has come up as part of a question involving user-mode 9p servers. thanks From tuhs at tuhs.org Sat Feb 7 02:26:33 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Fri, 6 Feb 2026 08:26:33 -0800 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: Sounds like more of a problem with NFS file handles - the server doesn't keep track of what's open. On Fri, Feb 6, 2026 at 8:02 AM ron minnich via TUHS wrote: > At some point there was an issue around inumbers being recycled, such that > a file might be opened, have an inumber that had been used, and confusion > followed. > > IIRC, there was a version field that was added to the inode (?), so protect > against this. > > I'm sure I've got lots of this wrong. It was a long time ago and the > neurons are dead. > > My question: in our modern era :-), I assume all inumbers are 64 bits, and, > for a given file system, never reused? Is that a safe assumption? > > This has come up as part of a question involving user-mode 9p servers. > > thanks > From tuhs at tuhs.org Sat Feb 7 03:34:14 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 6 Feb 2026 09:34:14 -0800 Subject: [TUHS] CHM Unix recovery video Message-ID: <7f125b23-57e1-a632-67ae-6dc9da0a199d@bitsavers.org> featuring Warren at the end... Computer History Museum Recovers Rare UNIX History: https://youtu.be/-xlq_MPWNKk From tuhs at tuhs.org Sat Feb 7 03:53:22 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 6 Feb 2026 09:53:22 -0800 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: > On Feb 6, 2026, at 8:01 AM, ron minnich via TUHS wrote: > > At some point there was an issue around inumbers being recycled, such that > a file might be opened, have an inumber that had been used, and confusion > followed. An opened file's dir entry may be removed but its inode would not be removed until its refcount (number of opens) drops to zero so no such confusion. > IIRC, there was a version field that was added to the inode (?), so protect > against this. This was likely added for the "stateless" NFS to deal with "ABA problem". From tuhs at tuhs.org Sat Feb 7 04:14:44 2026 From: tuhs at tuhs.org (Ronald Natalie via TUHS) Date: Fri, 06 Feb 2026 18:14:44 +0000 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: The inode is the essence of the file (pretty much everything other than its name). If it got reused while someone was still referencing it they got the wrong file. The inodes kept a reffence count of the number of directory entries that referred to it so it knew when to deallocate it. There was no “owner” directory, all links to an inode were the same. After a crash, in the early days, you would run dcheck which would scan through all the directories on the system and count references tt and then check that against the reference count in the inode. The most common discrepency was that the reference count in both places would go to zero but for whatever reason (most likely the file was being held open at the crash). You’d have to manually run clri to mark it unused. There was a 100 element inode freelist in the superblock, but unlike the data block freelist, it wasn’t linked to more free items. Once the 100 were used up, the kernel scanned all the inodes looking for freeones to repopulate the list. Eventually, we got fsck, and the systems stopped crashing so much. However, it was required to understand the filesystem and the various tools: icheck, dcheck, ncheck, clri, etc... It wasn’t until later (Berkeley, I think) that someone overhauled the filesystem code to assure that things were ordered in a way that never left the filesystem in a degenerate state on crashing. ------ Original Message ------ >From "ron minnich via TUHS" To "The Eunuchs Hysterical Society" Date 2/6/2026 11:01:46 AM Subject [TUHS] inodes, inumbers, and versions >At some point there was an issue around inumbers being recycled, such that >a file might be opened, have an inumber that had been used, and confusion >followed. > >IIRC, there was a version field that was added to the inode (?), so protect >against this. > >I'm sure I've got lots of this wrong. It was a long time ago and the >neurons are dead. > >My question: in our modern era :-), I assume all inumbers are 64 bits, and, >for a given file system, never reused? Is that a safe assumption? > >This has come up as part of a question involving user-mode 9p servers. > >thanks From tuhs at tuhs.org Sat Feb 7 04:33:12 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 6 Feb 2026 10:33:12 -0800 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: <20260206183312.GA16693@mcvoy.com> > It wasn???t until later (Berkeley, I think) that someone overhauled the > filesystem code to assure that things were ordered in a way that never left > the filesystem in a degenerate state on crashing. That feature was not in the first UFS in BSD nor was it in SunOS. Want to nuke your filesystem? Untar a tarball and pull power while that was running. Left a huge mess. ZFS did something about this. From tuhs at tuhs.org Sat Feb 7 04:45:38 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 6 Feb 2026 10:45:38 -0800 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: > On Feb 6, 2026, at 10:14 AM, Ronald Natalie via TUHS wrote: > > The inode is the essence of the file (pretty much everything other than its name). If it got reused while someone was still referencing it they got the wrong file. The in-core refcount of # of opens (i_count, not i_nlink) protects against this. Even if you do "rm foo", foo's inode is not freed if someone has foo open. Its inode is freed only after the last close. [Least how it was in v7). You do have ensure that the FS structure is consistent after a crash. From tuhs at tuhs.org Sat Feb 7 05:05:11 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 6 Feb 2026 14:05:11 -0500 Subject: [TUHS] inodes, inumbers, and versions In-Reply-To: References: Message-ID: below On Fri, Feb 6, 2026 at 1:14 PM Ronald Natalie via TUHS wrote: > ... > It wasn’t until later (Berkeley, I think) that someone overhauled the > filesystem code to assure that things were ordered in a way that never > left the filesystem in a degenerate state on crashing. > It was George Goble at Purdue who did the work to "harden" the file system in the original 4.1BSD code in approx 1980 [which was pushed back to UCB and was first included in BSD4.1A]. Besides the Dual Vax, George spliced a PDP-11 into the memory bus of one of his Vaxes and wrote a really neat memory analyzer/kernel debugger [which, sadly, was before USENIX had formal papers and may be lost to time]. Using it, he found several races and at least one zero-day issue in 4.1, all of which led up to his dual-CPU "Purdue Vax," a paper all its own. I remember the USENIX meeting (after he found ther zero-day), he had an invite-only/closed-door meeting with about 10-15 of the major UNIX systems people, and he explained it and the fix [Unix had a reputation of being secure, and this was the time of the UNIX *vs.* VMS fights in many places and George was worried that if the zero-day got out, it would hurt the reputation of not being "production quality."] IIRC, the changes for both file system hardening and this fix were in a Purdue directory on one of the USENIX tapes [although I may have had them at Tektronix directly from George]. From tuhs at tuhs.org Sat Feb 7 05:31:48 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 6 Feb 2026 14:31:48 -0500 Subject: [TUHS] CHM Unix recovery video In-Reply-To: <7f125b23-57e1-a632-67ae-6dc9da0a199d@bitsavers.org> References: <7f125b23-57e1-a632-67ae-6dc9da0a199d@bitsavers.org> Message-ID: Very nicely done. Thank you. Clem On Fri, Feb 6, 2026 at 12:34 PM Al Kossow via TUHS wrote: > featuring Warren at the end... > > Computer History Museum Recovers Rare UNIX History: > https://youtu.be/-xlq_MPWNKk > From tuhs at tuhs.org Mon Feb 9 20:35:51 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 09 Feb 2026 12:35:51 +0200 Subject: [TUHS] Portable C Compiler Revived - Revived! Message-ID: <202602091035.619AZrnF079020@freefriends.org> Hi All. To anyone who's interested, the revived version of the venerable Portable C Compiler (PCC) is available on GitHub. See https://github.com/PortableCC. The original system hosting this project became unavailable (IIRC) in October of 2023. A while back Anders Magnusson put the whole history of PCC up on Github, but at the time it had a number of bugs and I was not able to use it to compile gawk. :-( However, as of today, the various bugs that were blocking me are fixed. So I thought I might mention it here on this list. Enjoy, Arnold