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?