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 From tuhs at tuhs.org Sun Sep 21 06:35:32 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 20 Sep 2025 16:35:32 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: <20250920203533.04BBADCFD844@ary.qy> It appears that Dan Cross via TUHS said: >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. ... It is, but a program that has all the logic to adjust for 16th century calendar changes, not so much. (Try "cal 9 1752") My impression is that the Unix cal program was always this overimplemented so perhaps we can see whether other earlier programs did that too. R's, John From tuhs at tuhs.org Sun Sep 21 07:13:45 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 20 Sep 2025 17:13:45 -0400 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] Message-ID: below On Fri, Sep 19, 2025 at 6:15 PM Warner Losh > wrote: > 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. > Be careful, long before the Berne Convention, US companies most certainly could, and AT&T did put a copyright *i**n the UNIX source* as early as 1973's Fifth Edition. FWIW I just typed: find v[567]* -type f -print | xargs grep -i -n copyright | more v5_FifthEdition/UNIX-v5man.html:86:Copyright@: 1972, 1973, 1974

v5_FifthEdition/UNIX-v5man.html:97:Copyright © 1972, 1973, 1974

Binary file v5_FifthEdition/UNIX-v5man.pdf matches Binary file v5_FifthEdition/getsrc/unix_v5_rk.dsk matches Binary file v5_FifthEdition/getsrc/unix_v5_rk1.dsk matches Binary file v5_FifthEdition/getsrc/unix_v5_rk2.dsk matches Binary file v5_FifthEdition/unix-v5-feb-2015/unix_v5_rk.dsk matches Binary file v5_FifthEdition/unix-v5-feb-2015/unix_v5_rk1.dsk matches Binary file v5_FifthEdition/unix-v5-feb-2015/unix_v5_rk2.dsk matches v5_FifthEdition/usr/sys/conf/conf.c:2: * Copyright 1974 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/conf/low.s:1:/ Copyright 1974 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/conf/mch.s:1:/ Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/conf/mkconf.c:218: "/ Copyright 1974 Bell Telephone Laboratories Inc", v5_FifthEdition/usr/sys/conf/mkconf.c:279: " *\tCopyright 1974 Bell Telephone Laboratories Inc", v5_FifthEdition/usr/sys/dmr/bio.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/cat.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dc.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dh.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dhdm.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dhfdm.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dn.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/dp.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/kl.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/lp.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/mem.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/partab.c:2: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/pc.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/rf.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/rk.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/rp.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/tc.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/tm.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/tty.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/vs.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/dmr/vt.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/alloc.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/clock.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/fio.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/iget.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/main.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/malloc.c:3: * Copyright 1973 Bell Telephone Laboratories Inc v5_FifthEdition/usr/sys/ken/nami.c:3: * Copyright 1973 Bell Telephone Laboratories Inc :^C The real problem with copyright was that until 1983, with *Apple Computer, Inc v. Franklin Computer Corp *714 F.2d 1240. A US appellate court case ruled that binaries can also be copyrighted, not just the source code. [I recommend reading: https://internetlegal.com/impact-of-apple-vs-franklin-decision/] Until the AT&T v. BSDi/UCB case, I had never considered trade secrets related to UNIX technology. I don't remember anyone who did in those days. In fact, because of the copyright clause, Bostic had set out to rewrite any UNIX utility that might have been called a derivative work (as an example, that's why he wrote nvi -- because ex/vi had started out as an extension to ed). But then the lawsuit came about, a large number of us were worried about copyright, — which is why so many of us switched from *BSD to Linux, even though Linux was still a relatively new and unproven platform at the time (e.g., not much more than the toy OS you might have seen in OS class). Remember, the Franklin case is how the idea of the "clean room" was created. The problem *BSD had was that while a lot of code was written from scratch, it was hardly done using the formal clean room approach. Most people writing those new utilities certainly had seen the AT&T code. Many of us knew that, at places like the USENIX conference, we talked about in the hallways. If AT&T won, we would be able to fall back to Linux, so let's make it better. FWIW: when Coherent came on the scene, Dennis was part of the team that was asked to examine their code. The conclusion was that it was not a direct "rip off" of the BTL code, but certainly the people who wrote it were familiar with it. For whatever reason, at the time. AT&T's legal team backed down, and Coherent stayed on the market. That said, in the BSDi case, the hacker community got it wrong. AT&T went after BSDi/UCB under the trade secret claim, not copyright infringement. And, interestingly, the court did find *that AT&T owned the intellectual property* — i.e., >>the core ideas<< which made UNIX so powerful and unique. However, the moment the ACM paper was published, in July 1974, or Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade secret. > From tuhs at tuhs.org Sun Sep 21 09:02:24 2025 From: tuhs at tuhs.org (John P. Linderman via TUHS) Date: Sat, 20 Sep 2025 19:02:24 -0400 Subject: [TUHS] Fwd: Question In-Reply-To: References: Message-ID: Just got the following from Dick Haight, original author of the bs language. He's looking for the C source. If you know where to find it, respond to Dick. He might enjoy this Society. He's been around for a very long time. -- jpl ---------- Forwarded message --------- From: Dick Haight Date: Sat, Sep 20, 2025 at 5:09 PM Subject: Question To: John P. Linderman Hi. Still here. I recently reconnected with Vicki Rosenthal via linkedin. Fun. On YouTube a while back I commented with DrDave who had done a video about my forgotten language bs. It was distributed with AT&T system 3 and 5 but not with research dists. I’d kind of like to play around with bs again. Any ideas where C source might be found? D.H. From tuhs at tuhs.org Sun Sep 21 09:46:52 2025 From: tuhs at tuhs.org (Jeff Johnson via TUHS) Date: Sat, 20 Sep 2025 19:46:52 -0400 Subject: [TUHS] Fwd: Question In-Reply-To: References: Message-ID: <08c8c07c-40df-428e-bebe-a7947c67d5cf@app.fastmail.com> Current AIX (AIX 7.2 and 7.3) still ship /usr/bin/bs (and /usr/bin/sno also) and include man pages. I have several versions of bs - mostly from various System V (from SysVr2/NS32K, SysV/68k, and INTERACTIVE UNIX) trees from the 80s and 90s, and an IBM version from 1994. Look here for a representative earlier version from SunOS 3.4: https://github.com/calmsacibis995/sunos-34-src/tree/master/usr.bin/bs.gone Proper licensing is of course up to you. -- Jeffrey H. Johnson trnsz at pobox.com From tuhs at tuhs.org Sun Sep 21 10:37:49 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 21 Sep 2025 10:37:49 +1000 Subject: [TUHS] Fwd: Question In-Reply-To: References: Message-ID: On Sat, Sep 20, 2025 at 07:02:24PM -0400, John P. Linderman via TUHS wrote: > Just got the following from Dick Haight, original author of the bs > language. He's looking for the C source. If you know where to find it, > respond to Dick. He might enjoy this Society. He's been around for a very > long time. -- jpl Here :-) https://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/bs/bs.c https://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/bs/bs.c Cheers, Warren From tuhs at tuhs.org Sun Sep 21 11:06:04 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 20 Sep 2025 21:06:04 -0400 Subject: [TUHS] copyright, was History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: <20250921010604.B5EB1DD04AE9@ary.qy> It appears that Warner Losh via TUHS said: >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*. I'm sorry, but that gets the history wrong. The last major update to US copyright law was in 1976, with a minor update in 1980. We didn't join Berne until much later in 1989. While Berne affected a lot of aspects of copyright, like whether works need a notice (not any more) or how long it lasts (too long) it had no effect on software. You are correct in that until the mid 1960s everyone assumed that software was not eligible for copyright under the 1879 Baker vs. Selden decision that accounting forms weren't eligible since they were just instructions about how to do something. John Banzhaf registered the first software copyrights in 1964, to test that assumption. For a while it was unclear whether they were enforcable. In 1974 Congress set up CONTU to study copyright issues, which were mostly implemented in the 1976. There were a few left-overs addressed in 1980 which added computer software to the list of things explicitly allowed, although by then everyone had assumed it was implicitly included. So anyway, if AT&T had wanted to use copyright to protect Unix in the 1970s they could have. I expect they chose trade secret because copyright lawsuits are incredibly expensive and trade secret is a lot easier to enforce, at least if the secrets haven't leaked. R's, John From tuhs at tuhs.org Sun Sep 21 11:11:04 2025 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sun, 21 Sep 2025 11:11:04 +1000 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: References: Message-ID: > On 21 Sep 2025, at 07:13, Clem Cole via TUHS wrote: > > However, the moment the ACM paper was published, in July 1974, or > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > secret. For those like me that missed this textbook: Full text on Internet Archive, 485 pp Q: Bach in his Preface (p10) notes the book is based on an internal Bell Labs course he gave, including exercises. He also notes the two special issues of BSTJ 1978/1984 on UNIX. Did he have to get clearance to write / publish the book from Bell Labs management: I don’t know their policies. Is that correct? Which seems like a deliberate corporate act to publish the UNIX ’trade secrets’. This is ancient history and irrelevant now - the legal fights are over :) Not trying to prosecute what’s past, seeking clarity. -- From tuhs at tuhs.org Sun Sep 21 11:12:53 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 20 Sep 2025 21:12:53 -0400 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> Message-ID: <20250921011253.BA763DD04BD2@ary.qy> It appears that Charles H Sauer (he/him) via TUHS said: >> Before UNIX, almost all OS's were written in assembler, ... > >Emphasis on "portable," since there seemed to be so many competing >processor architectures. Charlie Yup. Until the late 1960s computers had such widely different addressing and data architectures that it wouldn't have made sense to try to write portable system software. FORTRAN and COBOL programs could be fairly portable, but at a much higher level of abstraction than an operating system. But S/360 became the de facto standord for mainframes, and a few years later the PDP-11 was successful enough as a mini that the only data format that mattered was twos-complement binary, and the only addressing was 8 bit bytes. That made portability a lot easier. The only attempt I know to put Unix on a machine that didn't have 8-bit bytes was the BBN C70 with 10-bit bytes. One of the programmers told me that finding all the 8-bit assumptions in Unix applications was very painful. R's, John From tuhs at tuhs.org Sun Sep 21 11:20:46 2025 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sun, 21 Sep 2025 11:20:46 +1000 Subject: [TUHS] copyright, was History of cal(1)? In-Reply-To: <20250921010604.B5EB1DD04AE9@ary.qy> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250921010604.B5EB1DD04AE9@ary.qy> Message-ID: > On 21 Sep 2025, at 11:06, John Levine via TUHS wrote: > > So anyway, if AT&T had wanted to use copyright to protect Unix in the 1970s they > could have. I expect they chose trade secret because copyright lawsuits are > incredibly expensive and trade secret is a lot easier to enforce, at least if > the secrets haven't leaked. > > R's, > John For those playing along at home, this is a good history. The AT&T legal department may not have wanted to ‘deposit’ the source code. Chapter 2: Copyright of Computer Programs According to the Copyright Office, the first deposit of a computer program for registration was on November 30, 1961. North American Aviation submitted a tape containing a computer program. While the Copyright Office was trying to determine whether such a deposit could be registered, two short computer programs were submitted by a Columbia University law student to determine how a computer program might be registered. One computer program was submitted as a printout published in the Columbia Law School News on April 20, 1964, while the other was on magnetic tape. The copyrights for both student computer programs were registered in May 1964, and North American Aviation’s computer program was registered in June 1964. [Author's note: It's been brought to my attention that there were at least three computer programs registered before the ones mentioned above. The first of those was a FORTRAN program entitled "Gaze-2, A One-Dimensional, Multigroup, Neutron Diffusion Theory Code for the IBM-7090," written by the General Atomic Division of General Dynamics, registered on February 1, 1963 (registration number A607663). In early 1964, General Dynamics registered two other computer programs (A677198 and A678350).] Surprisingly, the Copyright Office did not seem to think that the Supreme Court’s White-Smith v. Apollo decision prevented the copyrighting of computer programs. It believed that punched cards, a primary medium for computer programs at the time, could be read by somebody familiar with the code used to represent characters on the cards, or could be printed to get a computer program listing intelligible to a person. Magnetic tapes, presumably, were just like a whole bunch of punch cards on a more convenient medium. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From tuhs at tuhs.org Sun Sep 21 11:26:29 2025 From: tuhs at tuhs.org (babydr DBA James W. Laferriere via TUHS) Date: Sat, 20 Sep 2025 17:26:29 -0800 (AKDT) Subject: [TUHS] Lost software from 1989 - 1990 era . Message-ID: <2f145510-4f59-9153-9281-67a54317238c@baby-dragons.com> Hello All , Is there anyone who may have the original tapes or the actual tape contents Copied (Ie: The RAW contents pulled off) to disk , Of either of the tapes below ? As a long shot ... DEC US NO: VSOlll TITLE: Symposium Collection from the RSX SIG, Fall 1989, Anaheim Version: 1, January 1990 The # above maybe VS0111 . DECUS No. Title Status Version VS0110 PRO Public Domain Tape Is now available 1.0, September 1989 Either of them may give me an idea what happened to pro-121 (or pro121) . Which it was supposedly entered into . And YES I've dug thru all that I can find of the Dec-PROfessional sites that have open webpages . I've gone thru the Symposia Library in NOTES on eisner.decus.org ... The above tapes are the only entries that showed that rx50 image as being on the tapes . Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From tuhs at tuhs.org Sun Sep 21 11:39:21 2025 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 20 Sep 2025 21:39:21 -0400 Subject: [TUHS] copyright, was History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250921010604.B5EB1DD04AE9@ary.qy> Message-ID: <4e0b9cfb-7f7e-b38e-e087-407b582e8642@taugh.com> On Sun, 21 Sep 2025, sjenkin at canb.auug.org.au wrote: >> On 21 Sep 2025, at 11:06, John Levine via TUHS wrote: >> >> So anyway, if AT&T had wanted to use copyright to protect Unix in the 1970s they >> could have. I expect they chose trade secret because copyright lawsuits are >> incredibly expensive and trade secret is a lot easier to enforce, at least if >> the secrets haven't leaked. >> >> R's, >> John > > For those playing along at home, this is a good history. > > The AT&T legal department may not have wanted to ‘deposit’ the source code. > > Chapter 2: Copyright of Computer Programs > > > According to the Copyright Office, the first deposit of a computer program for registration was on November 30, 1961. > North American Aviation submitted a tape containing a computer program. > While the Copyright Office was trying to determine whether such a deposit could be registered, > two short computer programs were submitted by a Columbia University law student to determine how a computer program might be registered. Right, that was Banzhaf. He wrote this article "When a Computer Needs a Lawyer" which discusses copyright in the last two pages, with footnotes about those programs. https://insight.dickinsonlaw.psu.edu/dlra/vol71/iss2/6/ Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Sun Sep 21 12:28:28 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Sat, 20 Sep 2025 20:28:28 -0600 Subject: [TUHS] copyright, was History of cal(1)? In-Reply-To: <20250921010604.B5EB1DD04AE9@ary.qy> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250921010604.B5EB1DD04AE9@ary.qy> Message-ID: On Sat, Sep 20, 2025 at 7:06 PM John Levine wrote: > It appears that Warner Losh via TUHS said: > >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*. > > I'm sorry, but that gets the history wrong. > Thanks for the update. I was confusing different dates... > The last major update to US copyright law was in 1976, with a minor update > in > 1980. We didn't join Berne until much later in 1989. While Berne affected > a lot > of aspects of copyright, like whether works need a notice (not any more) > or how > long it lasts (too long) it had no effect on software. > Yea, the notice part is why AT&T likely lost copyright to V32 that Berkeley based 3BSD on... I was confusing that with not being able to have it at all... But without it, the AT&T IP protection fell back to Trade Secret which was in doubt due to the 1974 CACM article. > You are correct in that until the mid 1960s everyone assumed that software > was > not eligible for copyright under the 1879 Baker vs. Selden decision that > accounting forms weren't eligible since they were just instructions about > how to > do something. John Banzhaf registered the first software copyrights in > 1964, to > test that assumption. For a while it was unclear whether they were > enforcable. > > In 1974 Congress set up CONTU to study copyright issues, which were mostly > implemented in the 1976. There were a few left-overs addressed in 1980 > which > added computer software to the list of things explicitly allowed, although > by then everyone had assumed it was implicitly included. > Yea. That's some of the history that I Iived through. My first job in 1976 was definitely operating under the assumption that copyright couldn't happen. > So anyway, if AT&T had wanted to use copyright to protect Unix in the > 1970s they > could have. I expect they chose trade secret because copyright lawsuits > are > incredibly expensive and trade secret is a lot easier to enforce, at least > if > the secrets haven't leaked. > Here history is kinda complex. They sometimes had copyright notices included, and removed sometimes due to the 'no support at all' nature of the licenses (Clem can fill in the details). It was this sloppiness that led to the v.32 tapes going out w/o copyrights... > R's, > John > > > From tuhs at tuhs.org Sun Sep 21 15:25:27 2025 From: tuhs at tuhs.org (Niklas Karlsson via TUHS) Date: Sun, 21 Sep 2025 07:25:27 +0200 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <20250921011253.BA763DD04BD2@ary.qy> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> Message-ID: Den sön 21 sep. 2025 kl 03:13 skrev John Levine via TUHS : > That made portability a lot easier. The only attempt I know to put Unix > on a machine > that didn't have 8-bit bytes was the BBN C70 with 10-bit bytes. One of > the programmers > told me that finding all the 8-bit assumptions in Unix applications was > very painful. > I had been under the impression that there was a NetBSD port to the PDP-10, but apparently it has only been proposed. Niklas From tuhs at tuhs.org Sun Sep 21 17:52:53 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 21 Sep 2025 01:52:53 -0600 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: References: Message-ID: <202509210752.58L7qrpg051925@freefriends.org> Bach used to work at Intel in Haifa. If he hasn't retired yet, moshe.bach at intel.com should get to him, if you wish to ask. A few years back when I was also working at Intel, I got him to autograph my copy. :-) FWIW, Arnold steve jenkin via TUHS wrote: > > > > On 21 Sep 2025, at 07:13, Clem Cole via TUHS wrote: > > > > However, the moment the ACM paper was published, in July 1974, or > > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > > secret. > > For those like me that missed this textbook: > > Full text on Internet Archive, 485 pp > > > Q: > Bach in his Preface (p10) notes the book is based on an internal > Bell Labs course he gave, including exercises. > > He also notes the two special issues of BSTJ 1978/1984 on UNIX. > > Did he have to get clearance to write / publish the book > from Bell Labs management: I don’t know their policies. > > Is that correct? > > Which seems like a deliberate corporate act to publish > the UNIX ’trade secrets’. > > This is ancient history and irrelevant now > - the legal fights are over :) > > Not trying to prosecute what’s past, > seeking clarity. > > -- From tuhs at tuhs.org Sun Sep 21 22:45:00 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Sun, 21 Sep 2025 08:45:00 -0400 Subject: [TUHS] copyright, was History of cal(1) ? Message-ID: Prior to Unix, Calvin Mooers had spooked AT&T about software copyrights. Mooers obtained the copyright for a 1966 CACM article about his TRAC language and sued Western Electric, claiming that Claude Kagan's implementation of TRAC based on the article infringed the copyright. A Mooers win would have opened a Pandora's box, allowing languages to be copyrighted and, more generally, turning the technical literature into an arsenal for litigators. Although AT&T was confident of winning in court, the prospect of a loss, no matter how unlikely, was so appalling that they settled. The only publicly visible outcome was that Kagan changed the name of his implementation to Sam67. Doug From tuhs at tuhs.org Mon Sep 22 07:14:38 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 21 Sep 2025 17:14:38 -0400 Subject: [TUHS] copyright, was History of cal(1) ? In-Reply-To: References: Message-ID: <20250921211439.1E603DD2499E@ary.qy> Hi, old R.E.S.I.S.T.O.R.S. member here. It appears that Douglas McIlroy via TUHS said: >Prior to Unix, Calvin Mooers had spooked AT&T about software >copyrights. Mooers obtained the copyright for a 1966 CACM article >about his TRAC language and sued Western Electric, claiming that >Claude Kagan's implementation of TRAC based on the article infringed >the copyright. ... >so appalling that they settled. The only publicly visible outcome was >that Kagan changed the name of his implementation to Sam67. No surprise about the name change since Cal had a trademark on the name TRAC. Beyond that, Claude also changed the syntax a little so it looked more like Strachey's GPM and less like Trac. Trac was unlike other macrogenerators in that it cleanly separated I/O from macro expansion, and Sam76 still did it like Trac did, but that would have been a patent issue and this was before software patents. The whole episode was extremely strange. Cal had known Claude and the RESISTORS for years. Peter Eichenberger and I wrote our own Trac processors for the PDP-10 and PDP-11, independent of Claude's PDP-8 version. Cal had known about all of this before he sued. I cannot tell whether he wanted money or credit or what, but we had no hint that he was planning to sue or objected to anything we were doing. He never said anything to Peter or me. Later in the 1980s I lived around the corner from Cal in Harvard Square but unfortunately never got around to reintroducing myself. R's, John From tuhs at tuhs.org Mon Sep 22 07:32:01 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Sun, 21 Sep 2025 14:32:01 -0700 Subject: [TUHS] copyright, was History of cal(1) ? In-Reply-To: <20250921211439.1E603DD2499E@ary.qy> References: <20250921211439.1E603DD2499E@ary.qy> Message-ID: I am intrigued by the meaning of the name Resistors … On Sun, Sep 21, 2025 at 14:24 John Levine via TUHS wrote: > Hi, old R.E.S.I.S.T.O.R.S. member here. > > It appears that Douglas McIlroy via TUHS > said: > >Prior to Unix, Calvin Mooers had spooked AT&T about software > >copyrights. Mooers obtained the copyright for a 1966 CACM article > >about his TRAC language and sued Western Electric, claiming that > >Claude Kagan's implementation of TRAC based on the article infringed > >the copyright. ... > > >so appalling that they settled. The only publicly visible outcome was > >that Kagan changed the name of his implementation to Sam67. > > No surprise about the name change since Cal had a trademark on the name > TRAC. > Beyond that, Claude also changed the syntax a little so it looked more like > Strachey's GPM and less like Trac. Trac was unlike other macrogenerators > in that > it cleanly separated I/O from macro expansion, and Sam76 still did it like > Trac > did, but that would have been a patent issue and this was before software > patents. > > The whole episode was extremely strange. Cal had known Claude and the > RESISTORS > for years. Peter Eichenberger and I wrote our own Trac processors for the > PDP-10 > and PDP-11, independent of Claude's PDP-8 version. Cal had known about all > of > this before he sued. I cannot tell whether he wanted money or credit or > what, > but we had no hint that he was planning to sue or objected to anything we > were > doing. He never said anything to Peter or me. > > Later in the 1980s I lived around the corner from Cal in Harvard Square > but unfortunately never got around to reintroducing myself. > > R's, > John > From tuhs at tuhs.org Mon Sep 22 07:35:29 2025 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 21 Sep 2025 17:35:29 -0400 Subject: [TUHS] copyright, was History of cal(1) ? In-Reply-To: References: <20250921211439.1E603DD2499E@ary.qy> Message-ID: On Sun, 21 Sep 2025, ron minnich wrote: > I am intrigued by the meaning of the name Resistors … Keeping in mind it was the 1960s, it was nominally "Radically Emphatic Students Interested in Science, Technology, and Other Research Studies" but we were teen-agers and it was, you know, the 1960s. We have a web site with some historical stuff here: https://www.resistors.org/ R's, John > On Sun, Sep 21, 2025 at 14:24 John Levine via TUHS wrote: > >> Hi, old R.E.S.I.S.T.O.R.S. member here. >> >> It appears that Douglas McIlroy via TUHS >> said: >>> Prior to Unix, Calvin Mooers had spooked AT&T about software >>> copyrights. Mooers obtained the copyright for a 1966 CACM article >>> about his TRAC language and sued Western Electric, claiming that >>> Claude Kagan's implementation of TRAC based on the article infringed >>> the copyright. ... >> >>> so appalling that they settled. The only publicly visible outcome was >>> that Kagan changed the name of his implementation to Sam67. >> >> No surprise about the name change since Cal had a trademark on the name >> TRAC. >> Beyond that, Claude also changed the syntax a little so it looked more like >> Strachey's GPM and less like Trac. Trac was unlike other macrogenerators >> in that >> it cleanly separated I/O from macro expansion, and Sam76 still did it like >> Trac >> did, but that would have been a patent issue and this was before software >> patents. >> >> The whole episode was extremely strange. Cal had known Claude and the >> RESISTORS >> for years. Peter Eichenberger and I wrote our own Trac processors for the >> PDP-10 >> and PDP-11, independent of Claude's PDP-8 version. Cal had known about all >> of >> this before he sued. I cannot tell whether he wanted money or credit or >> what, >> but we had no hint that he was planning to sue or objected to anything we >> were >> doing. He never said anything to Peter or me. >> >> Later in the 1980s I lived around the corner from Cal in Harvard Square >> but unfortunately never got around to reintroducing myself. >> >> R's, >> John >> > Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Mon Sep 22 07:45:31 2025 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Sun, 21 Sep 2025 14:45:31 -0700 Subject: [TUHS] copyright, was History of cal(1) ? In-Reply-To: References: <20250921211439.1E603DD2499E@ary.qy> Message-ID: <3d08983f-cba8-653e-60b7-c3ca951e0c34@bitsavers.org> On 9/21/25 2:32 PM, ron minnich via TUHS wrote: > I am intrigued by the meaning of the name Resistors … > > On Sun, Sep 21, 2025 at 14:24 John Levine via TUHS wrote: > >> Hi, old R.E.S.I.S.T.O.R.S. member here. Claude's computer club. Much of the barn's contents were lost in a fire, including his B205 From tuhs at tuhs.org Mon Sep 22 07:46:03 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Mon, 22 Sep 2025 07:46:03 +1000 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: References: Message-ID: I barely knew what any official Bell Labs policy was, it was all pretty informal and you just asked for permission when it seemed the right thing to do. But there was a story that someone, probably a physicist, wanted to write a book and management said it was OK but they would take the royalties. This caused two changes: the physicist left and wrote the book, and management decided it was OK to write a book and keep the royalties provided you asked first and got permission, which presumably depended somewhat on performance and indirectly on the potential value of the publication for PR. -rob On Sun, Sep 21, 2025 at 11:11 AM steve jenkin via TUHS wrote: > > > > On 21 Sep 2025, at 07:13, Clem Cole via TUHS wrote: > > > > However, the moment the ACM paper was published, in July 1974, or > > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > > secret. > > For those like me that missed this textbook: > > Full text on Internet Archive, 485 pp > > > Q: > Bach in his Preface (p10) notes the book is based on an internal > Bell Labs course he gave, including exercises. > > He also notes the two special issues of BSTJ 1978/1984 on UNIX. > > Did he have to get clearance to write / publish the book > from Bell Labs management: I don’t know their policies. > > Is that correct? > > Which seems like a deliberate corporate act to publish > the UNIX ’trade secrets’. > > This is ancient history and irrelevant now > - the legal fights are over :) > > Not trying to prosecute what’s past, > seeking clarity. > > -- > From tuhs at tuhs.org Mon Sep 22 10:27:46 2025 From: tuhs at tuhs.org (Theodore Ts'o via TUHS) Date: Sun, 21 Sep 2025 20:27:46 -0400 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: References: Message-ID: <20250922002746.GB481137@mit.edu> On Sat, Sep 20, 2025 at 05:13:45PM -0400, Clem Cole wrote: > That said, in the BSDi case, the hacker community got it wrong. AT&T went > after BSDi/UCB under the trade secret claim, not copyright infringement. > And, interestingly, the court did find *that AT&T owned the intellectual > property* — i.e., >>the core ideas<< which made UNIX so powerful and > unique. However, the moment the ACM paper was published, in July 1974, or > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > secret. So inquiring minds want to know. When was the first date that Unix was distributed outside of Bell Labs, and when was the first license which included the assertion that it was a trade secret? According to Wikipedia ("which is never wrong"), In 1975, the first source license for UNIX was sold to Donald B. Gillies at the University of Illinois Urbana–Champaign (UIUC) Department of Computer Science.[27] Note that 1975 is *after* the publication of the CACM paper. There are hints that the Unix source code was shared before the first license, which makes it even worse. With copyright, without a license, you can't give it to anyone else, and you probably only use it because the person who gave it to you (if they had the authority to do so) could be construed to have given you an implied license to use it. But with a Trade Secret, it can only be protected if whenever you share it with someone outside of your organization, they must have signed an NDA, and the protection of the trade secret is if that person makes an unauthorized disclosure, (a) it's no longer protected, and (b) you can sue that person into oblivion. But once it's been disclosed (say, Rich Salz uploads it to Usenet from a public phone), if you can prove that it was Rich who did the dirty deed, you could sue and take away all of his assets, but the trade secret is gone at that point. (After 2016, the Defend Trade Secrets Act does allow courts to order ex-parte seizure of property to preven the dissemination of a trade secret, but it's only under very restrictive situations, and it seems to be mostly involve the situation where Alice has signed an NDA promising to Bob that she won't some trade secret information, but then Alice gives some physical object, such as a hard drive, containing that information to Charlie. In that case, Bob can ask the court for an ex-parte seizure, if (a) Bob can describe with reasonable particularity what is to be seized and where it located, (b) not publicize the requested seizure, and (c) provide security for any damages the third party might suffer if the court later determins that the seizure was wrongfully granted. So that's quite narrow, and if the trade secret is located on thousands of Usenet servers all over the world, the court is not likely going to give an order to Federal Marshals to seize the hard drives from all of the Usenet servers in order to prevent trade secret from being disseminated. :-) The bottom line is that if Bell Labs had *ever* distributed the information to third parties without an NDA before trying to claim that the methods and concepts of Unix were a "trade secret", it simply was neer going to fly. And to the extent that Bell Labs had distributed Unix source code to MIT without the trade secret clause, it was also doomed --- which is probably why AT&T wasn't willing to tell third parties like say, Digital, that MIT had a valid Unix license, since acknowledging that MIT had a valid license would have given away the game once it became clear that it didn't have the trade secrets clause. And if students at MIT weren't required to sign an NDA, any communications they had about how Unix worked would have invalidate any of those concepts as being under the trade secret. The bottom line is that trying to use Trade Secre was unbelievably stupid, and suggests that either (a) Bell Labs and AT&T Lawyers were incompetent, or (b) they weren't aware of prior dissemination of the information that they were trying to claim were trade secret. I suspect (b) is much more likely. Perhaps they never read the Unix CACM paper. :-) It's also not surprising that hacker community got it wrong, because it was such an insane and stupid legal tactic! - Ted From tuhs at tuhs.org Mon Sep 22 11:05:31 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 22 Sep 2025 11:05:31 +1000 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: <20250922002746.GB481137@mit.edu> References: <20250922002746.GB481137@mit.edu> Message-ID: On Sun, Sep 21, 2025 at 08:27:46PM -0400, Theodore Ts'o via TUHS wrote: > On Sat, Sep 20, 2025 at 05:13:45PM -0400, Clem Cole wrote: > > That said, in the BSDi case, the hacker community got it wrong. AT&T went > > after BSDi/UCB under the trade secret claim, not copyright infringement. > > And, interestingly, the court did find *that AT&T owned the intellectual > > property* — i.e., >>the core ideas<< which made UNIX so powerful and > > unique. However, the moment the ACM paper was published, in July 1974, or > > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > > secret. > > So inquiring minds want to know. When was the first date that Unix > was distributed outside of Bell Labs, and when was the first license > which included the assertion that it was a trade secret? > > According to Wikipedia ("which is never wrong"), > > In 1975, the first source license for UNIX was sold to Donald > B. Gillies at the University of Illinois Urbana–Champaign (UIUC) > Department of Computer Science.[27] "The first educational licence was granted, in October 1973, to Columbia University ... The Children's Museum in Boston was the first non educational recipient of UNIX in October 1973" Pirzada's thesis, p 47 "In January 1974, a Version 4 tape was delivered and Unix was installed by graduate student Keith Standiford." McKusick - Twenty Years of Berkeley Unix https://www.oreilly.com/openbook/opensources/book/kirkmck.html From tuhs at tuhs.org Mon Sep 22 11:14:52 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 22 Sep 2025 01:14:52 -0000 Subject: [TUHS] Trac, RESISTORS, copyright, ... In-Reply-To: <20250921211439.1E603DD2499E@ary.qy> <3d08983f-cba8-653e-60b7-c3ca951e0c34@bitsavers.org> References: <20250921211439.1E603DD2499E@ary.qy> <3d08983f-cba8-653e-60b7-c3ca951e0c34@bitsavers.org> Message-ID: <10aq7uc$1r6c$1@gal.iecc.com> According to Al Kossow via TUHS : >On 9/21/25 2:32 PM, ron minnich via TUHS wrote: >> I am intrigued by the meaning of the name Resistors … >> >> On Sun, Sep 21, 2025 at 14:24 John Levine via TUHS wrote: >> >>> Hi, old R.E.S.I.S.T.O.R.S. member here. > >Claude's computer club. He was the advisor, but the club ran itself. After I went off to college they and Claude had a falling out and the club moved to the Princeton campus, with the new advisor being my father. >Much of the barn's contents were lost in a fire, including his B205 It was all lost, burned to the ground. Fortunately a few of the items, notably the PDP-8 that DEC gave us, had been given away. There were a bunch of old manuals that I took when I left, some of which I sent you to scan for bitsavers. The PDP-8 is now at the InfoAge Museum in Wall NJ, and has been restored by volunteers so it works again. Here's a video of the very PDP-8 on which I learned to program: https://youtu.be/S2r_GujSc6w?si=d7V3Ncv850f_wCFz R's, John -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Mon Sep 22 11:54:20 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 22 Sep 2025 11:54:20 +1000 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: References: <20250922002746.GB481137@mit.edu> Message-ID: On Mon, Sep 22, 2025 at 11:05:31AM +1000, Jonathan Gray via TUHS wrote: > On Sun, Sep 21, 2025 at 08:27:46PM -0400, Theodore Ts'o via TUHS wrote: > > On Sat, Sep 20, 2025 at 05:13:45PM -0400, Clem Cole wrote: > > > That said, in the BSDi case, the hacker community got it wrong. AT&T went > > > after BSDi/UCB under the trade secret claim, not copyright infringement. > > > And, interestingly, the court did find *that AT&T owned the intellectual > > > property* — i.e., >>the core ideas<< which made UNIX so powerful and > > > unique. However, the moment the ACM paper was published, in July 1974, or > > > Bach's 1986 book came out, AT&T could no longer call the UNIX IP a trade > > > secret. > > > > So inquiring minds want to know. When was the first date that Unix > > was distributed outside of Bell Labs, and when was the first license > > which included the assertion that it was a trade secret? > > > > According to Wikipedia ("which is never wrong"), > > > > In 1975, the first source license for UNIX was sold to Donald > > B. Gillies at the University of Illinois Urbana–Champaign (UIUC) > > Department of Computer Science.[27] > > "The first educational licence was granted, in October 1973, to > Columbia University > ... > The Children's Museum in Boston was the first non educational recipient > of UNIX in October 1973" > Pirzada's thesis, p 47 > > "In January 1974, a Version 4 tape was delivered and Unix was installed > by graduate student Keith Standiford." > McKusick - Twenty Years of Berkeley Unix > https://www.oreilly.com/openbook/opensources/book/kirkmck.html Pirzada's use of 'license' may be wrong here. "Several universities contacted Bell Labs and received copies of the Fourth Edition. Agreements were signed not to disclose the source code, but no licenses were in use at this point." Don Libes & Sandy Ressler - Life with Unix, p 7 From tuhs at tuhs.org Mon Sep 22 11:54:45 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 21 Sep 2025 21:54:45 -0400 Subject: [TUHS] Trade Secrets and Copyrights [was History of cal(1)] In-Reply-To: <20250922002746.GB481137@mit.edu> References: <20250922002746.GB481137@mit.edu> Message-ID: On Sun, Sep 21, 2025 at 8:27 PM Theodore Ts'o wrote: > So inquiring minds want to know. When was the first date that Unix > was distributed outside of Bell Labs, and when was the first license > which included the assertion that it was a trade secret? > Columbia had the first. Lou Katz was >>external<< user 1 of Fourth Edition [Doug wins the awards for internal use]. I'd have to ask Lou what the date was, but I have always thought it was soon after Oct'73 SOSP (which redated the July CACM paper). > > According to Wikipedia ("which is never wrong"), > > In 1975, the first source license for UNIX was sold to Donald > B. Gillies at the University of Illinois Urbana–Champaign (UIUC) > Department of Computer Science.[27] > Interesting use of the words "sold" -- I wonder why . I had thought the first commercial license was for Rand. > > Note that 1975 is *after* the publication of the CACM paper. > > There are hints that the Unix source code was shared before the first > license, which makes it even worse. > That is the first time I have ever heard that. Do you have a source? > > But with a Trade Secret, it can only be protected if whenever you > share it with someone outside of your organization, they must have > signed an NDA, and the protection of the trade secret is if that > person makes an unauthorized disclosure, (a) it's no longer protected, > and (b) you can sue that person into oblivion. I agree that your description of using an NDA is the legal interpretation/practice. But I do wonder if it was the same way in the 70s. Remember also that AT&T is working under the 1956 consent decree that requires, in return for having a monopoly on the phone business, the corporation to "make its IP available to interested parties under reasonable licensing terms." The transistor is, of course, the best example of that — and AT&T/WE hardly made the kind of money that RCA, GE, TI, *et al *made creating transistors. > .... > The bottom line is that if Bell Labs had *ever* distributed the > information to third parties without an NDA before trying to claim > that the methods and concepts of Unix were a "trade secret", it simply > was neer going to fly. Well, I agree that trying to call it a trade secret after so many of us had been taught the techniques in school seems silly. And I never understood how that claim could be made. But I'm not sure that an NDA was required when they started. >>As I understand it<< the use of an NDAs really started to become more the norm only in the late 1970s. As I mentioned, we were warned about the AT&T copyright and its license, which is why the CMU lawyers had us sign the sublicense if we took the OS course. But there was never anything associated with a NDA. I did not even become familar with the term until a few years after I graduated. > And to the extent that Bell Labs had > distributed Unix source code to MIT without the trade secret clause, > it was also doomed --- which is probably why AT&T wasn't willing to > tell third parties like say, Digital, that MIT had a valid Unix > license, Al Arms and the folks at AT&T patent and licensing would not verify anyone having a license. That was not an MIT-specific thing. This is why we all sent a copy of the signature page for the license to another site before they would send you the code. The original "UNIX User Group" and Mel and Lou set up (which became USENIX) was invitation-only. That's why Ken put Mel's address in the V6 kit and told you to contact Mel. To be invited, you had to send Mel a copy of your signature page. > > The bottom line is that trying to use Trade Secre was unbelievably > stupid, and suggests that either (a) Bell Labs and AT&T Lawyers were > incompetent, or (b) they weren't aware of prior dissemination of the > information that they were trying to claim were trade secret. I > suspect (b) is much more likely. Perhaps they never read the Unix > CACM paper. :-) > Well, that's stronger than I would state. The AT&T legal team was aware of the disclosures and had been required to license and disclose them via the 1956 consent decree. As was explained to me, that was the basis of their claim. It was there IP. They owned it (and still did), but at the time, the law required them to share it, which was a bit of a catch-22 for them. Thus, the open question became "could they still call the IP a trade secret after having shared it?" The court said no. Anything they invented after Judge Green did not have to be shared, but before then, which UNIX certainly was. So, the interesting question is between the time of the 1956 decree and Judge Green: could AT&T realistically have had any trade secrets if it were required to license its IP? > It's also not surprising that hacker community got it wrong, because > it was such an insane and stupid legal tactic! > Again, as I said, we have spent all of the time being concerned about protecting AT&T's license and the copyright to their example implementation of that IP. From tuhs at tuhs.org Mon Sep 22 13:03:15 2025 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Sun, 21 Sep 2025 22:03:15 -0500 Subject: [TUHS] forth on early unix Message-ID: I'm doing forth exploring and am curious if there were forthen (is that even a word?) on early versions of unix that folks remember using? Will From tuhs at tuhs.org Mon Sep 22 13:17:11 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Sun, 21 Sep 2025 20:17:11 -0700 Subject: [TUHS] forth on early unix In-Reply-To: References: Message-ID: <20250922031711.GB31455@mcvoy.com> Bruce Karsh made me write a lot of forth on a Masscomp. Messed with me, he was good at that, I wrote more(1) in forth and he kept coming back with "can it go backwords?" "Can you search?" etc. I made a pretty good more clone in forth because of Bruce. And if you don't know him, I was on a zoom memorial for him and there were two Turing Award winners on that zoom. Bruce was somebody. I felt like I did not deserve to be there. I'm still not a forth fan. That said, the sun boot proms were in forth and there was some pretty cool forth in there. It knew the VM structures, it knew sockets, it knew a lot. I'm still not a forth fan but it was useful. On Sun, Sep 21, 2025 at 10:03:15PM -0500, Will Senn via TUHS wrote: > I'm doing forth exploring and am curious if there were forthen (is that even > a word?) on early versions of unix that folks remember using? > > Will -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Mon Sep 22 13:23:55 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Mon, 22 Sep 2025 13:23:55 +1000 Subject: [TUHS] forth on early unix In-Reply-To: <20250922031711.GB31455@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> Message-ID: I wrote a lot of forth as a student programming radio telescopes, often inside the telescope base itself. That was a thing back then, much to my surprise. The regexp implementation BWK has celebrated was likely rooted in a similar thing I did one hot summer day baking underneath a dish, annoyed at the difficulty of doing what I wanted to do. That version fit inside a 512-byte block (that was a forth thing back then), probably two or three times over. I survived forth. -rob On Mon, Sep 22, 2025 at 1:17 PM Larry McVoy via TUHS wrote: > Bruce Karsh made me write a lot of forth on a Masscomp. Messed with me, > he was good at that, I wrote more(1) in forth and he kept coming back with > "can it go backwords?" "Can you search?" etc. I made a pretty good more > clone in forth because of Bruce. And if you don't know him, I was on a > zoom memorial for him and there were two Turing Award winners on that > zoom. Bruce was somebody. I felt like I did not deserve to be there. > > I'm still not a forth fan. That said, the sun boot proms were in > forth and there was some pretty cool forth in there. It knew the VM > structures, it knew sockets, it knew a lot. I'm still not a forth fan > but it was useful. > > On Sun, Sep 21, 2025 at 10:03:15PM -0500, Will Senn via TUHS wrote: > > I'm doing forth exploring and am curious if there were forthen (is that > even > > a word?) on early versions of unix that folks remember using? > > > > Will > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Mon Sep 22 13:26:57 2025 From: tuhs at tuhs.org (Jeff Johnson via TUHS) Date: Sun, 21 Sep 2025 23:26:57 -0400 Subject: [TUHS] forth on early unix In-Reply-To: References: Message-ID: <5d284afc-5b1c-4da2-8c42-0a0dca37c970@app.fastmail.com> I mostly used fig-FORTH variations. Not old Unix so maybe off-topic but there was a fun TINY.FORTH which started out on Commodore 64. There was a C conversion of it for Honeywell CP-6. I rescued it and made also it work on modern Unix at https://GitHub.com/johnsonjh/6FORTH. -- Jeffrey H. Johnson trnsz at pobox.com On Sun, Sep 21, 2025, at 11:03 PM, Will Senn via TUHS wrote: > I'm doing forth exploring and am curious if there were forthen (is that > even a word?) on early versions of unix that folks remember using? > > Will From tuhs at tuhs.org Mon Sep 22 14:14:57 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Mon, 22 Sep 2025 14:14:57 +1000 (EST) Subject: [TUHS] forth on early unix In-Reply-To: <20250922031711.GB31455@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> Message-ID: On Sun, 21 Sep 2025, Larry McVoy via TUHS wrote: > I'm still not a forth fan. That said, the sun boot proms were in forth > and there was some pretty cool forth in there. It knew the VM > structures, it knew sockets, it knew a lot. I'm still not a forth fan > but it was useful. The FreeBSD boot scripts are written in FORTH (for the early stages at least). Cute language, but then again I was also brought up on APL\360 :-) -- Dave From tuhs at tuhs.org Mon Sep 22 14:52:46 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Sun, 21 Sep 2025 22:52:46 -0600 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: On Sun, Sep 21, 2025 at 10:15 PM Dave Horsfall via TUHS wrote: > On Sun, 21 Sep 2025, Larry McVoy via TUHS wrote: > > > I'm still not a forth fan. That said, the sun boot proms were in forth > > and there was some pretty cool forth in there. It knew the VM > > structures, it knew sockets, it knew a lot. I'm still not a forth fan > > but it was useful. > > The FreeBSD boot scripts are written in FORTH (for the early stages at > least). > The final loader was written in 4th (it's still in the tree) and handled the scripting around booting... We added lua several years ago and are phasing 4th out (14 was going to be the last release with it, but it lives on in 15 since lua uses more stack than 4th and some combos of options are too large on BIOS systems with a ~550k limit) Warner > Cute language, but then again I was also brought up on APL\360 :-) > > -- Dave > From tuhs at tuhs.org Mon Sep 22 17:12:15 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Mon, 22 Sep 2025 17:12:15 +1000 (EST) Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: On Sun, 21 Sep 2025, Warner Losh wrote: > The final loader was written in 4th (it's still in the tree) and handled > the scripting around booting...  We added lua several years ago and are > phasing 4th out (14 was going to be the last release with it, but it > lives on in 15 since lua uses more stack than 4th and some combos of > options are too large on BIOS systems with a ~550k limit)  But, but, nobody needs more than 640K :-) -- Dave From tuhs at tuhs.org Mon Sep 22 17:23:49 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 22 Sep 2025 01:23:49 -0600 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: <202509220723.58M7NnZG039234@freefriends.org> Rob Pike via TUHS wrote: > I survived forth. This might make a good bumper sticker, or t-shirt. :-) Arnold From tuhs at tuhs.org Mon Sep 22 18:02:31 2025 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Mon, 22 Sep 2025 10:02:31 +0200 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> On 22/09/2025 05:23, Rob Pike via TUHS wrote: > I survived forth. Likewise. I was trying to port forth to the PDP-10 and had to give up - but having had the experience, it made me able to do some neat stuff in PostScript. Julf From tuhs at tuhs.org Mon Sep 22 18:05:39 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 22 Sep 2025 08:05:39 +0000 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: <8BFF705C-BE97-4FFE-BFF0-05C115FDE2DA@archibald.dev> On Sep 21, 2025, at 21:23, Rob Pike wrote: > I wrote a lot of forth as a student programming radio telescopes, often > inside the telescope base itself. That was a thing back then, much to my > surprise. The regexp implementation BWK has celebrated was likely rooted in > a similar thing I did one hot summer day baking underneath a dish, annoyed > at the difficulty of doing what I wanted to do. That version fit inside a > 512-byte block (that was a forth thing back then), probably two or three > times over. Rob, Which regexp implementation was that? It sounds like one I haven't heard of. Are you referring to the one in The Practice of Programming that you did with bwk? Besides that, I know you wrote the ones for sam and Go; were there others? I've been working on tracing historical development of regexp engines (https://github.com/thaliaarchi/regexp-museum) and would be interested in any you were involved with. Thanks, Thalia From tuhs at tuhs.org Mon Sep 22 20:00:37 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Mon, 22 Sep 2025 20:00:37 +1000 Subject: [TUHS] forth on early unix In-Reply-To: <8BFF705C-BE97-4FFE-BFF0-05C115FDE2DA@archibald.dev> References: <20250922031711.GB31455@mcvoy.com> <8BFF705C-BE97-4FFE-BFF0-05C115FDE2DA@archibald.dev> Message-ID: That's the one, yes. Brian Kernighan wrote an exegesis of it that became the first chapter of the book Beautiful Code. He didn't say enough about its potentially pathological performance, but then it was pretty much the same algorithm as what ed(1) did, and unlikely to occur in non-brutal practice. I wrote the well-behaved, truly linear one in sam, which presotto extracted to create the Plan 9 regexp library. I did the early Go library, but Russ replaced it with a much more efficient, capable and (for better or worse) modern implementation. Those are the only two that saw the light of day, although I also made some "improvements" (i.e., non-regular additions) to the ed code when working on qed, some of which landed unattributed in vi. -rob On Mon, Sep 22, 2025 at 6:05 PM Thalia Archibald wrote: > On Sep 21, 2025, at 21:23, Rob Pike wrote: > > I wrote a lot of forth as a student programming radio telescopes, often > > inside the telescope base itself. That was a thing back then, much to my > > surprise. The regexp implementation BWK has celebrated was likely rooted > in > > a similar thing I did one hot summer day baking underneath a dish, > annoyed > > at the difficulty of doing what I wanted to do. That version fit inside a > > 512-byte block (that was a forth thing back then), probably two or three > > times over. > > Rob, > > Which regexp implementation was that? It sounds like one I haven't heard > of. Are > you referring to the one in The Practice of Programming that you did with > bwk? > Besides that, I know you wrote the ones for sam and Go; were there others? > I've > been working on tracing historical development of regexp engines > (https://github.com/thaliaarchi/regexp-museum) and would be interested in > any > you were involved with. > > Thanks, > Thalia > From tuhs at tuhs.org Mon Sep 22 22:51:11 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Mon, 22 Sep 2025 12:51:11 +0000 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: (Niklas Karlsson via TUHS's message of "Sun, 21 Sep 2025 07:25:27 +0200") References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> Message-ID: <7wbjn2fy68.fsf@junk.nocrew.org> Niklas Karlsson wrote: > I had been under the impression that there was a NetBSD port to the > PDP-10, but apparently it has only been proposed. It was started but didn't get very far. First it used GCC, later PCC. From tuhs at tuhs.org Mon Sep 22 23:03:53 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Mon, 22 Sep 2025 13:03:53 +0000 Subject: [TUHS] forth on early unix In-Reply-To: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> (Johan Helsingius via TUHS's message of "Mon, 22 Sep 2025 10:02:31 +0200") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> Message-ID: <7w7bxqfxl2.fsf@junk.nocrew.org> Johan Helsingius wrote: > I was trying to port forth to the PDP-10 and had to give up When was that? And why did you give up? I wrote a Forth for the PDP-8; based on that I would say one for the PDP-10 wouldn't be overly difficult. There's a Forth for the PDP-10 written in Maclisp, but perhaps that's a bit of a cheat. [Veering wildly off TUHS, redirected to COFF] From tuhs at tuhs.org Mon Sep 22 23:08:26 2025 From: tuhs at tuhs.org (Jeff Johnson via TUHS) Date: Mon, 22 Sep 2025 09:08:26 -0400 Subject: [TUHS] forth on early unix In-Reply-To: <7w7bxqfxl2.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: <6a1bfa93-8463-4b92-85ef-8216b929cf2f@app.fastmail.com> I also rescued and archived Roger Ivie’s THIRD, which is a portable (and non-standard) FORTH that works on various systems - it comes with pre-built PDP-8 and CP/M-80 binaries. https://github.com/johnsonjh/third It’s an odd yet clever implementation for small systems. -- Jeffrey H. Johnson trnsz at pobox.com On Mon, Sep 22, 2025, at 9:03 AM, Lars Brinkhoff via TUHS wrote: > Johan Helsingius wrote: >> I was trying to port forth to the PDP-10 and had to give up > > When was that? And why did you give up? > > I wrote a Forth for the PDP-8; based on that I would say one for the > PDP-10 wouldn't be overly difficult. > > There's a Forth for the PDP-10 written in Maclisp, but perhaps that's a > bit of a cheat. > > [Veering wildly off TUHS, redirected to COFF] From tuhs at tuhs.org Mon Sep 22 23:34:25 2025 From: tuhs at tuhs.org (Phillip Harbison via TUHS) Date: Mon, 22 Sep 2025 08:34:25 -0500 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> Message-ID: <8799d70f-51e3-469b-84bf-16ae8e00f0eb@xavax.com> Dave Horsfall via TUHS wrote: > Larry McVoy via TUHS wrote: > > I'm still not a forth fan. That said, the sun boot proms were in forth > > and there was some pretty cool forth in there. It knew the VM > > structures, it knew sockets, it knew a lot. I'm still not a forth fan > > but it was useful. > > The FreeBSD boot scripts are written in FORTH (for the early stages at > least). > > Cute language, but then again I was also brought up on APL\360 :-) Wasn't Open Firmware based on Forth? I recall running into it when working with MkLinux. -- Phil Harbison From tuhs at tuhs.org Mon Sep 22 23:43:55 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 22 Sep 2025 09:43:55 -0400 Subject: [TUHS] forth on early unix In-Reply-To: References: Message-ID: On Sun, Sep 21, 2025 at 11:09 PM Will Senn via TUHS wrote: > I'm doing forth exploring and am curious if there were forthen (is that > even a word?) on early versions of unix that folks remember using? Define "early versions"? I don't know about research Unix on the PDP-11, but as Larry mentioned, Sun's boot PROM monitors used forth, at least on SPARC (did they on 68k as well?). Some of the functionality was pretty neat: see the section titled "Symbiosis" in this short article from Mike Shapiro, which is nominally on little languages, but comes by way of describing the genesis of the Solaris MDB debugger: https://queue.acm.org/detail.cfm?id=1508217 The idea of Forth commands named for assembler mnemonics that assembled into SPARC instructions seems particularly inspired. These ideas still resonate and have relevance. As some folks may know, Oxide hardware doesn't use a BIOS or UEFI or any such thing; we boot almost directly into Unix. I say "almost" because we have a (very) thin loader stored in flash that runs directly from the reset vector and that initializes the x86 BSP, loads the kernel nucleus into RAM, and jumps to its entry point. This lets us treat the kernel like a standard, run-of-the-mill ELF binary: https://github.com/oxidecomputer/phbl/ However, that's not what we use when we're doing bringup for a new board or CPU microarchitecture: the cost, and wear on the part, of rewriting flash for each iteration is too high. For that, we have a separate program that runs from the reset vector and is kinda-sorta a "debugger" (not precisely a debugger in the "set a breakpoint and continue" sense, but rather in the, "can inspect a bunch of system state" sense). That program has a REPL that a user can interact with over a serial port, and supports sending a binary over the UART that is then loaded and run. The REPL has to be relatively easy to use, as we have non-kernel folks using it (EEs, for example). A kind of neat idea it implements is support for something analogous to pipelines: one can chain various commands together so that the output of one becomes input to the next, though I think in context it's closer to functional composition than pipes per se: suppose y = g(x) and I want to run f(y); in Algebra, this is the same as f(g(x)), and in our program, can be written as either `f . g x` (vaguely inspired by Haskell) or `g x | f` at the REPL. For details, see https://github.com/oxidecomputer/bldb/ However, when I was writing that, I was struggling a bit with how to organize the internal representation for commands and their arguments, and how to chain them together: if I gave an argument to a command, how would that interact with a chain? Would the explicit argument come first, last, what? How would the command know to read arguments from the pipe state, or whatever one would call it, versus what was given explicitly to the command? For that matter, how would the pipe state be represented? What if a command outputs more than one data (say, an address and a length)? Would I fill in some per-command (these are all builtins) data structure and pad it out to the expected number of elements by reading from some vector of prior-command data? What if the sizes didn't match up? What if I need to stash some data to pass to something later? It was getting messy. I was discussing this with Bryan Cantrill and he suggested I read Shapiro's article. The solution, which was so obvious, hit me once I got to the section about Forth and the Sun PROM monitor: use a stack to pass state across commands. A command takes its arguments from the stack, pulling only as many elements as it needs, and pushes its output back onto the same stack. If the REPL reads a command of the form, `foo a b` it pushes `b`, then `a`, and then invokes `foo`. A chain of commands is represented by a separate stack. I added commands to duplicate the item at the top of the stack, swap the top two elements, and of course push and pop; all very Forth-inspired. The result was a beautiful simplification: the system is easy to use but surprisingly powerful. Note that this also meant I could refer to data put on the stack by one command much later; so for example, I can read compressed data over the serial port, decompress it (returning the base address and size of the decompressed data), duplicate the data returned from decompression, use the duplicate to "mount" a ramdisk filesystem image leaving the original on the stack, then load a file from the ramdisk (which pushes its entry point onto the stack), and call its entry point, passing the previously-duplicated decomp data as arguments (indeed, that's exactly how we boot development images on the system). I suspect this is the sort of thing folks did in Forth regularly, and it continues to give inspiration in 2025! - Dan C. From tuhs at tuhs.org Tue Sep 23 00:51:43 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 22 Sep 2025 10:51:43 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250920203533.04BBADCFD844@ary.qy> References: <20250920203533.04BBADCFD844@ary.qy> Message-ID: On Sat, Sep 20, 2025 at 4:35 PM John Levine wrote: > It appears that Dan Cross via TUHS said: > >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. ... > > It is, but a program that has all the logic to adjust for 16th century > calendar changes, not so much. (Try "cal 9 1752") The amount of logic required to handle that in the 5th Ed version of `cal` is surprisingly small, consisting of only three places and perhaps a total of 8 or 9 lines of code, depending on how one wants to count. > My impression is that the Unix cal program was always this overimplemented > so perhaps we can see whether other earlier programs did that too. I edited a copy to get it to compile with a recent compiler. The changes were mainly to modernize the C dialect `=+` vs `+=` and that kind of thing; I added prototypes in a handful of places, and used ISO function definitions and a couple of `#include`'s. The result is 214 lines of code, including whitespace. Forgive me, but I'd hardly call that "over-implemented." THVV's Multics calendar program is actually meant to produce printable calendars to hang on a wall, with enough space that one could write birthdays and so forth onto them, as one might on a hanging calendar bought in a store. That program is over a thousand lines of code PL/1 code (including significant comments and whitespace): https://github.com/dancrossnyc/multics/blob/main/library_dir_dir/system_library_standard/source/bound_printing_cmds_.s.archive/calendar.pl1 Multics calendar does not appear to handle the Sep 1752 switch, however. - Dan C. From tuhs at tuhs.org Tue Sep 23 01:05:27 2025 From: tuhs at tuhs.org (Jeff Johnson via TUHS) Date: Mon, 22 Sep 2025 11:05:27 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250920203533.04BBADCFD844@ary.qy> Message-ID: You can also look at the code with (what should be) better indentation and proper syntax highlighting at https://dps8m.gitlab.io/sb/MR12.8/library_dir_dir/system_library_standard/source/bound_printing_cmds_.s.archive/calendar.pl1.html THVV’s also allows adding custom text and holidays before printing and it also includes code for calculating the date of Easter. It’s a quite the featureful program for when it was introduced. -- Jeffrey H. Johnson trnsz at pobox.com From tuhs at tuhs.org Tue Sep 23 01:19:19 2025 From: tuhs at tuhs.org (Phillip Harbison via TUHS) Date: Mon, 22 Sep 2025 10:19:19 -0500 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <20250921011253.BA763DD04BD2@ary.qy> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> Message-ID: John Levine via TUHS wrote: > Yup. Until the late 1960s computers had such widely different addressing and > data architectures that it wouldn't have made sense to try to write portable > system software. FORTRAN and COBOL programs could be fairly portable, but at a > much higher level of abstraction than an operating system. > ... > The only attempt I know to put Unix on a machine that didn't have 8-bit > bytes was the BBN C70 with 10-bit bytes. One of the programmers told > me that finding all the 8-bit assumptions in Unix applications was > very painful. UNIVAC 1100 says hi. - 36-bit general purpose A(ccumulator) registers. - 36-bit and 72-bit floating point - indeX registers split into 18-bit address (because who would ever need to address more than 256K words?) and 18-bit auto-increment - 6-bit characters (Fieldata). ASCII support added later with 9-bit characters (not sure how they used thew extra bit) - octal preferred here ;) UAH had been a Univac shop since beginning with NASA and US Army leftovers. This is probably why UAH waited until Sperry remarketed the Computer Consoles Power 6 (aka Tahoe, not to be confused with IBM Power 6). I installed UNIX, my homegrown clone of Emacs, and set up netnews on our first UNIX system (uahcs1). I was not an employee, just a proud alumnus and friend of the CS department chairman. Meanwhile I was running Unisoft's port of UNIX System V.0 on my home- built 68000 box with a mere 1 MB of memory and no demand paging hence the need for my own mini-clone of Emacs (more like MINCE) that loaded as fast as vi. It was dubbed "madhat" and was the first public access netnews host in The Rocket City with a free news feed compliments of Lindsey Cleveland at AT&T Atlanta Cable Works (akgua) until I migrated the feed to uahcs1. I worked on other 68K systems, both UNIX and embedded, but they were all programmed in C. It was not much of a challenge once you made sure your homegrown malloc (for embedded) always returned a long-aligned block of memory. A coworker had tested his malloc on an NS16032 and was confused when he got Address Error traps. He tried to convince management that the 68000 was broken. While the MS16032 supported unaligned access it did so at a huge performance penalty. Our compiler (Green Hills) took care of other alignment issues as long as your malloc behaved. It helped if you used unsigned chars since the 68K MOVE instruction did not sign-extend and required two instructions (EXT.W and EXT.L) to extend to 32 bits. The 68010 and later 680x0 family added EXT.B (extend byte to long word) but if you rolled your own libraries (for embedded) why not avoid sign extension entirely? -- Phil Harbison From tuhs at tuhs.org Tue Sep 23 01:24:48 2025 From: tuhs at tuhs.org (Phillip Harbison via TUHS) Date: Mon, 22 Sep 2025 10:24:48 -0500 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> Message-ID: <6e0d027d-b83b-4a4d-95f3-bcbb25741668@xavax.com> Phillip Harbison via TUHS wrote: > While the MS16032 supported unaligned access it did so at a huge > performance penalty. NS, as in National Semiconductor, not MS. -- Phil Harbison From tuhs at tuhs.org Tue Sep 23 01:41:14 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Mon, 22 Sep 2025 15:41:14 +0000 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: (Phillip Harbison via TUHS's message of "Mon, 22 Sep 2025 10:19:19 -0500") References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> Message-ID: <7wwm5qebqd.fsf@junk.nocrew.org> Phillip Harbison wrote: > UNIVAC 1100 says hi. > - 36-bit general purpose A(ccumulator) registers. > - 36-bit and 72-bit floating point > - indeX registers split into 18-bit address (because who would ever > need to address more than 256K words?) and 18-bit auto-increment > - 6-bit characters (Fieldata). ASCII support added later with 9-bit > characters (not sure how they used thew extra bit) > - octal preferred here ;) And for yet more fun, one's complement. After having worked on a PDP-10 backend for GCC, I looked into this one. But it never went anywhere. From tuhs at tuhs.org Tue Sep 23 02:07:40 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 22 Sep 2025 12:07:40 -0400 (EDT) Subject: [TUHS] History of cal(1)? Message-ID: <20250922160740.4D25218C073@mercury.lcs.mit.edu> > From: Dan Cross > Multics calendar does not appear to handle the Sep 1752 switch, however. Well, I doubt anyone's going to print a September, 1752 calendar, right? :-) Noel From tuhs at tuhs.org Tue Sep 23 02:27:45 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Mon, 22 Sep 2025 16:27:45 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250922160740.4D25218C073@mercury.lcs.mit.edu> References: <20250922160740.4D25218C073@mercury.lcs.mit.edu> Message-ID: Noel, Ever since a fella sawed through a 6.6kV AC cable next to the factory my dad worked in at the time, apparently using the logic... if (date = holiday_weekend && nobody_around = TRUE){ cut_cable(); } ...it has been my firm belief that there's always at least one person, somewhere, ready to do what most of us would dismiss as crazy or unnecessary. I can't remember who started off this thread about cal(1) but I'm very grateful as it has sent me down a rabbit hole of great depth, searching for cal source code and also comparing different versions of cal in terms of behavior. Cool stuff. Best, Cameron Sent from Proton Mail Android -------- Original Message -------- On 22/09/2025 17:07, Noel Chiappa via TUHS wrote: > > From: Dan Cross > > > Multics calendar does not appear to handle the Sep 1752 switch, however. > > Well, I doubt anyone's going to print a September, 1752 calendar, right? :-) > > Noel > From tuhs at tuhs.org Tue Sep 23 02:45:58 2025 From: tuhs at tuhs.org (Phillip Harbison via TUHS) Date: Mon, 22 Sep 2025 11:45:58 -0500 Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <7wwm5qebqd.fsf@junk.nocrew.org> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> <7wwm5qebqd.fsf@junk.nocrew.org> Message-ID: <3d136472-540e-4179-bdc0-c4e5fd4254a4@xavax.com> Lars Brinkhoff via TUHS wrote: > Phillip Harbison wrote: >> UNIVAC 1100 says hi. >> - 36-bit general purpose A(ccumulator) registers. >> ... > > And for yet more fun, one's complement. After having worked on a PDP-10 > backend for GCC, I looked into this one. But it never went anywhere. Oh! I forgot about that. I should have remembered the long discussion about binary math in 1st quarter 1100 assembler. During the space race plus early Army missile development they built Research Institute (now Von Braun Hall) where Sperry set up a trio of 1108 systems. When Sperry got out of the time sharing business due to some court decision, the Army took one, NASA took one, and UAH got one. Not sure if the 1108 was donated but the building was and became home to UAH school of engineering. The 1108 memory was upgraded from core to semiconductor which I think makes it an 1100/10. That's how we got stuck with Univac. -- Phil Harbison From tuhs at tuhs.org Tue Sep 23 04:18:58 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 22 Sep 2025 14:18:58 -0400 Subject: [TUHS] History of cal(1)? Message-ID: > [cal(1)] has all the logic to adjust for 16th century > calendar changes ... (Try "cal 9 1752") > My impression is that [it is] overimplemented. The fact that a 16th century change is illustrated by an 18th century example suggests that not quite "all the logic" is there. It's good for Great Britain and its colonies, but not elsewhere. So I'd say it's underimplemented :) Doug From tuhs at tuhs.org Tue Sep 23 04:38:06 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 22 Sep 2025 18:38:06 +0000 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) Message-ID: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Spurred by the discussion on regular expressions in the Forth thread: Unix V10 included a command named gre, which aimed to succeed grep, egrep, and fgrep. Does anyone know anything about it? Who wrote it? Was it used anywhere or succeeded by anything? Was it connected to Plan 9 or Inferno? >From its man page: > Gre supplants three classic programs, which are still available: > Grep handles only ed(1)-like regular expressions. It uses \(\) instead of (). > Egrep handles the same patterns as gre except for back-referencing with \1, \2, ... > Fgrep handles no operators except newline (alternation). https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 Thanks, Thalia Archibald From tuhs at tuhs.org Tue Sep 23 06:55:15 2025 From: tuhs at tuhs.org (Stuff Received via TUHS) Date: Mon, 22 Sep 2025 16:55:15 -0400 Subject: [TUHS] forth on early unix In-Reply-To: <8799d70f-51e3-469b-84bf-16ae8e00f0eb@xavax.com> References: <20250922031711.GB31455@mcvoy.com> <8799d70f-51e3-469b-84bf-16ae8e00f0eb@xavax.com> Message-ID: <9e7106ae-6dc3-9bec-6dd8-b9756cd1156f@riddermarkfarm.ca> On 2025-09-22 09:34, Phillip Harbison via TUHS wrote: > Dave Horsfall via TUHS wrote: >> Larry McVoy via TUHS wrote: >> > I'm still not a forth fan.  That said, the sun boot proms were in forth >> > and there was some pretty cool forth in there.  It knew the VM >> > structures, it knew sockets, it knew a lot.  I'm still not a forth fan >> > but it was useful. >> >> The FreeBSD boot scripts are written in FORTH (for the early stages at >> least). >> >> Cute language, but then again I was also brought up on APL\360 :-) > > Wasn't Open Firmware based on Forth? I recall running into it when > working with MkLinux. https://github.com/openbios/openboot (and other tidbits in the same repo). S. From tuhs at tuhs.org Tue Sep 23 08:37:23 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 22 Sep 2025 16:37:23 -0600 Subject: [TUHS] forth on early unix In-Reply-To: <9e7106ae-6dc3-9bec-6dd8-b9756cd1156f@riddermarkfarm.ca> References: <20250922031711.GB31455@mcvoy.com> <8799d70f-51e3-469b-84bf-16ae8e00f0eb@xavax.com> <9e7106ae-6dc3-9bec-6dd8-b9756cd1156f@riddermarkfarm.ca> Message-ID: On Mon, Sep 22, 2025, 2:55 PM Stuff Received via TUHS wrote: > On 2025-09-22 09:34, Phillip Harbison via TUHS wrote: > > Dave Horsfall via TUHS wrote: > >> Larry McVoy via TUHS wrote: > >> > I'm still not a forth fan. That said, the sun boot proms were in > forth > >> > and there was some pretty cool forth in there. It knew the VM > >> > structures, it knew sockets, it knew a lot. I'm still not a forth fan > >> > but it was useful. > >> > >> The FreeBSD boot scripts are written in FORTH (for the early stages at > >> least). > >> > >> Cute language, but then again I was also brought up on APL\360 :-) > > > > Wasn't Open Firmware based on Forth? I recall running into it when > > working with MkLinux. > > https://github.com/openbios/openboot (and other tidbits in the same repo) > Yea. The FreeBSD loader started out trying to replicate these interfaces but fell well short of that goal and then diverged... Warner > From tuhs at tuhs.org Tue Sep 23 10:34:53 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 22 Sep 2025 20:34:53 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: <20250923003454.03671DD56E9A@ary.qy> It appears that Douglas McIlroy via TUHS said: >> [cal(1)] has all the logic to adjust for 16th century >> calendar changes ... (Try "cal 9 1752") >> My impression is that [it is] overimplemented. > >The fact that a 16th century change is illustrated by an 18th century >example suggests that not quite "all the logic" is there. It's good >for Great Britain and its colonies, but not elsewhere. So I'd say it's >underimplemented :) You'll be relieved to know that ncal has addressed that omission: $ ncal -p AL Albania 1912-11-30 IS Iceland 1700-11-16 AT Austria 1583-10-05 IT Italy 1582-10-04 AU Australia 1752-09-02 JP Japan 1918-12-18 BE Belgium 1582-12-14 LT Lithuania 1918-02-01 BG Bulgaria 1916-03-31 LU Luxembourg 1582-12-14 CA Canada 1752-09-02 LV Latvia 1918-02-01 CH Switzerland 1655-02-28 NL Netherlands 1582-12-14 CN China 1911-12-18 NO Norway 1700-02-18 CZ Czech Republic 1584-01-06 PL Poland 1582-10-04 DE Germany 1700-02-18 PT Portugal 1582-10-04 DK Denmark 1700-02-18 RO Romania 1919-03-31 ES Spain 1582-10-04 RU Russia 1918-01-31 FI Finland 1753-02-17 SI Slovenia 1919-03-04 FR France 1582-12-09 SE Sweden 1753-02-17 GB United Kingdom 1752-09-02 TR Turkey 1926-12-18 GR Greece 1924-03-09 *US United States 1752-09-02 HU Hungary 1587-10-21 YU Yugoslavia 1919-03-04 R's, John PS: my point was not that it's a lot of code, but that is's a distinctive hack so one might look at earlier calendar programs to see whether they also did it to try and trace the chain of influence. From tuhs at tuhs.org Tue Sep 23 11:05:34 2025 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Tue, 23 Sep 2025 03:05:34 +0200 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250923003454.03671DD56E9A@ary.qy> References: <20250923003454.03671DD56E9A@ary.qy> Message-ID: <20250923010534.2L17rbeZ@steffen%sdaoden.eu> John Levine via TUHS wrote in <20250923003454.03671DD56E9A at ary.qy>: |It appears that Douglas McIlroy via TUHS \ |said: |>> [cal(1)] has all the logic to adjust for 16th century |>> calendar changes ... (Try "cal 9 1752") |>> My impression is that [it is] overimplemented. |> |>The fact that a 16th century change is illustrated by an 18th century |>example suggests that not quite "all the logic" is there. It's good |>for Great Britain and its colonies, but not elsewhere. So I'd say it's |>underimplemented :) | |You'll be relieved to know that ncal has addressed that omission: | |$ ncal -p | AL Albania 1912-11-30 IS Iceland 1700-11-16 | AT Austria 1583-10-05 IT Italy 1582-10-04 | AU Australia 1752-09-02 JP Japan 1918-12-18 | BE Belgium 1582-12-14 LT Lithuania 1918-02-01 | BG Bulgaria 1916-03-31 LU Luxembourg 1582-12-14 | CA Canada 1752-09-02 LV Latvia 1918-02-01 | CH Switzerland 1655-02-28 NL Netherlands 1582-12-14 | CN China 1911-12-18 NO Norway 1700-02-18 | CZ Czech Republic 1584-01-06 PL Poland 1582-10-04 | DE Germany 1700-02-18 PT Portugal 1582-10-04 (In an earlier thread on this topic Mr. McIlroy threw into the discussion that for example Germany was very much more complicated than that. And i said iirc something like "we tried to keep it local by then" [actually notoriously so], and unfortunately talked about Mors Teutonicus even, as "we more usually than not reached the Holy Land" before reaching the holy land, which *possibly* is the only one and true way to reach the holy land .. if you can. (Pffffhh, what a talk.)) | DK Denmark 1700-02-18 RO Romania 1919-03-31 | ES Spain 1582-10-04 RU Russia 1918-01-31 | FI Finland 1753-02-17 SI Slovenia 1919-03-04 | FR France 1582-12-09 SE Sweden 1753-02-17 | GB United Kingdom 1752-09-02 TR Turkey 1926-12-18 | GR Greece 1924-03-09 *US United States 1752-09-02 | HU Hungary 1587-10-21 YU Yugoslavia 1919-03-04 | |R's, |John | |PS: my point was not that it's a lot of code, but that is's a distinctive \ |hack so one might |look at earlier calendar programs to see whether they also did it to \ |try and trace the |chain of influence. --End of <20250923003454.03671DD56E9A at ary.qy> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Tue Sep 23 11:50:21 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Tue, 23 Sep 2025 11:50:21 +1000 Subject: [TUHS] History of cal(1)? In-Reply-To: <20250923010534.2L17rbeZ@steffen%sdaoden.eu> References: <20250923003454.03671DD56E9A@ary.qy> <20250923010534.2L17rbeZ@steffen%sdaoden.eu> Message-ID: There are so many calendars in the world. The Muslim calendar. The Jewish calendar. The Mayan calendar. Countless indigenous calendars too, I am certain. Whenever computing butts up against real human culture, things get messy fast. No point in trying to catalog the mess exhaustively. -rob On Tue, Sep 23, 2025 at 11:14 AM Steffen Nurpmeso via TUHS wrote: > John Levine via TUHS wrote in > <20250923003454.03671DD56E9A at ary.qy>: > |It appears that Douglas McIlroy via TUHS > \ > |said: > |>> [cal(1)] has all the logic to adjust for 16th century > |>> calendar changes ... (Try "cal 9 1752") > |>> My impression is that [it is] overimplemented. > |> > |>The fact that a 16th century change is illustrated by an 18th century > |>example suggests that not quite "all the logic" is there. It's good > |>for Great Britain and its colonies, but not elsewhere. So I'd say it's > |>underimplemented :) > | > |You'll be relieved to know that ncal has addressed that omission: > | > |$ ncal -p > | AL Albania 1912-11-30 IS Iceland 1700-11-16 > | AT Austria 1583-10-05 IT Italy 1582-10-04 > | AU Australia 1752-09-02 JP Japan 1918-12-18 > | BE Belgium 1582-12-14 LT Lithuania 1918-02-01 > | BG Bulgaria 1916-03-31 LU Luxembourg 1582-12-14 > | CA Canada 1752-09-02 LV Latvia 1918-02-01 > | CH Switzerland 1655-02-28 NL Netherlands 1582-12-14 > | CN China 1911-12-18 NO Norway 1700-02-18 > | CZ Czech Republic 1584-01-06 PL Poland 1582-10-04 > | DE Germany 1700-02-18 PT Portugal 1582-10-04 > > (In an earlier thread on this topic Mr. McIlroy threw into > the discussion that for example Germany was very much more > complicated than that. And i said iirc something like "we > tried to keep it local by then" [actually notoriously so], and > unfortunately talked about Mors Teutonicus even, as "we more > usually than not reached the Holy Land" before reaching the holy > land, which *possibly* is the only one and true way to reach the > holy land .. if you can. (Pffffhh, what a talk.)) > > | DK Denmark 1700-02-18 RO Romania 1919-03-31 > | ES Spain 1582-10-04 RU Russia 1918-01-31 > | FI Finland 1753-02-17 SI Slovenia 1919-03-04 > | FR France 1582-12-09 SE Sweden 1753-02-17 > | GB United Kingdom 1752-09-02 TR Turkey 1926-12-18 > | GR Greece 1924-03-09 *US United States 1752-09-02 > | HU Hungary 1587-10-21 YU Yugoslavia 1919-03-04 > | > |R's, > |John > | > |PS: my point was not that it's a lot of code, but that is's a > distinctive \ > |hack so one might > |look at earlier calendar programs to see whether they also did it to \ > |try and trace the > |chain of influence. > --End of <20250923003454.03671DD56E9A at ary.qy> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From tuhs at tuhs.org Tue Sep 23 13:57:46 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 22 Sep 2025 20:57:46 -0700 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250923003454.03671DD56E9A@ary.qy> <20250923010534.2L17rbeZ@steffen%sdaoden.eu> Message-ID: <89629F1E-3178-4544-AC42-9B834D501D8C@iitbombay.org> Things get quite complicated when you have lunisolar calendars! An extra lunar month is added every 32 or 33 lunar months to sync up with the solar cycle[1]. In India they have been in use for many centuries and even today most religious festivals and events follow them. Here's a typical calendar page[2]: https://www.prokerala.com/general/calendar/hinducalendar.php?year=2025&mon=september&sb=1#calendar As you can see plenty of information is imparted[3]. When I was a kid, we would always get a day-per-page calendar every year because of this. [1] One's birthday as per Indian & Greorian calendars lines up almost exactly every 19 years. [2] Not sure what software they use. The calendar also changes based on your location! [3] Things like sunrise/sunset, the zodiac moon is passing through, etc. Details explained here: https://www.anaadi.org/post/indian-calendar-part-3-the-panchangam > On Sep 22, 2025, at 6:50 PM, Rob Pike via TUHS wrote: > > There are so many calendars in the world. The Muslim calendar. The Jewish > calendar. The Mayan calendar. Countless indigenous calendars too, I am > certain. > > Whenever computing butts up against real human culture, things get messy > fast. No point in trying to catalog the mess exhaustively. > > -rob > > > On Tue, Sep 23, 2025 at 11:14 AM Steffen Nurpmeso via TUHS > wrote: > >> John Levine via TUHS wrote in >> <20250923003454.03671DD56E9A at ary.qy>: >> |It appears that Douglas McIlroy via TUHS >> \ >> |said: >> |>> [cal(1)] has all the logic to adjust for 16th century >> |>> calendar changes ... (Try "cal 9 1752") >> |>> My impression is that [it is] overimplemented. >> |> >> |>The fact that a 16th century change is illustrated by an 18th century >> |>example suggests that not quite "all the logic" is there. It's good >> |>for Great Britain and its colonies, but not elsewhere. So I'd say it's >> |>underimplemented :) >> | >> |You'll be relieved to know that ncal has addressed that omission: >> | >> |$ ncal -p >> | AL Albania 1912-11-30 IS Iceland 1700-11-16 >> | AT Austria 1583-10-05 IT Italy 1582-10-04 >> | AU Australia 1752-09-02 JP Japan 1918-12-18 >> | BE Belgium 1582-12-14 LT Lithuania 1918-02-01 >> | BG Bulgaria 1916-03-31 LU Luxembourg 1582-12-14 >> | CA Canada 1752-09-02 LV Latvia 1918-02-01 >> | CH Switzerland 1655-02-28 NL Netherlands 1582-12-14 >> | CN China 1911-12-18 NO Norway 1700-02-18 >> | CZ Czech Republic 1584-01-06 PL Poland 1582-10-04 >> | DE Germany 1700-02-18 PT Portugal 1582-10-04 >> >> (In an earlier thread on this topic Mr. McIlroy threw into >> the discussion that for example Germany was very much more >> complicated than that. And i said iirc something like "we >> tried to keep it local by then" [actually notoriously so], and >> unfortunately talked about Mors Teutonicus even, as "we more >> usually than not reached the Holy Land" before reaching the holy >> land, which *possibly* is the only one and true way to reach the >> holy land .. if you can. (Pffffhh, what a talk.)) >> >> | DK Denmark 1700-02-18 RO Romania 1919-03-31 >> | ES Spain 1582-10-04 RU Russia 1918-01-31 >> | FI Finland 1753-02-17 SI Slovenia 1919-03-04 >> | FR France 1582-12-09 SE Sweden 1753-02-17 >> | GB United Kingdom 1752-09-02 TR Turkey 1926-12-18 >> | GR Greece 1924-03-09 *US United States 1752-09-02 >> | HU Hungary 1587-10-21 YU Yugoslavia 1919-03-04 >> | >> |R's, >> |John >> | >> |PS: my point was not that it's a lot of code, but that is's a >> distinctive \ >> |hack so one might >> |look at earlier calendar programs to see whether they also did it to \ >> |try and trace the >> |chain of influence. >> --End of <20250923003454.03671DD56E9A at ary.qy> >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) >> From tuhs at tuhs.org Tue Sep 23 14:08:02 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 22 Sep 2025 21:08:02 -0700 Subject: [TUHS] forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <8799d70f-51e3-469b-84bf-16ae8e00f0eb@xavax.com> <9e7106ae-6dc3-9bec-6dd8-b9756cd1156f@riddermarkfarm.ca> Message-ID: To get even weirder, the original expansion rom standard for PCI included forth byte codes as an option for the ROM. That never quite worked out, it all became x86, and all the other architectures got stuck with an x86 emulator (and even some x86 firmware included an x86 emulator ...) more here: https://www.openfirmware.org/1275/home.html (dead links included: I really did want to hear Mitch Bradley singing the open firmware song, too bad!). But that page is doing OK for being 29 years old ... I realize this borders on COFF, but it does connect to Unix a tiny bit. On Mon, Sep 22, 2025 at 4:54 PM Warner Losh via TUHS wrote: > On Mon, Sep 22, 2025, 2:55 PM Stuff Received via TUHS > wrote: > > > On 2025-09-22 09:34, Phillip Harbison via TUHS wrote: > > > Dave Horsfall via TUHS wrote: > > >> Larry McVoy via TUHS wrote: > > >> > I'm still not a forth fan. That said, the sun boot proms were in > > forth > > >> > and there was some pretty cool forth in there. It knew the VM > > >> > structures, it knew sockets, it knew a lot. I'm still not a forth > fan > > >> > but it was useful. > > >> > > >> The FreeBSD boot scripts are written in FORTH (for the early stages at > > >> least). > > >> > > >> Cute language, but then again I was also brought up on APL\360 :-) > > > > > > Wasn't Open Firmware based on Forth? I recall running into it when > > > working with MkLinux. > > > > https://github.com/openbios/openboot (and other tidbits in the same > repo) > > > > Yea. The FreeBSD loader started out trying to replicate these interfaces > but fell well short of that goal and then diverged... > > Warner > > > > From tuhs at tuhs.org Tue Sep 23 14:50:57 2025 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Tue, 23 Sep 2025 14:50:57 +1000 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: I will tentatively suggest that it was Andrew Hume. I suspect his major contribution was the addition of Boyer-Moore. On Tue, 23 Sept 2025 at 04:38, Thalia Archibald via TUHS wrote: > Spurred by the discussion on regular expressions in the Forth thread: > > Unix V10 included a command named gre, which aimed to succeed grep, egrep, > and > fgrep. > > Does anyone know anything about it? Who wrote it? Was it used anywhere or > succeeded by anything? Was it connected to Plan 9 or Inferno? > > From its man page: > > Gre supplants three classic programs, which are still available: > > Grep handles only ed(1)-like regular expressions. It uses \(\) instead > of (). > > Egrep handles the same patterns as gre except for back-referencing with > \1, \2, ... > > Fgrep handles no operators except newline (alternation). > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 > > Thanks, > Thalia Archibald > From tuhs at tuhs.org Tue Sep 23 21:52:20 2025 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Tue, 23 Sep 2025 07:52:20 -0400 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: I'm pretty sure, also, that it was Andrew Hume. On Tue, Sep 23, 2025 at 12:51 AM Noel Hunt via TUHS wrote: > > I will tentatively suggest that it was Andrew Hume. I suspect > his major contribution was the addition of Boyer-Moore. > > > On Tue, 23 Sept 2025 at 04:38, Thalia Archibald via TUHS > wrote: > > > Spurred by the discussion on regular expressions in the Forth thread: > > > > Unix V10 included a command named gre, which aimed to succeed grep, egrep, > > and > > fgrep. > > > > Does anyone know anything about it? Who wrote it? Was it used anywhere or > > succeeded by anything? Was it connected to Plan 9 or Inferno? > > > > From its man page: > > > Gre supplants three classic programs, which are still available: > > > Grep handles only ed(1)-like regular expressions. It uses \(\) instead > > of (). > > > Egrep handles the same patterns as gre except for back-referencing with > > \1, \2, ... > > > Fgrep handles no operators except newline (alternation). > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 > > > > Thanks, > > Thalia Archibald > > From tuhs at tuhs.org Tue Sep 23 22:14:35 2025 From: tuhs at tuhs.org (Don Caldwell via TUHS) Date: Tue, 23 Sep 2025 08:14:35 -0400 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: It was definitely Andrew Hume. While at Shannon Labs, he was promoting and using it for some of his projects. On Tue, Sep 23, 2025 at 12:59 AM Noel Hunt via TUHS wrote: > I will tentatively suggest that it was Andrew Hume. I suspect > his major contribution was the addition of Boyer-Moore. > > > On Tue, 23 Sept 2025 at 04:38, Thalia Archibald via TUHS > wrote: > > > Spurred by the discussion on regular expressions in the Forth thread: > > > > Unix V10 included a command named gre, which aimed to succeed grep, > egrep, > > and > > fgrep. > > > > Does anyone know anything about it? Who wrote it? Was it used anywhere or > > succeeded by anything? Was it connected to Plan 9 or Inferno? > > > > From its man page: > > > Gre supplants three classic programs, which are still available: > > > Grep handles only ed(1)-like regular expressions. It uses \(\) instead > > of (). > > > Egrep handles the same patterns as gre except for back-referencing with > > \1, \2, ... > > > Fgrep handles no operators except newline (alternation). > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 > > > > Thanks, > > Thalia Archibald > > > From tuhs at tuhs.org Wed Sep 24 03:40:52 2025 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Tue, 23 Sep 2025 10:40:52 -0700 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: i think the plan9 grep is the fastest. it is grep, egrep, fgrep also. i think it is faster than boyer-moore. the whole program is a jit dfa read block for c in block { s=s.state[c] if s == nil do something occasionally } it is a very few cycles per byte. all of the time is reading a block. i cant imagine b/m could be faster. the best b/m could do is calculate the skip and then jump over bytes that you have already read. russ cox used it to do the (now defunct) code search in google. On Tue, Sep 23, 2025 at 5:14 AM Don Caldwell via TUHS wrote: > It was definitely Andrew Hume. While at Shannon Labs, he was promoting and > using it for some of his projects. > > On Tue, Sep 23, 2025 at 12:59 AM Noel Hunt via TUHS wrote: > > > I will tentatively suggest that it was Andrew Hume. I suspect > > his major contribution was the addition of Boyer-Moore. > > > > > > On Tue, 23 Sept 2025 at 04:38, Thalia Archibald via TUHS > > wrote: > > > > > Spurred by the discussion on regular expressions in the Forth thread: > > > > > > Unix V10 included a command named gre, which aimed to succeed grep, > > egrep, > > > and > > > fgrep. > > > > > > Does anyone know anything about it? Who wrote it? Was it used anywhere > or > > > succeeded by anything? Was it connected to Plan 9 or Inferno? > > > > > > From its man page: > > > > Gre supplants three classic programs, which are still available: > > > > Grep handles only ed(1)-like regular expressions. It uses \(\) > instead > > > of (). > > > > Egrep handles the same patterns as gre except for back-referencing > with > > > \1, \2, ... > > > > Fgrep handles no operators except newline (alternation). > > > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 > > > > > > Thanks, > > > Thalia Archibald > > > > > > From tuhs at tuhs.org Wed Sep 24 10:33:22 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Wed, 24 Sep 2025 10:33:22 +1000 (EST) Subject: [TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)? In-Reply-To: <7wwm5qebqd.fsf@junk.nocrew.org> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> <20250921011253.BA763DD04BD2@ary.qy> <7wwm5qebqd.fsf@junk.nocrew.org> Message-ID: On Mon, 22 Sep 2025, Lars Brinkhoff via TUHS wrote: > And for yet more fun, one's complement. After having worked on a PDP-10 > backend for GCC, I looked into this one. But it never went anywhere. Hey, what's wrong with negative zero? -- Dave, who used to program on a Cyber 72 From tuhs at tuhs.org Thu Sep 25 02:38:55 2025 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Wed, 24 Sep 2025 09:38:55 -0700 Subject: [TUHS] NFS at 40 Message-ID: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> https://nfs40.online/ this is all pretty cool From tuhs at tuhs.org Thu Sep 25 12:22:19 2025 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Wed, 24 Sep 2025 22:22:19 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: That's almost why Harvard settled with Trump. On Fri, Sep 19, 2025, 6:15 PM Warner Losh via TUHS wrote: > 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 > From tuhs at tuhs.org Fri Sep 26 00:07:54 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 25 Sep 2025 14:07:54 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: >> > >> >> 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 untrue. First, the US didn’t join the Berne Convention until 1989. Second, software copyright existed in the US well before Berne. Much analogy was made to piano rolls which were decided well back in 1908, Software was generally held to be the same sort of literary work that anything else was including these piano rolls and phonograph records. There’s tons of pre-Berne case law on this, Notably Apple v. Franklin, and Williams Elec v. Artic Intl. Both affirm that both the source code and the compiled code on computers is protectable. There were a number of reasons why Western Electric used Trade Secret rather than copyright. Some of it was due to the nature of Bell Labs. Other, is that when your protecting TECHNOLOGIC INFORMATION, trade secret allows you to stop that dissemination. Copyright, only prohibits making copies, but not dissemination of the information and patents by their very nature require the information to be disclosed. -Ron From tuhs at tuhs.org Fri Sep 26 00:50:18 2025 From: tuhs at tuhs.org (Theodore Ts'o via TUHS) Date: Thu, 25 Sep 2025 10:50:18 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: <20250925145018.GF19231@mit.edu> On Thu, Sep 25, 2025 at 02:07:54PM +0000, Ron Natalie via TUHS wrote: > There were a number of reasons why Western Electric used Trade Secret rather > than copyright. Some of it was due to the nature of Bell Labs. > Other, is that when your protecting TECHNOLOGIC INFORMATION, trade secret > allows you to stop that dissemination. Copyright, only prohibits making > copies, but not dissemination of the information and patents by their very > nature require the information to be disclosed. Sure, but only if the owner of that information.... doesn't disseminate it, at least not without very specfic protections. That means no trying to patent the setuid bit (as soon as you do that, it's no longer subject to trade secrets). It means no publishing a paper in CACM (as soon as you do that, the information in that paper is no longer subject to trade secret). And if you distribute tapes to people without requiring them to make sure anyone else they might distribute to must sign an NDA, it's not going to be protected. MIT didn't want to get students to sign NDA's that might ihhibit their ability to do future work, which is why MIT refused to sign a license with the Methods and Concepts clause. But if you believe that things don't work that way, then the trade secret wasn't going to prevent the dissemination of that technologic information. Effectively, Trade Secret is a bilateral thing, and is essentially something that gets established via a contract. In practice, there is *very* little difference between Alice and Bob signing a contract stating that Bob promises not to share the information (e.g., an NDA) and Alice and Bob signing a contract stating something is a Trade Secret. In both cases there is *very* little Alice can do to hammer Charlie under law if Charlie receives the information if Charlie didn't sign a NDA or some other contract acknowledging that a particular bit of information is a trade secret. I've handled Trade Secrets before in my time. Some of this was pre-release information about Itanium. In that case, the information was in a orange-covered book, with large letters on the cover saying that it was Intel Proprietary Information, and I had to sign a piece of paper stating that I had received a numbered copy of the information, and I had to promise not to share it and to keep it locked up if I wasn't using it. I've had colleagues who worked with pre-release information for the Sony Playstation, and in that case the information had to be kept in a locked room, and couldn't be taken out of the room --- and I've handled U.S. government classified information that had fewer protections that the Sony information was required to have. This is not "publish it in CACM and then try to think that you can stop dissemination about the technical information." This is why when the encryption key for DVD copy protection was published on the internet, athough that was presumably trade secret informtion, there was zilch that could be done to stop the dissemination of the encryption key. - Ted From tuhs at tuhs.org Fri Sep 26 01:06:09 2025 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Thu, 25 Sep 2025 11:06:09 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: On Thu, Sep 25, 2025 at 10:14 AM Ron Natalie via TUHS wrote: > > There were a number of reasons why Western Electric used Trade Secret > rather than copyright. Some of it was due to the nature of Bell Labs. > Other, is that when your protecting TECHNOLOGIC INFORMATION, trade > secret allows you to stop that dissemination. Copyright, only > prohibits making copies, but not dissemination of the information and > patents by their very nature require the information to be disclosed. > > US patent law doesn't specifically mention software. For a long time the US PTO, and the courts, allowed algorithms to be part of a patent declaration, but only as part of a device. Algorithms expressed as software were not in and of themselves patentable. That stance gradually changed. As you point out copyright protects creative expression of an idea or process. It does not protect the idea or process itself. That is what a patent does, and for a long time software wasn't considered patentable. So if you wanted to protect technological information related to software the alternative you were left with was to make it a trade secret--to legally require that anyone to which you divulged the secret did not disclose it to anyone else without your permission. The advantage of a trade secret is that the information is not disclosed. The disadvantage is that if someone else independently discovers it and obtains a patent for it, the patent holder may demand that you stop using the idea. -Paul W. From tuhs at tuhs.org Fri Sep 26 01:09:42 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 25 Sep 2025 15:09:42 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: I don’t disagree, but software copyright is almost as old as software. The earliest use was back in 1961, long before UNIX or its predecessors existed. Its nonexistance was not the reason Western Electric didn’t use it. ------ Original Message ------ From "Paul Winalski" To "Ron Natalie" Cc "TUHS main list" Date 9/25/2025 11:06:09 AM Subject Re: [TUHS] Re: History of cal(1)? >On Thu, Sep 25, 2025 at 10:14 AM Ron Natalie via TUHS >wrote: >> >>There were a number of reasons why Western Electric used Trade Secret >>rather than copyright. Some of it was due to the nature of Bell >>Labs. >>Other, is that when your protecting TECHNOLOGIC INFORMATION, trade >>secret allows you to stop that dissemination. Copyright, only >>prohibits making copies, but not dissemination of the information and >>patents by their very nature require the information to be disclosed. >> >US patent law doesn't specifically mention software. For a long time >the US PTO, and the courts, allowed algorithms to be part of a patent >declaration, but only as part of a device. Algorithms expressed as >software were not in and of themselves patentable. That stance >gradually changed. > >As you point out copyright protects creative expression of an idea or >process. It does not protect the idea or process itself. That is what >a patent does, and for a long time software wasn't considered >patentable. So if you wanted to protect technological information >related to software the alternative you were left with was to make it a >trade secret--to legally require that anyone to which you divulged the >secret did not disclose it to anyone else without your permission. The >advantage of a trade secret is that the information is not disclosed. >The disadvantage is that if someone else independently discovers it and >obtains a patent for it, the patent holder may demand that you stop >using the idea. > >-Paul W. From tuhs at tuhs.org Fri Sep 26 03:48:54 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 25 Sep 2025 13:48:54 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: On Thu, Sep 25, 2025 at 11:09 AM Ron Natalie via TUHS wrote: > I don’t disagree, but software copyright is almost as old as software. > The earliest use was back in 1961, long before UNIX or its predecessors > existed. > Its nonexistance was not the reason Western Electric didn’t use it. > > But AT&T >>did<< use a copyright on the sources, as I previously sent a screenful of output from: cd ; find . -type f -print | xargs grep -i Copyright | more and the >>copyright<< was all we were worried about at the time. You can do that with any directory that contains source from AT&T and I bet you'll find them. They freely put copyright in everything. Even early UNIX itself prints a banner when you log in, stating that Western Electric holds the copyright on the product you are using. As I mentioned earlier, CMU did not require us to sign an *NDA*. What they asked us to sign was a CMU document that stated we understood this material was licensed to the University, had an AT&T copyright, and we could not distribute it to anyone, without permission [at the time, the "permission gatekeeper was Howard Wakler of the CS Dept, who was responsible for all the systems, the licenses, et al] My memory is that >>before<< that, if CS or the Computer Center (IBM shop) hired you, we had to sign something that said we understood we were representing the University and we would not put any licenses at risk, and that was kept in our employee file. My >>guess< is that what we had to sign for the OS course was a child of that thinking. But I never asked him and have never known if it was Howard's idea to have us sign the agreement. My bet is he was part of it. That was the first OS class that did not use a "toy OS," but rather the 6th Edition of Unix. My >>guess< is that the Prof (Anita Jones), who was teaching the OS course, asked Howard for access to the sources for the students, and Howard likely said - Well, it's licensed to CMU and has an AT&T copyright on it. We need to ensure that they follow the rules for handling licensed IP. The point is that, as far as I know/can remember, the AT&T UNIX licensees for whom I worked (CMU, Tektronix, etc) never considered the UNIX IP as a trade secret. We did treat it as material with a copyright. I also have no recollection of ever hearing anyone at a USENIX talk discuss the "trade secret" aspect of any AT&T license, nor do I remember it coming up in what AT&T negotiated with us on the commercial side, specifically regarding a redistribution license (*i.e*., what would create the System III license). We did argue about where and how the sources could be stored at these sites. IIRC, both the research and commercial use licenses required you to name the CPU model and serial number. For commercial folks, you paid a CPU license to have the IP on it. Simply put, we were worried about infringing on AT&T's copyright and core "UNIX usage" license. Clem From tuhs at tuhs.org Fri Sep 26 06:36:53 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Fri, 26 Sep 2025 06:36:53 +1000 (EST) Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: On Thu, 25 Sep 2025, Clem Cole via TUHS wrote: [...] > and the >>copyright<< was all we were worried about at the time. You > can do that with any directory that contains source from AT&T and I bet > you'll find them. They freely put copyright in everything. Even early > UNIX itself prints a banner when you log in, stating that Western Electric > holds the copyright on the product you are using. Heck; at one time the "true" command was a Shell script with a huge copyright notice, followed by... nothing... (The "false" script actually had "exit 1" at the end.) -- Dave From tuhs at tuhs.org Fri Sep 26 07:05:04 2025 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Thu, 25 Sep 2025 23:05:04 +0200 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: <20250925210504.mFKm8IKW@steffen%sdaoden.eu> Dave Horsfall via TUHS wrote in : |On Thu, 25 Sep 2025, Clem Cole via TUHS wrote: |[...] | |> and the >>copyright<< was all we were worried about at the time. You |> can do that with any directory that contains source from AT&T and I bet |> you'll find them. They freely put copyright in everything. Even early |> UNIX itself prints a banner when you log in, stating that Western \ |> Electric |> holds the copyright on the product you are using. | |Heck; at one time the "true" command was a Shell script with a huge |copyright notice, followed by... nothing... (The "false" script |actually had "exit 1" at the end.) And today i programmer am still too apprehensive to remove the complete copyright notice, leaving only the present * SPDX-License-Identifier: ISC though the Linux kernel (but hey: Linux kernel!) goes that way, as far as i see. (Likely via a mostly automatized sed(1) run. It shortens --copyright output to two lines (minimum), in theory. --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 Fri Sep 26 07:53:20 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 25 Sep 2025 17:53:20 -0400 Subject: [TUHS] copyright maximalism, was History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: <20250925215320.D4FBCDE25B52@ary.qy> It appears that Dave Horsfall via TUHS said: >Heck; at one time the "true" command was a Shell script with a huge >copyright notice, followed by... nothing... $ /bin/true --version true (GNU coreutils) 8.32 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Jim Meyering. From tuhs at tuhs.org Fri Sep 26 08:06:46 2025 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Thu, 25 Sep 2025 18:06:46 -0400 Subject: [TUHS] copyright maximalism, was History of cal(1)? In-Reply-To: <20250925215320.D4FBCDE25B52@ary.qy> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250925215320.D4FBCDE25B52@ary.qy> Message-ID: Gnu folks are crazy, but Dave was talking about code released by ATT :) From tuhs at tuhs.org Fri Sep 26 08:14:36 2025 From: tuhs at tuhs.org (Steve Nickolas via TUHS) Date: Thu, 25 Sep 2025 18:14:36 -0400 (EDT) Subject: [TUHS] History of cal(1)? In-Reply-To: <20250925210504.mFKm8IKW@steffen%sdaoden.eu> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250925210504.mFKm8IKW@steffen%sdaoden.eu> Message-ID: On Thu, 25 Sep 2025, Steffen Nurpmeso via TUHS wrote: > And today i programmer am still too apprehensive to remove the > complete copyright notice, leaving only the present > > * SPDX-License-Identifier: ISC > > though the Linux kernel (but hey: Linux kernel!) goes that way, as > far as i see. (Likely via a mostly automatized sed(1) run. > It shortens --copyright output to two lines (minimum), in theory. I have a policy of always including the full license terms in every source file if it's a university-style license (e.g., MIT, BSD, UIUC). Better safe than sorry. Often I'll *also* include a license.txt with the same content. But I'm weird like that. -uso. From tuhs at tuhs.org Fri Sep 26 10:10:11 2025 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Thu, 25 Sep 2025 17:10:11 -0700 Subject: [TUHS] copyright maximalism, was History of cal(1)? In-Reply-To: <20250925215320.D4FBCDE25B52@ary.qy> References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> <20250925215320.D4FBCDE25B52@ary.qy> Message-ID: <4a6190eea4d11d3a@orthanc.ca> John Levine via TUHS writes: > $ /bin/true --version > true (GNU coreutils) 8.32 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later l>. [...] Even worse, have you read the source code? :-P I never knew exit(0) could be so hard. --lyndon From tuhs at tuhs.org Fri Sep 26 10:22:58 2025 From: tuhs at tuhs.org (jason-tuhs--- via TUHS) Date: Thu, 25 Sep 2025 17:22:58 -0700 (PDT) Subject: [TUHS] History of cal(1)? In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: > Heck; at one time the "true" command was a Shell script with a huge > copyright notice, followed by... nothing... (The "false" script > actually had "exit 1" at the end.) >From http://web.42.net/true.html ========================================================================== cat /bin/true # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; # All Rights Reserved # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; # The copyright notice above does not evidence any # actual or intended publication of such source code. #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ I'm not sure what I like most. The fact that they're claiming strict copyright on a file that is all comments? The fact that they're up to version 1.6 of all-comments, after five years of development? Or the fact that the GNU version had to be rewritten (due to the above copyright), and thus actually offers three times as much functionality? ========================================================================== -Jason From tuhs at tuhs.org Fri Sep 26 10:36:03 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Thu, 25 Sep 2025 17:36:03 -0700 Subject: [TUHS] NFS at 40 In-Reply-To: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> References: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> Message-ID: <20250926003603.GD25316@mcvoy.com> Does anyone know why Ron Lachman was there? What did he do for NFS? On Wed, Sep 24, 2025 at 09:38:55AM -0700, Al Kossow via TUHS wrote: > https://nfs40.online/ > > this is all pretty cool -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri Sep 26 10:38:44 2025 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 25 Sep 2025 17:38:44 -0700 Subject: [TUHS] NFS at 40 In-Reply-To: <20250926003603.GD25316@mcvoy.com> References: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> <20250926003603.GD25316@mcvoy.com> Message-ID: Lachman provided the reference NFS ports for System V folks, and lots of porting work for various vendors. IIRC. On Thu, Sep 25, 2025 at 5:36 PM Larry McVoy via TUHS wrote: > Does anyone know why Ron Lachman was there? What did he do for NFS? > > On Wed, Sep 24, 2025 at 09:38:55AM -0700, Al Kossow via TUHS wrote: > > https://nfs40.online/ > > > > this is all pretty cool > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Fri Sep 26 12:08:38 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 26 Sep 2025 02:08:38 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: References: Message-ID: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS wrote: > > Heck; at one time the "true" command was a Shell script with a huge > > copyright notice, followed by... nothing... (The "false" script > > actually had "exit 1" at the end.) > > > From http://web.42.net/true.html > > ========================================================================== > cat /bin/true > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > # All Rights Reserved > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > # The copyright notice above does not evidence any > # actual or intended publication of such source code. > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ > > > > I'm not sure what I like most. The fact that they're claiming strict > copyright on a file that is all comments? The fact that they're up to > version 1.6 of all-comments, after five years of development? Or the fact > that the GNU version had to be rewritten (due to the above copyright), and > thus actually offers three times as much functionality? > > ========================================================================== > > > -Jason So assuming the whole text of the program after the copyright statement itself as well as the source control statements is truly AT&T property...does that mean AT&T lays copyright to the empty file? I jest but it is an interesting suggestion. It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright? The files on the disk, sure, but since you can't easily put elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"? Mostly interested in UNIX filesystems on this subject but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF. - Matt G. From tuhs at tuhs.org Fri Sep 26 12:42:34 2025 From: tuhs at tuhs.org (Charles H. Sauer via TUHS) Date: Thu, 25 Sep 2025 21:42:34 -0500 Subject: [TUHS] NFS at 40 In-Reply-To: References: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> <20250926003603.GD25316@mcvoy.com> Message-ID: Yes. Dell SVR4 definitely included Lachman NFS. I booted Dell SVR4 earlier this evening and saw 1987/8/9 Lachman copyright notices. Lachman NFS might have been bundled in SVR4 by USL. For (Dell) SVR3, I’m pretty sure Lachman NFS was separately licensed. Dell SVR3 development was before my time there, so I don’t know for sure. As I think has been previously discussed on TUHS, I was part of IBM licensing NFS directly from Sun to be included on all IBM platforms, not just AIX. For AIX for RS/6000, there would have been no Lachman involvement. I assume that was also the case for AIX/370 & AIX PS/2. I also assume that other large companies, HP, Digital, … would not have used Lachman, but worked directly with the Sun code. Charlie > On Sep 25, 2025, at 7:38 PM, Tom Lyon via TUHS wrote: > > Lachman provided the reference NFS ports for System V folks, and lots of > porting work for various vendors. IIRC. > > On Thu, Sep 25, 2025 at 5:36 PM Larry McVoy via TUHS wrote: > >> Does anyone know why Ron Lachman was there? What did he do for NFS? >> >> On Wed, Sep 24, 2025 at 09:38:55AM -0700, Al Kossow via TUHS wrote: >>> https://nfs40.online/ >>> >>> this is all pretty cool >> >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> -- 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 Fri Sep 26 13:17:45 2025 From: tuhs at tuhs.org (John Levine via TUHS) Date: 25 Sep 2025 23:17:45 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> References: Message-ID: <20250926031746.13199DE30B41@ary.qy> It appears that segaloco via TUHS said: >It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright? The files on the disk, sure, but since you can't easily put >elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"? Mostly interested in UNIX filesystems on this subject >but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF. Copyright notices in the U.S. haven't been needed since we joined Berne in 1989. On the other hand, I think there is a strong argument that the metadata is functional so it's not eligible for copyright, or even if it is, Oracle vs. Google said (rather oversimplifying) copying is OK if it's essential to making something interoperate. R's, John PS: We're pretty deep in the weeds here. From tuhs at tuhs.org Fri Sep 26 13:18:36 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Thu, 25 Sep 2025 21:18:36 -0600 Subject: [TUHS] History of cal(1)? In-Reply-To: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS wrote: > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS < > tuhs at tuhs.org> wrote: > > > > Heck; at one time the "true" command was a Shell script with a huge > > > copyright notice, followed by... nothing... (The "false" script > > > actually had "exit 1" at the end.) > > > > > > From http://web.42.net/true.html > > > > > ========================================================================== > > cat /bin/true > > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > > # All Rights Reserved > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > > # The copyright notice above does not evidence any > > # actual or intended publication of such source code. > > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ > > > > > > > > I'm not sure what I like most. The fact that they're claiming strict > > copyright on a file that is all comments? The fact that they're up to > > version 1.6 of all-comments, after five years of development? Or the fact > > that the GNU version had to be rewritten (due to the above copyright), > and > > thus actually offers three times as much functionality? > > > > > ========================================================================== > > > > > > -Jason > > So assuming the whole text of the program after the copyright statement > itself as well as the source control statements is truly AT&T > property...does that mean AT&T lays copyright to the empty file? I jest > but it is an interesting suggestion. > I think this credits too much intentionality... but you can't copyright nothing, despite the claims here. There's no creative content. Also, we all know this was done by the sed-o-matic on every file without thinking. So from that perspective, it's not additive to nothing... It also brought to mind the question of whether a UNIX superblock for > instance could be placed under copyright? The files on the disk, sure, but > since you can't easily put elaborate license comments at the top of the > filesystem itself, is filesystem metadata inherently "un-copyright-able"? > Mostly interested in UNIX filesystems on this subject but if other systems > or general wisdom prevail in the discussion then that bit can fork to COFF. > Not applicable. The instance of the data and its structure cannot be copyright. It's an idea. The header file that describes it can be copyright. But I can write an equivalent one too (whether or not I saw the original). Not all books about white whales are owned by the estate of Herman Melville... So fs.h can be copyrighted to a degree. All the comments are copyrightable. The data structures enjoy somewhat less copyright protection. The structure names and element names may have some copyright, or may not if the names are important for interop. Some may be common data structures that are too common. You wouldn't know for sure until the end of any litigation. It's the uncertainty that drives people to the maximalist position. I know I won't get in trouble if I never look... Warner - Matt G. > From tuhs at tuhs.org Fri Sep 26 13:32:48 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 26 Sep 2025 03:32:48 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: Sent with Proton Mail secure email. On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS wrote: > On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS < > > tuhs at tuhs.org> wrote: > > > > > > Heck; at one time the "true" command was a Shell script with a huge > > > > copyright notice, followed by... nothing... (The "false" script > > > > actually had "exit 1" at the end.) > > > > > > From http://web.42.net/true.html > > > > ========================================================================== > > > > > cat /bin/true > > > > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > > > # All Rights Reserved > > > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > > > # The copyright notice above does not evidence any > > > # actual or intended publication of such source code. > > > > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ > > > > > > I'm not sure what I like most. The fact that they're claiming strict > > > copyright on a file that is all comments? The fact that they're up to > > > version 1.6 of all-comments, after five years of development? Or the fact > > > that the GNU version had to be rewritten (due to the above copyright), > > > and > > > thus actually offers three times as much functionality? > > > > ========================================================================== > > > > > -Jason > > > > So assuming the whole text of the program after the copyright statement > > itself as well as the source control statements is truly AT&T > > property...does that mean AT&T lays copyright to the empty file? I jest > > but it is an interesting suggestion. > > > I think this credits too much intentionality... but you can't copyright > nothing, despite the claims here. There's no creative content. > > Also, we all know this was done by the sed-o-matic on every file without > thinking. So from that perspective, it's not additive to nothing... > > It also brought to mind the question of whether a UNIX superblock for > > > instance could be placed under copyright? The files on the disk, sure, but > > since you can't easily put elaborate license comments at the top of the > > filesystem itself, is filesystem metadata inherently "un-copyright-able"? > > Mostly interested in UNIX filesystems on this subject but if other systems > > or general wisdom prevail in the discussion then that bit can fork to COFF. > > > Not applicable. The instance of the data and its structure cannot be > copyright. It's an idea. The header file that describes it can be > copyright. But I can write an equivalent one too (whether or not I saw the > original). Not all books about white whales are owned by the estate of > Herman Melville... > > So fs.h can be copyrighted to a degree. All the comments are copyrightable. > The data structures enjoy somewhat less copyright protection. The structure > names and element names may have some copyright, or may not if the names > are important for interop. Some may be common data structures that are too > common. You wouldn't know for sure until the end of any litigation. > > It's the uncertainty that drives people to the maximalist position. I know > I won't get in trouble if I never look... > > Warner > > - Matt G. I meant more along the lines of a specific disk, a physical instance. Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media. Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file. It's a construct more than it is original, intentional content. To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"? - Matt G. From tuhs at tuhs.org Fri Sep 26 13:59:18 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 26 Sep 2025 13:59:18 +1000 Subject: [TUHS] Copyright -> COFF Message-ID: Hi all, I think the copyright discussion has shifted enough that it now belongs over on COFF. Can future replies be directed there?! Thanks, Warren From tuhs at tuhs.org Sat Sep 27 00:26:03 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 26 Sep 2025 10:26:03 -0400 Subject: [TUHS] History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: [Honoring wkt's recent request for this discussion to migrate to COFF, sending TUHS to Bcc] While this discussion moves to COFF, there is a Unix tie-in specifically with respect to the empty-file `true`: Gerard Holzmann wrote a nice article about this several years ago in the "Reliable Code" column of IEEE Software, titled, "Code Inflation". It's not long, and it's a very fun read. Themes he explores may resonate well with the average TUHS reader: https://spinroot.com/gerard/pdf/Code_Inflation.pdf As an aside, the implementation of `true` as an empty file relies on a quirk of `sh` to work: `sh` would try to invoke a program via `exec`, and if that failed, would then try to interpret it as a shell script. Since a zero-byte file is not a valid binary executable for invocation via `exec`, this would fail; the shell would then try to interpret it, do nothing (as there was nothing to do), and exit with its default value (0), indicating success. But a side-effect of this is that one cannot directly `exec` true and expect success; the result is an error. "Why would anyone want to do that, anyway?" Good question; I suspect they wouldn't in the normal case. But I can imagine someone linking `true` to something they expect to succeed to, or specifying it as an argument to something in lieu of another command they didn't want to bother with (perhaps an editor or something). Perhaps `true` should be, `#!/bin/sh` and nothing else, but `exec` support for invoking interpreters via the `#!` syntax came in 4.1BSD, well after zero-byte `/bin/true`. A random thought: some versions of UFS have support for something they call "fast symlinks". Symbolic links, of course, are just files that contain a string naming some other file, and if a pathname has a component naming a symlink when walked by `namei`, that string is substituted for the name of the symlink. But often these names are very short, and recall that the `inode` contains some space for disk block addresses (60 bytes in UFS on 4.1C, but this got bigger in later versions). The idea with fast symlinks is that, if the target file name of a symlink is short enough, the system can just store it in the space that would normally be used for block addresses; there's no need to allocate a separate fragment from a disk block, let alone bear the cost of allocating a buffer and fetching a block from disk, if a short name can be written directly into the inode. I don't think anyone ever gave serious thought to generalizing this facility for very small files, but in principle, one could store their contents in a similar manner (think of all those random little files that just have a pid in them or something). In that case, one wonders what the smallest executable binary implementing `_exit(0)` is. Some folks have played around with hacks and gotten very small files indeed: less than 120 bytes for ELF files, for example, and with a.out, it would have been even smaller. So, it raises the question: could one have written a hyper-size optimized version of `true` that generated a very, very small executable binary that was embedded directly into its inode in the form of one of these hypothetical short files, but still executable? I suspect the answer is "yes". For the record, I don't think this would have any _practical_ utility, and putting effort into such a thing for real work would be about as useful as adding a `--false` flag to `true`. But it would be a neat hack. On Thu, Sep 25, 2025 at 11:32 PM segaloco via TUHS wrote: > On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS wrote: > > On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > > > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS < > > > tuhs at tuhs.org> wrote: > > > > > > > > Heck; at one time the "true" command was a Shell script with a huge > > > > > copyright notice, followed by... nothing... (The "false" script > > > > > actually had "exit 1" at the end.) > > > > > > > > From http://web.42.net/true.html > > > > > > ========================================================================== > > > > > > > cat /bin/true > > > > > > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > > > > # All Rights Reserved > > > > > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > > > > # The copyright notice above does not evidence any > > > > # actual or intended publication of such source code. > > > > > > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ > > > > > > > > I'm not sure what I like most. The fact that they're claiming strict > > > > copyright on a file that is all comments? The fact that they're up to > > > > version 1.6 of all-comments, after five years of development? Or the fact > > > > that the GNU version had to be rewritten (due to the above copyright), > > > > and > > > > thus actually offers three times as much functionality? > > > > > > ========================================================================== > > > > > > > -Jason > > > > > > So assuming the whole text of the program after the copyright statement > > > itself as well as the source control statements is truly AT&T > > > property...does that mean AT&T lays copyright to the empty file? I jest > > > but it is an interesting suggestion. > > > > I think this credits too much intentionality... but you can't copyright > > nothing, despite the claims here. There's no creative content. > > > > Also, we all know this was done by the sed-o-matic on every file without > > thinking. So from that perspective, it's not additive to nothing... I suspect the answer to the original question is "no", as it's really copyrighting nothing, and ... what would that mean? Can I claim copyright over the empty set in mathematics? Surely there must be a thing in order to claim copyright over that thing; copyrighting the absence of a thing makes no sense, and we're back to this notion that you can't copyright an idea. This feels like one of those weird "physical reality meets the law" things, like trying to pass a law banning meteor showers or something goofy like that. > I meant more along the lines of a specific disk, a physical instance. Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media. Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file. It's a construct more than it is original, intentional content. To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"? Huh. I don't know about a superblock, but it seems unlikely: a superblock changes all the time during the course of normal operation. To what would the copyright apply, other than the SB's state at a specific instance in time? How is that different than, say, trying to copyright the position of a flywheel in some mechanical engine at a specific moment in time? But it is an interesting question. IIRC Oracle's licensing terms for its database product are sort of weird in this regard: they license for a physical processor, and this has given folks all sorts of headaches when considering virtualized environments. A question that has been raised is whether it's a violation of the licensing terms to migrate the VM running an instance of Oracle to a separate physical machine, or even snapshot the VM's (memory) state and write it to a separate machine, then copy it back and resume it (even if the snapshot doesn't run). Questions like that make me glad I'm not a lawyer. - Dan C. From tuhs at tuhs.org Sat Sep 27 01:19:35 2025 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Fri, 26 Sep 2025 11:19:35 -0400 Subject: [TUHS] NFS at 40 In-Reply-To: (tuhs@tuhs.org) Message-ID: "Charles H. Sauer via TUHS" writes: > Yes. Dell SVR4 definitely included Lachman NFS. I booted Dell SVR4 earlier this evening and saw 1987/8/9 Lachman copyright notices. Lachman NFS might have been bundled in SVR4 by USL. > > For (Dell) SVR3, I’m pretty sure Lachman NFS was separately licensed. Dell SVR3 development was before my time there, so I don’t know for sure. > > As I think has been previously discussed on TUHS, I was part of IBM licensing NFS directly from Sun to be included on all IBM platforms, not just AIX. For AIX for RS/6000, there would have been no Lachman involvement. I assume that was also the case for AIX/370 & AIX PS/2. > > I also assume that other large companies, HP, Digital, … would not have used Lachman, but worked directly with the Sun code. A long time ago when I was working at AT&T in one of the software development groups we used a Vax running SVR3.0 and later SVR3.1 from DEC as our software platform. I worked with a coworker who did the systems programming and such for the platform and in our talks it came out that the IP stack in that SVR3.x on the Vax was from Lachman ported in by DEC. DEC tossed out the code base, whatever might have existed, that AT&T provided with the source reference for doing IP related stuff. This would have been in the 1990s. The coworker seemed to indicate that the Lachman code performed better and/or had all of the parts that one might expect in a IP stack that were missing in the AT&T version. We didn't run NFS on the Vax. > Charlie > >> On Sep 25, 2025, at 7:38 PM, Tom Lyon via TUHS wrote: >> >> Lachman provided the reference NFS ports for System V folks, and lots of >> porting work for various vendors. IIRC. >> >> On Thu, Sep 25, 2025 at 5:36 PM Larry McVoy via TUHS wrote: >> >>> Does anyone know why Ron Lachman was there? What did he do for NFS? >>> >>> On Wed, Sep 24, 2025 at 09:38:55AM -0700, Al Kossow via TUHS wrote: >>>> https://nfs40.online/ >>>> >>>> this is all pretty cool >>> >>> -- >>> --- >>> Larry McVoy Retired to fishing >>> http://www.mcvoy.com/lm/boat >>> > > -- > 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 -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Sat Sep 27 01:26:55 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 26 Sep 2025 11:26:55 -0400 Subject: [TUHS] NFS at 40 In-Reply-To: References: Message-ID: On Fri, Sep 26, 2025 at 11:20 AM Brad Spencer via TUHS wrote: > "Charles H. Sauer via TUHS" writes: > .... it came > out that the IP stack in that SVR3.x on the Vax was from Lachman ported > in by DEC. DEC tossed out the code base, whatever might have existed, > that AT&T provided with the source reference for doing IP related stuff. > This would have been in the 1990s. The coworker seemed to indicate that > the Lachman code performed better and/or had all of the parts that one > might expect in a IP stack that were missing in the AT&T version. > IIRC, the issue was System V's Streams (TLI) vs. UCB's Sockets. Most of the code for IP/TCP, particularly UNIX-based, wanted "pure-joy" and hacking the code to TLI was too much trouble. From tuhs at tuhs.org Sat Sep 27 01:41:32 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 26 Sep 2025 08:41:32 -0700 Subject: [TUHS] NFS at 40 In-Reply-To: References: Message-ID: <20250926154132.GH25316@mcvoy.com> On Fri, Sep 26, 2025 at 11:26:55AM -0400, Clem Cole via TUHS wrote: > On Fri, Sep 26, 2025 at 11:20???AM Brad Spencer via TUHS > wrote: > > > "Charles H. Sauer via TUHS" writes: > > .... it came > > out that the IP stack in that SVR3.x on the Vax was from Lachman ported > > in by DEC. DEC tossed out the code base, whatever might have existed, > > that AT&T provided with the source reference for doing IP related stuff. > > This would have been in the 1990s. The coworker seemed to indicate that > > the Lachman code performed better and/or had all of the parts that one > > might expect in a IP stack that were missing in the AT&T version. > > > IIRC, the issue was System V's Streams (TLI) vs. UCB's Sockets. Most of > the code for IP/TCP, particularly UNIX-based, wanted "pure-joy" and hacking > the code to TLI was too much trouble. Lachman's stuff came from Convergent, they wrote the STREAMS based TCP/IP stack (I know, I ported it to SVR3 for the ETA-10 project, and then again to SCO Unix which was maybe V7 based? It was pretty primitive. Might have been SVR3 or R2). STREAMS just sucked, way more overhead than UCB's sockets. I've never been a huge fan of the UI of sockets, it's clunky, but it was a lot better than the STREAMS layering. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat Sep 27 02:07:47 2025 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Fri, 26 Sep 2025 12:07:47 -0400 Subject: [TUHS] NFS at 40 In-Reply-To: (message from Clem Cole on Fri, 26 Sep 2025 11:26:55 -0400) Message-ID: Clem Cole writes: > On Fri, Sep 26, 2025 at 11:20 AM Brad Spencer via TUHS > wrote: > >> "Charles H. Sauer via TUHS" writes: >> .... it came >> out that the IP stack in that SVR3.x on the Vax was from Lachman ported >> in by DEC. DEC tossed out the code base, whatever might have existed, >> that AT&T provided with the source reference for doing IP related stuff. >> This would have been in the 1990s. The coworker seemed to indicate that >> the Lachman code performed better and/or had all of the parts that one >> might expect in a IP stack that were missing in the AT&T version. >> > IIRC, the issue was System V's Streams (TLI) vs. UCB's Sockets. Most of > the code for IP/TCP, particularly UNIX-based, wanted "pure-joy" and hacking > the code to TLI was too much trouble. Yes, that does tickle some memory cells and was probably one of the main reasons for the use of the Lachman code. The project would certainly have wanted the socket API. It has been a long time ago, however, and I didn't probe my coworker at the time for more details. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Sat Sep 27 02:14:43 2025 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Fri, 26 Sep 2025 12:14:43 -0400 Subject: [TUHS] NFS at 40 In-Reply-To: <20250926154132.GH25316@mcvoy.com> (message from Larry McVoy on Fri, 26 Sep 2025 08:41:32 -0700) Message-ID: Larry McVoy writes: > On Fri, Sep 26, 2025 at 11:26:55AM -0400, Clem Cole via TUHS wrote: >> On Fri, Sep 26, 2025 at 11:20???AM Brad Spencer via TUHS >> wrote: >> >> > "Charles H. Sauer via TUHS" writes: >> > .... it came >> > out that the IP stack in that SVR3.x on the Vax was from Lachman ported >> > in by DEC. DEC tossed out the code base, whatever might have existed, >> > that AT&T provided with the source reference for doing IP related stuff. >> > This would have been in the 1990s. The coworker seemed to indicate that >> > the Lachman code performed better and/or had all of the parts that one >> > might expect in a IP stack that were missing in the AT&T version. >> > >> IIRC, the issue was System V's Streams (TLI) vs. UCB's Sockets. Most of >> the code for IP/TCP, particularly UNIX-based, wanted "pure-joy" and hacking >> the code to TLI was too much trouble. > > Lachman's stuff came from Convergent, they wrote the STREAMS based TCP/IP > stack (I know, I ported it to SVR3 for the ETA-10 project, and then again > to SCO Unix which was maybe V7 based? It was pretty primitive. Might > have been SVR3 or R2). > > STREAMS just sucked, way more overhead than UCB's sockets. I've never > been a huge fan of the UI of sockets, it's clunky, but it was a lot better > than the STREAMS layering. I never saw the SVR3.x that may have used STREAMS, but my coworker did (assuming my memory is correct) and he may have indicated in our conversations that it performed rather badly (that very much rings a bell). The software group we were a part of was pretty well off and I know that we experimented with different platforms from time to time for the product and he may have had some experience with one of the experiments. The product was huge and complicated and more or less ate and entire computer to do its job, be it a Vax or later an HP. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Sat Sep 27 02:32:36 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 26 Sep 2025 09:32:36 -0700 Subject: [TUHS] NFS at 40 In-Reply-To: References: <20250926154132.GH25316@mcvoy.com> Message-ID: <20250926163236.GL25316@mcvoy.com> On Fri, Sep 26, 2025 at 12:14:43PM -0400, Brad Spencer wrote: > Larry McVoy writes: > > > On Fri, Sep 26, 2025 at 11:26:55AM -0400, Clem Cole via TUHS wrote: > >> On Fri, Sep 26, 2025 at 11:20???AM Brad Spencer via TUHS > >> wrote: > >> > >> > "Charles H. Sauer via TUHS" writes: > >> > .... it came > >> > out that the IP stack in that SVR3.x on the Vax was from Lachman ported > >> > in by DEC. DEC tossed out the code base, whatever might have existed, > >> > that AT&T provided with the source reference for doing IP related stuff. > >> > This would have been in the 1990s. The coworker seemed to indicate that > >> > the Lachman code performed better and/or had all of the parts that one > >> > might expect in a IP stack that were missing in the AT&T version. > >> > > >> IIRC, the issue was System V's Streams (TLI) vs. UCB's Sockets. Most of > >> the code for IP/TCP, particularly UNIX-based, wanted "pure-joy" and hacking > >> the code to TLI was too much trouble. > > > > Lachman's stuff came from Convergent, they wrote the STREAMS based TCP/IP > > stack (I know, I ported it to SVR3 for the ETA-10 project, and then again > > to SCO Unix which was maybe V7 based? It was pretty primitive. Might > > have been SVR3 or R2). > > > > STREAMS just sucked, way more overhead than UCB's sockets. I've never > > been a huge fan of the UI of sockets, it's clunky, but it was a lot better > > than the STREAMS layering. > > I never saw the SVR3.x that may have used STREAMS, but my coworker did > (assuming my memory is correct) and he may have indicated in our > conversations that it performed rather badly (that very much rings a > bell). The software group we were a part of was pretty well off and I > know that we experimented with different platforms from time to time for > the product and he may have had some experience with one of the > experiments. The product was huge and complicated and more or less ate > and entire computer to do its job, be it a Vax or later an HP. You could make it perform better if you tuned resources. The defaults for STREAMS were more appropriate for ttys than networking. I wrote, and published on comp.sources.unix (I think) something I called "sw" for "STREAMS watch". It was sort of like top(1) if I remember correctly (this was about 38 years ago) and displayed how much of each resource was used. I used this to tune things up to get pretty close to 10Mbit/sec out of some crappy 3com card on SCO. I googled a bit to see if I could find sw and couldn't but I have a copy so I stuck it here: http://mcvoy.com/lm/sw.shar if anyone still has to deal with STREAMS (can't imagine that is true but whatever). My apologies for the C style, I hadn't yet adopted Sun's coding style. --lm From tuhs at tuhs.org Sat Sep 27 03:23:48 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 26 Sep 2025 17:23:48 +0000 Subject: [TUHS] History of cal(1)? In-Reply-To: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: You can claim copyright for the C code that defines the superblock (i.e., the header), but the layout of the superblock itself is not something that can be protected by copyright. ------ Original Message ------ >From "segaloco via TUHS" To "The Eunuchs Hysterical Society" Date 9/25/2025 10:08:38 PM Subject [TUHS] Re: History of cal(1)? >On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS wrote: > >> > Heck; at one time the "true" command was a Shell script with a huge >> > copyright notice, followed by... nothing... (The "false" script >> > actually had "exit 1" at the end.) >> >> >> From http://web.42.net/true.html >> >> ========================================================================== >> cat /bin/true >> >> # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; >> # All Rights Reserved >> >> # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; >> # The copyright notice above does not evidence any >> # actual or intended publication of such source code. >> >> #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ >> >> >> >> I'm not sure what I like most. The fact that they're claiming strict >> copyright on a file that is all comments? The fact that they're up to >> version 1.6 of all-comments, after five years of development? Or the fact >> that the GNU version had to be rewritten (due to the above copyright), and >> thus actually offers three times as much functionality? >> >> ========================================================================== >> >> >> -Jason > >So assuming the whole text of the program after the copyright statement itself as well as the source control statements is truly AT&T property...does that mean AT&T lays copyright to the empty file? I jest but it is an interesting suggestion. > >It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright? The files on the disk, sure, but since you can't easily put elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"? Mostly interested in UNIX filesystems on this subject but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF. > >- Matt G. From tuhs at tuhs.org Sat Sep 27 08:14:07 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 27 Sep 2025 08:14:07 +1000 Subject: [TUHS] DWB troff and man(7) history question Message-ID: All, this message from G. Branden Robinson who is having trouble getting it through to the list. ----- Forwarded message from "G. Branden Robinson" ----- Does anyone know if DWB 2.0 (~1984) supported the `lq` and `rq` strings in its man(7) package? In DWB 3.3 (1993), they are easily found. https://github.com/n-t-roff/DWB3.3/blob/562bb8615116f46077ca03e8561323cc7a89673e/macros/man/an.sr#L30 But that's after Unix System V (1988), which finally made the decision to adopt these string definitions from 4BSD (1980). Regards, Branden ----- End forwarded message ----- From tuhs at tuhs.org Sat Sep 27 08:28:11 2025 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Fri, 26 Sep 2025 15:28:11 -0700 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: <760E225E-C2E8-4783-9833-57459EF6492D@humeweb.com> gre was written by me, although these days, i use a local link to grep. ken’s comment below is likely true now, but at the time gre was written, it was not true. boyer-moore filtering, as i called it, made a substantial difference. in fact, it saved (in a documented way) millions of dollars per year in the 5ESS programming project (during the mid to late 1980s). it is, of course, dependent on the string being searched for, but once that string had a literal substring of length 4 or more, it definitively sped things up. it all depends on the relative speed of CPU versus I/O efficiency. i also published a paper on this in “Software Practice and Experience” with Dan Sunday. > On Sep 23, 2025, at 10:40 AM, Ken Thompson via TUHS wrote: > > i think the plan9 grep is the fastest. > it is grep, egrep, fgrep also. > i think it is faster than boyer-moore. > the whole program is a jit dfa > > read block > for c in block > { > s=s.state[c] > if s == nil do something occasionally > } > > it is a very few cycles per byte. all of the > time is reading a block. i cant imagine b/m > could be faster. the best b/m could do is > calculate the skip and then jump over > bytes that you have already read. > > > russ cox used it to do the (now defunct) code > search in google. > > > On Tue, Sep 23, 2025 at 5:14 AM Don Caldwell via TUHS wrote: > >> It was definitely Andrew Hume. While at Shannon Labs, he was promoting and >> using it for some of his projects. >> >> On Tue, Sep 23, 2025 at 12:59 AM Noel Hunt via TUHS wrote: >> >>> I will tentatively suggest that it was Andrew Hume. I suspect >>> his major contribution was the addition of Boyer-Moore. >>> >>> >>> On Tue, 23 Sept 2025 at 04:38, Thalia Archibald via TUHS >>> wrote: >>> >>>> Spurred by the discussion on regular expressions in the Forth thread: >>>> >>>> Unix V10 included a command named gre, which aimed to succeed grep, >>> egrep, >>>> and >>>> fgrep. >>>> >>>> Does anyone know anything about it? Who wrote it? Was it used anywhere >> or >>>> succeeded by anything? Was it connected to Plan 9 or Inferno? >>>> >>>> From its man page: >>>>> Gre supplants three classic programs, which are still available: >>>>> Grep handles only ed(1)-like regular expressions. It uses \(\) >> instead >>>> of (). >>>>> Egrep handles the same patterns as gre except for back-referencing >> with >>>> \1, \2, ... >>>>> Fgrep handles no operators except newline (alternation). >>>> >>>> https://www.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/gre >>>> https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/gre.1 >>>> >>>> Thanks, >>>> Thalia Archibald >>>> >>> >> From tuhs at tuhs.org Sat Sep 27 09:01:38 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Fri, 26 Sep 2025 16:01:38 -0700 Subject: [TUHS] true command (was:History of cal(1)?) In-Reply-To: References: <20250919160357.GI416742@mit.edu> <20250919182131.GA468508@mit.edu> Message-ID: On 9/25/25 17:22, jason-tuhs--- via TUHS wrote: > >> Heck; at one time the "true" command was a Shell script with a huge copyright >> notice, followed by... nothing...  (The "false" script actually had "exit 1" >> at the end.) > > From http://web.42.net/true.html > > ========================================================================== > cat /bin/true > > #     Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > #       All Rights Reserved > > #     THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > #     The copyright notice above does not evidence any > #     actual or intended publication of such source code. > > #ident  "@(#)true.sh    1.6     93/01/11 SMI"   /* SVr4.0 1.4   */ > > > > I'm not sure what I like most.  The fact that they're claiming strict > copyright on a file that is all comments?  The fact that they're up to > version 1.6 of all-comments, after five years of development?  Or the fact > that the GNU version had to be rewritten (due to the above copyright), and > thus actually offers three times as much functionality? The ident line containing SMI indicates that the revision information comes from the Solaris source control system ("SMI" == "Sun Microsystems, Inc."). The "SVr4.0 1.4" comment at the end points to the revision of the file from AT&T's SVR4 source control system. Looking in our internal archives of the SCCS trees, Solaris 2.0 (the first SVR4 based release) had revision 1.3 of usr/src/cmd/true/true.sh, Solaris 2.1 updated it to revision 1.5, and Solaris 2.2 through 9 shipped the above mentioned revision 1.6. Version 1.3 added '#!/sbin/sh' and Version 1.6 changed to '#!/usr/bin/sh' -- all the other revisions were just syncing copyright info from AT&T or futzing with the format of the #ident lines. (The change from /sbin to /usr/sbin is recorded as avoiding warning messages when run in a non-C locale, since the statically linked shell in /sbin only supported the C locale and complained if you tried to run it in any other locale.) Solaris 10 replaced it with a C implementation to avoid shell startup overhead (including time wasted by the shell parser reading and discarding all the comment lines in the shell script). Personally, I still think the OpenSolaris clear command wins in terms of comment lines to functionality: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/clear/clear.sh -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Sat Sep 27 13:43:36 2025 From: tuhs at tuhs.org (Matt Day via TUHS) Date: Fri, 26 Sep 2025 21:43:36 -0600 Subject: [TUHS] NFS at 40 In-Reply-To: References: <262d3405-890a-3c39-0059-4f935f226123@bitsavers.org> <20250926003603.GD25316@mcvoy.com> Message-ID: You're right, according to Russel Sandberg's 1986 paper, "The Sun Network Filesystem: Design, Implementation and Experience": "The System V.2 port [of NFS] was done in a joint effort by Lachman Associates and The Instruction Set on a VAX 750. In order to avoid having to port the Berkeley networking code to the System V kernel an Excelan board was used. The Excelan board handles the ethernet, IP, and UDP layers. A new RPC transport layer had to be implemented to interface to the Excelan board. Adding the vnode/VFS interface to the System V kernel was the hardest part of the port." -- https://nfs40.online/wp-content/uploads/2025/08/rusty-nfs-revised.pdf A couple other paragraphs that caught my eye in Rusty's paper: "The port to the IBM PC, done by Geoff Arnold and Kim Kinnear at Sun, was complicated by the need to add a “redirector” layer to MS/DOS to catch system calls and redirect them. An implementation of UDP/IP also had to be added before RPC could be ported. The NFS client side implementation is written in assembler and occupies about 40K bytes of space. Currently, remote read operations are faster than a local hard disk access but remote write operations are slower. Over all, performance is about the same for remote and local access." "At the UniForum conference in February 1986, all of the completed NFS ports were demonstrated. There were 16 different vendors and five different operating systems all sharing files over an ethernet." "There were many people throughout Sun who were involved in the NFS development effort. Bob Lyon led the NFS group and helped with protocol issues, Steve Kleiman implemented the filesystem interface in the kernel from Bill Joy’s original design, Russel Sandberg ported RPC to the kernel and implemented the NFS virtual filesystem, Tom Lyon designed the protocol and provided far sighted inputs into the overall design, David Goldberg worked on many user level programs, Paul Weiss implemented the Yellow Pages, and Dan Walsh is the one to thank for the performance of NFS. The NFS consulting group, headed by Steve Isaac, has done an amazing job of getting NFS out to the world." On Thu, Sep 25, 2025 at 6:39 PM Tom Lyon via TUHS wrote: > Lachman provided the reference NFS ports for System V folks, and lots of > porting work for various vendors. IIRC. > > On Thu, Sep 25, 2025 at 5:36 PM Larry McVoy via TUHS > wrote: > > > Does anyone know why Ron Lachman was there? What did he do for NFS? > > > > On Wed, Sep 24, 2025 at 09:38:55AM -0700, Al Kossow via TUHS wrote: > > > https://nfs40.online/ > > > > > > this is all pretty cool > > > > -- > > --- > > Larry McVoy Retired to fishing > > http://www.mcvoy.com/lm/boat > > >