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 From tuhs at tuhs.org Tue Feb 10 02:05:38 2026 From: tuhs at tuhs.org (Daria Phoebe Brashear via TUHS) Date: Mon, 9 Feb 2026 11:05:38 -0500 Subject: [TUHS] Siemens RTL window manager Message-ID: Every time I spend time manually tiling windows, I think about the Siemens RTL Window Manager. Despite being approximately X11R4 years old in terms of coming to Unix, binaries of this built from X11R3-contrib were still floating around when I started exploring things past the base environment we were provided; Like the Andrew Window Manager and the port for X11, the source for this was lost for a while but unlike wmc, someone found, patched and shared a copy of the source a while back(+), and I dug out my copy again recently to hopefully play with. Lest the tarball ever become unavailable at the URL from the email, I've pushed a copy to GitHub here: https://github.com/dariaphoebe/rtl-wm + https://lists.suckless.org/dev/1112/10398.html -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com From tuhs at tuhs.org Tue Feb 10 12:20:04 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Mon, 9 Feb 2026 21:20:04 -0500 Subject: [TUHS] Siemens RTL window manager In-Reply-To: References: Message-ID: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> Took a bit to get it to crank over, and the mouse support is a bit janky (def. not made for a trackpad!) but happy to report it compiles on macos 26.2 using xquartz. If anyone's interested i can supply the patches. -- Briam R. On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: > Every time I spend time manually tiling windows, I think about the > Siemens RTL Window Manager. Despite being approximately X11R4 years > old in terms of coming to Unix, binaries of this built from > X11R3-contrib were still floating around when I started exploring > things past the base environment we were provided; Like the Andrew > Window Manager and the port for X11, the source for this was lost for > a while but unlike wmc, someone found, patched and shared a copy of > the source a while back(+), and I dug out my copy again recently to > hopefully play with. > > Lest the tarball ever become unavailable at the URL from the email, > I've pushed a copy to GitHub here: > https://github.com/dariaphoebe/rtl-wm > > > +https://lists.suckless.org/dev/1112/10398.html > From tuhs at tuhs.org Tue Feb 10 12:51:01 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Mon, 9 Feb 2026 18:51:01 -0800 Subject: [TUHS] Siemens RTL window manager In-Reply-To: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> Message-ID: <20260210025101.GN13898@mcvoy.com> Does anyone remeber ctwm an offshoot of twm? I ran ctwm for years, finally gave in when I switched to Xubuntu and used their manager. Did so because what I was doing was weird and all sorts of stuff didn't work, xubuntu just works. On Mon, Feb 09, 2026 at 09:20:04PM -0500, Briam Rodriguez via TUHS wrote: > Took a bit to get it to crank over, and the mouse support is a bit janky > (def. not made for a trackpad!) but happy to report it compiles on macos > 26.2 using xquartz. > > If anyone's interested i can supply the patches. > > -- Briam R. > > On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: > >Every time I spend time manually tiling windows, I think about the > >Siemens RTL Window Manager. Despite being approximately X11R4 years > >old in terms of coming to Unix, binaries of this built from > >X11R3-contrib were still floating around when I started exploring > >things past the base environment we were provided; Like the Andrew > >Window Manager and the port for X11, the source for this was lost for > >a while but unlike wmc, someone found, patched and shared a copy of > >the source a while back(+), and I dug out my copy again recently to > >hopefully play with. > > > >Lest the tarball ever become unavailable at the URL from the email, > >I've pushed a copy to GitHub here: > >https://github.com/dariaphoebe/rtl-wm > > > > > >+https://lists.suckless.org/dev/1112/10398.html > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Tue Feb 10 13:05:47 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 10 Feb 2026 13:05:47 +1000 Subject: [TUHS] Siemens RTL window manager In-Reply-To: <20260210025101.GN13898@mcvoy.com> References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> <20260210025101.GN13898@mcvoy.com> Message-ID: I wound up in tvtwm. I decided I wanted the simplicity of twm and the framed desktop adjacency of fvwm, and tvtwm was in principle more fluid but you could make keybindings jump in the virtual region aligned to "desktops" and keep twm simplicity so I stopped there. I didn't like fvwm because it reminded me of the OSF/1 CDE and I had disliked that so it was tainted by association of L&F but was actually perfectly cromulent. I liked what Colas? Naboo?? did at INRIA. I think it was LISP and called Koala or something. Only ran it briefly. -G On Tue, Feb 10, 2026 at 9:51 AM Larry McVoy via TUHS wrote: > Does anyone remeber ctwm an offshoot of twm? I ran ctwm for years, finally > gave in when I switched to Xubuntu and used their manager. Did so because > what I was doing was weird and all sorts of stuff didn't work, xubuntu > just works. > > On Mon, Feb 09, 2026 at 09:20:04PM -0500, Briam Rodriguez via TUHS wrote: > > Took a bit to get it to crank over, and the mouse support is a bit janky > > (def. not made for a trackpad!) but happy to report it compiles on macos > > 26.2 using xquartz. > > > > If anyone's interested i can supply the patches. > > > > -- Briam R. > > > > On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: > > >Every time I spend time manually tiling windows, I think about the > > >Siemens RTL Window Manager. Despite being approximately X11R4 years > > >old in terms of coming to Unix, binaries of this built from > > >X11R3-contrib were still floating around when I started exploring > > >things past the base environment we were provided; Like the Andrew > > >Window Manager and the port for X11, the source for this was lost for > > >a while but unlike wmc, someone found, patched and shared a copy of > > >the source a while back(+), and I dug out my copy again recently to > > >hopefully play with. > > > > > >Lest the tarball ever become unavailable at the URL from the email, > > >I've pushed a copy to GitHub here: > > >https://github.com/dariaphoebe/rtl-wm > > > > > > > > >+https://lists.suckless.org/dev/1112/10398.html > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Tue Feb 10 13:14:48 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Mon, 9 Feb 2026 19:14:48 -0800 Subject: [TUHS] Siemens RTL window manager In-Reply-To: References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> <20260210025101.GN13898@mcvoy.com> Message-ID: <20260210031448.GP13898@mcvoy.com> I think I went there for a bit but somehow ctwm sucked me in. Maybe it was the virtual desktops? That's a big deal for me, I have 6 right now. On Tue, Feb 10, 2026 at 01:05:47PM +1000, George Michaelson wrote: > I wound up in tvtwm. I decided I wanted the simplicity of twm and the > framed desktop adjacency of fvwm, and tvtwm was in principle more fluid but > you could make keybindings jump in the virtual region aligned to "desktops" > and keep twm simplicity so I stopped there. > > I didn't like fvwm because it reminded me of the OSF/1 CDE and I had > disliked that so it was tainted by association of L&F but was actually > perfectly cromulent. > > I liked what Colas? Naboo?? did at INRIA. I think it was LISP and called > Koala or something. Only ran it briefly. > > -G > > On Tue, Feb 10, 2026 at 9:51???AM Larry McVoy via TUHS wrote: > > > Does anyone remeber ctwm an offshoot of twm? I ran ctwm for years, finally > > gave in when I switched to Xubuntu and used their manager. Did so because > > what I was doing was weird and all sorts of stuff didn't work, xubuntu > > just works. > > > > On Mon, Feb 09, 2026 at 09:20:04PM -0500, Briam Rodriguez via TUHS wrote: > > > Took a bit to get it to crank over, and the mouse support is a bit janky > > > (def. not made for a trackpad!) but happy to report it compiles on macos > > > 26.2 using xquartz. > > > > > > If anyone's interested i can supply the patches. > > > > > > -- Briam R. > > > > > > On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: > > > >Every time I spend time manually tiling windows, I think about the > > > >Siemens RTL Window Manager. Despite being approximately X11R4 years > > > >old in terms of coming to Unix, binaries of this built from > > > >X11R3-contrib were still floating around when I started exploring > > > >things past the base environment we were provided; Like the Andrew > > > >Window Manager and the port for X11, the source for this was lost for > > > >a while but unlike wmc, someone found, patched and shared a copy of > > > >the source a while back(+), and I dug out my copy again recently to > > > >hopefully play with. > > > > > > > >Lest the tarball ever become unavailable at the URL from the email, > > > >I've pushed a copy to GitHub here: > > > >https://github.com/dariaphoebe/rtl-wm > > > > > > > > > > > >+https://lists.suckless.org/dev/1112/10398.html > > > > > > > > -- > > --- > > Larry McVoy Retired to fishing > > http://www.mcvoy.com/lm/boat > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Tue Feb 10 17:00:59 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Tue, 10 Feb 2026 02:00:59 -0500 Subject: [TUHS] Portable C Compiler Revived - Revived! In-Reply-To: <202602091035.619AZrnF079020@freefriends.org> References: <202602091035.619AZrnF079020@freefriends.org> Message-ID: > > To anyone who's interested, the revived version of the venerable > Portable C Compiler (PCC) is available on GitHub. See > https://github.com/PortableCC. > There's some interesting things in there: the f77 and fcom compilers (but not the i77 library); the "inc" (?) and "none" (bare metal) operating systems; and the "m16c" (Mitsubishi), "nova" (Data General), "pdp7", and "pdp10" architectures. There is also a separate compiler called "mip": I don't know what that is. > From tuhs at tuhs.org Tue Feb 10 17:17:17 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 10 Feb 2026 00:17:17 -0700 Subject: [TUHS] Portable C Compiler Revived - Revived! In-Reply-To: References: <202602091035.619AZrnF079020@freefriends.org> Message-ID: <202602100717.61A7HHSL066638@freefriends.org> John Cowan wrote: > > > > To anyone who's interested, the revived version of the venerable > > Portable C Compiler (PCC) is available on GitHub. See > > https://github.com/PortableCC. > > > > There's some interesting things in there: the f77 and fcom compilers (but > not the i77 library); the "inc" (?) and "none" (bare metal) operating > systems; and the "m16c" (Mitsubishi), "nova" (Data General), "pdp7", and > "pdp10" architectures. There is also a separate compiler called "mip": I > don't know what that is. > > > I also want to be clear that this isn't my repository or code; it belongs to Anders Magnusson. I just wanted to bring it to the attention of the crowd here. Arnold From tuhs at tuhs.org Tue Feb 10 17:35:04 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 10 Feb 2026 07:35:04 +0000 Subject: [TUHS] Portable C Compiler Revived - Revived! In-Reply-To: (John Cowan via TUHS's message of "Tue, 10 Feb 2026 02:00:59 -0500") References: <202602091035.619AZrnF079020@freefriends.org> Message-ID: <7wv7g53vbr.fsf@junk.nocrew.org> John Cowan wrote: >> https://github.com/PortableCC. > There's some interesting things in there: [...] > "pdp10" architectures. This was briefly used by Magnusson attempting to port NetBSD to the PDP-10. From tuhs at tuhs.org Tue Feb 10 20:01:47 2026 From: tuhs at tuhs.org (Hauke Fath via TUHS) Date: Tue, 10 Feb 2026 11:01:47 +0100 Subject: [TUHS] Siemens RTL window manager In-Reply-To: <20260210025101.GN13898@mcvoy.com> References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> <20260210025101.GN13898@mcvoy.com> Message-ID: <20260210110147722337.8f0f6096@Espresso.Rhein-Neckar.DE> On Mon, 9 Feb 2026 18:51:01 -0800, Larry McVoy via TUHS wrote: > Does anyone remeber ctwm an offshoot of twm? I ran ctwm for years, finally > gave in when I switched to Xubuntu and used their manager. ctwm has been NetBSD's default window manager for a while: Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany From tuhs at tuhs.org Wed Feb 11 03:08:35 2026 From: tuhs at tuhs.org (Daria Phoebe Brashear via TUHS) Date: Tue, 10 Feb 2026 12:08:35 -0500 Subject: [TUHS] Siemens RTL window manager In-Reply-To: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> Message-ID: Fork it and pull request? I planned to do this anyway (at this point macOS is all I actually have physical hardware for anyway) On Mon, Feb 9, 2026 at 9:20 PM Briam Rodriguez via TUHS wrote: > > Took a bit to get it to crank over, and the mouse support is a bit janky > (def. not made for a trackpad!) but happy to report it compiles on macos > 26.2 using xquartz. > > If anyone's interested i can supply the patches. > > -- Briam R. > > On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: > > Every time I spend time manually tiling windows, I think about the > > Siemens RTL Window Manager. Despite being approximately X11R4 years > > old in terms of coming to Unix, binaries of this built from > > X11R3-contrib were still floating around when I started exploring > > things past the base environment we were provided; Like the Andrew > > Window Manager and the port for X11, the source for this was lost for > > a while but unlike wmc, someone found, patched and shared a copy of > > the source a while back(+), and I dug out my copy again recently to > > hopefully play with. > > > > Lest the tarball ever become unavailable at the URL from the email, > > I've pushed a copy to GitHub here: > > https://github.com/dariaphoebe/rtl-wm > > > > > > +https://lists.suckless.org/dev/1112/10398.html > > -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com From tuhs at tuhs.org Wed Feb 11 03:12:55 2026 From: tuhs at tuhs.org (Daria Phoebe Brashear via TUHS) Date: Tue, 10 Feb 2026 12:12:55 -0500 Subject: [TUHS] Siemens RTL window manager In-Reply-To: References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> <20260210025101.GN13898@mcvoy.com> Message-ID: On Mon, Feb 9, 2026 at 10:12 PM George Michaelson via TUHS wrote: > > I wound up in tvtwm. I decided I wanted the simplicity of twm and the > framed desktop adjacency of fvwm, and tvtwm was in principle more fluid but > you could make keybindings jump in the virtual region aligned to "desktops" > and keep twm simplicity so I stopped there. > > I didn't like fvwm because it reminded me of the OSF/1 CDE and I had > disliked that so it was tainted by association of L&F but was actually > perfectly cromulent. I started with wmc (the Andrew window manager fork), then mwm: had I liked mwm, fvwm probably would have sufficed. But my life took a twisted path of briefly twm, tvtwm, olwm, then olvwm; I then carried private patches and a set of menus for a custom version of olvwm for YEARS, across SunOS 4, Solaris, and Linux. -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com From tuhs at tuhs.org Wed Feb 11 06:05:00 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 10 Feb 2026 15:05:00 -0500 Subject: [TUHS] Portable C Compiler Revived - Revived! In-Reply-To: References: <202602091035.619AZrnF079020@freefriends.org> Message-ID: below. As Arnold says, the repository is Anders Magnusson, and Arnold was just saying that he was able to get that compiler to compile awk. At his suggestion, I reached out to Anders for clarification (and CC'ed Arnold). Much of our interface is below. On Tue, Feb 10, 2026 at 2:01 AM John Cowan via TUHS wrote: > There's some interesting things in there: the f77 and fcom compilers (but > not the i77 library); Yes, that would need to be added as a minimum if this were to be targeted for real work. I did not poke at it too far, but given that it is missing i77, I suspect the ANSI suite would return a number of issues. Moreover, the UCB 4.X release of F77 was never particularly strong (and could not pass it either). > the "inc" (?) and "none" (bare metal) operating > systems; and the "m16c" (Mitsubishi), "nova" (Data General), "pdp7", and > "pdp10" architectures. Yes, he was extremely prolific but .. there are some missing pieces. WRT to the pdp10 target, it would be interesting how compairs the one in Panda (TOPS-20) distribution, which is used to prove a "UNIX-Like" (sort of) set of commands for TOPS-20. > There is also a separate compiler called "mip": I don't know what that is. > The mip directory in the original PCC suite is the "Machine Independent Pieces" and is common to all target ISAs and OSs (which are primarily UNIX-based). My Question to Anders in blue/ his response in orange: 1.) So, the first core question I have is, what is the provenance of your code base? Is it based on one of the original PCC threads (V7 or V32) directly, or modified by UCB (or someone else), or any of this code based on the later PCC2? The original 32V code. I fetched it when Caldera released it around 25 years ago. The BSD improvements was not released publically then. I had a wiki up until a few years ago about this (until the machine running it broke down). Quite trivial but with some useful information. Haven't spent any time to set it up again. Available using webarchive: https://web.archive.org/web/20230819230148/http://pcc.ludd.ltu.se/ 2.) Looking at the man page source, am I correct in believing the C front-end supports C99? True. I have over the last 25 years done quite some improvements, also in the backend. 3.) You have a directory called cxxcom and seem to build a binary of that name, but no man page. Looking at some of the files, such as cgram.y It looks to me like you are declaring C++ tokens also? So I'm thinking this is a C++ implementation. If so, does it try to follow any of the C++ standards (which ones)? :-) This was something I did quite some time ago (around 20 years ago) (because I had some free time). It is not working; and is very rudimentary. It passed "Hello World", but not much more than that. I checked it in so that it shouldn't get lost if someone wants to rescurrect it. 4.) You have a bunch of backends besides PDP-11 and VAX. You clearly wrote many of these, which is impressive. Did the PDP-11 and Vax start from the original Johnson (PDP-11) and Riesner (Vax) code bases? Did any of the others come from elsewhere (such as the set released by Steve Ward's RTS group at MIT)? The VAX was from 32V. The PDP11 backend was written by me, and as far as I remember, there is no other backend coming from any other sources (mostly due to licensing issues). 5.) The compilers generate assembler mnemonic as did the originals. Given the wide range of architectures and OS targets, the question arises: which assemblers and linkers does each target support, and is there a repository for them? Well, no. The output is for the OS (or SDK) which it has been ported to. It is usually expected to run in a Unix environment. Also note that many of the (more obscure) backends are not complete; for example Nova do not support any floating point. 6.) It was unclear to me if these compilers could easily be built as cross-compilers. Yes, most of them can. It uses the normal configure, so just specify a different target. I have broken out the floating point stuff so targets like vax/pdp11 easily should be able to cross-compile. A small idea/request. It would be helpful if you had a text file called READ_ME with notes like my questions and maybe a few more details WRT to each, plus any hints on how to build them. I also think it would be helpful to include a short description of the provenance. Since I think these are based on either V7/V32 PCC, it might be wise to consider placing a copy of the Caldera license [ https://www.tuhs.org/Archive/Caldera-license.pdf] at the top level of your tree. I think the questions you asked are answered on the (archived) web site. Maybe add a link to it somewhere? The caldera license is added to each file (as is common), but having license information about the project might be a good idea as well. ...I am not really up-to-speed with using git/github, so feel free to provide improvements that way :-) I'm trying to learn (in the little time I have left hacking - daytime job takes quite some time for me). From tuhs at tuhs.org Wed Feb 11 11:10:34 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Tue, 10 Feb 2026 20:10:34 -0500 Subject: [TUHS] Siemens RTL window manager In-Reply-To: References: <7e97d26a-3a86-4ea9-921f-99668bdc3e08@gmail.com> Message-ID: Hi Daria, I got rtl-wm building and running on macOS (tested on Apple Silicon with MacPorts). Opened a PR with the changes: https://github.com/dariaphoebe/rtl-wm/pull/1 The changes are minimal: - Two small source fixes (NULL → '\0' for char assignments - these were causing errors on modern clang) - A Makefile.macos for building with MacPorts X11 - Updated README with macOS instructions No changes to the original Imakefile or build system. Requires liboldX which isn't in MacPorts anymore, but builds fine from source. Let me know if you'd like any changes to the PR. -- Briam R. On 2/10/26 12:08 PM, Daria Phoebe Brashear wrote: > Fork it and pull request? I planned to do this anyway (at this point > macOS is all I actually have physical hardware for anyway) > > On Mon, Feb 9, 2026 at 9:20 PM Briam Rodriguez via TUHS wrote: >> Took a bit to get it to crank over, and the mouse support is a bit janky >> (def. not made for a trackpad!) but happy to report it compiles on macos >> 26.2 using xquartz. >> >> If anyone's interested i can supply the patches. >> >> -- Briam R. >> >> On 2/9/26 11:05 AM, Daria Phoebe Brashear via TUHS wrote: >>> Every time I spend time manually tiling windows, I think about the >>> Siemens RTL Window Manager. Despite being approximately X11R4 years >>> old in terms of coming to Unix, binaries of this built from >>> X11R3-contrib were still floating around when I started exploring >>> things past the base environment we were provided; Like the Andrew >>> Window Manager and the port for X11, the source for this was lost for >>> a while but unlike wmc, someone found, patched and shared a copy of >>> the source a while back(+), and I dug out my copy again recently to >>> hopefully play with. >>> >>> Lest the tarball ever become unavailable at the URL from the email, >>> I've pushed a copy to GitHub here: >>> https://github.com/dariaphoebe/rtl-wm >>> >>> >>> +https://lists.suckless.org/dev/1112/10398.html >>> > >