From tuhs at tuhs.org Wed Oct 1 01:22:18 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 30 Sep 2025 15:22:18 +0000 Subject: [TUHS] Interesting MIT links In-Reply-To: <735ea170-d408-73e5-9307-067e5d4ed53b@bitsavers.org> (Al Kossow via TUHS's message of "Mon, 29 Sep 2025 11:19:59 -0700") References: <7wikh15g5b.fsf@junk.nocrew.org> <735ea170-d408-73e5-9307-067e5d4ed53b@bitsavers.org> Message-ID: <7w7bxg3qz9.fsf@junk.nocrew.org> Al Kossow wrote: > Did all the file recovery documents (like the system names) make it > into what the MIT Archives have, or just the tape images? I didn't seem. Often I had to infer which system a tape came from from its contents. Some tapes have photos of the label. > There are problems with the images as well, like John Bordynuik > inventing his own .tap format with bad blocks handled differently, all > undocumented... I have seen many variants in there, such as little or big endian record size, records padded to 16 bits or not. Some records have frames dropped from the beginning or the end. Also old ITS backup tapes were transferred from low density tapes to a fewer number of high density tapes in the 80s, so sometimes same file appear in multiple savesets on a single tape. From tuhs at tuhs.org Wed Oct 1 01:29:48 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 30 Sep 2025 15:29:48 +0000 Subject: [TUHS] Interesting MIT links In-Reply-To: (Rich Salz via TUHS's message of "Mon, 29 Sep 2025 11:57:06 -0400") References: Message-ID: <7w34843qmr.fsf@junk.nocrew.org> Rich Salz wrote: > There *must* be Unix stuff in the MIT collection. One unusual thing I found was a copy of Harris HCX/UX. It's their Unix port for the "Tahoe" architecture; you know as in 4.3BSD-Tahoe. I don't know what to do about this. From tuhs at tuhs.org Wed Oct 1 08:55:14 2025 From: tuhs at tuhs.org (jslee via TUHS) Date: Wed, 01 Oct 2025 08:55:14 +1000 Subject: [TUHS] Interesting MIT links In-Reply-To: <7w34843qmr.fsf@junk.nocrew.org> References: <7w34843qmr.fsf@junk.nocrew.org> Message-ID: <5a5b2deb-bf64-4695-bd55-f7cc88ebf17b@app.fastmail.com> Hi, On Wed, 1 Oct 2025, at 01:29, Lars Brinkhoff via TUHS wrote: > Rich Salz wrote: >> There *must* be Unix stuff in the MIT collection. > > One unusual thing I found was a copy of Harris HCX/UX. I had never heard of the Harris before today. I’d heard of BSD Tahoe (I think Rich Stevens may have mentioned it in one of his books? Or maybe I just saw it in a family tree…) but not the machine Anyway mainly posting as after some googling I found this blogue poste: https://virtuallyfun.com/2017/02/24/the-harris-hcx-9-aka-tahoe-platform/ One commenter mentions that Dayton University also had one of these machines. John From tuhs at tuhs.org Fri Oct 3 11:33:25 2025 From: tuhs at tuhs.org (christopher fujino via TUHS) Date: Thu, 2 Oct 2025 18:33:25 -0700 Subject: [TUHS] The origins of portability in C Message-ID: I have often read things like, "`int`s in C are of unfixed size so that Unix could be ported." So I was surprised to read in Dennis Ritchie's "The Development of the C Language" that: PL/I, the implementation language of Multics, was not much to our > tastes, but we were also using other languages, including BCPL, and we > regretted losing the > advantages of writing programs in a language above the level of assembler, > such as ease of writ- > ing and clarity of understanding. At the time we did not put much weight > on portability; interest > in this arose later. > Brian Kernighan quotes Steve Johnson in "Unix: A History and a Memoir": There was another pressure to make Unix portable. A number of DEC's > competitors were beginning to grumble that regulated AT&T had too cozy a > relationship with DEC. We pointed out that there were no other machines > like the PDP-11 on the market, but this argument was getting weaker. > Dennis hooked me into the portability effort with one sentence: 'I think > that it would be easier to move Unix to another piece of hardware than to > rewrite an application to run under a different operating system.' I was > all in from that point on. A few questions: 1. Was Johnson's Portable C Compiler developed explicitly to port Unix, or was it already around? 2. And if it was already around, what was the initial motivation for creating a portable C compiler? 3. Am I right to assume that prior to the Portable C Compiler, C's primitives were thought of as PDP-11 specific? Thanks! Chris From tuhs at tuhs.org Fri Oct 3 11:52:00 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Fri, 3 Oct 2025 11:52:00 +1000 Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: It was done for the port to the Interdata. To answer question 3, I often heard (and early on, believed) that things like *p++ were invented for the addressing modes on the PDP-11, but was told by Ken and Dennis that they were not original. -rob On Fri, Oct 3, 2025 at 11:34 AM christopher fujino via TUHS wrote: > I have often read things like, "`int`s in C are of unfixed size so that > Unix could be ported." So I was surprised to read in Dennis Ritchie's "The > Development of the C Language" that: > > PL/I, the implementation language of Multics, was not much to our > > tastes, but we were also using other languages, including BCPL, and we > > regretted losing the > > advantages of writing programs in a language above the level of > assembler, > > such as ease of writ- > > ing and clarity of understanding. At the time we did not put much weight > > on portability; interest > > in this arose later. > > > > Brian Kernighan quotes Steve Johnson in "Unix: A History and a Memoir": > > There was another pressure to make Unix portable. A number of DEC's > > competitors were beginning to grumble that regulated AT&T had too cozy a > > relationship with DEC. We pointed out that there were no other machines > > like the PDP-11 on the market, but this argument was getting weaker. > > Dennis hooked me into the portability effort with one sentence: 'I think > > that it would be easier to move Unix to another piece of hardware than to > > rewrite an application to run under a different operating system.' I was > > all in from that point on. > > > A few questions: > > 1. Was Johnson's Portable C Compiler developed explicitly to port Unix, or > was it already around? > 2. And if it was already around, what was the initial motivation for > creating a portable C compiler? > 3. Am I right to assume that prior to the Portable C Compiler, C's > primitives were thought of as PDP-11 specific? > > Thanks! > > Chris > From tuhs at tuhs.org Fri Oct 3 13:02:47 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Fri, 3 Oct 2025 13:02:47 +1000 (EST) Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025, Rob Pike via TUHS wrote: > It was done for the port to the Interdata. To answer question 3, I often > heard (and early on, believed) that things like *p++ were invented for > the addressing modes on the PDP-11, but was told by Ken and Dennis that > they were not original. I believe the same thing was said about the SOB instruction too. -- Dave From tuhs at tuhs.org Fri Oct 3 14:30:53 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Thu, 2 Oct 2025 21:30:53 -0700 Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: if an instruction named SOB had not existed, it would have been necessary to create one. On Thu, Oct 2, 2025 at 8:14 PM Dave Horsfall via TUHS wrote: > On Fri, 3 Oct 2025, Rob Pike via TUHS wrote: > > > It was done for the port to the Interdata. To answer question 3, I often > > heard (and early on, believed) that things like *p++ were invented for > > the addressing modes on the PDP-11, but was told by Ken and Dennis that > > they were not original. > > I believe the same thing was said about the SOB instruction too. > > -- Dave > From tuhs at tuhs.org Sat Oct 4 00:12:01 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Fri, 3 Oct 2025 10:12:01 -0400 Subject: [TUHS] The origins of portability in C External Inbox Forums Message-ID: Portability of Fortran code was a major theme at Bell Labs. Phyllis Fox oversaw the creation of the Port library of numerical software, which became publicly available upon the advent of the internet. Before the Port library, Stan Brown, Barbara Rider, and Andy Hall had been central to an ambitious portability effort for Altran, a symbolic-algebra language. They identified Pfort, a subset of Fortran that was portable except for issues of data representation. In particular, Altran implemented multiple-precision integers. A verifier to assure that Fortran code complied with Pfort was written in Pfort. The M6 macroprocessor, also written in Pfort, was created to deal with adjusting Fortran code that depended on word size or character code. The Altran compiler itself was written in Pfort tailored by a set of M6 definitions for each machine architecture. Of course making C portable was a bigger deal than doing it for Altran. C had to compile to different instruction sets, while Altran always compiled to Pfort. But the Altran portability effort certainly fed into the C project, particularly via Steve Johnson, who worked on both. One notable congruence is their use of macro preprocessors. Doug From tuhs at tuhs.org Sun Oct 5 06:38:00 2025 From: tuhs at tuhs.org (David Barto via TUHS) Date: Sat, 4 Oct 2025 13:38:00 -0700 Subject: [TUHS] inode - does it have a meaning? Message-ID: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> In a blog post today I read: In most modern file systems, those data structures are known as inodes, and their numbers are inode numbers, sometimes shortened to inodes. The term is thought to be a contraction of index node, which certainly makes sense, but is lost in the mists of time. This was written by a fellow who is reasonably smart and knows his way around things MacOS, though not things UNIX. So before I go and tell him that inode really does mean ‘index node’, I’m checking here to clear the “mists of time.” I’ve always understood it to be a shortening of ‘index node’. Wikipedia (https://en.wikipedia.org/wiki/Inode) says There has been uncertainty on the Linux kernel mailing list about the reason for the "i" in "inode". In 2002, the question was brought to Unix pioneer Dennis Ritchie, who replied:[4] In truth, I don't know either. It was just a term that we started to use. "Index" is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the i-number is an index in this array, the i-node is the selected element of the array. (The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.) Further the Wikipedia article states that Bach says that the word ‘inode’ is a contraction of the term index node. So is there a ‘definitive’ answer for this, or is it really lost in the mists of time? David Men always learn from their mistakes how to make new ones. A.J.P. Taylor David Barto barto at kdbarto.org From tuhs at tuhs.org Sun Oct 5 07:15:28 2025 From: tuhs at tuhs.org (Jim Mellander via TUHS) Date: Sat, 4 Oct 2025 14:15:28 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 Message-ID: Hi all: I had the occasion to use the PDP-11/70 on the ground floor of Cory Hall. I was not a student, but was in the Navy stationed at Treasure Island, but groked Unix & visited there on my time off to tinker, among other things. I always have wondered who were the long hairs who were working inside the glass partition on the system. Also, I played with a PDP-11/45 in Evans Hall. I'm interested in any information anyone has about those times and places. Thanks in advance, Jim Mellander From tuhs at tuhs.org Sun Oct 5 07:57:15 2025 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sun, 5 Oct 2025 08:57:15 +1100 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: <0BD89802-685A-4416-9527-5CF39F0274B6@canb.auug.org.au> In 1989, Ken was interviewed by Mike Mahoney of Princeton, as part of the “Unix Oral History Project”. It seems ‘inode’ was being used from 1969 when Ken & Dennis were doing design, with Rudd Canaday in his office. ====================== Princeton have removed the original site. Copes can be found at: An edited summary by Mahoney: ====================== Ken’s Interview of "9-6-89" Thompson: Yeah. I was doing it on the 635 at the time. Yeah . I got these exponential curves where before it would get into trouble it would go way out and get lots and lots of simultaneous accesses going… I was playing with a disk sorting algorithms and caching algorithms at the time. All of those actually went into UNIX. Um. MSM: This would be the research aspect of the work? Thompson: Yeah. Then in the actual design. At that point, it just went to… There was a model of a user and a model of this, and they generated activities, and the activity went into the disks that were sorted and things like that. Um, um. It was never down to a design to the point of where you put the addresses, how you expand files and things like that. It was never down to that level. It was always at some higher level. I think it was just like one or two meetings, Dennis and Canaday and myself. Was just discussing these ideas of the general nature of keeping the files out of each other's hair and the nitty-gritty of expanding. Of the real implementation, where you put the block addresses, where you put this and this. I remember, um, we did it in Canaday's office. At the end of this discussion Canaday picked up the phone, and there was a new service in Bell Laboratories, dictation, where you call up essentially a tape recorder and you give notes, and then the next morning notes are typed and sent to you. The next day, these notes came back and the acronyms were butchered, like "inode" was "eyen" (Laughing). ====================== > On 5 Oct 2025, at 07:38, David Barto via TUHS wrote: > > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. > > This was written by a fellow who is reasonably smart and knows > his way around things MacOS, though not things UNIX. So before > I go and tell him that inode really does mean ‘index node’, I’m > checking here to clear the “mists of time.” > > I’ve always understood it to be a shortening of ‘index node’. > > Wikipedia (https://en.wikipedia.org/wiki/Inode) says > > There has been uncertainty on the Linux kernel mailing list > about the reason for the "i" in "inode". In 2002, the question > was brought to Unix pioneer Dennis Ritchie, who replied:[4] > > In truth, I don't know either. It was just a term that we > started to use. "Index" is my best guess, because of the > slightly unusual file system structure that stored the > access information of files as a flat array on the disk, > with all the hierarchical directory information living > aside from this. Thus the i-number is an index in this array, > the i-node is the selected element of the array. > (The "i-" notation was used in the 1st edition manual; > its hyphen was gradually dropped.) > > Further the Wikipedia article states that Bach says that the word ‘inode’ > is a contraction of the term index node. > > So is there a ‘definitive’ answer for this, or is it really lost in > the mists of time? > > David > > Men always learn from their mistakes how to make new ones. > A.J.P. Taylor > > David Barto > barto at kdbarto.org > > > -- 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 Oct 5 08:54:30 2025 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Sun, 05 Oct 2025 00:54:30 +0200 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: <20251004225430.mp_rFBJr@steffen%sdaoden.eu> David Barto via TUHS wrote in <143E170E-F64F-4AEE-83B1-BAB134267099 at kdbarto.org>: |In a blog post today I read: | | In most modern file systems, those data structures are | known as inodes, and their numbers are inode numbers, | sometimes shortened to inodes. The term is thought | to be a contraction of index node, which certainly | makes sense, but is lost in the mists of time. | |This was written by a fellow who is reasonably smart and knows |his way around things MacOS, though not things UNIX. So before |I go and tell him that inode really does mean ‘index node’, I’m |checking here to clear the “mists of time.” | |I’ve always understood it to be a shortening of ‘index node’. | |Wikipedia (https://en.wikipedia.org/wiki/Inode) says | | There has been uncertainty on the Linux kernel mailing list | about the reason for the "i" in "inode". In 2002, the question | was brought to Unix pioneer Dennis Ritchie, who replied:[4] | | In truth, I don't know either. It was just a term that we | started to use. "Index" is my best guess, because of the | slightly unusual file system structure that stored the | access information of files as a flat array on the disk, | with all the hierarchical directory information living | aside from this. Thus the i-number is an index in this array, | the i-node is the selected element of the array. | (The "i-" notation was used in the 1st edition manual; | its hyphen was gradually dropped.) | |Further the Wikipedia article states that Bach says that the word ‘inode’ |is a contraction of the term index node. | |So is there a ‘definitive’ answer for this, or is it really lost in |the mists of time? Sure is to me only that in 4.2BSD the "A Fast File System for UNIX" paper (share/doc/smm/05.fastfs/) talks +Every file has a descriptor associated with it called an +.I "inode". +The inode contains information describing ownership of the file, +time stamps marking last modification and access times for the file, +and an array of indices that point to the data blocks for the file. +For the purposes of this section, we assume that the first 8 blocks +of the file are directly referenced by values stored +in the inode structure itself*. Node with array of indices. Isn't this an influential paper? Not mentioned in Wikipedia. --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 Sun Oct 5 09:04:47 2025 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Sat, 4 Oct 2025 16:04:47 -0700 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: On 10/4/25 1:38 PM, David Barto via TUHS wrote: > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. The "provably secure" version of Unix, called KSOS, used "jnodes" instead of "inodes". I think this was because the main architect of KSOS was Jay McCauley, and he named them after himself. Jon From tuhs at tuhs.org Sun Oct 5 09:16:32 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Sat, 4 Oct 2025 19:16:32 -0400 (EDT) Subject: [TUHS] inode - does it have a meaning? Message-ID: <20251004231632.77B4418C077@mercury.lcs.mit.edu> > From: Steffen Nurpmeso > Isn't this an influential paper. Written well over a decade after initial UNIX. The chances that anyone there knew anything about very early UNIX (especially as old documents had not yet started to show up on the early Internet, back then) are zero. Noel From tuhs at tuhs.org Sun Oct 5 09:24:01 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Sat, 4 Oct 2025 17:24:01 -0600 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <20251004231632.77B4418C077@mercury.lcs.mit.edu> References: <20251004231632.77B4418C077@mercury.lcs.mit.edu> Message-ID: On Sat, Oct 4, 2025 at 5:16 PM Noel Chiappa via TUHS wrote: > > From: Steffen Nurpmeso > > > Isn't this an influential paper. > > Written well over a decade after initial UNIX. The chances that anyone > there > knew anything about very early UNIX (especially as old documents had not > yet > started to show up on the early Internet, back then) are zero. > Yet they could have had it from oral history, given Ken's 1975 sabbatical to Berkeley, no? And the paper pre-dates his later recollections, and surely he reviewed it and would have raised an objection if he knew it was wrong. Kirk McKusick, the author, is on this list, I think. Though, I will grant it's not primary evidence. Warner From tuhs at tuhs.org Sun Oct 5 14:57:03 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 5 Oct 2025 14:57:03 +1000 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: On Sat, Oct 04, 2025 at 01:38:00PM -0700, David Barto via TUHS wrote: > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. This is in the 197 CACM paper: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for index number) of the file. When the file is accessed, its i-number is used as an index into a system table (the i-list) stored in a known part of the device on which the directory resides. The entry thereby found (the file’s i-node) contains the description of the file ... But an earlier version of the paper has this: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for identification number) of the file. See https://github.com/DoctorWkt/unix_timesharing_paper/blob/master/filesystem.md So you could argue that, at the time of this draft, the wording implies "identification node" for i-node. Cheers, Warren From tuhs at tuhs.org Mon Oct 6 07:45:12 2025 From: tuhs at tuhs.org (Eric Allman via TUHS) Date: Sun, 5 Oct 2025 14:45:12 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 In-Reply-To: References: Message-ID: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> On 10/4/25 14:15, Jim Mellander via TUHS wrote: > Hi all: > > I had the occasion to use the PDP-11/70 on the ground floor of Cory Hall. I > was not a student, but was in the Navy stationed at Treasure Island, but > groked Unix & visited there on my time off to tinker, among other things. I believe that would have been the instructional PDP-11/70. There was also an 11/45 that was, to the best of my knowledge, shared by CS, Math, and Statistics. Math and Stat wanted to run the vendor OS but CS wanted to run UNIX, so ⅓ of the time it ran UNIX and 2/3 of the time it ran something else, maybe RSTS. I worked on the INGRES project, which eventually got their own PDP-11/70, which was on the 4th floor of Cory. There were a few guest accounts, but it wasn't an instructional machine other than for the graduate DBMS class. My recollection is that Berkeley was running 5th Edition when I got my first account, but that didn't last long. I was mostly insulated from the transition to 6th Edition, but I remember that it required a lot of changes in INGRES due to changes in both the libraries and the C language itself. I was not insulated from the transition to 7th Edition, which was a lot of work but easier to work with. There were other transitions when the VAXen started to appear, but those were later. > I always have wondered who were the long hairs who were working inside the > glass partition on the system. These were probably the usual suspects: Bill Joy and Chuck Haley (certainly), Bob Fabry (who convinced the department to run UNIX in the first place), Ken Thompson (when he was on sabbatical while at Berkeley), Jeff Shriebman, and many others that I'm forgetting at the moment. There were also a lot of other folks who weren't doing a lot of kernel work like Ken Arnold, Kirk McKusick (who shared an office with Bill), Tom Ferrin (UCSF, but spent time in Berkeley working with other UNIX folks), Eric Schmidt, Kurt Shoens, etc. For the most part they were not working inside the glass box. Bonus recollection: Ken Thompson gave a free evening class that was a walk-through of the v6 kernel. I think about a dozen people showed up. The Computer History Museum in Mountain View has an audio recording of the talk and an annotated listing with my personal notes. Yes, I held on to that listing for almost 50 years. > > Also, I played with a PDP-11/45 in Evans Hall. > > I'm interested in any information anyone has about those times and places. You might also want to check out videos of Kirk McKusick's talks on the history of UNIX at Berkeley. A search for "Kirk McKusick Berkeley UNIX history" should do the trick, or check out his Youtube channel at https://www.youtube.com/@marshallkirkmckusick1756. > > Thanks in advance, > > Jim Mellander eric From tuhs at tuhs.org Mon Oct 6 09:55:35 2025 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Sun, 5 Oct 2025 19:55:35 -0400 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: Pedant alert: inode - does it have an etymology. We know what it *MEANS* ... that's in some man page.\ ===== mindthegapdialogs.com north-fork.info On Sun, Oct 5, 2025 at 1:04 AM Warren Toomey via TUHS wrote: > On Sat, Oct 04, 2025 at 01:38:00PM -0700, David Barto via TUHS wrote: > > In a blog post today I read: > > > > In most modern file systems, those data structures are > > known as inodes, and their numbers are inode numbers, > > sometimes shortened to inodes. The term is thought > > to be a contraction of index node, which certainly > > makes sense, but is lost in the mists of time. > > This is in the 197 CACM paper: > > A directory entry contains only a name for the associated file and > a pointer to the file itself. This pointer is an integer called the > i-number (for index number) of the file. When the file is accessed, its > i-number is used as an index into a system table (the i-list) stored in > a known part of the device on which the directory resides. The entry > thereby found (the file’s i-node) contains the description of the file > ... > > But an earlier version of the paper has this: > > A directory entry contains only a name for the associated file and > a pointer to the file itself. This pointer is an integer called the > i-number (for identification number) of the file. > > See > https://github.com/DoctorWkt/unix_timesharing_paper/blob/master/filesystem.md > > So you could argue that, at the time of this draft, the wording implies > "identification node" for i-node. > > Cheers, Warren > From tuhs at tuhs.org Mon Oct 6 10:21:49 2025 From: tuhs at tuhs.org (Jim Mellander via TUHS) Date: Sun, 5 Oct 2025 17:21:49 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 In-Reply-To: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> References: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> Message-ID: Thanks! A little more of my experiences with Unix in those days: I was 18 and too clever for my own good. Not being a student, I managed to "get" a student's account by looking over their shoulder surreptitiously. I then wrote a trivial C program to mimic the login prompt and harvested a few other accounts. I created a hidden dot directory for my experiments, which mainly consisted of writing chess and checker programs for my own amusement. I devoured the thick white Unix manual of the day, and, I hesitate to admit, wrote a trivial shell fork bomb which just spawned additional copies of itself in the background. I remember firing it up on an ASR-33, and it printed out the PIDs slower and slower until the system froze. I tore off the printout and left. The next time I showed up, the aforementioned long-hairs approached me, and told me that they knew what I had done. In contrast to what would happen today, they told me that they would give me a guest account for my enjoyment if I promised to stay in my lane. I took their words to heart and continued tinkering with my programs for the rest of my time stationed in the Bay Area. I also got an account somehow on the CDC-6400 in the basement of Evans Hall, and ran a few interesting batch-mode programs from punch cards. I often wondered who those guys were, since their kindness actually pointed me on the straight and narrow. Probably my fork bomb caused them to re-engineer the process table, so that could be my minor contribution to Unix. My career ended up in cybersecurity, of course (it takes a thief...) at LBL right up the hill from the Berkeley campus, so it all worked out OK. As an aside to the discussion about 'true', it seems reasonable that in the usual case ("while true"), the shell version wouldn't be significantly, if any, slower than a separate binary, since the shared libraries would already be in core. On my apple silicon mac 'true' is a 84128 byte dual architecture binary..... Thanks to all the Unix pioneers! Jim Mellander On Sun, Oct 5, 2025 at 2:45 PM Eric Allman wrote: > > On 10/4/25 14:15, Jim Mellander via TUHS wrote: > > Hi all: > > > > I had the occasion to use the PDP-11/70 on the ground floor of Cory > Hall. I > > was not a student, but was in the Navy stationed at Treasure Island, but > > groked Unix & visited there on my time off to tinker, among other things. > > I believe that would have been the instructional PDP-11/70. There was > also an 11/45 that was, to the best of my knowledge, shared by CS, Math, > and Statistics. Math and Stat wanted to run the vendor OS but CS wanted > to run UNIX, so ⅓ of the time it ran UNIX and 2/3 of the time it ran > something else, maybe RSTS. > > I worked on the INGRES project, which eventually got their own > PDP-11/70, which was on the 4th floor of Cory. There were a few guest > accounts, but it wasn't an instructional machine other than for the > graduate DBMS class. > > My recollection is that Berkeley was running 5th Edition when I got my > first account, but that didn't last long. I was mostly insulated from > the transition to 6th Edition, but I remember that it required a lot of > changes in INGRES due to changes in both the libraries and the C > language itself. I was not insulated from the transition to 7th Edition, > which was a lot of work but easier to work with. > > There were other transitions when the VAXen started to appear, but those > were later. > > > I always have wondered who were the long hairs who were working inside > the > > glass partition on the system. > > These were probably the usual suspects: Bill Joy and Chuck Haley > (certainly), Bob Fabry (who convinced the department to run UNIX in the > first place), Ken Thompson (when he was on sabbatical while at > Berkeley), Jeff Shriebman, and many others that I'm forgetting at the > moment. There were also a lot of other folks who weren't doing a lot of > kernel work like Ken Arnold, Kirk McKusick (who shared an office with > Bill), Tom Ferrin (UCSF, but spent time in Berkeley working with other > UNIX folks), Eric Schmidt, Kurt Shoens, etc. For the most part they were > not working inside the glass box. > > Bonus recollection: Ken Thompson gave a free evening class that was a > walk-through of the v6 kernel. I think about a dozen people showed up. > The Computer History Museum in Mountain View has an audio recording of > the talk and an annotated listing with my personal notes. Yes, I held on > to that listing for almost 50 years. > > > > > Also, I played with a PDP-11/45 in Evans Hall. > > > > I'm interested in any information anyone has about those times and > places. > > You might also want to check out videos of Kirk McKusick's talks on the > history of UNIX at Berkeley. A search for "Kirk McKusick Berkeley UNIX > history" should do the trick, or check out his Youtube channel at > https://www.youtube.com/@marshallkirkmckusick1756. > > > > > Thanks in advance, > > > > Jim Mellander > > eric > > From tuhs at tuhs.org Mon Oct 6 14:04:06 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 06 Oct 2025 04:04:06 +0000 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: <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> Ken, Your email reminds me of a comment you made in a 1989 interview with Mike Mahoney, that suggests something earlier than QED: > I did a lot of compiling. Even in college and out of college I did a lot of > on-the-fly compilers. Ah. ah. I wrote a GREP-like program. It would... You > type in …, you’d say what you wanted it to look for, and a sed-like thing > also. That you’d say, I want to do a substitute of A for B or some block of > text. What it would do is compile a program that would look for A and > substitute in B and then run the compiled program so that one level removed > from it do I direct my (unclear) and the early languages, the regular > expression searching stuff in ED and its predecessors on CTSS and those things > were in fact compilers for searches. They in fact compiled regular... https://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/thompson.htm By anyone's history of regular expressions, your matcher in QED was the first software implementation of regular expressions. Was this grep-like program you wrote in college something earlier than that? Could you share more about it? Do you somehow still have the source for these? I'd love to study it. Thalia On Sep 23, 2025, at 11:40, Ken Thompson 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. From tuhs at tuhs.org Tue Oct 7 03:42:00 2025 From: tuhs at tuhs.org (David Barto via TUHS) Date: Mon, 6 Oct 2025 10:42:00 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 / fork bomb In-Reply-To: References: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> Message-ID: > On Oct 5, 2025, at 5:21 PM, Jim Mellander via TUHS wrote: > > I devoured the thick white Unix manual of the day, and, I hesitate to > admit, wrote a trivial shell fork bomb which just spawned additional copies > of itself in the background. I remember firing it up on an ASR-33, and it > printed out the PIDs slower and slower until the system froze. I tore off > the printout and left. > Back in the late 70’s (78-79) I wrote a shell script to process some files I had on sdcsvax. Shell functions where new and by mistake I used the script name as a function name. I ran my test and it did what I expected, so I logged out. Little did I know at the time that the script had forked itself and was now on a runaway path to take the machine down. Next time I logged in I had receive a message from Brian Kantor (the sdcsvax admin at the time) with a listing of processes running on the machine and the admonition: Don’t do this again. A humbling experience. David The two most common elements in the universe are Hydrogen and Stupidity - Harlan Ellison David Barto barto at kdbarto.org From tuhs at tuhs.org Tue Oct 7 07:23:19 2025 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Mon, 6 Oct 2025 14:23:19 -0700 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> Message-ID: I'll raise a glass to Professor Mahoney's memory when I get off work. He was my thesis advisor (I never finished the Ph.D.) and it's always nice to see him cited and realize that there are still people who value his work. Adam On Sun, Oct 5, 2025 at 9:14 PM Thalia Archibald via TUHS wrote: > Ken, > > Your email reminds me of a comment you made in a 1989 interview with Mike > Mahoney, that suggests something earlier than QED: > > From tuhs at tuhs.org Thu Oct 9 11:17:11 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 09 Oct 2025 01:17:11 +0000 Subject: [TUHS] Government-Issue UNIX? Message-ID: AT&T has had a variable relationship with governments over the years, especially the U.S. On one hand, Bell Laboratories collaborated with the government and military on an number of projects such as the Nike Missile and TelStar. On the other hand, the Bell System was under constant regulatory scrutiny that was eventually its undoing. Part of this has me wondering if there was ever an attempt by the U.S. or another government (that folks can discuss of course) to license with AT&T to create a government-issued version of UNIX. Something that immediately comes to mind is the KSOS secure UNIX version developed by the DoD from what I know. However, this would've been used internally, not something that the government would attempt to distribute en masse for day to day computer operations or directly to constituents. Another system that comes to mind, tangentially related, are the state-sponsored versions of GNU/Linux found in China and North Korea. Of course, AT&T doesn't factor in there because penguins, but still, it shows an interest in that sphere of influence also in providing a standardized operating system (to the benefit of users or state actors...unknown). Had this ever come up? Has (as a matter of public record) any government attempted to buy a source license from AT&T for UNIX and then produce their own state-sanctioned UNIX flavor? I would assume to produce KSOS, the DoD would've needed to hold one such source license, but that could be me being ignorant of special government contacts that exist in a wholly separate space from AT&T's commercial business. - Matt G. From tuhs at tuhs.org Thu Oct 9 15:28:52 2025 From: tuhs at tuhs.org (Tom Perrine via TUHS) Date: Wed, 8 Oct 2025 23:28:52 -0600 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: KSOS - for PDP-11 originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor rmode UNIX system call compatible system. Later there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. KSOS was used in the Trusted Downgrade System of the multi-level-secure "all-source" intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. KSOS-32 - a VAX "port" of KSOS (which was then retconned as "KSOS-11"). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were re-written as needed. I worked on both systems at Logicon. --tep On Wed, Oct 8, 2025 at 7:17 PM segaloco via TUHS wrote: > AT&T has had a variable relationship with governments over the years, > especially the U.S. On one hand, Bell Laboratories collaborated with > the government and military on an number of projects such as the Nike > Missile and TelStar. On the other hand, the Bell System was under > constant regulatory scrutiny that was eventually its undoing. > > Part of this has me wondering if there was ever an attempt by the U.S. > or another government (that folks can discuss of course) to license with > AT&T to create a government-issued version of UNIX. Something that > immediately comes to mind is the KSOS secure UNIX version developed by > the DoD from what I know. However, this would've been used internally, > not something that the government would attempt to distribute en masse > for day to day computer operations or directly to constituents. Another > system that comes to mind, tangentially related, are the state-sponsored > versions of GNU/Linux found in China and North Korea. Of course, AT&T > doesn't factor in there because penguins, but still, it shows an > interest in that sphere of influence also in providing a standardized > operating system (to the benefit of users or state actors...unknown). > > Had this ever come up? Has (as a matter of public record) any > government attempted to buy a source license from AT&T for UNIX and then > produce their own state-sanctioned UNIX flavor? I would assume to > produce KSOS, the DoD would've needed to hold one such source license, > but that could be me being ignorant of special government contacts that > exist in a wholly separate space from AT&T's commercial business. > > - Matt G. > From tuhs at tuhs.org Thu Oct 9 15:38:39 2025 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Thu, 9 Oct 2025 15:38:39 +1000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: I'm imagining somebody believing the system implicitly derived higher trust because "it's totally Wirth it" .. but a mixture of semi automatic program translation and Emacs lisp filtration, sounds like an exercise in complexity. No shade cast on anyone who made it work. I'm just.. well my gast is completely flabbered. G On Thu, 9 Oct 2025, 3:29 pm Tom Perrine via TUHS, wrote: > KSOS - for PDP-11 originally developed by Ford Aerospace, and then extended > at Logicon. It did have a supervisor rmode UNIX system call compatible > system. Later there was also a userland library that implemented something > that mostly matched the UNIX system calls. It had no kernel code in common > with UNIX. It was written in Modula. > > KSOS was used in the Trusted Downgrade System of the multi-level-secure > "all-source" intel fusion system that Logicon built for a few agencies. > ACCAT-GUARD and USAFE-GUARD, for example. > > KSOS-32 - a VAX "port" of KSOS (which was then retconned as "KSOS-11"). The > Modula code from -11 was run though Emacs macros to produce Modula-2, and > then parts were re-written as needed. > > I worked on both systems at Logicon. > > --tep > > > > On Wed, Oct 8, 2025 at 7:17 PM segaloco via TUHS wrote: > > > AT&T has had a variable relationship with governments over the years, > > especially the U.S. On one hand, Bell Laboratories collaborated with > > the government and military on an number of projects such as the Nike > > Missile and TelStar. On the other hand, the Bell System was under > > constant regulatory scrutiny that was eventually its undoing. > > > > Part of this has me wondering if there was ever an attempt by the U.S. > > or another government (that folks can discuss of course) to license with > > AT&T to create a government-issued version of UNIX. Something that > > immediately comes to mind is the KSOS secure UNIX version developed by > > the DoD from what I know. However, this would've been used internally, > > not something that the government would attempt to distribute en masse > > for day to day computer operations or directly to constituents. Another > > system that comes to mind, tangentially related, are the state-sponsored > > versions of GNU/Linux found in China and North Korea. Of course, AT&T > > doesn't factor in there because penguins, but still, it shows an > > interest in that sphere of influence also in providing a standardized > > operating system (to the benefit of users or state actors...unknown). > > > > Had this ever come up? Has (as a matter of public record) any > > government attempted to buy a source license from AT&T for UNIX and then > > produce their own state-sanctioned UNIX flavor? I would assume to > > produce KSOS, the DoD would've needed to hold one such source license, > > but that could be me being ignorant of special government contacts that > > exist in a wholly separate space from AT&T's commercial business. > > > > - Matt G. > > > From tuhs at tuhs.org Thu Oct 9 20:48:35 2025 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Thu, 9 Oct 2025 06:48:35 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: Well, BSD UNIX came out of the UC Berkeley CSRG, didn’t it? And CSRG’s funding was primarily from DARPA. So I would call BSD a government-issued version of UNIX. What am I missing from your question? ===== mindthegapdialogs.com north-fork.info On Wed, Oct 8, 2025 at 9:54 PM segaloco via TUHS wrote: > AT&T has had a variable relationship with governments over the years, > especially the U.S. On one hand, Bell Laboratories collaborated with > the government and military on an number of projects such as the Nike > Missile and TelStar. On the other hand, the Bell System was under > constant regulatory scrutiny that was eventually its undoing. > > Part of this has me wondering if there was ever an attempt by the U.S. > or another government (that folks can discuss of course) to license with > AT&T to create a government-issued version of UNIX. Something that > immediately comes to mind is the KSOS secure UNIX version developed by > the DoD from what I know. However, this would've been used internally, > not something that the government would attempt to distribute en masse > for day to day computer operations or directly to constituents. Another > system that comes to mind, tangentially related, are the state-sponsored > versions of GNU/Linux found in China and North Korea. Of course, AT&T > doesn't factor in there because penguins, but still, it shows an > interest in that sphere of influence also in providing a standardized > operating system (to the benefit of users or state actors...unknown). > > Had this ever come up? Has (as a matter of public record) any > government attempted to buy a source license from AT&T for UNIX and then > produce their own state-sanctioned UNIX flavor? I would assume to > produce KSOS, the DoD would've needed to hold one such source license, > but that could be me being ignorant of special government contacts that > exist in a wholly separate space from AT&T's commercial business. > > - Matt G. > From tuhs at tuhs.org Thu Oct 9 21:57:37 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 9 Oct 2025 07:57:37 -0400 Subject: [TUHS] Government-Issue UNIX? Message-ID: When Jim Reeds and I were making the IX multilevel-secure Unix (1987-88), an Orange-Book-compliant Unix was being made for the government at BTL's Whippany Lab. There was some communication between the two projects, but different objectives led to significantly different systems. Did the Whippany product become KSOS, or did DOD end up with two "secure" Unixes? Doug From tuhs at tuhs.org Fri Oct 10 00:35:55 2025 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Thu, 9 Oct 2025 07:35:55 -0700 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On 10/9/25 4:57 AM, Douglas McIlroy via TUHS wrote: > Did the Whippany product become KSOS, or did DOD end up with two > "secure" Unixes? KSOS was made from scratch at Ford Aerospace in the late 1970s. I was in the group that did it, although I didn't work on it because I didn't have a security clearance. Jon From tuhs at tuhs.org Fri Oct 10 02:21:53 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 09 Oct 2025 16:21:53 +0000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: There was also an IBM secure XENIX. I did some kernel work on it back in the day (long about 1989). ------ Original Message ------ >From "Jon Forrest via TUHS" To tuhs at tuhs.org Date 10/9/2025 10:35:55 AM Subject [TUHS] Re: Government-Issue UNIX? > > >On 10/9/25 4:57 AM, Douglas McIlroy via TUHS wrote: > >>Did the Whippany product become KSOS, or did DOD end up with two >>"secure" Unixes? > >KSOS was made from scratch at Ford Aerospace in the late >1970s. I was in the group that did it, although I didn't >work on it because I didn't have a security clearance. > >Jon > From tuhs at tuhs.org Fri Oct 10 07:39:18 2025 From: tuhs at tuhs.org (jslee via TUHS) Date: Fri, 10 Oct 2025 08:39:18 +1100 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <12cef0a1-bd05-41f8-b85f-81e1a007f280@app.fastmail.com> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: > KSOS was made from scratch at Ford Aerospace in the late > 1970s. I was in the group that did it, although I didn't > work on it because I didn't have a security clearance. There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? Intrigued, John From tuhs at tuhs.org Fri Oct 10 07:44:27 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 09 Oct 2025 21:44:27 +0000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <12cef0a1-bd05-41f8-b85f-81e1a007f280@app.fastmail.com> References: <12cef0a1-bd05-41f8-b85f-81e1a007f280@app.fastmail.com> Message-ID: > On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: > > > KSOS was made from scratch at Ford Aerospace in the late > > 1970s. I was in the group that did it, although I didn't > > work on it because I didn't have a security clearance. > > > There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( > > Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? > > Intrigued, > > John Fwiw the manual I have on hand is just for the kernel API, so I couldn't say. On a quick flip-through, the sections appear to have been rearranged (.e.g Section I describes datatypes used by syscalls) and in none of the sections did I spot anything particularly resembling userland applications, although I think the API documentation includes non-syscall entrypoints implying parts of a userland C library. - Matt G. From tuhs at tuhs.org Fri Oct 10 07:46:33 2025 From: tuhs at tuhs.org (Nelson H. F. Beebe via TUHS) Date: Thu, 9 Oct 2025 15:46:33 -0600 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <12cef0a1-bd05-41f8-b85f-81e1a007f280@app.fastmail.com> Message-ID: There is an accessible Usenix paper on KSOS: https://www.usenix.org/system/files/login/issues/login_december_2002.pdf The article by Tom Perrine is on pages 37--40. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From tuhs at tuhs.org Fri Oct 10 07:55:40 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 09 Oct 2025 21:55:40 +0000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On Thursday, October 9th, 2025 at 14:46, Nelson H. F. Beebe via TUHS wrote: > There is an accessible Usenix paper on KSOS: > > https://www.usenix.org/system/files/login/issues/login_december_2002.pdf > > The article by Tom Perrine is on pages 37--40. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - > ------------------------------------------------------------------------------- Well and for the record too the KSOS literature I have on hand was previously shared in a thread here: https://www.tuhs.org/pipermail/tuhs/2023-June/028441.html The two links: https://apps.dtic.mil/sti/pdfs/ADA111566.pdf - This is a "Final Report" on KSOS. https://apps.dtic.mil/sti/pdfs/ADA111577.pdf - This is then the User's Manual. I need to double check my paper copy, I think I saw a couple more sections that aren't in that scan, but I need to confirm. Either way though based on other markings I think my print copies are from the same original microfiche. - Matt G. From tuhs at tuhs.org Fri Oct 10 09:10:16 2025 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Thu, 9 Oct 2025 16:10:16 -0700 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: Speaking of the AT&T Orange Book, B level Unix system, I had some minor involvement with it from the system administration side of things. A secure US facility in the San Jose area known as the Blue Cube had sent a couple of servicemen to a class in security I was teaching. They shared a manual for managing the security aspects of the system: 123 commands just for managing security. That seemed totally unreasonable to me, in that most people had a difficult enough time managing ordinary Unix systems, where a sysadmin needed to know just a relative two handfuls of commands to be effective. I wonder how well KSOS was designed, or if it also included over 100 new commands for managing mandatory security? Rik On Thu, Oct 9, 2025 at 4:58 AM Douglas McIlroy via TUHS wrote: > When Jim Reeds and I were making the IX multilevel-secure Unix > (1987-88), an Orange-Book-compliant Unix was being made for the > government at BTL's Whippany Lab. There was some communication between > the two projects, but different objectives led to significantly > different systems. > > Did the Whippany product become KSOS, or did DOD end up with two > "secure" Unixes? > > Doug > From tuhs at tuhs.org Fri Oct 10 09:39:45 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 9 Oct 2025 19:39:45 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: Matt, You asked: * "**if there was ever an attempt by the U.S. or another government to license with AT&T to create a government-issued version of UNIX." * Taking your question in a different direction than some of the other responses, where do you see FIPS-151 fit in relation? For many years, the FIPS (Federal Information Processing Standard) was a formal requirement if a system was to be sold to the USG. In fact, NIST(part of the US Dept of Commerce) wrote a test suite to check to see if an OS conformed to FIPS-151 [it's described here: https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-2-1993.pdf — and today the suite is referred to as VSX-PCS]. The Open Group now maintains those test suites, which anyone can download if they like: https://posix.opengroup.org/testsuites.html. Note, they released updates to 6 of them in 2025. I would say that was a pretty strong statement that, while the US Gov, was not directly creating a UNIX implementation, they were making sure that the vendors supplied one. Clem From tuhs at tuhs.org Fri Oct 10 10:04:52 2025 From: tuhs at tuhs.org (Wesley Parish via TUHS) Date: Fri, 10 Oct 2025 13:04:52 +1300 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <051c0007-6559-4171-aa32-5ef38b511662@gmail.com> And the question that keeps recurring to my mind, is, what happened to the source trees of these "exotic beasts" in the Unix menagerie? Any chance they'd be freed any time soon? Wesley Parish On 10/10/2025 00:57, Douglas McIlroy via TUHS wrote: > When Jim Reeds and I were making the IX multilevel-secure Unix > (1987-88), an Orange-Book-compliant Unix was being made for the > government at BTL's Whippany Lab. There was some communication between > the two projects, but different objectives led to significantly > different systems. > > Did the Whippany product become KSOS, or did DOD end up with two > "secure" Unixes? > > Doug From tuhs at tuhs.org Fri Oct 10 10:12:23 2025 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Thu, 9 Oct 2025 17:12:23 -0700 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On 10/9/25 4:10 PM, Rik Farrow via TUHS wrote: > Speaking of the AT&T Orange Book, B level Unix system, I had some minor > involvement with it from the system administration side of things. A secure > US facility in the San Jose area known as the Blue Cube had sent a couple > of servicemen to a class in security I was teaching. They shared a manual > for managing the security aspects of the system: 123 commands just for > managing security. That seemed totally unreasonable to me, in that most > people had a difficult enough time managing ordinary Unix systems, where a > sysadmin needed to know just a relative two handfuls of commands to be > effective. > > I wonder how well KSOS was designed, or if it also included over 100 new > commands for managing mandatory security? I have no idea since I left Ford before KSOS was finished. John Nagle, who sometimes posts here, would probably know. Jon From tuhs at tuhs.org Fri Oct 10 11:11:08 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Thu, 9 Oct 2025 21:11:08 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. Gary Luckenbaugh Sent from my iPhone > On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: > >  >> >>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>> >>> KSOS was made from scratch at Ford Aerospace in the late >>> 1970s. I was in the group that did it, although I didn't >>> work on it because I didn't have a security clearance. >> >> >> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >> >> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >> >> Intrigued, >> >> John > > Fwiw the manual I have on hand is just for the kernel API, so I couldn't > say. On a quick flip-through, the sections appear to have been > rearranged (.e.g Section I describes datatypes used by syscalls) and in > none of the sections did I spot anything particularly resembling > userland applications, although I think the API documentation includes > non-syscall entrypoints implying parts of a userland C library. > > - Matt G. From tuhs at tuhs.org Fri Oct 10 11:30:04 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Thu, 9 Oct 2025 21:30:04 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <38748BBF-0054-4C49-A723-06AE1D7384AF@icloud.com> BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. Gary Luckenbaugh Sent from my iPhone > On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: > > I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. > > My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. > > Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. > > I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 > > That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. > > Gary Luckenbaugh > > Sent from my iPhone > >> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >> >>  >>> >>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>> >>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>> 1970s. I was in the group that did it, although I didn't >>>>> work on it because I didn't have a security clearance. >>> >>> >>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>> >>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>> >>> Intrigued, >>> >>> John >> >> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >> say. On a quick flip-through, the sections appear to have been >> rearranged (.e.g Section I describes datatypes used by syscalls) and in >> none of the sections did I spot anything particularly resembling >> userland applications, although I think the API documentation includes >> non-syscall entrypoints implying parts of a userland C library. >> >> - Matt G. From tuhs at tuhs.org Fri Oct 10 11:58:56 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 9 Oct 2025 21:58:56 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On Thu, Oct 9, 2025 at 7:50 PM Clem Cole via TUHS wrote: > You asked: * "**if there was ever an attempt by the U.S. or another > government to license with AT&T to create a government-issued version of > UNIX." * The responses to this question thus far have mostly related to military and other secure applications, and less to general computing use throughout the rest of the government. In either case, I think Clem has it right; the implication is that the government mostly publishes standards and relies on vendors and contractors to implement those standards; thus, no GI Unix distribution, just a specification. If anything, Microsoft Windows is probably the closest anything has ever come to a standard government OS. At one point, the US Marine Corps had standardized on Banyan VINES for a bunch of networking functions across the FMF. I wasn't in at the time, but my brother, who was a grunt-turned-Cobra-pilot and couldn't care less, told me when they started to transition away from it (this would have been early- or mid-1990s) and showed me a draft that was being circulated in his squadron about the upcoming infrastructure changes: because a bunch of young helo pilots must have been really, really interested :-). Anyway, written by non-experts, it overloaded a lot of computing acronyms in ways that only the military was capable of making so confusing. He wasn't nearly as amused as I was at that, or for that matter, amused at all; particularly given that I was so amused. A few years later, I was talking with a Warrant Officer who remembered working on VINES, but by then all that stuff had been replaced by Windows on Dell PCs/servers and Cisco networking gear. - Dan C. > Taking your question in a different direction than some of the > other responses, where do you see FIPS-151 fit in relation? For many > years, the FIPS (Federal Information Processing Standard) was a formal > requirement if a system was to be sold to the USG. In fact, NIST(part of > the US Dept of Commerce) wrote a test suite to check to see if an OS > conformed to FIPS-151 [it's described here: > https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-2-1993.pdf — and > today the suite is referred to as VSX-PCS]. The Open Group now maintains > those test suites, which anyone can download if they like: > https://posix.opengroup.org/testsuites.html. Note, they released updates to > 6 of them in 2025. > > I would say that was a pretty strong statement that, while the US Gov, > was not directly creating a UNIX implementation, they were making sure that > the vendors supplied one. > > Clem From tuhs at tuhs.org Fri Oct 10 12:27:42 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 9 Oct 2025 22:27:42 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <38748BBF-0054-4C49-A723-06AE1D7384AF@icloud.com> References: <38748BBF-0054-4C49-A723-06AE1D7384AF@icloud.com> Message-ID: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. > On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: > >  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. > > Gary Luckenbaugh > > > Sent from my iPhone > >> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >> >> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >> >> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >> >> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >> >> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >> >> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >> >> Gary Luckenbaugh >> >> Sent from my iPhone >> >>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>> >>>  >>>> >>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>> >>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>> 1970s. I was in the group that did it, although I didn't >>>>>> work on it because I didn't have a security clearance. >>>> >>>> >>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>> >>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>> >>>> Intrigued, >>>> >>>> John >>> >>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>> say. On a quick flip-through, the sections appear to have been >>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>> none of the sections did I spot anything particularly resembling >>> userland applications, although I think the API documentation includes >>> non-syscall entrypoints implying parts of a userland C library. >>> >>> - Matt G. From tuhs at tuhs.org Fri Oct 10 13:27:15 2025 From: tuhs at tuhs.org (Andy Wallis via TUHS) Date: Thu, 9 Oct 2025 23:27:15 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> Message-ID: IBM Federal Systems got sold off to Loral then Lockheed and is now owned by Leidos. The Gaithersburg plant was partially torn down to make way for a FedEx or UPS depot. There are still a number of ex IBM FS people still working at Leidos. I think Gary worked with me in the FAA ATC programs if it the same person I remember. It is still very much a UNIX shop. AIX has been replaced by RHEL. That place gave me my love of AIX from our FAA programs going back to AAS to ERAM. -Andy Wallis > On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: > > I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. > >> On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: >> >>  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. >> >> Gary Luckenbaugh >> >> >> Sent from my iPhone >> >>>> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >>> >>> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >>> >>> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >>> >>> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >>> >>> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >>> >>> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >>> >>> Gary Luckenbaugh >>> >>> Sent from my iPhone >>> >>>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>>> >>>>  >>>>> >>>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>>> >>>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>>> 1970s. I was in the group that did it, although I didn't >>>>>>> work on it because I didn't have a security clearance. >>>>> >>>>> >>>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>>> >>>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>>> >>>>> Intrigued, >>>>> >>>>> John >>>> >>>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>>> say. On a quick flip-through, the sections appear to have been >>>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>>> none of the sections did I spot anything particularly resembling >>>> userland applications, although I think the API documentation includes >>>> non-syscall entrypoints implying parts of a userland C library. >>>> >>>> - Matt G. > From tuhs at tuhs.org Fri Oct 10 23:21:07 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Fri, 10 Oct 2025 09:21:07 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <42BD5436-68AB-4634-B8C9-21EF14BFC8A7@icloud.com> There were quite a few secure products in the 80s. There was set of requirements promulgated by the Defense Intelligence Agency (defined by Mitre) for a Compartmented Mode Workstation. In the late 80s IBM, DEC, and HP had CMW offerings along with an Atlanta startup named Secure Ware that built a CMW based on a Unix system that ran on an Apple Mac. I believe it was A/UX. At IBM we licensed the Secure Ware product and had them port it to IBM's AIX. Our group in IBM Federal was responsible for the fork of AIX that resulted from the Secure Ware port. We also were responsible for getting the product certified by the DIA. We had many joint meetings with IBM, DEC, HP and the DIA. I was IBM's representative at those meetings. I believe HP went on to acquire Secure Ware. I asked Perplexity.AI about that and it blew a fuse. 😆 Gary Luckenbaugh Sent from my iPhone > On Oct 9, 2025, at 7:58 AM, Douglas McIlroy via TUHS wrote: > > When Jim Reeds and I were making the IX multilevel-secure Unix > (1987-88), an Orange-Book-compliant Unix was being made for the > government at BTL's Whippany Lab. There was some communication between > the two projects, but different objectives led to significantly > different systems. > > Did the Whippany product become KSOS, or did DOD end up with two > "secure" Unixes? > > Doug From tuhs at tuhs.org Fri Oct 10 23:29:04 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Fri, 10 Oct 2025 09:29:04 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> Message-ID: Yes, I know Tom Wellington very well. He was a strong proponent of Secure Xenix and worked hard to get it into NSA. I believe he had some success with that, even after it was sold to Trusted Information Systems. I heard there was a Secure Phone system built out of it, but that was past my time. Gary Luckenbaugh Sent from my iPhone > On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: > > I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. > >> On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: >> >>  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. >> >> Gary Luckenbaugh >> >> >> Sent from my iPhone >> >>>> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >>> >>> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >>> >>> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >>> >>> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >>> >>> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >>> >>> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >>> >>> Gary Luckenbaugh >>> >>> Sent from my iPhone >>> >>>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>>> >>>>  >>>>> >>>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>>> >>>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>>> 1970s. I was in the group that did it, although I didn't >>>>>>> work on it because I didn't have a security clearance. >>>>> >>>>> >>>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>>> >>>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>>> >>>>> Intrigued, >>>>> >>>>> John >>>> >>>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>>> say. On a quick flip-through, the sections appear to have been >>>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>>> none of the sections did I spot anything particularly resembling >>>> userland applications, although I think the API documentation includes >>>> non-syscall entrypoints implying parts of a userland C library. >>>> >>>> - Matt G. > From tuhs at tuhs.org Fri Oct 10 23:46:53 2025 From: tuhs at tuhs.org (Theodore Ts'o via TUHS) Date: Fri, 10 Oct 2025 09:46:53 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <20251010134653.GA566507@mit.edu> On Thu, Oct 09, 2025 at 09:11:08PM -0400, GARY LUCKENBAUGH via TUHS wrote: > I was the lead developer on IBM Secure Xenix. I designed all the > APIs and did much of the kernel work from Jan 1984 until 1989 when > we handed off the project to Steve Walker's Trusted Information > Systems. Yes, there was a huge push in that era for the government to ask the computer industry again for "Secure Unix". The catch phrase at the time was "B2 by '92". That is, that there would be multiple Unix systems be available for sale to the US government which would meet the the B2 level as defined by the Orange Book. (Multics could meet B3, but it was pretty clear that Unix could never achieve B3, but it was hoped that B2 was achievable.) More information about this can be found here: [1] https://bitsavers.computerhistory.org/pdf/sdc/adept-50/Lipner_-_The_Birth_and_Death_of_the_Orange_Book_2015.pdf There was an attempt to standardize the necessary interfaces in Posix. This was Posix.1e, and it got as far as Draft 17 before it was abandoned. Casey Schaufler was the last technical editor of Posix.1e before the plug was pulled and described the reasons why here[2]. [2] https://groups.google.com/g/comp.security.unix/c/gfyLMetqubs/m/5tBrcPuJA0gJ The short version is that there wasn't any commercial demand for Secure Unix, and while there were implementations of early drafts Posix Capabilities in Solaris, AIX, etc., it became clear that there wasn't enough of a market for the feature, and one by one, companies abandoned the effort. Linux does have an implementation of the last draft of Posix.1e, but and there is some use of it, but one of the problems is that the Posix capabilities were insufficiently granular. In particular, CAP_SYs_ADMIN is pretty much as good as root. There is some use of it to only give certain programs CAP_NET_RAW (for example) instead of root, but the ability to have doing a large number of capability modulation has pretty much been proved to be not workable. You can make the ping program no longer be setuid root, but set a POSIX capability effective mask so that CAP_NET_RAW is raised when ping is started, but would this compelling enough for a customer to switch from, say Solaris to AIX? Not really. So it's not surprising that companies weren't interested paying engineers to travel to POSIX.1e standards meetings, and to make all of the changes in the broader Unix userspace and appllication ecosystem to support the full POSIX capabilities vision. - Ted From tuhs at tuhs.org Sat Oct 11 00:19:30 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 10 Oct 2025 08:19:30 -0600 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <42BD5436-68AB-4634-B8C9-21EF14BFC8A7@icloud.com> References: <42BD5436-68AB-4634-B8C9-21EF14BFC8A7@icloud.com> Message-ID: <202510101419.59AEJUnH092698@freefriends.org> HP sounds right. I know 2 of the people who did SecureWare; one of them grew up down the street from me and is now a Jerusalem-based venture capitalist. :-) Arnold GARY LUCKENBAUGH via TUHS wrote: > There were quite a few secure products in the 80s. There was set of requirements promulgated by the Defense Intelligence Agency (defined by Mitre) for a Compartmented Mode Workstation. In the late 80s IBM, DEC, and HP had CMW offerings along with an Atlanta startup named Secure Ware that built a CMW based on a Unix system that ran on an Apple Mac. I believe it was A/UX. At IBM we licensed the Secure Ware product and had them port it to IBM's AIX. > > Our group in IBM Federal was responsible for the fork of AIX that resulted from the Secure Ware port. We also were responsible for getting the product certified by the DIA. We had many joint meetings with IBM, DEC, HP and the DIA. I was IBM's representative at those meetings. > > I believe HP went on to acquire Secure Ware. I asked Perplexity.AI about that and it blew a fuse. 😆 > > Gary Luckenbaugh > > Sent from my iPhone > > > On Oct 9, 2025, at 7:58 AM, Douglas McIlroy via TUHS wrote: > > > > When Jim Reeds and I were making the IX multilevel-secure Unix > > (1987-88), an Orange-Book-compliant Unix was being made for the > > government at BTL's Whippany Lab. There was some communication between > > the two projects, but different objectives led to significantly > > different systems. > > > > Did the Whippany product become KSOS, or did DOD end up with two > > "secure" Unixes? > > > > Doug From tuhs at tuhs.org Sat Oct 11 00:25:23 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Fri, 10 Oct 2025 10:25:23 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: Yep, that is me. I went through all the mergers and acquisitions as well, and retired from Leidos in 2017. At the time I was working in the plant in Gaithersburg. I spent probably 20 years off and on in that building. The entire thing was torn down a few years after Leidos acquired it, and Lockheed Martin had completed a full renovation a few years before it was torn down. My longest stint on FAA programs was during the ERAM period. I was the security architect from around 2001-2007. I had some intermittent periods during the AAS project, but I was mostly on loan to IBM Advanced Workstations Division during the AAS project. Sadly, I think all copies of IBM B2 Secure Xenix, CMW Xenix, and AIX/CMW have been lost to history. The tapes all became the property of Loral, and they didn't have an interest in keeping them. I had a complete set of product manuals for B2 Secure Xenix, but tossed them out in my last move. I'm curious about AT&T's Orange Book Security work, and SE/Linux. It sounds like there have been multiple waves of work on Defense related Unices; Ford Aerospace KSOS in the late 70s, IBM B2 Secure Xenix in the early 80s, the IBM/DEC/HP CMWs in the late 80s and early 90s, TIS takeover of IBM Xenix in late 80s, and then after my time, mid-90s maybe, the deployment of Secure Xenix in an application at NSA in Ft. Meade. I think it might have been for a telephone or secure guard of some sort. This might have been the work that Tom Wellington spearheaded for IBM. It's interesting that there wasn't much, if any, communication between the different generations of people working on defense Unices. I only met the the KSOS guys after IBM Federal and Ford Aerospace both became part of Loral. I only very recently heard that AT&T was building an Orange book Unix, and I know nothing about SE/Linux other than its existence. When Secure Xenix was being evaluated by the NCSC we went through dozens of rounds of "bring me a rock" please, and IBM just gave up, and sold it to TIS. Around 1986, when we were going through the painful "bring me a rock" phase, Andrew Tanennbaum wrote his book on Minix. I suggested that the Mitre guys create a reference implementation of a B2 Unix-like system using Minix. I've often wondered if the genesis of SE/Linux was the result of my planting a bug in the ear of the Mitre guy, whose name unfortunately I can't remember. I'm also really curious about the AT&T secure Unix. It appears that neither of us knew of the other's existence. I'm really curious if you were successfully certified by the NCSC or whatever they were called at the time. Gary Luckenbaugh Sent from my iPhone > On Oct 9, 2025, at 11:27 PM, Andy Wallis via TUHS wrote: > > IBM Federal Systems got sold off to Loral then Lockheed and is now owned by Leidos. The Gaithersburg plant was partially torn down to make way for a FedEx or UPS depot. > There are still a number of ex IBM FS people still working at Leidos. > I think Gary worked with me in the FAA ATC programs if it the same person I remember. > > It is still very much a UNIX shop. AIX has been replaced by RHEL. That place gave me my love of AIX from our FAA programs going back to AAS to ERAM. > -Andy Wallis > >> On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: >> >> I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. >> >>>> On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: >>> >>>  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. >>> >>> Gary Luckenbaugh >>> >>> >>> Sent from my iPhone >>> >>>>> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >>>> >>>> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >>>> >>>> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >>>> >>>> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >>>> >>>> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >>>> >>>> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >>>> >>>> Gary Luckenbaugh >>>> >>>> Sent from my iPhone >>>> >>>>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>>>> >>>>>  >>>>>> >>>>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>>>> >>>>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>>>> 1970s. I was in the group that did it, although I didn't >>>>>>>> work on it because I didn't have a security clearance. >>>>>> >>>>>> >>>>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>>>> >>>>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>>>> >>>>>> Intrigued, >>>>>> >>>>>> John >>>>> >>>>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>>>> say. On a quick flip-through, the sections appear to have been >>>>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>>>> none of the sections did I spot anything particularly resembling >>>>> userland applications, although I think the API documentation includes >>>>> non-syscall entrypoints implying parts of a userland C library. >>>>> >>>>> - Matt G. >> From tuhs at tuhs.org Sat Oct 11 00:33:04 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Fri, 10 Oct 2025 10:33:04 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <202510101419.59AEJUnH092698@freefriends.org> References: <202510101419.59AEJUnH092698@freefriends.org> Message-ID: Oh yes, was it David Arnovitz at Secure Ware I believe. I remember congratulating him when HP acquired them, but I gather other than the money, he didn't care much for HP. Gary Luckenbaugh Sent from my iPhone > On Oct 10, 2025, at 10:19 AM, Arnold Robbins via TUHS wrote: > > HP sounds right. I know 2 of the people who did SecureWare; one of them > grew up down the street from me and is now a Jerusalem-based venture > capitalist. :-) > > Arnold > > GARY LUCKENBAUGH via TUHS wrote: > >> There were quite a few secure products in the 80s. There was set of requirements promulgated by the Defense Intelligence Agency (defined by Mitre) for a Compartmented Mode Workstation. In the late 80s IBM, DEC, and HP had CMW offerings along with an Atlanta startup named Secure Ware that built a CMW based on a Unix system that ran on an Apple Mac. I believe it was A/UX. At IBM we licensed the Secure Ware product and had them port it to IBM's AIX. >> >> Our group in IBM Federal was responsible for the fork of AIX that resulted from the Secure Ware port. We also were responsible for getting the product certified by the DIA. We had many joint meetings with IBM, DEC, HP and the DIA. I was IBM's representative at those meetings. >> >> I believe HP went on to acquire Secure Ware. I asked Perplexity.AI about that and it blew a fuse. 😆 >> >> Gary Luckenbaugh >> >> Sent from my iPhone >> >>>> On Oct 9, 2025, at 7:58 AM, Douglas McIlroy via TUHS wrote: >>> >>> When Jim Reeds and I were making the IX multilevel-secure Unix >>> (1987-88), an Orange-Book-compliant Unix was being made for the >>> government at BTL's Whippany Lab. There was some communication between >>> the two projects, but different objectives led to significantly >>> different systems. >>> >>> Did the Whippany product become KSOS, or did DOD end up with two >>> "secure" Unixes? >>> >>> Doug From tuhs at tuhs.org Sat Oct 11 00:46:33 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Fri, 10 Oct 2025 10:46:33 -0400 Subject: [TUHS] Government-Issue UNIX? Message-ID: Very interesting. We didn't add fine grained privileges to Xenix until near the very end of the project, and I think it was just the CMW variant. We picked them up from a reference implementation done at Mitre in the Boston area. I can't remember the name of the guy that built that, but I heard he got a promotion because he was successful in getting his technology transferred to a commercial product. IBM sold us to Loral in 1994, so that explains why I never heard of the AT&T work. I was on loan to IBM Austin when we were sold, and I could have stayed with IBM if I moved there, but I had family on the east coast. I'm curious if the AT&T evaluation went smoother than the IBM one did. Gary Luckenbaugh Sent from my iPhone > On Oct 10, 2025, at 9:47 AM, Theodore Ts'o via TUHS wrote: > > On Thu, Oct 09, 2025 at 09:11:08PM -0400, GARY LUCKENBAUGH via TUHS wrote: >> I was the lead developer on IBM Secure Xenix. I designed all the >> APIs and did much of the kernel work from Jan 1984 until 1989 when >> we handed off the project to Steve Walker's Trusted Information >> Systems. > > Yes, there was a huge push in that era for the government to ask the > computer industry again for "Secure Unix". The catch phrase at the > time was "B2 by '92". That is, that there would be multiple Unix > systems be available for sale to the US government which would meet > the the B2 level as defined by the Orange Book. (Multics could meet > B3, but it was pretty clear that Unix could never achieve B3, but it > was hoped that B2 was achievable.) More information about this can be > found here: > > [1] https://bitsavers.computerhistory.org/pdf/sdc/adept-50/Lipner_-_The_Birth_and_Death_of_the_Orange_Book_2015.pdf > > There was an attempt to standardize the necessary interfaces in Posix. > This was Posix.1e, and it got as far as Draft 17 before it was abandoned. Casey Schaufler was the last technical editor of Posix.1e before the plug was pulled and described the reasons why here[2]. > > [2] https://groups.google.com/g/comp.security.unix/c/gfyLMetqubs/m/5tBrcPuJA0gJ > > The short version is that there wasn't any commercial demand for > Secure Unix, and while there were implementations of early drafts > Posix Capabilities in Solaris, AIX, etc., it became clear that there > wasn't enough of a market for the feature, and one by one, companies > abandoned the effort. > > Linux does have an implementation of the last draft of Posix.1e, but > and there is some use of it, but one of the problems is that the Posix > capabilities were insufficiently granular. In particular, > CAP_SYs_ADMIN is pretty much as good as root. There is some use of it > to only give certain programs CAP_NET_RAW (for example) instead of > root, but the ability to have doing a large number of capability > modulation has pretty much been proved to be not workable. > > You can make the ping program no longer be setuid root, but set a > POSIX capability effective mask so that CAP_NET_RAW is raised when > ping is started, but would this compelling enough for a customer to > switch from, say Solaris to AIX? Not really. So it's not surprising > that companies weren't interested paying engineers to travel to > POSIX.1e standards meetings, and to make all of the changes in the > broader Unix userspace and appllication ecosystem to support the full > POSIX capabilities vision. > > - Ted From tuhs at tuhs.org Sat Oct 11 03:16:40 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 10 Oct 2025 17:16:40 +0000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> Message-ID: I was working on crafting a second Ethernet interface into it and turning it in to a secure “downgrading” station. You took a file from one network, verified that it had no higher classified content, and then wrote it out on the lower classification network. If I recall properly, Jakob Rector had written the original driver. ------ Original Message ------ >From "GARY LUCKENBAUGH via TUHS" To "Ron Natalie via TUHS" Cc "segaloco" ; tuhs at tuhs.org Date 10/10/2025 9:29:04 AM Subject [TUHS] Re: Government-Issue UNIX? >Yes, I know Tom Wellington very well. He was a strong proponent of Secure Xenix and worked hard to get it into NSA. I believe he had some success with that, even after it was sold to Trusted Information Systems. I heard there was a Secure Phone system built out of it, but that was past my time. > >Gary Luckenbaugh > >Sent from my iPhone > >> On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: >> >> I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. >> >>> On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: >>> >>>  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. >>> >>> Gary Luckenbaugh >>> >>> >>> Sent from my iPhone >>> >>>>> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >>>> >>>> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >>>> >>>> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >>>> >>>> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >>>> >>>> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >>>> >>>> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >>>> >>>> Gary Luckenbaugh >>>> >>>> Sent from my iPhone >>>> >>>>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>>>> >>>>>  >>>>>> >>>>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>>>> >>>>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>>>> 1970s. I was in the group that did it, although I didn't >>>>>>>> work on it because I didn't have a security clearance. >>>>>> >>>>>> >>>>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>>>> >>>>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>>>> >>>>>> Intrigued, >>>>>> >>>>>> John >>>>> >>>>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>>>> say. On a quick flip-through, the sections appear to have been >>>>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>>>> none of the sections did I spot anything particularly resembling >>>>> userland applications, although I think the API documentation includes >>>>> non-syscall entrypoints implying parts of a userland C library. >>>>> >>>>> - Matt G. >> From tuhs at tuhs.org Sat Oct 11 03:27:33 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 10 Oct 2025 17:27:33 +0000 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> Message-ID: We worked with these guys for years. First IBM Federal Sector, then Federal Systems, then Loral, then Lockmart, then Leidos, My contact there said he’s worked for different companies without ever changing his office. I still have an IBM badge/door card from my days there. Of course, we joked about it, but my company was not much better. We were part of BDS, then spun out as KTS, then back into BDS, and then merged with BTG, then spun out again as Sensor Systems, then merged with Austin Information Systems to form Overwatch Systems (also picking up Visual Learning Systems, Paragon Imaging, and IT Spatial), and then got bought out by Textron. All along the way I did several UNIX ports, several X Server Ports, some Novell Drivers, all while developing our image processing products (intelligence and medical research). ------ Original Message ------ >From "Andy Wallis" To "Natalie Ron" Cc "GARY LUCKENBAUGH" ; "segaloco" ; tuhs at tuhs.org Date 10/9/2025 11:27:15 PM Subject Re: [TUHS] Re: Government-Issue UNIX? >IBM Federal Systems got sold off to Loral then Lockheed and is now owned by Leidos. The Gaithersburg plant was partially torn down to make way for a FedEx or UPS depot. >There are still a number of ex IBM FS people still working at Leidos. >I think Gary worked with me in the FAA ATC programs if it the same person I remember. > >It is still very much a UNIX shop. AIX has been replaced by RHEL. That place gave me my love of AIX from our FAA programs going back to AAS to ERAM. >-Andy Wallis > >> On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: >> >> I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. >> >>> On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: >>> >>>  BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. >>> >>> Gary Luckenbaugh >>> >>> >>> Sent from my iPhone >>> >>>>> On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: >>>> >>>> I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. >>>> >>>> My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. >>>> >>>> Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. >>>> >>>> I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 >>>> >>>> That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. >>>> >>>> Gary Luckenbaugh >>>> >>>> Sent from my iPhone >>>> >>>>>> On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: >>>>> >>>>>  >>>>>> >>>>>>>> On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: >>>>>>>> >>>>>>>> KSOS was made from scratch at Ford Aerospace in the late >>>>>>>> 1970s. I was in the group that did it, although I didn't >>>>>>>> work on it because I didn't have a security clearance. >>>>>> >>>>>> >>>>>> There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( >>>>>> >>>>>> Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? >>>>>> >>>>>> Intrigued, >>>>>> >>>>>> John >>>>> >>>>> Fwiw the manual I have on hand is just for the kernel API, so I couldn't >>>>> say. On a quick flip-through, the sections appear to have been >>>>> rearranged (.e.g Section I describes datatypes used by syscalls) and in >>>>> none of the sections did I spot anything particularly resembling >>>>> userland applications, although I think the API documentation includes >>>>> non-syscall entrypoints implying parts of a userland C library. >>>>> >>>>> - Matt G. >> From tuhs at tuhs.org Sat Oct 11 10:57:25 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Oct 2025 00:57:25 +0000 Subject: [TUHS] Some 1980 Bell System UNIX Descriptions Message-ID: I've just today received Bell System Information and Operations Systems, March 1980, Issue 4, and several UNIX variants are listed therein. Here I'll compile a few excerpts until such time as I can scan this. ------------ First, simply "UNIX" in this manual refers to the USG Program Generic version. From the description: "Issue 3 was released as a standard product in 1977. UNIX has been superseded by UNIX/TS in 4Q78." The status is given as becoming supported Bell Labs project 4Q73 (so referring to Program Generic starting in 1973?) and first supported as an "OTC" project 1Q76. The only document reference is given as "Western Electric Generic Program PG1C300", and the points of contact are D.N. Weldon and B.A. Tague. ------------ Unfortunately there is no "UNIX/TS" page, but there is a "UNIX/RT" page which as of this issue was renamed from MERT. The description claims: "UNIX/RT was released 1Q79." References are given to some of the papers in the 1978 BSTJ issue and to the PWB/UNIX User's Manual. The contacts are again given as Weldon and Tague. ------------ The only other UNIX version directly documented is PWB/UNIX. The description given is quite interesting, here's a couple excerpts: "The Programmer's Workbench is a computing facility that provides a convenient working environment and a uniform set of tools for computer program development and text processing. It is based on Bell Laboratories UNIX Time-Sharing System (UNIX/TS), so it is more properly known as PWB/UNIX. PWB/UNIX has several component systems, each of which augments thr capabilities of UNIX/TS to provide the desired software development and text processing environment." ... "PWB/UNIX is a time sharing system released and supported by Bell Laboratories Area 90." The status goes on to indicate the first installation was in October 1973. The "software" field, which on many other pages indicates the OS environment something runs in, for this one lists simply UNIX/TS. Finally the contacts include D.N. Weldon again as well as H.T. Gibson. Again unfortunately no corresponding UNIX/TS entry is to he found in this manual, but between the USG PGIII page and PWB/UNIX description, it all makes UNIX/TS sound like the next Program Generic, on which more complex systems like PWB/UNIX and UNIX/RT are then rebased sometime in late '78. That is just a hunch though, UNIX/TS remains an elusive figure, but there may be other systems in here built on top of UNIX/TS that shed a bit more light. One possible assumption from this too is that UNIX/TS might have looked a bit like PWB/UNIX, just without RJE, SCCS, MRCS (Modification Request Control System), and troff and the rest of DWB, as these are all listed as component systems layered on top of UNIX/TS. ------------ One honorable mention is the COSMOS system, which is given here as having been first installed 1Q74 and running on the "COSMIX" modified version of UNIX. No corresponding COSMIX page is in here so unfortunately can't chase that much further. For the record there is a lot of other software listed in here, all sorts of Bell System stuff from accounting software to various information management systems about things like vehicle fleets, inventory, HR software, quite a lot of stuff. The systems used are also wide and varied, with various DEC PDP models, IBM 360/370 and Amdahl work-alikes, Honeywell and GE systems, and several custom operating systems and hardware platforms like various ESS central controls and auxiliary processors. It interestingly looks to be typeset with some IBM system rather than UNIX, the text is all caps and layout reminds me of some IBM software catalogs from around the same time. Maybe the database was started on non-UNIX systems so is likewise typeset from those systems. Unfortunately there's no date listings of the previous issues. Anywho, there are probably plenty more nuggets in here but wanted to share those bits especially since they pertain to UNIX/TS. Lastly, what was not present were any mentions of Research UNIX, CB-UNIX, 32V, LSX, Mini-UNIX, or 3B systems, at least in what I've looked through thus far. If I find any more interesting bits I'll be sure to share them. If you know of some arcane Bell System software that you'd like me to look for in the manual, feel free to email me outside TUHS and I can target those pages for preservation first. - Matt G. From tuhs at tuhs.org Sat Oct 11 12:32:25 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 11 Oct 2025 13:32:25 +1100 Subject: [TUHS] Some 1980 Bell System UNIX Descriptions In-Reply-To: References: Message-ID: On Sat, Oct 11, 2025 at 12:57:25AM +0000, segaloco via TUHS wrote: > I've just today received Bell System Information and Operations > Systems, March 1980, Issue 4, and several UNIX variants are listed > therein. Here I'll compile a few excerpts until such time as I can > scan this. > > ------------ > > First, simply "UNIX" in this manual refers to the USG Program Generic > version. From the description: > > "Issue 3 was released as a standard product in 1977. UNIX has been > superseded by UNIX/TS in 4Q78." > > The status is given as becoming supported Bell Labs project 4Q73 > (so referring to Program Generic starting in 1973?) and first > supported as an "OTC" project 1Q76. The only document reference > is given as "Western Electric Generic Program PG1C300", and the > points of contact are D.N. Weldon and B.A. Tague. > > ------------ > > Unfortunately there is no "UNIX/TS" page, but there is a "UNIX/RT" > page which as of this issue was renamed from MERT. The description > claims: > > "UNIX/RT was released 1Q79." > > References are given to some of the papers in the 1978 BSTJ issue > and to the PWB/UNIX User's Manual. The contacts are again given > as Weldon and Tague. > > ------------ > > The only other UNIX version directly documented is PWB/UNIX. The > description given is quite interesting, here's a couple excerpts: > > "The Programmer's Workbench is a computing facility that provides > a convenient working environment and a uniform set of tools for > computer program development and text processing. It is based on > Bell Laboratories UNIX Time-Sharing System (UNIX/TS), so it is more > properly known as PWB/UNIX. PWB/UNIX has several component systems, > each of which augments thr capabilities of UNIX/TS to provide the > desired software development and text processing environment." > > ... > > "PWB/UNIX is a time sharing system released and supported by Bell > Laboratories Area 90." > > The status goes on to indicate the first installation was in October > 1973. The "software" field, which on many other pages indicates > the OS environment something runs in, for this one lists simply > UNIX/TS. Finally the contacts include D.N. Weldon again as well > as H.T. Gibson. > > Again unfortunately no corresponding UNIX/TS entry is to he found > in this manual, but between the USG PGIII page and PWB/UNIX > description, it all makes UNIX/TS sound like the next Program > Generic, on which more complex systems like PWB/UNIX and UNIX/RT > are then rebased sometime in late '78. That is just a hunch though, > UNIX/TS remains an elusive figure, but there may be other systems > in here built on top of UNIX/TS that shed a bit more light. One > possible assumption from this too is that UNIX/TS might have looked > a bit like PWB/UNIX, just without RJE, SCCS, MRCS (Modification > Request Control System), and troff and the rest of DWB, as these > are all listed as component systems layered on top of UNIX/TS. John Mashey described the relationship between PWB and TS in a May 1985 post to net.unix-wizards. https://www.tuhs.org/Usenet/comp.unix.wizards/1985-May/008079.html https://groups.google.com/g/net.unix-wizards/c/SLkG4v3wnuA/m/pgRSP-zc5AIJ "PWB/UNIX 1.0 was a Version 6-based system, as was 1.1 & 1.2; only 1.0 was released outside, as I recall [which was too bad: 1.2 was a really clean, well-tuned V6]. UNIX/TS 1.0 [my manual says Nov 78] was basically V7 + few kernel changes derived from PWB + some USG Generic 3 stuff. It's goal was to get at least the time-sharing kernel interface standard. It didn't have SCCS & other PWB major user-level subsystems, although little things crept in. PWB/UNIX 2.0 [June 1979] was UNIX/TS 1.0 + the rest of the PWB stuff. UNIX 3.0 [June 1980] was System III. Note there was no UNIX 2.0, whose number was taken by the last PWB release. Most of PWB/UNIX 2.0 was included." Pirzada's thesis (pp 38-39, 42-43) gives some more background: "In June, a task force (called the MOPS committee) set up to standardise the use of minicomputer operating systems in the Bell System recommended that PWB and USG UNIX should be combined into UNIX/TS (for Time Shared), which would be based on v7" p 65 "release descriptions for 1.0, 1.2, 2.0 and 2.1 and manuals for 1.0, 1.1, 1.2 and 2.0 were discovered with ex-PWB staff." From tuhs at tuhs.org Sat Oct 11 13:26:56 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Sat, 11 Oct 2025 03:26:56 +0000 (GMT) Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> Message-ID: <07c2c5aa-79ca-405a-a18c-b8b728935a0a@me.com> Wow, I thought I went through a lot of mergers and acquisitions, that's wild. On Oct 10, 2025, at 1:27 PM, Ron Natalie wrote: We worked with these guys for years. First IBM Federal Sector, then Federal Systems, then Loral, then Lockmart, then Leidos, My contact there said he’s worked for different companies without ever changing his office. I still have an IBM badge/door card from my days there. Of course, we joked about it, but my company was not much better. We were part of BDS, then spun out as KTS, then back into BDS, and then merged with BTG, then spun out again as Sensor Systems, then merged with Austin Information Systems to form Overwatch Systems (also picking up Visual Learning Systems, Paragon Imaging, and IT Spatial), and then got bought out by Textron. All along the way I did several UNIX ports, several X Server Ports, some Novell Drivers, all while developing our image processing products (intelligence and medical research). ------ Original Message ------ From "Andy Wallis" To "Natalie Ron" Cc "GARY LUCKENBAUGH" ; "segaloco" ; tuhs at tuhs.org Date 10/9/2025 11:27:15 PM Subject Re: [TUHS] Re: Government-Issue UNIX? IBM Federal Systems got sold off to Loral then Lockheed and is now owned by Leidos. The Gaithersburg plant was partially torn down to make way for a FedEx or UPS depot. There are still a number of ex IBM FS people still working at Leidos. I think Gary worked with me in the FAA ATC programs if it the same person I remember. It is still very much a UNIX shop. AIX has been replaced by RHEL. That place gave me my love of AIX from our FAA programs going back to AAS to ERAM. -Andy Wallis On Oct 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: I was consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was dealing with there. On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS wrote: BTW, Ron Natalie, where did you work on IBM Secure Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't remember. My 68 y/o brain isn't what it used to be. Gary Luckenbaugh Sent from my iPhone On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS wrote: I was the lead developer on IBM Secure Xenix. I designed all the APIs and did much of the kernel work from Jan 1984 until 1989 when we handed off the project to Steve Walker's Trusted Information Systems. My dream job was to work on the Unix kernel, and by some miracle I got to do that at IBM. I was the first IBMer on the project and the last off. This was my first job out of graduate school. My thesis advisor, Virgil Gligor, was an IBM consultant, and he knew they were looking for kernel developers, dare I say kernel hacker. Besides my advisor, and my IBM manager, I was the only one working the project until the summer of 1984 when we brought in two PhDs to work the project, one was from IBM's Yorktown Research Division, and one was a hire from AT&T Naperville. I was the only one with knowledge of the Unix kernel. I was two steps down the ladder from the guys with PhDs, but my manager quickly figured out I was the only one that really knew what I was doing. I got really annoyed with the analysis paralysis. I decided I had enough of that, and implemented the Mandatory Access Controls over a weekend. 😆 That project was a heck of a lot of fun, and the highlight of my career. I was one of IBM's first Unix people, and I got to run all around the corporation giving talks. My home base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a lot of time at IBM's Advanced Workstation Division in Austin, TX the home of IBM's AIX. Gary Luckenbaugh Sent from my iPhone On Oct 9, 2025, at 5:44 PM, segaloco via TUHS wrote: On Fri, 10 Oct 2025, at 01:35, Jon Forrest via TUHS wrote: KSOS was made from scratch at Ford Aerospace in the late 1970s. I was in the group that did it, although I didn't work on it because I didn't have a security clearance. There seems to be an IEEE paper on this, though I’ve not read it yet. Hate it when things need a login :-( Do you know where it belonged on the spectrum from “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? Intrigued, John Fwiw the manual I have on hand is just for the kernel API, so I couldn't say. On a quick flip-through, the sections appear to have been rearranged (.e.g Section I describes datatypes used by syscalls) and in none of the sections did I spot anything particularly resembling userland applications, although I think the API documentation includes non-syscall entrypoints implying parts of a userland C library. - Matt G. From tuhs at tuhs.org Sat Oct 11 14:22:47 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Oct 2025 04:22:47 +0000 Subject: [TUHS] Some 1980 Bell System UNIX Descriptions In-Reply-To: References: Message-ID: On Friday, October 10th, 2025 at 19:32, Jonathan Gray via TUHS wrote: > UNIX/TS 1.0 [my manual says Nov 78] was basically V7 + few kernel changes > derived from PWB + some USG Generic 3 stuff. It's goal was to get at least the > time-sharing kernel interface standard. It didn't have SCCS & other PWB > major user-level subsystems, although little things crept in. Do you mean you have a UNIX/TS manual or is this in reference to the acknowledgements in the PWB 1.0 manual? > "release descriptions for 1.0, 1.2, 2.0 and 2.1 and manuals for > 1.0, 1.1, 1.2 and 2.0 were discovered with ex-PWB staff." Something I often wonder about Pirzada's work, there is mention of all of these documents and versions but that does beg the question if any of these specimens were followed up on and scanned/preserved in any way as part of the work. PWB 2.0, PG III, and UNIX/TS would fill large holes in my mandiff efforts. - Matt G. From tuhs at tuhs.org Sat Oct 11 14:34:49 2025 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 11 Oct 2025 15:34:49 +1100 Subject: [TUHS] Some 1980 Bell System UNIX Descriptions In-Reply-To: References: Message-ID: On Sat, Oct 11, 2025 at 04:22:47AM +0000, segaloco via TUHS wrote: > On Friday, October 10th, 2025 at 19:32, Jonathan Gray via TUHS wrote: > > > UNIX/TS 1.0 [my manual says Nov 78] was basically V7 + few kernel changes > > derived from PWB + some USG Generic 3 stuff. It's goal was to get at least the > > time-sharing kernel interface standard. It didn't have SCCS & other PWB > > major user-level subsystems, although little things crept in. > > Do you mean you have a UNIX/TS manual or is this in reference to the > acknowledgements in the PWB 1.0 manual? That text, including the asides, is from Mashey. The date would likely be from the title page. From tuhs at tuhs.org Sat Oct 11 20:13:12 2025 From: tuhs at tuhs.org (Niklas Karlsson via TUHS) Date: Sat, 11 Oct 2025 12:13:12 +0200 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <07c2c5aa-79ca-405a-a18c-b8b728935a0a@me.com> References: <629EA22F-D678-4D54-837C-438F6E19D1F7@ronnatalie.com> <07c2c5aa-79ca-405a-a18c-b8b728935a0a@me.com> Message-ID: AGH! Whatever you're using to send mail seems to have eaten all newlines in your message, including what you're quoting. Do you think you could try and fix that? Because as it is, your message is basically unreadable. /Niklas Den lör 11 okt. 2025 kl 05:27 skrev GARY LUCKENBAUGH via TUHS : > Wow, I thought I went through a lot of mergers and acquisitions, that's > wild. On Oct 10, 2025, at 1:27 PM, Ron Natalie > wrote: We worked with these guys for years. First IBM Federal Sector, then > Federal Systems, then Loral, then Lockmart, then Leidos, My contact there > said he’s worked for different companies without ever changing his office. > I still have an IBM badge/door card from my days there. Of course, we joked > about it, but my company was not much better. We were part of BDS, then > spun out as KTS, then back into BDS, and then merged with BTG, then spun > out again as Sensor Systems, then merged with Austin Information Systems to > form Overwatch Systems (also picking up Visual Learning Systems, Paragon > Imaging, and IT Spatial), and then got bought out by Textron. All along the > way I did several UNIX ports, several X Server Ports, some Novell Drivers, > all while developing our image processing products (intelligence and > medical research). ------ Original Message ------ From "Andy Wallis" < > rawallis at panix.com> To "Natalie Ron" Cc "GARY > LUCKENBAUGH" ; "segaloco" ; > tuhs at tuhs.org Date 10/9/2025 11:27:15 PM Subject Re: [TUHS] Re: > Government-Issue UNIX? IBM Federal Systems got sold off to Loral then > Lockheed and is now owned by Leidos. The Gaithersburg plant was partially > torn down to make way for a FedEx or UPS depot. There are still a number of > ex IBM FS people still working at Leidos. I think Gary worked with me in > the FAA ATC programs if it the same person I remember. It is still very > much a UNIX shop. AIX has been replaced by RHEL. That place gave me my love > of AIX from our FAA programs going back to AAS to ERAM. -Andy Wallis On Oct > 9, 2025, at 10:28 PM, Ron Natalie via TUHS wrote: I was > consulting for IBM FSC (Gaithersburg MD). Tom Wellington was who I was > dealing with there. On Oct 9, 2025, at 21:30, GARY LUCKENBAUGH via TUHS < > tuhs at tuhs.org> wrote: BTW, Ron Natalie, where did you work on IBM Secure > Xenix? I'm surprised we didn't cross paths. Maybe we did, and I just don't > remember. My 68 y/o brain isn't what it used to be. Gary Luckenbaugh Sent > from my iPhone On Oct 9, 2025, at 9:11 PM, GARY LUCKENBAUGH via TUHS < > tuhs at tuhs.org> wrote: I was the lead developer on IBM Secure Xenix. I > designed all the APIs and did much of the kernel work from Jan 1984 until > 1989 when we handed off the project to Steve Walker's Trusted Information > Systems. My dream job was to work on the Unix kernel, and by some miracle I > got to do that at IBM. I was the first IBMer on the project and the last > off. This was my first job out of graduate school. My thesis advisor, > Virgil Gligor, was an IBM consultant, and he knew they were looking for > kernel developers, dare I say kernel hacker. Besides my advisor, and my IBM > manager, I was the only one working the project until the summer of 1984 > when we brought in two PhDs to work the project, one was from IBM's > Yorktown Research Division, and one was a hire from AT&T Naperville. I was > the only one with knowledge of the Unix kernel. I was two steps down the > ladder from the guys with PhDs, but my manager quickly figured out I was > the only one that really knew what I was doing. I got really annoyed with > the analysis paralysis. I decided I had enough of that, and implemented the > Mandatory Access Controls over a weekend. 😆 That project was a heck of a > lot of fun, and the highlight of my career. I was one of IBM's first Unix > people, and I got to run all around the corporation giving talks. My home > base was IBM Federal Systems Division in Gaithersburg, MD, but I spent a > lot of time at IBM's Advanced Workstation Division in Austin, TX the home > of IBM's AIX. Gary Luckenbaugh Sent from my iPhone On Oct 9, 2025, at 5:44 > PM, segaloco via TUHS wrote: On Fri, 10 Oct 2025, at > 01:35, Jon Forrest via TUHS wrote: KSOS was made from scratch at Ford > Aerospace in the late 1970s. I was in the group that did it, although I > didn't work on it because I didn't have a security clearance. There seems > to be an IEEE paper on this, though I’ve not read it yet. Hate it when > things need a login :-( Do you know where it belonged on the spectrum from > “zero AT&T code” to “new kernel but overwhelmingly AT&T userland”? > Intrigued, John Fwiw the manual I have on hand is just for the kernel API, > so I couldn't say. On a quick flip-through, the sections appear to have > been rearranged (.e.g Section I describes datatypes used by syscalls) and > in none of the sections did I spot anything particularly resembling > userland applications, although I think the API documentation includes > non-syscall entrypoints implying parts of a userland C library. - Matt G. From tuhs at tuhs.org Sun Oct 12 02:40:11 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sat, 11 Oct 2025 10:40:11 -0600 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: <202510101419.59AEJUnH092698@freefriends.org> Message-ID: <202510111640.59BGeBth004240@freefriends.org> Yes. He is two years older than I am, so I don't know him particularly well. But his father still lives down the street from my parents. :-) Arnold GARY LUCKENBAUGH via TUHS wrote: > Oh yes, was it David Arnovitz at Secure Ware I believe. I remember > congratulating him when HP acquired them, but I gather other than the > money, he didn't care much for HP. > > Gary Luckenbaugh > Sent from my iPhone > > > On Oct 10, 2025, at 10:19 AM, Arnold Robbins via TUHS wrote: > > > > HP sounds right. I know 2 of the people who did SecureWare; one of them > > grew up down the street from me and is now a Jerusalem-based venture > > capitalist. :-) > > > > Arnold > > > > GARY LUCKENBAUGH via TUHS wrote: > > > >> There were quite a few secure products in the 80s. There was set of requirements promulgated by the Defense Intelligence Agency (defined by Mitre) for a Compartmented Mode Workstation. In the late 80s IBM, DEC, and HP had CMW offerings along with an Atlanta startup named Secure Ware that built a CMW based on a Unix system that ran on an Apple Mac. I believe it was A/UX. At IBM we licensed the Secure Ware product and had them port it to IBM's AIX. > >> > >> Our group in IBM Federal was responsible for the fork of AIX that resulted from the Secure Ware port. We also were responsible for getting the product certified by the DIA. We had many joint meetings with IBM, DEC, HP and the DIA. I was IBM's representative at those meetings. > >> > >> I believe HP went on to acquire Secure Ware. I asked Perplexity.AI about that and it blew a fuse. 😆 > >> > >> Gary Luckenbaugh > >> > >> Sent from my iPhone > >> > >>>> On Oct 9, 2025, at 7:58 AM, Douglas McIlroy via TUHS wrote: > >>> > >>> When Jim Reeds and I were making the IX multilevel-secure Unix > >>> (1987-88), an Orange-Book-compliant Unix was being made for the > >>> government at BTL's Whippany Lab. There was some communication between > >>> the two projects, but different objectives led to significantly > >>> different systems. > >>> > >>> Did the Whippany product become KSOS, or did DOD end up with two > >>> "secure" Unixes? > >>> > >>> Doug From tuhs at tuhs.org Sun Oct 12 03:21:07 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Sat, 11 Oct 2025 13:21:07 -0400 Subject: [TUHS] My iPhone Message-ID: My iPhone apparently flipped out in quoting an email I responded to. I'll see if I can fix it later today. Gary Sent from my iPhone From tuhs at tuhs.org Sun Oct 12 03:39:42 2025 From: tuhs at tuhs.org (GARY LUCKENBAUGH via TUHS) Date: Sat, 11 Oct 2025 13:39:42 -0400 Subject: [TUHS] My iPhone Message-ID: <40D8F8B5-C5B2-42EC-8A00-EA3372EAB117@icloud.com> You can safely ignore that corrupted email. I only intended to reply to Ron Natalie. It wasn't anything significant. I apologize for the confusion. I guess Apple products aren't as high quality as they would like you to believe. Gary Sent from my iPhone From tuhs at tuhs.org Sun Oct 12 05:44:56 2025 From: tuhs at tuhs.org (Stuff Received via TUHS) Date: Sat, 11 Oct 2025 15:44:56 -0400 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On 2025-10-09 01:28, Tom Perrine via TUHS wrote: > KSOS - for PDP-11 originally developed by Ford Aerospace, and then extended > at Logicon. It did have a supervisor rmode UNIX system call compatible > system. Later there was also a userland library that implemented something > that mostly matched the UNIX system calls. It had no kernel code in common > with UNIX. It was written in Modula. Interesing -- what compilers did you use? S. > > KSOS was used in the Trusted Downgrade System of the multi-level-secure > "all-source" intel fusion system that Logicon built for a few agencies. > ACCAT-GUARD and USAFE-GUARD, for example. > > KSOS-32 - a VAX "port" of KSOS (which was then retconned as "KSOS-11"). The > Modula code from -11 was run though Emacs macros to produce Modula-2, and > then parts were re-written as needed. > > I worked on both systems at Logicon. > > --tep > > > > On Wed, Oct 8, 2025 at 7:17 PM segaloco via TUHS wrote: > >> AT&T has had a variable relationship with governments over the years, >> especially the U.S. On one hand, Bell Laboratories collaborated with >> the government and military on an number of projects such as the Nike >> Missile and TelStar. On the other hand, the Bell System was under >> constant regulatory scrutiny that was eventually its undoing. >> >> Part of this has me wondering if there was ever an attempt by the U.S. >> or another government (that folks can discuss of course) to license with >> AT&T to create a government-issued version of UNIX. Something that >> immediately comes to mind is the KSOS secure UNIX version developed by >> the DoD from what I know. However, this would've been used internally, >> not something that the government would attempt to distribute en masse >> for day to day computer operations or directly to constituents. Another >> system that comes to mind, tangentially related, are the state-sponsored >> versions of GNU/Linux found in China and North Korea. Of course, AT&T >> doesn't factor in there because penguins, but still, it shows an >> interest in that sphere of influence also in providing a standardized >> operating system (to the benefit of users or state actors...unknown). >> >> Had this ever come up? Has (as a matter of public record) any >> government attempted to buy a source license from AT&T for UNIX and then >> produce their own state-sanctioned UNIX flavor? I would assume to >> produce KSOS, the DoD would've needed to hold one such source license, >> but that could be me being ignorant of special government contacts that >> exist in a wholly separate space from AT&T's commercial business. >> >> - Matt G. >> From tuhs at tuhs.org Sun Oct 12 08:05:12 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Sun, 12 Oct 2025 09:05:12 +1100 (EST) Subject: [TUHS] My iPhone In-Reply-To: <40D8F8B5-C5B2-42EC-8A00-EA3372EAB117@icloud.com> References: <40D8F8B5-C5B2-42EC-8A00-EA3372EAB117@icloud.com> Message-ID: On Sat, 11 Oct 2025, GARY LUCKENBAUGH via TUHS wrote: > You can safely ignore that corrupted email. I only intended to reply to > Ron Natalie. It wasn't anything significant. I apologize for the > confusion. I guess Apple products aren't as high quality as they would > like you to believe. As they say about most road accidents: they're caused by the nut behind the wheel. -- Dave, who doesn't boast about his iPhone (nor blame it) From tuhs at tuhs.org Sun Oct 12 12:00:25 2025 From: tuhs at tuhs.org (Tom Perrine via TUHS) Date: Sat, 11 Oct 2025 20:00:25 -0600 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: <051c0007-6559-4171-aa32-5ef38b511662@gmail.com> References: <051c0007-6559-4171-aa32-5ef38b511662@gmail.com> Message-ID: I have what should be the "final" source tree for KSOS - as it existed when the Logicon work finished. I will dig it up. What I'm missing is the toolchain - Modula compiler, etc. I don't think I have the VaX KSOS032, but I will look. I will dig it up after my vacation ends in 10 days or so. --tep (Tom Perrine) On Thu, Oct 9, 2025 at 6:05 PM Wesley Parish via TUHS wrote: > And the question that keeps recurring to my mind, is, what happened to > the source trees of these "exotic beasts" in the Unix menagerie? Any > chance they'd be freed any time soon? > > Wesley Parish > > On 10/10/2025 00:57, Douglas McIlroy via TUHS wrote: > > When Jim Reeds and I were making the IX multilevel-secure Unix > > (1987-88), an Orange-Book-compliant Unix was being made for the > > government at BTL's Whippany Lab. There was some communication between > > the two projects, but different objectives led to significantly > > different systems. > > > > Did the Whippany product become KSOS, or did DOD end up with two > > "secure" Unixes? > > > > Doug > From tuhs at tuhs.org Mon Oct 13 05:10:30 2025 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Sun, 12 Oct 2025 12:10:30 -0700 Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: On 10/11/25 12:44 PM, Stuff Received via TUHS wrote: > On 2025-10-09 01:28, Tom Perrine via TUHS wrote: >> KSOS - for PDP-11 originally developed by Ford Aerospace, and then >> extended >> at Logicon. It did have a supervisor rmode UNIX system call compatible >> system. Later there was also a userland library that implemented >> something >> that mostly matched the UNIX system calls. It had no kernel code in >> common >> with UNIX. It was written in Modula. > > Interesing -- what compilers did you use? What I remember is that it used Modula 2 from a group at the Univ. of York in the UK. I don't know for sure that this is the version of Modula 2 that eventually was used for the implementation but I think it was. Jon From tuhs at tuhs.org Tue Oct 14 07:07:34 2025 From: tuhs at tuhs.org (Skip Tavakkolian via TUHS) Date: Mon, 13 Oct 2025 14:07:34 -0700 Subject: [TUHS] Whitesmiths Idris for Atari ST Message-ID: For anyone interested, the installation floppies for Idris-ST with X10 R4 are here: https://github.com/9nut/IDRIS-OS-for-Atari-ST It runs in Hatari emulator (sort of) and reported to run in PCE. -Skip From tuhs at tuhs.org Wed Oct 15 01:51:01 2025 From: tuhs at tuhs.org (Brian Walden via TUHS) Date: Wed, 15 Oct 2025 01:51:01 +1000 (AEST) Subject: [TUHS] Government-Issue UNIX? In-Reply-To: References: Message-ID: <176045705229.996466.7134185051487033518@minnie.tuhs.org> Sorry New York Comic-Con started last Thursday, but now that it is done, a compressed tar tree for SVMLS, System V/Multi-Level Security, the Orange Book changes by Bell Labs' Whippany Federal Systems from mid 1988 has somehow appeared in the wild at https://www.mediafire.com/file/7b5hp5gyl8k6uk4/svmls.tgz/file But act fast, as it will only be available for the next 14 days and then will be auto-deleted. It's small at under 200K, as it was intentionally kept lean, with the kernel changes under uts/ (the orig files are there too for an easy diff) and the security audit trail (sat) utilities under cmd/ > Douglas McIlroy via TUHS wrote: > When Jim Reeds and I were making the IX multilevel-secure Unix > (1987-88), an Orange-Book-compliant Unix was being made for the > government at BTL's Whippany Lab. There was some communication between > the two projects, but different objectives led to significantly > different systems. > > Did the Whippany product become KSOS, or did DOD end up with two > "secure" Unixes? > > Doug From tuhs at tuhs.org Wed Oct 15 04:26:00 2025 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Tue, 14 Oct 2025 14:26:00 -0400 Subject: [TUHS] "Preserving the legacy of Usenix ATC" Message-ID: Usenix met with ACM SIGOPS who wanted to learn about what it's like to hold an annual conference. Usenix doesn't have trademark or copyright on the term "ATC" but would like to see an ongoing commitment to its ideals. Many of us here got the email. If you didn't, it is on their website: https://www.usenix.org/blog/preserving-legacy-usenix-atc From tuhs at tuhs.org Wed Oct 15 07:38:59 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 14 Oct 2025 17:38:59 -0400 Subject: [TUHS] Fwd: Preserving the Legacy of USENIX ATC In-Reply-To: References: Message-ID: FYI ---------- Forwarded message --------- From: Casey Henderson-Ross Date: Tue, Oct 14, 2025 at 1:49 PM Subject: Preserving the Legacy of USENIX ATC To: Clement T Cole Read on for important update on the ATC name. [image: USENIX, the Advanced Computing Systems Association] Hello, The USENIX Annual Technical Conference (ATC) was a cornerstone of the USENIX community and a central gathering point for systems researchers and practitioners for fifty years. It provided a unique opportunity to blend deep scientific research with practical systems work. USENIX ATC was more than a venue for publishing research, and embodied the core ideals of USENIX itself. The decision to end the conference followed decades of experimentation to revitalize it, including a final effort to co-locate it with OSDI. As detailed in our earlier statement , USENIX ATC's evolution mirrored the maturing of the systems field, with many topics once housed primarily within USENIX ATC or other general systems conferences now served by specialized USENIX conferences. At the same time, SOSP and OSDI—two general systems conferences typically viewed as more prestigious—are now annual offerings, after long histories of being offered biennially. Over time, USENIX ATC declined to the point where, in 2024: - Only 165 people attended, where once we had over a thousand - 52 percent of those attendees were accepted authors - 91 percent of those authors required support from USENIX grant and discount programs to attend - In aggregate, there was only 28 percent attendance of registered attendees in the USENIX ATC conference sessions Given the experience this created for both presenters and attendees, the USENIX ATC Steering Committee and the USENIX Board of Directors concluded that, while there was still a strong and growing demand to *publish* research, a generalist North American-based practical systems *conference* of USENIX ATC's stature was no longer viable under the ideals that USENIX is committed to upholding, such as open access. As a result, we decided to discontinue USENIX ATC and incorporate a portion of its research topics with a practical bias into other USENIX conferences. Meanwhile, following the announcement of the final USENIX ATC conference, discussions emerged within the larger systems research community about launching a new conference with a similar focus. While these efforts developed independently of the USENIX Board, the request from ACM SIGOPS to reuse the "ATC" name prompted us to reengage with the broader USENIX ATC community to listen to their perspectives. Unsurprisingly, there was universal agreement with needing a venue to publish research. Some emphasized the value of the "ATC" name as a symbolic asset in establishing the new conference. Others expressed concern that using the name without maintaining its defining values could dilute its meaning or create confusion. Still others questioned whether a conference was still the right model going forward. These conversations affirmed both the legacy of USENIX ATC and the responsibility that comes with invoking it. The USENIX Board gave serious thought to how best to respond to the differing needs and desires of our community. As part of that deliberation, members of the USENIX Board and USENIX ATC Steering Committee welcomed the opportunity to meet with ACM SIGOPS leadership to share the financial and organizational realities of sustaining a conference grounded in the values of USENIX ATC. We wanted any organization considering a similar event to be aware of the conditions that caused us to bring the conference to a close. We recognize that other organizations may work under different constraints. And while USENIX does not hold a trademark or copyright on "ATC" or "Annual Technical Conference" and cannot prevent others from using the name, we believe doing so carries a responsibility. Any future event that seeks to adopt the "ATC" name should stand for more than just its technical focus. It should reflect a commitment to the ideals that made USENIX ATC a trusted, community-driven conference for five decades, including: - A high-quality, impartial peer review process that values technical depth and practical systems impact - Full free and open access to all recorded and published content, with no publication or subscription fees for individuals or organizations - Financial support for authors to reduce barriers to participation - A strong, enforced code of conduct that ensures an inclusive and respectful environment We believe that direct involvement from a significant portion of past USENIX ATC Steering Committee members and strong support from any organization who chooses to use the ATC name would help maintain continuity and uphold these shared ideals. As an organization, USENIX is proud of what USENIX ATC stood for and of the passionate community that sustained it for so long. We also remain committed to supporting systems researchers through our ongoing and future conferences. [image: Casey Henderson headshot] Best Regards, Casey Henderson-Ross Executive Director USENIX Association About this mailing list: You are receiving this email because you are or have been a member of USENIX, have attended USENIX conferences, or have signed up to receive emails from USENIX. USENIX never shares, sells, rents, or exchanges email addresses of its members, conference attendees, and other constituents. Review our privacy policy . We would like to continue sending you occasional email announcements like this one. However, if you no longer want to receive emails from USENIX, please click here to opt out of all communications from USENIX. If you have any questions about the mailing list, please email info at usenix.org. We may also be reached via postal mail: USENIX Association 2443 Fillmore St, #380-25600, San Francisco, CA 94115-1814, USA From tuhs at tuhs.org Wed Oct 15 14:48:11 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Tue, 14 Oct 2025 21:48:11 -0700 Subject: [TUHS] The oldest user@host email on Unix Message-ID: Around 50 years ago my Unix username was minnich. Once email became internet aware, I was minnich at udel. At some point, Mike Minnich appeared at Udel (my "pseudo brother" as he and I put it), I left udel, and mminnich at udel and minnich at udel emails got crossed, frequently. So about 42 years ago, I became rminnich. Remembering this got me to wondering: what was that first email address, in user at host form, on Unix? From tuhs at tuhs.org Wed Oct 15 23:26:02 2025 From: tuhs at tuhs.org (Lawrence Stewart via TUHS) Date: Wed, 15 Oct 2025 09:26:02 -0400 Subject: [TUHS] The oldest user@host email on Unix In-Reply-To: References: Message-ID: <3B3E4ED6-0755-4688-8B6A-32D70FCC5002@serissa.com> There are lots of email addresses of that form in the December 1978 Arpanet directory. Many of them @RAND-UNIX @ILL-UNIX, @SRI-UNIX etc. https://vtda.org/docs/computing/DefenceCommsAgency/ARAPNET_Directory_Dec78.pdf The 1975 Arpanet directory lists a couple (two) systems which sometimes run Unix, but they don’t appear in the user part of the directory. I’m listed in the ’78 directory as sysadmin of SU-ISL, which was an 11/34, later 11/45, running V6 and V7. We were connected to the Arpanet as a VDH from SUMEX. However, the directory shows my email as LY at SU-AI rather than SU-ISL. I think we didn’t have email working on our own machine yet. We got the net software from Rand, with the assistance of Steve Tepper. Prof. John Gill was pushing the Unix effort at ISL. He would also do fairly wacky things like hack the EPROMS in our cheap VDTs (Wyse? Hazeltine?) to make them usable with the Rand screen editor. -Larry > On Oct 15, 2025, at 12:48 AM, ron minnich via TUHS wrote: > > Around 50 years ago my Unix username was minnich. Once email became > internet aware, I was minnich at udel. > > At some point, Mike Minnich appeared at Udel (my "pseudo brother" as he and > I put it), I left udel, and mminnich at udel and minnich at udel emails got > crossed, frequently. So about 42 years ago, I became rminnich. > > Remembering this got me to wondering: what was that first email address, in > user at host form, on Unix? From tuhs at tuhs.org Thu Oct 16 02:28:25 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Wed, 15 Oct 2025 16:28:25 +0000 Subject: [TUHS] The oldest user@host email on Unix In-Reply-To: (ron minnich via TUHS's message of "Tue, 14 Oct 2025 21:48:11 -0700") References: Message-ID: <7wjz0w5due.fsf@junk.nocrew.org> Ron Minnich wrote: > Remembering this got me to wondering: what was that first email address, in > user at host form, on Unix? Some systems used the "user at host" form. That's atsign spelled out, with whitespace arond. For example "minsky at mit-ai". From tuhs at tuhs.org Thu Oct 16 03:41:39 2025 From: tuhs at tuhs.org (Jeff Johnson via TUHS) Date: Wed, 15 Oct 2025 13:41:39 -0400 Subject: [TUHS] The oldest user@host email on Unix In-Reply-To: <7wjz0w5due.fsf@junk.nocrew.org> References: <7wjz0w5due.fsf@junk.nocrew.org> Message-ID: <4fd4d9c4-5988-4f46-9424-42f720ba268c@app.fastmail.com> The convention for intersystem mail that used '@' on Multics was “-at” (i.e. "mail user -at host"). This was done for convenience so as to not interfere with the default line kill character which was “@“. -- Jeffrey H. Johnson trnsz at pobox.com On Wed, Oct 15, 2025, at 12:28 PM, Lars Brinkhoff via TUHS wrote: > Ron Minnich wrote: >> Remembering this got me to wondering: what was that first email address, in >> user at host form, on Unix? > > Some systems used the "user at host" form. That's atsign spelled out, > with whitespace arond. For example "minsky at mit-ai". From tuhs at tuhs.org Fri Oct 17 21:42:25 2025 From: tuhs at tuhs.org (Aharon Robbins via TUHS) Date: Fri, 17 Oct 2025 14:42:25 +0300 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question Message-ID: Hello All. A bit off-topic, perhaps, but thoughts from this crowd would be welcome. I just finished tracking down a bug in gawk that was only noticed because the Windows port is built without -DNEBUG, causing assertions (via assert(3)) to be included in the code. The regular *nix build defines NDEBUG, so that assertions are not included in the regular, "production" build. Now, I can understand why assert() and NDEBUG work the way they do. Particularly on the small PDP-11s on which C and Unix were developed, it made sense to have a way to remove assertions from code that would be installed for all users. However, I'm starting to wonder. Are my habits from yesteryear (defining NDEBUG by default) getting in the way of my being able (or users being able) to find bugs and report them? Should I remove the defining of NDEBUG from the default build? In particular, given the many orders of magnitude increase in CPU and memory of modern systems, is it likely that assertions won't really affect performance all that much? I'm starting to think that the answer is yes, it's time to remove NDEBUG. But I'm curious what the experienced developers here might think. Much thanks, Arnold From tuhs at tuhs.org Fri Oct 17 21:56:15 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 17 Oct 2025 07:56:15 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: FWIW: assertions are like a PFD (a.k.a. Personal floation device or life preserver). Going with a PFD is never a good idea, particularly if you are in open waters, as you never know when you could accidentally get washed overboard. Sent from a handheld expect more typos than usual On Fri, Oct 17, 2025 at 7:42 AM Aharon Robbins via TUHS wrote: > Hello All. > > A bit off-topic, perhaps, but thoughts from this crowd would be welcome. > > I just finished tracking down a bug in gawk that was only noticed > because the Windows port is built without -DNEBUG, causing assertions > (via assert(3)) to be included in the code. The regular *nix build > defines NDEBUG, so that assertions are not included in the regular, > "production" build. > > Now, I can understand why assert() and NDEBUG work the way they do. > Particularly on the small PDP-11s on which C and Unix were developed, > it made sense to have a way to remove assertions from code that would > be installed for all users. > > However, I'm starting to wonder. Are my habits from yesteryear (defining > NDEBUG by default) getting in the way of my being able (or users being > able) to find bugs and report them? Should I remove the defining of > NDEBUG from the default build? In particular, given the many orders of > magnitude increase in CPU and memory of modern systems, is it likely > that assertions won't really affect performance all that much? > > I'm starting to think that the answer is yes, it's time to remove > NDEBUG. But I'm curious what the experienced developers here > might think. > > Much thanks, > > Arnold > From tuhs at tuhs.org Fri Oct 17 21:58:07 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 17 Oct 2025 07:58:07 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: Going >>without<< a PFD — dyslexia-R-me Sent from a handheld expect more typos than usual On Fri, Oct 17, 2025 at 7:56 AM Clem Cole wrote: > FWIW: assertions are like a PFD (a.k.a. Personal floation device or life > preserver). Going with a PFD is never a good idea, particularly if you are > in open waters, as you never know when you could accidentally get washed > overboard. > > Sent from a handheld expect more typos than usual > > > On Fri, Oct 17, 2025 at 7:42 AM Aharon Robbins via TUHS > wrote: > >> Hello All. >> >> A bit off-topic, perhaps, but thoughts from this crowd would be welcome. >> >> I just finished tracking down a bug in gawk that was only noticed >> because the Windows port is built without -DNEBUG, causing assertions >> (via assert(3)) to be included in the code. The regular *nix build >> defines NDEBUG, so that assertions are not included in the regular, >> "production" build. >> >> Now, I can understand why assert() and NDEBUG work the way they do. >> Particularly on the small PDP-11s on which C and Unix were developed, >> it made sense to have a way to remove assertions from code that would >> be installed for all users. >> >> However, I'm starting to wonder. Are my habits from yesteryear (defining >> NDEBUG by default) getting in the way of my being able (or users being >> able) to find bugs and report them? Should I remove the defining of >> NDEBUG from the default build? In particular, given the many orders of >> magnitude increase in CPU and memory of modern systems, is it likely >> that assertions won't really affect performance all that much? >> >> I'm starting to think that the answer is yes, it's time to remove >> NDEBUG. But I'm curious what the experienced developers here >> might think. >> >> Much thanks, >> >> Arnold >> > From tuhs at tuhs.org Fri Oct 17 22:22:23 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 17 Oct 2025 08:22:23 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: On Fri, Oct 17, 2025 at 7:50 AM Aharon Robbins via TUHS wrote: > Hello All. > > A bit off-topic, perhaps, but thoughts from this crowd would be welcome. > > I just finished tracking down a bug in gawk that was only noticed > because the Windows port is built without -DNEBUG, causing assertions > (via assert(3)) to be included in the code. The regular *nix build > defines NDEBUG, so that assertions are not included in the regular, > "production" build. > > Now, I can understand why assert() and NDEBUG work the way they do. > Particularly on the small PDP-11s on which C and Unix were developed, > it made sense to have a way to remove assertions from code that would > be installed for all users. > > However, I'm starting to wonder. Are my habits from yesteryear (defining > NDEBUG by default) getting in the way of my being able (or users being > able) to find bugs and report them? Should I remove the defining of > NDEBUG from the default build? In particular, given the many orders of > magnitude increase in CPU and memory of modern systems, is it likely > that assertions won't really affect performance all that much? > > I'm starting to think that the answer is yes, it's time to remove > NDEBUG. But I'm curious what the experienced developers here > might think. > > Much thanks, My own two bit non-answer: it depends on what you're asserting and how often. I think whether or not one compiles out assertions should be guided by profiling: if setting NDEBUG results in a substantial speedup, and that's important (ie, the speedup is a critical path or of some kind), then set NDEBUG. On the other hand, if the performance difference is negligible, or even just small, I would preserve them. I do think our default these days should be to leave assertions in unless it's shown to be a substantial drag. One must question whether `assert` is the right thing or not, though; as an interface, it's pretty limited: a thing can either be true or not, but any surrounding information is not preserved; for example, one often wants to assert whether two things are equal, but if they are not, it's often very useful to know what the actual values are: `assert` doesn't give you that. One also wishes for a non-optional assertion that is always executed; perhaps `assert_always` or something (the illumos kernel inherited `ASSERT` and `VERIFY` from Solaris; `ASSERT` is compiled-out in non-debug builds, but `VERIFY` is always executed). I suppose the alternative in both cases is an explicit check against an expected condition and calling some kind of failure routine if the condition is not met. I do have a history question, though; `assert` seems to have found its way into Unix in 7th Edition. It's used most heavily in `refer`, and appears in exactly one place in `sh` (but `sh` defines it to just be `;`). A few other places define a macro called `ASSERT` (or a variation of that) that does more or less the same thing: `struct`, `uucp`, and a couple of places in the Fortran-77 compiler/library. There doesn't appear to be any history of it prior to v7. Who added it, and why? - Dan C. From tuhs at tuhs.org Sat Oct 18 00:01:15 2025 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 17 Oct 2025 07:01:15 -0700 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: <20251017140115.GN20133@mcvoy.com> In my retirement, I've discovered fishing on the ocean. And I've built up a little group of hand selected friends. One attribute we all share is PFD is always on. It goes off as things warm up and we shed our foul weather gear, but it goes right back on. I've hosted some people who don't share that idea, but only hosted them once. On Fri, Oct 17, 2025 at 07:58:07AM -0400, Clem Cole via TUHS wrote: > Going >>without<< a PFD ??? dyslexia-R-me > > Sent from a handheld expect more typos than usual > > > On Fri, Oct 17, 2025 at 7:56???AM Clem Cole wrote: > > > FWIW: assertions are like a PFD (a.k.a. Personal floation device or life > > preserver). Going with a PFD is never a good idea, particularly if you are > > in open waters, as you never know when you could accidentally get washed > > overboard. > > > > Sent from a handheld expect more typos than usual > > > > > > On Fri, Oct 17, 2025 at 7:42???AM Aharon Robbins via TUHS > > wrote: > > > >> Hello All. > >> > >> A bit off-topic, perhaps, but thoughts from this crowd would be welcome. > >> > >> I just finished tracking down a bug in gawk that was only noticed > >> because the Windows port is built without -DNEBUG, causing assertions > >> (via assert(3)) to be included in the code. The regular *nix build > >> defines NDEBUG, so that assertions are not included in the regular, > >> "production" build. > >> > >> Now, I can understand why assert() and NDEBUG work the way they do. > >> Particularly on the small PDP-11s on which C and Unix were developed, > >> it made sense to have a way to remove assertions from code that would > >> be installed for all users. > >> > >> However, I'm starting to wonder. Are my habits from yesteryear (defining > >> NDEBUG by default) getting in the way of my being able (or users being > >> able) to find bugs and report them? Should I remove the defining of > >> NDEBUG from the default build? In particular, given the many orders of > >> magnitude increase in CPU and memory of modern systems, is it likely > >> that assertions won't really affect performance all that much? > >> > >> I'm starting to think that the answer is yes, it's time to remove > >> NDEBUG. But I'm curious what the experienced developers here > >> might think. > >> > >> Much thanks, > >> > >> Arnold > >> > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat Oct 18 00:24:25 2025 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Fri, 17 Oct 2025 10:24:25 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: <20251017140115.GN20133@mcvoy.com> References: <20251017140115.GN20133@mcvoy.com> Message-ID: In OpenSSL we did something very much like the Sun ASSERT/VERIFY mechanisms. In non-debug VERIFY returned an error; in debug VERIFY was like ASSERT. From tuhs at tuhs.org Sat Oct 18 00:46:02 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Fri, 17 Oct 2025 07:46:02 -0700 Subject: [TUHS] ETXTBSY Message-ID: This came up in the context of 9P, in a discussion with a friend, and I got wondering when it came into UNIX. From tuhs at tuhs.org Sat Oct 18 01:28:19 2025 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 17 Oct 2025 11:28:19 -0400 Subject: [TUHS] ETXTBSY In-Reply-To: References: Message-ID: On Fri, Oct 17, 2025 at 10:55 AM ron minnich via TUHS wrote: > This came up in the context of 9P, in a discussion with a friend, and I got > wondering when it came into UNIX. It was in V4 in `exec`, so very early on. 5th Edition grew checking in `access` with a possible `ETXTBSY` return. - Dan C. From tuhs at tuhs.org Sat Oct 18 05:13:29 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Sat, 18 Oct 2025 06:13:29 +1100 (EST) Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025, Aharon Robbins via TUHS wrote: [...] > However, I'm starting to wonder. Are my habits from yesteryear > (defining NDEBUG by default) getting in the way of my being able (or > users being able) to find bugs and report them? Should I remove the > defining of NDEBUG from the default build? In particular, given the > many orders of magnitude increase in CPU and memory of modern systems, > is it likely that assertions won't really affect performance all that > much? At the very least you should fix the defect that's causing the assertion to fail, no? They're there for a reason... -- Dave From tuhs at tuhs.org Sat Oct 18 11:44:02 2025 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sat, 18 Oct 2025 12:44:02 +1100 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: <08014FB9-483A-4ED7-BE5B-BC06D3EA24C6@canb.auug.org.au> This thread, responding to the original, moved to COFF, not about Early Unix. ============================================================ > On 17 Oct 2025, at 22:42, Aharon Robbins via TUHS wrote: > > Now, I can understand why assert() and NDEBUG work the way they do. > Particularly on the small PDP-11s on which C and Unix were developed, > it made sense to have a way to remove assertions from code that would > be installed for all users. How many computing workloads are now CPU limited, and can’t afford run-time Sanity Checking in Userland? For decades, people would try to ‘optimise’ performance by initially writing in assembler [ that myth dealt with by others ]. That appears to have flipped to using huge, slow Frameworks, such as Javascript / ECMA script for ‘Applications’. I’m not advocating “CPU is free, we can afford to forget about optimisation”. That’s OK with prototypes and ‘run once or twice’, human time matters more, but not in high-volume production workloads. The deliberate creation of bloat & wasting resources (== energy & dollars) for production work isn’t Professional behaviour IMHO. 10-15 years ago I saw something about Google’s web server CPU utilisation, being 60%-70%, from memory. It struck me that “% CPU" wasn’t a good metric for throughput anymore, and ’system performance’ was a complex, multi-factored problem, that had to be tuned per workload and target metric for ‘performance’. Low-Latency is only achieved at the cost of throughput. Google may have deliberately opted for lower %CPU to be responsive. Around the same time, there were articles about the throughput increase and latency improvement by some large site moving to SSD’s. IIRC, their CPU utilisation dropped markedly as well. Removing the burden of I/O waits causing deep scheduling queues somehow reduced total kernel overhead. Perhaps fewer VM page faults because of shorter process residency… I’ve no data on modern Supercomputers - I’d expect there to be huge effort in turning resources for individual applications & data sets. There’d be real incentive at the high-end to maximise ‘performance’, as well as at the other end: low-power & embedded systems. I’m more talking about Commercial Off the Shelf and small- to mid-size installations: - the things people run every day and suffer from slow response times. -- 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 Sat Oct 18 20:36:05 2025 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Sat, 18 Oct 2025 06:36:05 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: The answer on NDEBUG depends too much on how the debug machinery is implemented and how it works. If the debug machinery hangs out an unsecured port to which anyone might send commands and from which it might pull information, then you obviously do not want that in the production system. The old SLAMMER infestation relied on development and debugging artifacts included in the early-2000s MSDE system. Habitually production teams did not strip these away when deploying production code, since debugging. YMMV ===== mindthegapdialogs.com north-fork.info On Fri, Oct 17, 2025 at 7:50 AM Aharon Robbins via TUHS wrote: > Hello All. > > A bit off-topic, perhaps, but thoughts from this crowd would be welcome. > > I just finished tracking down a bug in gawk that was only noticed > because the Windows port is built without -DNEBUG, causing assertions > (via assert(3)) to be included in the code. The regular *nix build > defines NDEBUG, so that assertions are not included in the regular, > "production" build. > > Now, I can understand why assert() and NDEBUG work the way they do. > Particularly on the small PDP-11s on which C and Unix were developed, > it made sense to have a way to remove assertions from code that would > be installed for all users. > > However, I'm starting to wonder. Are my habits from yesteryear (defining > NDEBUG by default) getting in the way of my being able (or users being > able) to find bugs and report them? Should I remove the defining of > NDEBUG from the default build? In particular, given the many orders of > magnitude increase in CPU and memory of modern systems, is it likely > that assertions won't really affect performance all that much? > > I'm starting to think that the answer is yes, it's time to remove > NDEBUG. But I'm curious what the experienced developers here > might think. > > Much thanks, > > Arnold > From tuhs at tuhs.org Sun Oct 19 17:08:33 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 19 Oct 2025 01:08:33 -0600 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: <202510190708.59J78XME040719@freefriends.org> Thanks to everyone who responded to my thoughts on NDEBUG. > On Fri, 17 Oct 2025, Aharon Robbins via TUHS wrote: > > [...] > > > However, I'm starting to wonder. Are my habits from yesteryear > > (defining NDEBUG by default) getting in the way of my being able (or > > users being able) to find bugs and report them? Should I remove the > > defining of NDEBUG from the default build? In particular, given the > > many orders of magnitude increase in CPU and memory of modern systems, > > is it likely that assertions won't really affect performance all that > > much? Dave Horsfall via TUHS wrote: > At the very least you should fix the defect that's causing the assertion > to fail, no? They're there for a reason... > > -- Dave Fixing the defect goes without saying. That's been done. I've decided to enable assertions in the next release, although I do plan to review the code to see where I have them and to do a little performance testing. Thanks again, Arnold From tuhs at tuhs.org Sun Oct 19 17:12:33 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 19 Oct 2025 01:12:33 -0600 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: <202510190712.59J7CXqs041310@freefriends.org> Dan Cross wrote: > One must question whether `assert` is the right thing or not, though; > as an interface, it's pretty limited: a thing can either be true or > not, but any surrounding information is not preserved; for example, > one often wants to assert whether two things are equal, but if they > are not, it's often very useful to know what the actual values are: > `assert` doesn't give you that. It can be done, it's just not pretty: assert(answer == 42 ? true : fprintf(stderr, "answer = %d, expected 42\n", answer), fflush(stderr), false); Note the use of the comma operator. The joys of Obfuscated C. :-) (I do get your main point.) Arnold From tuhs at tuhs.org Sun Oct 19 22:22:09 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 19 Oct 2025 08:22:09 -0400 Subject: [TUHS] To NDEBUG or not to NDEBUG, that is the question In-Reply-To: <202510190712.59J7CXqs041310@freefriends.org> References: <202510190712.59J7CXqs041310@freefriends.org> Message-ID: Cool. One of the old ISVs we worked during my DEC days (I’ve forgotten which) had an ASSERT3 macro with the value you had, what was expected and an optional message. Then the fprintf then added __FILE__ and __LINE__ with the message if added. But it all comes back to accepting being washed overboard happens when you least expect it and as you point out, added with careful placing, the performance cost should be negligible. Sent from a handheld expect more typos than usual On Sun, Oct 19, 2025 at 3:12 AM Arnold Robbins via TUHS wrote: > Dan Cross wrote: > > > One must question whether `assert` is the right thing or not, though; > > as an interface, it's pretty limited: a thing can either be true or > > not, but any surrounding information is not preserved; for example, > > one often wants to assert whether two things are equal, but if they > > are not, it's often very useful to know what the actual values are: > > `assert` doesn't give you that. > > It can be done, it's just not pretty: > > assert(answer == 42 ? true : > fprintf(stderr, "answer = %d, expected 42\n", answer), > fflush(stderr), false); > > Note the use of the comma operator. The joys of Obfuscated C. :-) > > (I do get your main point.) > > Arnold > From tuhs at tuhs.org Fri Oct 24 14:23:32 2025 From: tuhs at tuhs.org (David Anderson via TUHS) Date: Thu, 23 Oct 2025 21:23:32 -0700 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? Message-ID: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> A friend is digging into the history of the tar format and its variations. The GNU tar format originates from a non-compliant variation of POSIX ustar, which appears to have been inherited from John Gilmore's pdtar. And according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference used to implement ustar. Thus, it would be interesting to peruse draft 6, and see if the variations stem from later changes to ustar, or ambiguities in the draft's wording, or what. Anyone happen to have an old printout or digital copy of that draft lying around? Allegedly the draft would have been in circulation circa 1985-1986. Cheers, - Dave From tuhs at tuhs.org Sat Oct 25 03:29:49 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 24 Oct 2025 17:29:49 +0000 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? In-Reply-To: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> References: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> Message-ID: On Thursday, October 23rd, 2025 at 21:24, David Anderson via TUHS wrote: > A friend is digging into the history of the tar format and its variations. The GNU tar format originates from a non-compliant variation of POSIX ustar, which appears to have been inherited from John Gilmore's pdtar. And according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference used to implement ustar. Thus, it would be interesting to peruse draft 6, and see if the variations stem from later changes to ustar, or ambiguities in the draft's wording, or what. > > Anyone happen to have an old printout or digital copy of that draft lying around? Allegedly the draft would have been in circulation circa 1985-1986. > > Cheers, > - Dave I do have a draft copy standard of 1003.1 Issued April 1986. I can't find where there might be an indication of which draft it is, but it is a published copy with a nice dust jacket (pictured here : https://wiki.tuhs.org/lib/exe/fetch.php?w=200&tok=e9832c&media=publications:1986_posix_draft.jpg), much nicer IMO than the final perfect bound copies that came out. Section 10 concerns the "Archive/Interchange File Format (TAR Format)". If this is the specific draft you are referring to, I'll gladly give this section an expedient scan. - Matt G. From tuhs at tuhs.org Sat Oct 25 03:57:39 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 24 Oct 2025 17:57:39 +0000 Subject: [TUHS] XPG4, X/OPEN Curses, and SVID Issue 4 Physical Publication? Message-ID: Good day everyone, I've recently added an X/OPEN Portability Guide section and a photo of the first SVID issue to the standards section of the wiki: https://wiki.tuhs.org/doku.php?id=publications:standards I was wondering, does anyone here know if there were physically published versions of XPG4, any X/OPEN Curses physical literature, and/or published SVID Issue 4 copies? The latter I suspect is not very likely as SVID Issue 4 concerns spun-off-USL SVR 4.2 I believe, which didn't make the same splash earlier SVIDs did. I've only seen PDFs of this Issue 4. Anywho, I need to snap a shot of the second issue of Go Solo as well, and aside from these mentioned, I think the page should adequately demonstrate the appearance and basic utility of each of the standards observed. Thank you! - Matt G. From tuhs at tuhs.org Sat Oct 25 04:58:26 2025 From: tuhs at tuhs.org (Skip Tavakkolian via TUHS) Date: Fri, 24 Oct 2025 11:58:26 -0700 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? In-Reply-To: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> References: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> Message-ID: I've put photos of Section 10 here: https://photos.app.goo.gl/jU4Ug1i4eMaEwQuz6 On Thu, Oct 23, 2025 at 9:24 PM David Anderson via TUHS wrote: > > A friend is digging into the history of the tar format and its variations. The GNU tar format originates from a non-compliant variation of POSIX ustar, which appears to have been inherited from John Gilmore's pdtar. And according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference used to implement ustar. Thus, it would be interesting to peruse draft 6, and see if the variations stem from later changes to ustar, or ambiguities in the draft's wording, or what. > > Anyone happen to have an old printout or digital copy of that draft lying around? Allegedly the draft would have been in circulation circa 1985-1986. > > Cheers, > - Dave From tuhs at tuhs.org Sat Oct 25 06:53:32 2025 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 24 Oct 2025 16:53:32 -0400 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? In-Reply-To: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> References: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> Message-ID: Jim McGinnis and I wrote that chapter originally. I may have a copy in old masscomp files. I can send you a scan of the actual approved standard. I don’t remember any changes wrt the format itself, only the English text. Sent from a handheld expect more typos than usual On Fri, Oct 24, 2025 at 12:24 AM David Anderson via TUHS wrote: > A friend is digging into the history of the tar format and its variations. > The GNU tar format originates from a non-compliant variation of POSIX > ustar, which appears to have been inherited from John Gilmore's pdtar. And > according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference > used to implement ustar. Thus, it would be interesting to peruse draft 6, > and see if the variations stem from later changes to ustar, or ambiguities > in the draft's wording, or what. > > Anyone happen to have an old printout or digital copy of that draft lying > around? Allegedly the draft would have been in circulation circa 1985-1986. > > Cheers, > - Dave > From tuhs at tuhs.org Sat Oct 25 07:01:54 2025 From: tuhs at tuhs.org (David Anderson via TUHS) Date: Fri, 24 Oct 2025 14:01:54 -0700 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? In-Reply-To: References: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> Message-ID: <6de0f6b5-642c-4b46-a627-364dcd7dee95@app.fastmail.com> Thank you! This is useful as a reference, but it looks like it's N+1 from the version we're after. At least according to https://mirrors.nycbug.org/pub/The_Unix_Archive/Unix_Usenet/mod.std.unix/1986-September/000097.html, "Draft 6" was only circulated electronically, and what would have been "draft 7" became the printed trial use standard. That also aligns with the datestamp on your print being 1986, whereas draft 6 appears to have been circulating in late 1985. It does still provide a useful datapoint, which is that by "draft 7" the spec format was already different to what 1985 pdtar implemented. That further narrows down the window for when changes may have occurred. On Fri, Oct 24, 2025, at 11:58, Skip Tavakkolian via TUHS wrote: > I've put photos of Section 10 here: > > https://photos.app.goo.gl/jU4Ug1i4eMaEwQuz6 > > On Thu, Oct 23, 2025 at 9:24 PM David Anderson via TUHS wrote: > > > > A friend is digging into the history of the tar format and its variations. The GNU tar format originates from a non-compliant variation of POSIX ustar, which appears to have been inherited from John Gilmore's pdtar. And according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference used to implement ustar. Thus, it would be interesting to peruse draft 6, and see if the variations stem from later changes to ustar, or ambiguities in the draft's wording, or what. > > > > Anyone happen to have an old printout or digital copy of that draft lying around? Allegedly the draft would have been in circulation circa 1985-1986. > > > > Cheers, > > - Dave > From tuhs at tuhs.org Sat Oct 25 07:18:24 2025 From: tuhs at tuhs.org (David Anderson via TUHS) Date: Fri, 24 Oct 2025 14:18:24 -0700 Subject: [TUHS] Anyone have a copy of POSIX.1 (IEEE 1003.1-1988) draft 6? In-Reply-To: References: <0c490345-59ed-4893-8d02-edd427bf519b@app.fastmail.com> Message-ID: Thank you! We already have the final standard (thanks FIPS 151-1) and, thanks to this list, the 1986 trial use draft. If you have earlier copies of either drafts (e.g. draft 6 as was apparently published on FTP, per https://mirrors.nycbug.org/pub/The_Unix_Archive/Unix_Usenet/mod.std.unix/1986-January/000036.html), or earlier drafts of the chapter, those would be very interesting in order to see how the text changed, and how it might line up with implementations of the time. In particular, do you have any memory or surviving documents in which the format used the magic string "ustar" and lacked a version field? That's the ustar deviation called "old GNU" in today's source code, but appears to be inherited from 1985 pdtar, and that pdtar source points to draft 6 as the reference for the format being implemented. On Fri, Oct 24, 2025, at 13:53, Clem Cole wrote: > Jim McGinnis and I wrote that chapter originally. I may have a copy in old masscomp files. I can send you a scan of the actual approved standard. I don’t remember any changes wrt the format itself, only the English text. > > Sent from a handheld expect more typos than usual > > > On Fri, Oct 24, 2025 at 12:24 AM David Anderson via TUHS wrote: >> A friend is digging into the history of the tar format and its variations. The GNU tar format originates from a non-compliant variation of POSIX ustar, which appears to have been inherited from John Gilmore's pdtar. And according to pdtar's source code, draft 6 of POSIX.1-1988 was the reference used to implement ustar. Thus, it would be interesting to peruse draft 6, and see if the variations stem from later changes to ustar, or ambiguities in the draft's wording, or what. >> >> Anyone happen to have an old printout or digital copy of that draft lying around? Allegedly the draft would have been in circulation circa 1985-1986. >> >> Cheers, >> - Dave From tuhs at tuhs.org Mon Oct 27 01:43:40 2025 From: tuhs at tuhs.org (James Frew via TUHS) Date: Sun, 26 Oct 2025 08:43:40 -0700 Subject: [TUHS] free PowerBook G4 Message-ID: <29c0b147-ed69-41b7-bd4b-ac9b350e48d4@ucsb.edu> Clearing out my garage I came across a Mac PowerBook G4 15" that I bought new in 2005 (!). It's been sitting in my garage (boxed) for at least a decade. Physically, it's in really good shape, no dings, no screen rot. I powered it up, did a clean install of OS X 10.5 (Leopard), and it seems to work just fine. (It also booted and ran a Ubuntu 12.04 (!) Desktop live disc.) If you'd like your very own twenty-year-old UNIXoid system, lemme know. I'm happy to give it away as long as you either come fetch it in Santa Barbara, or prepay the shipping (~10 lbs) to somewhere in the US. Includes 2 power bricks, DVDs for OS X and Ubuntu, and a couple of CardBus (remember those?) adapters (SD card and extra USB ports). Full specs (System Profile output) on request. Cheers, /Frew From tuhs at tuhs.org Mon Oct 27 04:32:56 2025 From: tuhs at tuhs.org (Kenneth Goodwin via TUHS) Date: Sun, 26 Oct 2025 14:32:56 -0400 Subject: [TUHS] free PowerBook G4 In-Reply-To: <29c0b147-ed69-41b7-bd4b-ac9b350e48d4@ucsb.edu> References: <29c0b147-ed69-41b7-bd4b-ac9b350e48d4@ucsb.edu> Message-ID: I remember cardbus. I have two brand new cardbus network modules sitting on the shelf. It lived about a year or so as i recall On Sun, Oct 26, 2025, 11:44 AM James Frew via TUHS wrote: > Clearing out my garage I came across a Mac PowerBook G4 15" > < > https://everymac.com/systems/apple/powerbook_g4/specs/powerbook_g4_1.67_15.html> > > that I bought new in 2005 (!). It's been sitting in my garage (boxed) > for at least a decade. Physically, it's in really good shape, no dings, > no screen rot. I powered it up, did a clean install of OS X 10.5 > (Leopard), and it seems to work just fine. (It also booted and ran a > Ubuntu 12.04 (!) Desktop live disc.) > > If you'd like your very own twenty-year-old UNIXoid system, lemme know. > I'm happy to give it away as long as you either come fetch it in Santa > Barbara, or prepay the shipping (~10 lbs) to somewhere in the US. > Includes 2 power bricks, DVDs for OS X and Ubuntu, and a couple of > CardBus (remember those?) adapters (SD card and extra USB ports). Full > specs (System Profile output) on request. > > Cheers, > /Frew > From tuhs at tuhs.org Mon Oct 27 04:47:48 2025 From: tuhs at tuhs.org (William H. Mitchell via TUHS) Date: Sun, 26 Oct 2025 11:47:48 -0700 Subject: [TUHS] Free to good home: PDP 11TO3 Message-ID: James’ note about the G4 reminds me that somebody on this list might be interested in a PDP 11TO3 that’s sitting in my garage. It’s in a 50" rack with one RK05J. I’ve got a second RK05J that’s in pieces. I’ve got various uninventoried circuit boards that came with the 11, too. I’ll help you load it into your truck at my house in Tucson, AZ. Free lunch, dinner and overnight stay included, too! William Mitchell Mitchell Software Engineering Occasional Adjunct Instructor at U of AZ CS 520-870-6488 (m) Discord: x77686d, Twitter: @x77686d linkedin.com/in/x77686d From tuhs at tuhs.org Mon Oct 27 06:28:29 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Mon, 27 Oct 2025 07:28:29 +1100 (EST) Subject: [TUHS] Free to good home: PDP 11TO3 In-Reply-To: References: Message-ID: On Sun, 26 Oct 2025, William H. Mitchell via TUHS wrote: > James’ note about the G4 reminds me that somebody on this list might be > interested in a PDP 11TO3 that’s sitting in my garage. It’s in a 50" > rack with one RK05J. I’ve got a second RK05J that’s in pieces. I’ve got > various uninventoried circuit boards that came with the 11, too. [...] What's the 11TO3? Of is that the LSI-11/23? -- Dave From tuhs at tuhs.org Mon Oct 27 06:43:41 2025 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Sun, 26 Oct 2025 20:43:41 +0000 Subject: [TUHS] Free to good home: PDP 11TO3 In-Reply-To: References: Message-ID: No, 11/03 bundled with a RL01 hard disk (5.2MB). ------ Original Message ------ >From "Dave Horsfall via TUHS" To "The Eunuchs Hysterical Society" Date 10/26/2025 4:28:29 PM Subject [TUHS] Re: Free to good home: PDP 11TO3 >On Sun, 26 Oct 2025, William H. Mitchell via TUHS wrote: > >> James’ note about the G4 reminds me that somebody on this list might be >> interested in a PDP 11TO3 that’s sitting in my garage. It’s in a 50" >> rack with one RK05J. I’ve got a second RK05J that’s in pieces. I’ve got >> various uninventoried circuit boards that came with the 11, too. > >[...] > >What's the 11TO3? Of is that the LSI-11/23? > >-- Dave From tuhs at tuhs.org Mon Oct 27 07:28:16 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 26 Oct 2025 15:28:16 -0600 Subject: [TUHS] Is Doug Gwyn around anywhere? Message-ID: <202510262128.59QLSGnU050183@freefriends.org> Does anyone have an email for Doug Gwyn? I found something he did circa 1985, I thought he might get a kick out of seeing it. Thanks, Arnold From tuhs at tuhs.org Mon Oct 27 13:06:06 2025 From: tuhs at tuhs.org (Matt Day via TUHS) Date: Sun, 26 Oct 2025 21:06:06 -0600 Subject: [TUHS] Is Doug Gwyn around anywhere? In-Reply-To: <202510262128.59QLSGnU050183@freefriends.org> References: <202510262128.59QLSGnU050183@freefriends.org> Message-ID: Doug Gwyn is gwyn at arl.mil according to https://leakyabstractions.com/quotes/the-design-of-unix.html That web page says Gwyn is "Currently Emeritus at US Army Research Laboratory" which agrees with the C Experts Panel discussion he participated in back in 2020: https://news.ycombinator.com/item?id=22865357 On Sun, Oct 26, 2025 at 3:35 PM Arnold Robbins via TUHS wrote: > Does anyone have an email for Doug Gwyn? I found something he did > circa 1985, I thought he might get a kick out of seeing it. > > Thanks, > > Arnold > From tuhs at tuhs.org Mon Oct 27 13:16:05 2025 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Mon, 27 Oct 2025 13:16:05 +1000 Subject: [TUHS] Is Doug Gwyn around anywhere? In-Reply-To: References: <202510262128.59QLSGnU050183@freefriends.org> Message-ID: was he BRL? I have memories of this, in the "MH needs more work" days post-Rand. I believe it's also called "Aberdeen" -Maryland. (could be mixing up two Dougs possibly) From tuhs at tuhs.org Mon Oct 27 16:44:41 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 27 Oct 2025 00:44:41 -0600 Subject: [TUHS] Is Doug Gwyn around anywhere? In-Reply-To: <202510262128.59QLSGnU050183@freefriends.org> References: <202510262128.59QLSGnU050183@freefriends.org> Message-ID: <202510270644.59R6if5V085275@freefriends.org> Arnold Robbins via TUHS wrote: > Does anyone have an email for Doug Gwyn? I found something he did > circa 1985, I thought he might get a kick out of seeing it. > > Thanks, > > Arnold Thanks to everyone who responded. I sent an email to the arl.mil address. He was indeed at BRL. I think at some point it got renamed to ARL. (Army Research Lab?) Best wishes, Arnold From tuhs at tuhs.org Mon Oct 27 21:51:11 2025 From: tuhs at tuhs.org (Mike Markowski via TUHS) Date: Mon, 27 Oct 2025 07:51:11 -0400 Subject: [TUHS] Is Doug Gwyn around anywhere? In-Reply-To: References: <202510262128.59QLSGnU050183@freefriends.org> Message-ID: On Mon, Oct 27, 2025 at 1:45 AM George Michaelson via TUHS wrote: > was he BRL? I have memories of this, in the "MH needs more work" days > post-Rand. > > I believe it's also called "Aberdeen" -Maryland. > > (could be mixing up two Dougs possibly) > You're right. Doug and I were in offices either adjacent or 2 apart at Aberdeen Proving Ground, MD - it's been awhile! BRL (Ballistic Research Lab) was one of I think 7 labs combined to create Army Research Lab (ARL). I just checked and Doug is no longer in the email directory, so must be enjoying retirement. -Mike Markowski From tuhs at tuhs.org Fri Oct 31 11:22:36 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 31 Oct 2025 01:22:36 +0000 Subject: [TUHS] On Graduation from (VI) to (I) Message-ID: Present from the beginning, Section VI of the UNIX Programmer's Manual was the gathering place for all those little programs folks involved in the system had authored for fun and frolic rather than work and business, mostly. In-progress works and experimental features also often found themselves relegated to this section. If a feature was lucky (and not too "fun"), it earned the distinction of graduating then to the big leagues in Section I. Something I'm curious about is what sorts of decisions were involved in what section between the two to slot any given program at any given time. Of course the arbiters of the original manuals would've been folks at Bell/AT&T, but we also see this convention retained in other vendor's offerings, with them also relegating certain additions and components to this oft overlooked section. For me I'm also curious if there was a sense of pride, or on the flip side, a sense of selling out when/if one's program ascended the marble steps from section VI to section I. On one hand, I would feel proud that my work was appreciated enough to make it. On the other hand, I am a very diy person and would feel similarly proud of how much volume I could shove into section VI without concerning myself with the haughty expectations of those snooty section I programs. Anyone have any fun stories related to this dichotomy in the manual? Have your feelings ever been hurt because what you thought was section I work was banished to section VI? Was it less of a big deal than my dramatic delivery would suggest? - Matt G. From tuhs at tuhs.org Fri Oct 31 18:33:12 2025 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 31 Oct 2025 02:33:12 -0600 Subject: [TUHS] On Graduation from (VI) to (I) In-Reply-To: References: Message-ID: <202510310833.59V8XCal099338@freefriends.org> segaloco via TUHS wrote: > Was it less of a big deal than my dramatic delivery would suggest? Probably. But I wasn't there. Doug is probably the best person to answer. Arnold