From jnc at mercury.lcs.mit.edu Thu May 1 00:06:37 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Apr 2025 10:06:37 -0400 (EDT) Subject: [TUHS] Any Interdata war stories? Message-ID: <20250430140637.C00DA18C074@mercury.lcs.mit.edu> > From: Arnold Robbins > CCI made the Tahoe that 4.4 ran on, but I'm guessing it's a different > architecture than the Interdata? I think so. Almost all documentation on the Tahoe has been lost in the mists of time (if ANYONE retains ANY hardcopies of ANY hardware documentation for the Tahoe, PLEASE let me know), but I recently managed to work out a bit about it from the instruction decoding/printing routines in the debuggers from 4.3 BSD Tahoe: https://gunkies.org/wiki/Power_6/32 and it seems to be fairly different from the Interdata: http://bitsavers.org/pdf/interdata/32bit/29-365R01_32BitRefMan_Jun74.pdf Also, 'CCI' is 'Computer Consoles Incorporated', not "Concurrent Computer Corp". Noel From jsg at jsg.id.au Thu May 1 00:07:41 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 1 May 2025 00:07:41 +1000 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > From: Clem Cole > > > Yes, that was one of the RTS compilers for the NU machine. John Romkey > > may have done it, as he was the primary person behind PCIP > > I decided to poke around in the 'MIT-CSR' dump, since that was the machine > the PC/IP project started on, to see what I could find. Hoo boy! What an > adventure! > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. It > did have a shell file, 'grab', which contained: > > tftp -g $1 xx "PS:$1" > > and a 'graball' file which called 'grab' for the list of compiler source > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > So I did a Web search for Wayne Gramlich (with whom I hadn't communicated in > many decades), and he popped right up. (Amazing thing, this Internet thingy. > Who'd have ever thought, back in the day, that it would turn into what it > did? Well, probably John Brunner, whom I (sadly) never met, who was there > before any of us.) > > I took a chance, and called his number, and he was there, and we had a long > chat. He absolutely didn't do it, although he wrote the loader the project > used ('l68', the source for which I did find.) He's virtually certain Romkey > didn't (which would have been my guess too; Romkey was like a sophmore when > the project started). His best (_very_ faded) memory was that they started off > with a commercial compiler. (But see below.) > > That leaves several mysteries. 1) Why would a commercial compiler not come > with a linker? 2) Why did people who wanted to work with the PC/IP source > need a Bell license? > > > I did some more poking, and the list of files for the 86 compiler, from > 'graball': > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > table.c reader.c local2.c order.c match.c allo.c comm1.c > manifest mfile1 common macdefs mfile2 mac2defs > > matched the file names from 'pcc', as given in "A Tour Through the Portable C > Compiler": > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > (in section "The Source Files"). So whether the 86 compiler was done at MIT > (by someone in RTS), or at a company, it was definitely a 'pcc' descendant. > > (Possibly adding to the confusion, we had some other C compilers for various > ISA's in that project [building networking software for various > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, which I > have also found. It's possible that Wayne's vague memory of a commercial > compiler is of that one?) > > I really should reach out to Romkey and Bridgham, to see what they remember. > Later today. > > Whether the main motivation for keeping the compiler source on XX was i) > because disk space was short on CSR (we had only a hand-me-down pair of > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > version skew; or iii) because it was a commercial compiler, and we had to > protect the source (e.g. we didn't have the source to the 8080 compiler, only > the object modules), I have no idea. > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the 68K, > > Z8000 and 8086. I believe that each had separate assemblers, tjt who > > sometimes reads this list might know more, as he wrote the 68K assembler. > > There is an 'a86' directory on CSR, but it too is empty, except for a 'grab' > command file. That contains only: > > tftp -g $1 xx "PS:$1" > > I have no memory of who 'novick' might have been. A Web search for 'novick > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > Novitsky; she was in our group at LCS, and I have a vague memory of her being > associated with the networking software for micro-computers project.) > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, but he > didn't write c86; 'novick' might not have written a86. > > Something else to ask Romkey and Bridgham about. > > Noel "a version of the portable C Compiler that was modified by Chris Terman to produce code for an 8086 microprocessor was ported from the RTS VAX/780 to the CSR PDP-11/45." https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf "If you think that you need the source code, you should realize that a prerequisite to compiling the PC/IP programs is that you must have imported Chris Terman's 8086 version of the UNIX Portable C compiler and associated loader and assember systems. That importation in turn requires a UNIX system, a current UNIX license, and negotiation with Chris Terman." https://web.mit.edu/saltzer/www/publications/pcmemo.pdf From woods at robohack.ca Thu May 1 07:17:46 2025 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 30 Apr 2025 14:17:46 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: At Tue, 29 Apr 2025 00:55:05 -0600, arnold at skeeve.com wrote: Subject: [TUHS] Any Interdata war stories? > > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; In about 1981 or 1982 the chemistry (IIRC) department at University of Calgary had an Interdata 8/32 that was, at least for some time around then, running Unix. I remember poking around on it briefly, but I don't remember much more than that about it. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms From clemc at ccc.com Thu May 1 12:36:01 2025 From: clemc at ccc.com (Clem Cole) Date: Wed, 30 Apr 2025 22:36:01 -0400 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: So did Chris compiler go back to the Nu project? And thank you to Al for the Trix sources. As I said. It was national 16032 not z8000. FYI I had the whitesmith compiler at one point also. It generated code for a funky assembler called “anat” for “a natural assembler” which PJ conjured up for writing the compiler. It was was sort of a mix between an IL and 8080 assembler if my memory is correct. I’d love to see that distribution both the doc and the compiler again to May with on SIMH. I suspect I might appreciate it more than I did in those days. I hated it then but as I learned more about compilers and architectures PJ might have been on to something. Sent from a handheld expect more typos than usual On Wed, Apr 30, 2025 at 10:07 AM Jonathan Gray wrote: > On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > > From: Clem Cole > > > > > Yes, that was one of the RTS compilers for the NU machine. John > Romkey > > > may have done it, as he was the primary person behind PCIP > > > > I decided to poke around in the 'MIT-CSR' dump, since that was the > machine > > the PC/IP project started on, to see what I could find. Hoo boy! What an > > adventure! > > > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. > It > > did have a shell file, 'grab', which contained: > > > > tftp -g $1 xx "PS:$1" > > > > and a 'graball' file which called 'grab' for the list of compiler source > > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > > > So I did a Web search for Wayne Gramlich (with whom I hadn't > communicated in > > many decades), and he popped right up. (Amazing thing, this Internet > thingy. > > Who'd have ever thought, back in the day, that it would turn into what it > > did? Well, probably John Brunner, whom I (sadly) never met, who was there > > before any of us.) > > > > I took a chance, and called his number, and he was there, and we had a > long > > chat. He absolutely didn't do it, although he wrote the loader the > project > > used ('l68', the source for which I did find.) He's virtually certain > Romkey > > didn't (which would have been my guess too; Romkey was like a sophmore > when > > the project started). His best (_very_ faded) memory was that they > started off > > with a commercial compiler. (But see below.) > > > > That leaves several mysteries. 1) Why would a commercial compiler not > come > > with a linker? 2) Why did people who wanted to work with the PC/IP source > > need a Bell license? > > > > > > I did some more poking, and the list of files for the 86 compiler, from > > 'graball': > > > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > > table.c reader.c local2.c order.c match.c allo.c comm1.c > > manifest mfile1 common macdefs mfile2 mac2defs > > > > matched the file names from 'pcc', as given in "A Tour Through the > Portable C > > Compiler": > > > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > > > (in section "The Source Files"). So whether the 86 compiler was done at > MIT > > (by someone in RTS), or at a company, it was definitely a 'pcc' > descendant. > > > > (Possibly adding to the confusion, we had some other C compilers for > various > > ISA's in that project [building networking software for various > > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, > which I > > have also found. It's possible that Wayne's vague memory of a commercial > > compiler is of that one?) > > > > I really should reach out to Romkey and Bridgham, to see what they > remember. > > Later today. > > > > Whether the main motivation for keeping the compiler source on XX was i) > > because disk space was short on CSR (we had only a hand-me-down pair of > > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > > version skew; or iii) because it was a commercial compiler, and we had to > > protect the source (e.g. we didn't have the source to the 8080 compiler, > only > > the object modules), I have no idea. > > > > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the > 68K, > > > Z8000 and 8086. I believe that each had separate assemblers, tjt > who > > > sometimes reads this list might know more, as he wrote the 68K > assembler. > > > > There is an 'a86' directory on CSR, but it too is empty, except for a > 'grab' > > command file. That contains only: > > > > tftp -g $1 xx "PS:$1" > > > > I have no memory of who 'novick' might have been. A Web search for > 'novick > > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > > Novitsky; she was in our group at LCS, and I have a vague memory of her > being > > associated with the networking software for micro-computers project.) > > > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, > but he > > didn't write c86; 'novick' might not have written a86. > > > > Something else to ask Romkey and Bridgham about. > > > > Noel > > "a version of the portable C Compiler that was modified by Chris Terman > to produce code for an 8086 microprocessor was ported from the RTS VAX/780 > to the CSR PDP-11/45." > > https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf > > "If you think that you need the source code, you should realize that a > prerequisite to compiling the PC/IP programs is that you must have > imported Chris Terman's 8086 version of the UNIX Portable C compiler and > associated loader and assember systems. That importation in turn requires > a UNIX system, a current UNIX license, and negotiation with Chris Terman." > https://web.mit.edu/saltzer/www/publications/pcmemo.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu May 1 13:38:10 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 1 May 2025 13:38:10 +1000 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: Chris was part of the Nu project. "Was a principal developer of the NuMachine" "developed a family of portable C compilers for the (then) newly available microprocessors. These compilers were widely distributed as the first C implementations for the x86 and 68K processors." https://people.csail.mit.edu/cjt/resume.html On Wed, Apr 30, 2025 at 10:36:01PM -0400, Clem Cole wrote: > So did Chris compiler go back to the Nu project? And thank you to Al for > the Trix sources. As I said. It was national 16032 not z8000. > > > FYI I had the whitesmith compiler at one point also. It generated code for > a funky assembler called “anat” for “a natural assembler” which PJ conjured > up for writing the compiler. It was was sort of a mix between an IL and > 8080 assembler if my memory is correct. I’d love to see that > distribution both the doc and the compiler again to May with on SIMH. I > suspect I might appreciate it more than I did in those days. I hated it > then but as I learned more about compilers and architectures PJ might have > been on to something. > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 30, 2025 at 10:07 AM Jonathan Gray wrote: > > > On Wed, Apr 30, 2025 at 09:11:35AM -0400, Noel Chiappa wrote: > > > > From: Clem Cole > > > > > > > Yes, that was one of the RTS compilers for the NU machine. John > > Romkey > > > > may have done it, as he was the primary person behind PCIP > > > > > > I decided to poke around in the 'MIT-CSR' dump, since that was the > > machine > > > the PC/IP project started on, to see what I could find. Hoo boy! What an > > > adventure! > > > > > > In the PC/IP area, I found a 'c86' directory - but it was almost empty. > > It > > > did have a shell file, 'grab', which contained: > > > > > > tftp -g $1 xx "PS:$1" > > > > > > and a 'graball' file which called 'grab' for the list of compiler source > > > files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) > > > > > > So I did a Web search for Wayne Gramlich (with whom I hadn't > > communicated in > > > many decades), and he popped right up. (Amazing thing, this Internet > > thingy. > > > Who'd have ever thought, back in the day, that it would turn into what it > > > did? Well, probably John Brunner, whom I (sadly) never met, who was there > > > before any of us.) > > > > > > I took a chance, and called his number, and he was there, and we had a > > long > > > chat. He absolutely didn't do it, although he wrote the loader the > > project > > > used ('l68', the source for which I did find.) He's virtually certain > > Romkey > > > didn't (which would have been my guess too; Romkey was like a sophmore > > when > > > the project started). His best (_very_ faded) memory was that they > > started off > > > with a commercial compiler. (But see below.) > > > > > > That leaves several mysteries. 1) Why would a commercial compiler not > > come > > > with a linker? 2) Why did people who wanted to work with the PC/IP source > > > need a Bell license? > > > > > > > > > I did some more poking, and the list of files for the 86 compiler, from > > > 'graball': > > > > > > trees.c optim.c pftn.c code.c local.c scan.c xdefs.c > > > table.c reader.c local2.c order.c match.c allo.c comm1.c > > > manifest mfile1 common macdefs mfile2 mac2defs > > > > > > matched the file names from 'pcc', as given in "A Tour Through the > > Portable C > > > Compiler": > > > > > > https://maibriz.de/unix/ultrix/_root/porttour.pdf > > > > > > (in section "The Source Files"). So whether the 86 compiler was done at > > MIT > > > (by someone in RTS), or at a company, it was definitely a 'pcc' > > descendant. > > > > > > (Possibly adding to the confusion, we had some other C compilers for > > various > > > ISA's in that project [building networking software for various > > > micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, > > which I > > > have also found. It's possible that Wayne's vague memory of a commercial > > > compiler is of that one?) > > > > > > I really should reach out to Romkey and Bridgham, to see what they > > remember. > > > Later today. > > > > > > Whether the main motivation for keeping the compiler source on XX was i) > > > because disk space was short on CSR (we had only a hand-me-down pair of > > > CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent > > > version skew; or iii) because it was a commercial compiler, and we had to > > > protect the source (e.g. we didn't have the source to the 8080 compiler, > > only > > > the object modules), I have no idea. > > > > > > > > > > Anyway the MIT RTS folks made hardware and PCC back ends for the > > 68K, > > > > Z8000 and 8086. I believe that each had separate assemblers, tjt > > who > > > > sometimes reads this list might know more, as he wrote the 68K > > assembler. > > > > > > There is an 'a86' directory on CSR, but it too is empty, except for a > > 'grab' > > > command file. That contains only: > > > > > > tftp -g $1 xx "PS:$1" > > > > > > I have no memory of who 'novick' might have been. A Web search for > > 'novick > > > mit lcs' didn' turn anything up. (I wonder if it might have been Carol > > > Novitsky; she was in our group at LCS, and I have a vague memory of her > > being > > > associated with the networking software for micro-computers project.) > > > > > > Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, > > but he > > > didn't write c86; 'novick' might not have written a86. > > > > > > Something else to ask Romkey and Bridgham about. > > > > > > Noel > > > > "a version of the portable C Compiler that was modified by Chris Terman > > to produce code for an 8086 microprocessor was ported from the RTS VAX/780 > > to the CSR PDP-11/45." > > > > https://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/RFCs/csr-rfc-225.pdf > > > > "If you think that you need the source code, you should realize that a > > prerequisite to compiling the PC/IP programs is that you must have > > imported Chris Terman's 8086 version of the UNIX Portable C compiler and > > associated loader and assember systems. That importation in turn requires > > a UNIX system, a current UNIX license, and negotiation with Chris Terman." > > https://web.mit.edu/saltzer/www/publications/pcmemo.pdf > > From aek at bitsavers.org Thu May 1 14:20:56 2025 From: aek at bitsavers.org (Al Kossow) Date: Wed, 30 Apr 2025 21:20:56 -0700 Subject: [TUHS] PC/IP (was: Any Interdata war stories?) In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: On 4/30/25 8:38 PM, Jonathan Gray wrote: > Chris was part of the Nu project. > > "Was a principal developer of the NuMachine" > > "developed a family of portable C compilers for the (then) newly > available microprocessors. These compilers were widely distributed as > the first C implementations for the x86 and 68K processors." > > https://people.csail.mit.edu/cjt/resume.html I found most of the yearly LCS reports have been digitized to DTIC which answered a bunch of my questions about who was doing what at that time I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports From pugs78 at gmail.com Thu May 1 14:44:50 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 30 Apr 2025 21:44:50 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: I found this USENIX paper from Steve Johnson that has a lot of detail about the Interdata port (postscript format): "C and the AT&T Unix Port--A Personal History" https://www.usenix.org/legacy/publications/library/proceedings/usenix98/invited_talks/johnson.ps On Mon, Apr 28, 2025 at 11:55 PM wrote: > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; I don't think the code for it is in the > TUHS archives. > > Was the Interdata system in use at Bell Labs for actual work once > the port was complete? > > ISTR there was a meeting with Interdata about changes in the architecture > that Bell Labs wanted, that Interdata didn't want to make. What > was the full story? > > Any other info would be welcome. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri May 2 07:01:27 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 May 2025 21:01:27 +0000 Subject: [TUHS] Surviving System V/VME Artifacts? Message-ID: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was the WE321SB VME-bus single-board computer. The official operating system for this was UNIX System V/VME. This version is referenced in several document catalogues and literature surrounding this VME module. I was curious if anyone on list happens to know of any surviving System V/VME artifacts floating around out there. All I've been able to find are references to the system in other WE32x00 and UNIX documentation. Thanks for any info! - Matt G. From kevin.bowling at kev009.com Fri May 2 07:07:46 2025 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 1 May 2025 14:07:46 -0700 Subject: [TUHS] Surviving System V/VME Artifacts? In-Reply-To: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> References: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> Message-ID: On Thu, May 1, 2025 at 2:01 PM segaloco via TUHS wrote: > > So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was > the WE321SB VME-bus single-board computer. The official operating system for > this was UNIX System V/VME. This version is referenced in several document > catalogues and literature surrounding this VME module. I was curious if anyone > on list happens to know of any surviving System V/VME artifacts floating around > out there. All I've been able to find are references to the system in other > WE32x00 and UNIX documentation. I would also be interested if anyone has ever seen that hardware. VME stuff tends to be durable because it is used in machinery with long lifetimes so it doesn't usually go the way of commercial computer disappearing. > Thanks for any info! > > - Matt G. From tuhs at tuhs.org Fri May 2 07:35:40 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 May 2025 21:35:40 +0000 Subject: [TUHS] Surviving System V/VME Artifacts? In-Reply-To: References: <7N1hwohRijCD-e1YXNS-rsFj85Vj_lDQks3yc6Y31gK14djLTtRMRBw_3JsTZphiPBt34_ZEP9q2xRoKmKf7RDeRAqUvo8ANQCc3dShM1B4=@protonmail.com> Message-ID: On Thursday, May 1st, 2025 at 2:08 PM, Kevin Bowling wrote: > On Thu, May 1, 2025 at 2:01 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was > > the WE321SB VME-bus single-board computer. The official operating system for > > this was UNIX System V/VME. This version is referenced in several document > > catalogues and literature surrounding this VME module. I was curious if anyone > > on list happens to know of any surviving System V/VME artifacts floating around > > out there. All I've been able to find are references to the system in other > > WE32x00 and UNIX documentation. > > > I would also be interested if anyone has ever seen that hardware. VME > stuff tends to be durable because it is used in machinery with long > lifetimes so it doesn't usually go the way of commercial computer > disappearing. > > > Thanks for any info! > > > > - Matt G. Details about the module can be found here: https://archive.org/details/bitsavers_westernEleocessorsandPeripheralsAug87_47936355/page/n467/mode/2up In addition other WECo/ATTIS publications from the mid 80s describe this and other bits like the WE321EB eval board and WE321AP analysis pod. - Matt G. From arnold at skeeve.com Fri May 2 22:21:09 2025 From: arnold at skeeve.com (Aharon Robbins) Date: Fri, 02 May 2025 15:21:09 +0300 Subject: [TUHS] Off topic: Books on Unix security? Message-ID: Hi All. In a book I'm updating, I have the following references for Unix security. 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. 2. Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. One of my reviewers asked if these weren't "dusty references". So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. Thanks, Arnold From tjteixeira at earthlink.net Sat May 3 00:56:58 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Fri, 2 May 2025 10:56:58 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> On 5/1/25 12:20 AM, Al Kossow wrote: > On 4/30/25 8:38 PM, Jonathan Gray wrote: >> Chris was part of the Nu project. >> >> "Was a principal developer of the NuMachine" >> >> "developed a family of portable C compilers for the (then) newly >> available microprocessors. These compilers were widely distributed as >> the first C implementations for the x86 and 68K processors." >> >> https://people.csail.mit.edu/cjt/resume.html > > I found most of the yearly LCS reports have been digitized to DTIC > which answered a bunch of my questions about who was doing what at > that time > > I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports > > > Some background, though the MIT LCS progress reports should cover much of this. I won't attempt to put any dates. Chris Terman was one of the graduate students in the RTS group. Since VT-52 terminals were relatively scarce, he designed and built his own with a larger screen - something like 40 lines by maybe 120 or 132 characters, called the "Termanal". I don't remember if it used an 8080 to handle the control sequences in the data stream or something else. He then got interested in designing a terminal that could display bit map graphics, to be comparable to the graphics used on the Lisp Machines just being built by the MIT-AI lab. I had stumbled across one of the LCS progress reports that credits Professor Steve Ward and one of the undergraduate staff, Rae McClellan in assisting the design of this bit graph which was named the "Nu Terminal" (I don't think it was the "Nu Termanal"). This used an 8086. A couple of these were built. One of the undergraduate students, Jon Sieber, had been a member of an Explorer Post in Murray Hill where Dennis Ritchie was the advisor. Jon would regularly bring UNIX tapes from the Research Lab and included things like early versions of the Portable C Compiler and the Circuit Design Aids. Chris used the Circuit Design Aids to design wire-wrap boards for the Nu Terminal and the RTS lab got a semi-automatic wire wrap machine. Some students and staff took turns doing the actual wire wrapping. My contribution was writing some simple software that simulated a paper tape reader for the wire wrap machine. An undergraduate student, Mike Patrick, did his bachelor's thesis writing a table driven assembler and constructed tables for the 8086 and I think an 8080. Later there were drivers for the Zylog Z8000, the National Semiconductor NS16000 and the Motorola 68000. I contributed a small bit of code for doing optimal choice of short vs long branches (to branch to an address more than +/- 127 bytes, you had to branch around a longer jump instruction). Chris Terman did the work of modifying the Portable C Compiler to generate code for the 8086, the Z8000, NS16000 and MC68000. I think we may have built one machine with the Z8000, but quickly settled on using the MC68000, primarily because of the 32-bit support (one progress report says that Zenith was supposed to build multiple Z8000 based machines, but I don't remember those. The NS16000 had better memory management, but I don't think we ever actually received any CPU chips. Anyway, these compilers were what was distributed, and the MC68000 compiler in particular was used by almost all the companies that came out the MC68000-based Unix machines. Apollo was a notable exception, but Apollo wrote their own operating system from scratch rather than Unix. Side note: Bill Poduska came to visit Steve Ward and before the visit Steve was all excited, but was disappointed that Bill was not going to use Unix. Before the RTS group used Unix, they had written a small timesharing system for the PDP-11/45 that was used in the 6.031 introductory computer science course taught by Mike Dertouzos. Chris was involved in maintaining that, though I think Steve Ward was probably the main implementor. Chris had also spent too many hours changing address jumpers on Unibus and other controllers as well as tweaking Unix mkconf files, and thought that while the 4BSD autoconfiguration was an improvement, there should be a better way. Chris and Steve designed the Nu bus, and the Nu Bus was used in the MC68000 boards. Eventually it was picked up by Apple. Chris was one of many students who took the Mead/Conway LSI design course and ended up abandoning his research on portable compilers in favor of simulating LSI designs. He was also a co-founder of Symbolics and designed the controller for their laser printer before returning to MIT as a Lecturer and sponsored research staff. There were also proposed follow-on software projects related to the Nu terminal. One was Trix. Steve Ward said he didn't know what an "ics" was, but Multics clearly had too many, and Unix had too few, hence Trix. Jack Test was hired to do a lot of the development. Wikipedia has a reasonable summary of Trix, as far as I remember, but I had left RTS to join Masscomp in late 1981/early 1982, and I know Jack Test was an early employee of Alliant Computer so he left Trix probably in 1982. From clemc at ccc.com Sat May 3 01:15:39 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 May 2025 11:15:39 -0400 Subject: [TUHS] PC/IP In-Reply-To: <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: Thank you, Tom, for the definitive answers to much of this. I remembered that the Z8000 was mixed up in that mess, but it was missing from Al's Trix tape. Do you know if a Z8000 back end or set of support tools was ever built, and if so, does anyone know if they survived? It does look like Al has 8086 [Terman compiler]. 68K (of a few flavors) and an NS16032 (author's unknown). One of the tools you mentioned from MIT seems to have survived, although Dennis and I saved the official UNIX Circuit Design System release in the mid-1990s. Warren has had that TUHS archives ever since, but I'm not I ever saw you tools other than things like you 68K assembler, and I guess is was our fiiend Wayne that wrote the linker (which until this thread I did not now). BTW: Again, it proves how interwoven the people and tech (i.e., open source culture) were in the 1970s; i.e., it's not a new thing. The PDPs were running the Stanford Circuit Design System (SUDS) and the 11's often at USCD. The people came and went. For instance,the former Wayne was a year ahead of me at CMU before he headed to MIT for a Master's and PhD, ᐧ On Fri, May 2, 2025 at 10:57 AM Tom Teixeira wrote: > On 5/1/25 12:20 AM, Al Kossow wrote: > > On 4/30/25 8:38 PM, Jonathan Gray wrote: > >> Chris was part of the Nu project. > >> > >> "Was a principal developer of the NuMachine" > >> > >> "developed a family of portable C compilers for the (then) newly > >> available microprocessors. These compilers were widely distributed as > >> the first C implementations for the x86 and 68K processors." > >> > >> https://people.csail.mit.edu/cjt/resume.html > > > > I found most of the yearly LCS reports have been digitized to DTIC > > which answered a bunch of my questions about who was doing what at > > that time > > > > I've archived them at http://bitsavers.org/pdf/mit/lcs/progress_reports > > > > > > > Some background, though the MIT LCS progress reports should cover much > of this. I won't attempt to put any dates. > > Chris Terman was one of the graduate students in the RTS group. Since > VT-52 terminals were relatively scarce, he designed and built his own > with a larger screen - something like 40 lines by maybe 120 or 132 > characters, called the "Termanal". I don't remember if it used an 8080 > to handle the control sequences in the data stream or something else. > > He then got interested in designing a terminal that could display bit > map graphics, to be comparable to the graphics used on the Lisp Machines > just being built by the MIT-AI lab. I had stumbled across one of the LCS > progress reports that credits Professor Steve Ward and one of the > undergraduate staff, Rae McClellan in assisting the design of this bit > graph which was named the "Nu Terminal" (I don't think it was the "Nu > Termanal"). This used an 8086. A couple of these were built. One of the > undergraduate students, Jon Sieber, had been a member of an Explorer > Post in Murray Hill where Dennis Ritchie was the advisor. Jon would > regularly bring UNIX tapes from the Research Lab and included things > like early versions of the Portable C Compiler and the Circuit Design > Aids. Chris used the Circuit Design Aids to design wire-wrap boards for > the Nu Terminal and the RTS lab got a semi-automatic wire wrap machine. > Some students and staff took turns doing the actual wire wrapping. My > contribution was writing some simple software that simulated a paper > tape reader for the wire wrap machine. > > An undergraduate student, Mike Patrick, did his bachelor's thesis > writing a table driven assembler and constructed tables for the 8086 and > I think an 8080. Later there were drivers for the Zylog Z8000, the > National Semiconductor NS16000 and the Motorola 68000. I contributed a > small bit of code for doing optimal choice of short vs long branches (to > branch to an address more than +/- 127 bytes, you had to branch around a > longer jump instruction). > > Chris Terman did the work of modifying the Portable C Compiler to > generate code for the 8086, the Z8000, NS16000 and MC68000. I think we > may have built one machine with the Z8000, but quickly settled on using > the MC68000, primarily because of the 32-bit support (one progress > report says that Zenith was supposed to build multiple Z8000 based > machines, but I don't remember those. The NS16000 had better memory > management, but I don't think we ever actually received any CPU chips. > > Anyway, these compilers were what was distributed, and the MC68000 > compiler in particular was used by almost all the companies that came > out the MC68000-based Unix machines. Apollo was a notable exception, but > Apollo wrote their own operating system from scratch rather than Unix. > Side note: Bill Poduska came to visit Steve Ward and before the visit > Steve was all excited, but was disappointed that Bill was not going to > use Unix. > > Before the RTS group used Unix, they had written a small timesharing > system for the PDP-11/45 that was used in the 6.031 introductory > computer science course taught by Mike Dertouzos. Chris was involved in > maintaining that, though I think Steve Ward was probably the main > implementor. Chris had also spent too many hours changing address > jumpers on Unibus and other controllers as well as tweaking Unix mkconf > files, and thought that while the 4BSD autoconfiguration was an > improvement, there should be a better way. Chris and Steve designed the > Nu bus, and the Nu Bus was used in the MC68000 boards. Eventually it was > picked up by Apple. > > Chris was one of many students who took the Mead/Conway LSI design > course and ended up abandoning his research on portable compilers in > favor of simulating LSI designs. He was also a co-founder of Symbolics > and designed the controller for their laser printer before returning to > MIT as a Lecturer and sponsored research staff. > > There were also proposed follow-on software projects related to the Nu > terminal. One was Trix. Steve Ward said he didn't know what an "ics" > was, but Multics clearly had too many, and Unix had too few, hence Trix. > Jack Test was hired to do a lot of the development. Wikipedia has a > reasonable summary of Trix, as far as I remember, but I had left RTS to > join Masscomp in late 1981/early 1982, and I know Jack Test was an early > employee of Alliant Computer so he left Trix probably in 1982. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat May 3 01:28:03 2025 From: aek at bitsavers.org (Al Kossow) Date: Fri, 2 May 2025 08:28:03 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On 5/2/25 8:15 AM, Clem Cole wrote: > Thank you, Tom, for the definitive answers to much of this. This is a huge help to me. I came to Apple just before the Mac II was released and know all of the people that were involved with designing our PC version of Nubus. One of the people was Tony Masterson who came to Apple from TI, and I think I remember him telling me he was a MIT grad student. I've traced the path from Western Digital to TI for Nubus George White seems to be the MIT - Western Digital connection. http://bitsavers.org/pdf/ti/nubus/White_-_Nubus_Computer_Design_19840615.pdf Getting back to Unix, TI used Nubus to build the Explorer Lisp machines, with roots back to the MIT CADR based on the Nu Machine (aka TI 1500 Unix system). HP bought the 1500 product line, which was then EOL'ed. From jsg at jsg.id.au Sat May 3 19:16:57 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 3 May 2025 19:16:57 +1000 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On Fri, May 02, 2025 at 08:28:03AM -0700, Al Kossow wrote: > On 5/2/25 8:15 AM, Clem Cole wrote: > > Thank you, Tom, for the definitive answers to much of this. > > This is a huge help to me. I came to Apple just before the Mac II was released and know > all of the people that were involved with designing our PC version of Nubus. One of the > people was Tony Masterson who came to Apple from TI, and I think I remember him telling > me he was a MIT grad student. I've traced the path from Western Digital to TI for Nubus > George White seems to be the MIT - Western Digital connection. > http://bitsavers.org/pdf/ti/nubus/White_-_Nubus_Computer_Design_19840615.pdf James Gula was another person who moved from MIT to WD to TI. "Jim Gula has left the LCS staff to join WD; while we regret losing him, we feel that he will serve important roles both in the MIT/WD interface and in making the Nu into a successful product." LCS Progress Report 18, July 1980 - June 1981, p 212 "In December, it was concluded that the research interests of the TRIX project were best served by a re-engineering of its internal structure rather than by polishing of the existing implementation. In order to reconcile this plan with the need for a viable Nu programming environment for other projects, Version 7 UNIX was ported to the Nu during the Spring by Gula, Sieber, Terman, and Test." LCS Progress Report 18, July 1980 - June 1981, p 213 "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. We have an Ethernet based version of this Unix running at Stanford" Vaughan Pratt on fa.works, Jan 1982 https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ https://www.saildart.org/WORKS.MSG[UP,DOC]28 James Gula on LinkedIn: Engineering Manager, Texas Instruments, 1983 - 1986 Engineering manager for the Nu Machine Project Software Engineering Manager, Western Digital, 1981 - 1983 Managed the UNIX port to the Nu Machine project Technical Staff, MIT LCS, 1979 - 1981 Port of UNIX to the Nu Machine and related software. From douglas.mcilroy at dartmouth.edu Sat May 3 22:14:18 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 3 May 2025 08:14:18 -0400 Subject: [TUHS] Paragraphs formatted differently depending on previous ones Message-ID: Branden, > The relevant function fits on one screen, if your terminal window is at > least 36 lines high. :) (Much of it is given over to comments.) > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=d96a9c58bbe296b065fa250e3ea1e1a410cdde81#n2185 Actually there's still another function, spread_space that contains the inner R-L and L-R loops. The whole thing has become astonishingly complicated compared to what I remember as a few (carefully crafted) lines of code in the early roff. I admire your intrepid forays into the groff woods, of which this part must be among the less murky. Doug From g.branden.robinson at gmail.com Sat May 3 22:58:41 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 3 May 2025 07:58:41 -0500 Subject: [TUHS] Paragraphs formatted differently depending on previous ones In-Reply-To: References: Message-ID: <20250503125841.fmom3jjpgh4djyxq@illithid> [looping the groff list back in; Doug emailed TUHS instead] At 2025-05-03T08:14:18-0400, Douglas McIlroy wrote: > > The relevant function fits on one screen, if your terminal window is > > at least 36 lines high. :) (Much of it is given over to comments.) > > > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=d96a9c58bbe296b065fa250e3ea1e1a410cdde81#n2185 > > Actually there's still another function, spread_space that contains > the inner R-L and L-R loops. Yes. `distribute_space()` is in "env.cpp" (environment handling) and operates on the output line. `spread_space()` is in "node.cpp" and is what alters the width of `word_space_node` (and derived `unbreakable_space_node`) objects on the line. Whereas in troff mode, often every adjustable space on an underset line experiences adjustment, in nroff mode the converse is frequently true, as shown below. Some of this stuff will be more visible for debugging purposes with the new `pline` request and improved `pm` request in the forthcoming groff 1.24.0 release. Here's an altered version of the adjustment demonstrator I cooked up for Alex. It uses a shorter line length and fewer repetitions of "alex", but still illustrates alternating adjustment "parity", as I term it. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; \ printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; echo .dd; } \ | nroff 2>/dev/null | cat -s alex alex alex alex alex alex alex If we discard normal output with the `-z` option, reënable output to standard error, and send that to jq(1) for formatting, we get more information, which I'll relegate to a footnote because it's lengthy.[1] It also serves to illustrate how we can dump diversions, and the intriguing properties thereof in GNU troff. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; \ printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; } | nroff -z 2>&1 | jq > The whole thing has become astonishingly complicated compared to what > I remember as a few (carefully crafted) lines of code in the early > roff. The first computer I ever touched, and programmed, had 16 KB of RAM. Necessity is a mother in more than one sense. ;-) I'm doing what I can with the GNU troff code base to make it more intelligible. Among the windmills I'm tilting at are improved type annotations (like using `bool` for Booleans instead of integers for Yet Another Purpose), explicitly annotated null pointers, and above all, more meaningful variable and function names. Kernighan and Plauger, then Pike, beat this drum repeatedly in their books on programming style, but we're still not rid of hackers who think naming a variable `bflag` is a good idea. > I admire your intrepid forays into the groff woods, of which this part > must be among the less murky. Thank you! The reformed handling of device extension requests/escapes so that they could encode Unicode characters, and their conversion into nodes, was almost more murk than I could stand. I think it might have helped to have some of the new introspection features 12-18 months ago, but we have them now. There's always more to learn, and to document. For those who hadn't noticed, I'll put the relevant part of the "NEWS" file in another footnote.[2] I'm on the verge of adding another, `pftr`, to dump the dictionary of font translations (remappings), because mdoc is proving to be a headache this week with Savannah #66126. Regards, Branden [1] Observe how some of the `word_space_node`s have a width of `24`, and others a width of `48`. The latter are the "adjusted" spaces. $ { echo .ll 15n; echo .di dd; for n in $(seq 7); do echo alex; done; printf '.pl \\n(nlu\n'; echo .di; echo .pm dd; } | nroff -z 2>&1 | jq { "name": "dd", "file name": "", "starting line number": 2, "length": 35, "contents": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\n\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\n", "node list": [ { "type": "line_start_node", "diversion level": 0, "is_special_node": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 48, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 24, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": -40 }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": 0 }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 24, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "word_space_node", "diversion level": 0, "is_special_node": false, "hunits": 48, "undiscardable": true, "is hyphenless breakpoint": false, "terminal_color": "default", "width_list": [ { "width": 24, "sentence_width": 24 } ], "unformat": false }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "a" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "l" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "e" }, { "type": "glyph_node", "diversion level": 0, "is_special_node": false, "character": "x" }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": -40 }, { "type": "vertical_size_node", "diversion level": 0, "is_special_node": false, "vunits": 0 } ] } [2] NEWS: ---snip--- * A new request, `pcolor`, reports to the standard error stream details of each color name specified as an argument, including its color space identifier and channel value assignments. Without arguments, all defined colors are listed. (A device's default stroke and/or fill colors, "default", are not listed since they are immutable and their details unknown to the formatter.) * A new request, `pchar`, reports to the standard error stream data about any ordinary, special, or indexed character arguments. * A new request, `pcomposite`, reports to the standard error stream the list of defined composite character mappings. * A new request, `phw`, reports to the standard error stream the list of hyphenation exceptions associated with the current hyphenation language. * A new request, `pline`, reports to the standard error stream the list of output nodes (an internal data structure) corresponding to the pending output line. The list is empty if no such nodes exist. * The `pm` request now interprets any arguments as a sequence of macro, string, or diversion names, and reports their contents. * The `pnr` request now additionally reports the autoincrementation amount and interpolation format of each register (if it is not string-valued). * The `pnr` request now accepts arguments. It treats each as identifying a register and reports its properties to the standard error stream. * A new request, `pstream`, reports to the standard error stream the name of each stream opened with the `open` or `opena` requests, the name of the file backing it, and its mode (writing or appending). ---end snip--- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tjteixeira at earthlink.net Sat May 3 23:49:18 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Sat, 3 May 2025 09:49:18 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: <2e5786ed-73b2-4dac-b413-180fca01428e@earthlink.net> On 5/2/25 11:15 AM, Clem Cole wrote: > Thank you, Tom, for the definitive answers to much of this.  I > remembered that the Z8000 was mixed up in that mess, but it was > missing from Al's Trix tape.  Do you know if a Z8000 back end or set > of support tools was ever built, and if so, does anyone know if they > survived?  It does look like Al has 8086 [Terman compiler].  68K (of a > few flavors) and an NS16032 (author's unknown).  One of the tools you > mentioned from MIT seems to have survived, although Dennis and I saved > the official UNIX Circuit Design System release in the > mid-1990s. Warren has had that TUHS archives ever since, but I'm not I > ever saw you tools other than things like you 68K assembler, and I > guess is was our fiiend Wayne that wrote the linker (which until this > thread I did not now). > > BTW: Again, it proves how interwoven the people and tech (i.e., open > source culture) were in the 1970s; i.e., it's not a new thing.  The > PDPs were running the Stanford Circuit Design System (SUDS) and the > 11's often at USCD.  The people came and went.   For instance,the > former Wayne was a year ahead of me at CMU before he headed to MIT for > a Master's and PhD, > ᐧ > > I'm pretty sure a Z8000 back end was produced because I remember that we built at least one Z8000 board. One of the LCS progress reports mentions that Zenith had committed to build some Z8000 systems, back when "office automation" was a thing. However, I have no idea what happened to the tools. I don't remember anyone but Chris producing back ends, but it's possible someone else did the NS16032. But I don't remember anything else about the NS16000 systems. The tools Chris and others produced in support of the Mead/Conway LSI course were also widely distributed, but I'm not sure what the mechanism. Since those were completely unencumbered by Unix, there was probably less formality, but I expect the MIT license was included. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun May 4 04:29:14 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 3 May 2025 11:29:14 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > We have an Ethernet based version of this Unix running at Stanford" > Vaughan Pratt on fa.works, Jan 1982 > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > https://www.saildart.org/WORKS.MSG[UP,DOC]28 Since I've never seen the design for the original Nu 68K I wonder if that was where the "SUN" segment/page MMU came from, since it looked similar to what was in the CADR, and if the sniffing of the stack to see if it needed to grow on function calls came from the Terman compiler. From clemc at ccc.com Sun May 4 05:01:05 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 3 May 2025 15:01:05 -0400 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: There were a couple of solutions, but they were all similar, which might be challenging to figure out now. The first gen of the the micros needed an external MMU and by the time of the Z8000/68K family/NS16032/and even the Intel devices were already several different MMU from mini's and mainframes which the different microprocessor MMU swiped different ideas and added a few other there own (particular to them). I think poking around the Asilimor Workshop Archives is likely to be the most fruitful. I would love to find a copy of Forest Basket's paper where he proposed using 2 68000's as 'executor' and 'fixer' as Apollo and Masscomp would do [many of those were from Asilomar - Forest's was]. Yale Patt and a few of his students had a few MMU papers for some of the chips around that time, IIRC. Sadly, my copies of that stuff from a few of those Asilomar conferences were lost. ᐧ On Sat, May 3, 2025 at 2:29 PM Al Kossow wrote: > > > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > > We have an Ethernet based version of this Unix running at Stanford" > > Vaughan Pratt on fa.works, Jan 1982 > > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > > https://www.saildart.org/WORKS.MSG[UP,DOC]28 > > Since I've never seen the design for the original Nu 68K I wonder if > that was where the "SUN" segment/page MMU came from, since it looked > similar to what was in the CADR, and if the sniffing of the stack to > see if it needed to grow on function calls came from the Terman compiler. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun May 4 05:14:48 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 3 May 2025 12:14:48 -0700 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On 5/3/25 12:01 PM, Clem Cole wrote: > There were a couple of solutions, but they were all similar, which might be challenging to figure out now. The first gen of the the micros > needed an external MMU and by the time of the Z8000/68K family/NS16032/and even the Intel devices were already several different MMU from > mini's and mainframes which the different microprocessor MMU swiped different ideas and added a few other there own (particular to them).  I > think poking around the Asilimor Workshop Archives is likely to be the most fruitful.  I would love to find a copy of Forest Basket's paper > where he proposed using 2 68000's as 'executor' and 'fixer' as Apollo and Masscomp would do [many of those were from Asilomar - Forest's > was].  Yale Patt and a few of his students had a few MMU papers for some of the chips around that time, IIRC.   Sadly, my copies of that > stuff from a few of those Asilomar conferences were lost. > I hope the scanning and preservation efforts of the past 20 years continues. As a naive engineer coming to the Valley in 1984 with my only prior exposure being Usenet, the degree of tribal knowledge and interconnectedness took a while to realize. I'm still learning things, for example what is coming to light here, even after working at the Computer History Museum for almost 20 years now along with realizing how much of Valley folklore we don't have in our archives. From kevin.bowling at kev009.com Sun May 4 13:53:42 2025 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 3 May 2025 20:53:42 -0700 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: On Fri, May 2, 2025 at 5:21 AM Aharon Robbins wrote: > Hi All. > > In a book I'm updating, I have the following references for > Unix security. > > 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, > Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, > CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. > > 2. Building Secure Software: How to Avoid Security Problems the Right Way, > by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, > USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. > > 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew > Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, > 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. > > One of my reviewers asked if these weren't "dusty references". > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > I’d have to rummage around for a definitive answer but I think things have fractured a bit and OS level security is either a chapter or section in academic or professional books. That is mostly survey or long standing information, the edge is all in open source code and/or papers/presentations. There are several recent cryptography books aimed at a more practitioner level I can recommend if that is relevant to your quest. The main book that comes to mind 0321822137 is a C and C++ security survey that is worthwhile but not OS specific. I’d also like to know your title so I can add it to my collection when it is ready! > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun May 4 16:48:29 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 4 May 2025 16:48:29 +1000 Subject: [TUHS] PC/IP In-Reply-To: References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <4140ce42-1ef4-4e57-8f76-3881735d33e4@earthlink.net> Message-ID: On Sat, May 03, 2025 at 11:29:14AM -0700, Al Kossow wrote: > > > "John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. > > We have an Ethernet based version of this Unix running at Stanford" > > Vaughan Pratt on fa.works, Jan 1982 > > https://groups.google.com/g/fa.works/c/WHpSvlbG0A8/m/IUdSUIwJqAgJ > > https://www.saildart.org/WORKS.MSG[UP,DOC]28 > > Since I've never seen the design for the original Nu 68K I wonder if > that was where the "SUN" segment/page MMU came from, since it looked > similar to what was in the CADR, and if the sniffing of the stack to > see if it needed to grow on function calls came from the Terman compiler. Perhaps the Nu paper mentions an MMU? Referenced by the SUN documents, but not available online. S. A. Ward and C. J. Terman, "An approach to personal computing" Proceedings of COMPCON, IEEE, February 1980, pp. 460-465. IEEE doesn't have it online at https://www.computer.org/csdl/proceedings/1000109 The CHM has the proceedings: https://www.computerhistory.org/collections/catalog/102713995 CompCon80; VLSI: New Architectural Horizons; 1980. -- "The one question mark for the CPU board design was the memory management unit, to which Andy, Forest (who sent us a design while at PARC), and I all made significant contributions." Vaughan Pratt, in: >From the Valley of Heart's Delight to the Silicon Valley: A Study of Stanford University's Role in the Transformation Appendix A: The Founding of Sun Microsystems http://infolab.stanford.edu/pub/cstr/reports/csl/tr/97/713/CSL-TR-97-713.ps "So we switched to the 68000. I think we ended up with a 6810 as the original processor. I designed a memory-mapping system for that processor, which barely had the capabilities to do memory mapping. The original SUN workstation had a really fascinating memory mapping system. I was a little annoyed with Andy, because years later I discovered that he had patented that memory mapping system." Oral History of Forest Baskett, p 13 https://archive.computerhistory.org/resources/access/text/2017/12/102717243-05-01-acc.pdf https://patents.google.com/patent/US4527232A/en https://patents.google.com/patent/US4550368A/en From rich.salz at gmail.com Sun May 4 22:05:42 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 4 May 2025 08:05:42 -0400 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: The Bellovin and Cheswick book(s) although it's more about network security and firewalls. The OWASP guides. Practical UNIX and Internet security Book by Simson Garfinkel -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Sun May 4 22:46:29 2025 From: norman at oclsc.org (Norman Wilson) Date: Sun, 4 May 2025 08:46:29 -0400 (EDT) Subject: [TUHS] Off topic: Books on Unix security? Message-ID: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> Aharon Robbins: So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. === `Unix security' is not the most-specific of terms. Can you give more context? Norman Wilson Toronto ON From arnold at skeeve.com Sun May 4 23:32:21 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 04 May 2025 07:32:21 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> References: <0C977B8079CB002320322B6EE965753B.for-standards-violators@oclsc.org> Message-ID: <202505041332.544DWLj41616716@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > Aharon Robbins: > > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > > === > > `Unix security' is not the most-specific of terms. Can > you give more context? > > Norman Wilson > Toronto ON Classic things like setuid programs, writing daemons, as well as general secure coding practices for C and C++ in a *nix context. Thanks, Arnold From rik at rikfarrow.com Mon May 5 04:01:12 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Sun, 4 May 2025 11:01:12 -0700 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: Paul von Oorschot's Tools and Jewels: https://people.scs.carleton.ca/~paulv/toolsjewels.html This was designed as a textbook for security, and includes very good coverage of cryptography. Rik On Sun, May 4, 2025 at 5:06 AM Rich Salz wrote: > The Bellovin and Cheswick book(s) although it's more about network > security and firewalls. > The OWASP guides. > Practical UNIX and Internet security Book by Simson Garfinkel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Wed May 7 00:16:21 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 6 May 2025 09:16:21 -0500 Subject: [TUHS] Paragraphs formatted differently depending on previous ones In-Reply-To: References: <20250503003445.2ker2h3dgomawk6h@illithid> Message-ID: <20250506141621.wbilioq2bl3ibb6n@illithid> [looping TUHS back in since I'm correcting a message I sent there] Hi Dave, At 2025-05-06T08:36:55-0500, Dave Kemper wrote: > On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson > wrote: > > I guess another way of saying this is that, as I conceive it, a line > > that is "adequately full" contributes to the page's uniformity of > > grayness by definition. > > For an example of less-than-ideal results if this is _not_ considered > the case (groff's behavior before this change), see > http://savannah.gnu.org/bugs/?60673#comment0 (the initial report that > precipitated the commit Doug is commenting on). Yes. In my reply to Doug I incorrectly characterized the resolution of this bug as a "2023" change of mine, but I actually landed the change in 2021. It simply took until 2023 to appear in a released _groff_. To make this message more TUHS-o-riffic, let's observe that input using DWB 3.3 troff and Heirloom Doctools troff (descended from Solaris troff, descended from DWB 2.0 troff [I think]), and both of which descend from Kernighan's device-independent troff circa 1980. $ DWBHOME=. ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. $ ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. They are the same, and differ from groff 1.22.4 and earlier only in that they adjust spaces starting from the right end of the line instead of the left. At the risk of tooting our own horn, here's how groff 1.23.0+ handles the same input. $ ~/groff-1.23.0/bin/nroff groff-60673.roff | cat -s While the example in bug 57836’s original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty’s balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn’t "count" lines that don’t need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. Three observations: 1. One can find the input at Dave's URL above. 2. The input disables inter-sentence spacing. 3. The adjustment algorithm is a property not of grotty(1) (the output driver), but of GNU troff itself. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From arnold at skeeve.com Wed May 7 01:01:00 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 May 2025 09:01:00 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: <202505061501.546F10gs1802134@freefriends.org> Thanks to everyone who responded. Besides the original three in my quoted email, here are the additional ones I was recommended and have added to the list in my book. Some were recommended by more than one person. In any case, thank you all! 4. Secure Coding in C and C++, 2nd Edition, by Robert Seacord. ISBN-10: 0321822137, ISBN-13: 978-0321822130, Addison-Wesley Professional, Reading, Massachusetts, USA, 2013. 5. Secure Coding: Principles and Practices, by Mark G. Graff, Kenneth R. Van Wyk, and Debby Russell. ISBN-10: 0596002424, ISBN-13: 978-0596002428. O’Reilly Media, Inc., USA, 2003. 6. Writing Secure Code, 2nd Edition, by Michael Howard and David LeBlanc. ISBN-10: 0735617228, ISBN-13: 978-0735617223. Microsoft Press, USA, 2003. 7. Computer Security and the Internet—Tools and Jewels from Malware to Bitcoin, 2nd Edition, by Paul C. van Oorschot. ISBN-13: 978-3-030-83410-4. Springer Nature Switzerland AG, 2021. 8. Thinking Security: Stopping Next Year’s Hackers by Steven M. Bellovin. ISBN-10: 0134277546, ISBN-13: 978-0134277547. Addison-Wesley Professional, Reading, Mas- sachusetts, USA, 2015. 9. Security Engineering: A Guide to Building Dependable Distributed Systems, 3rd Edi- tion, by Ross Anderson. ISBN-10: 1119642787, ISBN-13: 978-1119642787. Wiley, USA, 2020. 10. Designing Secure Software: A Guide for Developers, by Loren Kohnfelder. ISBN-10: 1718501927, ISBN-13: 978-1718501928. No Starch Press, USA, 2021. 11. Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems, by Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield. ISBN-10: 1492083127, ISBN-13: 978-1492083122. O’Reilly Media, USA, 2020. 12. Secure By Design, by Daniel Deogun, Dan Bergh Johnsson, and Daniel Sawano. ISBN-10: 1617294357, ISBN-13: 978-1617294358. Manning, USA, 2019. Aharon Robbins wrote: > Hi All. > > In a book I'm updating, I have the following references for > Unix security. > > 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, > Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, > CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. > > 2. Building Secure Software: How to Avoid Security Problems the Right Way, > by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, > USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. > > 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew > Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, > 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. > > One of my reviewers asked if these weren't "dusty references". > So, before I just refer to them as "classics", can anyone recommend > more recent books? Feel free to answer in private. > > Thanks, > > Arnold From crossd at gmail.com Wed May 7 08:52:49 2025 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 May 2025 18:52:49 -0400 Subject: [TUHS] ATC'25 is the last ATC? Message-ID: I just heard that, after ATC'25, USENIX will be sunsetting the annual technical conference: this will apparently be the last one. I can't find any reference for it, though, and the web site mentions ATC'26 in Seattle? - Dan C. From rik at rikfarrow.com Wed May 7 09:41:46 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 6 May 2025 16:41:46 -0700 Subject: [TUHS] Fwd: An Announcement about the USENIX Annual Technical Conference In-Reply-To: References: Message-ID: I received this earlier today, and wondered if cross-posting it would be appropriate. Here goes... Rik ---------- Forwarded message --------- From: Casey Henderson-Ross Date: Tue, May 6, 2025 at 2:12 PM Subject: An Announcement about the USENIX Annual Technical Conference To: Rik Farrow Read on for important news. [image: USENIX, the Advanced Computing Systems Association] Hello, Rik, USENIX celebrates its 50th anniversary in 2025. We celebrate decades of innovations, experiments, and gatherings of the advanced computing system community. And in the spirit of our ever-evolving community, field, and industry, we announce the bittersweet conclusion of our longest-running event, the USENIX Annual Technical Conference in July 2025, following USENIX ATC '25. Since USENIX's inception in 1975, it has been a key gathering place for innovators in the advanced computing systems community. The early days of meetings evolved into the two annual conferences, the USENIX Summer and Winter Conferences, which in 1995 merged into the single Annual Technical Conference that has continued to evolve and serve thousands of our constituents for 30 years. For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC. USENIX ATC in its many iterations has been the home of an incredible list of "firsts" in our industry: - In 1979, ONYX, the first attempt at genuine UNIX hardware, was announced. - In 1982, DEC unveiled the creation of its UNIX product. - In 1983, Eric Allman presented the first paper on Sendmail, "Mail Systems and Addressing in 4.2BSD." - In 1985, Sun Microsystems presented the first paper on NFS, "Design and Implementation of the Sun Network Filesystem." - In 1988, the first light on Kerberos and the X Window system was presented. - In 1989, Tom Christiansen made his first Perl presentation as an Invited Talk. - In 1990, John Ousterhout presented Tcl. - In 1995, the first talk on Oak (later JAVA) was given as a Work-in-Progress report. - In 1998, Miguel de Icaza presented "The GNOME Desktop Environment." These examples represent just a few of the many contributions presented at USENIX ATC over the years, with hundreds of papers that account for thousands of citations of work that the community has presented, discussed, learned from, and built upon as the community evolved. Part of that evolution involved the continued development of subcommunities, as has been the case with USENIX Security, which began as a workshop in 1988 and has since grown to an annual symposium and the largest of our events in terms of both papers published and number of attendees annually, with 417 papers and 1,015 attendees at USENIX Security '24. The LISA (Large Installation System Administration) Conference, which also started as a workshop in 1987, grew in a similar fashion to its peak of over 1,000 attendees, but like USENIX ATC declined as its community changed until its own sunset in 2021. Papers on file and storage systems that would have previously been presented at USENIX ATC in the early 2000s began to find homes at FAST when it was founded in 2002. Networked systems papers started flowing to NSDI in 2003. As the biennial OSDI continued to grow alongside ACM's SOSP, OSDI became annual in 2021 and SOSP followed suit, providing the community with additional venues. While landmark moments in our community have continued at USENIX ATC, many others have also occurred at these other USENIX conferences, as showcased in the USENIX Test of Time Awards and the ACM SIGOPS Hall of Fame Awards , which celebrate influential works presented at both SOSP and OSDI. Although numerous papers continue to be submitted to USENIX ATC with significant research being reviewed, accepted, and presented, the community has evolved, and now attends conferences other than USENIX ATC. From 1,698 attendees in San Diego in 2000, ATC attendance dwindled to 165 attendees in Santa Clara in 2024—even as we had over 4,000 people attend all USENIX conferences in 2024. USENIX recognizes the pivotal role that USENIX ATC has played in the shaping of the Association itself as well as the lives and careers of its many attendees and members. We also realize that change is inevitable, and all good things must come to an end: if it weren't for ATC being a "victim of its own great success"—a foundry of so many other successful conferences and workshops—USENIX would never have grown and expanded so much over the decades. Thus our hearts are heavy as we celebrate ATC's history and legacy alongside the evolution of its younger siblings and face the financial realities of the post-pandemic world and volatile global economy. USENIX's resources to support its conferences and communities are not unlimited, particularly as we maintain our commitment to open-access publications that are free for our authors to publish. We have been reporting about these challenges via our Annual Meeting and subsequent reports for the past several years (2024 , 2023 , 2022 , 2021 , 2020 ). We deeply appreciate the financial support we have received from our community in the form of donations, memberships, and conference registrations. However, we continue to operate at a deficit and ATC continues to shrink. In making this hard choice, accepting the reality in front of us that encourages us to innovate in a different direction under challenging circumstances, we seek to embody the values of this community that was founded on curiosity, persistence, and collaboration. As we celebrate 50 years of both USENIX and ATC in its varying forms, we look towards the future of this vibrant community in the form of the many conferences that ATC continues to help create in its image: welcoming, thoughtful environments for the presentation of innovative work that fellow conference attendees help push forward. We look forward to honoring ATC's legacy alongside USENIX's history and its future in Boston in July of 2025. We would love to hear memories of your experience at the USENIX Annual Technical Conference over the years. Please submit your thoughts in words, video, or both by *Monday, June 2*. We will share your memories both at USENIX ATC '25 and afterwards. We hope that you will join us at USENIX ATC '25 , which will include both a celebration of USENIX's 50th anniversary on the evening of *Monday, July 7*, and a tribute to USENIX ATC on the evening of *Tuesday, July 8*. [image: Casey Henderson headshot] Best Regards, Casey Henderson-Ross Executive Director USENIX Association About this mailing list: You are receiving this email because you are or have been a member of USENIX, have attended USENIX conferences, or have signed up to receive emails from USENIX. USENIX never shares, sells, rents, or exchanges email addresses of its members, conference attendees, and other constituents. Review our privacy policy . We would like to continue sending you occasional email announcements like this one. However, if you no longer want to receive emails from USENIX, please click here to opt out of all communications from USENIX. If you have any questions about the mailing list, please email info at usenix.org. We may also be reached via postal mail: USENIX Association 2443 Fillmore St, #380-25600, San Francisco, CA 94115-1814, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed May 7 12:11:26 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Tue, 6 May 2025 19:11:26 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: References: Message-ID: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> On 5/6/25 15:52, Dan Cross wrote: > I just heard that, after ATC'25, USENIX will be sunsetting the annual > technical conference: this will apparently be the last one. > > I can't find any reference for it, though, and the web site mentions > ATC'26 in Seattle? See https://www.usenix.org/blog/usenix-atc-announcement -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From lm at mcvoy.com Wed May 7 12:55:26 2025 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 6 May 2025 19:55:26 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> Message-ID: <20250507025526.GC17185@mcvoy.com> On Tue, May 06, 2025 at 07:11:26PM -0700, Alan Coopersmith via TUHS wrote: > On 5/6/25 15:52, Dan Cross wrote: > >I just heard that, after ATC'25, USENIX will be sunsetting the annual > >technical conference: this will apparently be the last one. > > > >I can't find any reference for it, though, and the web site mentions > >ATC'26 in Seattle? > > See https://www.usenix.org/blog/usenix-atc-announcement I might regret this in the morning but I'd like to share when Usenix ceased to matter to me. I was the program committee chair for the 1999 Linux Expo which was a Usenix alternative. Before I go on, there is some back story. I reviewed papers for Usenix a bunch. One of the best papers I ever reviewed is this one: http://www.mcvoy.com/lm/papers/rtlmanifesto.pdf It got rejected, not on merit, but because Victor was not in the club, he was an unknown. Rob Gingell, someone I feared and respected, said he rejected it "because it wasn't posix". Not Rob's best day, the whole point was posix couldn't do what Victor did. Read that paper, it did real time right, nobody else has come close to do real time and time sharing. They fight each other. In 1999 when I was going to that conference, Ellie reached out to me and begged me to bring Linux to Usenix. She said I could have whatever I wanted, on the program committee for life, whatever I wanted. I asked for blind peer reviews. She said no. I used to love Usenix, I've written papers that were published there, but Usenix is dead to me. They did it to themselves. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From yuyi15968 at gmail.com Thu May 8 18:34:01 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Thu, 8 May 2025 16:34:01 +0800 Subject: [TUHS] Ken Thomson's email address? Message-ID: Oh, sorry guys, please forgive me for the off-topic question. I was wondering if anyone knows Ken Thomson's email address? I was wondering if he has any more archives of Unix from 1972 and before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu May 8 20:14:34 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 06:14:34 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508101434.3431818C084@mercury.lcs.mit.edu> > From: Jackson Helie G > I was wondering if anyone knows Ken Thomson's email address? I was > wondering if he has any more archives of Unix from 1972 and before. He does read this ist, and very occasionally posts to it. But there's no point bothering him, to ask; anything he had, he turned over many years ago. (To the point that people have recently been poring through the 'trash' bits in the "s1-bits" and s2-bit" tapes, IIRC, for lack of anything else to look at. Look for "A Census of /etc and /sys Prior to V4" in the TUHS archive to see some discussion of some of this work, by Matt Gilmore. I think somene else was working on it too, but I couldn't find it; I'm not up for looking through TUHS archives for it.) Noel From yuyi15968 at gmail.com Thu May 8 20:58:50 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Thu, 8 May 2025 18:58:50 +0800 Subject: [TUHS] Ken Thomson's email address? Message-ID: If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu May 8 22:13:26 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 08:13:26 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508121326.3163918C085@mercury.lcs.mit.edu> > From: Jackson Helie G > I would like to ask Ken Thompson if he has the first C compiler. He wouldn't; he didn't do much work on C. Dennis Ritchie (who created C) posted two very early ones here: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html Noel From clemc at ccc.com Thu May 8 23:42:00 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 May 2025 09:42:00 -0400 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: Message-ID: On Thu, May 8, 2025 at 6:59 AM Jackson Helie G wrote: > If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson > if he has the first C compiler. > The first "C" compiler wa an ephemeral state some time in the process of its evolution. Dennis started with his B implementation and began to add features he needed to support their new byte addressed PDP-11. He originalled called it nb or "new B." The compiler accepted the B syntax and new extensions for the new features. Eventually, the new feature started to make the language different enough the language became something he called C. At what time what was, I'm not sure I've ever heard anyone ever declare and definitive time or date. Look in https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ And start poking if you want to see early versions of the compiler. Have fun Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri May 9 00:04:31 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 May 2025 10:04:31 -0400 (EDT) Subject: [TUHS] Ken Thomson's email address? Message-ID: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> > From: Clem Cole > The first "C" compiler wa an ephemeral state some time in the process > of its evolution. Dennis started with his B implementation and began to > add features he needed See: The Development of the C Language https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html for detail on the evolution. Noel From clemc at ccc.com Fri May 9 00:22:10 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 May 2025 10:22:10 -0400 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: Thanks, Noel. I should have pointed to that paper also. I have always considered the demarcation point when structures were added, but I darned if I knew at what date or time Dennis chose to rename it. Clearly, one day (night, more likely), he realized it nb was really not B anymore and needed a new name. ᐧ On Thu, May 8, 2025 at 10:04 AM Noel Chiappa wrote: > > From: Clem Cole > > > The first "C" compiler wa an ephemeral state some time in the process > > of its evolution. Dennis started with his B implementation and began > to > > add features he needed > > See: > > The Development of the C Language > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > for detail on the evolution. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri May 9 04:59:46 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 May 2025 18:59:46 +0000 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: On Thursday, May 8th, 2025 at 7:23 AM, Clem Cole wrote: > Thanks, Noel. I should have pointed to that paper also. I have always considered the demarcation point when structures were added, but I darned if I knew at what date or time Dennis chose to rename it. Clearly, one day (night, more likely), he realized it nb was really not B anymore and needed a new name. > ᐧ > > On Thu, May 8, 2025 at 10:04 AM Noel Chiappa wrote: > > > > From: Clem Cole > > > > > The first "C" compiler wa an ephemeral state some time in the process > > > of its evolution. Dennis started with his B implementation and began to > > > add features he needed > > > > See: > > > > The Development of the C Language > > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > > > for detail on the evolution. > > > > Noel For the record another source of old C compiler code would be in the s1/s2 tapes here: https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ I'm not in a place to dig into them right now but one of the two tapes is a V2 root filesystem backup, the C compiler should be in a couple stages in /lib. Granted, its binary, but with enough disassembly work and comparison with other sources, it may be possible to recreate a compelling facsimile of whatever revision that represents. Otherwise as others have stated, the historic C compiler situation has been quite well plundered by this and other groups, supplemented of course by Dennis Ritchie's foresight to keep and provide so many artifacts and anecdotes. - Matt G. From mrochkind at gmail.com Fri May 9 05:38:19 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 8 May 2025 13:38:19 -0600 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: Seems that the subject line of this thread should be changed. Marc On Thu, May 8, 2025 at 1:00 PM segaloco via TUHS wrote: > On Thursday, May 8th, 2025 at 7:23 AM, Clem Cole wrote: > > > Thanks, Noel. I should have pointed to that paper also. I have always > considered the demarcation point when structures were added, but I darned > if I knew at what date or time Dennis chose to rename it. Clearly, one day > (night, more likely), he realized it nb was really not B anymore and needed > a new name. > > ᐧ > > > > On Thu, May 8, 2025 at 10:04 AM Noel Chiappa > wrote: > > > > > > From: Clem Cole > > > > > > > The first "C" compiler wa an ephemeral state some time in the process > > > > of its evolution. Dennis started with his B implementation and began > to > > > > add features he needed > > > > > > See: > > > > > > The Development of the C Language > > > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > > > > > > for detail on the evolution. > > > > > > Noel > > For the record another source of old C compiler code would be in > the s1/s2 tapes here: > https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ > > I'm not in a place to dig into them right now but one of the two > tapes is a V2 root filesystem backup, the C compiler should be > in a couple stages in /lib. Granted, its binary, but with > enough disassembly work and comparison with other sources, it > may be possible to recreate a compelling facsimile of whatever > revision that represents. > > Otherwise as others have stated, the historic C compiler > situation has been quite well plundered by this and other > groups, supplemented of course by Dennis Ritchie's foresight to > keep and provide so many artifacts and anecdotes. > > - Matt G. > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri May 9 11:42:59 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 9 May 2025 11:42:59 +1000 Subject: [TUHS] Old C compilers (was: Ken Thomson's email address?) In-Reply-To: References: <20250508140431.1CC4518C084@mercury.lcs.mit.edu> Message-ID: On Thursday, 8 May 2025 at 13:38:19 -0600, Marc Rochkind wrote: > On Thu, May 8, 2025 at 1:00 PM segaloco via TUHS wrote: > >> >> For the record another source of old C compiler code would be in >> the s1/s2 tapes here: >> https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/ >> >> I'm not in a place to dig into them right now but one of the two >> tapes is a V2 root filesystem backup, the C compiler should be >> in a couple stages in /lib. Granted, its binary, but with >> enough disassembly work and comparison with other sources, it >> may be possible to recreate a compelling facsimile of whatever >> revision that represents. Years ago (February 2000) I got the sources of a 1972 C compiler that I was able to compile and run on FreeBSD. The tarball should be called last1120c.tar.gz . I assume that I got it from the TUHS archive, but if you can't find it, let me know. > Seems that the subject line of this thread should be changed. Agreed. You, too, could have done this. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri May 9 13:32:41 2025 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 8 May 2025 22:32:41 -0500 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: References: Message-ID: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> On 5/2/25 7:21 AM, Aharon Robbins wrote: > 1. Practical UNIX & Internet Security, 3rd edition, by Simson > Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, > Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: > 978-0596003234. ... > One of my reviewers asked if these weren't "dusty references". So, > before I just refer to them as "classics", can anyone recommend more > recent books? Feel free to answer in private. Having read (most of) Practical UNIX & Internet Security, 3rd edition, and other similar texts... I've come to the realization that we as an industry haven't really moved beyond all of the problems taught to us in the '90s. It's really amazing to me how much of the advice given in those "classic" tombs is still as germane today as it was 30 years ago. Sure, some things have fallen off the bottom. But mostly, we've just added things on top. Fundamentals may get old, but they usually don't become wrong. -- Grant. . . . From arnold at skeeve.com Fri May 9 16:19:47 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 09 May 2025 00:19:47 -0600 Subject: [TUHS] Off topic: Books on Unix security? In-Reply-To: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> References: <25817610-b135-4c10-87ec-2d4a9d42523e@spamtrap.tnetconsulting.net> Message-ID: <202505090619.5496JlsM2032047@freefriends.org> Hi. Grant Taylor via TUHS wrote: > Having read (most of) Practical UNIX & Internet Security, 3rd edition, > and other similar texts... > > I've come to the realization that we as an industry haven't really moved > beyond all of the problems taught to us in the '90s. Sad, but true. > It's really > amazing to me how much of the advice given in those "classic" tombs is Um, "tomes" is what I think you meant. :-) > still as germane today as it was 30 years ago. > > Sure, some things have fallen off the bottom. But mostly, we've just > added things on top. > > Fundamentals may get old, but they usually don't become wrong. This last statement is exactly right. And in fact, it is my book on the fundamental *nix APIs that I'm updating.... Feel free to ping me privately if you want more info. Much thanks, Arnold P.S. Can I quote your statement? From yuyi15968 at gmail.com Sun May 11 20:28:25 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Sun, 11 May 2025 18:28:25 +0800 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: I checked Dennis M. Ritchie's "Users' Reference to B" and found an example of implementing a B program at the bottom of the manual. It said that bc generates intermediate code suitable for ba, and then ba generates assembly code. So, I am curious about what the intermediate code generated by bc is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjteixeira at earthlink.net Mon May 12 01:06:19 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Sun, 11 May 2025 11:06:19 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: Message-ID: On 5/11/25 6:28 AM, Jackson Helie G wrote: > I checked Dennis M. Ritchie's "Users' Reference to B" and found an > example of implementing a B program at the bottom of the manual. It > said that bc generates intermediate code suitable for ba, and then ba > generates assembly code. So, I am curious about what the intermediate > code generated by bc is? I found this reference (https://www.softwarepreservation.org/projects/BCPL/cambridge/Richards-Bootstrapping_BCPL-1973.pdf) written by Martin Richards about the intermediate code of BCPL. I never saw or used B, but this is one possibility. But it seems very different from C compilers prior to the Portable C Compiler, even though code generation was table driven (https://wolfram.schneider.org/bsd/7thEdManVol2/ctour/ctour.html). Note, before the RTS group at Project MAC started using UNIX, we had a home-written operating system for PDP-11/45 and PDP-11/70. I got a BCPL compiler from somewhere and made some enhancements - such as direct support for external variables and routines using a linker rather than the pure BCPL global array. When RTS got access to a VAX-11/780 running VMS, I was able to modify the Sixth or Seventh edition C compiler to generate code for the VAX-11/780 and wrote enough of a compatibility library to port various C programs to VMS. All that vanished once we were able to install 4BSD on the VAX-11/780. The machine was shared by the people doing the NIL project (New Implementation of LISP) on the VAX. I don't remember the details, but this paper coauthored by Guy Steele (https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf) implies that NIL shifted their efforts to a different target machine: "In 1978, Gabriel and Guy Steele set out to implement NIL [Brooks, 1982a] on the S-1 Mark IIA, a supercomputer being designed and built by the Lawrence Livermore National Laboratory [Correll, 1979; Hailpern, 1979]." -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon May 12 16:26:15 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 06:26:15 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: Message-ID: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> On May 11, 2025, at 03:28, Jackson Helie G wrote: > I am curious about what the intermediate code generated by bc is? Hi, I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in reconstructing B, which is probably the most extensive and faithful to the original. He’s written B compilers[0] in C for bootstrapping purposes, another in B, and reconstructed one in B which works on Unix V1. The intermediate code I think you’re referring to is the threaded code, which Angelo covers on his site[1], from having reverse engineered libb and bilib. There was some discussion on this list about it some years ago[2]. His work is probably the best resource. [0]: https://github.com/aap/b [1]: http://squoze.net/B/ [2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html Thalia From tuhs at tuhs.org Mon May 12 17:00:16 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 07:00:16 +0000 Subject: [TUHS] Unix Reverse Engineering Message-ID: <333C42E6-1B13-489C-919C-B496BDD2340B@archibald.dev> Hello everyone, I'm working on building a decompiler from PDP-11 assembly to C to ease studying old pre-C Unix sources. To start, I'm translating V5 `as` to period-idiomatic C and have finished most of pass 1. Then I'll port it to Rust with a design better suited to static analysis, while keeping exact fidelity to the original. I'll do the same for `cc` and `ld`, after. I stumbled upon Warren's disaout[0] today, which made me wonder: What tools have people for reverse engineering Unix assembly sources or a.out binaries? Things like disassemblers or decompilers. I assume there's some versions of programs which are now only extant as binaries? Are there enough such binaries that were written in C to warrant writing a decompiler that understands the specific codegen of `cc` to improve accuracy? For now, I'm focusing on decompiling hand-written assembly, but I'm keeping this case in mind. Thanks! Thalia [0]: https://github.com/DoctorWkt/unix-jun72/tree/master/tools/disaout From aap at papnet.eu Mon May 12 17:14:14 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 12 May 2025 09:14:14 +0200 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> Message-ID: Hi, thanks for mentioning my project! I recently ported the compiler to ITS on the PDP-10 and had to revisit the question of the intermediate code. My take is that it was probably an ASCII code and not all too different from PDP-7 assembly. One striking difference between the PDP-7 and PDP-11 interpreter that have survived is the handling of lvalues. Taking the address of something is done by an operator (u1) in the PDP-7 interpreter, whereas on the PDP-11 this is handled somewhere in the compilation process, and in addition to the automatic (a) and external (x) operators there are now lvalue versions of them (va and vx). I very very strongly suspect that this is handled by the B assembler and not the compiler. Two other questions are where the 'i'-versions of the a/x/c operators and the control flow of the conditional ?: operator were handled. For the latter i concluded it had to be the assembler, although the label numbers in printf.o are in line with those that would have been generated by the compiler. In contrast, the first and second pass of the C compiler use different ranges of labels. Unfortunately all these questions appeared and became clearer only over time and as a result there are various incarnations of my reconstructed compiler in the github repo....I should really make a push to clean it up a bit better, it's a complete mess. You may also want to check out my talk on B at VCFB 2024: https://www.youtube.com/watch?v=OLDTPlLa1bI Cheers, aap On 12/05/25, Thalia Archibald via TUHS wrote: > On May 11, 2025, at 03:28, Jackson Helie G wrote: > > I am curious about what the intermediate code generated by bc is? > > > Hi, > > I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in > reconstructing B, which is probably the most extensive and faithful to the > original. He’s written B compilers[0] in C for bootstrapping purposes, another > in B, and reconstructed one in B which works on Unix V1. The intermediate code I > think you’re referring to is the threaded code, which Angelo covers on his > site[1], from having reverse engineered libb and bilib. There was some > discussion on this list about it some years ago[2]. His work is probably the > best resource. > > [0]: https://github.com/aap/b > [1]: http://squoze.net/B/ > [2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html > > Thalia From tuhs at tuhs.org Mon May 12 18:10:59 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 08:10:59 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> Message-ID: <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> On May 12, 2025, at 00:14, Angelo Papenhoff wrote: > thanks for mentioning my project! > I recently ported the compiler to ITS on the PDP-10 and had to revisit > the question of the intermediate code. > My take is that it was probably an ASCII code and not all too different > from PDP-7 assembly. Very interesting! Is your take on the intermediate code the cases in pdp10_its/ba10.b:cexpr? In your compilers, you hack in preprocessing with sed. Do you know for sure that B had no preprocessor? It seems inconceivable now, as even `as` had constants. > You may also want to check out my talk on B at VCFB 2024: > https://www.youtube.com/watch?v=OLDTPlLa1bI I just watched your talk. Now the B intermediate language makes a lot more sense and I want to write a B compiler :). Have you done any further archaeology work on NB since what you have at ? How did you analyze the old tapes? Is there anything left there to examine? Thalia From jnc at mercury.lcs.mit.edu Mon May 12 20:58:43 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 06:58:43 -0400 (EDT) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> > From: Tom Teixeira > before the RTS group at Project MAC (Called the DSSR group at that point om time, if anyone wants to look anything up.) > I got a BCPL compiler from somewhere and made some enhancements - such > as direct support for external variables and routines using a linker > rather than the pure BCPL global array. This entire toolchain, including all the source, has been preserved; the BCPL compiler, the linker ('bind', itself written in BCPL), and a number of tools (including an extra one, 'ldrel', written by the CSR group on the 5th floor). I have in the past put up some pieces for download, but I never got around to doing the whole thing, as there didn't seem to be any interest. We (CSR) started working with the toolchain because it included support for MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler source as output). That toolchain used a relocatable formet, .rel': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5 that I think was based on one DEC had done. CSR was working with a semi-real-time operating system, called 'MOS': https://gunkies.org/wiki/MOS_operating_system for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work on the Internet; e.g. all the BBN 'core' routers used in the early Internet used it, after the very first ones [written in BCPL, oddly enough], which had used ELF: https://gunkies.org/wiki/ELF_operating_system but BBN soon switched to MOS.) MOS was written in MACRO-11; we started working with MOS with the same toolchain SRI had used for it, which ran on TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So, we started working with the MACRO-11, and bind, on UNIX. I then decided I'd rather write code for our PDP-11 packet switches in this nifty language called C, used on UNIX, which nobody else knew about (at that point). The first step was to write 'ldrel', to convert a.out files (produced by the C compiler) to .rel files, so 'bind' could work with them. After a while, we decided we'd rather use 'ld' as our linker (I think because it supported demand loading from binary libraries, so we didn't have to manually specify every file to link). The DSSR group had long ago written 'relld', which converted .rel files (produced by MACRO-11) to a.out files, so that was pretty easy. There seems to be a version of the BCPL compiler which produces 8080 code. It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C compiler was not done at MIT). (I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and they seem to have done a lot of work with various micros. It may not have all the pieces it needs to work, though; it seems to need "/usr/simulators/s6502/s6502.body" from the DSSR machine.) Pity I didn't save a dump of that machine too; I was once looking for the source of the Algol interpreter, written on the Delphi machine, and made to run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine still existed, and he thought not. So we have the binary of that Algol interpreter, but not the source. Of course, it was probably written in MACRO-11, so a disassembler would produce a reasonable facsimile. And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the MIT archives - they might well have done, and Prof. Ward just didn't know that. Noel From jnc at mercury.lcs.mit.edu Mon May 12 21:04:14 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 07:04:14 -0400 (EDT) Subject: [TUHS] Unix Reverse Engineering Message-ID: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> > From: Thalia Archibald > I'm working on building a decompiler from PDP-11 assembly to C to ease > studying old pre-C Unix sources. To start, I'm translating V5 `as` to > period-idiomatic C That's going to be a real trick; 'as' was written in PDP-11 assembler: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/as Noel From tuhs at tuhs.org Mon May 12 22:48:51 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 May 2025 12:48:51 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> Message-ID: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> On May 12, 2025, at 04:04, Noel wrote: > That's going to be a real trick; 'as' was written in PDP-11 assembler: It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 lines or 7/20 files in my translation of `as` to C. It seems that it was never ported to C by the original authors, so this is probably the most closely someone’s looked at many parts of it in a long time. I’ve very steadily been improving my PDP-11 assembly skills and rather efficient now. It’s quite tedious tracking all the register effects, though good signatures annotated with in- and out-registers helps a lot. I feel like a compiler, manually performing control flow structuring like the Relooper or LLVM Stackifier algorithms. With this completed, my manual effort will bootstrap reverse engineering the rest with a proper decompiler. Thalia From lars at nocrew.org Mon May 12 23:38:52 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 12 May 2025 13:38:52 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon, 12 May 2025 06:58:43 -0400 (EDT)") References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> Message-ID: <7wsela0x03.fsf@junk.nocrew.org> Noel Chiappa writes: > And I should ask Lars if the backup tapes of the DSSR/RTS machine went > to the MIT archives - they might well have done, and Prof. Ward just > didn't know that. They might. There are thousands of tapes, most of which are from ITS or TOPS-20. But that still leaves room for hundreds of Unix tar, dump, and cpio tapes in various interesting 16/32-bit and big/little endian combinations. I'm guessing they are 4BSD, Sun, and maybe PDP-11 formats. I haven't taken the time to go through them; in many cases modern tools don't work, so I have to make my own. A propos Teixeira's message, there are also VMS tapes with NIL. From aek at bitsavers.org Mon May 12 23:42:37 2025 From: aek at bitsavers.org (Al Kossow) Date: Mon, 12 May 2025 06:42:37 -0700 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <7wsela0x03.fsf@junk.nocrew.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> Message-ID: <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> On 5/12/25 6:38 AM, Lars Brinkhoff wrote: > Noel Chiappa writes: >> And I should ask Lars if the backup tapes of the DSSR/RTS machine went >> to the MIT archives - they might well have done, and Prof. Ward just >> didn't know that. > What was the name of the system(s)? A complication is MIT, being MIT, used their own backup tape format on some of their Unix systems. From tjteixeira at earthlink.net Tue May 13 00:52:11 2025 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Mon, 12 May 2025 10:52:11 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> <2240f862-2dc4-2268-387d-d90d0cd7a360@bitsavers.org> Message-ID: On 5/12/25 9:42 AM, Al Kossow wrote: > On 5/12/25 6:38 AM, Lars Brinkhoff wrote: >> Noel Chiappa writes: >>> And I should ask Lars if the backup tapes of the DSSR/RTS machine went >>> to the MIT archives - they might well have done, and Prof. Ward just >>> didn't know that. >> > > What was the name of the system(s)? > > A complication is MIT, being MIT, used their own backup tape format > on some of their Unix systems. > Delphi was the home-written time-sharing system for the PDP-11/45 I referred to. It would have had some home-written backup tape format. I'm not sure if it was backed up to tape, or just to duplicate RK05 packs. In addition to Steve Ward, Chris Terman may remember something about the Delphi system and backups. From arnold at skeeve.com Tue May 13 01:09:37 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 12 May 2025 09:09:37 -0600 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <7wsela0x03.fsf@junk.nocrew.org> References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> Message-ID: <202505121509.54CF9bCx2302958@freefriends.org> Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes are in there? Arnold Lars Brinkhoff wrote: > Noel Chiappa writes: > > And I should ask Lars if the backup tapes of the DSSR/RTS machine went > > to the MIT archives - they might well have done, and Prof. Ward just > > didn't know that. > > They might. There are thousands of tapes, most of which are from ITS or > TOPS-20. But that still leaves room for hundreds of Unix tar, dump, and > cpio tapes in various interesting 16/32-bit and big/little endian > combinations. I'm guessing they are 4BSD, Sun, and maybe PDP-11 > formats. I haven't taken the time to go through them; in many cases > modern tools don't work, so I have to make my own. > > A propos Teixeira's message, there are also VMS tapes with NIL. From f4grx at f4grx.net Tue May 13 01:21:28 2025 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Mon, 12 May 2025 17:21:28 +0200 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> References: <1166DA21-F799-463B-8F87-B18AE907D963@archibald.dev> <4B6B3474-ACFE-4EF8-8541-3A84EF0C63E0@archibald.dev> Message-ID: <4d76f0f5-5b57-4167-b514-6ff660c54adc@f4grx.net> Hello, On 12/05/2025 10:10, Thalia Archibald via TUHS wrote: > I just watched your talk. Now the B intermediate language makes a lot more sense > and I want to write a B compiler :). I did that, it was fun. I did a recursive descent parser (from scratch, so without yacc), and made it generate some C code. From a practical aspect, having tasted C for years, I find B quite annoying and pointless outside the gigantic historical interest. Sebastien From jnc at mercury.lcs.mit.edu Tue May 13 02:21:26 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 12 May 2025 12:21:26 -0400 (EDT) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? Message-ID: <20250512162126.A078918C077@mercury.lcs.mit.edu> > From: Al Kossow > What was the name of the system(s)? >From an early 'hosts' file: HOST MIT-RTS, [CHAOS 470,LCS 10/11],SERVER,UNIX,PDP11,[RTS,DSSR] I'd rather depend on that, than on my memory! (The names at the end are aliases.) While I was looking for a really early host file (I recall our early TFTP command had one; I don't think it was built into the command, but it might have been),~p I found a /jnk directory in MIT-CSR's root; it had a lot of interesting stuff in it. One particularly interesting one was 'kov': The idea of this kernel overlay scheme is to increase the amount of code that can be included in the UNIX kernel. This is done by reserving one of the I space segmentation registers (the highest free, usually KISA5 for non-split systems) and changing its value dynamically so as to map in the appropriate code as needed. I chose to use only one page register (limiting each KOV to 4Kw), in order to minimize the mapping overhead. I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 (and later BSD's)? That stuff is all poorly documented, and I'm not up for poring through both to compare them. This one was all done by Ken Harrenstien (KLH). Noel From lars at nocrew.org Tue May 13 03:03:28 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 12 May 2025 17:03:28 +0000 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <202505121509.54CF9bCx2302958@freefriends.org> (arnold@skeeve.com's message of "Mon, 12 May 2025 09:09:37 -0600") References: <20250512105843.BEA6118C077@mercury.lcs.mit.edu> <7wsela0x03.fsf@junk.nocrew.org> <202505121509.54CF9bCx2302958@freefriends.org> Message-ID: <7wmsbh223j.fsf@junk.nocrew.org> arnold at skeeve.com wrote: > Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes > are in there? Sorry, I really can't say. From tuhs at tuhs.org Tue May 13 04:36:55 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 May 2025 18:36:55 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: On Monday, May 12th, 2025 at 5:49 AM, Thalia Archibald via TUHS wrote: > On May 12, 2025, at 04:04, Noel wrote: > > > That's going to be a real trick; 'as' was written in PDP-11 assembler: > > > It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 > lines or 7/20 files in my translation of `as` to C. It seems that it was never > ported to C by the original authors, so this is probably the most closely > someone’s looked at many parts of it in a long time. > > I’ve very steadily been improving my PDP-11 assembly skills and rather efficient > now. It’s quite tedious tracking all the register effects, though good > signatures annotated with in- and out-registers helps a lot. I feel like a > compiler, manually performing control flow structuring like the Relooper or LLVM > Stackifier algorithms. With this completed, my manual effort will bootstrap > reverse engineering the rest with a proper decompiler. > > Thalia Not sure how helpful it'd be, but pdp11-dec-aout is a valid target for GNU binutils as of the current version, so objdump may be another disassembler/analyzer option. If it helps, here's some stalled-out work on disassembling V2 commands: https://gitlab.com/segaloco/v2src Do you have a particular end-goal in mind or is it just an exercise? - Matt G. From henry.r.bent at gmail.com Tue May 13 05:13:26 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 12 May 2025 15:13:26 -0400 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: On Mon, 12 May 2025 at 14:37, segaloco via TUHS wrote: > > Do you have a particular end-goal in mind or is it just an exercise? > > - Matt G. Learning from the past is wonderful. Reliving it is just cosplay. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Tue May 13 09:58:56 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 13 May 2025 01:58:56 +0200 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: Check v10's cmd/PDP11/11as source Cheers, aap On 12/05/25, Thalia Archibald via TUHS wrote: > On May 12, 2025, at 04:04, Noel wrote: > > That's going to be a real trick; 'as' was written in PDP-11 assembler: > > It has, indeed, been quite the challenge to translate. I’ve completed 1114/3531 > lines or 7/20 files in my translation of `as` to C. It seems that it was never > ported to C by the original authors, so this is probably the most closely > someone’s looked at many parts of it in a long time. > > I’ve very steadily been improving my PDP-11 assembly skills and rather efficient > now. It’s quite tedious tracking all the register effects, though good > signatures annotated with in- and out-registers helps a lot. I feel like a > compiler, manually performing control flow structuring like the Relooper or LLVM > Stackifier algorithms. With this completed, my manual effort will bootstrap > reverse engineering the rest with a proper decompiler. > > Thalia From tuhs at tuhs.org Tue May 13 19:46:00 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 13 May 2025 09:46:00 +0000 Subject: [TUHS] Unix Reverse Engineering In-Reply-To: References: <20250512110414.77BFA18C077@mercury.lcs.mit.edu> <9B29CCBD-BC91-4DC7-A189-057DECC1AD39@archibald.dev> Message-ID: <0215662D-1A66-4823-8E4B-6144CFF4DDFE@archibald.dev> aap wrote: > Check v10's cmd/PDP11/11as source Thanks for the pointer! I've now surveyed all the distributions in the TUHS Unix Tree and that's indeed the most interesting one. The V10 PDP-11 `as` and Jay Jaeger's MXAS[0] port of Mini-Unix `as` to DOS are the only translations of PDP-11 `as` to C and they both look to be faithful translations, though I haven't reviewed them in depth yet. Do you know any more about the background of the V10 PDP-11 `as`? It's a cross-assembler on VAX and its Makefile indicates it was written by John F. Reiser. According to Wikipedia, he did much of the work for Unix/32V, including writing its VAX assembler ported from Interdata 8/32 Unix. Unfortunately, the Interdata 8/32 port is not in the TUHS tree (though the unrelated 7/32 port is). Thalia [0]: https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/mxas.tar.gz From clemc at ccc.com Wed May 14 07:02:58 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 May 2025 17:02:58 -0400 Subject: [TUHS] The Official Announcement WRT the USENIX Annual Technical Conference Message-ID: Casey Henderson-Ross is the ED of USENIX. Since the list would not accept her message, she asked me, as a former President, to send this to folks on the TUHS mailing list. ------------------------------- Folks, As you may already be aware, today we made an important announcement about the USENIX Annual Technical Conference via our mailing list. We want to share this news with you directly as well in case you do not currently receive USENIX email. Please read the statement in its entirety here: https://www.usenix.org/blog/usenix-atc-announcement If you don't know me, I've served on the USENIX staff since 2002 and have had the privilege of serving as Executive Director since 2012. USENIX and the Annual Technical Conference are both dear to me as I know they are to many of you. This is difficult news to share even as we're grateful to be celebrating 50 years of USENIX this year. I hope that you'll share your memories via the form mentioned in the statement and that we'll also see many of you at USENIX ATC '25 in Boston in July: https://www.usenix.org/conference/atc25 If you'd like to contribute to activities there, please contact me directly. Thanks to all of you for honoring the history of UNIX and for your support of USENIX and ATC (in its different names and forms) over the decades. Best, Casey Henderson-Ross ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed May 14 07:58:07 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 May 2025 17:58:07 -0400 Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512162126.A078918C077@mercury.lcs.mit.edu> References: <20250512162126.A078918C077@mercury.lcs.mit.edu> Message-ID: On Mon, May 12, 2025 at 12:21 PM Noel Chiappa wrote: > > I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 > (and > later BSD's)? > Unlikely. The BSD overlay stuff was based on Fred Cantor work at DEC in the TIG group in Merrimack, NH that did V7m and later Ultrix11. Fred's code works on 11/40 as well as 11/45 class processors, where as by the time of 2.11BSD they dropped the 11/40 support. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed May 14 09:05:17 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 May 2025 09:05:17 +1000 (EST) Subject: [TUHS] What is the intermediate code generated by the bc interpreter? In-Reply-To: <20250512162126.A078918C077@mercury.lcs.mit.edu> References: <20250512162126.A078918C077@mercury.lcs.mit.edu> Message-ID: On Mon, 12 May 2025, Noel Chiappa wrote: > I found a /jnk directory in MIT-CSR's root; it had a lot of interesting > stuff in it. One particularly interesting one was 'kov': > > The idea of this kernel overlay scheme is to increase the amount of > code that can be included in the UNIX kernel. This is done by reserving > one of the I space segmentation registers (the highest free, usually > KISA5 for non-split systems) and changing its value dynamically so as > to map in the appropriate code as needed. I chose to use only one page > register (limiting each KOV to 4Kw), in order to minimize the mapping > overhead. Hammering KISA5 on 40-class machines seemed to have been a common trick in those days. For example, the AUSAM buffering scheme at UNSW had a global kernel symbol "b" (analogous to "u") sitting at 100000 (?) that pointed to the current buffer header; you could have as many buffers as physical memory allowed, ending the dreaded buffer-hang problem. -- Dave From tytso at mit.edu Wed May 14 23:33:36 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 14 May 2025 09:33:36 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250507025526.GC17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> Message-ID: <20250514133336.GD9943@mit.edu> On Tue, May 06, 2025 at 07:55:26PM -0700, Larry McVoy wrote: > > I might regret this in the morning but I'd like to share when Usenix > ceased to matter to me. I was the program committee chair for the 1999 > Linux Expo which was a Usenix alternative... > > In 1999 when I was going to that conference, Ellie reached out to me > and begged me to bring Linux to Usenix. She said I could have whatever > I wanted, on the program committee for life, whatever I wanted. > > I asked for blind peer reviews. She said no. I recently came across Bryan Cantrill's relections on the end of Usenix ATC[1], which is well worth the read. It references a number of also musings[2][3][4][5] that are also (in my opinion) very thoughtful, and shows that the tension between practical industry work and academic work is a very old one. [1] https://bcantrill.dtrace.org/2025/05/11/rip-usenix-atc/ [2] https://bcantrill.dtrace.org/2004/07/06/whither-usenix/ [3] https://web.archive.org/web/20081006150917/https://www.allthingsdistributed.com/historical/archives/000482.html [4] https://bcantrill.dtrace.org/2004/07/08/whither-usenix-part-ii/ [5] https://www.usenix.org/system/files/login/articles/login_fall16_01_farrow.pdf One of the interesting observations in [2] was that the program committee for the 2005 Freenix / Open Source program committee was solely from industry, and since I was one of the folks who participated in Freenix Program Committees (although I wasn't on the 2005 Freenix PC), and Bryan's concern that it would be the "dumping ground" for subpar work that wouldn't be accepted at the "big boys table". It's a lot more than that, though. I was at IBM at that time, and at IBM, right about then the bonus for getting for getting published at a conference had gotten eliminated. It was very clear that as far as IBM management was concerned, conference publication didn't matter. If you filed a patent, you would get paid a cash bonus. If you submit to any conference --- you wouldn't. On top of that, writing a good paper that would be accepted at conference where you are competing with academics working full-time trying to get tenure, is a lot of hard work and takes a lot of time. So speaking as a working engineer, you'd have to be especially passionate about writing a paper (perhaps because you came from the academic background), to think it was worth it. Open source made this worse, because if you're not going to get paid by your employer, and won't be given work time to work on a paper, if you're going to have to contribute on your own time, the question then becomes, which is better for your future employability? Publishing a paper, or contributing to an open source project, and then becoming a major contributor to an open source project? Finally, what industry conferences run by organizations like the Linux Foundation optimized for the value that most industry players cared about, which is the "hallway track". And that's ultimately what doomed Freenix. Freenix still tried to make people write papers, in the hopes that they could hone their paper-writing skills so they could eventually "graduate" to Usenix. But engineers didn't care about writing papers, and if you could just submit a talk proposal to the Linux Plumbers Conference, which do you think they would choose? If the main reason why you attend, and why your manager would approve your travel expenses, is because you can get face time for the people who will approve your open source contributions (which is what the managers care about), the choice between Freenix and the Ottowa Linux Symposium or Linux Plumbers wasn't even close. All of that being said, it is sad that Usenix ATC is ending. I will admit; I haven't attended in many years, mostly because of time and travel expense constraints. And from a personal perspective, last year, I spent some of my own money (with hotel costs generously covered by the Linux Foundation) to travel and present[6] at the Linux Foundation Members Summit. But could I say that I would spend my own money to attend a Usenix conference? Well, I never have, so probably not. :-/ [6] https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6ZxEAehCpQ/edit#slide=id.p - Ted P.S. Admittedly, the presentation at the LF Members Summit wasn't a technical topic, and the whole point was for me to make a point to executives at companies which use Open Source. From lm at mcvoy.com Thu May 15 00:54:52 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 14 May 2025 07:54:52 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514133336.GD9943@mit.edu> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> Message-ID: <20250514145452.GE17185@mcvoy.com> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: > It's a lot more than that, though. I was at IBM at that time, and at > IBM, right about then the bonus for getting for getting published at a > conference had gotten eliminated. It was very clear that as far as > IBM management was concerned, conference publication didn't matter. > If you filed a patent, you would get paid a cash bonus. If you submit > to any conference --- you wouldn't. That's wild. To the best of my knowledge, Sun didn't give you a bonus for either a paper or a patent, it was just part of the job. I certainly never got a bonus for that stuff. They did pay expenses for conferences but that was it. I personally viewed publishing as part of my resume. I didn't publish very often but when I did, I had something to say. I put a lot of hard work into each paper, I knew if my brain felt sort of constipated but I was still making the words come out, yeah, that was likely to be a good paper. I'd much rather you formed an opinion of my from my papers than my resume. The papers were hard, but that made them more significant than a listing of whatever projects I had worked on. If I were writing papers for a bonus, I dunno, seems like it cheapens the whole idea. I may have a different outlook as my family was pretty academic, Dad was a Rhodes scholar and went to get a physics PhD from Cornell, my brother got a PhD from Cornell, I was the black sheep of the family with a lowly Masters from UW Madison. I had PhD envy and part of the reason I published was to let people know I had something to say. Everyone is different I guess. --lm From sauer at technologists.com Thu May 15 01:21:07 2025 From: sauer at technologists.com (Charles H. Sauer (he/him)) Date: Wed, 14 May 2025 10:21:07 -0500 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <5cca37cf-4790-4a6a-87dc-274c6756939e@technologists.com> On 5/14/2025 9:54 AM, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I certainly > never got a bonus for that stuff. They did pay expenses for conferences > but that was it. IBM did not give bonuses for publishing when I was there (1975-1989), so if that stopped in 2005, it sounds like an aspect of the Gerstner era. IBM when I was there strongly encouraged/rewarded patents, and formally disclosing lesser innovations. There were also significant cash awards for "Outstanding Innovations/Inventions," and annual corporate recognition events celebrating those. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Thu May 15 05:16:04 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 14 May 2025 12:16:04 -0700 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> On 5/14/25 07:54, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I started at Sun after you left, and don't know when they started but patent bonuses were common in the 2000's at Sun. They paid up to $2000/person, with a max of $6000/team, when a patent was filed. (Based on a 2004 slide deck encouraging us to file more patents, I never got one to verify. They did emphasize they wanted patents for defensive reasons, including cross-licensing deals, not to attack other companies.) -alan- From pete at debu.gs Thu May 15 11:03:41 2025 From: pete at debu.gs (Pete) Date: Wed, 14 May 2025 18:03:41 -0700 Subject: [TUHS] Ken Thomson's email address? In-Reply-To: <20250508101434.3431818C084@mercury.lcs.mit.edu> References: <20250508101434.3431818C084@mercury.lcs.mit.edu> Message-ID: <68253D6D.3040602@debu.gs> On 2025年05月08日 03:14, Noel Chiappa wrote: > I'm not up for looking through TUHS archives for it. What I did when I subscribed (thanks, wkt) was download the archives (which are in mbox format), cat them, and then copy the messages to the directory where the TUHS messages are filtered. Took almost no time, but my mail server is in my house. This makes it pretty easy to search the archives locally: you can just use grep or if you have a mail reader with good search features, it's much easier than searching on the server. It looks like there was "A Census of /etc and /sys Prior to V4" on 2023-05-15, and "Census of Early (Pre-C Kernel) UNIX Documents" on 2024-02-14, both from segaloco. (The only downside to importing the mboxes is that the email addresses are tweaked to prevent spam.) That should make it easier to find the threads. Pete From tytso at mit.edu Thu May 15 23:57:06 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 15 May 2025 09:57:06 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <61cc7065-38de-441e-ab80-72f661ddccc7@oracle.com> Message-ID: <20250515135706.GA325737@mit.edu> On Wed, May 14, 2025 at 12:16:04PM -0700, Alan Coopersmith wrote: > I started at Sun after you left, and don't know when they started but > patent bonuses were common in the 2000's at Sun. They paid up to > $2000/person, with a max of $6000/team, when a patent was filed. > (Based on a 2004 slide deck encouraging us to file more patents, > I never got one to verify. They did emphasize they wanted patents for > defensive reasons, including cross-licensing deals, not to attack other > companies.) What I was at IBM, they paid $500/engineer, with a max of $2000/team for a patent being filed, with another $500/engineer if the patent was granted. It was quite common for IBM'ers to set up patent brainstorming teams of 4 people each (to max out the team limit), and the patents did't have to be related to what your department was working on. You could be in the IBM Linux Technology Center, and if you had an idea for something that might be novel in virtual reality, or massive multiplayer online games, or ways that AI could be applied in a health care context, it was all fair game. A particular patent team could be potentially responsible for dozens of patent filings, so it could be real money, especially if you were a relatively underpaid level 5 SWE. (Yeah, it wasn't as a big of a deal if you were a band 10 STSM.) It wasn't formally organized by management, but the fact that these teams exited and the resulting patents were of relatively low quality (in my humble opinion), this couldn't have come as a surprise to them. (From a defensive perspective, quantity was far more important than quality, after all. The patent system is so totaly screwed up....) But as far as papers were concerned, an accepted paper at ATC was worth (at best) brownie points at performance review time, at least in my part of the company. Combine that with the extreme difficulty in getting travel expense approval, it's pretty clear what management really thought about publishing being part of the job. Creating presentations for VP's, or spending all day in Fall Plan meetings justifying budget line items down to the SWE-month granularity? (And then after those plans become totally obsolete once the budget was handed down from on high, then there was Spring Re-plan....) Sure that was definitely part of the job. Publishing papers? Not so much. - Ted From stuff at riddermarkfarm.ca Fri May 16 07:00:28 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 15 May 2025 17:00:28 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <20250514145452.GE17185@mcvoy.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> Message-ID: <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> On 2025-05-14 10:54, Larry McVoy wrote: > On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >> It's a lot more than that, though. I was at IBM at that time, and at >> IBM, right about then the bonus for getting for getting published at a >> conference had gotten eliminated. It was very clear that as far as >> IBM management was concerned, conference publication didn't matter. >> If you filed a patent, you would get paid a cash bonus. If you submit >> to any conference --- you wouldn't. > > That's wild. To the best of my knowledge, Sun didn't give you a bonus > for either a paper or a patent, it was just part of the job. I certainly > never got a bonus for that stuff. They did pay expenses for conferences > but that was it. We may be drifting off topic but my last employer paid $50 per application filed plus $100 per grant. My penultimate employer paid a lousy $1 (minimal required consideration). S. From tuhs at tuhs.org Fri May 16 07:33:36 2025 From: tuhs at tuhs.org (Rod Bartlett via TUHS) Date: Thu, 15 May 2025 17:33:36 -0400 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> Message-ID: <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> U.S. Robotics had the best bonuses for filing patents of any company I've worked for. I think it was $1000 if they decided to file the patent application and another $1000 when it was granted. I also got an all expenses paid trip to Barcelona in 1999 for having filed 2 patents that year. Other companies were not nearly as generous. - Rod > On May 15, 2025, at 5:00 PM, Stuff Received wrote: > > On 2025-05-14 10:54, Larry McVoy wrote: >> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: >>> It's a lot more than that, though. I was at IBM at that time, and at >>> IBM, right about then the bonus for getting for getting published at a >>> conference had gotten eliminated. It was very clear that as far as >>> IBM management was concerned, conference publication didn't matter. >>> If you filed a patent, you would get paid a cash bonus. If you submit >>> to any conference --- you wouldn't. >> That's wild. To the best of my knowledge, Sun didn't give you a bonus >> for either a paper or a patent, it was just part of the job. I certainly >> never got a bonus for that stuff. They did pay expenses for conferences >> but that was it. > > We may be drifting off topic but my last employer paid $50 per application filed plus $100 per grant. My penultimate employer paid a lousy $1 (minimal required consideration). > > S. > From robpike at gmail.com Fri May 16 08:54:31 2025 From: robpike at gmail.com (Rob Pike) Date: Fri, 16 May 2025 08:54:31 +1000 Subject: [TUHS] ATC'25 is the last ATC? In-Reply-To: <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> References: <2e5ee2ad-84b5-4aed-9eda-c9ee7a55e26f@oracle.com> <20250507025526.GC17185@mcvoy.com> <20250514133336.GD9943@mit.edu> <20250514145452.GE17185@mcvoy.com> <43a0a867-522a-f953-c6c5-9be9383a6bd9@riddermarkfarm.ca> <439264E5-E266-4120-A735-0517D7CDB4DA@mac.com> Message-ID: At Bell Labs there was a rumor you got a symbolic dollar when a patent was filed, but it was only a rumor. Nonetheless I mentioned this to PJW who then reached in his wallet and handed me a greenback. Props. -rob On Fri, May 16, 2025 at 7:34 AM Rod Bartlett via TUHS wrote: > U.S. Robotics had the best bonuses for filing patents of any company I've > worked for. I think it was $1000 if they decided to file the patent > application and another $1000 when it was granted. I also got an all > expenses paid trip to Barcelona in 1999 for having filed 2 patents that > year. Other companies were not nearly as generous. > > - Rod > > > On May 15, 2025, at 5:00 PM, Stuff Received > wrote: > > > > On 2025-05-14 10:54, Larry McVoy wrote: > >> On Wed, May 14, 2025 at 09:33:36AM -0400, Theodore Ts'o wrote: > >>> It's a lot more than that, though. I was at IBM at that time, and at > >>> IBM, right about then the bonus for getting for getting published at a > >>> conference had gotten eliminated. It was very clear that as far as > >>> IBM management was concerned, conference publication didn't matter. > >>> If you filed a patent, you would get paid a cash bonus. If you submit > >>> to any conference --- you wouldn't. > >> That's wild. To the best of my knowledge, Sun didn't give you a bonus > >> for either a paper or a patent, it was just part of the job. I > certainly > >> never got a bonus for that stuff. They did pay expenses for conferences > >> but that was it. > > > > We may be drifting off topic but my last employer paid $50 per > application filed plus $100 per grant. My penultimate employer paid a > lousy $1 (minimal required consideration). > > > > S. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat May 17 02:01:39 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 May 2025 16:01:39 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? Message-ID: I'm curious if anyone has the scoop on this. To my knowledge the 1984 /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX standard. AT&T then comes along in 1985 with the first issue of the SVID, based largely on SVR2 from what I know. What I'm not getting a good read on or not is if the SVID was literally a direct response from AT&T to the creation of the /usr/group standard or if there was already an impetus in AT&T's sphere of influence to produce such a definitive document. In either case, AT&T does list the /usr/group standard as an influence, but doesn't go into the detail of "we made this because /usr/group's standard exists" or "we made this ourselves and oh /usr/group also happens to have a standard." Even outside of this, did AT&T maintain anything comparable to the SVID in prior years or was the manual essentially the interface definition? Thanks for any recollections! - Matt G. From clemc at ccc.com Sat May 17 03:57:27 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 May 2025 13:57:27 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: below. On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS wrote: > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor-neutral > UNIX > standard. AT&T then comes along in 1985 with the first issue of the SVID, > based > largely on SVR2 from what I know. > > There was a huge marketing campaign, "*System V. Consider it Standard*." But the >>users<<, particularly those weaned on BSD, said "hardly." /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much less, Sys III/V. SVID came later, and it was an attempt to force it down people's throats. The AT&T folks were sometimes a tad nasty at the POSIX meeting and wanted IEEE to "just use it," and we say, "no. It's incomplete and just plain wrong is so many places." The whole tar/cpio stuff from /usr/group was a great example of the start of it, but even things like trying to define a directory entry was strained. SVID did not have the new UCB directory system calls. For example, we all were certain that if we ever had a different FS, we needed to remove physical formats from the specification. There were no sockets, and yet nearly 100% of the working networking code in the wild, including on MS-DOS, was using sockets. The problem was that several people who came to the POSIX meetings post-SVID from AT&T were from marketing and sales. At the same time, the core of the original /usr/group and later POSIX teams were mostly engineering types. The sales/mktg folks were trying to establish a brand, the engineers were trying to solve an issue were we had code that did not work between our different systems. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Sat May 17 04:16:35 2025 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 16 May 2025 11:16:35 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <1bf9b965-8ec6-43f5-bb16-29c93aafbc3e@osta.com> As the Chair of the /usr/group Standards Committee from its start in 1981 to 1984, I can say that we got all of the major manufacturers of computer hardware running the UNIX operating system involved in this standards effort. This included AT&T, IBM, DEC, HP, Sun, Intel, and many smaller mini-computer and micro-computer hardware vendors. The /usr/group Standard was the starting point for the POSIX 1003.1 standard developed by the IEEE standards organization and first published in 1988.  AT&T was very involved in the development of both standards and would have made every effort to make their operating system to be compatible with the UNIX standards as they were developed over the following years. Details would have to come from AT&T. Heinz On 5/16/2025 9:01 AM, segaloco via TUHS wrote: > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX > standard. AT&T then comes along in 1985 with the first issue of the SVID, based > largely on SVR2 from what I know. > > What I'm not getting a good read on or not is if the SVID was literally a direct > response from AT&T to the creation of the /usr/group standard or if there was > already an impetus in AT&T's sphere of influence to produce such a definitive > document. In either case, AT&T does list the /usr/group standard as an > influence, but doesn't go into the detail of "we made this because /usr/group's > standard exists" or "we made this ourselves and oh /usr/group also happens to > have a standard." > > Even outside of this, did AT&T maintain anything comparable to the SVID in prior > years or was the manual essentially the interface definition? > > Thanks for any recollections! > > - Matt G. From sauer at technologists.com Sat May 17 04:18:43 2025 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 16 May 2025 13:18:43 -0500 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <7637a718-a20b-4016-b46d-b36462c558e2@technologists.com> further below On 5/16/2025 12:57 PM, Clem Cole wrote: > below. > > On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS > wrote: > > I'm curious if anyone has the scoop on this.  To my knowledge the 1984 > /usr/group standard constitutes the earliest attempt at a vendor- > neutral UNIX > standard.  AT&T then comes along in 1985 with the first issue of the > SVID, based > largely on SVR2 from what I know. > > There was a huge marketing campaign, "_/System V. Consider it Standard/ > _." But the >>users<<, particularly those weaned on BSD, said "hardly." > /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much > less, Sys III/V.  SVID came later, and it was an attempt to force it > down people's throats. > The AT&T folks were sometimes a tad nasty at the POSIX meeting and > wanted IEEE to "just use it," and we say, "no.  It's incomplete and just > plain wrong is so many places."    The whole tar/cpio stuff from /usr/ > group was a great example of the start of it, but even things like > trying to define a directory entry was strained.   SVID did not have the > new UCB directory system calls. For example, we all were certain that if > we ever had a different FS, we needed to remove physical formats from > the specification.   There were no sockets, and yet nearly 100% of the > working networking code in the wild, including on MS-DOS, was using > sockets. > > The problem was that several people who came to the POSIX meetings post- > SVID from AT&T were from marketing and sales. At the same time, the > core of the original /usr/group and later POSIX teams were mostly > engineering types.   The sales/mktg folks were trying to establish a > brand, the engineers were trying to solve an issue were we had code that > did not work between our different systems. "Convergence of AIX and 4.3BSD" (https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf) was another alternative to SVID that was intended to address a spectrum of requirements. It was gratifying that AIX people, IBM BSD people and Bruce Walker of LCC were able to reach consensus and put our names on that paper. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Sat May 17 04:22:23 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 May 2025 18:22:23 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: On Friday, May 16th, 2025 at 10:58 AM, Clem Cole wrote: > below. > > On Fri, May 16, 2025 at 12:01 PM segaloco via TUHS wrote: > > > I'm curious if anyone has the scoop on this. To my knowledge the 1984 > > /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX > > standard. AT&T then comes along in 1985 with the first issue of the SVID, based > > largely on SVR2 from what I know. > > There was a huge marketing campaign, "System V. Consider it Standard." But the >>users<<, particularly those weaned on BSD, said "hardly." > /usr/group was an attempt to deal with Ultrix, HP-UX, AIX, and, much less, Sys III/V. SVID came later, and it was an attempt to force it down people's throats. > The AT&T folks were sometimes a tad nasty at the POSIX meeting and wanted IEEE to "just use it," and we say, "no. It's incomplete and just plain wrong is so many places." The whole tar/cpio stuff from /usr/group was a great example of the start of it, but even things like trying to define a directory entry was strained. SVID did not have the new UCB directory system calls. For example, we all were certain that if we ever had a different FS, we needed to remove physical formats from the specification. There were no sockets, and yet nearly 100% of the working networking code in the wild, including on MS-DOS, was using sockets. > > > The problem was that several people who came to the POSIX meetings post-SVID from AT&T were from marketing and sales. At the same time, the core of the original /usr/group and later POSIX teams were mostly engineering types. The sales/mktg folks were trying to establish a brand, the engineers were trying to solve an issue were we had code that did not work between our different systems. > ᐧ Insightful as always Clem, thanks for the background. To me that sounds more like AT&T seeing the horse escaping the barn and trying to ensure they're a relevant part of the conversation, more for the sake of marketing their system and cornering things rather than a good faith attempt to improve and extend the ideas being set forth by the /usr/group effort. Not to discount the good intentions of plenty of folks involved, but that certainly sounds more like a case of "shoot, we should be the arbiter of this information" for the sake of their bottom line. My interpretation anyway. Aside but I recently landed a copy of SVID Issue 1, previously I only had Issue 3 (SVR4 era blue books, 5 volumes) and had seen auctions for Issue 2 that I didn't act on. Issue 1 is published in a nice hard cover, has a more minimalist perspective pattern on the cover than Issue 2 and is only one volume covering the C interface while mentioning future extension efforts such as basic utilities and the like. - Matt G. P.S. While on the subject of SVID, just throwing out there that I have seen auctions for a "Volume VI" in the Issue 3 era. No such volume is referenced in any of the others and the one auction I jumped on never arrived. When pressed on it the seller simply gave me a refund. This has all amounted to doubt that such a volume actually exists, but I've seen at least one grainy photo (because book sellers can't be bothered to show adequate pictures of the books they're selling but expect $$$ anyway) that appeared to show a cover saying "Volume VI" but in typical book seller fashion, it was far too grainy and low resolution to make out any details. In any case, I share this in the hopes someone might be familiar with what I'm talking about and can confirm/deny the existence of a 6th volume in this set. From mrochkind at gmail.com Sat May 17 05:01:27 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 16 May 2025 13:01:27 -0600 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: I was only slightly connected with the development of the POSIX standard, and as has been mentioned here, AT&T was a full participant. The real conflicts were in a related area and at the time were termed The GUI Wars. Basically, it was AT&T and Sun pushing OpenLook and everyone else pushing Motif. I seem to recall that the Motif folks (Open Software Foundation) more or less forced IEEE to just accept Motif as a standard. I was on a different committee that was trying to standardize a universal GUI interface that could work on any GUI, including Mac, Windows, Motif, and OpenLook. My product, XVT, was the base document. We never got past the draft stage. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat May 17 07:45:04 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 May 2025 17:45:04 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: Marc, you are right, but the OpenLook/Motif stuff was >>much<< later. Matt asked about the SVID thing about 5-6 years before that. The problem AT&T had was >>before<< Judge Green, they could not be in the computer biz, so they "*abandoned the sources on your doorstep, with no warranty of any kind.*" It was simply thatAT&T was not allowed to be in the computer business* by law*. Post Judge Green boy did AT&T's management >>want<< to be in the computer biz, and they* tried to use tactics *that had often worked for the largest computer firm to date. In fact, the firm that Charlie Brown [the AT&T CEO] was quoted as saying, he wanted to compete with and emulate IBM. If I recall correctly, he said something about matching them move for move. UNIX had been AT&T's baby, and AT&T wanted it back, but by then, the child had grown up and did not want or need its parent anymore. A lot of the failed actions post Judge Green are part of AT&T searching for a grip in a business its management team did not understand, nor was prepared to be a part of. The assumption was that before the breakup, they were the world's largest company, and even after, the new AT&T was still larger in assets than IBM, so they could compete. History proved otherwise. If they had used different tactics, with the assets AT&T had in its quiver, they might have been able to be a real force. But I think pride made them think that the 3B20 was going to be able to compete with a Mainframe (or even a Vax) — mind you, their own people wanted Vaxen or later Suns. AT&T Management seem to think that UNIX was the key, but AT&T had to be in charge of it. The funny thing, is if AT&T management had taken a zen approach and bolstered what everyone else was doing instead of trying to drive everyone else away [Microsoft's famous "embrace and extend model"], and not tried compete in the processor wars, but instead take on second source licenses and start using their boundary; I something wonder if it might have had a very different out come. They still would have needed to see the PC revolution coming, which I'm not sure management types used to 40-50% gross margin will ever under as 12-15% margin PC market (volume is everything) market. ᐧ On Fri, May 16, 2025 at 3:01 PM Marc Rochkind wrote: > I was only slightly connected with the development of the POSIX standard, > and as has been mentioned here, AT&T was a full participant. > > The real conflicts were in a related area and at the time were termed The > GUI Wars. Basically, it was AT&T and Sun pushing OpenLook and everyone else > pushing Motif. I seem to recall that the Motif folks (Open Software > Foundation) more or less forced IEEE to just accept Motif as a standard. > > I was on a different committee that was trying to standardize a universal > GUI interface that could work on any GUI, including Mac, Windows, Motif, > and OpenLook. My product, XVT, was the base document. We never got past the > draft stage. > > Marc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat May 17 08:19:22 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 16 May 2025 18:19:22 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sat May 17 08:24:27 2025 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Fri, 16 May 2025 15:24:27 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: <67697ba8683df795@orthanc.ca> I think AT&T's real problem was that the post-1984 UNIX business was run by the lawyers. If you look at it, nearly every UNIX-related fuckup on AT&T's part can be directly traced back to the lawyers. If they had only listened to Shakespeare. --lyndon From mrochkind at gmail.com Sat May 17 08:51:08 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 16 May 2025 16:51:08 -0600 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: <67697ba8683df795@orthanc.ca> References: <67697ba8683df795@orthanc.ca> Message-ID: On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyndon at orthanc.ca> wrote: > I think AT&T's real problem was that the post-1984 UNIX business > was run by the lawyers. If you look at it, nearly every UNIX-related > fuckup on AT&T's part can be directly traced back to the lawyers. > > If they had only listened to Shakespeare. > > --lyndon > Hey, you forgot the TM on UNIX! -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Sat May 17 09:33:08 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 16 May 2025 16:33:08 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: <67697ba8683df795@orthanc.ca> Message-ID: <4d568b48-c5d0-5e14-a187-3e19c30e425b@makerlisp.com> Well, this is almost the same thing, but I think of it more as trying to make money off of Unix. We lost the spirit of what made UNIX great when it became about having the standard, dominant, market leading, version, and all that nonsense. We might say first, get rid of all the marketers. On 05/16/2025 03:51 PM, Marc Rochkind wrote: > On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > > wrote: > > I think AT&T's real problem was that the post-1984 UNIX business > was run by the lawyers. If you look at it, nearly every UNIX-related > fuckup on AT&T's part can be directly traced back to the lawyers. > > If they had only listened to Shakespeare. > > --lyndon > > > Hey, you forgot the TM on UNIX! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat May 17 12:03:32 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 17 May 2025 02:03:32 +0000 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: <67697ba8683df795@orthanc.ca> Message-ID: <63itFju7o4rStRY1LjVZOnFVnEikLYjSOi-IZHLG3yZPdPaHbSupN2c7QUrXC7sX8XwwIrErBgJau3ijSu0wOnAocCfSLYjKwgZtQ5IJzEU=@protonmail.com> On Friday, May 16th, 2025 at 3:51 PM, Marc Rochkind wrote: > On Fri, May 16, 2025 at 4:24 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > I think AT&T's real problem was that the post-1984 UNIX business > > was run by the lawyers. If you look at it, nearly every UNIX-related > > fuckup on AT&T's part can be directly traced back to the lawyers. > > > > If they had only listened to Shakespeare. > > > > --lyndon > > > Hey, you forgot the TM on UNIX! Is it really UNIX* discussion without *UNIX is a trademark of Bell Laboratories. at the bottom of every third page? - Matt G. From jnc at mercury.lcs.mit.edu Sat May 17 20:59:41 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 17 May 2025 06:59:41 -0400 (EDT) Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? Message-ID: <20250517105941.AA5B718C07A@mercury.lcs.mit.edu> > From: Lyndon Nerenberg > I think AT&T's real problem was that the post-1984 UNIX business was > run by the lawyers. This is a common problem in many companies: executives who do not have deep knowledge of the company's fundamental business, but rather in some support area, rise to the top of the business, and proceeed to make bad decisions about that business (through lack of deep understanding of the business' fundamentals). The exact same problem arises not just with support functions, but also with the belief in 'pure managers'. The biggest recent example of this problem in Boeing; the people running a business that is fundamentally an engineering business made some bad decisions in areas that were fundamentally engineering. Car companies have displayed this disorder too. Which is not to say that such people _can't_ be effective leaders of such organizations; the classic example is James Webb, who 'ran' NASA from 1961 to 1968; he was originally a lawyer. I say 'ran' NASA because Webb was smart enough to understand the limits of his expertise, and he delegated all the technical decisions to his chief deputy, Hugh Dryden - who had started his career as an aeronautical scientist (a Ph.D in physics and mathematics). Noel From paul.winalski at gmail.com Sun May 18 00:58:54 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 17 May 2025 10:58:54 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: On Fri, May 16, 2025 at 6:26 PM Ron Natalie wrote: > Sort of like when DEC finally recognized that people were buying their > hardware to run UNIX. Still remember Armando getting up and saying > something to the effect that DEC hardware and UNIX had been synonymous for > years and that DEC finally noticed and the held up the first DEC UNIX > license (plate). > > Clem Cole had--and still has--the Massachusetts UNIX license plate on his car. I don't know when he first got that plate. Armando had the New Hampshire UNIX license plate. It was on a snazzy red Datsun 280 ZX. At the time (early 1980s) I was driving a frumpy rust-bucket Datsun B210. I had the New Hampshire VAXVMS license plate. Armando jokingly threatened to park his sports car next to my car and take a picture of the two OS license plates side-by-side. AT&T's "consider it a standard" campaign was pretty successful in getting corporate executive types thinking about UNIX. Sort of along the lines of the "Intel Inside" campaign, which actually got ordinary folks to care about whose chip was in their PC. But AT&T never was able to take advantage of the opening the "consider it a standard" campaign provided. In addition to the reasons Clem cited, I think AT&T simply never learned how to compete in an open market. They had been a regulated utility monopoly for so very long. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sun May 18 05:35:03 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Sat, 17 May 2025 12:35:03 -0700 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: Just for historical accuracy - I believe Bill Shannon first had the New Hampshire UNIX plate and Armando got it after Bill moved to Sun. Evidence: https://photos.app.goo.gl/FYR17LRpJNpSBCGv8 On Sat, May 17, 2025 at 7:59 AM Paul Winalski wrote: > On Fri, May 16, 2025 at 6:26 PM Ron Natalie wrote: > >> Sort of like when DEC finally recognized that people were buying their >> hardware to run UNIX. Still remember Armando getting up and saying >> something to the effect that DEC hardware and UNIX had been synonymous for >> years and that DEC finally noticed and the held up the first DEC UNIX >> license (plate). >> >> Clem Cole had--and still has--the Massachusetts UNIX license plate on his > car. I don't know when he first got that plate. Armando had the New > Hampshire UNIX license plate. It was on a snazzy red Datsun 280 ZX. At > the time (early 1980s) I was driving a frumpy rust-bucket Datsun B210. I > had the New Hampshire VAXVMS license plate. Armando jokingly threatened to > park his sports car next to my car and take a picture of the two OS license > plates side-by-side. > > AT&T's "consider it a standard" campaign was pretty successful in getting > corporate executive types thinking about UNIX. Sort of along the lines of > the "Intel Inside" campaign, which actually got ordinary folks to care > about whose chip was in their PC. > > But AT&T never was able to take advantage of the opening the "consider it > a standard" campaign provided. In addition to the reasons Clem cited, I > think AT&T simply never learned how to compete in an open market. They had > been a regulated utility monopoly for so very long. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun May 18 07:36:06 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 17 May 2025 17:36:06 -0400 Subject: [TUHS] Was the SVID A Foregone Conclusion Pre-usr group? In-Reply-To: References: Message-ID: If we are going to be historical, I believe that I have had the Massachusetts UNIX plate for at least 6 months before Shannon secured NH (and have had them since). They have been displayed on eight vehicles, currently on my '18 Model S/P100. Somewhere is a picture of our cars parked next to each other, which would have been the first UNIXmobile, my silver '79 Capri, which I also had at UCB. BTW: Goble had the Indiana UNIX plate, but I'm not sure where in the sequence he was. wnj eventually had California's VMUNIX plate, but that was after both Shannon and I, and I think George. Jon Hall has the current NH UNIX plate and the NH LINUX plate. Interesting story, Mass used to allow a single plate, with nothing or anything of your own choosing on the front. So, I used to have the official Mass plate on the back and DEC plate on the front, which looked like an NH plate. I got pulled over by a NH cop one time who was really confused. The Commonwealth of Mass made me stop doing that about 20 years ago. I'm on the 3rd set of plates (they changed colors once, the others just faded), and it's really time for me to order a new set, but that means dealing with the RMV, which is never fun. Clem ᐧ ᐧ On Sat, May 17, 2025 at 3:35 PM Tom Lyon wrote: > Just for historical accuracy - I believe Bill Shannon first had the New > Hampshire UNIX plate and Armando got it after Bill moved to Sun. > Evidence: https://photos.app.goo.gl/FYR17LRpJNpSBCGv8 > > On Sat, May 17, 2025 at 7:59 AM Paul Winalski > wrote: > >> On Fri, May 16, 2025 at 6:26 PM Ron Natalie wrote: >> >>> Sort of like when DEC finally recognized that people were buying their >>> hardware to run UNIX. Still remember Armando getting up and saying >>> something to the effect that DEC hardware and UNIX had been synonymous for >>> years and that DEC finally noticed and the held up the first DEC UNIX >>> license (plate). >>> >>> Clem Cole had--and still has--the Massachusetts UNIX license plate on >> his car. I don't know when he first got that plate. Armando had the New >> Hampshire UNIX license plate. It was on a snazzy red Datsun 280 ZX. At >> the time (early 1980s) I was driving a frumpy rust-bucket Datsun B210. I >> had the New Hampshire VAXVMS license plate. Armando jokingly threatened to >> park his sports car next to my car and take a picture of the two OS license >> plates side-by-side. >> >> AT&T's "consider it a standard" campaign was pretty successful in getting >> corporate executive types thinking about UNIX. Sort of along the lines of >> the "Intel Inside" campaign, which actually got ordinary folks to care >> about whose chip was in their PC. >> >> But AT&T never was able to take advantage of the opening the "consider it >> a standard" campaign provided. In addition to the reasons Clem cited, I >> think AT&T simply never learned how to compete in an open market. They had >> been a regulated utility monopoly for so very long. >> >> -Paul W. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sun May 18 14:17:10 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sun, 18 May 2025 14:17:10 +1000 Subject: [TUHS] Demise of AT&T Message-ID: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> responding to the SVID thread: This is my timeline for AT&T : 1956 - Consent decrees for IBM & AT&T, barring each other from entering the others’ business. 1964 - AT&T engages with MULTICS, to build an "Information and Computing Service”, supplying the customer ‘outlets’ 1969 - AT&T / Bell Labs withdraws from MULTICS 1974 - UNIX announced in CACM 1984 - AT&T de-merges, [0] into 7 Regional Operators, keeping ”long lines” and hardware/software development & manufacture. 1991 - IBM declares first loss, increasing losses for another two years. 1994 - Unix sold to Novell, hardware to NCR 2004 - AT&T acquired by SBC [0], a former Baby Bell that’d understood the Mobile phone market & pricing. Both IBM & AT&T were aware of “Silicon Valley” and the rapid evolution of microelectronics. AT&T even considered a 1966 Terman proposal, post-Stanford, to create “Silicon Valley East”. AT&T validly reasoned they couldn’t create it, there wasn’t the needed culture of Cooperation & Collaboration around them. Gordon Bell at DEC certainly understood the changes in technology and admitted “he didn’t believe it” [ i.e. predictions from his own models ]. It wasn’t just AT&T, IBM & DEC that got run over by commodity DRAM & CPU’s, it was the entire Minicomputer Industry, effectively extinct by 1995. [3] One of the causes of AT&T’s management failure was the “East Coat” management culture, documented by Tom Wolfe in 1983 [2] in “The Tinkerings of Robert Noyce”. What Wolfe seems to have missed is the “East Coast” focus on high Gross Margins (50%-90% for product lines, at both IBM & AT&T), compared to the Silicon Valley focus on “Volume” with implied modest Gross Margins: deliberately sharing cost-savings with Customers. An unanswered question about Silicon Valley is: Why did it happen in California and not be successfully cloned elsewhere? There is something different / special about California that for a century has diversified its economy, consistently grown its population faster than other US states, and grown its economy, over a century, faster than any US state or other nation. [ 7 ] I’ve not seen any definitive explanation of the Californian Miracle, it’s incontrovertible in the long-run numbers, before & after Silicon Chips, presumably due to multiple reinforcing factors, that create & maintain exceptional industries. i.e. virtuous circles, like Silicon Valley remaining an economic powerhouse, even as ’technology’ has evolved from Silicon devinces to chips, to software, to Internet Services. The Silicon Revolution didn’t just crush computer companies - it broke other long-term successful innovators: Kodak invented Digital Cameras in 1972, only to be forced into bankruptcy around 2009 after a century plus of operations, continuing after significant restructuring. =================== The SVID thread touches on the reasons that AT&T failed: Clem Cole was in the room when Bill Gates said “it’s all about volume” [ implying modest margins ] Others mention ‘lawyers’ came to dominate the firm, making poor decisions. Rob Pike has previously mentioned on-list a lawyer killed the music, in PAC format, they’d arranged to put on Plan 9 distribution CD. Rachel Chalmers [4] in 1999 quotes Dennis Ritchie on the struggles to get the Version 6 code and Lions Commentary released. The lawyers and Corporate Culture were still hanging on 20 years later, wanting to block public release because they could, not for business reasons. In 1956, AT&T accounted for ~2% of US GDP, equivalent to ~$500B in sales today [1], comparable to Apple’s 2024 earnings of $391B. Tom Wolfe [2] wrote a piece on Noyce at Fairchild, then Intel, and details an “East Coast Management Style”, of opulence, self-indulgence and aggrandisement of ’the ruling class’. Wolfe is excoriating about “East Coast” management, though doesn’t detail the Silicon Valley / California approach in any detail. Noyce & Moore left Fairchild in 1968 with the invention of the Self-Aligned Silicon Gate for MOSFET to pursue devices made of large, regular arrays of transistors, also, quite particularly, to run the business without interference from the East Coast, able to reinvest their profits and grow the business as fast as they could. Fairchild had passed over Noyce in favour of Lester Hogan from Motorola [5] and his management team. Hogan was given a record renumeration package to move to Fairchild, but didn’t save the business. Intel has lasted, quickly growing to be a significant force and holding a lead. Fairchild never recovered after Noyce & Moore left and it sputtered out, underlining the importance of management style in Semiconductor businesses. Fairchild Semiconductor had, for over a decade, grown to be the dominant silicon device manufacturer, despite the parent company consistently using their profits to invest in vanity projects with low returns or losses. In 1963, Fairchild had announced UHF TV transistors for "$1.05” ( ~$11 now ) after the FAA added UHF band to broadcast TV. To compete with Vacuum tubes, given for nothing to TV manufacturers, Fairchild had to drop prices ten-fold ( vs mil.spec devices ) [ Valve manufactures made their money on replacement valves, not on original parts. ] Importantly, Fairchild’s price was below cost at the time. The engineers who pitched this to Noyce knew they’d sell millions and be able to quickly reduce production costs to make large profits. Noyce & Moore seemed to have used their Maths ability to solve a business / economics problem for them: How to optimise long-run revenue and profits in a dynamic, high CapEx / R&D / Non-Recurring Expenditure technology field? Their answer is what we’ve christened “Moore’s Law”: a) run R&D as hard as you can, shortening the ‘generation’ period to 2-3 years, well below the usual 5-10 years for “cost recovery” b) pass on 100% of cost savings to customers, relying on “Elasticity of Demand” to drive Volumes and increase total revenue. I assume they understood enough Game Theory to know once they adopted a “high volume / low-cost / rapid generations” strategy, they’d force all manufacturers in the industry to follow or be left behind. Kenneth Flamm [6], an economist, has written about the sustained “100% pass-through rate” of Silicon Semiconductors until at least 2010. I’ve not seen him or others discuss the origins of this strategy, unique to Semiconductors. Gordon Bell [3] noted the impact of the CMOS CPU revolution created by Silicon Valley. In 1984, there were 92 US Minicomputer Companies using discrete or Small Scale IC’s. In 1990, only 4 survived: Data General, HP, DEC and IBM [ Bell in [3] notes their fates out to 2002 ] IBM declared it’s first loss [$2.6B] in 1991, deepening to ~$5B and then ~$8B in 1992 & 1993 - seemingly without warning, they were caught by the changes in the market as commodity chips surpassed everything. IBM knew microprocessors were rapidly evolving, knew it’s Corporate Culture was antithetical to developing a product quickly & cheaply, so developed the IBM PC in 1981 in Boca Raton, Florida - away from Manhattan & breaking their traditional fully internal development and high gross margin model. During the 1970’s and 1980’s, IBM accounted for over 50% of Industry revenue - bigger than everyone else combined. That they weren’t able to adapt and respond to the challenges they clearly saw speaks of management failure. Like AT&T, they saw technology evolving and correctly forecast it’s impact on their ’traditional’ business lines, but were unable to changed their corporate culture to adapt. ================================================================================= References ================================================================================= [0] 1984: Southwestern Bell Corporation (known as SBC Communications after 1995) In 2005, SBC acquired former parent AT&T Corporation and took the AT&T name, becoming AT&T Inc. =================== [1] How Antitrust Enforcement Can Spur Innovation: Bell Labs and the 1956 Consent Decree As described in Section I, the Bell System was the dominant provider of telecommunications services in the United States. In terms of assets, AT&T was by far the largest private corporation in the world in 1956. AT&T, together with all companies in the Bell system, employed 746,000 people with a total revenue of $5.3 billion or 1.9% of the U.S. GDP at the time (Antitrust Subcommittee, 1959; Temin and Galambos, 1987). =================== [2] THE TINKERINGS OF ROBERT NOYCE How the sun rose on the Silicon Valley Tom Wolfe, Dec 1983 A certain instinct Noyce had about this new industry and the people who worked in it began to take on the outlines of a concept. Corporations in the East adopted a feudal approach to organization, without even being aware of it. There were kings and lords, and there were vassals, soldiers, yeomen, and serfs, with layers of protocol and perquisites, such as the car and driver, to symbolize superiority and establish the boundary lines. Back east the CEOs had offices with carved paneling, fake fireplaces, escritoires, bergères, leather-bound books, and dressing rooms, like a suite in a baronial manor house. Fairchild Semiconductor needed a strict operating structure, particularly in this period of rapid growth, but it did not need a social structure. In fact, nothing could be worse. Noyce realized how much he detested the eastern corporate system of class and status with its endless gradations, topped off by the CEOs and vice-presidents who conducted their daily lives as if they were a corporate court and aristocracy. He rejected the idea of a social hierarchy at Fairchild. =================== [3] Rise and Fall of Minicomputers Decline of the Classic Minicomputer (1985-1995) Gordon Bell 2013 While the demise of classic minicomputers was clear by 1985, companies continued offering them until the early 1990s, when the firms went bankrupt or were acquired by more astute competitors. (See Table 1) Wang declared bankruptcy in 1992. Compaq bought DEC in 1998, and HP acquired Compaq in 2002. EMC turned Data General into a data storage business in 1999. Table 1 92 U.S. minicomputer companies, 1968-1985 (created by the author with help from colleagues over many years) The following list includes all firms making general and special-purpose minicomputers for real-time processing, communications, business etc., sold to end users through OEMs, and bundled for process control and testing. It does not include scores of military, AT&T, European, and Japanese computers and processing systems developed for niche markets. 49 started up and retained autonomy or died 2 grew at significant rates and continued to grow: Data General (1969), Prime (1972) 8 grew at diminished or declining rates, or found small niches 39 ceased to manufacture 10 merged with larger companies 8 existing computer companies built minicomputers 2 grew rapidly: Digital Equipment Corporation (1960), IBM (1965) 25 existing companies built minicomputers for their own use 1 formed a division, Dymec, around an acquisition and grew rapidly: HP (1966) =================== [4] Code Critic John Lions wrote the first, and perhaps only, literary criticism of Unix, sparking one of open source's first legal battles. Rachel Chalmers November 30, 1999 "By the time the seventh edition system came out, the company had begun to worry more about the intellectual property issues and 'trade secrets' and so forth," Ritchie explains. "There was somewhat of a struggle between us in the research group who saw the benefit in having the system readily available, and the Unix Support Group ... Even though in the 1970s Unix was not a commercial proposition, USG and the lawyers were cautious. At any rate, we in research lost the argument.” ——— Ritchie never lost hope that the Lions books could see the light of day. He leaned on company after company. "This was, after all, 25-plus-year-old material, but when they would ask their lawyers, they would say that they couldn't see any harm at first glance, but there was a sort of 'but you never know ...' attitude, and they never got the courage to go ahead," he explains. Finally, at SCO, Ritchie hit paydirt. He already knew Mike Tilson, an SCO executive. With the help of his fellow Unix gurus Peter Salus and Berny Goodheart, Ritchie brought pressure to bear. "Mike himself drafted a 'grant of permission' letter," says Ritchie, "'to save the legal people from doing the work!'" Research, at last, had won. =================== [5] Wikipedia on Fairchild Sherman Fairchild hired Lester Hogan, who was the head of Motorola semiconductor division. Hogan proceeded to hire another hundred managers from Motorola to entirely displace the management of Fairchild. The loss of these iconic executives, coupled with Hogan's displacement of Fairchild managers demoralized Fairchild and prompted the entire exodus of employees to found new companies. =================== [6] Moore's Law and the Economics of Semiconductor Price Trends Flamm, 2018, NBER ——— Flamm posits semiconductors [ DRAM & Microprocessors at least ] have maintained a 100% cost “pass-through rate” since the 1960’s. He’s been an expert witness for courts many times, as well as writing reports for the NBER and publishing academic papers. ——— In short, if the historic pattern of 2-3 year technology node introductions, combined with a long run trend of wafer processing costs increasing very slowly were to have continued indefinitely, a minimum floor of perhaps a 20 to 30 percent annual decline in quality-adjusted costs for manufacturing electronic circuits would be predicted, due solely to these “Moore’s Law” fabrication cost reductions. On average, over long periods, the denser, “shrink” version of the same chip design fabricated year earlier would be expected to cost 20 to 30 percent less to manufacture, purely because of the improved manufacturing technology. How would reductions in production cost translate into price declines? One very simple way to think about it would be in terms of a “pass-through rate,” defined as dP/dC (incremental change in price per incremental change in production cost). The pass-through rate for an industry-wide decline in marginal cost is equal to one in a perfectly competitive industry with constant returns to scale, but can exceed or fall short of 1 in imperfectly competitive industries. Assuming the perfectly competitive case as a benchmark for long-run pass-through in “relatively competitive” semiconductor product markets, this would then imply an expectation of 20-30% annual declines in price, due solely to Moore’s Law. To summarize these results, then, though there are substantial differences in the magnitude of declines across different time periods and data sources, all of the various types of price indexes constructed concur in showing substantially higher rates of decline in microprocessor price prior to 2004, a stop-and-start pattern after 2004, and a dramatically lower rate of decline since 2010. Taken at face value, this creates a new puzzle. Even if the rate of innovation had slowed in general for microprocessors, if the underlying innovation in semiconductor manufacturing technology has continued at the late 1990s pace (i.e., a new technology node every two years and roughly constant wafer processing costs in the long run), then manufacturing costs would continue to decline at a 30 percent annual rate, and the rates of decline in processor price that are being measured now fall well short of that mark. Either the rate of innovation in semiconductor manufacturing must also have declined, or the declining manufacturing costs are no longer being passed along to consumers to the same extent, or both. The semiconductor industry and engineering consensus seems to be that the pace of innovation derived from continuing feature-size scaling in semiconductor manufacturing has slowed markedly. ————————— [ submission to a court case ] Assessment of the Impact of Overcharges on Canadian Direct and Indirect Purchasers of DRAM and Products Containing DRAM Submitted to: The Honourable Ian Binnie 28 June 2013 VI. Pass-Through in this Case 48. Based upon my review of the information described above, I am of the view that there would likely be a very high degree of pass-through in DRAM distribution channels, all the way down to final consumers. This conclusion is based principally on a review of the structure of the various markets together with an application of standard economic theory. I also draw on pass-through analyses done by a number of experts in the U.S. action, recognizing that they are clearly contradictory on some key points. Evidence from the U.S. Case 49. Let me begin with a brief review of the work done by economists for various parties in the American action. a. In his report Michael Harris (July 10, 2007) estimated pass-through from top to bottom rather than just at one stage. That is, he looked to see if increases in the price of base DRAM were passed all the way down the distribution channels and increased computer prices. In one test he estimated that there was more than 100% pass-through of base DRAM price increased to final computer purchasers. In a second test he studied the effect of increases in spot market DRAM prices on aftermarket DRAM prices. Again, he found more than 100% pass-through.21 b. Professor Kenneth Flamm, in his report (December 15, 2010) provided estimates of the pass-through from retailers to final consumers using data from four major U.S. retailers (Best Buy, Office Depot, CDW, and Tech Depot) for various categories of computer products (desktops, notebooks, servers, memory, printers and graphics). Most pass-through estimates were in a range between 90% and 113%, the desktop and notebook rates were all within a few points above or below 100% with one exception. =================== [7] Links on California, population and economic growth from 1900 to 2000 ————————— Wikipedia The economy of the State of California is the largest in the United States [ in 2024 ]. It is the largest sub-national economy in the world. If California was an independent nation, it would rank as the fourth largest economy in the world in nominal terms, behind Germany and ahead of Japan. As of 2024, California is home to the highest number of Fortune 500 companies of any U.S. state. As both the most populous US state and one of the most climatologically diverse states the economy of California is varied, with many sizable sectors. ————————— California since c. 1900 population in 1900: 2 M. now largest US state by population & GNP. ————————— California’s Economy. [ fact sheet 2025 ] California is an economic powerhouse, nationally and globally. • In 2023, California’s gross domestic product (GDP) was about $3.9 trillion, comprising 14% of national GDP ($27.7 trillion). Texas and New York are the next largest state economies, at 9% and 8%, respectively. • California’s economy ranks fifth internationally, behind the US, China, Germany, and Japan. On a per capita basis, California’s GDP is greater than that of all of these countries. • California’s economy has grown relatively slowly in recent years, averaging 2.3% per year between 2020 and 2023, compared to 3.9% on average over the previous four years. By comparison, Florida (4.6%) and Texas (3.9%) grew faster than California since 2020. • Over the long term, California’s economy has grown faster than the nation overall (111% vs 75% over the past 25 years) and faster than other large states except for Texas (128%). On a per capita basis, California’s economic growth outpaces all other large states over the long term. Growth in jobs and businesses have powered the state’s economy. • California’s labor market grew by 4.2 million jobs (30%) between 1998 and the second quarter of 2024; over the same 25-year period, the number of businesses with employees grew more than 72%. Both outpaced population growth (18%), leading to robust gains in economic output. ————————— California’s Population [ fact sheet 2025 ] One in eight US residents lives in California. • With just over 39 million people (according to July 2024 estimates), California is the nation’s most populous state - its population is much larger than that of second-place Texas (31.3 million) and third-place Florida (23.4 million). ————————— =================== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From bear at typewritten.org Sun May 18 14:44:54 2025 From: bear at typewritten.org (r.stricklin) Date: Sat, 17 May 2025 21:44:54 -0700 Subject: [TUHS] Demise of AT&T In-Reply-To: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> References: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> Message-ID: <69DAF84F-58D6-4D78-B1B9-0593F24C263E@typewritten.org> > On May 17, 2025, at 9:17 PM, sjenkin at canb.auug.org.au wrote: > > I’ve not seen any definitive explanation of the Californian Miracle, > it’s incontrovertible in the long-run numbers, before & after Silicon Chips, > presumably due to multiple reinforcing factors, that create & maintain exceptional industries. > > i.e. virtuous circles, like Silicon Valley remaining an economic powerhouse, > even as ’technology’ has evolved from Silicon devinces to chips, to software, to Internet Services. > I find Steve Blank’s “Secret History” compelling, if perhaps not entirely exhaustive. I wasn’t there and couldn’t say, but it seems to me like a good explanation for a substantial portion of the story. Steve gives a lot of the credit to Terman’s ability to engage DARPA. https://steveblank.com/secret-history/ ok bear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun May 18 16:14:34 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 18 May 2025 00:14:34 -0600 Subject: [TUHS] Whither XVT? [ From the SVID thread ] In-Reply-To: References: Message-ID: <202505180614.54I6EYT02835474@freefriends.org> Hi Marc, Marc Rochkind wrote: > I was on a different committee that was trying to standardize a universal > GUI interface that could work on any GUI, including Mac, Windows, Motif, > and OpenLook. My product, XVT, was the base document. We never got past the > draft stage. I think XVT also supported libcurses, no? Around 1990-1991 I was in a start-up company and we looked at XVT for the UI we wanted to write. I remember being in the confeerence room on a phone call with you, and thinking how cool it was that we were talking to one of those famous UNIX guys who'd been at Bell Labs. A modern incarnation of your idea is the Qt toolkit, which lets one write C++ UI (and more) code that runs the same on Windows, Mac, *nix, and these days maybe even Android and iPhone. In any case, is the XVT code around somewhere? Thanks, Arnold From sjenkin at canb.auug.org.au Sun May 18 16:50:57 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sun, 18 May 2025 16:50:57 +1000 Subject: [TUHS] Demise of AT&T In-Reply-To: <69DAF84F-58D6-4D78-B1B9-0593F24C263E@typewritten.org> References: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> <69DAF84F-58D6-4D78-B1B9-0593F24C263E@typewritten.org> Message-ID: <6146FFAA-994B-41FE-9FC7-B9EEB18A4B3A@canb.auug.org.au> > On 18 May 2025, at 14:44, r.stricklin wrote: > > I find Steve Blank’s “Secret History” compelling, if perhaps not entirely exhaustive. I wasn’t there and couldn’t say, but it seems to me like a good explanation for a substantial portion of the story. Steve gives a lot of the credit to Terman’s ability to engage DARPA. > > https://steveblank.com/secret-history/ > > > ok > bear. Ric, Thanks for the great reply. Like Unix, there were a lot of actors who contributed to the success of Silicon Valley, all on the critical path. Terman & his work with Stanford is a big certainly part of the story, but I don’t agree with the Stanford view that they were wholly, or mainly, responsible for Silicon Valley. Terman tried very hard to sell his model after 1966, but nobody could see how to implement it - suggesting to me it was only possible within the context of California. Carolyn Tajnai, 1996 From the Valley of Heart's Delight to the Silicon Valley CSL-TR-97-713 California grew rapidly before and outside Silicon Valley, Hollywood springs to mind. It’s grown faster than every other US State and all other nations, at least from 1900-2000. While it’s population has grown largely from immigration, the GDP per person has also grown faster than elsewhere. The “mainly” Stanford / Terman hypothesis isn’t the whole story IMHO, because the prior 50+ years of growth in California shows somehow it was “special”. Other people point to the climate, cheap Real Estate, lots of jobs, business opportunities, good pay and other factors… [ there was a significant ‘barrier to entry’ for settling in The West - the high cost of getting there ] [ Most / all of the Immigrants from ‘back East’ were educated middle class with savings & ambition ] [ New York, in comparison, had immigrants living in slums and working for subsistence wages, ] [ NYC was a recreation of the Feudal social hierarchy they’d fled. Very few got rich, nearly none without money ] None of those reasons is necessary & sufficient, IMHO. California also has progressive politics, even under Republicans like Arnold Schwarzenegger. The state has been a leader in pollution & environmental laws since the 1960’s. Although the term, “vigilante", was coined in San Francisco before it had strong law enforcement, was part of “The Wild West” where cowboys carried firearms and ‘settled differences’ by shooting, California now has stricter gun laws than most states and lower rates of gunshot deaths. Perhaps the stronger environmental laws is partly explained by a Constitutional protection preventing ‘capture’ of the legislature & judiciary by Political Parties & elected officials, allowing the citizens to force change directly: Citizen Initiated Referenda / Initiatives [ links below ] This forms part of the context of California, something different about its culture, but isn’t “the One thing”. As I said, I’ve sifted through a lot [ for me ] and not been able to find a definitive casual link, leading me to think it’s a constellation of reinforcing conditions that created & sustained Silicon Valley. Stanford & Terman were necessary in this, of course. Thanks for the comments & good links. cheers steve j ================ There are three forms of direct democracy in California state elections: mandatory referendums (part of the Constitution of California since 1856), optional referendums, and initiatives. The initiative and optional (or facultative) referendum were introduced as Progressive Era reforms in 1911, by a constitutional amendment called Proposition 7. History of California Initiatives ================ Gregory Gromov in “El Dorado” notes another contributing factor - banning of ‘anti-compete’ clauses in employment contracts. With this catalyst of scientific and technological process acting locally in just one American state, a very special law was enacted in California in 1872. The law in question declared null and void any contract between a business owner and employee if said contract in any way restricted the employee’s freedom to change employers, even if that meant joining the former employer’s competition. In other words, any previously signed agreements—for example, an employee contract signed upon hiring— that could in any way limit the employee’s right to freely choose his or her place of work were deemed unenforceable in this 1872 law. More specifically, those clauses that were in conflict with this law were deemed unenforceable. As a result of this cascade of direct and indirect consequences from the application of this law in Silicon Valley, today a number of generally operating U.S. legal standards, including some of the most important, are practically blocked (“de facto” canceled). ================ -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sun May 18 23:28:39 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 18 May 2025 13:28:39 +0000 Subject: [TUHS] UNIX Plates In-Reply-To: References: Message-ID: Of course, Amrando put one of the DEC license plates (complete with the official expiration tabs) on the front of his car. It went missing for a while and he inquired if anybody had seen it (which get worldwide repsonse that it wasn’t in a lot of places). I think he eventually recovered it. ------ Original Message ------ >From "Clem Cole" To "Tom Lyon" Cc tuhs at tuhs.org Date 5/17/2025 5:36:06 PM Subject [TUHS] Re: Was the SVID A Foregone Conclusion Pre-usr group? >If we are going to be historical, I believe that I have had the >Massachusetts UNIX plate for at least 6 months before Shannon secured >NH (and have had them since). They have been displayed on eight >vehicles, currently on my '18 Model S/P100. Somewhere is a picture of >our cars parked next to each other, which would have been the first >UNIXmobile, my silver '79 Capri, which I also had at UCB. BTW: Goble >had the Indiana UNIX plate, but I'm not sure where in the sequence he >was. wnj eventually had California's VMUNIX plate, but that was after >both Shannon and I, and I think George. Jon Hall has the current NH >UNIX plate and the NH LINUX plate. > >Interesting story, Mass used to allow a single plate, with nothing or >anything of your own choosing on the front. So, I used to have the >official Mass plate on the back and DEC plate on the front, which >looked like an NH plate. I got pulled over by a NH cop one time who >was really confused. The Commonwealth of Mass made me stop doing that >about 20 years ago. I'm on the 3rd set of plates (they changed colors >once, the others just faded), and it's really time for me to order a >new set, but that means dealing with the RMV, which is never fun. > >Clem >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Mon May 19 00:55:07 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Sun, 18 May 2025 08:55:07 -0600 Subject: [TUHS] Whither XVT? [ From the SVID thread ] In-Reply-To: <202505180614.54I6EYT02835474@freefriends.org> References: <202505180614.54I6EYT02835474@freefriends.org> Message-ID: Arnold, I left XVT around 1992 or so and shortly after that it was absorbed into a California company owned by XVT's VC investor. Then the XVT assets were sold to someone and it was operated for some years as an independent company, but I don't know what happened after that. I haven't had any contact at all with XVT for over 30 years. Poking around, I see this website: https://providencesoftware.com/ where XVT seems still to exist. But that's just from Googling; I don't have any other knowledge. Indeed XVT supported character displays in addition to GUIs. Marc On Sun, May 18, 2025 at 12:14 AM wrote: > Hi Marc, > > Marc Rochkind wrote: > > > I was on a different committee that was trying to standardize a universal > > GUI interface that could work on any GUI, including Mac, Windows, Motif, > > and OpenLook. My product, XVT, was the base document. We never got past > the > > draft stage. > > I think XVT also supported libcurses, no? > > Around 1990-1991 I was in a start-up company and we looked at XVT > for the UI we wanted to write. I remember being in the confeerence room > on a phone call with you, and thinking how cool it was that we were > talking to one of those famous UNIX guys who'd been at Bell Labs. > > A modern incarnation of your idea is the Qt toolkit, which lets one > write C++ UI (and more) code that runs the same on Windows, Mac, *nix, > and these days maybe even Android and iPhone. > > In any case, is the XVT code around somewhere? > > Thanks, > > Arnold > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Mon May 19 01:15:46 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 18 May 2025 11:15:46 -0400 Subject: [TUHS] UNIX Plates In-Reply-To: References: Message-ID: On Sun, May 18, 2025 at 9:29 AM Ron Natalie wrote: > Of course, Amrando put one of the DEC license plates (complete with the > official expiration tabs) on the front of his car. > Was Armando living in New Hampshire at the time (he was working there)? If so, that front UNIX license plate should have been the official NH one--NH requires vehicles registered in the state to display both front and rear license plates. But I wouldn't put it past Armando to put the DEC license plate on the front as a joke. It would be unlikely to be noticed as a fake by NH cops, especially if he had the official expiration tabs on it. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon May 19 01:54:01 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 18 May 2025 09:54:01 -0600 Subject: [TUHS] Whither XVT? [ From the SVID thread ] In-Reply-To: References: <202505180614.54I6EYT02835474@freefriends.org> Message-ID: <202505181554.54IFs1rc2881733@freefriends.org> Thanks for the info Marc. Looks like Providence Software XVT is indeed a cross-platform toolkit. Marc Rochkind wrote: > Arnold, > > I left XVT around 1992 or so and shortly after that it was absorbed into a > California company owned by XVT's VC investor. Then the XVT assets were > sold to someone and it was operated for some years as an independent > company, but I don't know what happened after that. I haven't had any > contact at all with XVT for over 30 years. > > Poking around, I see this website: > > https://providencesoftware.com/ > > where XVT seems still to exist. But that's just from Googling; I don't have > any other knowledge. > > Indeed XVT supported character displays in addition to GUIs. > > Marc > > On Sun, May 18, 2025 at 12:14 AM wrote: > > > Hi Marc, > > > > Marc Rochkind wrote: > > > > > I was on a different committee that was trying to standardize a universal > > > GUI interface that could work on any GUI, including Mac, Windows, Motif, > > > and OpenLook. My product, XVT, was the base document. We never got past > > the > > > draft stage. > > > > I think XVT also supported libcurses, no? > > > > Around 1990-1991 I was in a start-up company and we looked at XVT > > for the UI we wanted to write. I remember being in the confeerence room > > on a phone call with you, and thinking how cool it was that we were > > talking to one of those famous UNIX guys who'd been at Bell Labs. > > > > A modern incarnation of your idea is the Qt toolkit, which lets one > > write C++ UI (and more) code that runs the same on Windows, Mac, *nix, > > and these days maybe even Android and iPhone. > > > > In any case, is the XVT code around somewhere? > > > > Thanks, > > > > Arnold > > > > > -- > Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. From clemc at ccc.com Mon May 19 02:15:24 2025 From: clemc at ccc.com (Clem Cole) Date: Sun, 18 May 2025 12:15:24 -0400 Subject: [TUHS] UNIX Plates In-Reply-To: References: Message-ID: Yes, and That is exactly what he did. At one point. Sent from a handheld expect more typos than usual On Sun, May 18, 2025 at 11:16 AM Paul Winalski wrote: > On Sun, May 18, 2025 at 9:29 AM Ron Natalie wrote: > >> Of course, Amrando put one of the DEC license plates (complete with the >> official expiration tabs) on the front of his car. >> > > Was Armando living in New Hampshire at the time (he was working there)? > If so, that front UNIX license plate should have been the official NH > one--NH requires vehicles registered in the state to display both front and > rear license plates. But I wouldn't put it past Armando to put the DEC > license plate on the front as a joke. It would be unlikely to be noticed > as a fake by NH cops, especially if he had the official expiration tabs on > it. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Mon May 19 09:31:39 2025 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Mon, 19 May 2025 09:31:39 +1000 Subject: [TUHS] Demise of AT&T In-Reply-To: References: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> <69DAF84F-58D6-4D78-B1B9-0593F24C263E@typewritten.org> <6146FFAA-994B-41FE-9FC7-B9EEB18A4B3A@canb.auug.org.au> Message-ID: Ric, Thanks for the Real World ‘ground truth’! You’ve woken me up to when the Mythical Golden Years had evaporated. I’ve had my head buried in historical commentary, mainly the 1950’s & 1960’s. Before Silicon Valley got rich :( The net effect of people dealing in Real Estate for 150 years isn’t ‘cheap housing’. Thanks very much for the correction. For my own reference, I should really say ‘once cheap real estate’ or ‘historically cheap’. From the 1850’s to 1900, land was exceedingly cheap in The Wild West, but not for 50 years :( cheers steve j > On 19 May 2025, at 09:05, Rik Farrow wrote: > > Hi Steve: > > Nice analysis, although I would disagree with you on one point: > > > Other people point to the climate, cheap Real Estate, lots of jobs, business opportunities, good pay and other factors… > > Cheap Real Estate? I was living near Washington DC in 1978 when a friend told me about the "Gold Coast". I asked her why they called California that, and she said because it was so expensive to live there. > > I moved there in 1979, and lived there until 1991, when my wife and I decided to move to a less expensive and crowded area in Arizona (Sedona). We had a family of four, plus needed extra rooms for my home office and her art studio, and have been priced out of living within a couple of hours drive of San Francisco. > > We really liked living there, and found people to be generally outgoing, good at communicating, cooperative but also very competitive. It was shocking to move to Arizona, with a much slower pace, but also people who were less friendly to strangers and less cooperative in general. Still, I certainly appreciated being in a place where I could hike and mountain bike, where in Marin County, north of SF, there would actually be cops with radar guns who would ticket bicyclists for coming around a corner on a dirt road faster than 5 mph! And once we had moved north of Marin, the opportunities for being alone in nature were low. The land was private and posted. > > So, no cheap Real Estate, not since the mid-70s. Instead, incredible home price inflation (now common where we live), and crazy-heavy traffic on top of that. > > Rik Farrow -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Mon May 19 10:02:13 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 18 May 2025 20:02:13 -0400 Subject: [TUHS] Demise of AT&T In-Reply-To: References: <99DBBF1C-B511-43B1-B4A2-7A56D557E773@canb.auug.org.au> <69DAF84F-58D6-4D78-B1B9-0593F24C263E@typewritten.org> <6146FFAA-994B-41FE-9FC7-B9EEB18A4B3A@canb.auug.org.au> Message-ID: Commercial real estate in silicon valley was a fraction of what it was in the Boston area. Not the same as the residential market. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon May 19 23:42:45 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 19 May 2025 09:42:45 -0400 (EDT) Subject: [TUHS] Demise of AT&T Message-ID: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> > From: Steve Jenkin > An unanswered question about Silicon Valley is: > Why did it happen in California and not be successfully cloned > elsewhere? One good attempt at answering this is in "Making Silicon Valley: Innovation and the Growth of High Tech, 1930-1970", by Christophe Lecuyer; it's also a very good history of the early Silicon Valley (before the mid-1960's). Most of it's available online, at Google: https://books.google.com/books?id=5TgKinNy5p8C I have neither the time nor energy to comment in detail on your very detailed post, but I think Lecuyer would mostly agree with your points. > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > CPU's, it was the entire Minicomputer Industry, effectively extinct by > 1995. Same thing for the work-station industry (with Sun being merely the most notable example). I have a tiny bit of second-hand personal knowldge in this area; my wife works for NASA, as a structural engineer, and they run a lot of large computerized mathematical models. In the 70's, they were using CDC 7600's; they moved along through various things as technology changed (IIRC, at one point they had SGI machines). These days, they seem to mostly be using high-end personal computers for this. Some specialized uses (various forms of CAD) I guess still use things that look like work-stations, but I expect they are stock personal computers with special I/O (very large displays, etc). So I guess now there are just supercomputers (themselves mostly built out of large numbers of commodity CPUs), and laptops. Well, there is also cloud computing, which is huge, but that also just uses lots of commodity CPUs. Noel From paul.winalski at gmail.com Tue May 20 02:18:15 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 19 May 2025 12:18:15 -0400 Subject: [TUHS] Demise of AT&T In-Reply-To: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: On Mon, May 19, 2025 at 9:43 AM Noel Chiappa wrote: > > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > > CPU's, it was the entire Minicomputer Industry, effectively extinct > by > > 1995. > > Same thing for the work-station industry (with Sun being merely the most > notable example). > Indeed. Extinction of existing practice by new technology happens all the time and not just in the computer field. Before sound recording and playback was invented, fancy restaurants, hotels, etc. hired orchestras to play background music. The phonograph put a huge number of orchestras out of business. There's a knee-jerk tendency in our industry for companies to respond to new technology by retreating to the high end of the market in an attempt to protect profit margins. IBM did this when minicomputers came along; Apollo did it when confronted with cheap workstations (Sun); DEC did it when the PC appeared; Intel right now is attempting to do it to stave off competition from ARM. In all cases the effort has been unsuccessful and usually has resulted in the death of the company (IBM has survived, but as a shadow of its former self). I think it was Scott McNealy who said (regarding protecting existing products and profit margins) that a tech company must be prepared to eat its own children. If they don't, the competition will. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue May 20 05:17:53 2025 From: rminnich at gmail.com (ron minnich) Date: Mon, 19 May 2025 12:17:53 -0700 Subject: [TUHS] Demise of AT&T In-Reply-To: References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: I had a talk with a DEC salesman in Sep 1990. They had just loaned me a DECStation for eval. me: "What happens if computers become commodities like sneakers" DEC salesman: "we go out of business" They were right. On Mon, May 19, 2025 at 9:18 AM Paul Winalski wrote: > On Mon, May 19, 2025 at 9:43 AM Noel Chiappa > wrote: > >> > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & >> > CPU's, it was the entire Minicomputer Industry, effectively extinct >> by >> > 1995. >> >> Same thing for the work-station industry (with Sun being merely the most >> notable example). >> > > Indeed. Extinction of existing practice by new technology happens all the > time and not just in the computer field. Before sound recording and > playback was invented, fancy restaurants, hotels, etc. hired orchestras to > play background music. The phonograph put a huge number of orchestras out > of business. > > There's a knee-jerk tendency in our industry for companies to respond to > new technology by retreating to the high end of the market in an attempt to > protect profit margins. IBM did this when minicomputers came along; Apollo > did it when confronted with cheap workstations (Sun); DEC did it when the > PC appeared; Intel right now is attempting to do it to stave off > competition from ARM. In all cases the effort has been unsuccessful and > usually has resulted in the death of the company (IBM has survived, but as > a shadow of its former self). > > I think it was Scott McNealy who said (regarding protecting existing > products and profit margins) that a tech company must be prepared to eat > its own children. If they don't, the competition will. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue May 20 05:44:32 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 19 May 2025 15:44:32 -0400 Subject: [TUHS] Whither Workstations? (Was Re: Demise of AT&T) In-Reply-To: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: On Mon, May 19, 2025 at 12:36 PM Noel Chiappa wrote: > > [snip] > > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > > CPU's, it was the entire Minicomputer Industry, effectively extinct by > > 1995. > > Same thing for the work-station industry (with Sun being merely the most > notable example). I have a tiny bit of second-hand personal knowldge in this > area; my wife works for NASA, as a structural engineer, and they run a lot of > large computerized mathematical models. In the 70's, they were using CDC > 7600's; they moved along through various things as technology changed (IIRC, > at one point they had SGI machines). These days, they seem to mostly be using > high-end personal computers for this. > > Some specialized uses (various forms of CAD) I guess still use things that > look like work-stations, but I expect they are stock personal computers > with special I/O (very large displays, etc). > > So I guess now there are just supercomputers (themselves mostly built out of > large numbers of commodity CPUs), and laptops. Well, there is also cloud > computing, which is huge, but that also just uses lots of commodity CPUs. The CPU ISAs may be _largely_ shared, but computing has bifurcated into two distinct camps: those machines intended for use in datacenters, and those intended for consumer use by end-users. CPUs intended for datacenters tend to be characterized by large caches, lower average clock speeds, wider IO and memory bandwidth. Those intended for consumer use tend to have high clock speeds, a bit less cache, and support for comparatively fewer IO devices/less memory. On the end-user side, you've got a further split between laptops/desktop machines and devices like phones, tablets, and so on. In both cases, the dominant IO buses used are PCIe and its variants (e.g., on the data center side you've got CXL), NVMe for storage is common in lots of places, everything supports Ethernet more or less (even WiFi uses the ethernet frame format), and so on. USB seems ubiquitous for peripherals on the end-user side. In short, these machines may be called "personal computers" and they may be PCs in the sense of being used primarily by one user, but contemporary data center machines have more in common with mainframes and high-end servers than the original PCs, and consumer machines are much closer architecturally to high end workstations than to yesteryear's PCs. My desktop machine is a Mac Studio with an ARM CPU; I call it a workstation and I think that's pretty accurate. At work, one of our EE's has a big x86 thing with some stupidly powerful graphics card that he uses to do board layout. It's a workstation in every recognizable sense, though it does happen to run Windows. - Dan C. From tuhs at tuhs.org Tue May 20 06:28:09 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 19 May 2025 20:28:09 +0000 Subject: [TUHS] Whither Workstations? (Was Re: Demise of AT&T) In-Reply-To: References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: On Monday, May 19th, 2025 at 12:45 PM, Dan Cross wrote: > On Mon, May 19, 2025 at 12:36 PM Noel Chiappa jnc at mercury.lcs.mit.edu wrote: > > > > [snip] > > > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > > > CPU's, it was the entire Minicomputer Industry, effectively extinct by > > > 1995. > > > > Same thing for the work-station industry (with Sun being merely the most > > notable example). I have a tiny bit of second-hand personal knowldge in this > > area; my wife works for NASA, as a structural engineer, and they run a lot of > > large computerized mathematical models. In the 70's, they were using CDC > > 7600's; they moved along through various things as technology changed (IIRC, > > at one point they had SGI machines). These days, they seem to mostly be using > > high-end personal computers for this. > > > > Some specialized uses (various forms of CAD) I guess still use things that > > look like work-stations, but I expect they are stock personal computers > > with special I/O (very large displays, etc). > > > > So I guess now there are just supercomputers (themselves mostly built out of > > large numbers of commodity CPUs), and laptops. Well, there is also cloud > > computing, which is huge, but that also just uses lots of commodity CPUs. > > > The CPU ISAs may be largely shared, but computing has bifurcated > into two distinct camps: those machines intended for use in > datacenters, and those intended for consumer use by end-users. > > CPUs intended for datacenters tend to be characterized by large > caches, lower average clock speeds, wider IO and memory bandwidth. > Those intended for consumer use tend to have high clock speeds, a bit > less cache, and support for comparatively fewer IO devices/less > memory. On the end-user side, you've got a further split between > laptops/desktop machines and devices like phones, tablets, and so on. > > In both cases, the dominant IO buses used are PCIe and its variants > (e.g., on the data center side you've got CXL), NVMe for storage is > common in lots of places, everything supports Ethernet more or less > (even WiFi uses the ethernet frame format), and so on. USB seems > ubiquitous for peripherals on the end-user side. > > In short, these machines may be called "personal computers" and they > may be PCs in the sense of being used primarily by one user, but > contemporary data center machines have more in common with mainframes > and high-end servers than the original PCs, and consumer machines are > much closer architecturally to high end workstations than to > yesteryear's PCs. > > My desktop machine is a Mac Studio with an ARM CPU; I call it a > workstation and I think that's pretty accurate. At work, one of our > EE's has a big x86 thing with some stupidly powerful graphics card > that he uses to do board layout. It's a workstation in every > recognizable sense, though it does happen to run Windows. > > - Dan C. This may be getting into the weeds a bit but don't forget industrial hardware, the stuff where you approach the blurry demarcation between CPU and MCU. This for me is always the third class when I'm discussing that sort of thing. Of course this also means "operating systems" closer to standalone applications sitting on top of some microkernel like (se)L4, but you did have VME-based workstations and UNIX versions specifically for VME systems. For me these walk a line between true workstations and minicomputers, but as usual that is from the perspective of having not been there. For the record, one of the canonical UNIX development environments from AT&T for WE32x00 stuff was a WE32100 and support chips thrown on a VME module running System V/VME. From what I know, VME is still quite common in industrial control. How much UNIX and workalikes constitute the OS landscape in today's VME ecosystem eludes me. Either way, I feel like this is a class of computers that frequently flies under the radar, but if we're talking strictly consumer stuff, yeah VME very quickly loses relevance. - Matt G. From crossd at gmail.com Tue May 20 06:54:44 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 19 May 2025 16:54:44 -0400 Subject: [TUHS] Whither Workstations? (Was Re: Demise of AT&T) In-Reply-To: References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: On Mon, May 19, 2025 at 4:28 PM segaloco via TUHS wrote: > On Monday, May 19th, 2025 at 12:45 PM, Dan Cross wrote: > > On Mon, May 19, 2025 at 12:36 PM Noel Chiappa jnc at mercury.lcs.mit.edu wrote: > > > > [snip] > > > > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > > > > CPU's, it was the entire Minicomputer Industry, effectively extinct by > > > > 1995. > > > > > > Same thing for the work-station industry (with Sun being merely the most > > > notable example). I have a tiny bit of second-hand personal knowldge in this > > > area; my wife works for NASA, as a structural engineer, and they run a lot of > > > large computerized mathematical models. In the 70's, they were using CDC > > > 7600's; they moved along through various things as technology changed (IIRC, > > > at one point they had SGI machines). These days, they seem to mostly be using > > > high-end personal computers for this. > > > > > > Some specialized uses (various forms of CAD) I guess still use things that > > > look like work-stations, but I expect they are stock personal computers > > > with special I/O (very large displays, etc). > > > > > > So I guess now there are just supercomputers (themselves mostly built out of > > > large numbers of commodity CPUs), and laptops. Well, there is also cloud > > > computing, which is huge, but that also just uses lots of commodity CPUs. > > > > > > The CPU ISAs may be largely shared, but computing has bifurcated > > into two distinct camps: those machines intended for use in > > datacenters, and those intended for consumer use by end-users. > > > > CPUs intended for datacenters tend to be characterized by large > > caches, lower average clock speeds, wider IO and memory bandwidth. > > Those intended for consumer use tend to have high clock speeds, a bit > > less cache, and support for comparatively fewer IO devices/less > > memory. On the end-user side, you've got a further split between > > laptops/desktop machines and devices like phones, tablets, and so on. > > > > In both cases, the dominant IO buses used are PCIe and its variants > > (e.g., on the data center side you've got CXL), NVMe for storage is > > common in lots of places, everything supports Ethernet more or less > > (even WiFi uses the ethernet frame format), and so on. USB seems > > ubiquitous for peripherals on the end-user side. > > > > In short, these machines may be called "personal computers" and they > > may be PCs in the sense of being used primarily by one user, but > > contemporary data center machines have more in common with mainframes > > and high-end servers than the original PCs, and consumer machines are > > much closer architecturally to high end workstations than to > > yesteryear's PCs. > > > > My desktop machine is a Mac Studio with an ARM CPU; I call it a > > workstation and I think that's pretty accurate. At work, one of our > > EE's has a big x86 thing with some stupidly powerful graphics card > > that he uses to do board layout. It's a workstation in every > > recognizable sense, though it does happen to run Windows. > > This may be getting into the weeds a bit but don't forget industrial hardware, the stuff where you approach the blurry demarcation between CPU and MCU. That's fair. I also ignored SBCs like the Raspberry Pi and its imitators and strictly embedded stuff. > This for me is always the third class when I'm discussing that sort of thing. Of course this also means "operating systems" closer to standalone applications sitting on top of some microkernel like (se)L4, but you did have VME-based workstations and UNIX versions specifically for VME systems. For me these walk a line between true workstations and minicomputers, but as usual that is from the perspective of having not been there. For the record, one of the canonical UNIX development environments from AT&T for WE32x00 stuff was a WE32100 and support chips thrown on a VME module running System V/VME. From what I know, VME is still quite common in industrial control. How much UNIX and workalikes constitute the OS landscape in today's VME ecosystem eludes me. My sense is that a lot of industrial hardware these days follows the same pattern as consumer devices, albeit often in a hardened chassis or with slightly different peripherals that allow them to work in environments with temperature extremes, poor airflow, and so on. I don't get the sense that VME is still the dominant factor that it once was in that space, but I'm not on a factory floor, either. Idly, I wonder how many industrial systems are built from, say, a Raspberry Pi compute module? Perhaps a more interesting third dimension would be safety-critical systems in automotive, aerospace, or medical applications. The PC in my doctor's office is just a small desktop thing running Windows and a bunch of software from EPIC, but the automagic blood pressure cuff with the nifty graphical display the nurse uses to take my vitals is something else entirely. > Either way, I feel like this is a class of computers that frequently flies under the radar, but if we're talking strictly consumer stuff, yeah VME very quickly loses relevance. Interestingly, some of the earlier Sun machines were VME based. As I recall, if you popped the hood off of a "pizzabox" Sun 3/50, there was a VME SBC in there with some drive bays. In that regard, the SPARCstation 1 paper is worth reading as an evolutionary marker. - Dan C. From stu at remphrey.net Thu May 22 01:30:20 2025 From: stu at remphrey.net (Stuart Remphrey) Date: Thu, 22 May 2025 01:30:20 +1000 Subject: [TUHS] Whither Workstations? (Was Re: Demise of AT&T) In-Reply-To: References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: On Tue, 20 May 2025 at 06:55, Dan Cross wrote: > Interestingly, some of the earlier Sun machines were VME based. As I > recall, if you popped the hood off of a "pizzabox" Sun 3/50, there was > a VME SBC in there with some drive bays. In that regard, the > SPARCstation 1 paper is worth reading as an evolutionary marker. > > - Dan C. > I recall installing small bunches of Sun 3/50 or 3/60 workstations, networked to a Sun 3/280 deskside server(-ish), for engineering offices and tertiary training rooms (around 1986 or so?) -- all VME-based -- after Sun switched from Multibus as used in the Sun 2/50 and 2/180(?) workstations. IIRC some Sun 3's desksides may still have used Multibus, for some I/O options (reel tape??) -- though I might be hallucinating that part... channeling my inner AI... - Stuart Remphrey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miod at online.fr Thu May 22 01:59:19 2025 From: miod at online.fr (Miod Vallat) Date: Wed, 21 May 2025 15:59:19 +0000 Subject: [TUHS] Whither Workstations? (Was Re: Demise of AT&T) In-Reply-To: References: <20250519134245.3F5CC18C088@mercury.lcs.mit.edu> Message-ID: > IIRC some Sun 3's desksides may still have used Multibus, for some I/O > options (reel tape??) -- though I might be hallucinating that part... > channeling my inner AI... Yes, there were a few Multibus devices using Multibus-to-VME adaptors; the Xylogics 450/451 SMD controller were run this way.