From jnc at mercury.lcs.mit.edu Thu May 1 00:06:37 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Apr 2025 10:06:37 -0400 (EDT) Subject: [TUHS] Any Interdata war stories? Message-ID: <20250430140637.C00DA18C074@mercury.lcs.mit.edu> > From: Arnold Robbins > CCI made the Tahoe that 4.4 ran on, but I'm guessing it's a different > architecture than the Interdata? I think so. Almost all documentation on the Tahoe has been lost in the mists of time (if ANYONE retains ANY hardcopies of ANY hardware documentation for the Tahoe, PLEASE let me know), but I recently managed to work out a bit about it from the instruction decoding/printing routines in the debuggers from 4.3 BSD Tahoe: https://gunkies.org/wiki/Power_6/32 and it seems to be fairly different from the Interdata: http://bitsavers.org/pdf/interdata/32bit/29-365R01_32BitRefMan_Jun74.pdf Also, 'CCI' is 'Computer Consoles Incorporated', not "Concurrent Computer Corp". Noel From jsg at jsg.id.au Thu May 1 00:07:41 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 1 May 2025 00:07:41 +1000 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > From: Clem Cole > > > Yes, that was one of the RTS compilers for the NU machine. John Romkey > > may have done it, as he was the primary person behind PCIP > > I decided to poke around in the 'MIT-CSR' dump, since that was the machine > the PC/IP project started on, to see what I could find. Hoo boy! What an > adventure! > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. It > did have a shell file, 'grab', which contained: > > tftp -g $1 xx "PS:$1" > > and a 'graball' file which called 'grab' for the list of compiler source > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > So I did a Web search for Wayne Gramlich (with whom I hadn't communicated in > many decades), and he popped right up. (Amazing thing, this Internet thingy. > Who'd have ever thought, back in the day, that it would turn into what it > did? Well, probably John Brunner, whom I (sadly) never met, who was there > before any of us.) > > I took a chance, and called his number, and he was there, and we had a long > chat. He absolutely didn't do it, although he wrote the loader the project > used ('l68', the source for which I did find.) He's virtually certain Romkey > didn't (which would have been my guess too; Romkey was like a sophmore when > the project started). His best (_very_ faded) memory was that they started off > with a commercial compiler. (But see below.) > > That leaves several mysteries. 1) Why would a commercial compiler not come > with a linker? 2) Why did people who wanted to work with the PC/IP source > need a Bell license? > > > I did some more poking, and the list of files for the 86 compiler, from > 'graball': > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > table.c reader.c local2.c order.c match.c allo.c comm1.c > manifest mfile1 common macdefs mfile2 mac2defs > > matched the file names from 'pcc', as given in "A Tour Through the Portable C > Compiler": > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > (in section "The Source Files"). So whether the 86 compiler was done at MIT > (by someone in RTS), or at a company, it was definitely a 'pcc' descendant. > > (Possibly adding to the confusion, we had some other C compilers for various > ISA's in that project [building networking software for various > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, which I > have also found. It's possible that Wayne's vague memory of a commercial > compiler is of that one?) > > I really should reach out to Romkey and Bridgham, to see what they remember. > Later today. > > Whether the main motivation for keeping the compiler source on XX was i) > because disk space was short on CSR (we had only a hand-me-down pair of > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > version skew; or iii) because it was a commercial compiler, and we had to > protect the source (e.g. we didn't have the source to the 8080 compiler, only > the object modules), I have no idea. > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the 68K, > > Z8000 and 8086. I believe that each had separate assemblers, tjt who > > sometimes reads this list might know more, as he wrote the 68K assembler. > > There is an 'a86' directory on CSR, but it too is empty, except for a 'grab' > command file. That contains only: > > tftp -g $1 xx "PS:$1" > > I have no memory of who 'novick' might have been. A Web search for 'novick > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > Novitsky; she was in our group at LCS, and I have a vague memory of her being > associated with the networking software for micro-computers project.) > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, but he > didn't write c86; 'novick' might not have written a86. > > Something else to ask Romkey and Bridgham about. > > Noel "a version of the portable C Compiler that was modified by Chris Terman to produce code for an 8086 microprocessor was ported from the RTS VAX/780 to the CSR PDP-11/45." https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf "If you think that you need the source code, you should realize that a prerequisite to compiling the PC/IP programs is that you must have imported Chris Terman's 8086 version of the UNIX Portable C compiler and associated loader and assember systems. That importation in turn requires a UNIX system, a current UNIX license, and negotiation with Chris Terman." https://web.mit.edu/saltzer/www/publications/pcmemo.pdf From woods at robohack.ca Thu May 1 07:17:46 2025 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 30 Apr 2025 14:17:46 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: At Tue, 29 Apr 2025 00:55:05 -0600, arnold at skeeve.com wrote: Subject: [TUHS] Any Interdata war stories? > > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; In about 1981 or 1982 the chemistry (IIRC) department at University of Calgary had an Interdata 8/32 that was, at least for some time around then, running Unix. I remember poking around on it briefly, but I don't remember much more than that about it. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms From clemc at ccc.com Thu May 1 12:36:01 2025 From: clemc at ccc.com (Clem Cole) Date: Wed, 30 Apr 2025 22:36:01 -0400 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: So did Chris compiler go back to the Nu project? And thank you to Al for the Trix sources. As I said. It was national 16032 not z8000. FYI I had the whitesmith compiler at one point also. It generated code for a funky assembler called “anat” for “a natural assembler” which PJ conjured up for writing the compiler. It was was sort of a mix between an IL and 8080 assembler if my memory is correct. I’d love to see that distribution both the doc and the compiler again to May with on SIMH. I suspect I might appreciate it more than I did in those days. I hated it then but as I learned more about compilers and architectures PJ might have been on to something. Sent from a handheld expect more typos than usual On Wed, Apr 30, 2025 at 10:07 AM Jonathan Gray wrote: > On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > > From: Clem Cole > > > > > Yes, that was one of the RTS compilers for the NU machine. John > Romkey > > > may have done it, as he was the primary person behind PCIP > > > > I decided to poke around in the 'MIT-CSR' dump, since that was the > machine > > the PC/IP project started on, to see what I could find. Hoo boy! What an > > adventure! > > > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. > It > > did have a shell file, 'grab', which contained: > > > > tftp -g $1 xx "PS:$1" > > > > and a 'graball' file which called 'grab' for the list of compiler source > > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > > > So I did a Web search for Wayne Gramlich (with whom I hadn't > communicated in > > many decades), and he popped right up. (Amazing thing, this Internet > thingy. > > Who'd have ever thought, back in the day, that it would turn into what it > > did? Well, probably John Brunner, whom I (sadly) never met, who was there > > before any of us.) > > > > I took a chance, and called his number, and he was there, and we had a > long > > chat. He absolutely didn't do it, although he wrote the loader the > project > > used ('l68', the source for which I did find.) He's virtually certain > Romkey > > didn't (which would have been my guess too; Romkey was like a sophmore > when > > the project started). His best (_very_ faded) memory was that they > started off > > with a commercial compiler. (But see below.) > > > > That leaves several mysteries. 1) Why would a commercial compiler not > come > > with a linker? 2) Why did people who wanted to work with the PC/IP source > > need a Bell license? > > > > > > I did some more poking, and the list of files for the 86 compiler, from > > 'graball': > > > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > > table.c reader.c local2.c order.c match.c allo.c comm1.c > > manifest mfile1 common macdefs mfile2 mac2defs > > > > matched the file names from 'pcc', as given in "A Tour Through the > Portable C > > Compiler": > > > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > > > (in section "The Source Files"). So whether the 86 compiler was done at > MIT > > (by someone in RTS), or at a company, it was definitely a 'pcc' > descendant. > > > > (Possibly adding to the confusion, we had some other C compilers for > various > > ISA's in that project [building networking software for various > > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, > which I > > have also found. It's possible that Wayne's vague memory of a commercial > > compiler is of that one?) > > > > I really should reach out to Romkey and Bridgham, to see what they > remember. > > Later today. > > > > Whether the main motivation for keeping the compiler source on XX was i) > > because disk space was short on CSR (we had only a hand-me-down pair of > > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > > version skew; or iii) because it was a commercial compiler, and we had to > > protect the source (e.g. we didn't have the source to the 8080 compiler, > only > > the object modules), I have no idea. > > > > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the > 68K, > > > Z8000 and 8086. I believe that each had separate assemblers, tjt > who > > > sometimes reads this list might know more, as he wrote the 68K > assembler. > > > > There is an 'a86' directory on CSR, but it too is empty, except for a > 'grab' > > command file. That contains only: > > > > tftp -g $1 xx "PS:$1" > > > > I have no memory of who 'novick' might have been. A Web search for > 'novick > > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > > Novitsky; she was in our group at LCS, and I have a vague memory of her > being > > associated with the networking software for micro-computers project.) > > > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, > but he > > didn't write c86; 'novick' might not have written a86. > > > > Something else to ask Romkey and Bridgham about. > > > > Noel > > "a version of the portable C Compiler that was modified by Chris Terman > to produce code for an 8086 microprocessor was ported from the RTS VAX/780 > to the CSR PDP-11/45." > > https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf > > "If you think that you need the source code, you should realize that a > prerequisite to compiling the PC/IP programs is that you must have > imported Chris Terman's 8086 version of the UNIX Portable C compiler and > associated loader and assember systems. That importation in turn requires > a UNIX system, a current UNIX license, and negotiation with Chris Terman." > https://web.mit.edu/saltzer/www/publications/pcmemo.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu May 1 13:38:10 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 1 May 2025 13:38:10 +1000 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: Chris was part of the Nu project. "Was a principal developer of the NuMachine" "developed a family of portable C compilers for the (then) newly available microprocessors. These compilers were widely distributed as the first C implementations for the x86 and 68K processors." https://people.csail.mit.edu/cjt/resume.html On Wed, Apr 30, 2025 at 10:36:01PM -0400, Clem Cole wrote: > So did Chris compiler go back to the Nu project? And thank you to Al for > the Trix sources. As I said. It was national 16032 not z8000. > > > FYI I had the whitesmith compiler at one point also. It generated code for > a funky assembler called “anat” for “a natural assembler” which PJ conjured > up for writing the compiler. It was was sort of a mix between an IL and > 8080 assembler if my memory is correct. I’d love to see that > distribution both the doc and the compiler again to May with on SIMH. I > suspect I might appreciate it more than I did in those days. I hated it > then but as I learned more about compilers and architectures PJ might have > been on to something. > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 30, 2025 at 10:07 AM Jonathan Gray wrote: > > > On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > > > From: Clem Cole > > > > > > > Yes, that was one of the RTS compilers for the NU machine. John > > Romkey > > > > may have done it, as he was the primary person behind PCIP > > > > > > I decided to poke around in the 'MIT-CSR' dump, since that was the > > machine > > > the PC/IP project started on, to see what I could find. Hoo boy! What an > > > adventure! > > > > > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. > > It > > > did have a shell file, 'grab', which contained: > > > > > > tftp -g $1 xx "PS:$1" > > > > > > and a 'graball' file which called 'grab' for the list of compiler source > > > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > > > > > So I did a Web search for Wayne Gramlich (with whom I hadn't > > communicated in > > > many decades), and he popped right up. (Amazing thing, this Internet > > thingy. > > > Who'd have ever thought, back in the day, that it would turn into what it > > > did? Well, probably John Brunner, whom I (sadly) never met, who was there > > > before any of us.) > > > > > > I took a chance, and called his number, and he was there, and we had a > > long > > > chat. He absolutely didn't do it, although he wrote the loader the > > project > > > used ('l68', the source for which I did find.) He's virtually certain > > Romkey > > > didn't (which would have been my guess too; Romkey was like a sophmore > > when > > > the project started). His best (_very_ faded) memory was that they > > started off > > > with a commercial compiler. (But see below.) > > > > > > That leaves several mysteries. 1) Why would a commercial compiler not > > come > > > with a linker? 2) Why did people who wanted to work with the PC/IP source > > > need a Bell license? > > > > > > > > > I did some more poking, and the list of files for the 86 compiler, from > > > 'graball': > > > > > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > > > table.c reader.c local2.c order.c match.c allo.c comm1.c > > > manifest mfile1 common macdefs mfile2 mac2defs > > > > > > matched the file names from 'pcc', as given in "A Tour Through the > > Portable C > > > Compiler": > > > > > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > > > > > (in section "The Source Files"). So whether the 86 compiler was done at > > MIT > > > (by someone in RTS), or at a company, it was definitely a 'pcc' > > descendant. > > > > > > (Possibly adding to the confusion, we had some other C compilers for > > various > > > ISA's in that project [building networking software for various > > > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, > > which I > > > have also found. It's possible that Wayne's vague memory of a commercial > > > compiler is of that one?) > > > > > > I really should reach out to Romkey and Bridgham, to see what they > > remember. > > > Later today. > > > > > > Whether the main motivation for keeping the compiler source on XX was i) > > > because disk space was short on CSR (we had only a hand-me-down pair of > > > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > > > version skew; or iii) because it was a commercial compiler, and we had to > > > protect the source (e.g. we didn't have the source to the 8080 compiler, > > only > > > the object modules), I have no idea. > > > > > > > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the > > 68K, > > > > Z8000 and 8086. I believe that each had separate assemblers, tjt > > who > > > > sometimes reads this list might know more, as he wrote the 68K > > assembler. > > > > > > There is an 'a86' directory on CSR, but it too is empty, except for a > > 'grab' > > > command file. That contains only: > > > > > > tftp -g $1 xx "PS:$1" > > > > > > I have no memory of who 'novick' might have been. A Web search for > > 'novick > > > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > > > Novitsky; she was in our group at LCS, and I have a vague memory of her > > being > > > associated with the networking software for micro-computers project.) > > > > > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, > > but he > > > didn't write c86; 'novick' might not have written a86. > > > > > > Something else to ask Romkey and Bridgham about. > > > > > > Noel > > > > "a version of the portable C Compiler that was modified by Chris Terman > > to produce code for an 8086 microprocessor was ported from the RTS VAX/780 > > to the CSR PDP-11/45." > > > > https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf > > > > "If you think that you need the source code, you should realize that a > > prerequisite to compiling the PC/IP programs is that you must have > > imported Chris Terman's 8086 version of the UNIX Portable C compiler and > > associated loader and assember systems. That importation in turn requires > > a UNIX system, a current UNIX license, and negotiation with Chris Terman." > > https://web.mit.edu/saltzer/www/publications/pcmemo.pdf > > From aek at bitsavers.org Thu May 1 14:20:56 2025 From: aek at bitsavers.org (Al Kossow) Date: Wed, 30 Apr 2025 21:20:56 -0700 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: On 4/30/25 8:38 PM, Jonathan Gray wrote: > Chris was part of the Nu project. > > "Was a principal developer of the NuMachine" > > "developed a family of portable C compilers for the (then) newly > available microprocessors. These compilers were widely distributed as > the first C implementations for the x86 and 68K processors." > > https://people.csail.mit.edu/cjt/resume.html I found most of the yearly LCS reports have been digitized to DTIC which answered a bunch of my questions about who was doing what at that time I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports From pugs78 at gmail.com Thu May 1 14:44:50 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 30 Apr 2025 21:44:50 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: I found this USENIX paper from Steve Johnson that has a lot of detail about the Interdata port (postscript format): "C and the AT&T Unix Port--A Personal History" https://www.usenix.org/legacy/publications/library/proceedings/usenix98/invited_talks/johnson.ps On Mon, Apr 28, 2025 at 11:55 PM wrote: > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; I don't think the code for it is in the > TUHS archives. > > Was the Interdata system in use at Bell Labs for actual work once > the port was complete? > > ISTR there was a meeting with Interdata about changes in the architecture > that Bell Labs wanted, that Interdata didn't want to make. What > was the full story? > > Any other info would be welcome. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri May 2 07:01:27 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 May 2025 21:01:27 +0000 Subject: [TUHS] Surviving System V/VME Artifacts? Message-ID: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was the WE321SB VME-bus single-board computer. The official operating system for this was UNIX System V/VME. This version is referenced in several document catalogues and literature surrounding this VME module. I was curious if anyone on list happens to know of any surviving System V/VME artifacts floating around out there. All I've been able to find are references to the system in other WE32x00 and UNIX documentation. Thanks for any info! - Matt G. From kevin.bowling at kev009.com Fri May 2 07:07:46 2025 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 1 May 2025 14:07:46 -0700 Subject: [TUHS] Surviving System V/VME Artifacts? In-Reply-To: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> References: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> Message-ID: On Thu, May 1, 2025 at 2:01 PM segaloco via TUHS wrote: > > So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was > the WE321SB VME-bus single-board computer. The official operating system for > this was UNIX System V/VME. This version is referenced in several document > catalogues and literature surrounding this VME module. I was curious if anyone > on list happens to know of any surviving System V/VME artifacts floating around > out there. All I've been able to find are references to the system in other > WE32x00 and UNIX documentation. I would also be interested if anyone has ever seen that hardware. VME stuff tends to be durable because it is used in machinery with long lifetimes so it doesn't usually go the way of commercial computer disappearing. > Thanks for any info! > > - Matt G. From tuhs at tuhs.org Fri May 2 07:35:40 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 May 2025 21:35:40 +0000 Subject: [TUHS] Surviving System V/VME Artifacts? In-Reply-To: References: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> Message-ID: On Thursday, May 1st, 2025 at 2:08 PM, Kevin Bowling wrote: > On Thu, May 1, 2025 at 2:01 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was > > the WE321SB VME-bus single-board computer. The official operating system for > > this was UNIX System V/VME. This version is referenced in several document > > catalogues and literature surrounding this VME module. I was curious if anyone > > on list happens to know of any surviving System V/VME artifacts floating around > > out there. All I've been able to find are references to the system in other > > WE32x00 and UNIX documentation. > > > I would also be interested if anyone has ever seen that hardware. VME > stuff tends to be durable because it is used in machinery with long > lifetimes so it doesn't usually go the way of commercial computer > disappearing. > > > Thanks for any info! > > > > - Matt G. Details about the module can be found here: https://archive.org/details/bitsavers_westernEleocessorsandPeripheralsAug87_47936355/page/n467/mode/2up In addition other WECo/ATTIS publications from the mid 80s describe this and other bits like the WE321EB eval board and WE321AP analysis pod. - Matt G. From arnold at skeeve.com Fri May 2 22:21:09 2025 From: arnold at skeeve.com (Aharon Robbins) Date: Fri, 02 May 2025 15:21:09 +0300 Subject: [TUHS] Off topic: Books on Unix security? Message-ID: Hi All. In a book I'm updating, I have the following references for Unix security. 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. 2. Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. One of my reviewers asked if these weren't "dusty references". So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. Thanks, Arnold From tjteixeira at earthlink.net Sat May 3 00:56:58 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Fri, 2 May 2025 10:56:58 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> On 5/1/25 12:20 AM, Al Kossow wrote: > On 4/30/25 8:38 PM, Jonathan Gray wrote: >> Chris was part of the Nu project. >> >> "Was a principal developer of the NuMachine" >> >> "developed a family of portable C compilers for the (then) newly >> available microprocessors. These compilers were widely distributed as >> the first C implementations for the x86 and 68K processors." >> >> https://people.csail.mit.edu/cjt/resume.html > > I found most of the yearly LCS reports have been digitized to DTIC > which answered a bunch of my questions about who was doing what at > that time > > I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports > > > Some background, though the MIT LCS progress reports should cover much of this. I won't attempt to put any dates. Chris Terman was one of the graduate students in the RTS group. Since VT-52 terminals were relatively scarce, he designed and built his own with a larger screen - something like 40 lines by maybe 120 or 132 characters, called the "Termanal". I don't remember if it used an 8080 to handle the control sequences in the data stream or something else. He then got interested in designing a terminal that could display bit map graphics, to be comparable to the graphics used on the Lisp Machines just being built by the MIT-AI lab. I had stumbled across one of the LCS progress reports that credits Professor Steve Ward and one of the undergraduate staff, Rae McClellan in assisting the design of this bit graph which was named the "Nu Terminal" (I don't think it was the "Nu Termanal"). This used an 8086. A couple of these were built. One of the undergraduate students, Jon Sieber, had been a member of an Explorer Post in Murray Hill where Dennis Ritchie was the advisor. Jon would regularly bring UNIX tapes from the Research Lab and included things like early versions of the Portable C Compiler and the Circuit Design Aids. Chris used the Circuit Design Aids to design wire-wrap boards for the Nu Terminal and the RTS lab got a semi-automatic wire wrap machine. Some students and staff took turns doing the actual wire wrapping. My contribution was writing some simple software that simulated a paper tape reader for the wire wrap machine. An undergraduate student, Mike Patrick, did his bachelor's thesis writing a table driven assembler and constructed tables for the 8086 and I think an 8080. Later there were drivers for the Zylog Z8000, the National Semiconductor NS16000 and the Motorola 68000. I contributed a small bit of code for doing optimal choice of short vs long branches (to branch to an address more than +/- 127 bytes, you had to branch around a longer jump instruction). Chris Terman did the work of modifying the Portable C Compiler to generate code for the 8086, the Z8000, NS16000 and MC68000. I think we may have built one machine with the Z8000, but quickly settled on using the MC68000, primarily because of the 32-bit support (one progress report says that Zenith was supposed to build multiple Z8000 based machines, but I don't remember those. The NS16000 had better memory management, but I don't think we ever actually received any CPU chips. Anyway, these compilers were what was distributed, and the MC68000 compiler in particular was used by almost all the companies that came out the MC68000-based Unix machines. Apollo was a notable exception, but Apollo wrote their own operating system from scratch rather than Unix. Side note: Bill Poduska came to visit Steve Ward and before the visit Steve was all excited, but was disappointed that Bill was not going to use Unix. Before the RTS group used Unix, they had written a small timesharing system for the PDP-11/45 that was used in the 6.031 introductory computer science course taught by Mike Dertouzos. Chris was involved in maintaining that, though I think Steve Ward was probably the main implementor. Chris had also spent too many hours changing address jumpers on Unibus and other controllers as well as tweaking Unix mkconf files, and thought that while the 4BSD autoconfiguration was an improvement, there should be a better way. Chris and Steve designed the Nu bus, and the Nu Bus was used in the MC68000 boards. Eventually it was picked up by Apple. Chris was one of many students who took the Mead/Conway LSI design course and ended up abandoning his research on portable compilers in favor of simulating LSI designs. He was also a co-founder of Symbolics and designed the controller for their laser printer before returning to MIT as a Lecturer and sponsored research staff. There were also proposed follow-on software projects related to the Nu terminal. One was Trix. Steve Ward said he didn't know what an "ics" was, but Multics clearly had too many, and Unix had too few, hence Trix. Jack Test was hired to do a lot of the development. Wikipedia has a reasonable summary of Trix, as far as I remember, but I had left RTS to join Masscomp in late 1981/early 1982, and I know Jack Test was an early employee of Alliant Computer so he left Trix probably in 1982. From clemc at ccc.com Sat May 3 01:15:39 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 May 2025 11:15:39 -0400 Subject: [TUHS] PC/IP In-Reply-To: <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: Thank you, Tom, for the definitive answers to much of this. I remembered that the Z8000 was mixed up in that mess, but it was missing from Al's Trix tape. Do you know if a Z8000 back end or set of support tools was ever built, and if so, does anyone know if they survived? It does look like Al has 8086 [Terman compiler]. 68K (of a few flavors) and an NS16032 (author's unknown). One of the tools you mentioned from MIT seems to have survived, although Dennis and I saved the official UNIX Circuit Design System release in the mid-1990s. Warren has had that TUHS archives ever since, but I'm not I ever saw you tools other than things like you 68K assembler, and I guess is was our fiiend Wayne that wrote the linker (which until this thread I did not now). BTW: Again, it proves how interwoven the people and tech (i.e., open source culture) were in the 1970s; i.e., it's not a new thing. The PDPs were running the Stanford Circuit Design System (SUDS) and the 11's often at USCD. The people came and went. For instance,the former Wayne was a year ahead of me at CMU before he headed to MIT for a Master's and PhD, ᐧ On Fri, May 2, 2025 at 10:57 AM Tom Teixeira wrote: > On 5/1/25 12:20 AM, Al Kossow wrote: > > On 4/30/25 8:38 PM, Jonathan Gray wrote: > >> Chris was part of the Nu project. > >> > >> "Was a principal developer of the NuMachine" > >> > >> "developed a family of portable C compilers for the (then) newly > >> available microprocessors. These compilers were widely distributed as > >> the first C implementations for the x86 and 68K processors." > >> > >> https://people.csail.mit.edu/cjt/resume.html > > > > I found most of the yearly LCS reports have been digitized to DTIC > > which answered a bunch of my questions about who was doing what at > > that time > > > > I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports > > > > > > > Some background, though the MIT LCS progress reports should cover much > of this. I won't attempt to put any dates. > > Chris Terman was one of the graduate students in the RTS group. Since > VT-52 terminals were relatively scarce, he designed and built his own > with a larger screen - something like 40 lines by maybe 120 or 132 > characters, called the "Termanal". I don't remember if it used an 8080 > to handle the control sequences in the data stream or something else. > > He then got interested in designing a terminal that could display bit > map graphics, to be comparable to the graphics used on the Lisp Machines > just being built by the MIT-AI lab. I had stumbled across one of the LCS > progress reports that credits Professor Steve Ward and one of the > undergraduate staff, Rae McClellan in assisting the design of this bit > graph which was named the "Nu Terminal" (I don't think it was the "Nu > Termanal"). This used an 8086. A couple of these were built. One of the > undergraduate students, Jon Sieber, had been a member of an Explorer > Post in Murray Hill where Dennis Ritchie was the advisor. Jon would > regularly bring UNIX tapes from the Research Lab and included things > like early versions of the Portable C Compiler and the Circuit Design > Aids. Chris used the Circuit Design Aids to design wire-wrap boards for > the Nu Terminal and the RTS lab got a semi-automatic wire wrap machine. > Some students and staff took turns doing the actual wire wrapping. My > contribution was writing some simple software that simulated a paper > tape reader for the wire wrap machine. > > An undergraduate student, Mike Patrick, did his bachelor's thesis > writing a table driven assembler and constructed tables for the 8086 and > I think an 8080. Later there were drivers for the Zylog Z8000, the > National Semiconductor NS16000 and the Motorola 68000. I contributed a > small bit of code for doing optimal choice of short vs long branches (to > branch to an address more than +/- 127 bytes, you had to branch around a > longer jump instruction). > > Chris Terman did the work of modifying the Portable C Compiler to > generate code for the 8086, the Z8000, NS16000 and MC68000. I think we > may have built one machine with the Z8000, but quickly settled on using > the MC68000, primarily because of the 32-bit support (one progress > report says that Zenith was supposed to build multiple Z8000 based > machines, but I don't remember those. The NS16000 had better memory > management, but I don't think we ever actually received any CPU chips. > > Anyway, these compilers were what was distributed, and the MC68000 > compiler in particular was used by almost all the companies that came > out the MC68000-based Unix machines. Apollo was a notable exception, but > Apollo wrote their own operating system from scratch rather than Unix. > Side note: Bill Poduska came to visit Steve Ward and before the visit > Steve was all excited, but was disappointed that Bill was not going to > use Unix. > > Before the RTS group used Unix, they had written a small timesharing > system for the PDP-11/45 that was used in the 6.031 introductory > computer science course taught by Mike Dertouzos. Chris was involved in > maintaining that, though I think Steve Ward was probably the main > implementor. Chris had also spent too many hours changing address > jumpers on Unibus and other controllers as well as tweaking Unix mkconf > files, and thought that while the 4BSD autoconfiguration was an > improvement, there should be a better way. Chris and Steve designed the > Nu bus, and the Nu Bus was used in the MC68000 boards. Eventually it was > picked up by Apple. > > Chris was one of many students who took the Mead/Conway LSI design > course and ended up abandoning his research on portable compilers in > favor of simulating LSI designs. He was also a co-founder of Symbolics > and designed the controller for their laser printer before returning to > MIT as a Lecturer and sponsored research staff. > > There were also proposed follow-on software projects related to the Nu > terminal. One was Trix. Steve Ward said he didn't know what an "ics" > was, but Multics clearly had too many, and Unix had too few, hence Trix. > Jack Test was hired to do a lot of the development. Wikipedia has a > reasonable summary of Trix, as far as I remember, but I had left RTS to > join Masscomp in late 1981/early 1982, and I know Jack Test was an early > employee of Alliant Computer so he left Trix probably in 1982. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat May 3 01:28:03 2025 From: aek at bitsavers.org (Al Kossow) Date: Fri, 2 May 2025 08:28:03 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On 5/2/25 8:15 AM, Clem Cole wrote: > Thank you, Tom, for the definitive answers to much of this. This is a huge help to me. I came to Apple just before the Mac II was released and know all of the people that were involved with designing our PC version of Nubus. One of the people was Tony Masterson who came to Apple from TI, and I think I remember him telling me he was a MIT grad student. I've traced the path from Western Digital to TI for Nubus George White seems to be the MIT - Western Digital connection. http://bitsavers.org/pdf/ti/nubus/White_-_Nubus_Computer_Design_19840615.pdf Getting back to Unix, TI used Nubus to build the Explorer Lisp machines, with roots back to the MIT CADR based on the Nu Machine (aka TI 1500 Unix system). HP bought the 1500 product line, which was then EOL'ed. From jsg at jsg.id.au Sat May 3 19:16:57 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 3 May 2025 19:16:57 +1000 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On Fri, May 02, 2025 at 08:28:03AM -0700, Al Kossow wrote: > On 5/2/25 8:15 AM, Clem Cole wrote: > > Thank you, Tom, for the definitive answers to much of this. > > This is a huge help to me. I came to Apple just before the Mac II was released and know > all of the people that were involved with designing our PC version of Nubus. One of the > people was Tony Masterson who came to Apple from TI, and I think I remember him telling > me he was a MIT grad student. I've traced the path from Western Digital to TI for Nubus > George White seems to be the MIT - Western Digital connection. > http://bitsavers.org/pdf/ti/nubus/White_-_Nubus_Computer_Design_19840615.pdf James Gula was another person who moved from MIT to WD to TI. "Jim Gula has left the LCS staff to join WD; while we regret losing him, we feel that he will serve important roles both in the MIT/WD interface and in making the Nu into a successful product." LCS Progress Report 18, July 1980 - June 1981, p 212 "In December, it was concluded that the research interests of the TRIX project were best served by a re-engineering of its internal structure rather than by polishing of the existing implementation. In order to reconcile this plan with the need for a viable Nu programming environment for other projects, Version 7 UNIX was ported to the Nu during the Spring by Gula, Sieber, Terman, and Test." LCS Progress Report 18, July 1980 - June 1981, p 213 "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. We have an Ethernet based version of this Unix running at Stanford" Vaughan Pratt on fa.works, Jan 1982 https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ https://www.saildart.org/WORKS.MSG[UP,DOC]28 James Gula on LinkedIn: Engineering Manager, Texas Instruments, 1983 - 1986 Engineering manager for the Nu Machine Project Software Engineering Manager, Western Digital, 1981 - 1983 Managed the UNIX port to the Nu Machine project Technical Staff, MIT LCS, 1979 - 1981 Port of UNIX to the Nu Machine and related software. From douglas.mcilroy at dartmouth.edu Sat May 3 22:14:18 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 3 May 2025 08:14:18 -0400 Subject: [TUHS] Paragraphs formatted differently depending on previous ones Message-ID: Branden, > The relevant function fits on one screen, if your terminal window is at > least 36 lines high. :) (Much of it is given over to comments.) > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=d96a9c58bbe296b065fa250e3ea1e1a410cdde81#n2185 Actually there's still another function, spread_space that contains the inner R-L and L-R loops. The whole thing has become astonishingly complicated compared to what I remember as a few (carefully crafted) lines of code in the early roff. I admire your intrepid forays into the groff woods, of which this part must be among the less murky. Doug From g.branden.robinson at gmail.com Sat May 3 22:58:41 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 3 May 2025 07:58:41 -0500 Subject: [TUHS] Paragraphs formatted differently depending on previous ones In-Reply-To: References: Message-ID: <20250503125841.fmom3jjpgh4djyxq@illithid> [looping the groff list back in; Doug emailed TUHS instead] At 2025-05-03T08:14:18-0400, Douglas McIlroy wrote: > > The relevant function fits on one screen, if your terminal window is > > at least 36 lines high. :) (Much of it is given over to comments.) > > > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=d96a9c58bbe296b065fa250e3ea1e1a410cdde81#n2185 > > Actually there's still another function, spread_space that contains > the inner R-L and L-R loops. Yes. `distribute_space()` is in "env.cpp" (environment handling) and operates on the output line. `spread_space()` is in "node.cpp" and is what alters the width of `word_space_node` (and derived `unbreakable_space_node`) objects on the line. Whereas in troff mode, often every adjustable space on an underset line experiences adjustment, in nroff mode the converse is frequently true, as shown below. Some of this stuff will be more visible for debugging purposes with the new `pline` request and improved `pm` request in the forthcoming groff 1.24.0 release. Here's an altered version of the adjustment demonstrator I cooked up for Alex. It uses a shorter line length and fewer repetitions of "alex", but still illustrates alternating adjustment "parity", as I term it. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; \ printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; echo .dd; } \ | nroff 2>/dev/null | cat -s alex alex alex alex alex alex alex If we discard normal output with the `-z` option, reënable output to standard error, and send that to jq(1) for formatting, we get more information, which I'll relegate to a footnote because it's lengthy.[1] It also serves to illustrate how we can dump diversions, and the intriguing properties thereof in GNU troff. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; \ printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; } | nroff -z 2>&1 | jq > The whole thing has become astonishingly complicated compared to what > I remember as a few (carefully crafted) lines of code in the early > roff. The first computer I ever touched, and programmed, had 16 KB of RAM. Necessity is a mother in more than one sense. ;-) I'm doing what I can with the GNU troff code base to make it more intelligible. Among the windmills I'm tilting at are improved type annotations (like using `bool` for Booleans instead of integers for Yet Another Purpose), explicitly annotated null pointers, and above all, more meaningful variable and function names. Kernighan and Plauger, then Pike, beat this drum repeatedly in their books on programming style, but we're still not rid of hackers who think naming a variable `bflag` is a good idea. > I admire your intrepid forays into the groff woods, of which this part > must be among the less murky. Thank you! The reformed handling of device extension requests/escapes so that they could encode Unicode characters, and their conversion into nodes, was almost more murk than I could stand. I think it might have helped to have some of the new introspection features 12-18 months ago, but we have them now. There's always more to learn, and to document. For those who hadn't noticed, I'll put the relevant part of the "NEWS" file in another footnote.[2] I'm on the verge of adding another, `pftr`, to dump the dictionary of font translations (remappings), because mdoc is proving to be a headache this week with Savannah #66126. Regards, Branden [1] Observe how some of the `word_space_node`s have a width of `24`, and others a width of `48`. The latter are the "adjusted" spaces. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; } | nroff -z 2>&1 | jq { "name": "dd", "file name": "", "starting line number": 2, "length": 35, "contents": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\n\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\n", "node list": [ { "type": "line_start_node", "diversion level": 0, "is_special_node": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 48, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 24, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": -40 }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": 0 }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 24, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 48, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": -40 }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": 0 } ] } [2] NEWS: ---snip--- * A new request, `pcolor`, reports to the standard error stream details of each color name specified as an argument, including its color space identifier and channel value assignments. Without arguments, all defined colors are listed. (A device's default stroke and/or fill colors, "default", are not listed since they are immutable and their details unknown to the formatter.) * A new request, `pchar`, reports to the standard error stream data about any ordinary, special, or indexed character arguments. * A new request, `pcomposite`, reports to the standard error stream the list of defined composite character mappings. * A new request, `phw`, reports to the standard error stream the list of hyphenation exceptions associated with the current hyphenation language. * A new request, `pline`, reports to the standard error stream the list of output nodes (an internal data structure) corresponding to the pending output line. The list is empty if no such nodes exist. * The `pm` request now interprets any arguments as a sequence of macro, string, or diversion names, and reports their contents. * The `pnr` request now additionally reports the autoincrementation amount and interpolation format of each register (if it is not string-valued). * The `pnr` request now accepts arguments. It treats each as identifying a register and reports its properties to the standard error stream. * A new request, `pstream`, reports to the standard error stream the name of each stream opened with the `open` or `opena` requests, the name of the file backing it, and its mode (writing or appending). ---end snip--- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tjteixeira at earthlink.net Sat May 3 23:49:18 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Sat, 3 May 2025 09:49:18 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: <2e5786ed-73b2-4dac-b413-180fca01428e@earthlink.net> On 5/2/25 11:15 AM, Clem Cole wrote: > Thank you, Tom, for the definitive answers to much of this.  I > remembered that the Z8000 was mixed up in that mess, but it was > missing from Al's Trix tape.  Do you know if a Z8000 back end or set > of support tools was ever built, and if so, does anyone know if they > survived?  It does look like Al has 8086 [Terman compiler].  68K (of a > few flavors) and an NS16032 (author's unknown).  One of the tools you > mentioned from MIT seems to have survived, although Dennis and I saved > the official UNIX Circuit Design System release in the > mid-1990s. Warren has had that TUHS archives ever since, but I'm not I > ever saw you tools other than things like you 68K assembler, and I > guess is was our fiiend Wayne that wrote the linker (which until this > thread I did not now). > > BTW: Again, it proves how interwoven the people and tech (i.e., open > source culture) were in the 1970s; i.e., it's not a new thing.  The > PDPs were running the Stanford Circuit Design System (SUDS) and the > 11's often at USCD.  The people came and went.   For instance,the > former Wayne was a year ahead of me at CMU before he headed to MIT for > a Master's and PhD, > ᐧ > > I'm pretty sure a Z8000 back end was produced because I remember that we built at least one Z8000 board. One of the LCS progress reports mentions that Zenith had committed to build some Z8000 systems, back when "office automation" was a thing. However, I have no idea what happened to the tools. I don't remember anyone but Chris producing back ends, but it's possible someone else did the NS16032. But I don't remember anything else about the NS16000 systems. The tools Chris and others produced in support of the Mead/Conway LSI course were also widely distributed, but I'm not sure what the mechanism. Since those were completely unencumbered by Unix, there was probably less formality, but I expect the MIT license was included. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun May 4 04:29:14 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 3 May 2025 11:29:14 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > We have an Ethernet based version of this Unix running at Stanford" > Vaughan Pratt on fa.works, Jan 1982 > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > https://www.saildart.org/WORKS.MSG[UP,DOC]28 Since I've never seen the design for the original Nu 68K I wonder if that was where the "SUN" segment/page MMU came from, since it looked similar to what was in the CADR, and if the sniffing of the stack to see if it needed to grow on function calls came from the Terman compiler. From clemc at ccc.com Sun May 4 05:01:05 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 3 May 2025 15:01:05 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: There were a couple of solutions, but they were all similar, which might be challenging to figure out now. The first gen of the the micros needed an external MMU and by the time of the Z8000/68K family/NS16032/and even the Intel devices were already several different MMU from mini's and mainframes which the different microprocessor MMU swiped different ideas and added a few other there own (particular to them). I think poking around the Asilimor Workshop Archives is likely to be the most fruitful. I would love to find a copy of Forest Basket's paper where he proposed using 2 68000's as 'executor' and 'fixer' as Apollo and Masscomp would do [many of those were from Asilomar - Forest's was]. Yale Patt and a few of his students had a few MMU papers for some of the chips around that time, IIRC. Sadly, my copies of that stuff from a few of those Asilomar conferences were lost. ᐧ On Sat, May 3, 2025 at 2:29 PM Al Kossow wrote: > > > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > > We have an Ethernet based version of this Unix running at Stanford" > > Vaughan Pratt on fa.works, Jan 1982 > > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > > https://www.saildart.org/WORKS.MSG[UP,DOC]28 > > Since I've never seen the design for the original Nu 68K I wonder if > that was where the "SUN" segment/page MMU came from, since it looked > similar to what was in the CADR, and if the sniffing of the stack to > see if it needed to grow on function calls came from the Terman compiler. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun May 4 05:14:48 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 3 May 2025 12:14:48 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On 5/3/25 12:01 PM, Clem Cole wrote: > There were a couple of solutions, but they were all similar, which might be challenging to figure out now. The first gen of the the micros > needed an external MMU and by the time of the Z8000/68K family/NS16032/and even the Intel devices were already several different MMU from > mini's and mainframes which the different microprocessor MMU swiped different ideas and added a few other there own (particular to them).  I > think poking around the Asilimor Workshop Archives is likely to be the most fruitful.  I would love to find a copy of Forest Basket's paper > where he proposed using 2 68000's as 'executor' and 'fixer' as Apollo and Masscomp would do [many of those were from Asilomar - Forest's > was].  Yale Patt and a few of his students had a few MMU papers for some of the chips around that time, IIRC.   Sadly, my copies of that > stuff from a few of those Asilomar conferences were lost. > I hope the scanning and preservation efforts of the past 20 years continues. As a naive engineer coming to the Valley in 1984 with my only prior exposure being Usenet, the degree of tribal knowledge and interconnectedness took a while to realize. I'm still learning things, for example what is coming to light here, even after working at the Computer History Museum for almost 20 years now along with realizing how much of Valley folklore we don't have in our archives. From kevin.bowling at kev009.com Sun May 4 13:53:42 2025 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 3 May 2025 20:53:42 -0700 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: On Fri, May 2, 2025 at 5:21 AM Aharon Robbins wrote: > Hi All. > > In a book I'm updating, I have the following references for > Unix security. > > 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, > Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, > CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. > > 2. Building Secure Software: How to Avoid Security Problems the Right Way, > by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, > USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. > > 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew > Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, > 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. > > One of my reviewers asked if these weren't "dusty references". > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > I’d have to rummage around for a definitive answer but I think things have fractured a bit and OS level security is either a chapter or section in academic or professional books. That is mostly survey or long standing information, the edge is all in open source code and/or papers/presentations. There are several recent cryptography books aimed at a more practitioner level I can recommend if that is relevant to your quest. The main book that comes to mind 0321822137 is a C and C++ security survey that is worthwhile but not OS specific. I’d also like to know your title so I can add it to my collection when it is ready! > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun May 4 16:48:29 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 4 May 2025 16:48:29 +1000 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On Sat, May 03, 2025 at 11:29:14AM -0700, Al Kossow wrote: > > > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > > We have an Ethernet based version of this Unix running at Stanford" > > Vaughan Pratt on fa.works, Jan 1982 > > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > > https://www.saildart.org/WORKS.MSG[UP,DOC]28 > > Since I've never seen the design for the original Nu 68K I wonder if > that was where the "SUN" segment/page MMU came from, since it looked > similar to what was in the CADR, and if the sniffing of the stack to > see if it needed to grow on function calls came from the Terman compiler. Perhaps the Nu paper mentions an MMU? Referenced by the SUN documents, but not available online. S. A. Ward and C. J. Terman, "An approach to personal computing" Proceedings of COMPCON, IEEE, February 1980, pp. 460-465. IEEE doesn't have it online at https://www.computer.org/csdl/proceedings/1000109 The CHM has the proceedings: https://www.computerhistory.org/collections/catalog/102713995 CompCon80; VLSI: New Architectural Horizons; 1980. -- "The one question mark for the CPU board design was the memory management unit, to which Andy, Forest (who sent us a design while at PARC), and I all made significant contributions." Vaughan Pratt, in: >From the Valley of Heart's Delight to the Silicon Valley: A Study of Stanford University's Role in the Transformation Appendix A: The Founding of Sun Microsystems http://infolab.stanford.edu/pub/cstr/reports/csl/tr/97/713/CSL-TR-97-713.ps "So we switched to the 68000. I think we ended up with a 6810 as the original processor. I designed a memory-mapping system for that processor, which barely had the capabilities to do memory mapping. The original SUN workstation had a really fascinating memory mapping system. I was a little annoyed with Andy, because years later I discovered that he had patented that memory mapping system." Oral History of Forest Baskett, p 13 https://archive.computerhistory.org/resources/access/text/2017/12/102717243-05-01-acc.pdf https://patents.google.com/patent/US4527232A/en https://patents.google.com/patent/US4550368A/en From rich.salz at gmail.com Sun May 4 22:05:42 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 4 May 2025 08:05:42 -0400 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: The Bellovin and Cheswick book(s) although it's more about network security and firewalls. The OWASP guides. Practical UNIX and Internet security Book by Simson Garfinkel -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Sun May 4 22:46:29 2025 From: norman at oclsc.org (Norman Wilson) Date: Sun, 4 May 2025 08:46:29 -0400 (EDT) Subject: [TUHS] Off topic: Books on Unix security? Message-ID: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> Aharon Robbins: So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. === `Unix security' is not the most-specific of terms. Can you give more context? Norman Wilson Toronto ON From arnold at skeeve.com Sun May 4 23:32:21 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 04 May 2025 07:32:21 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> References: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> Message-ID: <202505041332.544DWLj41616716@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > Aharon Robbins: > > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > > === > > `Unix security' is not the most-specific of terms. Can > you give more context? > > Norman Wilson > Toronto ON Classic things like setuid programs, writing daemons, as well as general secure coding practices for C and C++ in a *nix context. Thanks, Arnold From rik at rikfarrow.com Mon May 5 04:01:12 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Sun, 4 May 2025 11:01:12 -0700 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: Paul von Oorschot's Tools and Jewels: https://people.scs.carleton.ca/~paulv/toolsjewels.html This was designed as a textbook for security, and includes very good coverage of cryptography. Rik On Sun, May 4, 2025 at 5:06 AM Rich Salz wrote: > The Bellovin and Cheswick book(s) although it's more about network > security and firewalls. > The OWASP guides. > Practical UNIX and Internet security Book by Simson Garfinkel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Wed May 7 00:16:21 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 6 May 2025 09:16:21 -0500 Subject: [TUHS] Paragraphs formatted differently depending on previous ones In-Reply-To: References: <20250503003445.2ker2h3dgomawk6h@illithid> Message-ID: <20250506141621.wbilioq2bl3ibb6n@illithid> [looping TUHS back in since I'm correcting a message I sent there] Hi Dave, At 2025-05-06T08:36:55-0500, Dave Kemper wrote: > On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson > wrote: > > I guess another way of saying this is that, as I conceive it, a line > > that is "adequately full" contributes to the page's uniformity of > > grayness by definition. > > For an example of less-than-ideal results if this is _not_ considered > the case (groff's behavior before this change), see > http://savannah.gnu.org/bugs/?60673#comment0 (the initial report that > precipitated the commit Doug is commenting on). Yes. In my reply to Doug I incorrectly characterized the resolution of this bug as a "2023" change of mine, but I actually landed the change in 2021. It simply took until 2023 to appear in a released _groff_. To make this message more TUHS-o-riffic, let's observe that input using DWB 3.3 troff and Heirloom Doctools troff (descended from Solaris troff, descended from DWB 2.0 troff [I think]), and both of which descend from Kernighan's device-independent troff circa 1980. $ DWBHOME=. ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. $ ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. They are the same, and differ from groff 1.22.4 and earlier only in that they adjust spaces starting from the right end of the line instead of the left. At the risk of tooting our own horn, here's how groff 1.23.0+ handles the same input. $ ~/groff-1.23.0/bin/nroff groff-60673.roff | cat -s While the example in bug 57836’s original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty’s balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn’t "count" lines that don’t need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. Three observations: 1. One can find the input at Dave's URL above. 2. The input disables inter-sentence spacing. 3. The adjustment algorithm is a property not of grotty(1) (the output driver), but of GNU troff itself. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From arnold at skeeve.com Wed May 7 01:01:00 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 May 2025 09:01:00 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: <202505061501.546F10gs1802134@freefriends.org> Thanks to everyone who responded. Besides the original three in my quoted email, here are the additional ones I was recommended and have added to the list in my book. Some were recommended by more than one person. In any case, thank you all! 4. Secure Coding in C and C++, 2nd Edition, by Robert Seacord. ISBN-10: 0321822137, ISBN-13: 978-0321822130, Addison-Wesley Professional, Reading, Massachusetts, USA, 2013. 5. Secure Coding: Principles and Practices, by Mark G. Graff, Kenneth R. Van Wyk, and Debby Russell. ISBN-10: 0596002424, ISBN-13: 978-0596002428. O’Reilly Media, Inc., USA, 2003. 6. Writing Secure Code, 2nd Edition, by Michael Howard and David LeBlanc. ISBN-10: 0735617228, ISBN-13: 978-0735617223. Microsoft Press, USA, 2003. 7. Computer Security and the Internet—Tools and Jewels from Malware to Bitcoin, 2nd Edition, by Paul C. van Oorschot. ISBN-13: 978-3-030-83410-4. Springer Nature Switzerland AG, 2021. 8. Thinking Security: Stopping Next Year’s Hackers by Steven M. Bellovin. ISBN-10: 0134277546, ISBN-13: 978-0134277547. Addison-Wesley Professional, Reading, Mas- sachusetts, USA, 2015. 9. Security Engineering: A Guide to Building Dependable Distributed Systems, 3rd Edi- tion, by Ross Anderson. ISBN-10: 1119642787, ISBN-13: 978-1119642787. Wiley, USA, 2020. 10. Designing Secure Software: A Guide for Developers, by Loren Kohnfelder. ISBN-10: 1718501927, ISBN-13: 978-1718501928. No Starch Press, USA, 2021. 11. Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems, by Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield. ISBN-10: 1492083127, ISBN-13: 978-1492083122. O’Reilly Media, USA, 2020. 12. Secure By Design, by Daniel Deogun, Dan Bergh Johnsson, and Daniel Sawano. ISBN-10: 1617294357, ISBN-13: 978-1617294358. Manning, USA, 2019. Aharon Robbins wrote: > Hi All. > > In a book I'm updating, I have the following references for > Unix security. > > 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, > Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, > CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. > > 2. Building Secure Software: How to Avoid Security Problems the Right Way, > by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, > USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. > > 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew > Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, > 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. > > One of my reviewers asked if these weren't "dusty references". > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > > Thanks, > > Arnold From crossd at gmail.com Wed May 7 08:52:49 2025 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 May 2025 18:52:49 -0400 Subject: [TUHS] ATC'25 is the last ATC? Message-ID: I just heard that, after ATC'25, USENIX will be sunsetting the annual technical conference: this will apparently be the last one. I can't find any reference for it, though, and the web site mentions ATC'26 in Seattle? - Dan C. From rik at rikfarrow.com Wed May 7 09:41:46 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 6 May 2025 16:41:46 -0700 Subject: [TUHS] Fwd: An Announcement about the USENIX Annual Technical Conference In-Reply-To: References: Message-ID: I received this earlier today, and wondered if cross-posting it would be appropriate. Here goes... Rik ---------- Forwarded message --------- From: Casey Henderson-Ross Date: Tue, May 6, 2025 at 2:12 PM Subject: An Announcement about the USENIX Annual Technical Conference To: Rik Farrow Read on for important news. [image: USENIX, the Advanced Computing Systems Association] Hello, Rik, USENIX celebrates its 50th anniversary in 2025. We celebrate decades of innovations, experiments, and gatherings of the advanced computing system community. And in the spirit of our ever-evolving community, field, and industry, we announce the bittersweet conclusion of our longest-running event, the USENIX Annual Technical Conference in July 2025, following USENIX ATC '25. Since USENIX's inception in 1975, it has been a key gathering place for innovators in the advanced computing systems community. The early days of meetings evolved into the two annual conferences, the USENIX Summer and Winter Conferences, which in 1995 merged into the single Annual Technical Conference that has continued to evolve and serve thousands of our constituents for 30 years. For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC. USENIX ATC in its many iterations has been the home of an incredible list of "firsts" in our industry: - In 1979, ONYX, the first attempt at genuine UNIX hardware, was announced. - In 1982, DEC unveiled the creation of its UNIX product. - In 1983, Eric Allman presented the first paper on Sendmail, "Mail Systems and Addressing in 4.2BSD." - In 1985, Sun Microsystems presented the first paper on NFS, "Design and Implementation of the Sun Network Filesystem." - In 1988, the first light on Kerberos and the X Window system was presented. - In 1989, Tom Christiansen made his first Perl presentation as an Invited Talk. - In 1990, John Ousterhout presented Tcl. - In 1995, the first talk on Oak (later JAVA) was given as a Work-in-Progress report. - In 1998, Miguel de Icaza presented "The GNOME Desktop Environment." These examples represent just a few of the many contributions presented at USENIX ATC over the years, with hundreds of papers that account for thousands of citations of work that the community has presented, discussed, learned from, and built upon as the community evolved. Part of that evolution involved the continued development of subcommunities, as has been the case with USENIX Security, which began as a workshop in 1988 and has since grown to an annual symposium and the largest of our events in terms of both papers published and number of attendees annually, with 417 papers and 1,015 attendees at USENIX Security '24. The LISA (Large Installation System Administration) Conference, which also started as a workshop in 1987, grew in a similar fashion to its peak of over 1,000 attendees, but like USENIX ATC declined as its community changed until its own sunset in 2021. Papers on file and storage systems that would have previously been presented at USENIX ATC in the early 2000s began to find homes at FAST when it was founded in 2002. Networked systems papers started flowing to NSDI in 2003. As the biennial OSDI continued to grow alongside ACM's SOSP, OSDI became annual in 2021 and SOSP followed suit, providing the community with additional venues. While landmark moments in our community have continued at USENIX ATC, many others have also occurred at these other USENIX conferences, as showcased in the USENIX Test of Time Awards and the ACM SIGOPS Hall of Fame Awards , which celebrate influential works presented at both SOSP and OSDI. Although numerous papers continue to be submitted to USENIX ATC with significant research being reviewed, accepted, and presented, the community has evolved, and now attends conferences other than USENIX ATC. From 1,698 attendees in San Diego in 2000, ATC attendance dwindled to 165 attendees in Santa Clara in 2024—even as we had over 4,000 people attend all USENIX conferences in 2024. USENIX recognizes the pivotal role that USENIX ATC has played in the shaping of the Association itself as well as the lives and careers of its many attendees and members. We also realize that change is inevitable, and all good things must come to an end: if it weren't for ATC being a "victim of its own great success"—a foundry of so many other successful conferences and workshops—USENIX would never have grown and expanded so much over the decades. Thus our hearts are heavy as we celebrate ATC's history and legacy alongside the evolution of its younger siblings and face the financial realities of the post-pandemic world and volatile global economy. USENIX's resources to support its conferences and communities are not unlimited, particularly as we maintain our commitment to open-access publications that are free for our authors to publish. We have been reporting about these challenges via our Annual Meeting and subsequent reports for the past several years (2024 , 2023 , 2022 , 2021 , 2020 ). We deeply appreciate the financial support we have received from our community in the form of donations, memberships, and conference registrations. However, we continue to operate at a deficit and ATC continues to shrink. In making this hard choice, accepting the reality in front of us that encourages us to innovate in a different direction under challenging circumstances, we seek to embody the values of this community that was founded on curiosity, persistence, and collaboration. As we celebrate 50 years of both USENIX and ATC in its varying forms, we look towards the future of this vibrant community in the form of the many conferences that ATC continues to help create in its image: welcoming, thoughtful environments for the presentation of innovative work that fellow conference attendees help push forward. We look forward to honoring ATC's legacy alongside USENIX's history and its future in Boston in July of 2025. We would love to hear memories of your experience at the USENIX Annual Technical Conference over the years. Please submit your thoughts in words, video, or both by *Monday, June 2*. We will share your memories both at USENIX ATC '25 and afterwards. We hope that you will join us at USENIX ATC '25 , which will include both a celebration of USENIX's 50th anniversary on the evening of *Monday, July 7*, and a tribute to USENIX ATC on the evening of *Tuesday, July 8*. [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed May 7 12:11:26 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Tue, 6 May 2025 19:11:26 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: References: Message-ID: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> On 5/6/25 15:52, Dan Cross wrote: > I just heard that, after ATC'25, USENIX will be sunsetting the annual > technical conference: this will apparently be the last one. > > I can't find any reference for it, though, and the web site mentions > ATC'26 in Seattle? See https://www.usenix.org/blog/usenix-atc-announcement -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From lm at mcvoy.com Wed May 7 12:55:26 2025 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 6 May 2025 19:55:26 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> Message-ID: <20250507025526.GC17185@mcvoy.com> On Tue, May 06, 2025 at 07:11:26PM -0700, Alan Coopersmith via TUHS wrote: > On 5/6/25 15:52, Dan Cross wrote: > >I just heard that, after ATC'25, USENIX will be sunsetting the annual > >technical conference: this will apparently be the last one. > > > >I can't find any reference for it, though, and the web site mentions > >ATC'26 in Seattle? > > See https://www.usenix.org/blog/usenix-atc-announcement I might regret this in the morning but I'd like to share when Usenix ceased to matter to me. I was the program committee chair for the 1999 Linux Expo which was a Usenix alternative. Before I go on, there is some back story. I reviewed papers for Usenix a bunch. One of the best papers I ever reviewed is this one: http://www.mcvoy.com/lm/papers/rtlmanifesto.pdf It got rejected, not on merit, but because Victor was not in the club, he was an unknown. Rob Gingell, someone I feared and respected, said he rejected it "because it wasn't posix". Not Rob's best day, the whole point was posix couldn't do what Victor did. Read that paper, it did real time right, nobody else has come close to do real time and time sharing. They fight each other. In 1999 when I was going to that conference, Ellie reached out to me and begged me to bring Linux to Usenix. She said I could have whatever I wanted, on the program committee for life, whatever I wanted. I asked for blind peer reviews. She said no. I used to love Usenix, I've written papers that were published there, but Usenix is dead to me. They did it to themselves. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From yuyi15968 at gmail.com Thu May 8 18:34:01 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Thu, 8 May 2025 16:34:01 +0800 Subject: [TUHS] Ken Thomson's email address? Message-ID: Oh, sorry guys, please forgive me for the off-topic question. I was wondering if anyone knows Ken Thomson's email address? I was wondering if he has any more archives of Unix from 1972 and before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu May 8 20:14:34 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 06:14:34 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508101434.3431818C084@mercury.lcs.mit.edu> > From: Jackson Helie G > I was wondering if anyone knows Ken Thomson's email address? I was > wondering if he has any more archives of Unix from 1972 and before. He does read this ist, and very occasionally posts to it. But there's no point bothering him, to ask; anything he had, he turned over many years ago. (To the point that people have recently been poring through the 'trash' bits in the "s1-bits" and s2-bit" tapes, IIRC, for lack of anything else to look at. Look for "A Census of /etc and /sys Prior to V4" in the TUHS archive to see some discussion of some of this work, by Matt Gilmore. I think somene else was working on it too, but I couldn't find it; I'm not up for looking through TUHS archives for it.) Noel From yuyi15968 at gmail.com Thu May 8 20:58:50 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Thu, 8 May 2025 18:58:50 +0800 Subject: [TUHS] Ken Thomson's email address? Message-ID: If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu May 8 22:13:26 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 08:13:26 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508121326.3163918C085@mercury.lcs.mit.edu> > From: Jackson Helie G > I would like to ask Ken Thompson if he has the first C compiler. He wouldn't; he didn't do much work on C. Dennis Ritchie (who created C) posted two very early ones here: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html Noel From clemc at ccc.com Thu May 8 23:42:00 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 May 2025 09:42:00 -0400 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: Message-ID: On Thu, May 8, 2025 at 6:59 AM Jackson Helie G wrote: > If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson > if he has the first C compiler. > The first "C" compiler wa an ephemeral state some time in the process of its evolution. Dennis started with his B implementation and began to add features he needed to support their new byte addressed PDP-11. He originalled called it nb or "new B." The compiler accepted the B syntax and new extensions for the new features. Eventually, the new feature started to make the language different enough the language became something he called C. At what time what was, I'm not sure I've ever heard anyone ever declare and definitive time or date. Look in https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ And start poking if you want to see early versions of the compiler. Have fun Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri May 9 00:04:31 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 10:04:31 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> > From: Clem Cole > The first "C" compiler wa an ephemeral state some time in the process > of its evolution. Dennis started with his B implementation and began to > add features he needed See: The Development of the C Language https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html for detail on the evolution. Noel From clemc at ccc.com Fri May 9 00:22:10 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 May 2025 10:22:10 -0400 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: Thanks, Noel. I should have pointed to that paper also. I have always considered the demarcation point when structures were added, but I darned if I knew at what date or time Dennis chose to rename it. Clearly, one day (night, more likely), he realized it nb was really not B anymore and needed a new name. ᐧ On Thu, May 8, 2025 at 10:04 AM Noel Chiappa wrote: > > From: Clem Cole > > > The first "C" compiler wa an ephemeral state some time in the process > > of its evolution. Dennis started with his B implementation and began > to > > add features he needed > > See: > > The Development of the C Language > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > for detail on the evolution. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri May 9 04:59:46 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 May 2025 18:59:46 +0000 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: On Thursday, May 8th, 2025 at 7:23 AM, Clem Cole wrote: > Thanks, Noel. I should have pointed to that paper also. I have always considered the demarcation point when structures were added, but I darned if I knew at what date or time Dennis chose to rename it. Clearly, one day (night, more likely), he realized it nb was really not B anymore and needed a new name. > ᐧ > > On Thu, May 8, 2025 at 10:04 AM Noel Chiappa wrote: > > > > From: Clem Cole > > > > > The first "C" compiler wa an ephemeral state some time in the process > > > of its evolution. Dennis started with his B implementation and began to > > > add features he needed > > > > See: > > > > The Development of the C Language > > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > > > for detail on the evolution. > > > > Noel For the record another source of old C compiler code would be in the s1/s2 tapes here: https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ I'm not in a place to dig into them right now but one of the two tapes is a V2 root filesystem backup, the C compiler should be in a couple stages in /lib. Granted, its binary, but with enough disassembly work and comparison with other sources, it may be possible to recreate a compelling facsimile of whatever revision that represents. Otherwise as others have stated, the historic C compiler situation has been quite well plundered by this and other groups, supplemented of course by Dennis Ritchie's foresight to keep and provide so many artifacts and anecdotes. - Matt G. From mrochkind at gmail.com Fri May 9 05:38:19 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 8 May 2025 13:38:19 -0600 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: Seems that the subject line of this thread should be changed. Marc On Thu, May 8, 2025 at 1:00 PM segaloco via TUHS wrote: > On Thursday, May 8th, 2025 at 7:23 AM, Clem Cole wrote: > > > Thanks, Noel. I should have pointed to that paper also. I have always > considered the demarcation point when structures were added, but I darned > if I knew at what date or time Dennis chose to rename it. Clearly, one day > (night, more likely), he realized it nb was really not B anymore and needed > a new name. > > ᐧ > > > > On Thu, May 8, 2025 at 10:04 AM Noel Chiappa > wrote: > > > > > > From: Clem Cole > > > > > > > The first "C" compiler wa an ephemeral state some time in the process > > > > of its evolution. Dennis started with his B implementation and began > to > > > > add features he needed > > > > > > See: > > > > > > The Development of the C Language > > > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > > > > > for detail on the evolution. > > > > > > Noel > > For the record another source of old C compiler code would be in > the s1/s2 tapes here: > https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ > > I'm not in a place to dig into them right now but one of the two > tapes is a V2 root filesystem backup, the C compiler should be > in a couple stages in /lib. Granted, its binary, but with > enough disassembly work and comparison with other sources, it > may be possible to recreate a compelling facsimile of whatever > revision that represents. > > Otherwise as others have stated, the historic C compiler > situation has been quite well plundered by this and other > groups, supplemented of course by Dennis Ritchie's foresight to > keep and provide so many artifacts and anecdotes. > > - Matt G. > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri May 9 11:42:59 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 9 May 2025 11:42:59 +1000 Subject: [TUHS] Old C compilers (was: Ken Thomson's email address?) In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: On Thursday, 8 May 2025 at 13:38:19 -0600, Marc Rochkind wrote: > On Thu, May 8, 2025 at 1:00 PM segaloco via TUHS wrote: > >> >> For the record another source of old C compiler code would be in >> the s1/s2 tapes here: >> https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ >> >> I'm not in a place to dig into them right now but one of the two >> tapes is a V2 root filesystem backup, the C compiler should be >> in a couple stages in /lib. Granted, its binary, but with >> enough disassembly work and comparison with other sources, it >> may be possible to recreate a compelling facsimile of whatever >> revision that represents. Years ago (February 2000) I got the sources of a 1972 C compiler that I was able to compile and run on FreeBSD. The tarball should be called last1120c.tar.gz . I assume that I got it from the TUHS archive, but if you can't find it, let me know. > Seems that the subject line of this thread should be changed. Agreed. You, too, could have done this. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri May 9 13:32:41 2025 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 8 May 2025 22:32:41 -0500 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> On 5/2/25 7:21 AM, Aharon Robbins wrote: > 1. Practical UNIX & Internet Security, 3rd edition, by Simson > Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, > Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: > 978-0596003234. ... > One of my reviewers asked if these weren't "dusty references". So, > before I just refer to them as "classics", can anyone recommend more > recent books? Feel free to answer in private. Having read (most of) Practical UNIX & Internet Security, 3rd edition, and other similar texts... I've come to the realization that we as an industry haven't really moved beyond all of the problems taught to us in the '90s. It's really amazing to me how much of the advice given in those "classic" tombs is still as germane today as it was 30 years ago. Sure, some things have fallen off the bottom. But mostly, we've just added things on top. Fundamentals may get old, but they usually don't become wrong. -- Grant. . . . From arnold at skeeve.com Fri May 9 16:19:47 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 09 May 2025 00:19:47 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> References: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> Message-ID: <202505090619.5496JlsM2032047@freefriends.org> Hi. Grant Taylor via TUHS wrote: > Having read (most of) Practical UNIX & Internet Security, 3rd edition, > and other similar texts... > > I've come to the realization that we as an industry haven't really moved > beyond all of the problems taught to us in the '90s. Sad, but true. > It's really > amazing to me how much of the advice given in those "classic" tombs is Um, "tomes" is what I think you meant. :-) > still as germane today as it was 30 years ago. > > Sure, some things have fallen off the bottom. But mostly, we've just > added things on top. > > Fundamentals may get old, but they usually don't become wrong. This last statement is exactly right. And in fact, it is my book on the fundamental *nix APIs that I'm updating.... Feel free to ping me privately if you want more info. Much thanks, Arnold P.S. Can I quote your statement? From yuyi15968 at gmail.com Sun May 11 20:28:25 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Sun, 11 May 2025 18:28:25 +0800 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: I checked Dennis M. Ritchie's "Users' Reference to B" and found an example of implementing a B program at the bottom of the manual. It said that bc generates intermediate code suitable for ba, and then ba generates assembly code. So, I am curious about what the intermediate code generated by bc is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjteixeira at earthlink.net Mon May 12 01:06:19 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Sun, 11 May 2025 11:06:19 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: Message-ID: On 5/11/25 6:28 AM, Jackson Helie G wrote: > I checked Dennis M. Ritchie's "Users' Reference to B" and found an > example of implementing a B program at the bottom of the manual. It > said that bc generates intermediate code suitable for ba, and then ba > generates assembly code. So, I am curious about what the intermediate > code generated by bc is? I found this reference (https://www.softwarepreservation.org/projects/BCPL/cambridge/Richards-Bootstrapping_BCPL-1973.pdf) written by Martin Richards about the intermediate code of BCPL. I never saw or used B, but this is one possibility. But it seems very different from C compilers prior to the Portable C Compiler, even though code generation was table driven (https://wolfram.schneider.org/bsd/7thEdManVol2/ctour/ctour.html). Note, before the RTS group at Project MAC started using UNIX, we had a home-written operating system for PDP-11/45 and PDP-11/70. I got a BCPL compiler from somewhere and made some enhancements - such as direct support for external variables and routines using a linker rather than the pure BCPL global array. When RTS got access to a VAX-11/780 running VMS, I was able to modify the Sixth or Seventh edition C compiler to generate code for the VAX-11/780 and wrote enough of a compatibility library to port various C programs to VMS. All that vanished once we were able to install 4BSD on the VAX-11/780. The machine was shared by the people doing the NIL project (New Implementation of LISP) on the VAX. I don't remember the details, but this paper coauthored by Guy Steele (https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf) implies that NIL shifted their efforts to a different target machine: "In 1978, Gabriel and Guy Steele set out to implement NIL [Brooks, 1982a] on the S-1 Mark IIA, a supercomputer being designed and built by the Lawrence Livermore National Laboratory [Correll, 1979; Hailpern, 1979]." -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon May 12 16:26:15 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 06:26:15 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: Message-ID: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> On May 11, 2025, at 03:28, Jackson Helie G wrote: > I am curious about what the intermediate code generated by bc is? Hi, I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in reconstructing B, which is probably the most extensive and faithful to the original. He’s written B compilers[0] in C for bootstrapping purposes, another in B, and reconstructed one in B which works on Unix V1. The intermediate code I think you’re referring to is the threaded code, which Angelo covers on his site[1], from having reverse engineered libb and bilib. There was some discussion on this list about it some years ago[2]. His work is probably the best resource. [0]: https://github.com/aap/b [1]: http://squoze.net/B/ [2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html Thalia From tuhs at tuhs.org Mon May 12 17:00:16 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 07:00:16 +0000 Subject: [TUHS] Unix Reverse Engineering Message-ID: <333C42E6-1B13-489C-919C-B496BDD2340B@archibald.dev> Hello everyone, I'm working on building a decompiler from PDP-11 assembly to C to ease studying old pre-C Unix sources. To start, I'm translating V5 `as` to period-idiomatic C and have finished most of pass 1. Then I'll port it to Rust with a design better suited to static analysis, while keeping exact fidelity to the original. I'll do the same for `cc` and `ld`, after. I stumbled upon Warren's disaout[0] today, which made me wonder: What tools have people for reverse engineering Unix assembly sources or a.out binaries? Things like disassemblers or decompilers. I assume there's some versions of programs which are now only extant as binaries? Are there enough such binaries that were written in C to warrant writing a decompiler that understands the specific codegen of `cc` to improve accuracy? For now, I'm focusing on decompiling hand-written assembly, but I'm keeping this case in mind. Thanks! Thalia [0]: https://github.com/DoctorWkt/unix-jun72/tree/master/tools/disaout From aap at papnet.eu Mon May 12 17:14:14 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 12 May 2025 09:14:14 +0200 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> Message-ID: Hi, thanks for mentioning my project! I recently ported the compiler to ITS on the PDP-10 and had to revisit the question of the intermediate code. My take is that it was probably an ASCII code and not all too different from PDP-7 assembly. One striking difference between the PDP-7 and PDP-11 interpreter that have survived is the handling of lvalues. Taking the address of something is done by an operator (u1) in the PDP-7 interpreter, whereas on the PDP-11 this is handled somewhere in the compilation process, and in addition to the automatic (a) and external (x) operators there are now lvalue versions of them (va and vx). I very very strongly suspect that this is handled by the B assembler and not the compiler. Two other questions are where the 'i'-versions of the a/x/c operators and the control flow of the conditional ?: operator were handled. For the latter i concluded it had to be the assembler, although the label numbers in printf.o are in line with those that would have been generated by the compiler. In contrast, the first and second pass of the C compiler use different ranges of labels. Unfortunately all these questions appeared and became clearer only over time and as a result there are various incarnations of my reconstructed compiler in the github repo....I should really make a push to clean it up a bit better, it's a complete mess. You may also want to check out my talk on B at VCFB 2024: https://www.youtube.com/watch?v=OLDTPlLa1bI Cheers, aap On 12/05/25, Thalia Archibald via TUHS wrote: > On May 11, 2025, at 03:28, Jackson Helie G wrote: > > I am curious about what the intermediate code generated by bc is? > > > Hi, > > I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in > reconstructing B, which is probably the most extensive and faithful to the > original. He’s written B compilers[0] in C for bootstrapping purposes, another > in B, and reconstructed one in B which works on Unix V1. The intermediate code I > think you’re referring to is the threaded code, which Angelo covers on his > site[1], from having reverse engineered libb and bilib. There was some > discussion on this list about it some years ago[2]. His work is probably the > best resource. > > [0]: https://github.com/aap/b > [1]: http://squoze.net/B/ > [2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html > > Thalia From tuhs at tuhs.org Mon May 12 18:10:59 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 08:10:59 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> Message-ID: <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> On May 12, 2025, at 00:14, Angelo Papenhoff wrote: > thanks for mentioning my project! > I recently ported the compiler to ITS on the PDP-10 and had to revisit > the question of the intermediate code. > My take is that it was probably an ASCII code and not all too different > from PDP-7 assembly. Very interesting! Is your take on the intermediate code the cases in pdp10_its/ba10.b:cexpr? In your compilers, you hack in preprocessing with sed. Do you know for sure that B had no preprocessor? It seems inconceivable now, as even `as` had constants. > You may also want to check out my talk on B at VCFB 2024: > https://www.youtube.com/watch?v=OLDTPlLa1bI I just watched your talk. Now the B intermediate language makes a lot more sense and I want to write a B compiler :). Have you done any further archaeology work on NB since what you have at ? How did you analyze the old tapes? Is there anything left there to examine? Thalia From jnc at mercury.lcs.mit.edu Mon May 12 20:58:43 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 06:58:43 -0400 (EDT) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> > From: Tom Teixeira > before the RTS group at Project MAC (Called the DSSR group at that point om time, if anyone wants to look anything up.) > I got a BCPL compiler from somewhere and made some enhancements - such > as direct support for external variables and routines using a linker > rather than the pure BCPL global array. This entire toolchain, including all the source, has been preserved; the BCPL compiler, the linker ('bind', itself written in BCPL), and a number of tools (including an extra one, 'ldrel', written by the CSR group on the 5th floor). I have in the past put up some pieces for download, but I never got around to doing the whole thing, as there didn't seem to be any interest. We (CSR) started working with the toolchain because it included support for MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler source as output). That toolchain used a relocatable formet, .rel': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5 that I think was based on one DEC had done. CSR was working with a semi-real-time operating system, called 'MOS': https://gunkies.org/wiki/MOS_operating_system for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work on the Internet; e.g. all the BBN 'core' routers used in the early Internet used it, after the very first ones [written in BCPL, oddly enough], which had used ELF: https://gunkies.org/wiki/ELF_operating_system but BBN soon switched to MOS.) MOS was written in MACRO-11; we started working with MOS with the same toolchain SRI had used for it, which ran on TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So, we started working with the MACRO-11, and bind, on UNIX. I then decided I'd rather write code for our PDP-11 packet switches in this nifty language called C, used on UNIX, which nobody else knew about (at that point). The first step was to write 'ldrel', to convert a.out files (produced by the C compiler) to .rel files, so 'bind' could work with them. After a while, we decided we'd rather use 'ld' as our linker (I think because it supported demand loading from binary libraries, so we didn't have to manually specify every file to link). The DSSR group had long ago written 'relld', which converted .rel files (produced by MACRO-11) to a.out files, so that was pretty easy. There seems to be a version of the BCPL compiler which produces 8080 code. It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C compiler was not done at MIT). (I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and they seem to have done a lot of work with various micros. It may not have all the pieces it needs to work, though; it seems to need "/usr/simulators/s6502/s6502.body" from the DSSR machine.) Pity I didn't save a dump of that machine too; I was once looking for the source of the Algol interpreter, written on the Delphi machine, and made to run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine still existed, and he thought not. So we have the binary of that Algol interpreter, but not the source. Of course, it was probably written in MACRO-11, so a disassembler would produce a reasonable facsimile. And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the MIT archives - they might well have done, and Prof. Ward just didn't know that. Noel From jnc at mercury.lcs.mit.edu Mon May 12 21:04:14 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 07:04:14 -0400 (EDT) Subject: [TUHS] Unix Reverse Engineering Message-ID: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> > From: Thalia Archibald > I'm working on building a decompiler from PDP-11 assembly to C to ease > studying old pre-C Unix sources. To start, I'm translating V5 `as` to > period-idiomatic C That's going to be a real trick; 'as' was written in PDP-11 assembler: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/as Noel From tuhs at tuhs.org Mon May 12 22:48:51 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 12:48:51 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> Message-ID: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> On May 12, 2025, at 04:04, Noel wrote: > That's going to be a real trick; 'as' was written in PDP-11 assembler: It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 lines or 7/20 files in my translation of `as` to C. It seems that it was never ported to C by the original authors, so this is probably the most closely someone’s looked at many parts of it in a long time. I’ve very steadily been improving my PDP-11 assembly skills and rather efficient now. It’s quite tedious tracking all the register effects, though good signatures annotated with in- and out-registers helps a lot. I feel like a compiler, manually performing control flow structuring like the Relooper or LLVM Stackifier algorithms. With this completed, my manual effort will bootstrap reverse engineering the rest with a proper decompiler. Thalia From lars at nocrew.org Mon May 12 23:38:52 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 12 May 2025 13:38:52 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon, 12 May 2025 06:58:43 -0400 (EDT)") References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> Message-ID: <7wsela0x03.fsf@junk.nocrew.org> Noel Chiappa writes: > And I should ask Lars if the backup tapes of the DSSR/RTS machine went > to the MIT archives - they might well have done, and Prof. Ward just > didn't know that. They might. There are thousands of tapes, most of which are from ITS or TOPS-20. But that still leaves room for hundreds of Unix tar, dump, and cpio tapes in various interesting 16/32-bit and big/little endian combinations. I'm guessing they are 4BSD, Sun, and maybe PDP-11 formats. I haven't taken the time to go through them; in many cases modern tools don't work, so I have to make my own. A propos Teixeira's message, there are also VMS tapes with NIL. From aek at bitsavers.org Mon May 12 23:42:37 2025 From: aek at bitsavers.org (Al Kossow) Date: Mon, 12 May 2025 06:42:37 -0700 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <7wsela0x03.fsf@junk.nocrew.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> Message-ID: <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> On 5/12/25 6:38 AM, Lars Brinkhoff wrote: > Noel Chiappa writes: >> And I should ask Lars if the backup tapes of the DSSR/RTS machine went >> to the MIT archives - they might well have done, and Prof. Ward just >> didn't know that. > What was the name of the system(s)? A complication is MIT, being MIT, used their own backup tape format on some of their Unix systems. From tjteixeira at earthlink.net Tue May 13 00:52:11 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Mon, 12 May 2025 10:52:11 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> Message-ID: On 5/12/25 9:42 AM, Al Kossow wrote: > On 5/12/25 6:38 AM, Lars Brinkhoff wrote: >> Noel Chiappa writes: >>> And I should ask Lars if the backup tapes of the DSSR/RTS machine went >>> to the MIT archives - they might well have done, and Prof. Ward just >>> didn't know that. >> > > What was the name of the system(s)? > > A complication is MIT, being MIT, used their own backup tape format > on some of their Unix systems. > Delphi was the home-written time-sharing system for the PDP-11/45 I referred to. It would have had some home-written backup tape format. I'm not sure if it was backed up to tape, or just to duplicate RK05 packs. In addition to Steve Ward, Chris Terman may remember something about the Delphi system and backups. From arnold at skeeve.com Tue May 13 01:09:37 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 12 May 2025 09:09:37 -0600 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <7wsela0x03.fsf@junk.nocrew.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> Message-ID: <202505121509.54CF9bCx2302958@freefriends.org> Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes are in there? Arnold Lars Brinkhoff wrote: > Noel Chiappa writes: > > And I should ask Lars if the backup tapes of the DSSR/RTS machine went > > to the MIT archives - they might well have done, and Prof. Ward just > > didn't know that. > > They might. There are thousands of tapes, most of which are from ITS or > TOPS-20. But that still leaves room for hundreds of Unix tar, dump, and > cpio tapes in various interesting 16/32-bit and big/little endian > combinations. I'm guessing they are 4BSD, Sun, and maybe PDP-11 > formats. I haven't taken the time to go through them; in many cases > modern tools don't work, so I have to make my own. > > A propos Teixeira's message, there are also VMS tapes with NIL. From f4grx at f4grx.net Tue May 13 01:21:28 2025 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Mon, 12 May 2025 17:21:28 +0200 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> Message-ID: <4d76f0f5-5b57-4167-b514-6ff660c54adc@f4grx.net> Hello, On 12/05/2025 10:10, Thalia Archibald via TUHS wrote: > I just watched your talk. Now the B intermediate language makes a lot more sense > and I want to write a B compiler :). I did that, it was fun. I did a recursive descent parser (from scratch, so without yacc), and made it generate some C code. From a practical aspect, having tasted C for years, I find B quite annoying and pointless outside the gigantic historical interest. Sebastien From jnc at mercury.lcs.mit.edu Tue May 13 02:21:26 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 12:21:26 -0400 (EDT) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: <20250512162126.A078918C077@mercury.lcs.mit.edu> > From: Al Kossow > What was the name of the system(s)? >From an early 'hosts' file: HOST MIT-RTS, [CHAOS 470,LCS 10/11],SERVER,UNIX,PDP11,[RTS,DSSR] I'd rather depend on that, than on my memory! (The names at the end are aliases.) While I was looking for a really early host file (I recall our early TFTP command had one; I don't think it was built into the command, but it might have been),~p I found a /jnk directory in MIT-CSR's root; it had a lot of interesting stuff in it. One particularly interesting one was 'kov': The idea of this kernel overlay scheme is to increase the amount of code that can be included in the UNIX kernel. This is done by reserving one of the I space segmentation registers (the highest free, usually KISA5 for non-split systems) and changing its value dynamically so as to map in the appropriate code as needed. I chose to use only one page register (limiting each KOV to 4Kw), in order to minimize the mapping overhead. I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 (and later BSD's)? That stuff is all poorly documented, and I'm not up for poring through both to compare them. This one was all done by Ken Harrenstien (KLH). Noel From lars at nocrew.org Tue May 13 03:03:28 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 12 May 2025 17:03:28 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <202505121509.54CF9bCx2302958@freefriends.org> (arnold@skeeve.com's message of "Mon, 12 May 2025 09:09:37 -0600") References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> <202505121509.54CF9bCx2302958@freefriends.org> Message-ID: <7wmsbh223j.fsf@junk.nocrew.org> arnold at skeeve.com wrote: > Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes > are in there? Sorry, I really can't say. From tuhs at tuhs.org Tue May 13 04:36:55 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 May 2025 18:36:55 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: On Monday, May 12th, 2025 at 5:49 AM, Thalia Archibald via TUHS wrote: > On May 12, 2025, at 04:04, Noel wrote: > > > That's going to be a real trick; 'as' was written in PDP-11 assembler: > > > It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 > lines or 7/20 files in my translation of `as` to C. It seems that it was never > ported to C by the original authors, so this is probably the most closely > someone’s looked at many parts of it in a long time. > > I’ve very steadily been improving my PDP-11 assembly skills and rather efficient > now. It’s quite tedious tracking all the register effects, though good > signatures annotated with in- and out-registers helps a lot. I feel like a > compiler, manually performing control flow structuring like the Relooper or LLVM > Stackifier algorithms. With this completed, my manual effort will bootstrap > reverse engineering the rest with a proper decompiler. > > Thalia Not sure how helpful it'd be, but pdp11-dec-aout is a valid target for GNU binutils as of the current version, so objdump may be another disassembler/analyzer option. If it helps, here's some stalled-out work on disassembling V2 commands: https://gitlab.com/segaloco/v2src Do you have a particular end-goal in mind or is it just an exercise? - Matt G. From henry.r.bent at gmail.com Tue May 13 05:13:26 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 12 May 2025 15:13:26 -0400 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: On Mon, 12 May 2025 at 14:37, segaloco via TUHS wrote: > > Do you have a particular end-goal in mind or is it just an exercise? > > - Matt G. Learning from the past is wonderful. Reliving it is just cosplay. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Tue May 13 09:58:56 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 13 May 2025 01:58:56 +0200 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: Check v10's cmd/PDP11/11as source Cheers, aap On 12/05/25, Thalia Archibald via TUHS wrote: > On May 12, 2025, at 04:04, Noel wrote: > > That's going to be a real trick; 'as' was written in PDP-11 assembler: > > It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 > lines or 7/20 files in my translation of `as` to C. It seems that it was never > ported to C by the original authors, so this is probably the most closely > someone’s looked at many parts of it in a long time. > > I’ve very steadily been improving my PDP-11 assembly skills and rather efficient > now. It’s quite tedious tracking all the register effects, though good > signatures annotated with in- and out-registers helps a lot. I feel like a > compiler, manually performing control flow structuring like the Relooper or LLVM > Stackifier algorithms. With this completed, my manual effort will bootstrap > reverse engineering the rest with a proper decompiler. > > Thalia From tuhs at tuhs.org Tue May 13 19:46:00 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 13 May 2025 09:46:00 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: <0215662D-1A66-4823-8E4B-6144CFF4DDFE@archibald.dev> aap wrote: > Check v10's cmd/PDP11/11as source Thanks for the pointer! I've now surveyed all the distributions in the TUHS Unix Tree and that's indeed the most interesting one. The V10 PDP-11 `as` and Jay Jaeger's MXAS[0] port of Mini-Unix `as` to DOS are the only translations of PDP-11 `as` to C and they both look to be faithful translations, though I haven't reviewed them in depth yet. Do you know any more about the background of the V10 PDP-11 `as`? It's a cross-assembler on VAX and its Makefile indicates it was written by John F. Reiser. According to Wikipedia, he did much of the work for Unix/32V, including writing its VAX assembler ported from Interdata 8/32 Unix. Unfortunately, the Interdata 8/32 port is not in the TUHS tree (though the unrelated 7/32 port is). Thalia [0]: https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/mxas.tar.gz From clemc at ccc.com Wed May 14 07:02:58 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 May 2025 17:02:58 -0400 Subject: [TUHS] The Official Announcement WRT the USENIX Annual Technical Conference Message-ID: Casey Henderson-Ross is the ED of USENIX. Since the list would not accept her message, she asked me, as a former President, to send this to folks on the TUHS mailing list. ------------------------------- Folks, As you may already be aware, today we made an important announcement about the USENIX Annual Technical Conference via our mailing list. We want to share this news with you directly as well in case you do not currently receive USENIX email. Please read the statement in its entirety here: https://www.usenix.org/blog/usenix-atc-announcement If you don't know me, I've served on the USENIX staff since 2002 and have had the privilege of serving as Executive Director since 2012. USENIX and the Annual Technical Conference are both dear to me as I know they are to many of you. This is difficult news to share even as we're grateful to be celebrating 50 years of USENIX this year. I hope that you'll share your memories via the form mentioned in the statement and that we'll also see many of you at USENIX ATC '25 in Boston in July: https://www.usenix.org/conference/atc25 If you'd like to contribute to activities there, please contact me directly. Thanks to all of you for honoring the history of UNIX and for your support of USENIX and ATC (in its different names and forms) over the decades. Best, Casey Henderson-Ross ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed May 14 07:58:07 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 May 2025 17:58:07 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512162126.A078918C077@mercury.lcs.mit.edu> References: <20250512162126.A078918C077@mercury.lcs.mit.edu> Message-ID: On Mon, May 12, 2025 at 12:21 PM Noel Chiappa wrote: > > I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 > (and > later BSD's)? > Unlikely. The BSD overlay stuff was based on Fred Cantor work at DEC in the TIG group in Merrimack, NH that did V7m and later Ultrix11. Fred's code works on 11/40 as well as 11/45 class processors, where as by the time of 2.11BSD they dropped the 11/40 support. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed May 14 09:05:17 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 May 2025 09:05:17 +1000 (EST) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512162126.A078918C077@mercury.lcs.mit.edu> References: <20250512162126.A078918C077@mercury.lcs.mit.edu> Message-ID: On Mon, 12 May 2025, Noel Chiappa wrote: > I found a /jnk directory in MIT-CSR's root; it had a lot of interesting > stuff in it. One particularly interesting one was 'kov': > > The idea of this kernel overlay scheme is to increase the amount of > code that can be included in the UNIX kernel. This is done by reserving > one of the I space segmentation registers (the highest free, usually > KISA5 for non-split systems) and changing its value dynamically so as > to map in the appropriate code as needed. I chose to use only one page > register (limiting each KOV to 4Kw), in order to minimize the mapping > overhead. Hammering KISA5 on 40-class machines seemed to have been a common trick in those days. For example, the AUSAM buffering scheme at UNSW had a global kernel symbol "b" (analogous to "u") sitting at 100000 (?) that pointed to the current buffer header; you could have as many buffers as physical memory allowed, ending the dreaded buffer-hang problem. -- Dave From tytso at mit.edu Wed May 14 23:33:36 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 14 May 2025 09:33:36 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250507025526.GC17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> Message-ID: <20250514133336.GD9943@mit.edu> On Tue, May 06, 2025 at 07:55:26PM -0700, Larry McVoy wrote: > > I might regret this in the morning but I'd like to share when Usenix > ceased to matter to me. I was the program committee chair for the 1999 > Linux Expo which was a Usenix alternative... > > In 1999 when I was going to that conference, Ellie reached out to me > and begged me to bring Linux to Usenix. She said I could have whatever > I wanted, on the program committee for life, whatever I wanted. > > I asked for blind peer reviews. She said no. I recently came across Bryan Cantrill's relections on the end of Usenix ATC[1], which is well worth the read. It references a number of also musings[2][3][4][5] that are also (in my opinion) very thoughtful, and shows that the tension between practical industry work and academic work is a very old one. [1] https://bcantrill.dtrace.org/2025/05/11/rip-usenix-atc/ [2] https://bcantrill.dtrace.org/2004/07/06/whither-usenix/ [3] https://web.archive.org/web/20081006150917/https://www.allthingsdistributed.com/historical/archives/000482.html [4] https://bcantrill.dtrace.org/2004/07/08/whither-usenix-part-ii/ [5] https://www.usenix.org/system/files/login/articles/login_fall16_01_farrow.pdf One of the interesting observations in [2] was that the program committee for the 2005 Freenix / Open Source program committee was solely from industry, and since I was one of the folks who participated in Freenix Program Committees (although I wasn't on the 2005 Freenix PC), and Bryan's concern that it would be the "dumping ground" for subpar work that wouldn't be accepted at the "big boys table". It's a lot more than that, though. I was at IBM at that time, and at IBM, right about then the bonus for getting for getting published at a conference had gotten eliminated. It was very clear that as far as IBM management was concerned, conference publication didn't matter. If you filed a patent, you would get paid a cash bonus. If you submit to any conference --- you wouldn't. On top of that, writing a good paper that would be accepted at conference where you are competing with academics working full-time trying to get tenure, is a lot of hard work and takes a lot of time. So speaking as a working engineer, you'd have to be especially passionate about writing a paper (perhaps because you came from the academic background), to think it was worth it. Open source made this worse, because if you're not going to get paid by your employer, and won't be given work time to work on a paper, if you're going to have to contribute on your own time, the question then becomes, which is better for your future employability? Publishing a paper, or contributing to an open source project, and then becoming a major contributor to an open source project? Finally, what industry conferences run by organizations like the Linux Foundation optimized for the value that most industry players cared about, which is the "hallway track". And that's ultimately what doomed Freenix. Freenix still tried to make people write papers, in the hopes that they could hone their paper-writing skills so they could eventually "graduate" to Usenix. But engineers didn't care about writing papers, and if you could just submit a talk proposal to the Linux Plumbers Conference, which do you think they would choose? If the main reason why you attend, and why your manager would approve your travel expenses, is because you can get face time for the people who will approve your open source contributions (which is what the managers care about), the choice between Freenix and the Ottowa Linux Symposium or Linux Plumbers wasn't even close. All of that being said, it is sad that Usenix ATC is ending. I will admit; I haven't attended in many years, mostly because of time and travel expense constraints. And from a personal perspective, last year, I spent some of my own money (with hotel costs generously covered by the Linux Foundation) to travel and present[6] at the Linux Foundation Members Summit. But could I say that I would spend my own money to attend a Usenix conference? Well, I never have, so probably not. :-/ [6] https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6ZxEAehCpQ/edit#slide=id.p - Ted P.S. Admittedly, the presentation at the LF Members Summit wasn't a technical topic, and the whole point was for me to make a point to executives at companies which use Open Source. From lm at mcvoy.com Thu May 15 00:54:52 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 14 May 2025 07:54:52 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514133336.GD9943@mit.edu> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> Message-ID: <20250514145452.GE17185@mcvoy.com> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: > It's a lot more than that, though. I was at IBM at that time, and at > IBM, right about then the bonus for getting for getting published at a > conference had gotten eliminated. It was very clear that as far as > IBM management was concerned, conference publication didn't matter. > If you filed a patent, you would get paid a cash bonus. If you submit > to any conference --- you wouldn't. That's wild. To the best of my knowledge, Sun didn't give you a bonus for either a paper or a patent, it was just part of the job. I certainly never got a bonus for that stuff. They did pay expenses for conferences but that was it. I personally viewed publishing as part of my resume. I didn't publish very often but when I did, I had something to say. I put a lot of hard work into each paper, I knew if my brain felt sort of constipated but I was still making the words come out, yeah, that was likely to be a good paper. I'd much rather you formed an opinion of my from my papers than my resume. The papers were hard, but that made them more significant than a listing of whatever projects I had worked on. If I were writing papers for a bonus, I dunno, seems like it cheapens the whole idea. I may have a different outlook as my family was pretty academic, Dad was a Rhodes scholar and went to get a physics PhD from Cornell, my brother got a PhD from Cornell, I was the black sheep of the family with a lowly Masters from UW Madison. I had PhD envy and part of the reason I published was to let people know I had something to say. Everyone is different I guess. --lm From sauer at technologists.com Thu May 15 01:21:07 2025 From: sauer at technologists.com (Charles H. Sauer (he/him)) Date: Wed, 14 May 2025 10:21:07 -0500 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <5cca37cf-4790-4a6a-87dc-274c6756939e@technologists.com> On 5/14/2025 9:54 AM, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I certainly > never got a bonus for that stuff. They did pay expenses for conferences > but that was it. IBM did not give bonuses for publishing when I was there (1975-1989), so if that stopped in 2005, it sounds like an aspect of the Gerstner era. IBM when I was there strongly encouraged/rewarded patents, and formally disclosing lesser innovations. There were also significant cash awards for "Outstanding Innovations/Inventions," and annual corporate recognition events celebrating those. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Thu May 15 05:16:04 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 14 May 2025 12:16:04 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> On 5/14/25 07:54, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I started at Sun after you left, and don't know when they started but patent bonuses were common in the 2000's at Sun. They paid up to $2000/person, with a max of $6000/team, when a patent was filed. (Based on a 2004 slide deck encouraging us to file more patents, I never got one to verify. They did emphasize they wanted patents for defensive reasons, including cross-licensing deals, not to attack other companies.) -alan- From pete at debu.gs Thu May 15 11:03:41 2025 From: pete at debu.gs (Pete) Date: Wed, 14 May 2025 18:03:41 -0700 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: <20250508101434.3431818C084@mercury.lcs.mit.edu> References: <20250508101434.3431818C084@mercury.lcs.mit.edu> Message-ID: <68253D6D.3040602@debu.gs> On 2025年05月08日 03:14, Noel Chiappa wrote: > I'm not up for looking through TUHS archives for it. What I did when I subscribed (thanks, wkt) was download the archives (which are in mbox format), cat them, and then copy the messages to the directory where the TUHS messages are filtered. Took almost no time, but my mail server is in my house. This makes it pretty easy to search the archives locally: you can just use grep or if you have a mail reader with good search features, it's much easier than searching on the server. It looks like there was "A Census of /etc and /sys Prior to V4" on 2023-05-15, and "Census of Early (Pre-C Kernel) UNIX Documents" on 2024-02-14, both from segaloco. (The only downside to importing the mboxes is that the email addresses are tweaked to prevent spam.) That should make it easier to find the threads. Pete From tytso at mit.edu Thu May 15 23:57:06 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 15 May 2025 09:57:06 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> Message-ID: <20250515135706.GA325737@mit.edu> On Wed, May 14, 2025 at 12:16:04PM -0700, Alan Coopersmith wrote: > I started at Sun after you left, and don't know when they started but > patent bonuses were common in the 2000's at Sun. They paid up to > $2000/person, with a max of $6000/team, when a patent was filed. > (Based on a 2004 slide deck encouraging us to file more patents, > I never got one to verify. They did emphasize they wanted patents for > defensive reasons, including cross-licensing deals, not to attack other > companies.) What I was at IBM, they paid $500/engineer, with a max of $2000/team for a patent being filed, with another $500/engineer if the patent was granted. It was quite common for IBM'ers to set up patent brainstorming teams of 4 people each (to max out the team limit), and the patents did't have to be related to what your department was working on. You could be in the IBM Linux Technology Center, and if you had an idea for something that might be novel in virtual reality, or massive multiplayer online games, or ways that AI could be applied in a health care context, it was all fair game. A particular patent team could be potentially responsible for dozens of patent filings, so it could be real money, especially if you were a relatively underpaid level 5 SWE. (Yeah, it wasn't as a big of a deal if you were a band 10 STSM.) It wasn't formally organized by management, but the fact that these teams exited and the resulting patents were of relatively low quality (in my humble opinion), this couldn't have come as a surprise to them. (From a defensive perspective, quantity was far more important than quality, after all. The patent system is so totaly screwed up....) But as far as papers were concerned, an accepted paper at ATC was worth (at best) brownie points at performance review time, at least in my part of the company. Combine that with the extreme difficulty in getting travel expense approval, it's pretty clear what management really thought about publishing being part of the job. Creating presentations for VP's, or spending all day in Fall Plan meetings justifying budget line items down to the SWE-month granularity? (And then after those plans become totally obsolete once the budget was handed down from on high, then there was Spring Re-plan....) Sure that was definitely part of the job. Publishing papers? Not so much. - Ted From stuff at riddermarkfarm.ca Fri May 16 07:00:28 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 15 May 2025 17:00:28 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> On 2025-05-14 10:54, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I certainly > never got a bonus for that stuff. They did pay expenses for conferences > but that was it. We may be drifting off topic but my last employer paid $50 per application filed plus $100 per grant. My penultimate employer paid a lousy $1 (minimal required consideration). S. From tuhs at tuhs.org Fri May 16 07:33:36 2025 From: tuhs at tuhs.org (Rod Bartlett via TUHS) Date: Thu, 15 May 2025 17:33:36 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> Message-ID: <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> U.S. Robotics had the best bonuses for filing patents of any company I've worked for. I think it was $1000 if they decided to file the patent application and another $1000 when it was granted. I also got an all expenses paid trip to Barcelona in 1999 for having filed 2 patents that year. Other companies were not nearly as generous. - Rod > On May 15, 2025, at 5:00 PM, Stuff Received wrote: > > On 2025-05-14 10:54, Larry McVoy wrote: >> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >>> It's a lot more than that, though. I was at IBM at that time, and at >>> IBM, right about then the bonus for getting for getting published at a >>> conference had gotten eliminated. It was very clear that as far as >>> IBM management was concerned, conference publication didn't matter. >>> If you filed a patent, you would get paid a cash bonus. If you submit >>> to any conference --- you wouldn't. >> That's wild. To the best of my knowledge, Sun didn't give you a bonus >> for either a paper or a patent, it was just part of the job. I certainly >> never got a bonus for that stuff. They did pay expenses for conferences >> but that was it. > > We may be drifting off topic but my last employer paid $50 per application filed plus $100 per grant. My penultimate employer paid a lousy $1 (minimal required consideration). > > S. > From robpike at gmail.com Fri May 16 08:54:31 2025 From: robpike at gmail.com (Rob Pike) Date: Fri, 16 May 2025 08:54:31 +1000 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> Message-ID: At Bell Labs there was a rumor you got a symbolic dollar when a patent was filed, but it was only a rumor. Nonetheless I mentioned this to PJW who then reached in his wallet and handed me a greenback. Props. -rob On Fri, May 16, 2025 at 7:34 AM Rod Bartlett via TUHS wrote: > U.S. Robotics had the best bonuses for filing patents of any company I've > worked for. I think it was $1000 if they decided to file the patent > application and another $1000 when it was granted. I also got an all > expenses paid trip to Barcelona in 1999 for having filed 2 patents that > year. Other companies were not nearly as generous. > > - Rod > > > On May 15, 2025, at 5:00 PM, Stuff Received > wrote: > > > > On 2025-05-14 10:54, Larry McVoy wrote: > >> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: > >>> It's a lot more than that, though. I was at IBM at that time, and at > >>> IBM, right about then the bonus for getting for getting published at a > >>> conference had gotten eliminated. It was very clear that as far as > >>> IBM management was concerned, conference publication didn't matter. > >>> If you filed a patent, you would get paid a cash bonus. If you submit > >>> to any conference --- you wouldn't. > >> That's wild. To the best of my knowledge, Sun didn't give you a bonus > >> for either a paper or a patent, it was just part of the job. I > certainly > >> never got a bonus for that stuff. They did pay expenses for conferences > >> but that was it. > > > > We may be drifting off topic but my last employer paid $50 per > application filed plus $100 per grant. My penultimate employer paid a > lousy $1 (minimal required consideration). > > > > S. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat May 17 02:01:39 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 May 2025 16:01:39 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? Message-ID: I'm curious if anyone has the scoop on this. To my knowledge the 1984 /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX standard. AT&T then comes along in 1985 with the first issue of the SVID, based largely on SVR2 from what I know. What I'm not getting a good read on or not is if the SVID was literally a direct response from AT&T to the creation of the /usr/group standard or if there was already an impetus in AT&T's sphere of influence to produce such a definitive document. In either case, AT&T does list the /usr/group standard as an influence, but doesn't go into the detail of "we made this because /usr/group's standard exists" or "we made this ourselves and oh /usr/group also happens to have a standard." Even outside of this, did AT&T maintain anything comparable to the SVID in prior years or was the manual essentially the interface definition? Thanks for any recollections! - Matt G. From clemc at ccc.com Sat May 17 03:57:27 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 May 2025 13:57:27 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: below. On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS wrote: > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor-neutral > UNIX > standard. AT&T then comes along in 1985 with the first issue of the SVID, > based > largely on SVR2 from what I know. > > There was a huge marketing campaign, "*System V. Consider it Standard*." But the >>users<<, particularly those weaned on BSD, said "hardly." /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much less, Sys III/V. SVID came later, and it was an attempt to force it down people's throats. The AT&T folks were sometimes a tad nasty at the POSIX meeting and wanted IEEE to "just use it," and we say, "no. It's incomplete and just plain wrong is so many places." The whole tar/cpio stuff from /usr/group was a great example of the start of it, but even things like trying to define a directory entry was strained. SVID did not have the new UCB directory system calls. For example, we all were certain that if we ever had a different FS, we needed to remove physical formats from the specification. There were no sockets, and yet nearly 100% of the working networking code in the wild, including on MS-DOS, was using sockets. The problem was that several people who came to the POSIX meetings post-SVID from AT&T were from marketing and sales. At the same time, the core of the original /usr/group and later POSIX teams were mostly engineering types. The sales/mktg folks were trying to establish a brand, the engineers were trying to solve an issue were we had code that did not work between our different systems. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Sat May 17 04:16:35 2025 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 16 May 2025 11:16:35 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <1bf9b965-8ec6-43f5-bb16-29c93aafbc3e@osta.com> As the Chair of the /usr/group Standards Committee from its start in 1981 to 1984, I can say that we got all of the major manufacturers of computer hardware running the UNIX operating system involved in this standards effort. This included AT&T, IBM, DEC, HP, Sun, Intel, and many smaller mini-computer and micro-computer hardware vendors. The /usr/group Standard was the starting point for the POSIX 1003.1 standard developed by the IEEE standards organization and first published in 1988.  AT&T was very involved in the development of both standards and would have made every effort to make their operating system to be compatible with the UNIX standards as they were developed over the following years. Details would have to come from AT&T. Heinz On 5/16/2025 9:01 AM, segaloco via TUHS wrote: > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX > standard. AT&T then comes along in 1985 with the first issue of the SVID, based > largely on SVR2 from what I know. > > What I'm not getting a good read on or not is if the SVID was literally a direct > response from AT&T to the creation of the /usr/group standard or if there was > already an impetus in AT&T's sphere of influence to produce such a definitive > document. In either case, AT&T does list the /usr/group standard as an > influence, but doesn't go into the detail of "we made this because /usr/group's > standard exists" or "we made this ourselves and oh /usr/group also happens to > have a standard." > > Even outside of this, did AT&T maintain anything comparable to the SVID in prior > years or was the manual essentially the interface definition? > > Thanks for any recollections! > > - Matt G. From sauer at technologists.com Sat May 17 04:18:43 2025 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 16 May 2025 13:18:43 -0500 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <7637a718-a20b-4016-b46d-b36462c558e2@technologists.com> further below On 5/16/2025 12:57 PM, Clem Cole wrote: > below. > > On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS > wrote: > > I'm curious if anyone has the scoop on this.  To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor- > neutral UNIX > standard.  AT&T then comes along in 1985 with the first issue of the > SVID, based > largely on SVR2 from what I know. > > There was a huge marketing campaign, "_/System V. Consider it Standard/ > _." But the >>users<<, particularly those weaned on BSD, said "hardly." > /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much > less, Sys III/V.  SVID came later, and it was an attempt to force it > down people's throats. > The AT&T folks were sometimes a tad nasty at the POSIX meeting and > wanted IEEE to "just use it," and we say, "no.  It's incomplete and just > plain wrong is so many places."    The whole tar/cpio stuff from /usr/ > group was a great example of the start of it, but even things like > trying to define a directory entry was strained.   SVID did not have the > new UCB directory system calls. For example, we all were certain that if > we ever had a different FS, we needed to remove physical formats from > the specification.   There were no sockets, and yet nearly 100% of the > working networking code in the wild, including on MS-DOS, was using > sockets. > > The problem was that several people who came to the POSIX meetings post- > SVID from AT&T were from marketing and sales. At the same time, the > core of the original /usr/group and later POSIX teams were mostly > engineering types.   The sales/mktg folks were trying to establish a > brand, the engineers were trying to solve an issue were we had code that > did not work between our different systems. "Convergence of AIX and 4.3BSD" (https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf) was another alternative to SVID that was intended to address a spectrum of requirements. It was gratifying that AIX people, IBM BSD people and Bruce Walker of LCC were able to reach consensus and put our names on that paper. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Sat May 17 04:22:23 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 May 2025 18:22:23 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: On Friday, May 16th, 2025 at 10:58 AM, Clem Cole wrote: > below. > > On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS wrote: > > > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > > /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX > > standard. AT&T then comes along in 1985 with the first issue of the SVID, based > > largely on SVR2 from what I know. > > There was a huge marketing campaign, "System V. Consider it Standard." But the >>users<<, particularly those weaned on BSD, said "hardly." > /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much less, Sys III/V. SVID came later, and it was an attempt to force it down people's throats. > The AT&T folks were sometimes a tad nasty at the POSIX meeting and wanted IEEE to "just use it," and we say, "no. It's incomplete and just plain wrong is so many places." The whole tar/cpio stuff from /usr/group was a great example of the start of it, but even things like trying to define a directory entry was strained. SVID did not have the new UCB directory system calls. For example, we all were certain that if we ever had a different FS, we needed to remove physical formats from the specification. There were no sockets, and yet nearly 100% of the working networking code in the wild, including on MS-DOS, was using sockets. > > > The problem was that several people who came to the POSIX meetings post-SVID from AT&T were from marketing and sales. At the same time, the core of the original /usr/group and later POSIX teams were mostly engineering types. The sales/mktg folks were trying to establish a brand, the engineers were trying to solve an issue were we had code that did not work between our different systems. > ᐧ Insightful as always Clem, thanks for the background. To me that sounds more like AT&T seeing the horse escaping the barn and trying to ensure they're a relevant part of the conversation, more for the sake of marketing their system and cornering things rather than a good faith attempt to improve and extend the ideas being set forth by the /usr/group effort. Not to discount the good intentions of plenty of folks involved, but that certainly sounds more like a case of "shoot, we should be the arbiter of this information" for the sake of their bottom line. My interpretation anyway. Aside but I recently landed a copy of SVID Issue 1, previously I only had Issue 3 (SVR4 era blue books, 5 volumes) and had seen auctions for Issue 2 that I didn't act on. Issue 1 is published in a nice hard cover, has a more minimalist perspective pattern on the cover than Issue 2 and is only one volume covering the C interface while mentioning future extension efforts such as basic utilities and the like. - Matt G. P.S. While on the subject of SVID, just throwing out there that I have seen auctions for a "Volume VI" in the Issue 3 era. No such volume is referenced in any of the others and the one auction I jumped on never arrived. When pressed on it the seller simply gave me a refund. This has all amounted to doubt that such a volume actually exists, but I've seen at least one grainy photo (because book sellers can't be bothered to show adequate pictures of the books they're selling but expect $$$ anyway) that appeared to show a cover saying "Volume VI" but in typical book seller fashion, it was far too grainy and low resolution to make out any details. In any case, I share this in the hopes someone might be familiar with what I'm talking about and can confirm/deny the existence of a 6th volume in this set. From mrochkind at gmail.com Sat May 17 05:01:27 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 16 May 2025 13:01:27 -0600 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: I was only slightly connected with the development of the POSIX standard, and as has been mentioned here, AT&T was a full participant. The real conflicts were in a related area and at the time were termed The GUI Wars. Basically, it was AT&T and Sun pushing OpenLook and everyone else pushing Motif. I seem to recall that the Motif folks (Open Software Foundation) more or less forced IEEE to just accept Motif as a standard. I was on a different committee that was trying to standardize a universal GUI interface that could work on any GUI, including Mac, Windows, Motif, and OpenLook. My product, XVT, was the base document. We never got past the draft stage. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat May 17 07:45:04 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 May 2025 17:45:04 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: Marc, you are right, but the OpenLook/Motif stuff was >>much<< later. Matt asked about the SVID thing about 5-6 years before that. The problem AT&T had was >>before<< Judge Green, they could not be in the computer biz, so they "*abandoned the sources on your doorstep, with no warranty of any kind.*" It was simply thatAT&T was not allowed to be in the computer business* by law*. Post Judge Green boy did AT&T's management >>want<< to be in the computer biz, and they* tried to use tactics *that had often worked for the largest computer firm to date. In fact, the firm that Charlie Brown [the AT&T CEO] was quoted as saying, he wanted to compete with and emulate IBM. If I recall correctly, he said something about matching them move for move. UNIX had been AT&T's baby, and AT&T wanted it back, but by then, the child had grown up and did not want or need its parent anymore. A lot of the failed actions post Judge Green are part of AT&T searching for a grip in a business its management team did not understand, nor was prepared to be a part of. The assumption was that before the breakup, they were the world's largest company, and even after, the new AT&T was still larger in assets than IBM, so they could compete. History proved otherwise. If they had used different tactics, with the assets AT&T had in its quiver, they might have been able to be a real force. But I think pride made them think that the 3B20 was going to be able to compete with a Mainframe (or even a Vax) — mind you, their own people wanted Vaxen or later Suns. AT&T Management seem to think that UNIX was the key, but AT&T had to be in charge of it. The funny thing, is if AT&T management had taken a zen approach and bolstered what everyone else was doing instead of trying to drive everyone else away [Microsoft's famous "embrace and extend model"], and not tried compete in the processor wars, but instead take on second source licenses and start using their boundary; I something wonder if it might have had a very different out come. They still would have needed to see the PC revolution coming, which I'm not sure management types used to 40-50% gross margin will ever under as 12-15% margin PC market (volume is everything) market. ᐧ On Fri, May 16, 2025 at 3:01 PM Marc Rochkind wrote: > I was only slightly connected with the development of the POSIX standard, > and as has been mentioned here, AT&T was a full participant. > > The real conflicts were in a related area and at the time were termed The > GUI Wars. Basically, it was AT&T and Sun pushing OpenLook and everyone else > pushing Motif. I seem to recall that the Motif folks (Open Software > Foundation) more or less forced IEEE to just accept Motif as a standard. > > I was on a different committee that was trying to standardize a universal > GUI interface that could work on any GUI, including Mac, Windows, Motif, > and OpenLook. My product, XVT, was the base document. We never got past the > draft stage. > > Marc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat May 17 08:19:22 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 16 May 2025 18:19:22 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sat May 17 08:24:27 2025 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Fri, 16 May 2025 15:24:27 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <67697ba8683df795@orthanc.ca> I think AT&T's real problem was that the post-1984 UNIX business was run by the lawyers. If you look at it, nearly every UNIX-related fuckup on AT&T's part can be directly traced back to the lawyers. If they had only listened to Shakespeare. --lyndon From mrochkind at gmail.com Sat May 17 08:51:08 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 16 May 2025 16:51:08 -0600 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: <67697ba8683df795@orthanc.ca> References: <67697ba8683df795@orthanc.ca> Message-ID: On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyndon at orthanc.ca> wrote: > I think AT&T's real problem was that the post-1984 UNIX business > was run by the lawyers. If you look at it, nearly every UNIX-related > fuckup on AT&T's part can be directly traced back to the lawyers. > > If they had only listened to Shakespeare. > > --lyndon > Hey, you forgot the TM on UNIX! -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Sat May 17 09:33:08 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 16 May 2025 16:33:08 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: <67697ba8683df795@orthanc.ca> Message-ID: <4d568b48-c5d0-5e14-a187-3e19c30e425b@makerlisp.com> Well, this is almost the same thing, but I think of it more as trying to make money off of Unix. We lost the spirit of what made UNIX great when it became about having the standard, dominant, market leading, version, and all that nonsense. We might say first, get rid of all the marketers. On 05/16/2025 03:51 PM, Marc Rochkind wrote: > On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > > wrote: > > I think AT&T's real problem was that the post-1984 UNIX business > was run by the lawyers. If you look at it, nearly every UNIX-related > fuckup on AT&T's part can be directly traced back to the lawyers. > > If they had only listened to Shakespeare. > > --lyndon > > > Hey, you forgot the TM on UNIX! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat May 17 12:03:32 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 17 May 2025 02:03:32 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: <67697ba8683df795@orthanc.ca> Message-ID: <63itFju7o4rStRY1LjVZOnFVnEikLYjSOi-IZHLG3yZPdPaHbSupN2c7QUrXC7sX8XwwIrErBgJau3ijSu0wOnAocCfSLYjKwgZtQ5IJzEU=@protonmail.com> On Friday, May 16th, 2025 at 3:51 PM, Marc Rochkind wrote: > On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > I think AT&T's real problem was that the post-1984 UNIX business > > was run by the lawyers. If you look at it, nearly every UNIX-related > > fuckup on AT&T's part can be directly traced back to the lawyers. > > > > If they had only listened to Shakespeare. > > > > --lyndon > > > Hey, you forgot the TM on UNIX! Is it really UNIX* discussion without *UNIX is a trademark of Bell Laboratories. at the bottom of every third page? - Matt G. From jnc at mercury.lcs.mit.edu Sat May 17 20:59:41 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 17 May 2025 06:59:41 -0400 (EDT) Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? Message-ID: <20250517105941.AA5B718C07A@mercury.lcs.mit.edu> > From: Lyndon Nerenberg > I think AT&T's real problem was that the post-1984 UNIX business was > run by the lawyers. This is a common problem in many companies: executives who do not have deep knowledge of the company's fundamental business, but rather in some support area, rise to the top of the business, and proceeed to make bad decisions about that business (through lack of deep understanding of the business' fundamentals). The exact same problem arises not just with support functions, but also with the belief in 'pure managers'. The biggest recent example of this problem in Boeing; the people running a business that is fundamentally an engineering business made some bad decisions in areas that were fundamentally engineering. Car companies have displayed this disorder too. Which is not to say that such people _can't_ be effective leaders of such organizations; the classic example is James Webb, who 'ran' NASA from 1961 to 1968; he was originally a lawyer. I say 'ran' NASA because Webb was smart enough to understand the limits of his expertise, and he delegated all the technical decisions to his chief deputy, Hugh Dryden - who had started his career as an aeronautical scientist (a Ph.D in physics and mathematics). Noel From paul.winalski at gmail.com Sun May 18 00:58:54 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 17 May 2025 10:58:54 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: On Fri, May 16, 2025 at 6:26 PM Ron Natalie wrote: > Sort of like when DEC finally recognized that people were buying their > hardware to run UNIX. Still remember Armando getting up and saying > something to the effect that DEC hardware and UNIX had been synonymous for > years and that DEC finally noticed and the held up the first DEC UNIX > license (plate). > > Clem Cole had--and still has--the Massachusetts UNIX license plate on his car. I don't know when he first got that plate. Armando had the New Hampshire UNIX license plate. It was on a snazzy red Datsun 280 ZX. At the time (early 1980s) I was driving a frumpy rust-bucket Datsun B210. I had the New Hampshire VAXVMS license plate. Armando jokingly threatened to park his sports car next to my car and take a picture of the two OS license plates side-by-side. AT&T's "consider it a standard" campaign was pretty successful in getting corporate executive types thinking about UNIX. Sort of along the lines of the "Intel Inside" campaign, which actually got ordinary folks to care about whose chip was in their PC. But AT&T never was able to take advantage of the opening the "consider it a standard" campaign provided. In addition to the reasons Clem cited, I think AT&T simply never learned how to compete in an open market. They had been a regulated utility monopoly for so very long. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: