From tuhs at tuhs.org Tue Sep 2 22:49:02 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 02 Sep 2025 06:49:02 -0600 Subject: [TUHS] Brian Kernighan's talk on the history of Unix at VCF East this year Message-ID: <202509021249.582Cn22h066009@freefriends.org> Hi All. My brother sent me the link to this article: https://thenewstack.io/unix-co-creator-brian-kernighan-on-rust-distros-and-nixos/ IMHO you should skip over the article and move to the video at the end of it. I always enjoy listening to him. Enjoy, Arnold From tuhs at tuhs.org Wed Sep 3 09:39:03 2025 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 2 Sep 2025 18:39:03 -0500 Subject: [TUHS] Python Documentary Message-ID: <042da406-62ee-46f3-8b66-98976a87a66a@gmail.com> All, I know my language pals are all over this, but in case you hadn't been paying attention, python's riding ascendant these days and I would argue, unix played a big role in the birthing of this language. It's fingerprints are all over it, so to speak. A documentary came out the other day and it's very worth watching - the overlap with unix's latter days is evident, even though it's very much about the language. Here's the link, enjoy (or grumble, the choice is yours): https://www.youtube.com/watch?v=GfH4QL4VqJ0 Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Sep 3 11:42:05 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Tue, 2 Sep 2025 18:42:05 -0700 Subject: [TUHS] Brian Kernighan's talk on the history of Unix at VCF East this year In-Reply-To: <202509021249.582Cn22h066009@freefriends.org> References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: <20250903014205.GQ21837@mcvoy.com> Brian at 83 is better than me at 50 (I'm 63 and even worse). What an amazing guy. On Tue, Sep 02, 2025 at 06:49:02AM -0600, Arnold Robbins via TUHS wrote: > Hi All. > > My brother sent me the link to this article: > https://thenewstack.io/unix-co-creator-brian-kernighan-on-rust-distros-and-nixos/ > > IMHO you should skip over the article and move to the video at the end of > it. I always enjoy listening to him. > > Enjoy, > > Arnold -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Sep 3 17:39:52 2025 From: tuhs at tuhs.org (Diomidis Spinellis via TUHS) Date: Wed, 3 Sep 2025 10:39:52 +0300 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: <202509021249.582Cn22h066009@freefriends.org> References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: In Brian Kernighan's amazing VCF talk that Arnold Robbins shared yesterday, bwk mentions that Steve N[uancen?] came up with the famous spell checking pipeline: cat | tr | sort | uniq | comm https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s Anybody knows the correct name of that person? ChatGPT only hallucinates many wrong ones. Many thanks, Diomidis - https://www.spinellis.gr From tuhs at tuhs.org Wed Sep 3 17:56:55 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 3 Sep 2025 17:56:55 +1000 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: On Wed, Sep 03, 2025 at 10:39:52AM +0300, Diomidis Spinellis via TUHS wrote: > In Brian Kernighan's amazing VCF talk that Arnold Robbins shared yesterday, > bwk mentions that Steve N[uancen?] came up with the famous spell checking > pipeline: cat | tr | sort | uniq | comm > > https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s > > Anybody knows the correct name of that person? ChatGPT only hallucinates > many wrong ones. "The spell script originated with Steve Johnson." >From page 149 of Brian's book, UNIX: A History and a Memoir. An example script is on page 150. From tuhs at tuhs.org Wed Sep 3 20:03:33 2025 From: tuhs at tuhs.org (Nikos Vasilakis via TUHS) Date: Wed, 3 Sep 2025 06:03:33 -0400 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: El mié, 3 sept 2025 a la(s) 3:57 a.m., Jonathan Gray via TUHS (tuhs at tuhs.org) escribió: > > On Wed, Sep 03, 2025 at 10:39:52AM +0300, Diomidis Spinellis via TUHS wrote: > > In Brian Kernighan's amazing VCF talk that Arnold Robbins shared yesterday, > > bwk mentions that Steve N[uancen?] came up with the famous spell checking > > pipeline: cat | tr | sort | uniq | comm > > > > https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s > > > > Anybody knows the correct name of that person? ChatGPT only hallucinates > > many wrong ones. > > "The spell script originated with Steve Johnson." > From page 149 of Brian's book, UNIX: A History and a Memoir. > An example script is on page 150. Also: "Steve Johnson wrote the first version of the spell in an afternoon in 1975." from an older reference, Jon Bentley's "Programming Pearls: A spelling Checker" (CACM, May 1st, 1985), which offers additional analysis of this program (and is openly accessible): https://dl.acm.org/doi/10.1145/3532.315102 N. From tuhs at tuhs.org Wed Sep 3 21:44:48 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 3 Sep 2025 21:44:48 +1000 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: On Wed, Sep 03, 2025 at 06:03:33AM -0400, Nikos Vasilakis via TUHS wrote: > El mié, 3 sept 2025 a la(s) 3:57 a.m., Jonathan Gray via TUHS > (tuhs at tuhs.org) escribió: > > > > On Wed, Sep 03, 2025 at 10:39:52AM +0300, Diomidis Spinellis via TUHS wrote: > > > In Brian Kernighan's amazing VCF talk that Arnold Robbins shared yesterday, > > > bwk mentions that Steve N[uancen?] came up with the famous spell checking > > > pipeline: cat | tr | sort | uniq | comm > > > > > > https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s > > > > > > Anybody knows the correct name of that person? ChatGPT only hallucinates > > > many wrong ones. > > > > "The spell script originated with Steve Johnson." > > From page 149 of Brian's book, UNIX: A History and a Memoir. > > An example script is on page 150. > > Also: "Steve Johnson wrote the first version of the spell in an > afternoon in 1975." from an older reference, Jon Bentley's > "Programming Pearls: A spelling Checker" (CACM, May 1st, 1985), which > offers additional analysis of this program (and is openly accessible): > https://dl.acm.org/doi/10.1145/3532.315102 > > N. The spell manual page from fifth edition is dated 2/26/74. The script was not distributed with fifth or six edition as far as I can tell. Seventh edition has Doug's C version. From tuhs at tuhs.org Wed Sep 3 22:53:16 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 3 Sep 2025 08:53:16 -0400 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: On Wed, Sep 3, 2025 at 3:47 AM Diomidis Spinellis via TUHS wrote: > In Brian Kernighan's amazing VCF talk that Arnold Robbins shared > yesterday, bwk mentions that Steve N[uancen?] came up with the famous > spell checking pipeline: cat | tr | sort | uniq | comm > > https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s > > Anybody knows the correct name of that person? ChatGPT only > hallucinates many wrong ones. As others have pointed out, it was Steve Johnson. I wanted to mention that he did say Steve Johnson in the video as well, though I can see how one might (mis)hear differently; I think that's just an artifact of the audio. - Dan C. From tuhs at tuhs.org Thu Sep 4 00:38:34 2025 From: tuhs at tuhs.org (Heinz Lycklama via TUHS) Date: Wed, 3 Sep 2025 07:38:34 -0700 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: <1aff910d-4943-4ba0-b011-fd0707b48abc@osta.com> Grok provides a meaningful answer. ------------------------------------------------------------------------ Brian Kernighan is credited with demonstrating the famous spell checking pipeline using Unix commands like cat | tr | sort | uniq | comm (or similar variations). In a classic 1970s Bell Labs video titled "The UNIX Operating System," he showcased pipelines for spell checking as an early example of Unix's power. The video uses a pipeline like makewords sentence | lowercase | sort | unique | mismatch to extract words, lowercase them, sort, remove duplicates, and compare against a dictionary—concepts that directly inspired modern equivalents with tr for translation, uniq for deduplication, and comm for comparison. This approach highlights Unix's philosophy of combining simple tools for complex tasks, and while the exact commands evolved, the core idea stems from Kernighan's presentation. The original spell command from 1975, written by Stephen C. Johnson with improvements by Douglas McIlroy, used a similar internal logic but not this exact pipeline. ------------------------------------------------------------------------ Heinz On 9/3/2025 5:53 AM, Dan Cross via TUHS wrote: > On Wed, Sep 3, 2025 at 3:47 AM Diomidis Spinellis via TUHS > wrote: >> In Brian Kernighan's amazing VCF talk that Arnold Robbins shared >> yesterday, bwk mentions that Steve N[uancen?] came up with the famous >> spell checking pipeline: cat | tr | sort | uniq | comm >> >> https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s >> >> Anybody knows the correct name of that person? ChatGPT only >> hallucinates many wrong ones. > As others have pointed out, it was Steve Johnson. I wanted to mention > that he did say Steve Johnson in the video as well, though I can see > how one might (mis)hear differently; I think that's just an artifact > of the audio. > > - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Sep 4 02:03:57 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 03 Sep 2025 16:03:57 +0000 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: On Sep 3, 2025, at 01:39, Diomidis Spinellis wrote: > > In Brian Kernighan's amazing VCF talk that Arnold Robbins shared > yesterday, bwk mentions that Steve N[uancen?] came up with the famous > spell checking pipeline: cat | tr | sort | uniq | comm > > https://www.youtube.com/watch?v=WEb_YL1K1Qg&t=1396s In “The UNIX System: Making Computers More Productive” (1982), Brian Kernighan describes a similar pipeline: makewords sentence | lowercase | sort | unique | mismatch -� where `sentence` is a file and the last character typed was not shown. Spell-checking evidently teaches pipelines well, as he’s been explaining similar formulations for a long time. Thalia From tuhs at tuhs.org Thu Sep 4 02:06:35 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 03 Sep 2025 16:06:35 +0000 Subject: [TUHS] Who came up with the spell check pipeline? In-Reply-To: References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: <7C4F4A43-E736-436C-BAD0-D4D40BAA0BB7@archibald.dev> On Sep 3, 2025, at 10:03, Thalia Archibald wrote: > In “The UNIX System: Making Computers More Productive” (1982), Brian Kernighan > describes a similar pipeline And that film can be found here: https://www.youtube.com/watch?v=tc4ROCJYbm0 Thalia From tuhs at tuhs.org Thu Sep 4 12:31:05 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 4 Sep 2025 12:31:05 +1000 Subject: [TUHS] dmr's C Compiler: a more detailed look? Message-ID: Hi all, does anybody know of a deeper dive into dmr's PDP-11 C compiler other than "A Tour through the UNIX C Compiler" from the Unix Programmer’s Manual Vol 2B? I'm specifically interested in the PDP-11 code generation from the AST trees: given the PDP-11 has a heap of addressing modes, there must be interesting ways of using them in a compiler to avoid registers. Anyway, if there is something closer to a function-level (and data structure level) exposition, I'd be very keen to find it! Many thanks in advance, Warren From tuhs at tuhs.org Fri Sep 5 07:53:18 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Thu, 04 Sep 2025 21:53:18 +0000 Subject: [TUHS] Brian Kernighan's talk on the history of Unix at VCF East this year In-Reply-To: <202509021249.582Cn22h066009@freefriends.org> References: <202509021249.582Cn22h066009@freefriends.org> Message-ID: <5W51nWcqJ9-uuyRHnqIkrl6VjMHzTlplOncCDpfkCggel1oBN77i-2k10befFnxq4Yhl55Zvd6RZ8FzDGHHkDdQnNyu2yepopKfUFIM56KU=@protonmail.ch> Hello Arnold, Thank you for sharing that link. I actually sneaked a peek at some of the article but realized, as you suggested, that I should skip straight to the video. One of the most enjoyable 100 minutes. Mr. Kernighan just has a way of communicating that I my brain latches onto. I found it interesting that the calm and collected presentation of information that lured me into "The C Programming Language", in college 38 years ago, endured in this verbal presentation. I loved his sense of humor also. How lucky are the students at Princeton who get an opportunity to go to one of his lectures, regardless of the subject! Best regards, Cameron From tuhs at tuhs.org Sun Sep 7 11:25:43 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 07 Sep 2025 01:25:43 +0000 Subject: [TUHS] [COFF] Early Bell Laboratories CPU Datasheets In-Reply-To: References: Message-ID: And now I've started a repository here: https://gitlab.com/segaloco/pwb5btl_man This will slowly accumulate reconstructions of the various manpages in the BTL edition of the Release 5.0 User's and Administrator's Manuals. I've started with the MAC-4 development utilities, and intend to tackle the pages for the MAC-8 and BASIC-16 environments next. I'll be adding various pages from these manuals over time, in the same spirit as my 4.1 3B20S project. I look forward to the opportunity to share these materials around Bell Labs's use of UNIX in their hardware design operations. Will probably start a more focused TUHS thread when the repository has more stuff in it, but a Bcc mention for now. - Matt G. On Friday, September 5th, 2025 at 23:02, segaloco via COFF wrote: > Just wanted to share a couple of datasheets that may interest folks here. This evening I scanned both the MAC-8 and MAC-4 preliminary datasheets from late 1978. While many details of the MAC-8 are currently known, the MAC-4 has been elusive in my study until I received these documents in a collection of MAC-8 materials. > > [https://archive.org/details/212-b-mac-8-data-sheet](https://archive.org/details/212-b-mac-8-data-sheet/) > > [https://archive.org/details/mac-4-specification-sheet](https://archive.org/details/mac-4-specification-sheet/) > > These are Bell Laboratories' 1970's 8-bit and 4-bit microprocessors which preceded their work on the WE32000. > > I have some hints on the typical development environment too. The BTL editions of the UNIX 5.0 and SVR2 manuals contain numerous references to MAC-8 and MAC-4 tools. I intend to preserve those pages too as part of a larger effort to illuminate the history of these two processors. > > I've provided much more info here: https://forum.vcfed.org/index.php?threads/western-electric-component-databooks.1250931/#post-1464263 > > - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Sep 7 13:26:43 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 07 Sep 2025 03:26:43 +0000 Subject: [TUHS] Bell COSMOS UNIX Commands Message-ID: As discussed in a previous thread, Bell Laboratories' COSMOS system was an early AT&T application of UNIX outside of research, software development, and typesetting, starting a trend of using UNIX as the underlying system for telephone switching hardware. Well I happened to be reading up on some various switching hardware when I came across this AT&T spec for the "Frame Transaction Codes" used in the COSMOS system: https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf The first issue of this manual is from 1979. I don't know for certain if this manual is describing UNIX commands, but they are all prefixed with a "%" alluding to a mid-70s shell. There may be more nuggets hiding in COSMOS-adjacent literature out there. - Matt G. From tuhs at tuhs.org Mon Sep 8 20:27:22 2025 From: tuhs at tuhs.org (Jason Stevens via TUHS) Date: Mon, 8 Sep 2025 11:27:22 +0100 Subject: [TUHS] Bruce Evans 386 Minix patches & compiler source Message-ID: Hi all! It's been quite a while since I was messing with Minix386 back in the days when Bruce Evans released a set of patches to bring 386 support. I'm pretty sure over on oldlinux.org the patch set exists, but I can only find the one set of binaries of his 386 toolchain. I know it eventually evolved into the bin86 toolchain that Linus would go on to use to create real mode boot code, but I don't know if any of the source code to his 1991/1992 386 toolchain ever got published? Thanks in advance! Jason Stevens From tuhs at tuhs.org Tue Sep 9 09:23:15 2025 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Tue, 9 Sep 2025 09:23:15 +1000 Subject: [TUHS] Bruce Evans 386 Minix patches & compiler source In-Reply-To: References: Message-ID: On Monday, 8 September 2025 at 11:27:22 +0100, The UNIX Heritage Society wrote: > Hi all! > It's been quite a while since I was messing with Minix386 back in the days > when Bruce Evans released a set of patches to bring 386 support. > I'm pretty sure over on oldlinux.org the patch set exists, but I can only > find the one set of binaries of his 386 toolchain. > I know it eventually evolved into the bin86 toolchain that Linus would go on > to use to create real mode boot code, but I don't know if any of the source > code to his 1991/1992 386 toolchain ever got published? I received Bruce's computers when he died, and I briefly looked into some of the data on the disks. If you can give me some search strings for file names, I can take a look and possibly find something. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Tue Sep 9 12:47:06 2025 From: tuhs at tuhs.org (Jason Stevens via TUHS) Date: Tue, 9 Sep 2025 03:47:06 +0100 Subject: [TUHS] Bruce Evans 386 Minix patches & compiler source Message-ID: Sure here is some: /local/bin/ld /local/bin/as /local/bin/sc /usr/local/lib/i86/crtso.o /usr/local/lib/i386/crtso.o pre-defined macros seem to be __LONG_BIG_ENDIAN__ __FIRST_ARG_IN_AX__ __CALLER_SAVES__ __AS386_16__ __AS386_32__ -----Original Message----- From: Greg 'groggy' Lehey To: Jason Stevens Cc: The UNIX Heritage Society Sent: 9/9/25 12:23 AM Subject: Re: [TUHS] Bruce Evans 386 Minix patches & compiler source On Monday, 8 September 2025 at 11:27:22 +0100, The UNIX Heritage Society wrote: > Hi all! > It's been quite a while since I was messing with Minix386 back in the days > when Bruce Evans released a set of patches to bring 386 support. > I'm pretty sure over on oldlinux.org the patch set exists, but I can only > find the one set of binaries of his 386 toolchain. > I know it eventually evolved into the bin86 toolchain that Linus would go on > to use to create real mode boot code, but I don't know if any of the source > code to his 1991/1992 386 toolchain ever got published? I received Bruce's computers when he died, and I briefly looked into some of the data on the disks. If you can give me some search strings for file names, I can take a look and possibly find something. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php From tuhs at tuhs.org Tue Sep 9 14:02:20 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Tue, 9 Sep 2025 14:02:20 +1000 Subject: [TUHS] Bruce Evans 386 Minix patches & compiler source In-Reply-To: References: Message-ID: On Mon, Sep 08, 2025 at 11:27:22AM +0100, Jason Stevens via TUHS wrote: > Hi all! > It's been quite a while since I was messing with Minix386 back in the days > when Bruce Evans released a set of patches to bring 386 support. > I'm pretty sure over on oldlinux.org the patch set exists, but I can only > find the one set of binaries of his 386 toolchain. the version in minix 386 archives (without full sources): bccbin16.tar.Z bccbin32.tar.Z bcclib.tar.Z bcc.tar.Z > I know it eventually evolved into the bin86 toolchain that Linus would go on > to use to create real mode boot code, but I don't know if any of the source > code to his 1991/1992 386 toolchain ever got published? FreeBSD has Bruce's C Compiler (bcc) in ports as devel/bcc http://distcache.freebsd.org/ports-distfiles/bcc.tar.gz VERSION: 1995 Mar 12 10:29 UTC same file available at http://fare.tunes.org/files/asm/bcc-95.3.12.src.tgz An earlier (1991/1992) version of the as/ld part of it https://ftp.funet.fi/pub/Linux/bin/as86.src.tar.Z From tuhs at tuhs.org Wed Sep 10 05:07:14 2025 From: tuhs at tuhs.org (Phillip Harbison via TUHS) Date: Tue, 9 Sep 2025 14:07:14 -0500 Subject: [TUHS] HBD, DMR! Message-ID: <854aa178-d1b9-4aa4-9a01-426e033f39e8@xavax.com> Happy Birthday, Dennis Ritchie! RIP! Gone but never forgotten! https://www.facebook.com/AssociationForComputingMachinery/posts/pfbid02qcn4HRipMueZtvkAASeSPWWySNgA858qaUawszWTfncsxMYzV6rbPyMKJMo952YMl Who else remembers when DMR crossposted to comp.unix an announcement of a Q-Bus modem card under the subject "Q-Bus Integral Lightning Rod"? Or when he denied ever being a membee of the "demigodic party". Or when he and Ken Thompson appeared on the cover of Byte(?) and in the background on a VT100 was the command "$ cat xxxxxxxx > /dev/lp". No fancy printer daemons for those guys! He definitely had a sense of humor. -- Phil Harbison From tuhs at tuhs.org Wed Sep 10 14:48:44 2025 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Wed, 10 Sep 2025 14:48:44 +1000 Subject: [TUHS] Bruce Evans 386 Minix patches & compiler source In-Reply-To: References: Message-ID: On Monday, 8 September 2025 at 11:27:22 +0100, The UNIX Heritage Society wrote: > Hi all! > It's been quite a while since I was messing with Minix386 back in the days > when Bruce Evans released a set of patches to bring 386 support. > I'm pretty sure over on oldlinux.org the patch set exists, but I can only > find the one set of binaries of his 386 toolchain. > I know it eventually evolved into the bin86 toolchain that Linus would go on > to use to create real mode boot code, but I don't know if any of the source > code to his 1991/1992 386 toolchain ever got published? > Thanks in advance! I may have something for you: -rw-r--r-- 1 15 wheel 1,204,371 9 Sep 2009 minix-1.5.10.tar.gz -rw-r--r-- 1 15 wheel 188,964 10 Sep 2009 minix-extra.tar.gz -r--r--r-- 1 15 wheel 15,247,252 18 Dec 1994 minix.tar.gz Don't be put off by the dates of the archives; the programs are mainly from 1992 and 1993. They're all on http://www.lemis.com/grog/tmp, which is not readable. In particular minix.tar.gz could be useful. Take a look and let me know; there's more to search. The programs won't stay there; expect wkt to tell you where the end up, once we have established exactly what they are. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Thu Sep 11 03:11:30 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 10 Sep 2025 11:11:30 -0600 Subject: [TUHS] Is it still possible to find old USENET postings? Message-ID: <202509101711.58AHBUVI035333@freefriends.org> I'm looking for something posted to comp.unix.questions in October of 1989, for which I have a printout. I'm hoping I can still find it online somehow. Any advice? Thanks, Arnold From tuhs at tuhs.org Thu Sep 11 03:27:44 2025 From: tuhs at tuhs.org (A. P. Garcia via TUHS) Date: Wed, 10 Sep 2025 13:27:44 -0400 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <202509101711.58AHBUVI035333@freefriends.org> References: <202509101711.58AHBUVI035333@freefriends.org> Message-ID: On Wed, Sep 10, 2025, 1:11 PM Arnold Robbins via TUHS wrote: > I'm looking for something posted to comp.unix.questions in October of 1989, for which I have a printout. I'm hoping I can still find it online somehow. I'm only aware of Google Groups and Henry Spencer's utzoo archive. The latter was taken down from the Internet Archive, but there's a mirror at https://shiftleft.com/mirrors/utzoo-usenet/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Sep 11 08:17:22 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 11 Sep 2025 08:17:22 +1000 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <202509101711.58AHBUVI035333@freefriends.org> References: <202509101711.58AHBUVI035333@freefriends.org> Message-ID: On Wed, Sep 10, 2025 at 11:11:30AM -0600, Arnold Robbins via TUHS wrote: > I'm looking for something posted to comp.unix.questions in October of > 1989, for which I have a printout. I'm hoping I can still find it online > somehow. Try this: https://www.tuhs.org/Usenet/comp.unix.questions/ Cheers! Warren From tuhs at tuhs.org Thu Sep 11 18:19:08 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 11 Sep 2025 02:19:08 -0600 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <202509101711.58AHBUVI035333@freefriends.org> References: <202509101711.58AHBUVI035333@freefriends.org> Message-ID: <202509110819.58B8J8wR091001@freefriends.org> Hi All. I wrote: > I'm looking for something posted to comp.unix.questions in October of > 1989, for which I have a printout. I'm hoping I can still find it online > somehow. > > Any advice? > > Thanks, > > Arnold Thanks to everyone who sent answers. A particular thank you to Adam Sjøgren who found the article: https://article.olduse.net/9157 at elsie.UUCP on the site he maintains. It's fun to see it. I agree with ADO that the answers do reflect the corporate culture of the time. :-) Arnold From tuhs at tuhs.org Thu Sep 11 18:54:12 2025 From: tuhs at tuhs.org (Ori Kuttner via TUHS) Date: Thu, 11 Sep 2025 11:54:12 +0300 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <202509110819.58B8J8wR091001@freefriends.org> References: <202509101711.58AHBUVI035333@freefriends.org> <202509110819.58B8J8wR091001@freefriends.org> Message-ID: On Thu, Sep 11, 2025 at 11:19 AM Arnold Robbins via TUHS wrote: > Hi All. > > I wrote: > > > I'm looking for something posted to comp.unix.questions in October of > > 1989, for which I have a printout. I'm hoping I can still find it online > > somehow. > > > > Any advice? > > > > Thanks, > > > > Arnold > > Thanks to everyone who sent answers. > > A particular thank you to Adam Sjøgren > who found the article: https://article.olduse.net/9157 at elsie.UUCP > on the site he maintains. > > It's fun to see it. I agree with ADO that the answers do > reflect the corporate culture of the time. :-) > Sun says, it's not a bug, it is a feature :-) > > Arnold > From tuhs at tuhs.org Thu Sep 11 20:52:51 2025 From: tuhs at tuhs.org (Leah Neukirchen via TUHS) Date: Thu, 11 Sep 2025 12:52:51 +0200 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <202509110819.58B8J8wR091001@freefriends.org> (Arnold Robbins via TUHS's message of "Thu, 11 Sep 2025 02:19:08 -0600") References: <202509101711.58AHBUVI035333@freefriends.org> <202509110819.58B8J8wR091001@freefriends.org> Message-ID: <87jz25gt18.fsf@vuxu.org> Arnold Robbins via TUHS writes: > Thanks to everyone who sent answers. > > A particular thank you to Adam Sjøgren > who found the article: https://article.olduse.net/9157 at elsie.UUCP > on the site he maintains. > > It's fun to see it. I agree with ADO that the answers do > reflect the corporate culture of the time. :-) Now I wonder what the awk versions did, that didn't print each line that contains an equal sign? -- Leah Neukirchen https://leahneukirchen.org/ From tuhs at tuhs.org Thu Sep 11 21:25:30 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 11 Sep 2025 05:25:30 -0600 Subject: [TUHS] Is it still possible to find old USENET postings? In-Reply-To: <87jz25gt18.fsf@vuxu.org> References: <202509101711.58AHBUVI035333@freefriends.org> <202509110819.58B8J8wR091001@freefriends.org> <87jz25gt18.fsf@vuxu.org> Message-ID: <202509111125.58BBPU2H099729@freefriends.org> Leah Neukirchen wrote: > Arnold Robbins via TUHS writes: > > > Thanks to everyone who sent answers. > > > > A particular thank you to Adam Sjøgren > > who found the article: https://article.olduse.net/9157 at elsie.UUCP > > on the site he maintains. > > > > It's fun to see it. I agree with ADO that the answers do > > reflect the corporate culture of the time. :-) > > Now I wonder what the awk versions did, that didn't print each line > that contains an equal sign? > > -- > Leah Neukirchen https://leahneukirchen.org/ Probably produced syntax errors. Since it's hard to tell when you see just the '/=' whether it's an assignment operator or the beginning of a regular expression. Issues with /= still lurk in the One True Awk. See this one from June: https://github.com/onetrueawk/awk/pull/255. :-) Arnold From tuhs at tuhs.org Thu Sep 11 21:32:21 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 11 Sep 2025 05:32:21 -0600 Subject: [TUHS] Vintage Mt. Xinu bumber sticker for the highest bidder :-) Message-ID: <202509111132.58BBWL3J000423@freefriends.org> Hi All. In cleaning out some old files yesterday, I found a Mt. Xinu bumper sticker from 1986 with the slogan 4.3 + NFS > {sigma for n = 0 to infinity} V.n It's in pretty pristine condition. I'm willing to send it off for the highest bid + the price of postage. If interested, please email me DIRECTLY with your bid. Bidding to close by Monday morning, Israel time. Payment via Paypal or US check to my US address. This is meant in a spirit of fun, I hope Warren won't be mad at me. :-) Thanks, Arnold From tuhs at tuhs.org Fri Sep 12 12:29:58 2025 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Thu, 11 Sep 2025 19:29:58 -0700 Subject: [TUHS] OSF Research OS Collected Papers Message-ID: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> I came across copies of a few papers that I think came from the multi-volume OSF Research Institute OS Collected Papers Did they ever make these volumes generally available? From tuhs at tuhs.org Fri Sep 12 14:48:18 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 12 Sep 2025 14:48:18 +1000 Subject: [TUHS] OSF Research OS Collected Papers In-Reply-To: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> References: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> Message-ID: On Thu, Sep 11, 2025 at 07:29:58PM -0700, Al Kossow via TUHS wrote: > I came across copies of a few papers that I think came from the multi-volume OSF Research Institute OS Collected Papers > Did they ever make these volumes generally available? Operating Systems - Collected Papers Vol. 1, March 1993 Operating Systems - Collected Papers Vol. 2, October 1993 Operating Systems - Collected Papers Vol. 3, April 1994 Operating Systems - Collected Papers Vol. 4, October 1995 Operating Systems - Collected Papers Vol. 5, March 1997 postscript versions of individual papers: https://web.archive.org/web/19970607223018/http://www.osf.org/os/os.coll.papers/index.html https://web.archive.org/web/19970615200522/http://www.osf.org/os/os.coll.papers/Vol1/index.html https://web.archive.org/web/19970615200559/http://www.osf.org/os/os.coll.papers/Vol2/index.html https://web.archive.org/web/19970615200636/http://www.osf.org/os/os.coll.papers/Vol3/index.html https://web.archive.org/web/19970615200713/http://www.osf.org/os/os.coll.papers/Vol4/index.html price list from March 1997: https://web.archive.org/web/19970707164633/http://www.opengroup.org/RI/ri/pubs/Pubsform.html From tuhs at tuhs.org Fri Sep 12 15:49:07 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 12 Sep 2025 05:49:07 +0000 Subject: [TUHS] AT&T Videotape Library Message-ID: I recently saw some auctions for "AT&T Videotape Library" ephemera while searching for documents and it seems there were a fair deal of tapes one could order on subjects such as typical shell usage and UNIX internals. This is distinct from tapes that were distributed by USL, although I couldn't tell you what they published besides C education, I happened upon a Volume 2 set from a early '90s C educational film set. Anywho, I've found myself curious about the content and frankly the production, especially CG effects for transitions and demonstrations. Has anyone on list viewed any of these tapes or even better have the scoop on the production thereof? I have a particular soft spot for corporate educational material of bygone days, I type as I look at my stack of BSP manuals. Some day I hope to have the hardware to preserve VHS tapes because I've already got 5 tapes of various AT&T stuff I've picked up over the years. Also just in general, any historic educational video content concerning UNIX you find particularly memorable? For me it's the early '80s AT&T promotional films about UNIX in which you can tell they're editing over "The UNIX System" in post after everyone had already said just UNIX during taping. It's funny, the manual edits feel quite the same: g/\(UNIX\)/s//The \1 System/g Not saying that to disparage either, I find it a charming little edit with an interesting back story. - Matt G. From tuhs at tuhs.org Fri Sep 12 20:57:13 2025 From: tuhs at tuhs.org (Mike Dank via TUHS) Date: Fri, 12 Sep 2025 06:57:13 -0400 Subject: [TUHS] AT&T Videotape Library Message-ID: <772CA1AF-DDFD-4C9A-A8CD-1DF0389FDDF3@gmail.com> I actually have a few of these tapes I picked up from a flea market a while back and am planning on digitizing in the next month or two. C Language for Programmers - Volumes 4-8 The Shell Command Language for Programmers - Volumes 4-7 I forget if one of the tapes from these is missing, and it’s a shame that I don’t have the beginning volumes for any of them but I grabbed everything being sold at the time. Cheers, Mike > On Sep 12, 2025, at 02:09, segaloco via TUHS wrote: >  > I recently saw some auctions for "AT&T Videotape Library" ephemera while > searching for documents and it seems there were a fair deal of tapes one > could order on subjects such as typical shell usage and UNIX internals. > This is distinct from tapes that were distributed by USL, although I > couldn't tell you what they published besides C education, I happened > upon a Volume 2 set from a early '90s C educational film set. > > Anywho, I've found myself curious about the content and frankly the > production, especially CG effects for transitions and demonstrations. > Has anyone on list viewed any of these tapes or even better have the > scoop on the production thereof? I have a particular soft spot for > corporate educational material of bygone days, I type as I look at my > stack of BSP manuals. Some day I hope to have the hardware to preserve > VHS tapes because I've already got 5 tapes of various AT&T stuff I've > picked up over the years. > > Also just in general, any historic educational video content concerning > UNIX you find particularly memorable? For me it's the early '80s AT&T > promotional films about UNIX in which you can tell they're editing over > "The UNIX System" in post after everyone had already said just UNIX > during taping. It's funny, the manual edits feel quite the same: > > g/\(UNIX\)/s//The \1 System/g > > Not saying that to disparage either, I find it a charming little edit > with an interesting back story. > > - Matt G. From tuhs at tuhs.org Fri Sep 12 22:14:05 2025 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 12 Sep 2025 05:14:05 -0700 Subject: [TUHS] OSF Research OS Collected Papers In-Reply-To: References: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> Message-ID: <33f9bf02-7923-2f9e-81b0-b1e3857c1bc2@bitsavers.org> On 9/11/25 9:48 PM, Jonathan Gray wrote: > postscript versions of individual papers: > thanks! there is only one IA snapshot that actually has the Vol1-4 postscript files https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol1/index.html https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol2/index.html https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol3/index.html https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol4/index.html From tuhs at tuhs.org Fri Sep 12 23:00:28 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 12 Sep 2025 23:00:28 +1000 Subject: [TUHS] OSF Research OS Collected Papers In-Reply-To: <33f9bf02-7923-2f9e-81b0-b1e3857c1bc2@bitsavers.org> References: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> <33f9bf02-7923-2f9e-81b0-b1e3857c1bc2@bitsavers.org> Message-ID: On Fri, Sep 12, 2025 at 05:14:05AM -0700, Al Kossow via TUHS wrote: > On 9/11/25 9:48 PM, Jonathan Gray wrote: > > > postscript versions of individual papers: > > > > thanks! there is only one IA snapshot that actually has the Vol1-4 postscript files > > https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol1/index.html > https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol2/index.html > https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol3/index.html > https://web.archive.org/web/19970616122217/http://www.osf.org:80/os/os.coll.papers/Vol4/index.html Strange, I downloaded all the postscript files from the other links without problem. The bibliography may also be helpful, mentions which volume of the collected papers to check. https://web.archive.org/web/19971016173810/http://www.opengroup.org/RI/ri/biblio/Bibliography.frame.html From tuhs at tuhs.org Fri Sep 12 23:48:12 2025 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 12 Sep 2025 06:48:12 -0700 Subject: [TUHS] OSF Research OS Collected Papers In-Reply-To: References: <7dcd0963-2fc6-0054-9516-1f22135a3b94@bitsavers.org> <33f9bf02-7923-2f9e-81b0-b1e3857c1bc2@bitsavers.org> Message-ID: On 9/12/25 6:00 AM, Jonathan Gray wrote: > Strange, I downloaded all the postscript files from the other links > without problem. > > The bibliography may also be helpful, mentions which volume of > the collected papers to check. > https://web.archive.org/web/19971016173810/http://www.opengroup.org/RI/ri/biblio/Bibliography.frame.html > I am not able to access most of the postscript files in that bibliography They need to be archived somewhere else then if you can recover the. From tuhs at tuhs.org Sat Sep 13 04:23:53 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Fri, 12 Sep 2025 11:23:53 -0700 Subject: [TUHS] bell labs murray hill artifacts Message-ID: where's the shockley transistor? and the map of the US showing the Bell System empire, with a light for each central office? aside: the old RCA labs building is still there in princeton, and the 7 Emmys are still there in the decaying lobby. But the RCA museum, including the TV camera used on Apollo 15 and signed by the astronauts, has been broken up and scattered. Where is the murray hill history? From tuhs at tuhs.org Sat Sep 13 05:30:14 2025 From: tuhs at tuhs.org (James Johnston via TUHS) Date: Fri, 12 Sep 2025 12:30:14 -0700 Subject: [TUHS] bell labs murray hill artifacts In-Reply-To: References: Message-ID: When Lucent took over MH, the museum in the front was scattered to the wind. I have no idea what happened to the Stowkowsky (sp?) recordings, the "first talking movie" recording, artificial larynx, and the like. I know that the leadership regarded them as "stuck in the past" and ripped stuff out wholesale. After the 1996 split, I was no longer welcome at MH, so I can't say much more about anything inside the security zone. On Fri, Sep 12, 2025 at 11:34 AM ron minnich via TUHS wrote: > where's the shockley transistor? > > and the map of the US showing the Bell System empire, with a light for each > central office? > > aside: the old RCA labs building is still there in princeton, and the 7 > Emmys are still there in the decaying lobby. But the RCA museum, including > the TV camera used on Apollo 15 and signed by the astronauts, has been > broken up and scattered. > > Where is the murray hill history? > -- James D. (jj) Johnston Former Chief Scientist, Immersion Networks From tuhs at tuhs.org Sat Sep 13 08:16:46 2025 From: tuhs at tuhs.org (David Chmelik via TUHS) Date: Fri, 12 Sep 2025 22:16:46 -0000 (UTC) Subject: [TUHS] Is it still possible to find old USENET postings? References: <202509101711.58AHBUVI035333@freefriends.org> Message-ID: <10a264e$mht$1@ciao.gmane.io> On Wed, 10 Sep 2025 11:11:30 -0600, Arnold Robbins via TUHS wrote: > I'm looking for something posted to comp.unix.questions in October of > 1989, for which I have a printout. I'm hoping I can still find it online > somehow. [...] In Usenet newsgroups about Usenet, like alt.(culture|fan).usenet, news.*, and ones on newsreaders (Pan2), etc. people linked some old archives (other replies already mentioned some) but also said like check large commercial Usenet newsservers; GigaNews was a top example but they mentioned several others. Some have free trials and others have prices so low that for how long they go back for text groups, I think it's worth it so will signup... maybe same as free archives mentioned, but it'd be easier for me, and maybe more reliable than free servers that often go down or lose historical posts. From tuhs at tuhs.org Sat Sep 13 10:11:22 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Sat, 13 Sep 2025 10:11:22 +1000 Subject: [TUHS] bell labs murray hill artifacts In-Reply-To: References: Message-ID: The Shockley-Bardeen-Brattain (sic) transistor you're referring to was just a replica anyway. The original was lost long ago as part of normal lab activity. -rob On Sat, Sep 13, 2025 at 4:24 AM ron minnich via TUHS wrote: > where's the shockley transistor? > > and the map of the US showing the Bell System empire, with a light for each > central office? > > aside: the old RCA labs building is still there in princeton, and the 7 > Emmys are still there in the decaying lobby. But the RCA museum, including > the TV camera used on Apollo 15 and signed by the astronauts, has been > broken up and scattered. > > Where is the murray hill history? > From tuhs at tuhs.org Sat Sep 13 10:47:58 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Fri, 12 Sep 2025 17:47:58 -0700 Subject: [TUHS] bell labs murray hill artifacts In-Reply-To: References: Message-ID: well, there goes that illusion! On Fri, Sep 12, 2025 at 5:11 PM Rob Pike wrote: > The Shockley-Bardeen-Brattain (sic) transistor you're referring to was > just a replica anyway. The original was lost long ago as part of normal lab > activity. > > -rob > > > On Sat, Sep 13, 2025 at 4:24 AM ron minnich via TUHS > wrote: > >> where's the shockley transistor? >> >> and the map of the US showing the Bell System empire, with a light for >> each >> central office? >> >> aside: the old RCA labs building is still there in princeton, and the 7 >> Emmys are still there in the decaying lobby. But the RCA museum, including >> the TV camera used on Apollo 15 and signed by the astronauts, has been >> broken up and scattered. >> >> Where is the murray hill history? >> > From tuhs at tuhs.org Sun Sep 14 01:39:36 2025 From: tuhs at tuhs.org (Russ Cox via TUHS) Date: Sat, 13 Sep 2025 11:39:36 -0400 Subject: [TUHS] bell labs murray hill artifacts In-Reply-To: References: Message-ID: In late 2019, at the time of the Unix 50th celebration, Nokia still had archivists on staff. They were organized enough to pull out quite a few of the Unix room artifacts for display (in a different room). It has been almost six years now, of course, but I would hope they still have those archives. Best, Russ From tuhs at tuhs.org Sun Sep 14 02:02:20 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Sat, 13 Sep 2025 12:02:20 -0400 Subject: [TUHS] bell labs murray hill artifacts In-Reply-To: References: Message-ID: FWIW, I corresponded with the archivist a few months ago. Doug On Sat, Sep 13, 2025 at 11:40 AM Russ Cox via TUHS wrote: > > In late 2019, at the time of the Unix 50th celebration, Nokia still had > archivists on staff. They were organized enough to pull out quite a few of > the Unix room artifacts for display (in a different room). It has been > almost six years now, of course, but I would hope they still have those > archives. > > Best, > Russ From tuhs at tuhs.org Tue Sep 16 10:09:53 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 16 Sep 2025 10:09:53 +1000 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? Message-ID: Hi all, a quick question. Was Unix the first to separate a file's name from the other file metadata (thus allowing hard links where no filename is "better" than the others)? Thanks, Warren From tuhs at tuhs.org Tue Sep 16 10:30:03 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 15 Sep 2025 20:30:03 -0400 (EDT) Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? Message-ID: <20250916003003.8C27818C073@mercury.lcs.mit.edu> > From: Warren Toomey > Was Unix the first to separate a file's name from the other file metadata UNIX was the first filesystem I know of where file metadata was not kept in the directory. So, yes. Noel From tuhs at tuhs.org Tue Sep 16 10:46:52 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 15 Sep 2025 20:46:52 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: References: Message-ID: below... On Mon, Sep 15, 2025 at 8:10 PM Warren Toomey via TUHS wrote: > Hi all, a quick question. Was Unix the first to separate > a file's name from the other file metadata (thus allowing > hard links where no filename is "better" than the others)? > I'm not 100% I'm following you. As far as I know, a significant innovation in UNIC from its contemporaries, when Ken and Dennis were first considering file systems, was the realization that humans and computers have distinct needs for the file store. So Ken created a first-level (lower) file system that mapped well to the computer itself, which is 100% flat. A numerical index identifies files in that linear list or "map" that is common to all files. Furthermore, the metadata associated with each file is stored in that single, internal list. But that low-level file system is never exposed to anything but the OS kernel. A human-oriented file system is layered on top, where everything is a stream of bytes, and files are given human-understandable names that are associated with the actual file in the low-level store. The OS then defines a structure for some of those files and gives them types (stored in the metadata). What changed over time with UNIC to UNIX was how the upper-level file system was exposed to the user programs. The current hierarchical structure emerged after trying a few others, which was the beauty of the design. What the kernbel uses is the "i-number," while humans use a path. This two-level store was unique as far as I know, so I would believe that it was indeed first From tuhs at tuhs.org Tue Sep 16 10:53:42 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Tue, 16 Sep 2025 10:53:42 +1000 (EST) Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <20250916003003.8C27818C073@mercury.lcs.mit.edu> References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> Message-ID: On Mon, 15 Sep 2025, Noel Chiappa via TUHS wrote: > UNIX was the first filesystem I know of where file metadata was not kept > in the directory. So, yes. I still recall being surprised in the early 70s upon learning that the filename was not part of the file (I came from OS/360 and RSX-11); I thought it was odd, then realised the sheer genius of it. -- Dave From tuhs at tuhs.org Tue Sep 16 12:08:23 2025 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Mon, 15 Sep 2025 19:08:23 -0700 Subject: [TUHS] 1980s troff help? Message-ID: Anyone have a working pic|tbl|eqn|troff setup? In preparation for next week's NFS celebration, it'd be great to get some of the original specs turned into PDFs. The TUHS archive has the NFS kernel source release for non-Sun developers/licensees at https://www.tuhs.org/Archive/Distributions/Sun/ Under usr/src/sun/doc are all the protocol specifications - nfs, rpc, xdr, and yp. But they're all troff source. The README says: To troff the files in this directory, use: pic | tbl | eqn | troff -ms sunhead.ms - This assumes that troff is a front end that sets up ditroff. sunhead.ms requires more font positions than the standard troff allows. Font position 7 is mapped to a constant width font and font position 6 is mapped to a bold constant width font. If you don't have these, you'll have to play with the mappings. The file sunhead.ms is a header file containing some definitions. It'd be great if these specs could be turned into pdfs. I was never any good with troff. There's a site being built with tons of NFS docs; these would be a great addition. Thanks for any help! From tuhs at tuhs.org Tue Sep 16 12:08:30 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 15 Sep 2025 22:08:30 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? Message-ID: Strachey and Stoy independently invented the same idea at essentially the same time. Their operating system, OS1, went into operation before Unix but didn't get a file system until OS4, in April 1970. So Unix beat it by six calendar months, but neither influenced the other. OS6 was published in The Computer Journal in 1972, ahead of Unix. Source with commentary a la Lions was available. Yet Unix got the world's attention. Unix was compiled to machine language for the PDP11, while OS6 was compiled to interpreted code for the Modular One made by Control Technologies Limited. Unix had time-sharing, while OS6 was single user. And finally Unix was American, while OS6 was British. Later there was a similarly accidental "race" to port the two operating systems. I'm not sure whether Wollongong or Oxford won. Doug From tuhs at tuhs.org Tue Sep 16 12:24:12 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 15 Sep 2025 22:24:12 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? External Message-ID: My arithmetic mod 12 is bad. August for the Unix file system to April for OS4 is not six months. I won't offer another guess. Doug From tuhs at tuhs.org Tue Sep 16 12:44:39 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 15 Sep 2025 22:44:39 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: References: Message-ID: On Mon, Sep 15, 2025 at 8:19 PM Warren Toomey via TUHS wrote: > Hi all, a quick question. Was Unix the first to separate > a file's name from the other file metadata (thus allowing > hard links where no filename is "better" than the others)? I wondered if perhaps Multics had the concept, but it appears that it does not, if I am ready section 2.1 of https://multicians.org/fjcc4.html correctly. It does have symbolic links, but those seem to be of the conventional variety we are familiar with from Unix, and the names associated with a link are distinguished from the "primary name", which is special. Multics directory entries of the "branch" variety carry a file's metadata in addition to the primary name; entries of the "link" variety point to other entries. Note that, unlike Unix, where inodes contain physical disk addresses for the file's data (and indirect/doubly-indirect blocks), Multics directory entries include a VTOC index, However, it appears that the Berkeley Timesharing System for the SDS-930 may have had something like hard links. Section 12.9 of https://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/R-21_Time-Sharing_System_Reference_Oct68.pdf describes the directory structure for that system, and notes that what we'd call a directory entry is a 3-word record in a hash table (presumably indexed by file name), with the first two words containing "string pointers to the file name" and the 4th word containing "a pointer to a 4-word 'description block'". The "description block" is described as something containing metadata and sounds an awful lot like an inode. That document goes on to say, "notice that several entries in the hash table may point to a single description block; the associated names are then synonyms for the same object, which can be referenced by any of them." The next paragraph continues: "The command DEFINE NAME creates a new name to point to an existing description block; conversely DELETE NAME detaches the name from its description block, the description block itself is lost only if this was the only name pointing to it." So the Project GENIE OS at least separated file names and metadata, though it appears that each user had a single directory level. Regardless, I'd say that meets the requested criteria. I wonder what DTSS did in this area, if anything. - Dan C. From tuhs at tuhs.org Tue Sep 16 12:53:15 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 15 Sep 2025 20:53:15 -0600 Subject: [TUHS] 1980s troff help? In-Reply-To: References: Message-ID: <202509160253.58G2rFDA072203@freefriends.org> I was able to get the plan9port troff going without too much trouble. It let me format a book published in 1981 without too much trouble. I can send you the notes I made. I'm not too soure about fonts 6 and 7 though. Let me know (off list) if you want more info. Arnold Tom Lyon via TUHS wrote: > Anyone have a working pic|tbl|eqn|troff setup? In preparation for next > week's NFS celebration, it'd be great to get some of the original specs > turned into PDFs. > > The TUHS archive has the NFS kernel source release for non-Sun > developers/licensees at https://www.tuhs.org/Archive/Distributions/Sun/ > > Under usr/src/sun/doc are all the protocol specifications - nfs, rpc, xdr, > and yp. But they're all troff source. The README says: > > To troff the files in this directory, use: > > pic | tbl | eqn | troff -ms sunhead.ms - > > This assumes that troff is a front end that sets up ditroff. sunhead.ms > requires more font positions than the standard troff allows. Font position 7 > is mapped to a constant width font and font position 6 is mapped to a bold > constant width font. If you don't have these, you'll have to play with the > mappings. > > The file sunhead.ms is a header file containing some definitions. > > > It'd be great if these specs could be turned into pdfs. > I was never any good with troff. > > There's a site being built with tons of NFS docs; these would be a great > addition. > > Thanks for any help! From tuhs at tuhs.org Tue Sep 16 12:59:02 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 15 Sep 2025 20:59:02 -0600 Subject: [TUHS] 1980s troff help? In-Reply-To: <202509160253.58G2rFDA072203@freefriends.org> References: <202509160253.58G2rFDA072203@freefriends.org> Message-ID: <202509160259.58G2x2bH072872@freefriends.org> I'll also note that in the past I've had a lot of success with groff -C (compatibility mode) using original Unix macro files from the TUHS archives. That may provide another (easier) option. Arnold Robbins via TUHS wrote: > I was able to get the plan9port troff going without too much > trouble. It let me format a book published in 1981 without > too much trouble. I can send you the notes I made. > > I'm not too soure about fonts 6 and 7 though. > > Let me know (off list) if you want more info. > > Arnold > > Tom Lyon via TUHS wrote: > > > Anyone have a working pic|tbl|eqn|troff setup? In preparation for next > > week's NFS celebration, it'd be great to get some of the original specs > > turned into PDFs. > > > > The TUHS archive has the NFS kernel source release for non-Sun > > developers/licensees at https://www.tuhs.org/Archive/Distributions/Sun/ > > > > Under usr/src/sun/doc are all the protocol specifications - nfs, rpc, xdr, > > and yp. But they're all troff source. The README says: > > > > To troff the files in this directory, use: > > > > pic | tbl | eqn | troff -ms sunhead.ms - > > > > This assumes that troff is a front end that sets up ditroff. sunhead.ms > > requires more font positions than the standard troff allows. Font position 7 > > is mapped to a constant width font and font position 6 is mapped to a bold > > constant width font. If you don't have these, you'll have to play with the > > mappings. > > > > The file sunhead.ms is a header file containing some definitions. > > > > > > It'd be great if these specs could be turned into pdfs. > > I was never any good with troff. > > > > There's a site being built with tons of NFS docs; these would be a great > > addition. > > > > Thanks for any help! From tuhs at tuhs.org Tue Sep 16 14:13:41 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Tue, 16 Sep 2025 14:13:41 +1000 Subject: [TUHS] 1980s troff help? In-Reply-To: References: Message-ID: On Mon, Sep 15, 2025 at 07:08:23PM -0700, Tom Lyon via TUHS wrote: > Anyone have a working pic|tbl|eqn|troff setup? In preparation for next > week's NFS celebration, it'd be great to get some of the original specs > turned into PDFs. > > The TUHS archive has the NFS kernel source release for non-Sun > developers/licensees at https://www.tuhs.org/Archive/Distributions/Sun/ > > Under usr/src/sun/doc are all the protocol specifications - nfs, rpc, xdr, > and yp. But they're all troff source. The README says: > > To troff the files in this directory, use: > > pic | tbl | eqn | troff -ms sunhead.ms - > > This assumes that troff is a front end that sets up ditroff. sunhead.ms > requires more font positions than the standard troff allows. Font position 7 > is mapped to a constant width font and font position 6 is mapped to a bold > constant width font. If you don't have these, you'll have to play with the > mappings. > > The file sunhead.ms is a header file containing some definitions. > > > It'd be great if these specs could be turned into pdfs. > I was never any good with troff. > > There's a site being built with tons of NFS docs; these would be a great > addition. > > Thanks for any help! Output can be compared to scans. -- Networking on the Sun Workstation Part Number: 800-1177-01 Revision: A of 15 April 1985 For: Sun System Release 2.0 https://archive.org/details/Sun_800-1177-01_SunOS_2.0_Networking_on_the_Sun_Workstation https://archive.org/details/sun-networking -- Networking on the Sun Workstation 800-1325-03 Revision: B of 17 February 1986 bitsavers pdf/sun/sunos/3.0/ 800-1324-03B_Networking_on_the_Sun_Workstation_198602.pdf From tuhs at tuhs.org Tue Sep 16 14:21:08 2025 From: tuhs at tuhs.org (Tom Perrine via TUHS) Date: Mon, 15 Sep 2025 21:21:08 -0700 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <20250916003003.8C27818C073@mercury.lcs.mit.edu> References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> Message-ID: I think that was also true of Multics. On Mon, Sep 15, 2025 at 5:30 PM Noel Chiappa via TUHS wrote: > > From: Warren Toomey > > > Was Unix the first to separate a file's name from the other file > metadata > > UNIX was the first filesystem I know of where file metadata was not kept in > the directory. So, yes. > > Noel > From tuhs at tuhs.org Tue Sep 16 14:40:06 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 15 Sep 2025 21:40:06 -0700 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: References: Message-ID: In case anyone is further interested in Strachey & Stoy's OS6.... https://www.cs.ox.ac.uk/files/3230/PRG08.pdf Excerpt: A single file may be associated with different pairs of names in different indexes, or even in the same index. This is one form of sharing of files: two different entries point to the same file. The file here is equivalent to an inode. "Pairs of name" can be file name and file type but the system doesn't care which meaning a user attaches. There is no link count and the system has to GC. There is even a link command! Theoretically one can construct a directory tree (an index table). The paper is an interesting & easy read! I wonder how much of the OS6 & Unix designs were influenced by the respective culture's sensibilities (British and American as well as University vs Bell Labs)! Bakul > On Sep 15, 2025, at 7:08 PM, Douglas McIlroy via TUHS wrote: > > Strachey and Stoy independently invented the same idea at essentially > the same time. > Their operating system, OS1, went into operation before Unix but > didn't get a file system until OS4, in April 1970. So Unix beat it by > six calendar months, but neither influenced the other. > > OS6 was published in The Computer Journal in 1972, ahead of Unix. > Source with commentary a la Lions was available. Yet Unix got the > world's attention. Unix was compiled to machine language for the > PDP11, while OS6 was compiled to interpreted code for the Modular One > made by Control Technologies Limited. Unix had time-sharing, while OS6 > was single user. And finally Unix was American, while OS6 was British. > > Later there was a similarly accidental "race" to port the two > operating systems. I'm not sure whether Wollongong or Oxford won. > > Doug From tuhs at tuhs.org Tue Sep 16 16:15:12 2025 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 16 Sep 2025 16:15:12 +1000 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> Message-ID: Is the return of a stat() call from the directory block not file "metadata"? G On Tue, 16 Sept 2025, 2:21 pm Tom Perrine via TUHS, wrote: > I think that was also true of Multics. > > > On Mon, Sep 15, 2025 at 5:30 PM Noel Chiappa via TUHS > wrote: > > > > From: Warren Toomey > > > > > Was Unix the first to separate a file's name from the other file > > metadata > > > > UNIX was the first filesystem I know of where file metadata was not kept > in > > the directory. So, yes. > > > > Noel > > > From tuhs at tuhs.org Tue Sep 16 18:36:57 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Tue, 16 Sep 2025 04:36:57 -0400 (EDT) Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? Message-ID: <20250916083657.010F018C073@mercury.lcs.mit.edu> > From: Dan Cross > I wondered if perhaps Multics had the concept You have no idea of the depth of the tarpit you just stepped into! Making it even deeper, Multics has two quite different generations of file systems; read about the second one (reasons why, etc) here: https://www.multicians.org/nss.html File metadata was kept in the directory in the first; in the second, much metadata _was_ moved to a thing called a 'Volume Table of Contents' (VTOC), which is sort of like the ilist (the above says "[w]e were aware of the Unix file system design, where there was a similar split between naming data in directories and physical data in the inode"). However, even in the New Storage System, _some_ metadata (ACLs, etc) remained in the directories, see: https://www.multicians.org/mtbs/MTB-220.pdf Just to increase the complexity, in both systems, in addition to the segment's primary name (sort of a 'hard link'), and logical ('soft') links, segments could have additional secondary names (much used for short names for commands - the familiar ls, cp, mv, etc were all short names), kept in the same directory as the primary name: https://multicians.org/mga.html#additionalnames (Please excuse Bernie.) Are we having fun yet? :-) > it appears that the Berkeley Timesharing System for the SDS-930 may > have had something like hard links I was wondering if BTSS (on which, of course, Ken worked) had such, but was too lazy to look. Thanks! > From: George Michaelson > Is the return of a stat() call from the directory block not file > "metadata"? stat() mostly return information from the inode. Noel From tuhs at tuhs.org Tue Sep 16 19:58:20 2025 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 16 Sep 2025 19:58:20 +1000 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <20250916083657.010F018C073@mercury.lcs.mit.edu> References: <20250916083657.010F018C073@mercury.lcs.mit.edu> Message-ID: stat() mostly return information from the inode Which is not the contents of the file. It's data about the file. It's attributes, such as creation and modification times, its owner and group, pointers to extended attributes. Its... metadata. G From tuhs at tuhs.org Tue Sep 16 22:34:05 2025 From: tuhs at tuhs.org (Russ Cox via TUHS) Date: Tue, 16 Sep 2025 08:34:05 -0400 Subject: [TUHS] 1980s troff help? In-Reply-To: References: Message-ID: I downloaded the Sun archive, changed the troff to refer to fonts C and CB instead of L and LB, and then ran it through the Heirloom Doctools version of troff with no problems. I published the results in a Git repo at https://github.com/rsc/nfs. Specifically see: https://github.com/rsc/nfs/blob/main/release.pdf https://github.com/rsc/nfs/tree/main/usr/src/sun/doc The conversion is fairly close to the scans that Jonathan Gray posted but not exact. The released text is not always the same as the scanned text, and the code for generating the tables of contents was not released, so those are missing. But overall it is surprisingly close. Best, Russ From tuhs at tuhs.org Tue Sep 16 23:50:59 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Tue, 16 Sep 2025 09:50:59 -0400 (EDT) Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? Message-ID: <20250916135059.596E518C073@mercury.lcs.mit.edu> > From: George Michaelson > Which is not the contents of the file. It's data about the file. > It's attributes, such as creation and modification times, its owner > and group, pointers to extended attributes. > Its... metadata. You said: >>> Is the return of a stat() call from the directory block not file >>> "metadata"? I replied: >> stat() mostly return information from the inode. Note the "from the directory block". Noel !h From tuhs at tuhs.org Wed Sep 17 00:04:12 2025 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Tue, 16 Sep 2025 07:04:12 -0700 Subject: [TUHS] 1980s troff help? In-Reply-To: References: Message-ID: Awesome! Many thanks! On Tue, Sep 16, 2025 at 5:34 AM Russ Cox wrote: > I downloaded the Sun archive, changed the troff to refer to > fonts C and CB instead of L and LB, and then ran it through > the Heirloom Doctools > version of troff with no problems. > I published the results in a Git repo at https://github.com/rsc/nfs. > > Specifically see: > https://github.com/rsc/nfs/blob/main/release.pdf > https://github.com/rsc/nfs/tree/main/usr/src/sun/doc > > The conversion is fairly close to the scans that Jonathan Gray > posted but not exact. The released text is not always the same > as the scanned text, and the code for generating the tables of > contents was not released, so those are missing. > But overall it is surprisingly close. > > Best, > Russ > > From tuhs at tuhs.org Wed Sep 17 02:24:07 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 16 Sep 2025 12:24:07 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> Message-ID: On Tue, Sep 16, 2025 at 2:15 AM George Michaelson via TUHS wrote: > Is the return of a stat() call from the directory block not file "metadata"? As Noel pointed out, there's no real metadata in the directory entry itself. The directory entry is really just a pair, consisting of a string (the path name component in the entry) and an inode number. Critically, the inode is stored separately, and holds all of the metadata describing a file. So while `stat()` may take a file name as an argument, internally the kernel uses that to look up the associated inode and populates the structure it returns from _that_, not from the directory entry. But as usual, it's slightly more complicated than that: on the PDP-11 Unix directory entries were fixed size: 16 bytes; 2 bytes for the inode number (interpreted as an unsigned 16-bit integer) and 14 for the file name part. Working with these is incredibly simple. But Berkeley expanded this a bit with UFS, allowing 4 bytes (interpreted as an unsigned 32-bit integer) for the inode number and up to 255 characters for the file name. But since most file names were well-short of 255 characters, storing them as such was wasteful, so they added two other fields: a record length and a name length. This enabled them to compress entries down to a minimal record size, aligned to a 4-byte boundary, and thus pack entries together rather more tightly than if the entire 256 bytes (255 + 1 for the terminating NUL byte) were stored directly. Lookups---the most common operation---remained simple: to retrieve the "next" entry in a directory, one need only add the offset from the current entry to that entry's position relative to the start of the directory file, but that was an extra step compared to what workaday programmers were used to doing (which was just opening the directory file read-only and, well, reading from it), so the `opendir`/`readdir`/`closedir` interfaces were added to hide this in the kernel and mimic the more traditional open/read/close loop. Unfortunately, adding and removing entries became significantly more complex than in earlier file system versions. Regardless, the additional data added to directory entries are really more details of the implementation of directories themselves, and not metadata about the file an entry points to. - Dan C. > On Tue, 16 Sept 2025, 2:21 pm Tom Perrine via TUHS, wrote: > > I think that was also true of Multics. > > > > > > On Mon, Sep 15, 2025 at 5:30 PM Noel Chiappa via TUHS > > wrote: > > > > > > From: Warren Toomey > > > > > > > Was Unix the first to separate a file's name from the other file > > > metadata > > > > > > UNIX was the first filesystem I know of where file metadata was not kept > > in > > > the directory. So, yes. > > > > > > Noel > > > > > From tuhs at tuhs.org Wed Sep 17 02:57:54 2025 From: tuhs at tuhs.org (Paul McJones via TUHS) Date: Tue, 16 Sep 2025 09:57:54 -0700 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <175801671968.996474.11265049190579299170@minnie.tuhs.org> References: <175801671968.996474.11265049190579299170@minnie.tuhs.org> Message-ID: <0D0E254E-9FDB-4B29-ADB0-262F59B0FAE6@mcjones.org> > On 15 Sep 2025 21:40:06 -0700,Bakul Shah wrote: > > In case anyone is further interested in Strachey & Stoy's OS6.... > > https://www.cs.ox.ac.uk/files/3230/PRG08.pdf > > Excerpt: > A single file may be associated with different pairs of > names in different indexes, or even in the same index. This is > one form of sharing of files: two different entries point to the > same file. Perhaps also of interest: Christopher Strachey and Joseph Stoy. The text of OS6Pub. PRG-09, Programming Research Group, Oxford University Computer Laboratory, July 1972. http://www.cs.ox.ac.uk/files/3231/PRG09.pdf Christopher Strachey and Joseph Stoy. The text of OS6Pub (Commentary). PRG-09 (c), Programming Research Group, Oxford University Computer Laboratory, July 1972. https://www.cs.ox.ac.uk/files/4632/PRG-9%28c%29.pdf From tuhs at tuhs.org Wed Sep 17 07:03:13 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 16 Sep 2025 17:03:13 -0400 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <20250916083657.010F018C073@mercury.lcs.mit.edu> References: <20250916083657.010F018C073@mercury.lcs.mit.edu> Message-ID: On Tue, Sep 16, 2025 at 4:44 AM Noel Chiappa via TUHS wrote: > > From: Dan Cross > > > I wondered if perhaps Multics had the concept > > You have no idea of the depth of the tarpit you just stepped into! Making it > even deeper, Multics has two quite different generations of file systems; > read about the second one (reasons why, etc) here: > > https://www.multicians.org/nss.html > > File metadata was kept in the directory in the first; in the second, much > metadata _was_ moved to a thing called a 'Volume Table of Contents' (VTOC), > which is sort of like the ilist (the above says "[w]e were aware of the Unix > file system design, where there was a similar split between naming data in > directories and physical data in the inode"). However, even in the New > Storage System, _some_ metadata (ACLs, etc) remained in the directories, see: > > https://www.multicians.org/mtbs/MTB-220.pdf > > Just to increase the complexity, in both systems, in addition to the > segment's primary name (sort of a 'hard link'), and logical ('soft') links, > segments could have additional secondary names (much used for short names for > commands - the familiar ls, cp, mv, etc were all short names), kept in the > same directory as the primary name: > > https://multicians.org/mga.html#additionalnames > > (Please excuse Bernie.) Are we having fun yet? :-) Ooops, yup: I had looked at the VTOC code in Multics, but sent before I finished editing my reply to mention it beyond a half-finished sentence; mea culpa, there! FWIW from what I saw, the VTOC entry contains physical disk addresses for files, and is indexed by a "VTOCE index", which is an integer that is stored in branch directory entries. However, most of the metadata about the file, such as timestamps, ACL pointers, the primary name, size, etc remains in branch entries. For those interested in the gory details, the definition of a Multics directory entry, as of MR12.8 is online: https://dps8m.gitlab.io/sb/MR12.8/library_dir_dir/include/dir_entry.incl.pl1.html (No problem about Bernie; he's a character.) > > it appears that the Berkeley Timesharing System for the SDS-930 may > > have had something like hard links > > I was wondering if BTSS (on which, of course, Ken worked) had such, but was > too lazy to look. Thanks! Sure thing! - Dan C. From tuhs at tuhs.org Wed Sep 17 09:10:51 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 17 Sep 2025 09:10:51 +1000 Subject: [TUHS] Building the two-pass Portable C Compiler Message-ID: I seem to have lots of questions this month! I'm trying to build the two-pass version of the Portable C compiler on 2.11BSD. I'm using the OpenSimH disk image from https://github.com/chasecovello/211bsd-pidp11 I am in /usr/src/lib/pcc doing a make -f Makefile.twopass. We get down to this error: comm1.c:3: STRINGFILE undefined; func. StringFile and the relevant source code line is: static char *StringFile = STRINGFILE; /* From Makefile -DSTRINGFILE= ... */ Neither Makefile nor Makefile.twopass define STRINGFILE, so I am at a loss. The code seems to use this file for error reporting: errprep(soff, buf) unsigned short soff; ... errfd = open(StringFile, O_RDONLY, 0); Could it be /usr/share/misc/lintstrings which seems to have compiler error message in it? Does anybody have a memory of this? Thanks, Warren From tuhs at tuhs.org Wed Sep 17 12:49:56 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 16 Sep 2025 20:49:56 -0600 Subject: [TUHS] Building the two-pass Portable C Compiler In-Reply-To: References: Message-ID: <202509170249.58H2nu33057179@freefriends.org> Why not just try it and see what happens? Arnold Warren Toomey via TUHS wrote: > I seem to have lots of questions this month! > > I'm trying to build the two-pass version of the Portable C compiler > on 2.11BSD. I'm using the OpenSimH disk image from > https://github.com/chasecovello/211bsd-pidp11 > > I am in /usr/src/lib/pcc doing a make -f Makefile.twopass. > We get down to this error: > > comm1.c:3: STRINGFILE undefined; func. StringFile > > and the relevant source code line is: > > static char *StringFile = STRINGFILE; /* From Makefile -DSTRINGFILE= ... */ > > Neither Makefile nor Makefile.twopass define STRINGFILE, so I am > at a loss. The code seems to use this file for error reporting: > > errprep(soff, buf) > unsigned short soff; > ... > errfd = open(StringFile, O_RDONLY, 0); > > Could it be /usr/share/misc/lintstrings which seems to have > compiler error message in it? > > Does anybody have a memory of this? > > Thanks, Warren From tuhs at tuhs.org Wed Sep 17 13:55:16 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 16 Sep 2025 23:55:16 -0400 Subject: [TUHS] Building the two-pass Portable C Compiler In-Reply-To: References: Message-ID: I believe that is the file you want, since it is defined in the lint Makefile and given that pcc started out as lint, and given this comment on the lint READ_ME (note the files are actually: /usr/lib/mip in the 2.11BSD tree) /* * @(#)READ_ME 1.2 (Berkeley) 4/8/85 */ Most of lint's source files are shared with the portable compiler: they are found in /usr/src/lib/mip. The files here are only those which are unique to lint. On Tue, Sep 16, 2025 at 7:10 PM Warren Toomey via TUHS wrote: > I seem to have lots of questions this month! > > I'm trying to build the two-pass version of the Portable C compiler > on 2.11BSD. I'm using the OpenSimH disk image from > https://github.com/chasecovello/211bsd-pidp11 > > I am in /usr/src/lib/pcc doing a make -f Makefile.twopass. > We get down to this error: > > comm1.c:3: STRINGFILE undefined; func. StringFile > > and the relevant source code line is: > > static char *StringFile = STRINGFILE; /* From Makefile -DSTRINGFILE= > ... */ > > Neither Makefile nor Makefile.twopass define STRINGFILE, so I am > at a loss. The code seems to use this file for error reporting: > > errprep(soff, buf) > unsigned short soff; > ... > errfd = open(StringFile, O_RDONLY, 0); > > Could it be /usr/share/misc/lintstrings which seems to have > compiler error message in it? > > Does anybody have a memory of this? > > Thanks, Warren > From tuhs at tuhs.org Wed Sep 17 20:13:26 2025 From: tuhs at tuhs.org (Leah Neukirchen via TUHS) Date: Wed, 17 Sep 2025 12:13:26 +0200 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: (Dan Cross via TUHS's message of "Tue, 16 Sep 2025 12:24:07 -0400") References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> Message-ID: <87y0qdfku1.fsf@vuxu.org> Dan Cross via TUHS writes: > Lookups---the most common > operation---remained simple: to retrieve the "next" entry in a > directory, one need only add the offset from the current entry to that > entry's position relative to the start of the directory file, but that > was an extra step compared to what workaday programmers were used to > doing (which was just opening the directory file read-only and, well, > reading from it), so the `opendir`/`readdir`/`closedir` interfaces > were added to hide this in the kernel and mimic the more traditional > open/read/close loop. And then we had to wait until POSIX.1-2024 until the "old" interface became standardized (which is useful because opendir doesn't let you specify buffer size). https://pubs.opengroup.org/onlinepubs/9799919799/functions/posix_getdents.html -- Leah Neukirchen https://leahneukirchen.org/ From tuhs at tuhs.org Thu Sep 18 00:06:39 2025 From: tuhs at tuhs.org (Jeremy C. Reed via TUHS) Date: Wed, 17 Sep 2025 14:06:39 +0000 (UTC) Subject: [TUHS] Building the two-pass Portable C Compiler In-Reply-To: References: Message-ID: <63f753d7-be1c-9f18-9b66-25713945289@reedmedia.net> > Neither Makefile nor Makefile.twopass define STRINGFILE, so I am > at a loss. The code seems to use this file for error reporting: Also look at ucb/mkstr.c and man/man1/mkstr.1 in the 2.11BSD. * Program to create a string error message file * from a group of C programs. Arguments are the name * of the file where the strings are to be placed, the * prefix of the new files where the processed source text * is to be placed, and the files to be processed. * * The program looks for 'error("' in the source stream. So you may be able to use mkstr to generate it. Some examples in 2.11BSD also include kermit, sendmail, and news. I believe that the code uses mkstr to build a single file of all the error strings and builds replacement code that excludes the error strings but uses offset number instead. From tuhs at tuhs.org Thu Sep 18 00:36:24 2025 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Wed, 17 Sep 2025 16:36:24 +0200 Subject: [TUHS] Quick Question: Early Filesystems and Name/Metadata Separation? In-Reply-To: <87y0qdfku1.fsf@vuxu.org> References: <20250916003003.8C27818C073@mercury.lcs.mit.edu> <87y0qdfku1.fsf@vuxu.org> Message-ID: <20250917143624.hSoVMMuH@steffen%sdaoden.eu> Leah Neukirchen via TUHS wrote in <87y0qdfku1.fsf at vuxu.org>: |Dan Cross via TUHS writes: | |> Lookups---the most common |> operation---remained simple: to retrieve the "next" entry in a |> directory, one need only add the offset from the current entry to that |> entry's position relative to the start of the directory file, but that |> was an extra step compared to what workaday programmers were used to |> doing (which was just opening the directory file read-only and, well, |> reading from it), so the `opendir`/`readdir`/`closedir` interfaces |> were added to hide this in the kernel and mimic the more traditional |> open/read/close loop. | |And then we had to wait until POSIX.1-2024 until the "old" interface |became standardized (which is useful because opendir doesn't let you |specify buffer size). And with the (yet only "encouraged") DT_FORCE_TYPE flag for |https://pubs.opengroup.org/onlinepubs/9799919799/functions/posix_getdent\ |s.html a painful, racy / unsafe programming could finally iterate out. Just last week, due to a thread on a FreeBSD list i read, i looked into an implementation that is the quarter of a century old; it contains several (preprocessor conditionalized) code paths, dependend upon availability of certain *at() series functions (not to talk about ENOSYS handling, which is done badly), and it was a pain, and very unsafe. No, it effectively is broken to create absolute (real)paths and/or chdir() (multi-threading was a thing, that is locked..) for querying file statuses. Hoping for this. (And posix_devctl() instead of ioctl(), though i think .. the Unix world becomes somewhat easy, anyhow.) Plan9port that is talked about here at the moment went into the other direction five years ago, and dropped all the getdents / getdirentries (maybe) shims to end up only with opendir. 'Thing was also that opendir() stuff performs allocations, and thus sucks in the entire memory cache layer, and that sucks in threading stuff ... All that does no longer matter with all the init, fini etc sections, ifunc's, TLS (ThreadSpecificData), of modern times. Of course. P.S.: i would at least remove the defunct header fields if you do not want to fix it, Warren. Isn't that nothing more than a sed(1) invocation? It is so .. an ugly alien spot, and it cannot even be healed with tea tree oil. (Sigh.) --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 Thu Sep 18 07:08:46 2025 From: tuhs at tuhs.org (Stuff Received via TUHS) Date: Wed, 17 Sep 2025 17:08:46 -0400 Subject: [TUHS] 1980s troff help? In-Reply-To: References: Message-ID: On 2025-09-16 08:34, Russ Cox via TUHS wrote: > I downloaded the Sun archive, changed the troff to refer to > fonts C and CB instead of L and LB, and then ran it through > the Heirloom Doctools > version of troff with no problems. I was going to put them through the troff system on my Solaris 11.3 box but it has no "pic" -- most surprisingly. S. > I published the results in a Git repo at https://github.com/rsc/nfs. > > Specifically see: > https://github.com/rsc/nfs/blob/main/release.pdf > https://github.com/rsc/nfs/tree/main/usr/src/sun/doc > > The conversion is fairly close to the scans that Jonathan Gray > posted but not exact. The released text is not always the same > as the scanned text, and the code for generating the tables of > contents was not released, so those are missing. > But overall it is surprisingly close. > > Best, > Russ From tuhs at tuhs.org Fri Sep 19 02:53:24 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 18 Sep 2025 12:53:24 -0400 Subject: [TUHS] History of cal(1)? Message-ID: Over on the Multicians list, Jeffrey Johnson asked a question about the Multics `calendar` program, which was written by Tom van Vleck in Dec, 1973. Despite what some man pages say, the analogous Unix `cal` program appears to have arrived in the 5th Edition (mid 1974). Jeffrey's question was whether `cal` was inspired by `calendar`? My suspicion is that it was not, and this is a case of parallel invention: after all, a program that prints out a calendar is obviously useful. I also suspect that program, or something substantially similar, had existed for quite a while before someone tossed it into /usr/source/s1 in time for 5th Edition. Does anyone recall who wrote it, and when? But this also rekindles my curiosity about something I've always wondered: what _was_ the level of communication between the folks at Bell Labs and the Multics people after 1969? By all accounts, individuals remained friendly and collegial with one another, but it seems like communication (let alone collaboration) between the two "camps" was minimal. Is that accurate? - Dan C. From tuhs at tuhs.org Fri Sep 19 03:36:36 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Thu, 18 Sep 2025 17:36:36 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: Hi Dan, This is not a full answer to your question but cal appeared in Research UNIX 1st Edition, Nov 3, 1971. I'd be interested to compare the source code, in terms of how it was implemented, between the original and the version I have on this phone which is part of util-linux 2.40.2. Best regards, Cameron Tyre From tuhs at tuhs.org Fri Sep 19 04:31:19 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 18 Sep 2025 14:31:19 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: On Thu, Sep 18, 2025 at 1:36 PM Cameron Míċeál Tyre via TUHS wrote: > Hi Dan, > > This is not a full answer to your question but cal appeared in Research UNIX 1st Edition, Nov 3, 1971. Ah, good catch! It was in /usr/ken and in section 6 of the manual (games), not section 1. > I'd be interested to compare the source code, in terms of how it was implemented, between the original and the version I have on this phone which is part of util-linux 2.40.2. Well, for starters, I'd guess it was in assembly language. - Dan C. From tuhs at tuhs.org Fri Sep 19 05:51:25 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 18 Sep 2025 15:51:25 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: On Thu, Sep 18, 2025 at 12:54 PM Dan Cross via TUHS wrote: > ... > > But this also rekindles my curiosity about something I've always > wondered: what _was_ the level of communication between the folks at > Bell Labs and the Multics people after 1969? By all accounts, > individuals remained friendly and collegial with one another, but it > seems like communication (let alone collaboration) between the two > "camps" was minimal. Is that accurate? > Doug and Ken are the best to answer for the MH folk. But I'll take a stab at the communications within the CS Research Community during the 70s, which I lived in. As we all know, Unix spread quickly outside of MH to researchers, and a great deal of development took place "on the outside." Some of those ideas came back to the Research versions, but not all. But I think there was a good bit of cross-pollination within the community — even before Usenet or the Internet itself. Sometimes we would swap magnetic tapes directly, and often we would bring tapes to a conference with our work and come home with work from others. We knew each other and talked. Taking MetCalfe's law into account, because there so many Unix installations (and we were all talking to each other), that style of sharing could not happen with Multics, I will posit that by 1975 most, if not nearly all, researchers in the systems world were at least familiar with Elliott Organick's 1972 book — "*The Multics System: An Examination of its Structure*," and many of us had read it and trying to learn lessons from it. It was a text that was referred to in my undergrad OS course, and by the time I was a grad student working in systems, it was pretty much assumed that everyone in the room had read it. I certainly thought Multics had some cool ideas. However, I barely touched a Multics system in those days via my limited remote access (MIT's system). And I never physically saw a Multics-capable processor until many years later. I admit that from reading Organski's book, I had some wild images of computer operators mounting mag tapes so a program could continue execution after a segment defined as not being directly addressable. So while I was familiar with Multics, I certainly "knew" a lot more about UNIX. I had it, and I was hacking its kernel. I personally did little of what we call programming on Multics, and at the same time, I was being paid to program in Unix (and some TOPS-10/TOPS-20 shop). I don't think I'm really unique here. If the data from website Multicians.org is correct, there were just too few Multics installations to be found (11 in 1975), and only two were at universities (MIT and the University of Louisiana). The other nine were at commercial sites. Note that in 1975, we know there were at least 5 times the number of Unix installations. Most of these sites were ones that had had some level of CS Research. By 1979, the numbers were 25 for Multics and over 600 for Unix. By 1979, Multics OS was stable, and the hardware to run it (the "3rd generation" H6180 had been on the market since 1973) had certainly matured from the original GE-645. So why did Multics not play a more significant role? Once again, core economics of the time played a huge part. If you use Google AI, it will tell you that a Honeywell H6180 computer system running Multics, like MIT was running in 1979, had a list price of about $7 million when it was introduced. This price included a complete system with multiple components, not just the central computer unit. Now think about a PDP 11/34, with full 256K bytes of memory, a couple of RK05 and probably an RP04 equivalent as its disk, 9-track tape, Printonix printer, and 16 serial ports using after-market DH11 — a pretty standard V7 installation, which costs approximately $100-150K. Even if you ran it on a Vax, it was not more than approximately 3 times that number. But this is a massive difference from the $7M for a Multic system. It's a simple Christenson disruption — the "lesser" system wins over the earlier, more "mature", and full-featured, "better" one. As a result, cross-pollination opportunities were not available. Unix/V7 and its derivatives got the attention of units because the economics favored it. Just like Linux receives today. Clem From tuhs at tuhs.org Fri Sep 19 13:41:05 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 18 Sep 2025 23:41:05 -0400 Subject: [TUHS] History of cal(1)? Message-ID: Multics established connections between BTL and MIT, as did Unix between BTL and many CS departments. However, I don't remember much communication with MIT about Unix. Perhaps that is because MIT was not an early adopter, so by the time Unix arrived there connections ran every which way, not just to the hub at Murray Hill. Early adoption was precluded by the MIT legal department's opinion that AT&T's trade-secret assertion was too onerous. As I understand it, the main sticking point was that one was not supposed to use anything one learned from Unix code in any other context. I don't how other universities' legal departments regarded the trade secret--perhaps that the cat was so far out of the bag that strict enforcement was impossible. I'd love to hear how MIT's Unix ban was broken, and how long it took for that to happen. Doug From tuhs at tuhs.org Sat Sep 20 02:03:57 2025 From: tuhs at tuhs.org (Theodore Ts'o via TUHS) Date: Fri, 19 Sep 2025 12:03:57 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: <20250919160357.GI416742@mit.edu> On Thu, Sep 18, 2025 at 11:41:05PM -0400, Douglas McIlroy via TUHS wrote: > Early adoption was precluded by the MIT legal department's opinion > that AT&T's trade-secret assertion was too onerous. As I understand > it, the main sticking point was that one was not supposed to use > anything one learned from Unix code in any other context. I don't how > other universities' legal departments regarded the trade > secret--perhaps that the cat was so far out of the bag that strict > enforcement was impossible. > > I'd love to hear how MIT's Unix ban was broken, and how long it took > for that to happen. The way that I heard the story was that MIT lawyers interpreted the trade-secret assertion that since it included the magic term "methods and concepts", if any MIT student was exposed to Unix's "methods and concepts", they would be subject to the trade secret restrictions. This was interpreted as "MIT students would be contiminated and might not be able to be able to work for other employers or do various work in the future, and We Won't Stand For It." The way it was broken was that someone managed to get an MIT Alum working at AT&T as some high-ranking muckety-muck to give MIT a license where the contract did *not* have the Methods and Concepts clause. The problem with that was that AT&T legal *hated* the fact that MIT had a license without the Methods and Concepts clause, and so they refused to acknolwedge to other companies (say, such as Digital), that MIT had a valid Unix source license, and so this prevented MIT Project Athena from getting an official Ultrix source license. But thanks to some other MIT alum, MIT Project Athena mysteriously got an Ultrix sourc tree that had core dumps in it, that was apparently an taken from some engineering machine, as opposed to an official Digital source release. Now, I wasn't there so this is a second or third-hand story; nor have I seen the purpoted license w/o the Methods and Concepts clause. But I have seen the unofficial Ultrix source tree in an MIT AFS volume. Based on this story, if it is true, even though I have been exposed to Unix source code from before the BSD distribution on the 'Net, as far as I know, I was never subject to the Methods and Concepts clause, because MIT has a Unix license without that clause. In any case, given that I never signed any NDA when I Started working as a student systems programmer, the way Trade Secret law works, I would never have been liability; the legal risk would have been solely bourne by MIT. And apparently, MIT at one point wasn't willing to take that legal risk, or require students to sign NDA's. I'm guessing UCB's lawyers had a different understanding of the Methods and Concepts clause, or perhaps didn't take it seriously? As far as I know no staff or students at UCB signed contracts binding them to adhere to keeping AT&T's trade secrets, right? If that's true, the trade secret would have been doomed anyway. Cheers, - Ted From tuhs at tuhs.org Sat Sep 20 02:20:41 2025 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Fri, 19 Sep 2025 12:20:41 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250919160357.GI416742@mit.edu> References: <20250919160357.GI416742@mit.edu> Message-ID: More fun Trade Secret stories. I think around the time that Usenix was funding UUNet, Rick Adams asked an ATT lawyer what would happen if someone uploaded all the Unix source to Usenet from a payphone. "He gulped" and admitted the trade secret protection would be gone. Perhaps Clem was in the room where that conversation happened. From tuhs at tuhs.org Sat Sep 20 02:53:21 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 19 Sep 2025 12:53:21 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> Message-ID: On Fri, Sep 19, 2025 at 12:21 PM Rich Salz via TUHS wrote: > More fun Trade Secret stories. I think around the time that Usenix was > funding UUNet, Rick Adams asked an ATT lawyer what would happen if someone > uploaded all the Unix source to Usenet from a payphone. "He gulped" and > admitted the trade secret protection would be gone. Perhaps Clem was in > the room where that conversation happened. > Nope. But the difference is that CMU's lawyers made any student who had AT&T code sign an NDA (even for the OS course). They wanted to ensure we understand the source code we were using for the class had a copyright and that we would not share that >>source<< with anyone. But when we signed that document, the CMU lawyers stated explicitly to us (and also supposedly had reminded AT&T's lawyers) that under PA law, there were two items: 1. anything we >>learned<< was ours to keep, and 2. the AT&T license could not restrict someone from working at Place X because once they saw Place Y's IP. I believe California has the same law. I do know that in Massachusetts, from being personally involved when Tom Teixeria and I left Masscomp for Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who had recently been named President of Masscomp, tried to sue. These two points held firm — Gus eventually backed off). BTW: I also know that the trade secret was the crux of the AT&T vs BSDi/UCB [not copyright infringement, like many of us thought initially]. In the end, the court was explicit: Yes, AT&T owned the IP (i.e., methods and ideas from UNIX were AT&T's IP). However, once AT&T allowed someone to see the IP (much less publish papers and books about said IP in the open), the IP could not be called a trade secret (I still have my "mentally contaminated" button that a number of us at UCB had made. And as we know, BSDi/UCB prevailed. FWIW: if AT&T had one, then all of the rewrites of UNIX's IP [starting with Idris to the then burgeoning Linux] would have fallen up that rule). So, it sounds like MIT had the sentence struck, while the lawyers at CMU and UCB took a similar stance that you cannot create a "mind eraser" and you cannot keep someone from working, just because they worked for you. From tuhs at tuhs.org Sat Sep 20 04:21:31 2025 From: tuhs at tuhs.org (Theodore Ts'o via TUHS) Date: Fri, 19 Sep 2025 14:21:31 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> Message-ID: <20250919182131.GA468508@mit.edu> On Fri, Sep 19, 2025 at 12:53:21PM -0400, Clem Cole wrote: > But the difference is that CMU's lawyers made any student who had AT&T code > sign an NDA (even for the OS course). They wanted to ensure we > understand the source code we were using for the class had a copyright and > that we would not share that >>source<< with anyone. But when we signed > that document, the CMU lawyers stated explicitly to us (and also supposedly > had reminded AT&T's lawyers) that under PA law, there were two items: > > 1. anything we >>learned<< was ours to keep, and > 2. the AT&T license could not restrict someone from working at Place X > because once they saw Place Y's IP. > > I believe California has the same law. I do know that in Massachusetts, > from being personally involved when Tom Teixeria and I left Masscomp for > Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who had > recently been named President of Masscomp, tried to sue. These two points > held firm — Gus eventually backed off). I'm not a lawyer, but I suspect IP law wasn't as settled back then. Remember, this was before courts ruled that Lotus couldn't copyright their user interface. And even if the law was "clear", the way the US court system works is that the party with the larger legal budget can often intimidate people who might not be able to afford the best justice money can buy. This is what I've learned by hanging around lawyers who disagreed about whether it was "safe" to ship CDDL-licened ZFS code ported to GPL-licensed Linux kernel. It's not just about law, but how litigious the copyright owner might be, and if the defendant is a small company, such a lawsuit might be seen as "punching down", but if the defendant was a large company, it might have very different PR angle, and PR is often at least as important whether the company prevails in a court of law (if defendant doesn't go out of business first). Even if you will eventually win, there's a reason why many people will settle patent lawsuits because even if you are sure that you are in the right, it might be cheaper to pay the Danegeld than to eventually prevail after multiple years of litigation. So I wouldn't be surprised that different legal teams coming from different universities might have come out in different places (especially if they thought they could use their Alumni mafia back channel to eventually side step the whole issue. :-) - Ted From tuhs at tuhs.org Sat Sep 20 05:57:22 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 19 Sep 2025 15:57:22 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: On Thu, Sep 18, 2025 at 3:52 PM Clem Cole wrote: > [snip] > But I'll take a stab at the communications within the CS Research Community during the 70s, which I lived in. Thanks, Clem: this is just the sort of thing I am interested in. I realize this is veering off toward COFF territory, but another couple of follow-up questions; inline. > As we all know, Unix spread quickly outside of MH to researchers, and a great deal of development took place "on the outside." Some of those ideas came back to the Research versions, but not all. But I think there was a good bit of cross-pollination within the community — even before Usenet or the Internet itself. Sometimes we would swap magnetic tapes directly, and often we would bring tapes to a conference with our work and come home with work from others. We knew each other and talked. So I sort of wonder if the Multics folks also showed up to some of those conferences: SOSP, for example. I imagine people like Fano and Corby attended. And the Unix community coalesced quickly and became quite strong (as we all know), I wonder about interaction with other communities. To be a tad pithy about it, did folks get together for coffee during the hallway track? Grab dinner or a drink in the evening? That kind of thing. > Taking MetCalfe's law into account, because there so many Unix installations (and we were all talking to each other), that style of sharing could not happen with Multics, I will posit that by 1975 most, if not nearly all, researchers in the systems world were at least familiar with Elliott Organick's 1972 book — "The Multics System: An Examination of its Structure," and many of us had read it and trying to learn lessons from it. It was a text that was referred to in my undergrad OS course, and by the time I was a grad student working in systems, it was pretty much assumed that everyone in the room had read it. > > I certainly thought Multics had some cool ideas. However, I barely touched a Multics system in those days via my limited remote access (MIT's system). And I never physically saw a Multics-capable processor until many years later. I admit that from reading Organski's book, I had some wild images of computer operators mounting mag tapes so a program could continue execution after a segment defined as not being directly addressable. So while I was familiar with Multics, I certainly "knew" a lot more about UNIX. I had it, and I was hacking its kernel. I personally did little of what we call programming on Multics, and at the same time, I was being paid to program in Unix (and some TOPS-10/TOPS-20 shop). > > I don't think I'm really unique here. If the data from website Multicians.org is correct, there were just too few Multics installations to be found (11 in 1975), and only two were at universities (MIT and the University of Louisiana). The other nine were at commercial sites. Note that in 1975, we know there were at least 5 times the number of Unix installations. Most of these sites were ones that had had some level of CS Research. By 1979, the numbers were 25 for Multics and over 600 for Unix. > > By 1979, Multics OS was stable, and the hardware to run it (the "3rd generation" H6180 had been on the market since 1973) had certainly matured from the original GE-645. So why did Multics not play a more significant role? Once again, core economics of the time played a huge part. If you use Google AI, it will tell you that a Honeywell H6180 computer system running Multics, like MIT was running in 1979, had a list price of about $7 million when it was introduced. This price included a complete system with multiple components, not just the central computer unit. Now think about a PDP 11/34, with full 256K bytes of memory, a couple of RK05 and probably an RP04 equivalent as its disk, 9-track tape, Printonix printer, and 16 serial ports using after-market DH11 — a pretty standard V7 installation, which costs approximately $100-150K. Even if you ran it on a Vax, it was not more than approximately 3 times that number. But this is a massive difference from the $7M for a Multic system. > > It's a simple Christenson disruption — the "lesser" system wins over the earlier, more "mature", and full-featured, "better" one. As a result, cross-pollination opportunities were not available. Unix/V7 and its derivatives got the attention of units because the economics favored it. Just like Linux receives today. These are really great points. It sure seems like Multics has had a huge influence, but indirectly, as it was difficult to come by for actual use. Thanks again, Clem. - Dan C. From tuhs at tuhs.org Sat Sep 20 06:30:09 2025 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Fri, 19 Sep 2025 15:30:09 -0500 Subject: [TUHS] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: References: Message-ID: [trying to broaden the discussion & transition to COFF] On 9/19/2025 2:57 PM, Dan Cross via TUHS wrote: > So I sort of wonder if the Multics folks also showed up to some of > those conferences: SOSP, for example. I imagine people like Fano and > Corby attended. And the Unix community coalesced quickly and became > quite strong (as we all know), I wonder about interaction with other > communities. Looking at the SOSP 1973 list of presentations at https://dblp.org/db/conf/sosp/sosp73.html, where Dennis & Ken presented Unix at IBM Yorktown, there's only one presentation obviously Multics related, by Saltzer, and no other presentations obviously associated with currently well known operating systems. In the (admittedly, insular) IBM environment, there seemed little interest in anything besides MVS for production and VM/370 for development. (From Popek/Goldberg SOSP 1973 Abstract: "Virtual machine systems have been implemented on a limited number of third generation computer systems, e.g. CP-67 on the IBM 360/67. From previous empirical studies, it is known that certain third generation computer systems, e.g. the DEC PDP-10, cannot support a virtual machine system.") As late as 1979 at UT-Austin, Unix was not available in the C.S. Dept -- TOPS-10 was gaining traction over the homegrown "UT-2D" environment for CDC 6400/6600 and the subsequent CDC machines that supplanted those. For various reasons, lack of commercial dominance, lack of source, ..., there didn't seem to be any specific OS that gained mind share in the O.S. community until Unix did. Well after 1985 in IBM, those of us advocating Unix were definitely in the minority. [https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/] 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 Sep 20 07:49:20 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Fri, 19 Sep 2025 17:49:20 -0400 (EDT) Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? Message-ID: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> > From: Charles H Sauer > For various reasons, lack of commercial dominance, lack of source, ..., > there didn't seem to be any specific OS that gained mind share in the > O.S. community until Unix did. Before UNIX, almost all OS's were written in assembler, tying them to one particular vendor's machines. (Multics, although in PL/I, was so specialized to the Heneywell architecture it was in the same boat.) UNIX was really the first portable OS (at least, that I know of - am I wrong?. I suspect thatwas a large factor too. Noel From tuhs at tuhs.org Sat Sep 20 07:59:36 2025 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Fri, 19 Sep 2025 16:59:36 -0500 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> Message-ID: <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> On 9/19/2025 4:49 PM, Noel Chiappa wrote: > > From: Charles H Sauer > > > For various reasons, lack of commercial dominance, lack of source, ..., > > there didn't seem to be any specific OS that gained mind share in the > > O.S. community until Unix did. > > Before UNIX, almost all OS's were written in assembler, tying them to one > particular vendor's machines. (Multics, although in PL/I, was so specialized > to the Heneywell architecture it was in the same boat.) UNIX was really the > first portable OS (at least, that I know of - am I wrong?. I suspect thatwas > a large factor too. > > Noel Emphasis on "portable," since there seemed to be so many competing processor architectures. 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 Sep 20 08:14:52 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 19 Sep 2025 16:14:52 -0600 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250919182131.GA468508@mit.edu> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: On Fri, Sep 19, 2025 at 12:21 PM Theodore Ts'o via TUHS wrote: > On Fri, Sep 19, 2025 at 12:53:21PM -0400, Clem Cole wrote: > > But the difference is that CMU's lawyers made any student who had AT&T > code > > sign an NDA (even for the OS course). They wanted to ensure we > > understand the source code we were using for the class had a copyright > and > > that we would not share that >>source<< with anyone. But when we signed > > that document, the CMU lawyers stated explicitly to us (and also > supposedly > > had reminded AT&T's lawyers) that under PA law, there were two items: > > > > 1. anything we >>learned<< was ours to keep, and > > 2. the AT&T license could not restrict someone from working at Place X > > because once they saw Place Y's IP. > > > > I believe California has the same law. I do know that in Massachusetts, > > from being personally involved when Tom Teixeria and I left Masscomp for > > Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who > had > > recently been named President of Masscomp, tried to sue. These two points > > held firm — Gus eventually backed off). > > I'm not a lawyer, but I suspect IP law wasn't as settled back then. > Remember, this was before courts ruled that Lotus couldn't copyright > their user interface. And even if the law was "clear", the way the US > court system works is that the party with the larger legal budget can > often intimidate people who might not be able to afford the best > justice money can buy. > It's worse than that. The US joined the Berne Convention in 1980, which threw a lot of monkey wrenches into things. The 1980 Copyright act changed a lot of things. Prior to that, you could not copyright software *AT*ALL*. This is why Unix was done via Trade Secret: they couldn't copyright the software. > This is what I've learned by hanging around lawyers who disagreed > about whether it was "safe" to ship CDDL-licened ZFS code ported to > GPL-licensed Linux kernel. It's not just about law, but how litigious > the copyright owner might be, and if the defendant is a small company, > such a lawsuit might be seen as "punching down", but if the defendant > was a large company, it might have very different PR angle, and PR is > often at least as important whether the company prevails in a court of > law (if defendant doesn't go out of business first). > This is true... It's all about risk. How much risk are you willing to take with an action? There's never 0 risk. And the answer often depends on the specifics. > Even if you will eventually win, there's a reason why many people will > settle patent lawsuits because even if you are sure that you are in > the right, it might be cheaper to pay the Danegeld than to eventually > prevail after multiple years of litigation. > > So I wouldn't be surprised that different legal teams coming from > different universities might have come out in different places > (especially if they thought they could use their Alumni mafia back > channel to eventually side step the whole issue. :-) > Yea. It's all about risk. How much risk is there? Do we care? How do we mitigate it? There's times you "play nice" even if you think the other side has no case because long-game strategies (like the Alumni mafia) are easier to get things resolved than an instant head-on collision. Warner