From tuhs at tuhs.org Mon May 4 05:59:50 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Sun, 3 May 2026 12:59:50 -0700 Subject: [TUHS] quick question on PDP-11 addressing Message-ID: I was re-reading the KT-11 docs, and got somewhat confused, and wanted to verify my memory, that (absent Split I&D) user programs had virtual addresses in the range 0-0xffff, and kernels the same: 0-0xffff. Thanks, I know this has been discussed before, but I'm giving a talk at IWP9 next week and want to make sure I'm not missing something. The KT-11 doc left me uncertain. You gotta love those old DEC docs, complete with SSI logic diagrams ... From tuhs at tuhs.org Mon May 4 06:33:24 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 3 May 2026 16:33:24 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: <20260503203324.B64EC107B7BB2@ary.qy> It appears that ron minnich via TUHS said: >I was re-reading the KT-11 docs, and got somewhat confused, and wanted >to verify my memory, that (absent Split I&D) user programs had virtual >addresses in the range 0-0xffff, and kernels the same: 0-0xffff. Yes. All PDP-11's were 16 bit machines and the addresses generated by programs were 16 bits. We used octai so it was 0 to 0177777. Different models had more or less elaborate schemes to map the 16 bit program addresses into 18 or 22 bit physical addresses. Some models had two modes, user and kernel, some had three, user, supervisor and kernel, with separate I and D addressing in each. For each of the two or six virtual address spaces there was an eight-entry map that mapped 8K pages of program addresses to 8K pages of physical memory. Unix systems as far as I know always treated user programs as a single chunk, or with I/D a single sharable chunk of I and another chunk of D. Bonus kludgery: Unibus addresses were 18 bits so on 22 bit systems (11/44 and /70) there was another address map from Unibus to physical memory for DMA devices. R's, John From tuhs at tuhs.org Mon May 4 06:35:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 3 May 2026 16:35:26 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: below On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS wrote: > I was re-reading the KT-11 docs, A PDP-11 has 16-bit registers, so all addressing must be within a 64K boundary. There are a few versions of the MMU - KS11 [CSS option for 11/20 - http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option] - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual ] - KT-11C,CD for the 11/45 class [45, 50, 55) [ https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf ]\ - For the 11/70, the MMU is builtin and the PARs are SW compatible with KT-11-C - and the KT-11D for the 40 class [40, 35] https://gunkies.org/wiki/KT11-D_Memory_Management_Unit - later 40 class processors (34, 34A and 60) use the KT-11A which is software compatible with the KT-11D In all cases, regardless of operation mode (user, supervisor, kernel), the CPU has a 16-bit address (virtual) space of 32K words (64K bytes). The MMU then maps those 16 bits into either an 18 or 22-bit physical address space. On a 40-class processor, that means a total of 64K bytes of address space at a time, regardless of how the data in that address space is used. On the 45 and 70 class processors have the funky I/D bit, which gives 2 separate 16-bit address spaces, instruction or data, so the MMU and OS can provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU, however, the '17th' which picks which of those two 64K byte hunks is being used is inferred from either and instruction or data fetch. > and got somewhat confused, and wanted > to verify my memory, that (absent Split I&D) user programs had virtual > addresses in the range 0-0xffff, and kernels the same: 0-0xffff. > > Thanks, I know this has been discussed before, but I'm giving a talk > at IWP9 next week and want to make sure I'm not missing something. The > KT-11 doc left me uncertain. > > You gotta love those old DEC docs, complete with SSI logic diagrams ... > From tuhs at tuhs.org Mon May 4 06:39:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 3 May 2026 16:39:26 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: As a PS and for completion, consider the registers: Register Usage Conventions - R0 and R1 (Accumulators/Return Values): These are used as temporary scratchpads for expression evaluation. When a function returns a value, it is placed in R0; if the return value is a 32-bit long, the high-order bits are placed in R0 and the low-order bits in R1. - R2, R3, and R4 (Local Variables): These are used for local variables within a function. By convention, their values must be saved to the stack upon entering a procedure and restored before exiting, ensuring the calling function's data remains intact. - R5 (Frame Pointer / Environment Pointer): Known in UNIX as the FP, R5 points to the current procedure's "activation record" or stack frame. It is used to access function arguments and local variables stored on the stack. - R6 (Stack Pointer / SP): This register tracks the top of the system stack. The hardware uses R6 implicitly during interrupts, traps, and subroutine calls (the JSR and RTS instructions). - R7 (Program Counter / PC): This register contains the memory address of the next instruction to be executed. Because it is a general register, it can be used with various addressing modes to provide immediate data and relative addressing On Sun, May 3, 2026 at 4:35 PM Clem Cole wrote: > below > > On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS wrote: > >> I was re-reading the KT-11 docs, > > A PDP-11 has 16-bit registers, so all addressing must be within a 64K > boundary. > > There are a few versions of the MMU > > - KS11 [CSS option for 11/20 - > http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option] > - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual > ] > - KT-11C,CD for the 11/45 class [45, 50, 55) [ > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf > ]\ > - For the 11/70, the MMU is builtin and the PARs are SW compatible > with KT-11-C > - and the KT-11D for the 40 class [40, 35] > https://gunkies.org/wiki/KT11-D_Memory_Management_Unit > - later 40 class processors (34, 34A and 60) use the KT-11A which is > software compatible with the KT-11D > > In all cases, regardless of operation mode (user, supervisor, kernel), the > CPU has a 16-bit address (virtual) space of 32K words (64K bytes). The MMU > then maps those 16 bits into either an 18 or 22-bit physical address > space. On a 40-class processor, that means a total of 64K bytes of address > space at a time, regardless of how the data in that address space is used. > On the 45 and 70 class processors have the funky I/D bit, which gives 2 > separate 16-bit address spaces, instruction or data, so the MMU and OS can > provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU, > however, the '17th' which picks which of those two 64K byte hunks is > being used is inferred from either and instruction or data fetch. > > > > >> and got somewhat confused, and wanted >> to verify my memory, that (absent Split I&D) user programs had virtual >> addresses in the range 0-0xffff, and kernels the same: 0-0xffff. >> >> Thanks, I know this has been discussed before, but I'm giving a talk >> at IWP9 next week and want to make sure I'm not missing something. The >> KT-11 doc left me uncertain. >> >> You gotta love those old DEC docs, complete with SSI logic diagrams ... >> > From tuhs at tuhs.org Mon May 4 07:10:47 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Sun, 03 May 2026 17:10:47 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <20260503203324.B64EC107B7BB2@ary.qy> References: <20260503203324.B64EC107B7BB2@ary.qy> Message-ID: <202605032110.643LAlMZ013157@ultimate.com> John Levine wrote: > ... there was an eight-entry map that > mapped 8K pages of program addresses to 8K pages of physical memory. DEC docs (or at least the KT11-C document Clem posted a link for) call them "variable size pages"; each of them can map anything from 32 words up to 4KW (8KB), but I think it's fairer to think of each (mode x I/D) virtual address space as broken into eight segments at 8KW boundaries. Each segment has the option to grow from up from the bottom of the segment, or down from the top. Not all systems make it easy to restart an instruction after a "fault" like one might expect from hearing the word "paging" CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared memory segments. From tuhs at tuhs.org Mon May 4 16:19:59 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Mon, 04 May 2026 02:19:59 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605032110.643LAlMZ013157@ultimate.com> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> Message-ID: <202605040619.6446JxTO022824@ultimate.com> I wrote: > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > memory segments. The sysv_pdp11.tgz I just found has has a library shmsys.c which indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c AND I've yet to spot the kernel support in the available CB Unix listings... From tuhs at tuhs.org Mon May 4 17:18:20 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 4 May 2026 17:18:20 +1000 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605040619.6446JxTO022824@ultimate.com> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> Message-ID: On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > I wrote: > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > memory segments. > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > AND I've yet to spot the kernel support in the available CB Unix > listings... You may be looking for MAUS? https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf maus.c cbunix4.pdf pp 64-66 sysent.c cbunix6.pdf pp 50-52 1, &maus, /* 58 = set up MAUS segment reg */ From tuhs at tuhs.org Mon May 4 17:50:53 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 04 May 2026 01:50:53 -0600 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> Message-ID: <202605040750.6447orQ8041827@freefriends.org> Jonathan Gray via TUHS wrote: > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > I wrote: > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > memory segments. > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > AND I've yet to spot the kernel support in the available CB Unix > > listings... > > You may be looking for MAUS? > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > maus.c cbunix4.pdf pp 64-66 > sysent.c cbunix6.pdf pp 50-52 > > 1, &maus, /* 58 = set up MAUS segment reg */ The UNIX 4.0 release notes that Matt sent out a little while ago mentions that on the PDP-11 MAUS is supported instead of the shared memory sys calls. FWIW. Arnold From tuhs at tuhs.org Mon May 4 19:35:38 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 04 May 2026 09:35:38 +0000 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605040750.6447orQ8041827@freefriends.org> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> Message-ID: On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS wrote: > Jonathan Gray via TUHS wrote: > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > I wrote: > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > > memory segments. > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > > AND I've yet to spot the kernel support in the available CB Unix > > > listings... > > > > You may be looking for MAUS? > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > maus.c cbunix4.pdf pp 64-66 > > sysent.c cbunix6.pdf pp 50-52 > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > The UNIX 4.0 release notes that Matt sent out a little while ago > mentions that on the PDP-11 MAUS is supported instead of the > shared memory sys calls. FWIW. > > Arnold > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 specific. Since shm is expected in future non-PDP-11 UNIX, a separate, more portable solution was developed (I don't know the internal name) which supports all the future platforms, but isn't workable in PDP-11 UNIX. Between this and other factors, SVR2 is the last USG UNIX to touch the PDP-11 as far as prevailing literature is concerned. For instance, I have the SVR2 System Release Description and it still mentions PDP-11/70 compatibility. That said, machid(1) as of SVR4 manuals lists pdp11 as a reportable target. I've never confirmed whether this is simply a matter of aged documentation or if somewhere deep inside AT&T they kept SysV going on PDP-11 past SVR2. For the record, 3B20 and 3B21 UNIX was supported long after SysV went the SCO route in the from of UNIX/RTR. That's only to point out that some of the 70s UNIX platforms do have continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. I have a Lucent training document on C in shipment currently, I'll see soon if it lends any credence to late-era PDP-11 support in the USG or BTL streams. Given BTL moving to VAX-11 in the early 80s though, anything post-that e.g. Lucent it's may yield nothing useful in the PDP-11 longevity question. - Matt G. From tuhs at tuhs.org Mon May 4 20:07:24 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 04 May 2026 04:07:24 -0600 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> Message-ID: <202605041007.644A7ObI052144@freefriends.org> segaloco via TUHS wrote: > On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS wrote: > > > Jonathan Gray via TUHS wrote: > > > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > > I wrote: > > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > > > memory segments. > > > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > > > AND I've yet to spot the kernel support in the available CB Unix > > > > listings... > > > > > > You may be looking for MAUS? > > > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > > > maus.c cbunix4.pdf pp 64-66 > > > sysent.c cbunix6.pdf pp 50-52 > > > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > > > The UNIX 4.0 release notes that Matt sent out a little while ago > > mentions that on the PDP-11 MAUS is supported instead of the > > shared memory sys calls. FWIW. > > > > Arnold > > > > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 > specific. Since shm is expected in future non-PDP-11 UNIX, a separate, > more portable solution was developed (I don't know the internal name) > which supports all the future platforms, but isn't workable in PDP-11 > UNIX. Between this and other factors, SVR2 is the last USG UNIX to touch > the PDP-11 as far as prevailing literature is concerned. For instance, I > have the SVR2 System Release Description and it still mentions PDP-11/70 > compatibility. That said, machid(1) as of SVR4 manuals lists pdp11 > as a reportable target. I've never confirmed whether this is simply a > matter of aged documentation or if somewhere deep inside AT&T they kept > SysV going on PDP-11 past SVR2. For the record, 3B20 and 3B21 UNIX was > supported long after SysV went the SCO route in the from of UNIX/RTR. > That's only to point out that some of the 70s UNIX platforms do have > continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere > in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. > Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. > I have a Lucent training document on C in shipment currently, I'll see > soon if it lends any credence to late-era PDP-11 support in the USG > or BTL streams. Given BTL moving to VAX-11 in the early 80s though, > anything post-that e.g. Lucent it's may yield nothing useful in the > PDP-11 longevity question. > > - Matt G. It is super unlikely that anything past SVR2 ran on the PDP-11. Demand paging was introduced sometime in the SVR3 period, along with STREAMS networking, the filesystem switch and RFS, and SVR4 was architectually very much like SunOS, with demand paging, a vnode-based filesystem architecture, both traditional and BSD fast filesystems, and with socket and STREAMS networking, NFS and I think even RFS. WWWWAAAAYYY too much to shoe-horn into an -11. The porting platform changed over time also, from -11 to Vax to 386 and 3Bxx, with older ones being dropped along the way. Arnold From tuhs at tuhs.org Tue May 5 01:59:59 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 4 May 2026 08:59:59 -0700 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605041007.644A7ObI052144@freefriends.org> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> <202605041007.644A7ObI052144@freefriends.org> Message-ID: related question, when people started getting their VAXes, what was the smallest configuration that ran Unix? On Mon, May 4, 2026 at 3:07 AM Arnold Robbins via TUHS wrote: > segaloco via TUHS wrote: > > > On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS < > tuhs at tuhs.org> wrote: > > > > > Jonathan Gray via TUHS wrote: > > > > > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > > > I wrote: > > > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported > shared > > > > > > memory segments. > > > > > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in > sysent.c > > > > > AND I've yet to spot the kernel support in the available CB Unix > > > > > listings... > > > > > > > > You may be looking for MAUS? > > > > > > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > > > > > maus.c cbunix4.pdf pp 64-66 > > > > sysent.c cbunix6.pdf pp 50-52 > > > > > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > > > > > The UNIX 4.0 release notes that Matt sent out a little while ago > > > mentions that on the PDP-11 MAUS is supported instead of the > > > shared memory sys calls. FWIW. > > > > > > Arnold > > > > > > > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 > > specific. Since shm is expected in future non-PDP-11 UNIX, a separate, > > more portable solution was developed (I don't know the internal name) > > which supports all the future platforms, but isn't workable in PDP-11 > > UNIX. Between this and other factors, SVR2 is the last USG UNIX to > touch > > the PDP-11 as far as prevailing literature is concerned. For instance, I > > have the SVR2 System Release Description and it still mentions PDP-11/70 > > compatibility. That said, machid(1) as of SVR4 manuals lists pdp11 > > as a reportable target. I've never confirmed whether this is simply a > > matter of aged documentation or if somewhere deep inside AT&T they kept > > SysV going on PDP-11 past SVR2. For the record, 3B20 and 3B21 UNIX was > > supported long after SysV went the SCO route in the from of UNIX/RTR. > > That's only to point out that some of the 70s UNIX platforms do have > > continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere > > in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. > > Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. > > I have a Lucent training document on C in shipment currently, I'll see > > soon if it lends any credence to late-era PDP-11 support in the USG > > or BTL streams. Given BTL moving to VAX-11 in the early 80s though, > > anything post-that e.g. Lucent it's may yield nothing useful in the > > PDP-11 longevity question. > > > > - Matt G. > > It is super unlikely that anything past SVR2 ran on the PDP-11. Demand > paging was introduced sometime in the SVR3 period, along with STREAMS > networking, the filesystem switch and RFS, and SVR4 was architectually > very much like SunOS, with demand paging, a vnode-based filesystem > architecture, both traditional and BSD fast filesystems, and with socket > and STREAMS networking, NFS and I think even RFS. > > WWWWAAAAYYY too much to shoe-horn into an -11. > > The porting platform changed over time also, from -11 to Vax to 386 and > 3Bxx, > with older ones being dropped along the way. > > Arnold > From tuhs at tuhs.org Tue May 5 02:26:03 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 4 May 2026 12:26:03 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> <202605041007.644A7ObI052144@freefriends.org> Message-ID: On Mon, May 4, 2026 at 12:07 PM ron minnich via TUHS wrote: > related question, when people started getting their VAXes, what was the > smallest configuration that ran Unix? > Originally the smallest memory configuration for the VAX-11/780 was 128KB. My alma mater was a hardware beta test site for the VAX-11/780 (in 1977). Our machine had 1MB of memory. I joined DEC as a software engineer in 1980. Nobody in the VAX software group knew of anyone running a 128KB VAX of any model. When VAX/VMS Version 4.0 came out in the mid-1980s there were still a few (4 or 5) 512KB VAX systems out there running VAX/VMS. VMS V4 would not run properly with less than 1MB of memory. After quite a bit of bellyaching and wrangling DEC decided that it was cheaper to simply give those 4 or 5 customers 512K more of memory for free rather than try to shoehorn VMS V4 into 512KB. For all later VAXen the minimum memory size was measured in megabytes. I would imagine that Unix would have no problem running on a 128KB VAX system, if any of those actually existed. More likely the smallest Unix configuration would be a 512KB VAX-11/725 or 11/730. -Paul W. From tuhs at tuhs.org Tue May 5 02:36:02 2026 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Mon, 4 May 2026 09:36:02 -0700 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> <202605041007.644A7ObI052144@freefriends.org> Message-ID: <7a330657-8294-4965-9878-9c549644cb30@gmail.com> On 5/4/26 8:59 AM, ron minnich via TUHS wrote: > related question, when people started getting their VAXes, what was the > smallest configuration that ran Unix? This isn't an exact answer to your question but in 1978(?) I did some contracting for a place in Santa Barbara that had just accepted delivery of a VAX 11/780 with 256K (!!!) of RAM. It ran VMS, not Unix, and was barely a single user system. They soon added another 512K and it made a miraculous improvement. Jon From tuhs at tuhs.org Tue May 5 03:04:36 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 4 May 2026 13:04:36 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> Message-ID: below. On Mon, May 4, 2026 at 5:35 AM segaloco via TUHS wrote: > On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS > wrote: > > > Jonathan Gray via TUHS > wrote: > > > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > > I wrote: > > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > > > memory segments. > > > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > > > AND I've yet to spot the kernel support in the available CB Unix > > > > listings... > > > > > > You may be looking for MAUS? > > > > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > For folk playing at home, Jonathan is pointing to the10 PDF's that are scans (but not OCRed) pr(1) listings of CB Unix 2.3 source code https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/raw/SourceCode/ > > > maus.c cbunix4.pdf pp 64-66 > > > sysent.c cbunix6.pdf pp 50-52 > > > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > > > > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 > specific. Right, to quote from page III "Acknowledgments" section on page III of CB-UNIX *Programmer's Manual Edition 2.3 * [ https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/raw/cbunix_intro.pdf ] "The form of this manual follows that of the *UNIX Programmer's Manual-Seventh Edition, Volume 1 *developed by M. D . Mcllroy. A large part of the present manual's contents is descended from the *UNIX Programmer's Manual-Sixth Edition* by K. Thompson and D. M. Ritchie (Bell Telephone Laboratories, May 1975) and the *PWB/UNIX User's Manuals* by I. A. Dolotta, R.C. Haight, and E. M. Piskorik, eds. (Bell Telephone Laboratories, May 1977). A special credit should also be given to the UNIX support effort of department 3624; their support of UNIX helped make this manual possible. The number of our colleagues who have contributed to UNIX and CB-UNIX software and documentation is, by now, too large to list here, but the usefulness and acceptance of UNIX and of CB-UNIX are true measures of their collective success." Now check the readme.txt file at the top of the CB_Unix TUHS archives area. The reader learns that CB-UNIX "was developed to address deficiencies inherent in Research Unix, notably the lack of interprocess communication and file locking, considered essential for a database management system. Several Bell System *operation support system products* were based on CB/UNIX, such as the *Switching Control Center System*. The primary innovations were power-fail restart, line disciplines, terminal types, and IPC features similar to System V's messages and shared memory." Remember, this readme.txt file was written many years later. UNIX 3.0/System III was still in development, so the mention of System V is intended to offer the reader a modern context to a historical fact. Thus, the first editions of CB-UNIX began as a set of changes to the first Research Editions that ran on the 11/20 without an MMU that Ken had [the DEC CSS group's KS-11]. Because it was running on an MMU-less PDP-11/20, I will most likely date this as the Research First or Second editions. CB-UNIX was developed for a product delivered to the Bell Operating Companies called SCCS (Switching Control Center System) — which should not be confused with Marc Rochkind's "Source Code Control System." Dale DeJager was the supervisor of the team in Columbus, and he explains what happened in a 1984 news message to net.unix [ https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/P_G_s9SJBrgJ ] — note the highlighting is mine: ... I was the supervisor of the group in Columbus for a number of years that was responsible for the development of CB-UNIX. The system was derived from the UNIX operating system that was used in the SCCS (Switching Control Center System), which incidentally was the first application of UNIX outside of research. (UNIX was running on an 11/20, at the time, without memory management and we deployed the first version of SCCS in New Jersey Bell in New Brunswick, NJ.) The SCCS version of UNIX had a number of unique features for the times: semaphores and line disciplines (in 1974!) for example. Hal Pearson was responsible for semaphores, and Bill Snider for line disciplines. Messages and shared memory were first added to CB-UNIX in about 1975 or 1976. Shared memory was called MAUS (pronounced moss, standing for Multiple Access User Space) and was derived from an earlier version done by R. J. Purdue. CB-UNIX became rather widely accepted within BTL as a base for turnkey Operations Systems--many of which have been described in the BSTJ. Note that CB-UNIX was not a derivative of UNIX/RT, but of Version 6 and Version 7. PWB UNIX† was also a derivative of Version 7. USG UNIX was originally a derivative of Version 6 and 7 with some CB-UNIX facilities added. Eventually, a decision was made to consolidate to two versions of UNIX: UNIX/TS and UNIX/RT. RT was a derivative of MERT, and TS a derivative of PWB UNIX. RT was to be used by Operations Systems, but was never too widely accepted. Eventually, UNIX/TS was augmented to have many of the features present in CB-UNIX (this was done by Roger Faulkner at Indian Hill, BTL. This, in turn, became the base for UNIX 4.0, which was never released externally. While this augmentation was going on, UNIX/TS was being changed into UNIX 3.0 which was release externally as SYSTEM III. In more recent history, CB-UNIX has been eliminated entirely in favor of UNIX 5.0. (one reason is because it never ran on anything other than the 11/70) I once had a viewgraph with all this on it which I had great fun trying to explain. As Dale says here, the target system for CB-UNIX was an 11/70. My understanding is that it wouldn't boot on a 40-class processor, but it would run on a 45-class. By the time of the CB-UNIX release (2.3), Research Seventh, as well as UNIX/TS from USG in Summit, had been released. > Since shm is expected in future non-PDP-11 UNIX Let me put that in context. The Summit-based Unix Support Group was a fairly recent creation [76-77 timeframe, I believe]. But the team, like Dale's in Columbus and other Bell Labs sites, wrote programs in support of the Bell Operating Companies. Those teams had been relying on features that CB-UNIX supported. By the mid-late 70's, AT&T management realized that UNIX >>system<< development was going on at many (they would determine, too many) BTL sites. This was the basis for USG in Summit (BTW — my experience at the time is that it may have cut down a number of "kernel" hacks and hackers, it was still very widespread for a reason I'll not mention here). Dale describes this as: "Eventually, a decision was made to consolidate to two versions of UNIX: UNIX/TS and UNIX/RT." But to do that, features that were private to some internal teams, like those from CB-UNIX, needed to be included in the standard versions, so that "products" being developed in the different labs and *AT&T subcompanies could run on the "common" system.* So the "expectation" really was a "customer requirement" from the other labs and the operating companies. USG's target customer within the Bell System had production code that needed to run. If AT&T were to have a "standard OS" for the Bell System, shared memory and several other CB-UNIX features would have to be supported. > , a separate, more portable solution was developed (I don't know the > internal name) which supports all the future platforms, but isn't workable > in PDP-11 UNIX. I'm not so sure about the statement that the PDP-11 is unworkable, as it has been the workhorse for the entire Bell System. According to some of my DEC colleagues, AT&T was not only the #1 customer for DEC but, for a long time, continued to buy 11/70s instead of Vaxen. As I understand it, AT&T's taste for the 11/70 is one of the reasons DEC began developing the single-chip F-11, T-11, and finally the J-11; along with the J-11-based systems, the 11/73, 11/83, and 11/93 in 1984, 1985, and 1990. However, full production of AT&T's own BELLMAC-32, *a.k.a.*, 32100, started in 1982, and by 1984, we see their 3B2, 3B5, and 3B15 systems that are built on them. I think support for newer versions of the operating system was just not prioritized. That is to say, the need for spending effort on it by then was not there. as much as by that time the 11/70 was being phased out as both a development and operating company deployed system. > Between this and other factors, SVR2 is the last USG UNIX to touch the > PDP-11 as far as prevailing literature is concerned. For instance, I have > the SVR2 System Release Description and it still mentions PDP-11/70 > compatibility. SVR1 supported both Vax and PDP-11. My memory was that the commercial customers outside the Bell Systems could order either version. A bit later, SVR2 still supported the PDP-11 architecture, but it was its transitional release (what DEC would have called 'legacy products'). The VAX-11/780 replaced the PDP-11 as the official "reference platform" (*a.k.a.,* porting base) for this version, meaning all subsequent development and optimizations were first implemented on the VAX before being ported to other machines. By SVR3, the 3B2 was. > That said, machid(1) as of SVR4 manuals lists pdp11 as a reportable > target. I've never confirmed whether this is simply a matter of aged > documentation or if somewhere deep inside AT&T they kept SysV going on > PDP-11 past SVR2. It was a big enough company, particularly when you include the operating companies. So even after being split up, the PDP-11 was still a large installed base within the former Bell System. But the ROI on continued support was clearly not there for USG's management. > For the record, 3B20 and 3B21 UNIX was supported long after SysV went the > SCO route in the from of UNIX/RTR. That's only to point out that some of the 70s UNIX platforms do have > continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere in > BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. I agree, see previous comment. > Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. Agreed. > I have a Lucent training document on C in shipment currently, I'll see > soon if it lends any credence to late-era PDP-11 support in the USG or BTL > streams. Given BTL moving to VAX-11 in the early 80s though, anything > post-that e.g. Lucent it's may yield nothing useful in the PDP-11 longevity > question. I understand. Clem † Dale is referring to PWB 2.0 in this context. The original PWB (a.k.a. 1.0) was a delta to Research Sixth. From tuhs at tuhs.org Wed May 6 15:26:01 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 06 May 2026 05:26:01 +0000 Subject: [TUHS] DECtapes under the UNIX room floor Message-ID: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the UNIX room floor while he was searching for early distributions. Are these the Dennis_Tapes? > However, some old paper tapes and DECtapes of unknown content were discovered > underneath the floor-boards in the UNIX room. [page 64] https://www.tuhs.org/Archive/Documentation/Theses/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf > All, way back when, Dennis sent me [Warren] some DECtape images to look after. https://www.tuhs.org/pipermail/tuhs/2023-July/028590.html Thalia From tuhs at tuhs.org Wed May 6 15:47:27 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 6 May 2026 15:47:27 +1000 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote: > In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the > UNIX room floor while he was searching for early distributions. Are these the > Dennis_Tapes? I would almost certainly say yes. I can dig out Dennis' original e-mail when he first mentions the DEC tapes. Will try to find it ... Warren From tuhs at tuhs.org Wed May 6 15:57:51 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 6 May 2026 15:57:51 +1000 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote: > In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the > UNIX room floor while he was searching for early distributions. Are these the > Dennis_Tapes? Here's what I've got. In Jan 1999 I sent this e-mail to dmr: Now, about that V2 DECtape. In the July 1984 issue of ;login: there is a Unix trivia quiz. At the top, it says: The following quiz was distributed at the Salt Lake City conference by Rob Pike... Jim McKie had the best score for an individual (57) and was awarded an authenticated 1972 DECtape containing UNIX Version 2. In 1995, I emailed Jim and asked him what had happened to the tape? He replied: a couple of years ago we sent that dectape along with a bunch of others we found under to floor to keith bostic at berkeley who had resurrected a dectape drive. i don't remember getting it back. i'll enquire. i loved pdp11's. So I assume that it must have been one of the DECtapes you had Keith read. However, somehow it got lost because you haven't mentioned it. So: do you guys still have those DECtapes, or does Keith have them? But earlier, in Sept 1997, Dennis has sent me this e-mail: The files here were read from old DECtapes made in the early 1970s. Paul Vixie and Keith Bostic unearthed a DECtape drive and made it work, we unearthed the tapes. The tapes were written in either the 'tap' or 'tp' format, which are similar in that they have a directory of up to 192 entries at the start with names and other information including the size and tape address of the files. 'tp' was the later format, and was in use by November 1973, the date of the 4th edition manual. With `tap', the times associated with the files were recorded in pre-modern units: sixtieths of a second, from an origin that changed. The first three editions of the manual had BUGS sections noting that 32 bits can represent only about 2.5 years in this unit, and this implied continuing crises as the time overflowed. I believe that the change to use seconds for Unix time took place along with the change to the C version of the operating system, which occurred about the end of the summer of 1973, and also that the change from `tap' to `tp' took place at the same time. (This is consistent with the dates of the 3rd and 4th edition manuals). Thus the dates recorded with the `tp' tapes probably correspond reliably to the modification dates of the files at the time of saving them (of course, this gives only a upper bound on their creation, since they might have been copied or trivially touched just before saving them). Recovering the proper dates for the `tap' tapes is less reliable, because there was at least one change of epoch (from 1971 to 1972) during the period they could possibly have been produced. I believe that the 1972 epoch is most likely the correct one for the tapes here. apl Ken's apl program, together with his rendition of astro (translated from Morris's Fortran). Probably OK dates, 1975-76. config Ken's program for configuring PDP11s. It told you price, maintenance, checked for bus loading. Interesting for DEC price lists in 1974. dmr Random stuff from my directory. Most probable dates: 1972. The `paper' directory contains a version of the original SOSP Unix paper (haven't compared it with the CACM version). cgd appears to be an experiment in converting Fortran threaded code to machine language, using a warmed over version of the earliest C code generator. It's written in NB, not C. fd is some fortran programs, in particular a polynomial root-finder I found somewhere. aman is some version of the PDP-11 assembler manual. fd is a fortran program for plotting functions of 2 variables. notes1 and notes2 are evidently notes I made for myself for a talk on unix. They are quite interesting. tty.s is evidently the terminal processing routine for an assembly-language version of unix. note that it handles IBM 2741 terminals with two kinds of typeballs (938 and correspondence). crypt.c encrypts using a variant of the Hagelin machine. pig.b is an interesting artifact: it is a B program that echoes what you type in Pig latin. (Incidentally, there is a translation of this program into C, dated 1978, in a subdirectory that still spins on a disk attached to the Unix machine where I get my mail.) dmr2 the let directory contains drafts of a bunch of letters to people who asked about unix in early days. (lett6 is to andy tanenbaum). The let directory contains drafts of a bunch of letters to people who asked about unix in early days. (lett6 is to andy tanenbaum). Other bits: restric discusses some early thoughts about types in C. I don't know who it was addressed to (perhaps even to myself). ct is an even briefer list about what I though was important. iosys is a manual for writing system device drivers. e-pi Our programs to compute e and pi to a million places. The one for e worked; it took some months on a time-shared PDP-11 without memory mapping. Incidentally the J directory name is correct: this sequence printed the greek letter pi on a Teletype model 37. Plan 9 won't let me create this. It wants me to use Unicode! games Ken's work on various games. Check out chomp/c0.c, which has a briefly-existing form of structure declaration using parentheses instead of braces. ken check out the values of the AT&T Savings plan in the early 70s (plan), and what interested Ken's son (corey/*) then. ken-du Here, you can read our wtmp files from 1974 and 1975. ken-sky A bunch of interesting old ken stuff (eg a version of the units program from the days when the dollar fetched 302.7 yen) last1120c The source for a version of C that compiled for the PDP-11/20. It didn't have structures, it didn't have #define, and pointers were declared p[]. But look! The initialization routine says init("float", 2); init("double", 3); /* init("long", 4); */ init("auto", 5); init("extern", 6); nsys If the decoding of the date on the tape is correct (Aug 1973), this is the source for the earliest C version of Unix likely to be recovered. `nsys' meant the C version rather than the assembly version, and Aug 73 is plausible for a running instance of this system. prestruct-c This is approximately the same era as `last1120c,' but 6 months later; despite the name, this compiler now handles structures. (The struct keyword has displaced `long' as keyword number 4!) The name of the tape indicates that the state of the compiler was saved just before converting it to use structures inside itself. The compiler is much less complete--just the c??.c files, not the tables for code generation. s1 I haven't cracked this yet. s2 Is not source, but a dump of (parts of) /bin, /etc, /usr/lib, and bits of a few other directories. Caution! The tape uses absolute pathnames, and is dangerous to extract unless you want to install old PDP-11 binaries. (tap format). sys-dsu This system didn't come directly from us. After poking around it for a while I found a file containing this (in cr.h): /***************************************************************** ** ** ** U C L A Data Secure Unix ** ** ** ** Copyright 1977 ** ** ** ** Mark Kampe, Charles Kline, Gerald Popek, Evelyn Walton ** ** ** *****************************************************************/ So, it appears that `dsu' is `data-secure unix' and this is a record of one of the early security projects! They must have sent it to us. Might be fun to examine it; I suppose we should tell Gerry Popek of its existence. unix This is probably a `boot' tape; it has binary images of the system and some raw utility programs for use when booting (memory testers, loaders for diagnostics, and the like). Cheers, Warren From tuhs at tuhs.org Wed May 6 16:47:59 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 6 May 2026 16:47:59 +1000 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote: > In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the > UNIX room floor while he was searching for early distributions. Are these the > Dennis_Tapes? And, finally, the tape images are at: https://www.tuhs.org/Archive/Applications/Dennis_Tapes Cheers, Warren From tuhs at tuhs.org Wed May 6 18:12:15 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 06 May 2026 08:12:15 +0000 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: Interesting. I’ve reviewed Dennis_Tapes before, but different bits stand out this time. On May 5, 2026, at 22:57, Warren Toomey wrote: > The following quiz was distributed at the Salt Lake City conference > by Rob Pike... Jim McKie had the best score for an individual (57) and was > awarded an authenticated 1972 DECtape containing UNIX Version 2. Neat. I scanned a paper from this 1984 USENIX. https://archive.org/details/nielsen_object_kernel_1984 > With `tap', the times associated with the files were recorded > in pre-modern units: sixtieths of a second, from an origin that > changed. Was there a precedent for the choice of sixtieths of a second? > dmr > Random stuff from my directory. Most probable dates: 1972. > The `paper' directory contains a version > of the original SOSP Unix paper (haven't compared > it with the CACM version). This should be rendered and added to TUHS. > cgd appears to be an experiment in converting > Fortran threaded code to machine language, > using a warmed over version of the earliest C > code generator. It's written in NB, not C. This would be a great reference for reconstructing B/NB, along with the well-known last1120c and prestruct-c! > notes1 and notes2 are evidently notes I made for myself > for a talk on unix. They are quite interesting. “UNIX is running on at least five PDP-11”. Modified 1972-03-15. This should also be rendered. > dmr2 > the let directory contains drafts of a bunch of letters > to people who asked about unix in early days. (lett6 > is to andy tanenbaum). Dr. Paul C. Abegglen from the University of Utah requested UNIX on 1973-11-21 and Dennis replied in lett8. I wish I knew more about him, but I’ve found very little. He’s from the Chemistry Department, not computer graphics like Martin Newell (who apparently received UNIX V4 in June 1974), so a connection seems tenuous. Martin recognized the name, but nothing else, when I asked. > games > Ken's work on various games. Check out chomp/c0.c, > which has a briefly-existing form of structure > declaration using parentheses instead of braces. This has the source to bj, moo, chess, wump, and ttt (but not cubic)! > ken > check out the values of the AT&T Savings plan in the > early 70s (plan), and what interested Ken's son (corey/*) > then. distr/ has Ken’s 1975 licensee list that I’ve analyzed, but I glossed over dsk{b,m,s}, which are the listings of the binary, manual, and source distributions. pwd/ is a password cracker. > ken-sky > A bunch of interesting old ken stuff (eg a version of > the units program from the days when the dollar fetched > 302.7 yen) nih.a is Ken’s trusting trust backdoor (https://research.swtch.com/nih). > sys-dsu > This system didn't come directly from us. After > poking around it for a while I found a file containing > this (in cr.h): > > /***************************************************************** > ** ** > ** U C L A Data Secure Unix ** > ** ** > ** Copyright 1977 ** > ** ** > ** Mark Kampe, Charles Kline, Gerald Popek, Evelyn Walton ** > ** ** > *****************************************************************/ > > So, it appears that `dsu' is `data-secure unix' and this is a > record of one of the early security projects! They must > have sent it to us. Might be fun to examine it; I suppose > we should tell Gerry Popek of its existence. It would be interesting to analyze this to tease out an intermediate snapshot around January 1977. > unix > This is probably a `boot' tape; it has binary images of > the system and some raw utility programs for use when booting > (memory testers, loaders for diagnostics, and the like). This is dated 1975-07-14. Has it been analyzed? Thalia From tuhs at tuhs.org Wed May 6 18:32:14 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 6 May 2026 03:32:14 -0500 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: <20260506083214.un4cgnw7xzkevbm3@illithid> At 2026-05-06T08:12:15+0000, Thalia Archibald via TUHS wrote: > > With `tap', the times associated with the files were recorded > > in pre-modern units: sixtieths of a second, from an origin that > > changed. > > Was there a precedent for the choice of sixtieths of a second? We may be spoiled for choice; sexagesimal goes back over 4,000 years to the ancient Sumerians. ;-) It's also the mains line frequency in North America. I don't know if anyone's ever clocked a digital computer that slow, but some peripherals might have stuck a rectifier on the mains and used that for a clock. Here's an app note from Renesas for a real-time clock that works that way. Crystals go home! https://www.renesas.cn/zh/document/apn/an1342-using-60hz-power-line-frequency-accurate-real-time-clock-timebase > > dmr > > Random stuff from my directory. Most probable dates: 1972. > > The `paper' directory contains a version > > of the original SOSP Unix paper (haven't compared > > it with the CACM version). > > This should be rendered and added to TUHS. ...and gotten into Clem Cole's hands so we can see how groff fares as the renderer. ;-) 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 tuhs at tuhs.org Wed May 6 20:11:00 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Wed, 6 May 2026 06:11:00 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <20260506083214.un4cgnw7xzkevbm3@illithid> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> Message-ID: On Wed, May 6, 2026 at 4:32 AM G. Branden Robinson via TUHS wrote: \> > Was there a precedent for the choice of sixtieths of a second? > > We may be spoiled for choice; sexagesimal goes back over 4,000 years to > the ancient Sumerians. ;-) > > It's also the mains line frequency in North America. I don't know if > anyone's ever clocked a digital computer that slow, but some peripherals > might have stuck a rectifier on the mains and used that for a clock. See the '"Electronics" and "Computing" sections of https://en.wikipedia.org/wiki/Jiffy_(time). From tuhs at tuhs.org Thu May 7 03:25:36 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Wed, 06 May 2026 13:25:36 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> Message-ID: <202605061725.646HPaad081924@ultimate.com> John Cowan wrote: > See the '"Electronics" and "Computing" sections of > https://en.wikipedia.org/wiki/Jiffy_(time). The "Computing" section is pretty light on history. DEC had a long history of 60Hz "line time" or "mains" clocks. Wall clocks that use synchronous motors (demonstrated by Tesla in 1893, and common since the first part of the 20th century) depend on long-term accuracy of line frequency. PDP-7 UNIX depends on the PDP-4/7 feature of location 7 being decremented at 60Hz and generating an interrupt on overflow. The PDP-6 has a "power line frequency" clock in the built-in APR (arithmetic processor) device, and the KA10 (PDP-10, the PDP-6 follow-on) has readable bit in the APR device indicating that the system was on 50Hz power. I know less about PDP-5/8 and PDP-11s, but line time clocks were present, or available as options (DK8-EA on the PDP-8/E, DL11-W, KW11 on PDP-11s, the 11/03 has a switch on the power supply for LTC). From tuhs at tuhs.org Thu May 7 03:37:14 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 06 May 2026 17:37:14 +0000 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <202605061725.646HPaad081924@ultimate.com> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> Message-ID: On Wednesday, May 6th, 2026 at 10:25, Phil Budne via TUHS wrote: > John Cowan wrote: > > See the '"Electronics" and "Computing" sections of > > https://en.wikipedia.org/wiki/Jiffy_(time). > > The "Computing" section is pretty light on history. > > DEC had a long history of 60Hz "line time" or "mains" clocks. Well and tying in UNIX, BTL and AT&T had much experience in the realm of AC generation of all kinds between ringing generators, lamp interruptors, magnetos, and so on. Heck, BTL was even working on a real-time clock circuit for PDP-11s in the mid 70s: https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1048_A_Continuous_Service_RTC_for_Digital_Computers.pdf - Matt G. From tuhs at tuhs.org Thu May 7 04:13:34 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Wed, 06 May 2026 14:13:34 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> Message-ID: <202605061813.646IDYhk082929@ultimate.com> > https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1048_A_Continuous_Service_RTC_for_Digital_Computers.pdf Looks like a combination of Looks like a combination "RTC" (real time, "time of year" (TOY), or "wall" clock) like the PC BIOS/CMOS clock chip (or an I2C RTC), which by default uses line frequency, and ALSO an LTC (or line time clock) interrupt source of "jiffies" CTSS (the progenitor of both Multics and DEC timesharing systems) had a "chronolog" device (attached as a magtape drive?) that supplied the current time, month and day (but not year!), while even large (million dollar) DEC timesharing systems in the 1970's and 80's expected a human operator to be present to enter the date and time. But I can understand AT&T wanting embedded billing systems to have good timestamps! I wonder: Was the VAX 11/780 the first DEC system that came with an RTC/TOY clock out of the box? From tuhs at tuhs.org Thu May 7 04:19:58 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 6 May 2026 14:19:58 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: On Wed, May 6, 2026 at 4:12 AM Thalia Archibald via TUHS wrote: > > > Was there a precedent for the choice of sixtieths of a second? > Yes, DEC used line frequency from very early on in their processors. For the original PDP-11s (/20, 40, 45, 70), the KW11-L (not be confused with the KW-11P) was a single high card http://www.bitsavers.org/pdf/dec/pdp11/1140/EK-KW11L_TM-002_KW11-L_Line_Time_Clock_Manual_Jul74.pdf [there is a picture of in on gunkies: https://gunkies.org/wiki/KW11-L_Line_Time_Clock ], the functionality was added to the DL11-W, so when it was used as the console KL11 it also acted as a KW11-L The purpose is to produce interrupts at a rate of 50 or 60 Hz, driven from the AC power provided to the CPU's power supply [which is why UNIX is configured appropriately]. If I understand the history correctly, the PDP-5 (1963): is the first DEC machine to offer a Type 137 Real Time Clock, which could be configured to trigger interrupts at the power line frequency (60Hz or 50Hz). This design directly influenced the later PDP-8. PDP-8 (1965): Supported the DK8-EA (and later the DK8-L and DK8-P) real-time clocks. The DK8-L Line Frequency Clock was functionally identical to the KW11-L, providing a flag and interrupt every 16.6ms or 20ms. PDP-6 (1964): As a large-scale system, it had a central clock (the Type 701) that provided several fixed frequencies, including a line frequency signal for system timekeeping. PDP-7 (1965): Offered the Type 175 or Type 144 real-time clocks. Like the PDP-5, these could be set to line frequency for basic task scheduling. From tuhs at tuhs.org Thu May 7 05:59:01 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 6 May 2026 15:59:01 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <202605061813.646IDYhk082929@ultimate.com> References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> <202605061813.646IDYhk082929@ultimate.com> Message-ID: On Wed, May 6, 2026 at 2:13 PM Phil Budne via TUHS wrote: > I wonder: Was the VAX 11/780 the first DEC system that came with an > RTC/TOY clock out of the box? > Sort of. It was not battery-backed up, which is why both VMS and UNIX require the time to be set. IIRC first Vaxen to have a battery to cover the TOY on a power outage, were the Mayflower machines (uVax and VaxStation systems). The J-11-based systems had a TOY, as did the 23+ (not the 23). FWIW: I've been trying to get Supnik to allow support for them into SIMH and then set via the host. Bob's solution is when you start SIMH, it assume is was from power-off, which is supported by all OS's on all models of both. From tuhs at tuhs.org Thu May 7 06:51:07 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 6 May 2026 13:51:07 -0700 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: On Fri, Jan 27, 2023 at 5:23 PM Kevin Bowling wrote: > > > > On Fri, Jan 27, 2023 at 1:54 AM wrote: >> >> Hi. >> >> I've been using trn for decades to read a very few USENET groups. Until recently I've >> been using aioe.org as my NNTP server but it seems to have gone dark. Before that >> I used eternal-september.org, but when I try that I now get: >> >> | $ NNTPSERVER=news.eternal-september.org trn >> | Connecting to news.eternal-september.org...Done. >> | >> | Invalid (bogus) newsgroup found: comp.sys.3b1 >> | >> | Invalid (bogus) newsgroup found: comp.sources.bugs >> | >> | Invalid (bogus) newsgroup found: comp.misc >> | >> | Invalid (bogus) newsgroup found: comp.compilers >> | .... >> >> And those all are (or were!) valid groups. If anyone has suggestions for a good >> free NNTP server, please let me know. Privately is fine. I'm at a bit of >> a loss otherwise. > > > I maintain inn and some related ports for FreeBSD. I run a public server at csiph.com and am happy to provide accounts or peering to interested parties. Read access is open. I am working on a new thing http://csiph.com/groups. Search indexing is currently paused while I move storage to enterprise flash but covers up through comp.* History is about 10-20 years deep depending on the hierarchy. I still need to figure out how to back fill everything, the goal is to fully replace Google Groups for historical research. > >> >> Thanks, >> >> Arnold From tuhs at tuhs.org Thu May 7 08:22:51 2026 From: tuhs at tuhs.org (babydr DBA James W. Laferriere via TUHS) Date: Wed, 6 May 2026 14:22:51 -0800 (AKDT) Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <809651a3-42be-e680-3eee-ad885dcfffdf@baby-dragons.com> Thank You , Kevin . JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From tuhs at tuhs.org Thu May 7 08:49:35 2026 From: tuhs at tuhs.org (Erik E. Fair via TUHS) Date: Wed, 06 May 2026 15:49:35 -0700 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <202605061813.646IDYhk082929@ultimate.com> Message-ID: <5088.1778107775@cesium.clock.org> I have a tickle in my memory that the Unix V7 (or 2BSD?) answer to a lack of battery-backed ToD/ToY RTC was using the last modify date of inode #2 in the root filesystem as "close enough for government work" precisely because that'd be the last one modified in a clean shutdown, and definitely better than starting time_t zero (epoch: 00:00 Jan 1 1970 GMT). There was also the issue for many years of having to kill cron before doing a big delta time change: cron would wake up suddenly hours or days later than it thought the last time it had run, and would spawn all work it needed to run to "catch up" ... Erik From tuhs at tuhs.org Thu May 7 09:14:21 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 6 May 2026 17:14:21 -0600 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: <5088.1778107775@cesium.clock.org> References: <202605061813.646IDYhk082929@ultimate.com> <5088.1778107775@cesium.clock.org> Message-ID: On Wed, May 6, 2026, 4:49 PM Erik E. Fair via TUHS wrote: > I have a tickle in my memory that the Unix V7 (or 2BSD?) answer to a lack > of battery-backed ToD/ToY RTC was using the last modify date of inode #2 in > the root filesystem as "close enough for government work" precisely because > that'd be the last one modified in a clean shutdown, and definitely better > than starting time_t zero (epoch: 00:00 Jan 1 1970 GMT). > BSD does that to this day. Warner There was also the issue for many years of having to kill cron before doing > a big delta time change: cron would wake up suddenly hours or days later > than it thought the last time it had run, and would spawn all work it > needed to run to "catch up" ... > > Erik > From tuhs at tuhs.org Thu May 7 11:20:43 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 6 May 2026 21:20:43 -0400 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <20260507012043.6552B1086AB32@ary.qy> >>> | Connecting to news.eternal-september.org...Done. >>> | >>> | Invalid (bogus) newsgroup found: comp.sys.3b1 >>> | >>> | Invalid (bogus) newsgroup found: comp.sources.bugs >>> | >>> | Invalid (bogus) newsgroup found: comp.misc >>> | >>> | Invalid (bogus) newsgroup found: comp.compilers I still moderate comp.compilers and feed it directly to eternal-september. You must have misconfigured something. R's, JOhn From tuhs at tuhs.org Thu May 7 11:23:19 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 6 May 2026 21:23:19 -0400 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <20260507012043.6552B1086AB32@ary.qy> References: <202301270853.30R8rif6014271@freefriends.org> <20260507012043.6552B1086AB32@ary.qy> Message-ID: On Wed, May 6, 2026 at 9:20 PM John Levine via TUHS wrote: > >>> | Connecting to news.eternal-september.org...Done. > >>> | > >>> | Invalid (bogus) newsgroup found: comp.sys.3b1 > >>> | > >>> | Invalid (bogus) newsgroup found: comp.sources.bugs > >>> | > >>> | Invalid (bogus) newsgroup found: comp.misc > >>> | > >>> | Invalid (bogus) newsgroup found: comp.compilers > > I still moderate comp.compilers and feed it directly to eternal-september. > You must have misconfigured something. >From the earlier quoted text, the error messages above were from 2023. - Dan C. From tuhs at tuhs.org Thu May 7 23:27:52 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Thu, 7 May 2026 09:27:52 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> <202605061813.646IDYhk082929@ultimate.com> Message-ID: On Wed, May 6, 2026 at 3:59 PM Clem Cole via TUHS wrote: > On Wed, May 6, 2026 at 2:13 PM Phil Budne via TUHS wrote: > > > I wonder: Was the VAX 11/780 the first DEC system that came with an > > RTC/TOY clock out of the box? > > > Sort of. It was not battery-backed up, which is why both VMS and UNIX > require the time to be set. IIRC first Vaxen to have a battery to cover > the TOY on a power outage, were the Mayflower machines (uVax and > VaxStation systems). The J-11-based systems had a TOY, as did the 23+ (not > the 23). > > On the 11/780 there was an optional battery backup available that allowed the PDP-11/03-based console subsystem to maintain the TOY clock when the system is powered down. The 11/75 0 also had an optional battery backup for the TOY clock. TOY clock battery backup was not available on the 11/730. This prompted Dick Hustvedt, chief VAX/VMS development engineer, to play a brilliant April Fools prank. On April 1 the VMS Group's 11/730 had a new peripheral. It was a sundial on a stand. There was a photocell positioned at the 12 o'clock position. The sundial was plugged into the 11/730's UNIBUS adapter. On the sundial was a very authentic-looking (it was made using the actual fonts and layout) DEC marketing brochure claiming the device to be an "SD730 Fixed Head Solar Horologue". This device could detect noon and set the 11/730's TOY clock accordingly. -Paul W. From tuhs at tuhs.org Fri May 8 00:13:14 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 7 May 2026 10:13:14 -0400 Subject: [TUHS] DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> <202605061813.646IDYhk082929@ultimate.com> Message-ID: On Thu, May 7, 2026 at 9:28 AM Paul Winalski wrote: > TOY clock battery backup was not available on the 11/730. This prompted > Dick Hustvedt, chief VAX/VMS development engineer, to play a brilliant > April Fools prank. On April 1 the VMS Group's 11/730 had a new > peripheral. It was a sundial on a stand. There was a photocell positioned > at the 12 o'clock position. The sundial was plugged into the 11/730's > UNIBUS adapter. On the sundial was a very authentic-looking (it was made > using the actual fonts and layout) DEC marketing brochure claiming the > device to be an "SD730 Fixed Head Solar Horologue". This device could > detect noon and set the 11/730's TOY clock accordingly. > And for those readers who never had the pleasure of having a meeting in ZK03 and seeing it, "SD730 Fixed Head Solar Horologue", along with the brochure, lived in his memory in a clear plexiglass display in a conference room. After Compaq sold the building, I sometimes wondered what happened to it and to some of the interesting artifacts that decorated each conference room, each of which had been named after a famous Mathematician or Computer Scientist, rather than numbered. Clem From tuhs at tuhs.org Fri May 8 09:55:33 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 07 May 2026 23:55:33 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> Message-ID: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> Received a question from Thalia Archibald concerning my use of the nomenclature "PG3" vs Pirzada's "Gen3.0". I pulled together the info below, seems like it might be interesting to the broader audience: So it's a bit fuzzy when you get into the weeds. This document[1] defines the acronym "PG" as such: > At the highest level in the document hierarchy is the > Program Document (PG) Index that lists all of the documents > associated with a program generic. A single PG-level directory > occupies the corresponding position in the file system hierarchy. So within their source control structure you would have directories: pg-1c300-01 (issue 1) pg-1c300-02 (issue 2) And then under those the "PR" directories containing the individual groupings of source files, other documents, etc. This isn't what I originally based my use of this acronym on though, rather just Program Generic (PG). Typically if I do see a shorter name, the system is just referred to as a "Generic", proper noun. This was common practice within AT&T and did not just apply to UNIX[2][3]. In fact, this first round of USG UNIX (before UNIX/TS and later) was very "Bell-ish" compared to later efforts. The manuals were the only ones rendered to Bell System standards in that they had the OSD headers with document ID, issue, date, etc. rather than just the standard manpage masthead. Several of the USG documents of the time look like the same typesetting package used for 3ESS generic pidents for instance. As I was gathering some of this info, I keep seeing PG-1C300 used where the system is referred to in short. This actually makes sense given AT&T's use of the "PG" prefix for a number of different projects. For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built on UNIX by WECo for a frame system in telco offices[5], has documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix for the underlying generic. Outside of UNIX, PG-3H903 is one of the 3ESS generics[6]. After compiling all of that info, I'm inclined to say that the "canonical" names in increasing length are "PG-1C300", then "Generic", then "Program Generic". I would think given Pirzada's being at AT&T at the time though the "Gen3.0" etc. nomenclature would also be acceptable, just maybe not "period". - Matt G. P.S. As always this is just my own research, I wasn't there so I'd certainly get some second opinions if available. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf [2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf [3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf [4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf [5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf [6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf From tuhs at tuhs.org Fri May 8 09:59:05 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Thu, 07 May 2026 23:59:05 +0000 Subject: [TUHS] Name of UNIX Program Generic Message-ID: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev> What was the common shorthand for UNIX Program Generic Issue 3? Generic 3.0, as Pirzada refers to it [0]? "UNIX PG-1C300 Issue 3”, as it identifies itself in /usr/sys/lib1? PG3, as chosen for our recent release of the tapes? Why was UNIX Program Generic called something so, well, generic? Is it part of a larger naming scheme? Thalia [0]: https://www.tuhs.org/Archive/Documentation/Theses/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf From tuhs at tuhs.org Fri May 8 10:11:38 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Thu, 7 May 2026 17:11:38 -0700 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> Message-ID: <20260508001138.GE25310@mcvoy.com> I've never heard of PG3. Is this something like the SVID or something else? On Thu, May 07, 2026 at 11:55:33PM +0000, segaloco via TUHS wrote: > Received a question from Thalia Archibald concerning my use of the > nomenclature "PG3" vs Pirzada's "Gen3.0". I pulled together the info > below, seems like it might be interesting to the broader audience: > > So it's a bit fuzzy when you get into the weeds. This document[1] > defines the acronym "PG" as such: > > > At the highest level in the document hierarchy is the > > Program Document (PG) Index that lists all of the documents > > associated with a program generic. A single PG-level directory > > occupies the corresponding position in the file system hierarchy. > > So within their source control structure you would have directories: > > pg-1c300-01 (issue 1) > pg-1c300-02 (issue 2) > > And then under those the "PR" directories containing the individual > groupings of source files, other documents, etc. > > This isn't what I originally based my use of this acronym on though, > rather just Program Generic (PG). > Typically if I do see a shorter name, > the system is just referred to as a "Generic", proper noun. This was > common practice within AT&T and did not just apply to UNIX[2][3]. > In fact, this first round of USG UNIX (before UNIX/TS and later) was > very "Bell-ish" compared to later efforts. The manuals were the only > ones rendered to Bell System standards in that they had the OSD headers > with document ID, issue, date, etc. rather than just the standard > manpage masthead. Several of the USG documents of the time look like > the same typesetting package used for 3ESS generic pidents for instance. > > As I was gathering some of this info, I keep seeing PG-1C300 used where > the system is referred to in short. This actually makes sense given > AT&T's use of the "PG" prefix for a number of different projects. > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built > on UNIX by WECo for a frame system in telco offices[5], has > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix > for the underlying generic. Outside of UNIX, PG-3H903 is one of the > 3ESS generics[6]. > > After compiling all of that info, I'm inclined to say that the > "canonical" names in increasing length are "PG-1C300", then "Generic", > then "Program Generic". I would think given Pirzada's being at AT&T > at the time though the "Gen3.0" etc. nomenclature would also be > acceptable, just maybe not "period". > > - Matt G. > > P.S. As always this is just my own research, I wasn't there so I'd > certainly get some second opinions if available. > > [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf > [2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf > [3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf > [4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf > [5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf > [6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri May 8 10:12:54 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Fri, 08 May 2026 00:12:54 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> Message-ID: <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> Interestingly, Pirzada calls it “issue 1 of UNIX Operating System Generic PG-1C300”, never “Program Generic”. These are the Generic releases mentioned by Pirzada: - USG release 1.0 (15 December 1973) - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974) - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) - PG-1C300 issue 3 (spring 1977) Additionally with the same number scheme: - PG-1C600: MERT Release 0 (November 1977) Thalia > On May 7, 2026, at 16:55, segaloco via TUHS wrote: > > Received a question from Thalia Archibald concerning my use of the > nomenclature "PG3" vs Pirzada's "Gen3.0". I pulled together the info > below, seems like it might be interesting to the broader audience: > > So it's a bit fuzzy when you get into the weeds. This document[1] > defines the acronym "PG" as such: > >> At the highest level in the document hierarchy is the >> Program Document (PG) Index that lists all of the documents >> associated with a program generic. A single PG-level directory >> occupies the corresponding position in the file system hierarchy. > > So within their source control structure you would have directories: > > pg-1c300-01 (issue 1) > pg-1c300-02 (issue 2) > > And then under those the "PR" directories containing the individual > groupings of source files, other documents, etc. > > This isn't what I originally based my use of this acronym on though, > rather just Program Generic (PG). > Typically if I do see a shorter name, > the system is just referred to as a "Generic", proper noun. This was > common practice within AT&T and did not just apply to UNIX[2][3]. > In fact, this first round of USG UNIX (before UNIX/TS and later) was > very "Bell-ish" compared to later efforts. The manuals were the only > ones rendered to Bell System standards in that they had the OSD headers > with document ID, issue, date, etc. rather than just the standard > manpage masthead. Several of the USG documents of the time look like > the same typesetting package used for 3ESS generic pidents for instance. > > As I was gathering some of this info, I keep seeing PG-1C300 used where > the system is referred to in short. This actually makes sense given > AT&T's use of the "PG" prefix for a number of different projects. > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built > on UNIX by WECo for a frame system in telco offices[5], has > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix > for the underlying generic. Outside of UNIX, PG-3H903 is one of the > 3ESS generics[6]. > > After compiling all of that info, I'm inclined to say that the > "canonical" names in increasing length are "PG-1C300", then "Generic", > then "Program Generic". I would think given Pirzada's being at AT&T > at the time though the "Gen3.0" etc. nomenclature would also be > acceptable, just maybe not "period". > > - Matt G. > > P.S. As always this is just my own research, I wasn't there so I'd > certainly get some second opinions if available. > > [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf > [2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf > [3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf > [4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf > [5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf > [6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf From tuhs at tuhs.org Fri May 8 11:19:38 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Thu, 7 May 2026 19:19:38 -0600 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> Message-ID: "USG mod level 3.33" might be the best moniker. Unix Operating System Generic makes the most sense to me, since Bell entities would take that and turn it into the specific OS for their switch, billing system, etc. USG curated the research products into something that people could use. Warner On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS wrote: > Interestingly, Pirzada calls it “issue 1 of UNIX Operating System Generic > PG-1C300”, never “Program Generic”. > > These are the Generic releases mentioned by Pirzada: > - USG release 1.0 (15 December 1973) > - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974) > - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) > - PG-1C300 issue 3 (spring 1977) > > Additionally with the same number scheme: > - PG-1C600: MERT Release 0 (November 1977) > > Thalia > > > On May 7, 2026, at 16:55, segaloco via TUHS wrote: > > > > Received a question from Thalia Archibald concerning my use of the > > nomenclature "PG3" vs Pirzada's "Gen3.0". I pulled together the info > > below, seems like it might be interesting to the broader audience: > > > > So it's a bit fuzzy when you get into the weeds. This document[1] > > defines the acronym "PG" as such: > > > >> At the highest level in the document hierarchy is the > >> Program Document (PG) Index that lists all of the documents > >> associated with a program generic. A single PG-level directory > >> occupies the corresponding position in the file system hierarchy. > > > > So within their source control structure you would have directories: > > > > pg-1c300-01 (issue 1) > > pg-1c300-02 (issue 2) > > > > And then under those the "PR" directories containing the individual > > groupings of source files, other documents, etc. > > > > This isn't what I originally based my use of this acronym on though, > > rather just Program Generic (PG). > > Typically if I do see a shorter name, > > the system is just referred to as a "Generic", proper noun. This was > > common practice within AT&T and did not just apply to UNIX[2][3]. > > In fact, this first round of USG UNIX (before UNIX/TS and later) was > > very "Bell-ish" compared to later efforts. The manuals were the only > > ones rendered to Bell System standards in that they had the OSD headers > > with document ID, issue, date, etc. rather than just the standard > > manpage masthead. Several of the USG documents of the time look like > > the same typesetting package used for 3ESS generic pidents for instance. > > > > As I was gathering some of this info, I keep seeing PG-1C300 used where > > the system is referred to in short. This actually makes sense given > > AT&T's use of the "PG" prefix for a number of different projects. > > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built > > on UNIX by WECo for a frame system in telco offices[5], has > > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix > > for the underlying generic. Outside of UNIX, PG-3H903 is one of the > > 3ESS generics[6]. > > > > After compiling all of that info, I'm inclined to say that the > > "canonical" names in increasing length are "PG-1C300", then "Generic", > > then "Program Generic". I would think given Pirzada's being at AT&T > > at the time though the "Gen3.0" etc. nomenclature would also be > > acceptable, just maybe not "period". > > > > - Matt G. > > > > P.S. As always this is just my own research, I wasn't there so I'd > > certainly get some second opinions if available. > > > > [1] - > https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf > > [2] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf > > [3] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf > > [4] - > https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs > 01-02 Title Page.pdf > > [5] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf > > [6] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf > > > From tuhs at tuhs.org Fri May 8 11:24:46 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 8 May 2026 11:24:46 +1000 Subject: [TUHS] Name of UNIX Program Generic In-Reply-To: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev> References: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev> Message-ID: On Thu, May 07, 2026 at 11:59:05PM +0000, Thalia Archibald via TUHS wrote: > What was the common shorthand for UNIX Program Generic Issue 3? > Generic 3.0, as Pirzada refers to it [0]? "Generic 3" has some usage as well: "This version of the Unix Programmer's Manual is essentially the Program Generic 3 Edition (March 1977) with update pages" G.W.R.L. - preface to MERT Release 0, Unix Programmer's Manual October 1977 ... "List of Update Pages for Unix Generic 3" "This document describes differences users may encounter when changing to UNIX/TS Edition 1.0 from the last release of the C compiler shipped for Generic 3." Andrew Koenig - Changes in the C Environment for UNIX/TS Edition 1.0 September 27, 1978 https://archive.org/details/AUUGN_V01_3/page/n18/mode/1up AUUGN Vol 1, No 3, Feb-Mar 1979, pp 19-24 "PDP-11/70 computer results prior to 1980 are for the Generic 3 (PG 1C-300) UNIX system version" J. Feder - The Evolution of UNIX System Performance BSTJ Vol 63, No 8, October 1984, pp 1791-1814 "USG Generic 3" John Mashey net.unix-wizards, Xenix286 Wonders, Bugs, and Patches..., May 9, 1985 https://www.tuhs.org/Usenet/comp.unix.wizards/1985-May/008079.html "We put together the UNIX Support Group [USG] in September of 1973 and released the first C version of UNIX internally. [Generic I, II, and III were produced by these initial efforts.]" Berkley Tague interviewed by Ned Peirce Unix Review, Vol 3, No 6, June 1985, p 61 https://archive.org/details/Unix_Review_1985_Jun.pdf/page/n61/mode/2up From tuhs at tuhs.org Fri May 8 11:25:07 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Fri, 08 May 2026 01:25:07 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> Message-ID: <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev> On May 7, 2026, at 18:19, Warner Losh wrote: > On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS wrote: >> These are the Generic releases mentioned by Pirzada: >> - USG release 1.0 (15 December 1973) >> - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974) >> - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) >> - PG-1C300 issue 3 (spring 1977) > > "USG mod level 3.33" might be the best moniker. Note that the USG release number is one off from the Generic issue number, so mod level 3.33 corresponds to issue 2, not issue 3. Pirzada does not list the mod level for issue 3. Thalia From tuhs at tuhs.org Fri May 8 11:30:39 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Thu, 7 May 2026 19:30:39 -0600 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev> Message-ID: On Thu, May 7, 2026, 7:25 PM Thalia Archibald wrote: > On May 7, 2026, at 18:19, Warner Losh wrote: > > On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS > wrote: > >> These are the Generic releases mentioned by Pirzada: > >> - USG release 1.0 (15 December 1973) > >> - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974) > >> - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) > >> - PG-1C300 issue 3 (spring 1977) > > > > "USG mod level 3.33" might be the best moniker. > > Note that the USG release number is one off from the Generic issue number, > so mod level 3.33 corresponds to issue 2, not issue 3. > Pirzada does not list the mod level for issue 3. > Fair point. I see other emal call it Generic 3... and a few other names... I thought it was easy until I saw them. Warner > From tuhs at tuhs.org Fri May 8 11:48:38 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 08 May 2026 01:48:38 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <76759356-BBDB-4234-A341-4850CC135029@archibald.dev> Message-ID: On Thursday, May 7th, 2026 at 18:19, Warner Losh via TUHS wrote: > "USG mod level 3.33" might be the best moniker. > > Unix Operating System Generic makes the most sense to me, since Bell > entities would take that and turn it into the specific OS for their switch, > billing system, etc. USG curated the research products into something that > people could use. > > Warner > Pirzada's thesis gives these timeframes for USG's initial version: 73-12-15 - USG Release 1.0 74-04-?? - USG Release 2.0 74-11-?? - USG Release 2 mod 2.24 (PG Issue 1) 76-01-?? - USG Release 3.0 mod 3.33 (PG Issue 2) 77-03-?? - USG PG Issue 3 (No Release or mod number given). So there was the release mod level and the issue of the generic. This dual versioning scheme also appears in CB-UNIX, which has manuals featuring "Editions" like 2.1, 2.3, but then a kernel featuring "releases" like 2 and 3. I've documented this situation a bit in the wiki here: https://wiki.tuhs.org/doku.php?id=systems:cb1 By the way just to summarize since I've made a lot of noise about it but maybe haven't explained the basics: Program Generic Issue 3, or PG3 as I've been calling it, is the last "supported" USG release inside AT&T prior to reorganization of USG's efforts behind the UNIX/TS and ongoing PWB projects. In particular, UNIX Program Generic was intended as a UNIX packaging that met BTL standards. This made for several pecularities: - Printed manuals (of which Issue 2 and Issue 3 are the only confirmed widely-printed releases) contained OSDD (Operations Systems Deliverable Documentation) headers, common to other BTL systems documentation in requiring the document code, date, issue number, etc. printed in the outer corner of the page, much like Bell System Practices (BSP) documents. - The literature and sources themselves were arranged in this PG-, PA-, PD-, etc. nomenclature found in other AT&T projects like switching stuff in Columbus. - Other AT&T projects built on top of Program Generic then cite it or at least adhere to similar documentation requirements such as COSMOS and MERT Release 0. So yeah the "USG supported UNIX for the BTL user community" was one part of their responsibilities, but with Program Generic that also expanded to supporting UNIX as a standard AT&T OS for building telco and related systems on top of. While UNIX was the in-house solution, AT&T also maintained standards for systems development on top of other operating systems such as OS 1100 and VMS. Some documentation can be found here in BSP section 007 on Information Systems: https://www.telecomarchive.com/007.html Anywho, probably enough from the firehose on mid 70s USG activities for now. I'm just so glad some of this stuff is finally preserved properly and folks are talking about it. Program Generic in particular is very "Bell-ish" so tickles the overlap between my UNIX and telecom interests well. - Matt G. From tuhs at tuhs.org Fri May 8 12:28:49 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 7 May 2026 22:28:49 -0400 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <20260508001138.GE25310@mcvoy.com> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> Message-ID: Different audiences/different objectives. PG was a term and efforts directed >>inside<< the Bell System to try to get their own different and divergent UNIX implementations together in a more uniform manner. SVID was much later and directed >>externally<< to folks like you and me. It was a reaction by USG to /usr/group’s 1985 document, which was rebirthed/rewritten in IEEE/ANSI style to become P1003. AT&T has started their ‘consider it standard’ campaign and was very much miffed that the ‘definition’ of there ‘thing’ was being defined outside of AT&T and they did not control it. In fact, there was a big effort to try to get P1003 to take SVID directly (we pushed back, not nearly hard enough in my eyes, but that’s a different story). In fact, ATT never stopped, so if you look at later editions of you can see more and more influence it had on later documents. To complete the thought, SPEC1170 was created when it was realized by the members of UI (particularly the ISVs), that even with SVID and POSIX it was still really hard to actually develop large systems oriented SW products because while system call interface was now fairly well defined, there were so many other ‘upper level’ interfaces [1170 of them in fact - how it got its name] within the different UNIX implementations that described how a system was managed and user encountered a Unix-based system, it was extremely difficult to create just one version of your product- the test matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64, SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX … you get the idea. Sent from a handheld expect more typos than usual On Thu, May 7, 2026 at 8:11 PM Larry McVoy via TUHS wrote: > I've never heard of PG3. Is this something like the SVID or something > else? > > On Thu, May 07, 2026 at 11:55:33PM +0000, segaloco via TUHS wrote: > > Received a question from Thalia Archibald concerning my use of the > > nomenclature "PG3" vs Pirzada's "Gen3.0". I pulled together the info > > below, seems like it might be interesting to the broader audience: > > > > So it's a bit fuzzy when you get into the weeds. This document[1] > > defines the acronym "PG" as such: > > > > > At the highest level in the document hierarchy is the > > > Program Document (PG) Index that lists all of the documents > > > associated with a program generic. A single PG-level directory > > > occupies the corresponding position in the file system hierarchy. > > > > So within their source control structure you would have directories: > > > > pg-1c300-01 (issue 1) > > pg-1c300-02 (issue 2) > > > > And then under those the "PR" directories containing the individual > > groupings of source files, other documents, etc. > > > > This isn't what I originally based my use of this acronym on though, > > rather just Program Generic (PG). > > Typically if I do see a shorter name, > > the system is just referred to as a "Generic", proper noun. This was > > common practice within AT&T and did not just apply to UNIX[2][3]. > > In fact, this first round of USG UNIX (before UNIX/TS and later) was > > very "Bell-ish" compared to later efforts. The manuals were the only > > ones rendered to Bell System standards in that they had the OSD headers > > with document ID, issue, date, etc. rather than just the standard > > manpage masthead. Several of the USG documents of the time look like > > the same typesetting package used for 3ESS generic pidents for instance. > > > > As I was gathering some of this info, I keep seeing PG-1C300 used where > > the system is referred to in short. This actually makes sense given > > AT&T's use of the "PG" prefix for a number of different projects. > > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built > > on UNIX by WECo for a frame system in telco offices[5], has > > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix > > for the underlying generic. Outside of UNIX, PG-3H903 is one of the > > 3ESS generics[6]. > > > > After compiling all of that info, I'm inclined to say that the > > "canonical" names in increasing length are "PG-1C300", then "Generic", > > then "Program Generic". I would think given Pirzada's being at AT&T > > at the time though the "Gen3.0" etc. nomenclature would also be > > acceptable, just maybe not "period". > > > > - Matt G. > > > > P.S. As always this is just my own research, I wasn't there so I'd > > certainly get some second opinions if available. > > > > [1] - > https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf > > [2] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf > > [3] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf > > [4] - > https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs > 01-02 Title Page.pdf > > [5] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf > > [6] - > https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Sat May 9 00:25:13 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 8 May 2026 07:25:13 -0700 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> Message-ID: <20260508142513.GI25310@mcvoy.com> On Thu, May 07, 2026 at 10:28:49PM -0400, Clem Cole wrote: > matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64, > SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX ??? you get the idea. With the exception of AIX370/RS/PS2 and DGUX, BitKeeper ran on all of those and added Linux/370, SGI, MacOS, and all variants of Windows. It sort of doesn't matter these days but the portability stuff in that source base is worth a look. From tuhs at tuhs.org Sat May 9 01:31:09 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 11:31:09 -0400 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: <20260508142513.GI25310@mcvoy.com> References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: below On Fri, May 8, 2026 at 10:25 AM Larry McVoy wrote: > On Thu, May 07, 2026 at 10:28:49PM -0400, Clem Cole wrote: > > matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64, > > SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX ??? you get the idea. > > With the exception of AIX370/RS/PS2 and DGUX, BitKeeper ran on all of > those and added Linux/370, SGI, MacOS, and all variants of Windows. > I know it did. For many (most) programs and tool suites, frankly, POSIX conformance was all that was needed. But much larger programs, and often had tentacles into OS things, such as Oracle, SAP, BAAN, and a slew of CAD vendors, could not. BTW: this only got worse with Linux clusters. For instance, Fluent (later purchased by ANSYS) had a test matrix of over 144 combinations to get a release out the door at one point. > > It sort of doesn't matter these days but the portability stuff in that > source base is worth a look. > Actually, I've found it is now worse than it was during the proprietary UNIX days, as you know, we have many of the "end-arounds" that traditional UNIX had. Since the hardware is no longer "single sourced" from Sun, DEC, HP, or whoever (in the old days, users really wouldn't mix the "supported" hardware on production systems. The largest end users are stuck with what the ISV approved. Then add things like security planes, and modern *IX systems just have to deal with more issues. Users are in trouble even if their application programs run on an Intel*64 or compatible processor board, when the user adds hardware subsystems such as different kinds of interconnects, or when they add other tools that step on each other (for instance, different tool vendors bring their own MPI) or shared libraries. FWIW: I just ran into the shared library issue this week with macOS Tahoe — some of Apple's binaries and dynamic libraries are compiled as arm64e [which only Apple can certify — it part of the SIP system], so package managers must use the traditional arm64; but try to mix certain programs using exec that have shared libraries and SIP will fail. From tuhs at tuhs.org Sat May 9 01:51:00 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Fri, 08 May 2026 15:51:00 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: I've come to realize, only recently, that Apple moving from Intel's x86-64 architecture to their own take on AArch64/ARM64 might help them streamline design, development and production but it's a royal pain in the derriere for many other reasons. Quite a few packages I've tried to install over the last year have turned out to be for Intel x86-64 Macs and nothing later. Regarding your issue, below, you can disable SIP, or at least, you used to be able to do so. Have a great rest of your day, everyone. The weekend starts at 5 pm... On Friday, May 8th, 2026 at 4:32 PM, Clem Cole via TUHS wrote, in part: > FWIW: I just ran into the shared library issue this week with macOS Tahoe > — some of Apple's binaries and dynamic libraries are compiled as arm64e > [which only Apple can certify — it part of the SIP system], so package > managers must use the traditional arm64; but try to mix certain programs > using exec that have shared libraries and SIP will fail. > From tuhs at tuhs.org Sat May 9 03:37:49 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 08 May 2026 17:37:49 +0000 Subject: [TUHS] Some UNIX/TS Info From John Mashey Message-ID: Hi folks, I recently contacted John Mashey with some questions about UNIX/TS, he sent along the following information: > Sure, real quick. > > I assume you’ve seen Andrew Tannenbaum’s history, which is pretty good: > > https://www.rro.rs/unixarchive-usenet/comp.unix.questions/1988-July/005999.html > > although it is ambguous on some dates. My UNIX/TS manual is dated November 1978. > > By late 1976, Bell labs management had realized: > > a) Almost every project in Bell Labs wsa either using UNIX for development, text-processing or other support activies, OR delivering/planning operations support systems running UNIX. > > b) But there was a multiplicity of versions. > > So, to start consolidatation, > > 3 of us moved from PWB dept to Berk Tague’s UNIX Support Group in early 1977. > > Dick Haight Supervisor > > Larry Wehr & I, MTS. > > Goal was take the not-yet-released but well-along V7, make changes as needed (especially from PWB ruggedizing, accounting, performance, etc), > > and get a version suitable for time-sharing, BUT NOT with the CB-UNIX=> USG PG 3 IPC, semaphores, messaging, etc operations support systems stuff. > > I.e., we wanted a kernel that PWB dept didn’t have to change to make suitable for the large-user-community, computer-center environments that now existed. > > Mid-1979 was PWB/UNIX 2.0, i.e., UNIX/TS kernel+commands, with PWB tools, subsystems like RJE, LEAP, MRCS, etc. > > Mid-1980 was System III released outside. > > There was no outside System IV, internally, that was when the CB-UNIX features got folded into the mainline, released outside as System V. > > https://en.wikipedia.org/wiki/CB_UNIX > > Thus: > > V7 > > 1 UNIX/TS > > 2 PWB/UNIX 2 > > 3 System III > > 4 System IV (internal only) = > 5 System V > > I may some day take you up on that offer. I’m slowly going through old documents, trying to clean out house, may find things of interest. > > Thanks for kind words. Those were interesting times, and for some more related history, you might have fun with: > > The Long Road to 64-bits – double, double, toil & trouble > > https://spawn-queue.acm.org/doi/pdf/10.1145/1165754.1165766original in Qqueue, 2006 > > https://dl.acm.org/doi/10.1145/1435417.1435431then CACM wanted it, 2009 > > Weirdly, the 2 versions of the above rarely get cited in literature, but together have been downloaded >100K times: > > https://dl.acm.org/action/doSearch?AllField=long+road+to+64-bits > > One conclusion: ~1975 UNIX was on 16-bit PDP-11s, butC was getting ported to 32-bitters like IBM S?360, XDS Sigma5, etc. > > Had we been thinking 15-years ahead, we could have done better with typedefs & programming styles that would have saved much pain later. > > More recently: > > Interactions, Impacts and Coincidences of the First Golden Age of Computer Architecture > > https://techviser.com/wp-content/uploads/2022/06/Mashey.IEEE_.Micro_.2022.pdf > >> From:segaloco >> >> Sent:Thursday, May 7, 2026 9:42 PM >> >> To: John Mashey >> >> Subject:RE: UNIX/TS ? >> >> Thanks for the reply John! Frankly the thing that interests me the most is what relationship that system had with the Program Generic efforts USG was engaged in before, if the prior system was transformed into TS, if research was resampled, and/or if the earlier work in PWB was incorporated in any of what that system looked like. >> >> For some background, I recently helped archive and resurrect a copy of Program Generic Issue 3 from 1977 along with the documentation: >> >> https://www.tuhs.org/pipermail/tuhs/2026-April/033604.html >> >> This successful effort as well as preserving several UNIX 4.x documents from 1981 has renewed my interest in precisely what sort of rebundling UNIX/TS involved and how it differs from what was around it. It represents a bit of a historical hole which I've been able to flush out a fair deal of documentation surrounding. >> >> I'd also like to extend the offer that I am pretty constantly engaged with scanning and archiving lost and obscure UNIX literature, especially BTL/WECo materials. I'd gladly extend my services (and shipping) gratis if you have any notable materials you feel should be preserved. >> >> Finally a thank you John for the work you contributed. You and so many others delivered a system that shapes computing to this day and that countless lessons still emerge from. >> >> - Matt G. >> >> On Thursday, May 7th, 2026 at 21:30, John Mashey wrote: >> >>> Sure, that’s me. & I might be able to answer a few questions on UNIX/TS ,although I’d departed the UNIX Support Group in mid-1978 for Whippany, shortly before UNIX/TS released. >>> >>>> From:segaloco >>>> >>>> Sent:Thursday, May 7, 2026 7:17 PM >>>> >>>> To: John Mashey >>>> >>>> Subject:UNIX/TS ? >>>> >>>> Hello, my name is Matt Gilmore and I hope I am reaching the inbox of John Mashey! >>>> >>>> I was wondering if you might be the very same John Mashey of UNIX fame who played a key role in the Programmer's Workbench branch of the software. I'm hoping to get in touch regarding some study I am engaged in documenting USG UNIX developments from the mid 70s. Among other things I've been working to document details concerning the UNIX/TS effort. >>>> >>>> - Matt G. From tuhs at tuhs.org Sat May 9 03:46:30 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 8 May 2026 10:46:30 -0700 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: References: Message-ID: <20260508174630.GL25310@mcvoy.com> Huh, I just learned that Andrew was part of Masscomp. Clem, how did that come about? On Fri, May 08, 2026 at 05:37:49PM +0000, segaloco via TUHS wrote: > Hi folks, I recently contacted John Mashey with some questions about UNIX/TS, he sent along the following information: > > > Sure, real quick. > > > > I assume you???ve seen Andrew Tannenbaum???s history, which is pretty good: > > > > https://www.rro.rs/unixarchive-usenet/comp.unix.questions/1988-July/005999.html > > > > although it is ambguous on some dates. My UNIX/TS manual is dated November 1978. > > > > By late 1976, Bell labs management had realized: > > > > a) Almost every project in Bell Labs wsa either using UNIX for development, text-processing or other support activies, OR delivering/planning operations support systems running UNIX. > > > > b) But there was a multiplicity of versions. > > > > So, to start consolidatation, > > > > 3 of us moved from PWB dept to Berk Tague???s UNIX Support Group in early 1977. > > > > Dick Haight Supervisor > > > > Larry Wehr & I, MTS. > > > > Goal was take the not-yet-released but well-along V7, make changes as needed (especially from PWB ruggedizing, accounting, performance, etc), > > > > and get a version suitable for time-sharing, BUT NOT with the CB-UNIX=> USG PG 3 IPC, semaphores, messaging, etc operations support systems stuff. > > > > I.e., we wanted a kernel that PWB dept didn???t have to change to make suitable for the large-user-community, computer-center environments that now existed. > > > > Mid-1979 was PWB/UNIX 2.0, i.e., UNIX/TS kernel+commands, with PWB tools, subsystems like RJE, LEAP, MRCS, etc. > > > > Mid-1980 was System III released outside. > > > > There was no outside System IV, internally, that was when the CB-UNIX features got folded into the mainline, released outside as System V. > > > > https://en.wikipedia.org/wiki/CB_UNIX > > > > Thus: > > > > V7 > > > > 1 UNIX/TS > > > > 2 PWB/UNIX 2 > > > > 3 System III > > > > 4 System IV (internal only) = > > > 5 System V > > > > I may some day take you up on that offer. I???m slowly going through old documents, trying to clean out house, may find things of interest. > > > > Thanks for kind words. Those were interesting times, and for some more related history, you might have fun with: > > > > The Long Road to 64-bits ??? double, double, toil & trouble > > > > https://spawn-queue.acm.org/doi/pdf/10.1145/1165754.1165766original in Qqueue, 2006 > > > > https://dl.acm.org/doi/10.1145/1435417.1435431then CACM wanted it, 2009 > > > > Weirdly, the 2 versions of the above rarely get cited in literature, but together have been downloaded >100K times: > > > > https://dl.acm.org/action/doSearch?AllField=long+road+to+64-bits > > > > One conclusion: ~1975 UNIX was on 16-bit PDP-11s, butC was getting ported to 32-bitters like IBM S?360, XDS Sigma5, etc. > > > > Had we been thinking 15-years ahead, we could have done better with typedefs & programming styles that would have saved much pain later. > > > > More recently: > > > > Interactions, Impacts and Coincidences of the First Golden Age of Computer Architecture > > > > https://techviser.com/wp-content/uploads/2022/06/Mashey.IEEE_.Micro_.2022.pdf > > > >> From:segaloco > >> > >> Sent:Thursday, May 7, 2026 9:42 PM > >> > >> To: John Mashey > >> > >> Subject:RE: UNIX/TS ? > >> > >> Thanks for the reply John! Frankly the thing that interests me the most is what relationship that system had with the Program Generic efforts USG was engaged in before, if the prior system was transformed into TS, if research was resampled, and/or if the earlier work in PWB was incorporated in any of what that system looked like. > >> > >> For some background, I recently helped archive and resurrect a copy of Program Generic Issue 3 from 1977 along with the documentation: > >> > >> https://www.tuhs.org/pipermail/tuhs/2026-April/033604.html > >> > >> This successful effort as well as preserving several UNIX 4.x documents from 1981 has renewed my interest in precisely what sort of rebundling UNIX/TS involved and how it differs from what was around it. It represents a bit of a historical hole which I've been able to flush out a fair deal of documentation surrounding. > >> > >> I'd also like to extend the offer that I am pretty constantly engaged with scanning and archiving lost and obscure UNIX literature, especially BTL/WECo materials. I'd gladly extend my services (and shipping) gratis if you have any notable materials you feel should be preserved. > >> > >> Finally a thank you John for the work you contributed. You and so many others delivered a system that shapes computing to this day and that countless lessons still emerge from. > >> > >> - Matt G. > >> > >> On Thursday, May 7th, 2026 at 21:30, John Mashey wrote: > >> > >>> Sure, that???s me. & I might be able to answer a few questions on UNIX/TS ,although I???d departed the UNIX Support Group in mid-1978 for Whippany, shortly before UNIX/TS released. > >>> > >>>> From:segaloco > >>>> > >>>> Sent:Thursday, May 7, 2026 7:17 PM > >>>> > >>>> To: John Mashey > >>>> > >>>> Subject:UNIX/TS ? > >>>> > >>>> Hello, my name is Matt Gilmore and I hope I am reaching the inbox of John Mashey! > >>>> > >>>> I was wondering if you might be the very same John Mashey of UNIX fame who played a key role in the Programmer's Workbench branch of the software. I'm hoping to get in touch regarding some study I am engaged in documenting USG UNIX developments from the mid 70s. Among other things I've been working to document details concerning the UNIX/TS effort. > >>>> > >>>> - Matt G. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat May 9 03:48:13 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Fri, 8 May 2026 10:48:13 -0700 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: The x86_64 emulation in Rosetta 2 is pretty good, although macOS 27 is going to be the last one that includes it. However...in general I'd say be wary of x86_64-only applications. At least at GCP (I don't know about AWS) you get slightly more performance per dollar (well...better for integer, worse for floating point, so it depends on your workload, but mine's mostly integer) if you go with aarch64 even for Linux. This isn't the first time an almost-hegemony got dethroned, of course. We had, at the beginning of my career (I'm kinda young for this crowd) "all the world's a VAX". After that, for a long time, x86 and amd64 came very close to being the only architecture out there, but then Intel/AMD couldn't keep up with the need for low-power devices (perhaps because their instruction set had evolved so incrementally and with so much emphasis on backwards-compatibility), and ARM basically entirely devoured the mobile market, and seems to be coming for the server market as energy prices go up. Unix has been multiplatform since v6, and both GCC and LLVM support many,many targets, so there's little excuse for single-architecture applications. If whatever you're running is x86-only and it's a Mac app, then it's probably abandonware. Which, I mean, fair enough for this crowd, but also if it was written assuming 2015 hardware specs, it probably runs just fine under emulation on a modern ARM system. Generally, it's not that ARM is any faster than x86_64--but it can take much less energy to give you the same amount of computation. If you only have a couple hundred watts of compute at home on things that are mostly plugged in, you probably don't care, but if you're renting your capacity from someone else, or trying to run on battery much, it starts to matter a lot. Apple has made an interesting choice in this space. My M1 Macbook Air was *astonishingly* better than any laptop I'd ever previously owned. It wasn't really any faster than what it replaced (an Intel Macbook Pro), but it had a sixteen-hour battery life while still weighing less (the battery is of course the majority of the weight of the machine). The M3 I now have, on the other hand, is just the boring standard incremental upgrade over its predecessor. A little faster, the screen's a slightly better resolution, but it's not the "I can run for *how* long before I need to plug into a socket?!?" that the M1 was. Adam On Fri, May 8, 2026 at 8:57 AM Cameron Míċeál Tyre via TUHS wrote: > I've come to realize, only recently, that Apple moving from Intel's x86-64 > architecture to their own take on AArch64/ARM64 might help them streamline > design, development and production but it's a royal pain in the derriere > for many other reasons. Quite a few packages I've tried to install over the > last year have turned out to be for Intel x86-64 Macs and nothing later. > > Regarding your issue, below, you can disable SIP, or at least, you used to > be able to do so. > > Have a great rest of your day, everyone. The weekend starts at 5 pm... > > > > On Friday, May 8th, 2026 at 4:32 PM, Clem Cole via TUHS > wrote, in part: > > > FWIW: I just ran into the shared library issue this week with macOS > Tahoe > > — some of Apple's binaries and dynamic libraries are compiled as arm64e > > [which only Apple can certify — it part of the SIP system], so package > > managers must use the traditional arm64; but try to mix certain programs > > using exec that have shared libraries and SIP will fail. > > > From tuhs at tuhs.org Sat May 9 04:06:45 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 08 May 2026 18:06:45 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: On Friday, May 8th, 2026 at 10:48, Adam Thornton via TUHS wrote: > Generally, it's not that ARM is any faster than x86_64--but it can take > much less energy to give you the same amount of computation. With the advent of widespread mobile devices, this was crucial. Necessity drove ARMs meteoric rise, and now priorities seem to be shifting once again, this time surrounding supply chains and fab redundancy, stuff like that. My hunch is we're going to start seeing more interest in royalty-free designs like RISC-V and even moreso if there are such designs over in the realm of solid state memory. No sociopolitical commentary but the TSMC situation is certainly on the mind. Couple this with the hiring spree companies like Apple and nVidia had in the RISC-V realm several years ago and I suspect we'll start seeing the baby steps towards another tectonic shift possibly in the next decade. Granted this is now getting quite far afield from the original subject. To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V now, so that means there is also hope for bootstrapping other historic UNIX systems (like PG3) on RISC-V. Given the nature of RISC-V as purely an ISA standard, not an implementation, this implies that UNIX's life has now been extended theoretically indefinitely, RISC-V is supposed to have future proofing baked-into the ISA design, offering an appealing interface to compute that isn't as likely to evaporate in a decade or two. But that's basicslly what they said about System/360 and VAX was it not? I guess time will tell if RISC-V really significantly moves the needle in the modern UNIX-like playfield. - Matt G. From tuhs at tuhs.org Sat May 9 04:20:57 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 8 May 2026 12:20:57 -0600 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: On Fri, May 8, 2026 at 12:06 PM segaloco via TUHS wrote: > On Friday, May 8th, 2026 at 10:48, Adam Thornton via TUHS > wrote: > > > Generally, it's not that ARM is any faster than x86_64--but it can take > > much less energy to give you the same amount of computation. > > With the advent of widespread mobile devices, this was crucial. Necessity > drove ARMs meteoric rise, and now priorities seem to be shifting once > again, this time surrounding supply chains and fab redundancy, stuff like > that. My hunch is we're going to start seeing more interest in > royalty-free designs like RISC-V and even moreso if there are such designs > over in the realm of solid state memory. No sociopolitical commentary but > the TSMC situation is certainly on the mind. Couple this with the hiring > spree companies like Apple and nVidia had in the RISC-V realm several years > ago and I suspect we'll start seeing the baby steps towards another > tectonic shift possibly in the next decade. > > Granted this is now getting quite far afield from the original subject. > To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V > now, so that means there is also hope for bootstrapping other historic UNIX > systems (like PG3) on RISC-V. xv6 was written for 32-bit i386, so porting wasn't so bad. The Unixes of this era (PG3 roughly V6) don't yet have the portability fixes that even the 7th Edition has, so there's a lot of porting to be done. None of the sizes of things are abstracted, so there's a lot of +2 baked into the code since it knows that's how big a pointer is.. Sure would be a cool project, though. The Miller papers on the Wollongong Interdata port have many of the details... Warner > Given the nature of RISC-V as purely an ISA standard, not an > implementation, this implies that UNIX's life has now been extended > theoretically indefinitely, RISC-V is supposed to have future proofing > baked-into the ISA design, offering an appealing interface to compute that > isn't as likely to evaporate in a decade or two. > > But that's basicslly what they said about System/360 and VAX was it not? > I guess time will tell if RISC-V really significantly moves the needle in > the modern UNIX-like playfield. > > - Matt G. > From tuhs at tuhs.org Sat May 9 04:28:01 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 14:28:01 -0400 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: On Fri, May 8, 2026 at 11:51 AM Cameron Míċeál Tyre via TUHS wrote: > I've come to realize, only recently, that Apple moving from Intel's x86-64 > architecture to their own take on AArch64/ARM64 might help them streamline > design, development and production but it's a royal pain in the derriere > for many other reasons. Quite a few packages I've tried to install over the > last year have turned out to be for Intel x86-64 Macs and nothing later. > > Regarding your issue, below, you can disable SIP, or at least, you used to > be able to do so. > Yes, but it does not change the arm64e / arm64 binary issue on macOS; a binary stored in a macho file marked as arm64e includes Pointer Authentication Codes (PAC). PAC is an Apple security feature designed to prevent memory corruption and code-injection attacks. The two binary formats differ in instruction set features and how the OS handles them: - Security (PAC): arm64e utilizes ARMv8.3-A instructions to cryptographically sign and verify pointers (like return addresses and function pointers) before use. If a pointer is tampered with by malware, the authentication fails, and the program crashes safely instead of executing malicious code. Standard arm64 binaries do not use these instructions. - ABI Stability: The arm64e Application Binary Interface (ABI) is considered unstable and "private" by Apple. Apple uses it for all its own system software—such as the kernel and system libraries—because they can recompile the entire OS if the ABI changes. - Third-Party Support: Most third-party apps are distributed as arm64. Apple generally restricts the distribution of arm64e binaries in the App Store because the changing ABI would cause them to break on future macOS updates. - Binary Execution: - arm64 binaries run on all Apple Silicon Macs. - arm64e binaries only run on processors that support PAC (A12 chips or M1 and newer) and usually require special developer "preview" flags to run if they aren't signed by Apple. - Interoperability: An arm64 executable can call arm64e libraries, but an arm64e executable cannot call standard arm64 libraries for security reasons, as doing so would bypass the pointer protections. This last point is what bites brew in the backside, with dynamic libraries [which is how I ran into the problem earlier this week]. From tuhs at tuhs.org Sat May 9 04:47:08 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Fri, 08 May 2026 18:47:08 +0000 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: Ah, gotcha. Another thing I learned today and always glad to, thank you. On Friday, May 8th, 2026 at 7:28 PM, Clem Cole wrote, in part: > > - Interoperability: An arm64 executable can call arm64e libraries, but an arm64e executable cannot call standard arm64 libraries for security reasons, as doing so would bypass the pointer protections. > > This last point is what bites brew in the backside, with dynamic libraries [which is how I ran into the problem earlier this week]. From tuhs at tuhs.org Sat May 9 06:23:05 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 16:23:05 -0400 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 Message-ID: All the recent discussion about the original of the B Programming Language, PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has been lost to time. In 1977, Dennis published a Bell Laboratories internal memorandum entitled: "*A New Input-Output **Package*," which described libS. a for the then-current Sixth Edition. This is also the time frame of USG's work on Program Generic UNIX and what would be called UNIX/TS 1.0. The contents of this paper were rewritten to become Chapter 7 of K&R1 (including on page 144, discussion of -lS needed to be included at compile/link time). I would like to add a copy of the original paper to the TUHS archives, but I have been unable to find one so far. The one place I thought I might have one, I recently examined and was disappointed to find I had not kept that from my CMU days. My memory (which could be wrong here) was that it was included in the "Typesetter C" release, which was a compiler release for Sixth Edition sites that had obtained a license for a late 1970s version of a C source'd troff. The C compiler was an updated version of DMR's compiler with support for unsigned and union data types, typedef and bit-fields; as well as the new Standard I/O library (*a.k.a.*, libS.a) - as some of these had made their way into the "croff" source. That said, looking at the croff sources in PWB 1.0 shows that version doesn't use any of those features, and we know Joe died in 1977 — and I just don't remember what was in the distribution. As i said, my memory is hazy on all this. What I do remember is that we had a flavor of Joe's troff for the C/A/T at Tektronix in the late 1970s, and we were using a copy of vcat(1) that I got from Tom Ferrin at UCSF to "typeset" to a Versatec plotter. I will also note that Brian certainly used the new C language features, but he did not start on ditroff until 1979, published the paper on it in 1982, and in 1983 it was part of DWB. So .. if anyone can find a copy of the document, please let me know. Thanks, Clem From tuhs at tuhs.org Sat May 9 06:43:48 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Fri, 08 May 2026 20:43:48 +0000 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: References: Message-ID: <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev> On May 8, 2026, at 13:23, Clem Cole wrote: > All the recent discussion about the original of the B Programming Language, > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has > been lost to time. In 1977, Dennis published a Bell Laboratories internal > memorandum entitled: "*A New Input-Output **Package*," which described libS. > a for the then-current Sixth Edition. This is also the time frame of USG's > work on Program Generic UNIX and what would be called UNIX/TS 1.0. The contents > of this paper were rewritten to become Chapter 7 of K&R1 (including on page > 144, discussion of -lS needed to be included at compile/link time). > > I would like to add a copy of the original paper to the TUHS archives, but > I have been unable to find one so far. The one place I thought I might > have one, I recently examined and was disappointed to find I had not kept that > from my CMU days. This reminds me of Mike Leak’s portable C library, the immediate ancestor of stdio. There appear to be at least three revisions of the paper: - 1973: cited by https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf - 1975-05-16: https://archive.org/details/ThePortableCLibrary_May75 - 1975-06-27: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib The 1973 version is not archived, but Mike could be emailed. Discussion, including an answer of yours: https://retrocomputing.stackexchange.com/questions/25471/where-is-mike-lesks-circa-1973-portable-i-o-package-for-c Thalia From tuhs at tuhs.org Sat May 9 07:27:48 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 17:27:48 -0400 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev> References: <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev> Message-ID: below On Fri, May 8, 2026 at 4:43 PM Thalia Archibald wrote: > On May 8, 2026, at 13:23, Clem Cole wrote: > > All the recent discussion about the original of the B Programming > Language, > > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far > has > > been lost to time. In 1977, Dennis published a Bell Laboratories > internal > > memorandum entitled: "*A New Input-Output **Package*," which described > libS. > > a for the then-current Sixth Edition. This is also the time frame of > USG's > > work on Program Generic UNIX and what would be called UNIX/TS 1.0. The > contents > > of this paper were rewritten to become Chapter 7 of K&R1 (including on > page > > 144, discussion of -lS needed to be included at compile/link time). > > > > I would like to add a copy of the original paper to the TUHS archives, > but > > I have been unable to find one so far. The one place I thought I might > > have one, I recently examined and was disappointed to find I had not > kept that > > from my CMU days. > > This reminds me of Mike Leak’s portable C library, the immediate ancestor > of > stdio. There appear to be at least three revisions of the paper: > > - 1973: cited by > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf I don't think I ever saw this version. > > - 1975-05-16: https://archive.org/details/ThePortableCLibrary_May75 Thanks, I had seen this before and it is the most complete. It talks about things that he did not discuss in the version packaged with Sixth Edition. Besides making sure its in the TUHS Document's archives, we need check to ensure that it does indeed match the code; as well as trying to OCR it and see if we can recreate a cleaner version like I did with some of the B stuff from Dennis. > > - 1975-06-27: > https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib While the date is a month later, I suspect that is an artificat of the packaging of things to create the release and Dennis had grabbed an earlier verion. > > > The 1973 version is not archived, but Mike could be emailed. > Certainly, if only to see what changed. It would be best if we had both the earlier version and the code, but I suspect we have lost both to time. I'll try close the loop with Mike. > > Discussion, including an answer of yours: > > https://retrocomputing.stackexchange.com/questions/25471/where-is-mike-lesks-circa-1973-portable-i-o-package-for-c Yes, and I pointed to the V6 version. One of my longer term desires is in the TUHS archives to add a PDF and HTML directories for each release that has the doc files and man files turned into ODF abnd HTML for better viewing. That said Branden Robinson has been super when I have run into issues when I have tried to make modern rendering with groff of many of these older docs. > > > Thalia > From tuhs at tuhs.org Sat May 9 08:41:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 08 May 2026 22:41:18 +0000 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: References: Message-ID: On Friday, May 8th, 2026 at 13:23, Clem Cole via TUHS wrote: > All the recent discussion about the original of the B Programming Language, > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has > been lost to time. In 1977, Dennis published a Bell Laboratories internal > memorandum entitled: "*A New Input-Output **Package*," which described libS. > a for the then-current Sixth Edition. It looks like someone has digitized it as an HTML page here: http://roguelife.org/~fujita/COOKIES/HISTORY/V6/newgear.html Looks to be a Japanese UNIX history webpage: http://roguelife.org/~fujita/COOKIES/HISTORY/ I haven't explored the rest of their stuff, busy with a work thing right now, but that might bear some further leads. Note the http: if anyone is paranoid about that sort of thing. Not like you're sending credentials but as someone who is on https-only and has to approve all my http connections I got my expected popup, so fyi. - Matt G. From tuhs at tuhs.org Sat May 9 09:34:27 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 19:34:27 -0400 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: References: Message-ID: Matt, Thank you. With Nelson's help we did find a copy inside of the PWB 1.0 docs, though it's of very poor quality. https://bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf [pgs 169-174] By looking at Nelson's wonderful Unix Bibliography database, it looks like Dennis might have published it as TM1159, on 6-May-1977 As for this HTML file, unfortunately, it is both incomplete (missing several sections, including details on printf) and has a few entries that the PWB version lacks for a couple of string routines. On Fri, May 8, 2026 at 6:41 PM segaloco via TUHS wrote: > On Friday, May 8th, 2026 at 13:23, Clem Cole via TUHS > wrote: > > > All the recent discussion about the original of the B Programming > Language, > > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far > has > > been lost to time. In 1977, Dennis published a Bell Laboratories > internal > > memorandum entitled: "*A New Input-Output **Package*," which described > libS. > > a for the then-current Sixth Edition. > > It looks like someone has digitized it as an HTML page here: > > http://roguelife.org/~fujita/COOKIES/HISTORY/V6/newgear.html > > Looks to be a Japanese UNIX history webpage: > > http://roguelife.org/~fujita/COOKIES/HISTORY/ > > I haven't explored the rest of their stuff, busy with a > work thing right now, but that might bear some further leads. > Note the http: if anyone is paranoid about that sort of thing. > Not like you're sending credentials but as someone who is on > https-only and has to approve all my http connections I got my > expected popup, so fyi. > > - Matt G. > From tuhs at tuhs.org Sat May 9 10:22:54 2026 From: tuhs at tuhs.org (Anthony Martin via TUHS) Date: Fri, 8 May 2026 17:22:54 -0700 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: References: Message-ID: Is this the version you're looking for? https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/libc/stdio/ios.r It looks like it uses pretty standard ms(6) macros. The Plan 9 version of troff(1) handles it well. Cheers, Anthony From tuhs at tuhs.org Sat May 9 11:07:30 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 9 May 2026 11:07:30 +1000 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: <20260508174630.GL25310@mcvoy.com> References: <20260508174630.GL25310@mcvoy.com> Message-ID: On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote: > Huh, I just learned that Andrew was part of Masscomp. Clem, how did that > come about? The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not the Andrew Tanenbaum (ast) associated with MINIX. From tuhs at tuhs.org Sat May 9 11:24:35 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 8 May 2026 21:24:35 -0400 Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library paper from 1977 In-Reply-To: References: Message-ID: Yes, it is!! Thank you. And now I see we have a number of copies scattered in the archives. It's in the s4 directory of the PWB1.0 sources, on the BBN tcp tape, and in 2.9, 2.11, and 4.3BSD as part of the ctour directories, and I just found another copy in the uu.net archives. On Fri, May 8, 2026 at 8:23 PM Anthony Martin wrote: > Is this the version you're looking for? > > https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/libc/stdio/ios.r > > It looks like it uses pretty standard ms(6) macros. > The Plan 9 version of troff(1) handles it well. > > Cheers, > Anthony > From tuhs at tuhs.org Sat May 9 11:30:04 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 8 May 2026 18:30:04 -0700 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: References: <20260508174630.GL25310@mcvoy.com> Message-ID: <20260509013004.GN25310@mcvoy.com> On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote: > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote: > > Huh, I just learned that Andrew was part of Masscomp. Clem, how did that > > come about? > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not > the Andrew Tanenbaum (ast) associated with MINIX. But it was the Masscomp guy who did the history writeup? I could see that with Clem at Masscomp, Clem knows the history. Thanks for the clarification Jonathan, appreciate it. In the information you didn't ask for department, I'm half Dutch, have lived there, learned the language, some, and I interviewed with ast to go to grad school there (I think, it was a long time ago, when I went there is not clear but I did interview with him). I really liked the Minix idea, it wasn't as good as QNX but it was mostly (I think) just him. It's a significant chunk of work. I decided to pass because the building he was in was gray, the furniture was gray, the weather was gray. That's trite but where he was working just didn't suck me in. While I don't regret that choice, I think working with him could have been fun. --lm From tuhs at tuhs.org Sat May 9 12:50:56 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 8 May 2026 22:50:56 -0400 Subject: [TUHS] PG3 or Gen3.0? In-Reply-To: References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev> <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com> <20260508001138.GE25310@mcvoy.com> <20260508142513.GI25310@mcvoy.com> Message-ID: On Fri, May 8, 2026 at 2:17 PM segaloco via TUHS wrote: > Granted this is now getting quite far afield from the original subject. To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V now, so that means there is also hope for bootstrapping other historic UNIX systems (like PG3) on RISC-V. Yeah, as Warner pointed out, this isn't quite accurate. xv6 isn't a port in any meaningful way, and in particular it shares no code with 6th Ed. Rather, it is an independent reimplementation along similar design lines. Even under that very loose constraint, however, much is different. Some things were added to be there from the start: xv6 protects kernel data structures with fine-grained locks, and has supported SMP machines from inception. Additionally, virtual memory segments are constructed on top of a page-based virtual address space. Some were removed: xv6 doesn't really support a notion of "users" or terminal devices, file permissions really exist (partly as a consequence of not having users), and a number of system calls were deliberately not added. These differences are not gratuitous, but rather pragmatic: it's a pedagogical system, so the selection is primarily based on educational relevance. Some things (a few system calls, etc) are left as exercises for students. - Dan C. From tuhs at tuhs.org Sat May 9 15:54:26 2026 From: tuhs at tuhs.org (Andy Kosela via TUHS) Date: Sat, 9 May 2026 07:54:26 +0200 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: <20260509013004.GN25310@mcvoy.com> References: <20260508174630.GL25310@mcvoy.com> <20260509013004.GN25310@mcvoy.com> Message-ID: On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS wrote: > On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote: > > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote: > > > Huh, I just learned that Andrew was part of Masscomp. Clem, how did > that > > > come about? > > > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not > > the Andrew Tanenbaum (ast) associated with MINIX. > > But it was the Masscomp guy who did the history writeup? I could see that > with Clem at Masscomp, Clem knows the history. > > Thanks for the clarification Jonathan, appreciate it. > > In the information you didn't ask for department, I'm half Dutch, > have lived there, learned the language, some, and I interviewed with > ast to go to grad school there (I think, it was a long time ago, when I > went there is not clear but I did interview with him). I really liked > the Minix idea, it wasn't as good as QNX but it was mostly (I think) > just him. It's a significant chunk of work. I decided to pass because > the building he was in was gray, the furniture was gray, the weather > was gray. That's trite but where he was working just didn't suck me in. > While I don't regret that choice, I think working with him could have > been fun. While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3 was a different beast. It was intended to be production-grade and developed as a collaborative effort. I know this because I contributed some code to it. It also leveraged the NetBSD userland. That included: - NetBSD libc - NetBSD build infrastructure - many NetBSD userland utilities: ls, cp, sh, etc. - NetBSD bootloader components - pkgsrc package system In practice, later MINIX 3 felt closer to a small NetBSD-like system running on top of the MINIX microkernel than to the older, fully self-contained MINIX 1/2 systems. It was really nice and I am still amazed why it did not become more popular. --Andy From tuhs at tuhs.org Sat May 9 22:31:03 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 9 May 2026 08:31:03 -0400 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: References: <20260508174630.GL25310@mcvoy.com> <20260509013004.GN25310@mcvoy.com> Message-ID: Yes, he was an early Masscomp hacker. How did that happen? Easy, trb was a friend of mine from a few years previously. I had joined Masscomp as the second Unix hacker to help Tom with the O very early on. But shortly there after we started expanding as there was a lot to do, and I introduced trb to our VP of Eng (Lorin Gale) and Lorin hired him. IIRC: He worked extensively on the command system, for maybe two or three years. As I recall he was living closer to Boston proper and had a social life centered around Cambridge. While Masscomp was out on 495 (Littleton/Westford), so he had a bit if a haul. Eventually he took a job closer Cambridge. At some point he landed in the Boston office of Interactive Systems Corp, which is when he wrote that note, but I don’t remember if he had a stop somewhere else before that. I’ll have to ask him. Clem Sent from a handheld expect more typos than usual On Sat, May 9, 2026 at 1:54 AM Andy Kosela via TUHS wrote: > On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS wrote: > > > On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote: > > > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote: > > > > Huh, I just learned that Andrew was part of Masscomp. Clem, how did > > that > > > > come about? > > > > > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not > > > the Andrew Tanenbaum (ast) associated with MINIX. > > > > But it was the Masscomp guy who did the history writeup? I could see > that > > with Clem at Masscomp, Clem knows the history. > > > > Thanks for the clarification Jonathan, appreciate it. > > > > In the information you didn't ask for department, I'm half Dutch, > > have lived there, learned the language, some, and I interviewed with > > ast to go to grad school there (I think, it was a long time ago, when I > > went there is not clear but I did interview with him). I really liked > > the Minix idea, it wasn't as good as QNX but it was mostly (I think) > > just him. It's a significant chunk of work. I decided to pass because > > the building he was in was gray, the furniture was gray, the weather > > was gray. That's trite but where he was working just didn't suck me in. > > While I don't regret that choice, I think working with him could have > > been fun. > > > While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3 > was a different beast. It was intended to be production-grade and developed > as a collaborative effort. I know this because I contributed some code to > it. It also leveraged the NetBSD userland. > > That included: > > - NetBSD libc > - NetBSD build infrastructure > - many NetBSD userland utilities: ls, cp, sh, etc. > - NetBSD bootloader components > - pkgsrc package system > > In practice, later MINIX 3 felt closer to a small NetBSD-like system > running on top of the MINIX microkernel than to the older, fully > self-contained MINIX 1/2 systems. It was really nice and I am still amazed > why it did not become more popular. > > --Andy > From tuhs at tuhs.org Sat May 9 22:39:19 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 9 May 2026 08:39:19 -0400 Subject: [TUHS] Some UNIX/TS Info From John Mashey In-Reply-To: References: <20260508174630.GL25310@mcvoy.com> <20260509013004.GN25310@mcvoy.com> Message-ID: BTW: for people newish to the Unix community, as noted there are two people in our community named Andy Tannenbaum. They are both wonderful people, and have enjoyed knowing them both. And for those of us that have known them, they are sometimes referred to as “landscape” and “portrait” - I’ll leave it to the reader to find pictures of each and to figure out which us which. 😉 Sent from a handheld expect more typos than usual On Sat, May 9, 2026 at 8:31 AM Clem Cole wrote: > Yes, he was an early Masscomp hacker. How did that happen? Easy, trb was > a friend of mine from a few years previously. I had joined Masscomp as the > second Unix hacker to help Tom with the O very early on. But shortly > there after we started expanding as there was a lot to do, and I > introduced trb to our VP of Eng (Lorin Gale) and Lorin hired him. IIRC: He > worked extensively on the command system, for maybe two or three years. > > As I recall he was living closer to Boston proper and had a social life > centered around Cambridge. While Masscomp was out on 495 > (Littleton/Westford), so he had a bit if a haul. Eventually he took a job > closer Cambridge. At some point he landed in the Boston office of > Interactive Systems Corp, which is when he wrote that note, but I don’t > remember if he had a stop somewhere else before that. I’ll have to ask him. > > > Clem > > > Sent from a handheld expect more typos than usual > > On Sat, May 9, 2026 at 1:54 AM Andy Kosela via TUHS wrote: > >> On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS >> wrote: >> >> > On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote: >> > > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote: >> > > > Huh, I just learned that Andrew was part of Masscomp. Clem, how did >> > that >> > > > come about? >> > > >> > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not >> > > the Andrew Tanenbaum (ast) associated with MINIX. >> > >> > But it was the Masscomp guy who did the history writeup? I could see >> that >> > with Clem at Masscomp, Clem knows the history. >> > >> > Thanks for the clarification Jonathan, appreciate it. >> > >> > In the information you didn't ask for department, I'm half Dutch, >> > have lived there, learned the language, some, and I interviewed with >> > ast to go to grad school there (I think, it was a long time ago, when I >> > went there is not clear but I did interview with him). I really liked >> > the Minix idea, it wasn't as good as QNX but it was mostly (I think) >> > just him. It's a significant chunk of work. I decided to pass because >> > the building he was in was gray, the furniture was gray, the weather >> > was gray. That's trite but where he was working just didn't suck me in. >> > While I don't regret that choice, I think working with him could have >> > been fun. >> >> >> While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3 >> was a different beast. It was intended to be production-grade and >> developed >> as a collaborative effort. I know this because I contributed some code to >> it. It also leveraged the NetBSD userland. >> >> That included: >> >> - NetBSD libc >> - NetBSD build infrastructure >> - many NetBSD userland utilities: ls, cp, sh, etc. >> - NetBSD bootloader components >> - pkgsrc package system >> >> In practice, later MINIX 3 felt closer to a small NetBSD-like system >> running on top of the MINIX microkernel than to the older, fully >> self-contained MINIX 1/2 systems. It was really nice and I am still amazed >> why it did not become more popular. >> >> --Andy >> > From tuhs at tuhs.org Sun May 10 01:40:09 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 09 May 2026 15:40:09 +0000 Subject: [TUHS] PDP-11/20 On eBay Message-ID: Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention: https://www.ebay.com/itm/327147586264 After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element. I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup. Happy hunting! - Matt G. From tuhs at tuhs.org Sun May 10 01:45:56 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Sat, 09 May 2026 15:45:56 +0000 Subject: [TUHS] PDP-11/20 On eBay In-Reply-To: References: Message-ID: There’s also an 11/55 up for sale: https://www.ebay.com/itm/145952655225 You could actually bring UNIX up on this thing, but it only has a couple of RX01 floppies. ------ Original Message ------ >From "segaloco via TUHS" To "The Eunuchs Hysterical Society" Date 5/9/2026 11:40:09 AM Subject [TUHS] PDP-11/20 On eBay >Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention: > >https://www.ebay.com/itm/327147586264 > >After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element. I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup. Happy hunting! > >- Matt G. From tuhs at tuhs.org Sun May 10 02:11:20 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 09 May 2026 16:11:20 +0000 Subject: [TUHS] PDP-11/20 On eBay In-Reply-To: References: Message-ID: On Saturday, May 9th, 2026 at 08:46, Ron Natalie wrote: > There’s also an 11/55 up for sale: > https://www.ebay.com/itm/145952655225 > > You could actually bring UNIX up on this thing, but it only has a couple > of RX01 floppies. Wowzers can these price tags get eyewatering. I wonder to what degree UNIX alone influences the PDP-11 resale market vs. the DEC operating systems... - Matt G. From tuhs at tuhs.org Sun May 10 04:25:48 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Sat, 09 May 2026 18:25:48 +0000 Subject: [TUHS] PDP-11/20 On eBay In-Reply-To: References: Message-ID: On the other hand, for a few hundred dollars you can build a Microsoft PI simulation of an 11-70 (the PiDP-11/70 kit even comes with a pretty cool scale model of the control panel). I’ve got it chugging away running 2.9 BSD right now (though I can boot of the Really Sh-ty Timesharing System for old time’s sake). One of these days, I’ll switch out the kernel to the BRL one that I spent ten years working on. ------ Original Message ------ >From "segaloco via TUHS" To "The Eunuchs Hysterical Society" Date 5/9/2026 12:11:20 PM Subject [TUHS] Re: PDP-11/20 On eBay >On Saturday, May 9th, 2026 at 08:46, Ron Natalie wrote: > >> There’s also an 11/55 up for sale: >> https://www.ebay.com/itm/145952655225 >> >> You could actually bring UNIX up on this thing, but it only has a couple >> of RX01 floppies. > >Wowzers can these price tags get eyewatering. I wonder to what degree UNIX alone influences the PDP-11 resale market vs. the DEC operating systems... > >- Matt G. From tuhs at tuhs.org Mon May 11 07:28:31 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Sun, 10 May 2026 14:28:31 -0700 Subject: [TUHS] PDP-11/20 On eBay In-Reply-To: References: Message-ID: On Sat, May 9, 2026 at 8:40 AM segaloco via TUHS wrote: > > Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention: > > https://www.ebay.com/itm/327147586264 > > After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element. I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup. Happy hunting! If you want to play around with stuff like this but can't, I'll plug my friend Dave McGuire's Large Scale Systems Museum in the Pittsburgh area. It's really worth a trek if you enjoy unix history, you can walk up and boot unix on a PDP or VAX. Ken Shariff did a review a while back https://www.righto.com/2019/10/a-visit-to-large-scale-systems-museum.html. The official website is https://www.mact.io/ > - Matt G. From tuhs at tuhs.org Mon May 11 08:22:25 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 10 May 2026 18:22:25 -0400 Subject: [TUHS] PDP-11/20 On eBay In-Reply-To: References: Message-ID: On Sat, May 9, 2026 at 11:40 AM segaloco via TUHS wrote: > ... After the link is an auction for a PDP-11/20 with a KE11-A Extended > Arithmetic Element. I don't off the top of my head know if this is enough > to be the core of a V1/V2 system, but figured I'd mention it in case any > intrepid list members are trying to roll a real V1/V2 setup. Happy hunting! > It needs KE11-A, as Dennis required it for his compiler, so that's a check box. But there are other issues: the earliest versions of the PDP-11/20 did not have an MMU (or user/supervisor), but did have a maximum memory of 56K for a stock 11/20. Dennis describes the early issues of running without an MMU and actually what happened after they got one (KS-11): https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html So, to really run early Unix on the 121/20, you need a KS-11 and a full complement of Unibus memory (256K). None of these seems to have been found in the wild, much less the documentation. Supnik's MIMIC supports it, and we also have some early UNIX code. Together what we know can be found here: https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option From tuhs at tuhs.org Tue May 12 18:19:25 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Tue, 12 May 2026 10:19:25 +0200 Subject: [TUHS] fork Message-ID: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Hello, I succeeded in implementing DEQNA support in my emulator so I could put it on-line with a simple HTTP server on BSD 2.11. Now something unexpected is happening: after a request, a "" proces is left in the process list. Usually that is caused by a fork() not being join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, SIG_IGN); so I thought I took care of that? Could it be that old UNIX systems do not allow the signal-construction for that? Or is something else going wrong? regards p.s. it is on http://pdp.komputilo.nl:8080/ (behind a NAT router) and it takes quite a while to serve pages :-) -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com From tuhs at tuhs.org Tue May 12 18:39:38 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 12 May 2026 18:39:38 +1000 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: On Tue, May 12, 2026 at 10:19:25AM +0200, Folkert van Heusden via TUHS wrote: > Now something unexpected is happening: after a request, a "" proces > is left in the process list. Usually that is caused by a fork() not being > join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, > SIG_IGN); so I thought I took care of that? I'm going to take an educated guess. You fork() a child, but in the parent process you never wait()? Thus, once the child exit()s, no process collects the exit status and so the child becomes a zombie process. Eventually the init process will reap your child's exit status. signal(SIGCHLD, SIG_IGN) is only going to make the parent ignore any change to the child's status; it doesn't take the child out of the process table. Technically (I believe), the child's memory and other resources are freed when it exit(s), but the process-id, the exit status and the slot in the process table stay there until someone wait(s). Cheers, Warren From tuhs at tuhs.org Tue May 12 20:55:09 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 12 May 2026 10:55:09 +0000 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: Processes stay zombines until someone waits for them. If their parent is alive, it will have to execute a wait() to get the status. If the parent is dead, prossess 1 (historically INIT) will becoe the parent for the purpose of wain(). Note that there are differing SIGCHLD / SIGCLD behaviors, In addition to the sitnal being caught telling the process that there’s something to wait on, some systems take specifally setting SIGCHLD to SIG_IGN as an indiation that you don’t ever want to wait and any children when they die will immediately go away without entering the zombine state. From tuhs at tuhs.org Tue May 12 21:18:48 2026 From: tuhs at tuhs.org (Peter Jeremy via TUHS) Date: Tue, 12 May 2026 21:18:48 +1000 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS wrote: >Now something unexpected is happening: after a request, a "" proces >is left in the process list. Usually that is caused by a fork() not being >join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, >SIG_IGN); so I thought I took care of that? For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN means that child processes will not become zombies but will instead be implicitly reaped immediately. This doesn't exist in BSD2.11 and, as far as I can tell from looking through the sources, there's no equivalent behaviour: When a process exits, the process becomes a zombie and the parent is sent a SIGCHLD (see kern_exit.c::exit()). In psignal(), if a signal is marked SIG_IGN, the signal is completely ignored - there's no special handling of SIGCHLD. There's no obvious code to clean up zombie processes if the parent doesn't wait() for them. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tuhs at tuhs.org Tue May 12 22:38:14 2026 From: tuhs at tuhs.org (rob--- via TUHS) Date: Tue, 12 May 2026 13:38:14 +0100 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: I remember having to use a double fork() in the 90’s which I think maybe to solve a problem like this that the top process can fork() and wait() but the child fork(’s again and exits so that the death of the grandchild process gets cleaned by by init. Regards, Rob. > On 12 May 2026, at 12:18, Peter Jeremy via TUHS wrote: > > On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS wrote: >> Now something unexpected is happening: after a request, a "" proces >> is left in the process list. Usually that is caused by a fork() not being >> join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, >> SIG_IGN); so I thought I took care of that? > > For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag > for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN means that > child processes will not become zombies but will instead be implicitly > reaped immediately. > > This doesn't exist in BSD2.11 and, as far as I can tell from looking > through the sources, there's no equivalent behaviour: When a process exits, > the process becomes a zombie and the parent is sent a SIGCHLD (see > kern_exit.c::exit()). In psignal(), if a signal is marked SIG_IGN, the > signal is completely ignored - there's no special handling of SIGCHLD. > There's no obvious code to clean up zombie processes if the parent doesn't > wait() for them. > > -- > Peter Jeremy From tuhs at tuhs.org Wed May 13 00:18:48 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Tue, 12 May 2026 16:18:48 +0200 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: <20260512141848.eLpWpVzc@steffen%sdaoden.eu> rob--- via TUHS wrote in : |> On 12 May 2026, at 12:18, Peter Jeremy via TUHS wrote: |> |> On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS rg> wrote: |>> Now something unexpected is happening: after a request, a "" \ |>> proces |>> is left in the process list. Usually that is caused by a fork() \ |>> not being |>> join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, |>> SIG_IGN); so I thought I took care of that? |> |> For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag |> for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN \ |> means that |> child processes will not become zombies but will instead be implicitly |> reaped immediately. |> |> This doesn't exist in BSD2.11 and, as far as I can tell from looking |> through the sources, there's no equivalent behaviour: When a process \ |> exits, |> the process becomes a zombie and the parent is sent a SIGCHLD (see |> kern_exit.c::exit()). In psignal(), if a signal is marked SIG_IGN, the |> signal is completely ignored - there's no special handling of SIGCHLD. |> There's no obvious code to clean up zombie processes if the parent \ |> doesn't |> wait() for them. |I remember having to use a double fork() in the 90’s which I think \ |maybe to solve a problem like this that the top process can fork() \ |and wait() but the child fork(’s again and exits so that the death \ |of the grandchild process gets cleaned by by init. In a communication this year a friendly Russian said By the way, I thought that double fork is something useless for dozens of years. As I remember, the second fork() was needed because of relatively old SysV-like systems still gave more than enough permissions to the child process after the first fork(). As I remember Richard Stevens book, BSDs never required second fork. fork()+setsid() were enough. But I guess maybe Linux inherited SysV-like behaviour/issue and that is why second fork() is needed. and he refers to advanced_pogramming_in_the_unix_environment, 13.3, Coding Rules, on daemonization: 2. Call fork and have the parent exit. This does several things. First, if the daemon was started as a simple shell command, having the parent terminate makes the shell think that the command is done. Second, the child inherits the process group ID of the parent but gets a new process ID, so we're guaranteed that the child is not a process group leader. This is a prerequisite for the call to setsid that is done next. 3. Call setsid to create a new session. The three steps listed in Section 9.5 occur. The process (a) becomes a session leader of a new session, (b) becomes the process group leader of a new process group, and (c) has no controlling terminal. Under System V–based systems, some people recommend calling fork again at this point and having the parent terminate. The second child continues as the daemon. This guarantees that the daemon is not a session leader, which prevents it from acquiring a controlling terminal under the System V rules (Section 9.6). Alternatively, to avoid acquiring a controlling terminal, be sure to specify O_NOCTTY whenever opening a terminal device. [Which in turn is POSIX.1 leaves the choice of the mechanism used to allocate a controlling terminal up to each individual implementation. We'll show the actual steps in Section 19.4. Systems derived from UNIX System V allocate the controlling terminal for a session when the session leader opens the first terminal device that is not already associated with a session. This assumes that the call to open by the session leader does not specify the O_NOCTTY flag (Section 3.3). BSD-based systems allocate the controlling terminal for a session when the session leader calls ioctl with a request argument of TIOCSCTTY (the third argument is a null pointer). The session cannot already have a controlling terminal for this call to succeed. (Normally, this call to ioctl follows a call to setsid, which guarantees that the process is a session leader without a controlling terminal.) The POSIX.1 O_NOCTTY flag to open is not used by BSD-based systems, except in compatibility-mode support for other systems.] (He mentioned this, i think, because i do double fork in some stupid little thing (greylister), but this is because of Linux and FreeBSD sandboxing .. and the "necessity" to separate the actual syslog interaction, on Linux mostly because of who knows what syslog internally needs .. and fd is opened delayed etc etc etc. OpenBSD has added a syslog system call which makes that topic easy. Btw, and imho, Linux seccomp should really have a way to simply declare a bitmask of allowed or forbidden system calls, instead of these lengthy tit-and-tat things. Maybe landlock, .. but this is off topic, of course.) New FreeBSD and Linux offer possibilities to declare the "reaper" process to which PIDs get reparented. FreeBSD with iteration over, and all that. (Then again this is not well integrated in respect to P(luggable)A(uthentication)M(odules), which is pretty well used on Linux, FreeBSD, NetBSD, and offers sessions, but any idiot -- even myself that is -- can "escape" from these sessions with a simple I/O-redirected shell command, effectively ending up with init(8), because they do not use this reaper functionality. On Linux, you have that systemd monster, which surely does this the right way, on top, say. There is finit, i think it also tries to go cgroup + X, but in how far it does X, aka capabilities, overlay mounts (for eg /tmp/), i would have to look again. BSDs, anyway not. The mentioned guy swears on s6 / runit, which is then also some approach, more UNIX-like, that much is plain. Puh. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed May 13 00:32:18 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Tue, 12 May 2026 10:32:18 -0400 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: <202605121432.64CEWIqd038238@ultimate.com> > But in main() of httpdp I invoke > signal(SIGCHLD, SIG_IGN); so I thought I took care of that? > > Could it be that old UNIX systems do not allow the signal-construction > for that? Or is something else going wrong? I seem to recall that the magic property of discarding zombies if SIGCHLD is ignored was introduced by AT&T (in System V?), later made user controllable in one of the Grand Unification effort [SUSv2?] I also have vague recollection of some signal define having different spellings in the different camps, but can't find any trace of it having been SIGCHILD [sic]! From tuhs at tuhs.org Wed May 13 00:51:30 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 12 May 2026 10:51:30 -0400 Subject: [TUHS] fork In-Reply-To: <202605121432.64CEWIqd038238@ultimate.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <202605121432.64CEWIqd038238@ultimate.com> Message-ID: <309ff4ac-00f9-4d87-9099-41267a8cf798@case.edu> On 5/12/26 10:32 AM, Phil Budne via TUHS wrote: > I also have vague recollection of some signal define having different > spellings in the different camps, but can't find any trace of it > having been SIGCHILD [sic]! SIGCHLD vs. SIGCLD. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Wed May 13 02:51:52 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Tue, 12 May 2026 18:51:52 +0200 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: <9de657ea744fea9717775d533724933d@vanheusden.com> Thanks to everybody who responded. After a waitpid() in the signal handler, all is good. Never realised that you could do that in a signal handler! With that, it runs a lot longer before I need to restart something :-) Strange thing though is that I need to do e.g. a ping from bsd to $world to keep things going. If not, it keeps running but won't respond anymore to network traffic. regards From tuhs at tuhs.org Wed May 13 03:12:29 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 12 May 2026 13:12:29 -0400 Subject: [TUHS] fork In-Reply-To: <9de657ea744fea9717775d533724933d@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> Message-ID: On Tue, May 12, 2026 at 12:52 PM Folkert van Heusden via TUHS wrote: >[snip] > Strange thing though is that I need to do e.g. a ping from bsd to $world > to keep things going. If not, it keeps running but won't respond anymore > to network traffic. Hmm. Off the top of my head, I wonder if it's an ARP issue. Is your emulator passing ARP requests for thye BSD system correctly? - Dan C. From tuhs at tuhs.org Wed May 13 06:11:16 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Tue, 12 May 2026 22:11:16 +0200 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> Message-ID: <6337e07d002dba23bcc069d8205cb6f6@vanheusden.com> >> [snip] >> Strange thing though is that I need to do e.g. a ping from bsd to >> $world >> to keep things going. If not, it keeps running but won't respond >> anymore >> to network traffic. > > Hmm. Off the top of my head, I wonder if it's an ARP issue. > Is your emulator passing ARP requests for thye BSD system correctly? I think it does because else it would not be able to communicate at all I think. Maybe the ARP entries are evicted from the cache (on either side) for some reason. Something else is strange too: I configured the netmask to 255.255.254.0 (for 192.168.64.0/23) and it sets that to 255.255.255.0. From tuhs at tuhs.org Wed May 13 06:34:13 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 12 May 2026 14:34:13 -0600 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: On Tue, May 12, 2026 at 5:19 AM Peter Jeremy via TUHS wrote: > On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS > wrote: > >Now something unexpected is happening: after a request, a "" > proces > >is left in the process list. Usually that is caused by a fork() not being > >join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD, > >SIG_IGN); so I thought I took care of that? > > For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag > for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN means that > child processes will not become zombies but will instead be implicitly > reaped immediately. > Yes. This was defined in System V (I think r4, but I'm not 100% sure). 4.4BSD didn't have it. FreeBSD added it in 1997. Linux had it earlier due to its affinity to System V, though I've not done a deep dive on this yet. > This doesn't exist in BSD2.11 and, as far as I can tell from looking > through the sources, there's no equivalent behaviour: When a process exits, > the process becomes a zombie and the parent is sent a SIGCHLD (see > kern_exit.c::exit()). In psignal(), if a signal is marked SIG_IGN, the > signal is completely ignored - there's no special handling of SIGCHLD. > There's no obvious code to clean up zombie processes if the parent doesn't > wait() for them. > Over simplifying a bit, 2.11BSD was 7th Edition, with lots of add-ons from 4.2BSD and 4.3BSD, plus a number of pdp-11 only things that post-dated the 7th edition (like overlay support). Most of the kernel-side components originated from 4.2BSD with a few updates from 4.3BSD. Since 4BSD at CSRG never had SA_NOCLDWAIT, 2.11 doesn't have it. The zombies are only cleaned up when the parent exits and they wind up at init. Other reapers came much later. Warner From tuhs at tuhs.org Wed May 13 14:53:38 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Wed, 13 May 2026 04:53:38 +0000 Subject: [TUHS] fork In-Reply-To: <9de657ea744fea9717775d533724933d@vanheusden.com> (Folkert van Heusden via TUHS's message of "Tue, 12 May 2026 18:51:52 +0200") References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> Message-ID: <7wlddnkizx.fsf@junk.nocrew.org> Folkert van Heusden wrote: > After a waitpid() in the signal handler, all is good. > Never realised that you could do that in a signal handler! Maybe you "can't". That is, if you strictly follow the C standard. There are very few things you are allowed to do inside a signal handler. POSIX relaxes the constraints considerably, and it seems waitpid is indeed allowed. From tuhs at tuhs.org Wed May 13 15:24:13 2026 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Wed, 13 May 2026 07:24:13 +0200 Subject: [TUHS] fork In-Reply-To: <6337e07d002dba23bcc069d8205cb6f6@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> <6337e07d002dba23bcc069d8205cb6f6@vanheusden.com> Message-ID: On Tue, May 12, 2026 at 10:11:16PM +0200, Folkert van Heusden via TUHS wrote: > I think it does because else it would not be able to communicate at all I > think. Maybe the ARP entries are evicted from the cache (on either side) for > some reason. > > > > Something else is strange too: I configured the netmask to 255.255.254.0 > (for 192.168.64.0/23) and it sets that to 255.255.255.0. Not sure 2.11BSD supports CIDR (aka. classless) or if you have to enable it. If not then 192.168.x.x will always end up with a /24 (Class C) netmask and things like 172.x.x.x a /16 (Class B) and 10.x.x.x with a /8 (Class A) Also such a netmask mismatch between your router/gw and the device will cause broadcast (and thus ARP) handling issues. Modern devices will (re)populate their ARP table if they receive a packet from an unknown device so they learn quicker and things can kinda limp along but in reality it is b0rken ;) Older OS'es don't tend to do that and have a more strict handling in that respect so issues like this pop up sooner there.. Bye, Arno. From tuhs at tuhs.org Wed May 13 21:29:15 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 13 May 2026 07:29:15 -0400 Subject: [TUHS] fork In-Reply-To: <7wlddnkizx.fsf@junk.nocrew.org> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> <7wlddnkizx.fsf@junk.nocrew.org> Message-ID: On Wed, May 13, 2026 at 1:04 AM Lars Brinkhoff via TUHS wrote: > Folkert van Heusden wrote: > > After a waitpid() in the signal handler, all is good. > > Never realised that you could do that in a signal handler! > > Maybe you "can't". That is, if you strictly follow the C standard. > There are very few things you are allowed to do inside a signal handler. In ISO C, you can't. The rules are a bit different if you the signal handler is invoked synchronously, but if it's not, the things the program can do that do not result in the dreaded, "undefined behavior" are very limited. It can manipulate stack locals are, use values of integer type `volatile sig_atomic_t`, use lock-free atomics, and call a handful of functions to halt the program. But ISO C doesn't know anything about processes, fork, SIGCHLD, or waitpid. :-D > POSIX relaxes the constraints considerably, and it seems waitpid is > indeed allowed. Yes. Each edition of POSIX includes a defined version of ISO C as a normative reference; for POSIX.1-2024 (properly, "The Open Group Base Specifications Issue 8, IEEE Std 1003.1 - 2024 Edition"), that version is C17 (aka, "ISO/IEC 9899:2018, Programming Languages - C"). The rules from ISO C still about, but functions that are what POSIX calls, "async-signal-safe" are allowable in signal signal handlers. `waitpid` is one of those. There are something like 200 of them: https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04 Btw, a fun trick to turn a signal into a synchronous event, is what is sometimes called the, "self-pipe" trick. Here, you create a pipe, set the write-end of it to be non-blocking, and in your signal handler, write a byte into the pipe (you make it non-blocking so that you never block in the signal handler, should the pipe fill up). Then, you can run `select` (or `poll` or whatever) in your "main loop" and add the read-end of the pipe to the read-set you're selecting on; when you receive a signal, that pipe will become readable, you read a byte out of it, and you can do whatever you would have needed to do to handle the signal in a normal context. I think Dan Bernstein was the first person to document the idea. - Dan C. From tuhs at tuhs.org Thu May 14 10:30:28 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 14 May 2026 10:30:28 +1000 Subject: [TUHS] Test e-mail: ignore Message-ID: All, I just made a big server change; I've split my personal e-mail/www server "minnie" off from the main TUHS server. This is to ensure that the TUHS is still working. Please ignore! Thanks, Warren From tuhs at tuhs.org Thu May 14 11:57:27 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Thu, 14 May 2026 01:57:27 +0000 Subject: [TUHS] What is this 1972 C/NB program? Message-ID: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> This mysterious program is in the s1 tape, but has not yet been identified. Does it look familiar? https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c It looks like it processes line continuations. It filters files to only runs of lines continued with hyphen with the adjoining whitespace stripped. Only letters and hyphens are allowed in such lines. [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* But there's bugs, so the grammar is actually the following, where EOF is included in the negated sets as NUL: ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* Could this be a sort of preprocessor? Perhaps for some sort of a configuration language? It reads the list of named files, printing each filename with "%s:\n \n" before. The space on an empty line is strange. It uses & and | for conditionals and is typed, characteristic of early C and NB. It uses this horrid indentation style, which doesn't match ken or dmr. Do you recognize who? Example: while((b[++i] = get(ifile)) != 0) {if((b[i] >= 'a' & b[i] <= 'z') | (b[i] >= 'A' & b[i] <= 'Z')) {c[j++] = b[i]; goto cont; } I've taken some liberties to simplify it below. I changed it to operate on a single file. And equivalently, I reformatted it, replaced an unnecessary buffer with a single char, and simplified control flow. See the above link for the original. char c[60]; main(argc, argv) int argc; char *argv[]; { char b; int isw, j, k; isw = j = 0; while((b = getchar()) != 0) { if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= 'Z')) { c[j++] = b; continue; } if(b == '-') { c[j++] = b; if((b = getchar()) != '\n') { c[j++] = b; continue; } if(j == 1) { isw = j = 0; continue; } isw = 1; while(((b = getchar()) == ' ') || (b == '\t') || (b == '\n')) ; c[j++] = b; continue; } if(isw == 1) { k = 0; c[j++] = '\n'; while(k < j) putchar(c[k++]); } isw = j = 0; } } Thalia From tuhs at tuhs.org Thu May 14 13:35:19 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Thu, 14 May 2026 13:35:19 +1000 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: On Thu, May 14, 2026 at 01:57:27AM +0000, Thalia Archibald via TUHS wrote: > This mysterious program is in the s1 tape, but has not yet been identified. > Does it look familiar? > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c very close to https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd2/hyphen.c described in the Program Generic PG-1C300 issue 2 manual on bitsavers: hyphen(VI) find hyphenated words From tuhs at tuhs.org Thu May 14 13:47:15 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Thu, 14 May 2026 03:47:15 +0000 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: On May 13, 2026, at 21:35, Jonathan Gray wrote: > On Thu, May 14, 2026 at 01:57:27AM +0000, Thalia Archibald wrote: >> This mysterious program is in the s1 tape, but has not yet been identified. >> Does it look familiar? >> https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > very close to > https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd2/hyphen.c > > described in the Program Generic PG-1C300 issue 2 manual on bitsavers: > > hyphen(VI) find hyphenated words Such a simple utility. Classic UNIX. Thalia From tuhs at tuhs.org Thu May 14 21:50:02 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Thu, 14 May 2026 13:50:02 +0200 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> <6337e07d002dba23bcc069d8205cb6f6@vanheusden.com> Message-ID: >> I think it does because else it would not be able to communicate at >> all I >> think. Maybe the ARP entries are evicted from the cache (on either >> side) for >> some reason. >> >> Something else is strange too: I configured the netmask to >> 255.255.254.0 >> (for 192.168.64.0/23) and it sets that to 255.255.255.0. > > Not sure 2.11BSD supports CIDR (aka. classless) or if you have to > enable it. > > If not then 192.168.x.x will always end up with a /24 (Class C) netmask > and things like 172.x.x.x a /16 (Class B) and 10.x.x.x with a /8 (Class > A) > > Also such a netmask mismatch between your router/gw and the device will > cause broadcast (and thus ARP) handling issues. Modern devices will > (re)populate their ARP table if they receive a packet from an unknown > device so they learn quicker and things can kinda limp along but in > reality it is b0rken ;) Yes, but if you take /24 they both are still in the same segment. But I agree it is not ideal. So I added vxlan to my emulator allowing me to insert/retrieve the packets in a /24 segment I have elsewhere. -- www.vanheusden.com From tuhs at tuhs.org Thu May 14 23:22:12 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Thu, 14 May 2026 08:22:12 -0500 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: it's looking for hyphens as previously explained, but here are a couple of notes: int nread 1; should probably be    int nread = 1; static ibuf; should probably be    static char *ibuf;     or     static int *ibuf; These look like bugs, but old c was quirky, so I wouldn't swear by it. Will On 5/13/26 20:57, Thalia Archibald via TUHS wrote: > This mysterious program is in the s1 tape, but has not yet been identified. > Does it look familiar? > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > It looks like it processes line continuations. It filters files to only runs of > lines continued with hyphen with the adjoining whitespace stripped. Only letters > and hyphens are allowed in such lines. > [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* > > But there's bugs, so the grammar is actually the following, where EOF is > included in the negated sets as NUL: > ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* > > Could this be a sort of preprocessor? Perhaps for some sort of a configuration > language? > > It reads the list of named files, printing each filename with "%s:\n \n" before. > The space on an empty line is strange. > > It uses & and | for conditionals and is typed, characteristic of early C and NB. > > It uses this horrid indentation style, which doesn't match ken or dmr. > Do you recognize who? Example: > > while((b[++i] = get(ifile)) != 0) > {if((b[i] >= 'a' & b[i] <= 'z') | > (b[i] >= 'A' & b[i] <= 'Z')) > {c[j++] = b[i]; > goto cont; > } > > I've taken some liberties to simplify it below. I changed it to operate on a > single file. And equivalently, I reformatted it, replaced an unnecessary buffer > with a single char, and simplified control flow. See the above link for the > original. > > char c[60]; > > main(argc, argv) > int argc; > char *argv[]; > { > char b; > int isw, j, k; > > isw = j = 0; > while((b = getchar()) != 0) { > if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= 'Z')) { > c[j++] = b; > continue; > } > if(b == '-') { > c[j++] = b; > if((b = getchar()) != '\n') { > c[j++] = b; > continue; > } > if(j == 1) { > isw = j = 0; > continue; > } > isw = 1; > while(((b = getchar()) == ' ') || (b == '\t') || (b == '\n')) > ; > c[j++] = b; > continue; > } > if(isw == 1) { > k = 0; > c[j++] = '\n'; > while(k < j) > putchar(c[k++]); > } > isw = j = 0; > } > } > > Thalia > > From tuhs at tuhs.org Thu May 14 23:46:30 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 14 May 2026 09:46:30 -0400 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: Will. That was the original B/C syntax. Remember that B, like BLISS has only one data type: word. So pointers are not special. I suspect this is very early C, possibly nB given that it has a char type. Sent from a handheld expect more typos than usual On Thu, May 14, 2026 at 9:22 AM Will Senn via TUHS wrote: > it's looking for hyphens as previously explained, but here are a couple > of notes: > > int nread 1; > > should probably be int nread = 1; > > static ibuf; > > should probably be static char *ibuf; > > or > > static int *ibuf; > > These look like bugs, but old c was quirky, so I wouldn't swear by it. > > Will > > On 5/13/26 20:57, Thalia Archibald via TUHS wrote: > > This mysterious program is in the s1 tape, but has not yet been > identified. > > Does it look familiar? > > > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > > > It looks like it processes line continuations. It filters files to only > runs of > > lines continued with hyphen with the adjoining whitespace stripped. Only > letters > > and hyphens are allowed in such lines. > > [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* > > > > But there's bugs, so the grammar is actually the following, where EOF is > > included in the negated sets as NUL: > > ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* > > > > Could this be a sort of preprocessor? Perhaps for some sort of a > configuration > > language? > > > > It reads the list of named files, printing each filename with "%s:\n \n" > before. > > The space on an empty line is strange. > > > > It uses & and | for conditionals and is typed, characteristic of early C > and NB. > > > > It uses this horrid indentation style, which doesn't match ken or dmr. > > Do you recognize who? Example: > > > > while((b[++i] = get(ifile)) != 0) > > {if((b[i] >= 'a' & b[i] <= 'z') | > > (b[i] >= 'A' & b[i] <= 'Z')) > > {c[j++] = b[i]; > > goto cont; > > } > > > > I've taken some liberties to simplify it below. I changed it to operate > on a > > single file. And equivalently, I reformatted it, replaced an unnecessary > buffer > > with a single char, and simplified control flow. See the above link for > the > > original. > > > > char c[60]; > > > > main(argc, argv) > > int argc; > > char *argv[]; > > { > > char b; > > int isw, j, k; > > > > isw = j = 0; > > while((b = getchar()) != 0) { > > if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= 'Z')) { > > c[j++] = b; > > continue; > > } > > if(b == '-') { > > c[j++] = b; > > if((b = getchar()) != '\n') { > > c[j++] = b; > > continue; > > } > > if(j == 1) { > > isw = j = 0; > > continue; > > } > > isw = 1; > > while(((b = getchar()) == ' ') || (b == '\t') > || (b == '\n')) > > ; > > c[j++] = b; > > continue; > > } > > if(isw == 1) { > > k = 0; > > c[j++] = '\n'; > > while(k < j) > > putchar(c[k++]); > > } > > isw = j = 0; > > } > > } > > > > Thalia > > > > > From tuhs at tuhs.org Fri May 15 00:17:47 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Thu, 14 May 2026 14:17:47 +0000 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: (Will Senn via TUHS's message of "Thu, 14 May 2026 08:22:12 -0500") References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: <7wpl2yhy7o.fsf@junk.nocrew.org> Will Senn wrote: > int nread 1; In old (really old) C, that's how you initialize a variable. I'm particularly aware of this, since Alan Snyder brought this syntax from Bell Labs back to MIT around 1974, and that's how his C compiler for ITS works. From tuhs at tuhs.org Fri May 15 00:27:05 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 14 May 2026 10:27:05 -0400 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: On Thu, May 14, 2026 at 10:24 AM Clem Cole via TUHS wrote: > Will. That was the original B/C syntax. Remember that B, like BLISS has > only one data type: word. So pointers are not special. I suspect this is > very early C, possibly nB given that it has a char type. Also, PL/I used `|` and `&` for boolean operators, as shown in the fragment Thalia initially posted; `II` and `&&` came a bit later. - Dan C. > On Thu, May 14, 2026 at 9:22 AM Will Senn via TUHS wrote: > > > it's looking for hyphens as previously explained, but here are a couple > > of notes: > > > > int nread 1; > > > > should probably be int nread = 1; > > > > static ibuf; > > > > should probably be static char *ibuf; > > > > or > > > > static int *ibuf; > > > > These look like bugs, but old c was quirky, so I wouldn't swear by it. > > > > Will > > > > On 5/13/26 20:57, Thalia Archibald via TUHS wrote: > > > This mysterious program is in the s1 tape, but has not yet been > > identified. > > > Does it look familiar? > > > > > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > > > > > It looks like it processes line continuations. It filters files to only > > runs of > > > lines continued with hyphen with the adjoining whitespace stripped. Only > > letters > > > and hyphens are allowed in such lines. > > > [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* > > > > > > But there's bugs, so the grammar is actually the following, where EOF is > > > included in the negated sets as NUL: > > > ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* > > > > > > Could this be a sort of preprocessor? Perhaps for some sort of a > > configuration > > > language? > > > > > > It reads the list of named files, printing each filename with "%s:\n \n" > > before. > > > The space on an empty line is strange. > > > > > > It uses & and | for conditionals and is typed, characteristic of early C > > and NB. > > > > > > It uses this horrid indentation style, which doesn't match ken or dmr. > > > Do you recognize who? Example: > > > > > > while((b[++i] = get(ifile)) != 0) > > > {if((b[i] >= 'a' & b[i] <= 'z') | > > > (b[i] >= 'A' & b[i] <= 'Z')) > > > {c[j++] = b[i]; > > > goto cont; > > > } > > > > > > I've taken some liberties to simplify it below. I changed it to operate > > on a > > > single file. And equivalently, I reformatted it, replaced an unnecessary > > buffer > > > with a single char, and simplified control flow. See the above link for > > the > > > original. > > > > > > char c[60]; > > > > > > main(argc, argv) > > > int argc; > > > char *argv[]; > > > { > > > char b; > > > int isw, j, k; > > > > > > isw = j = 0; > > > while((b = getchar()) != 0) { > > > if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= 'Z')) { > > > c[j++] = b; > > > continue; > > > } > > > if(b == '-') { > > > c[j++] = b; > > > if((b = getchar()) != '\n') { > > > c[j++] = b; > > > continue; > > > } > > > if(j == 1) { > > > isw = j = 0; > > > continue; > > > } > > > isw = 1; > > > while(((b = getchar()) == ' ') || (b == '\t') > > || (b == '\n')) > > > ; > > > c[j++] = b; > > > continue; > > > } > > > if(isw == 1) { > > > k = 0; > > > c[j++] = '\n'; > > > while(k < j) > > > putchar(c[k++]); > > > } > > > isw = j = 0; > > > } > > > } > > > > > > Thalia > > > > > > > > From tuhs at tuhs.org Fri May 15 01:01:04 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 14 May 2026 11:01:04 -0400 Subject: [TUHS] What is this 1972 C/NB program? Message-ID: Does the hyphen-sniffer perchance come from WWB? Doug From tuhs at tuhs.org Fri May 15 03:46:35 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Thu, 14 May 2026 12:46:35 -0500 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: <8daed909-6f87-4605-a810-29efa517dfac@gmail.com> Ah, duly noted. I read it as old C, but not that old :). Will On 5/14/26 08:46, Clem Cole wrote: > Will. That was the original B/C syntax.  Remember that B, like BLISS > has only one data type: word. So pointers are not special.  I suspect > this is very early C, possibly nB given that it has a char type. > > > Sent from a handheld expect more typos than usual > > On Thu, May 14, 2026 at 9:22 AM Will Senn via TUHS wrote: > > it's looking for hyphens as previously explained, but here are a > couple > of notes: > > int nread 1; > > should probably be    int nread = 1; > > static ibuf; > > should probably be    static char *ibuf; > >      or > >      static int *ibuf; > > These look like bugs, but old c was quirky, so I wouldn't swear by it. > > Will > > On 5/13/26 20:57, Thalia Archibald via TUHS wrote: > > This mysterious program is in the s1 tape, but has not yet been > identified. > > Does it look familiar? > > > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > > > It looks like it processes line continuations. It filters files > to only runs of > > lines continued with hyphen with the adjoining whitespace > stripped. Only letters > > and hyphens are allowed in such lines. > >      [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* > > > > But there's bugs, so the grammar is actually the following, > where EOF is > > included in the negated sets as NUL: > >      ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* > > > > Could this be a sort of preprocessor? Perhaps for some sort of a > configuration > > language? > > > > It reads the list of named files, printing each filename with > "%s:\n \n" before. > > The space on an empty line is strange. > > > > It uses & and | for conditionals and is typed, characteristic of > early C and NB. > > > > It uses this horrid indentation style, which doesn't match ken > or dmr. > > Do you recognize who? Example: > > > > while((b[++i] = get(ifile)) != 0) > >          {if((b[i] >= 'a' & b[i] <= 'z') | > >          (b[i] >= 'A' & b[i] <= 'Z')) > >                  {c[j++] = b[i]; > >                  goto cont; > >                  } > > > > I've taken some liberties to simplify it below. I changed it to > operate on a > > single file. And equivalently, I reformatted it, replaced an > unnecessary buffer > > with a single char, and simplified control flow. See the above > link for the > > original. > > > > char c[60]; > > > > main(argc, argv) > > int argc; > > char *argv[]; > > { > >          char b; > >          int isw, j, k; > > > >          isw = j = 0; > >          while((b = getchar()) != 0) { > >                  if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= > 'Z')) { > >                          c[j++] = b; > >                          continue; > >                  } > >                  if(b == '-') { > >                          c[j++] = b; > >                          if((b = getchar()) != '\n') { > >                                  c[j++] = b; > >                                  continue; > >                          } > >                          if(j == 1) { > >                                  isw = j = 0; > >                                  continue; > >                          } > >                          isw = 1; > >                          while(((b = getchar()) == ' ') || (b == > '\t') || (b == '\n')) > >                                  ; > >                          c[j++] = b; > >                          continue; > >                  } > >                  if(isw == 1) { > >                          k = 0; > >                          c[j++] = '\n'; > >                          while(k < j) > >                                  putchar(c[k++]); > >                  } > >                  isw = j = 0; > >          } > > } > > > > Thalia > > > > > From tuhs at tuhs.org Fri May 15 04:39:51 2026 From: tuhs at tuhs.org (Jim Geist via TUHS) Date: Thu, 14 May 2026 12:39:51 -0600 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: <8daed909-6f87-4605-a810-29efa517dfac@gmail.com> References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> <8daed909-6f87-4605-a810-29efa517dfac@gmail.com> Message-ID: If I remember, it's an anachronism from B, like when the operator assignments where still =+, =-, etc. On Thu, May 14, 2026 at 12:24 PM Will Senn via TUHS wrote: > Ah, duly noted. I read it as old C, but not that old :). > > Will > > On 5/14/26 08:46, Clem Cole wrote: > > Will. That was the original B/C syntax. Remember that B, like BLISS > > has only one data type: word. So pointers are not special. I suspect > > this is very early C, possibly nB given that it has a char type. > > > > > > Sent from a handheld expect more typos than usual > > > > On Thu, May 14, 2026 at 9:22 AM Will Senn via TUHS > wrote: > > > > it's looking for hyphens as previously explained, but here are a > > couple > > of notes: > > > > int nread 1; > > > > should probably be int nread = 1; > > > > static ibuf; > > > > should probably be static char *ibuf; > > > > or > > > > static int *ibuf; > > > > These look like bugs, but old c was quirky, so I wouldn't swear by > it. > > > > Will > > > > On 5/13/26 20:57, Thalia Archibald via TUHS wrote: > > > This mysterious program is in the s1 tape, but has not yet been > > identified. > > > Does it look familiar? > > > > > > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > > > > > It looks like it processes line continuations. It filters files > > to only runs of > > > lines continued with hyphen with the adjoining whitespace > > stripped. Only letters > > > and hyphens are allowed in such lines. > > > [a-zA-Z-]+(-\n[\t\n]*[a-zA-Z-]+)* > > > > > > But there's bugs, so the grammar is actually the following, > > where EOF is > > > included in the negated sets as NUL: > > > ([a-zA-Z]|-[^\n])+(-\n[ \t\n]*[^ \t\n]([a-zA-Z]|-[^\n])*)* > > > > > > Could this be a sort of preprocessor? Perhaps for some sort of a > > configuration > > > language? > > > > > > It reads the list of named files, printing each filename with > > "%s:\n \n" before. > > > The space on an empty line is strange. > > > > > > It uses & and | for conditionals and is typed, characteristic of > > early C and NB. > > > > > > It uses this horrid indentation style, which doesn't match ken > > or dmr. > > > Do you recognize who? Example: > > > > > > while((b[++i] = get(ifile)) != 0) > > > {if((b[i] >= 'a' & b[i] <= 'z') | > > > (b[i] >= 'A' & b[i] <= 'Z')) > > > {c[j++] = b[i]; > > > goto cont; > > > } > > > > > > I've taken some liberties to simplify it below. I changed it to > > operate on a > > > single file. And equivalently, I reformatted it, replaced an > > unnecessary buffer > > > with a single char, and simplified control flow. See the above > > link for the > > > original. > > > > > > char c[60]; > > > > > > main(argc, argv) > > > int argc; > > > char *argv[]; > > > { > > > char b; > > > int isw, j, k; > > > > > > isw = j = 0; > > > while((b = getchar()) != 0) { > > > if((b >= 'a' && b <= 'z') || (b >= 'A' && b <= > > 'Z')) { > > > c[j++] = b; > > > continue; > > > } > > > if(b == '-') { > > > c[j++] = b; > > > if((b = getchar()) != '\n') { > > > c[j++] = b; > > > continue; > > > } > > > if(j == 1) { > > > isw = j = 0; > > > continue; > > > } > > > isw = 1; > > > while(((b = getchar()) == ' ') || (b == > > '\t') || (b == '\n')) > > > ; > > > c[j++] = b; > > > continue; > > > } > > > if(isw == 1) { > > > k = 0; > > > c[j++] = '\n'; > > > while(k < j) > > > putchar(c[k++]); > > > } > > > isw = j = 0; > > > } > > > } > > > > > > Thalia > > > > > > > > From tuhs at tuhs.org Fri May 15 06:30:21 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Thu, 14 May 2026 15:30:21 -0500 Subject: [TUHS] fork In-Reply-To: References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> <7wlddnkizx.fsf@junk.nocrew.org> Message-ID: <20260514203021.xl54uihagcvgt63i@illithid> At 2026-05-13T07:29:15-0400, Dan Cross via TUHS wrote: > Btw, a fun trick to turn a signal into a synchronous event, is what is > sometimes called the, "self-pipe" trick. Here, you create a pipe, set > the write-end of it to be non-blocking, and in your signal handler, > write a byte into the pipe (you make it non-blocking so that you never > block in the signal handler, should the pipe fill up). Then, you can > run `select` (or `poll` or whatever) in your "main loop" and add the > read-end of the pipe to the read-set you're selecting on; when you > receive a signal, that pipe will become readable, you read a byte out > of it, and you can do whatever you would have needed to do to handle > the signal in a normal context. I think Dan Bernstein was the first > person to document the idea. Forgive the Unfrozen Caveman Engineer question, but... How is that method superior to having a `volatile sig_atomic_t` of Boolean sense that gets set in the signal handler and checked in the main program's event loop? I fear I may owe some former junior colleagues an apology... Is Bernstein's method the preferred idiom in Plan 9, which discarded `register`, `const`, _and_ `volatile` from its C compiler? :-O https://plan9.io/sys/doc/comp.html (And yeah, I know you know exactly where that document came to my attention recently. ;-) ) 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 tuhs at tuhs.org Fri May 15 08:32:53 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 14 May 2026 18:32:53 -0400 Subject: [TUHS] fork In-Reply-To: <20260514203021.xl54uihagcvgt63i@illithid> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> <9de657ea744fea9717775d533724933d@vanheusden.com> <7wlddnkizx.fsf@junk.nocrew.org> <20260514203021.xl54uihagcvgt63i@illithid> Message-ID: On Thu, May 14, 2026 at 4:39 PM G. Branden Robinson via TUHS wrote: > At 2026-05-13T07:29:15-0400, Dan Cross via TUHS wrote: > > Btw, a fun trick to turn a signal into a synchronous event, is what is > > sometimes called the, "self-pipe" trick. Here, you create a pipe, set > > the write-end of it to be non-blocking, and in your signal handler, > > write a byte into the pipe (you make it non-blocking so that you never > > block in the signal handler, should the pipe fill up). Then, you can > > run `select` (or `poll` or whatever) in your "main loop" and add the > > read-end of the pipe to the read-set you're selecting on; when you > > receive a signal, that pipe will become readable, you read a byte out > > of it, and you can do whatever you would have needed to do to handle > > the signal in a normal context. I think Dan Bernstein was the first > > person to document the idea. > > Forgive the Unfrozen Caveman Engineer question, but... Not at all! > How is that method superior to having a `volatile sig_atomic_t` of > Boolean sense that gets set in the signal handler and checked in the > main program's event loop? I fear I may owe some former junior > colleagues an apology... To be clear, you _can_ do that. But the programmer may find it unsatisfactory in several ways. First, there's the matter of where one checks it, and when. Allow me to explain by illustration. One might imagine code like this (untested, excuse errors, for instructional purposes only, etc): | volatile sig_atomic_t intr = 0; | void handler(int ignored_signo) { intr = 1; } | int main(void) { | signal(SIGWHATEVER, handler); | for (;;) { | // Set up all the inputs to `select` here.... | if (intr!=0) { intr = 0; /* Handle the signal... */ } | int err = select(nfds, rfds, wfds, NULL, NULL); | if (err==-1&&errno==EINTR) continue; | /* If we get here, there was no signal. */ | } | return 0; | } (This is a little more compact that I would ordinarily write it, but I'm going trying to conserve space; hopefully gmail doesn't strip out all the whitespace. :-/) This may look ok: we test for whether a signal occurred before the `select`, and handle if it so. And if the signal is delivered while we're in `select`, that's ok: the system call will be interrupted by its delivery, we'll see that reflected in the combination of `signal`'s return value and the value of `errno`, and we'll go back to the top of the loop and repeat the check. But there's a race: suppose that a signal is delivered immediately _after_ checking `intr!=0` but _before_ entry to `select`. The kernel would arrange an upcall to run `handler`, and then resume the program's normal flow of execution after. The program would then invoke `select`, where we'd block; we wouldn't check `intr` until the next iteration of the loop, which may be delayed indefinitely, if nothing happens that makes `select` return. One may wonder if this is likely; after all, signals are only delivered via a round trip through the kernel; but the system might take an interrupt right after the comparison instruction, but before the branch to to the `select` call, trapping us on that journey. One might, perhaps, render this harmless by supplying a timeout to the `select` (or `poll` or other equivalent) call and check the `intr` flag again whenever `select` returns, whether due an event, interruption, or timeout. That works, but how do you choose the timeout? Too short, and we're burning CPU needlessly; too long, and we may have unacceptable latency dealing with the signal. It's worth noting here that POSIX added `pselect`, which takes a pointer to a signal mask, and (if that is non-null) atomically replaces the caller's mask with the one given for the duration of the call. So you _can_ solve this by blocking signal delivery, checking the flag, and then `pselect`ing with a mask that re-enables that signal; if `pselect` is interrupted, just go back to the check. That avoids the race condition: a signal sent between the check and before the `pselect` will be held pending by the kernel until it's unmasked, then delivered: that is, it will interrupt the `pselect`, so you end up with code that looks much like the above. But there's another complication this does not handle, this time with multithreading. In a multithreaded POSIX program (already quite common, but only becoming more so), you don't necessarily know what thread a signal sent _to a process_ will be delivered on (`pthread_signal` can be used to send a signal to a specific thread, of course, but many things that generate signals don't use `pthread_signal`). So a signal may not be delivered to the thread that is running the event loop. So how do you know when to check? The issue there, again, is latency: if that thread is blocked inside of `select` or equivalent, it won't see the flag set by the signal handler until the next time it comes out of the kernel, which may be arbitrarily far in the future. Timeouts just come back to the duration selection problem mentioned before. The self-pipe trick solves all of these issues, because it composes naturally with `select` (or `poll`, etc): one simply adds the read-end of the pipe to the read FD set. If `select` returns with `EINTR` due to delivery of a signal of interest, you simply re-start it, and it returns immediately since there will be data available on the read-end of the pipe, put there by the signal handler. If the signal is delivered and handled on another thread, you'll still get a timely notification, because it will unblock the `select` in the main loop. You don't need a timeout to ensure bounded time for dealing with the signal (though you may want one for other reasons). > Is Bernstein's method the preferred idiom in Plan 9, which discarded > `register`, `const`, _and_ `volatile` from its C compiler? :-O I sense jest...but seriously, no, I don't think so. Plan 9 doesn't have signals, it has notes; you don't send a signal identified by a number to a process, but rather you issue a `write` the file, `/proc//note`. That's delivered to the process via an upcall, much like a Unix signal, but the argument is a pointer to the contents of the `write` (which is guaranteed to be nul-terminated). The process _has_ to terminate the note handler by invoking the `noted` system call (or exiting). Plan 9 also doesn't have `select`, but it does have `rfork`, which lets programs create multiple processes sharing (almost) the same address space. Multithreaded programs usually synchronize via shared memory, and can kill each other if they detect some kind of exceptional event. Generally, notes are not as heavily used on Plan 9 as signals are on Unix/Linux and friends; they're more for killing a program or kicking it into the `Stopped` state for a debugger, and much less as an _ad hoc_ IPC mechanism for signaling random events. I'm unaware of anyone doing anything like the self-pipe trick on Plan 9, though there's no reason you couldn't if you wanted to. But perhaps Rob or someone else will chime in if with examples, if there are any. > https://plan9.io/sys/doc/comp.html > > (And yeah, I know you know exactly where that document came to my > attention recently. ;-) ) :-D (For those unaware, Branden has done work recently normalizing behavior across the various strains of `troff`, including the ones from Plan 9 and Plan9 from Userspace.) - Dan C. From tuhs at tuhs.org Fri May 15 10:39:45 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 15 May 2026 10:39:45 +1000 Subject: [TUHS] What is this 1972 C/NB program? In-Reply-To: References: <34C08115-0D38-4979-98F5-2E2D892A89E4@archibald.dev> Message-ID: On Thu, May 14, 2026 at 01:35:19PM +1000, Jonathan Gray via TUHS wrote: > On Thu, May 14, 2026 at 01:57:27AM +0000, Thalia Archibald via TUHS wrote: > > This mysterious program is in the s1 tape, but has not yet been identified. > > Does it look familiar? > > https://github.com/DoctorWkt/unix-jun72/blob/master/src/cmd/unknown.c > > very close to > https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd2/hyphen.c > > described in the Program Generic PG-1C300 issue 2 manual on bitsavers: > > hyphen(VI) find hyphenated words a longer list of manual pages: Third Edition, hyphen(I) Fourth Edition, hyphen(VI) Fifth Edition, hyphen(VI) Program Generic PG-1C300 Issue 2, hyphen(VI) Program Generic PG-1C300 Issue 3, hyphen(VI) MERT Release 0, hyphen(VI) CB-UNIX 2.3, hyphen(1) System III, hyphen(1) System V Release 1, hyphen(1) System V Release 2, hyphen(1) Documenter's Workbench Release 2.0, hyphen(1) From tuhs at tuhs.org Sun May 17 21:17:51 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Sun, 17 May 2026 13:17:51 +0200 Subject: [TUHS] time on bsd 2.11 on a pdp11 Message-ID: <5553faf353c84499efaefa2a1c928759@vanheusden.com> Hello, I wonder: how is time-keeping done in bsd2.11 on a pdp11? Am I right that it depends on the kw11-l line interrupt (50 or 60 Hz) or is there an other timer that I missed? regards -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com From tuhs at tuhs.org Mon May 18 03:58:33 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Sun, 17 May 2026 13:58:33 -0400 Subject: [TUHS] Fwd: [multicians] Peter Neumann has died In-Reply-To: References: Message-ID: Tom van Vleck just passed the below forwarded message on the Multics mailing list. Very sad news. - Dan C. ---------- Forwarded message --------- From: Tom Van Vleck via groups.io Date: Sun, May 17, 2026, 1:27 PM Subject: [multicians] Peter Neumann has died To: Robert Watson wrote me Unfortunately, I email with the heartbreaking news that Peter Neumann passed away in his sleep last night, at the hospital in Santa Clara, due to complications arising from his fall and subsequent surgery a few weeks ago. His daughter Hellie was with him at the hospital at the time, and they had been listening to classical music together — as you may know, music was another of his great loves in life beyond computer security, with Peter an accomplished player of the piano, French horn, and various other instruments. Hellie has asked me to reach out to his friends and colleagues with this news — it’s still early in the morning in California and I will send on more information in due course, but it is currently believed that SRI will host a memorial service for him in Menlo Park in a month or so. https://www.csl.sri.com/~neumann/ is Peter's SRI home page. He was a wonderful friend and colleague. _._,_._,_ ------------------------------ Groups.io Links: You receive all messages sent to this group. View/Reply Online (#5960) | Reply to Group | Reply to Sender | Mute This Topic | New Topic ------------------------------ -- sent via multicians at groups.io -- more Multics info at https://multicians.org/ ------------------------------ Your Subscription | Contact Group Owner | Unsubscribe [ crossd at gmail.com] _._,_._,_ From tuhs at tuhs.org Mon May 18 06:01:40 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 17 May 2026 16:01:40 -0400 Subject: [TUHS] time on bsd 2.11 on a pdp11 In-Reply-To: <5553faf353c84499efaefa2a1c928759@vanheusden.com> References: <5553faf353c84499efaefa2a1c928759@vanheusden.com> Message-ID: Yes, it uses the KW11 Sent from a handheld expect more typos than usual On Sun, May 17, 2026 at 7:18 AM Folkert van Heusden via TUHS wrote: > Hello, > > I wonder: how is time-keeping done in bsd2.11 on a pdp11? Am I right > that it depends on the kw11-l line interrupt (50 or 60 Hz) or is there > an other timer that I missed? > > regards > > -- > www.vanheusden.com [1] > > Links: > ------ > [1] http://www.vanheusden.com > From tuhs at tuhs.org Tue May 19 10:20:01 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 18 May 2026 20:20:01 -0400 Subject: [TUHS] RIP Peter Salus Message-ID: I just found out that Peter Salus passed away on May 15. His "Quarter Century of Unix" is required reading for any serious student of Unix history. - Dan C. From tuhs at tuhs.org Tue May 19 10:38:41 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Mon, 18 May 2026 17:38:41 -0700 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: Message-ID: RIP. Did he ever interact with this community? On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS wrote: > > I just found out that Peter Salus passed away on May 15. His "Quarter > Century of Unix" is required reading for any serious student of Unix > history. > > - Dan C. From tuhs at tuhs.org Tue May 19 11:07:45 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 19 May 2026 01:07:45 +0000 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: Message-ID: <6GCEx8BTEv-o1w0wRBcgP7mu7r5jgunBLBDj6FeMjrW-RmyINnPzEjua5KNBlzF19nJoplnuo57cpV8ZpI4yaKomIowaDu0Oc4y0g3JtFDg=@archibald.dev> A tragic loss. That's a fantastic book Thalia On Monday, May 18th, 2026 at 18:21, Dan Cross wrote: > I just found out that Peter Salus passed away on May 15. His "Quarter > Century of Unix" is required reading for any serious student of Unix > history. > > - Dan C. From tuhs at tuhs.org Tue May 19 11:30:46 2026 From: tuhs at tuhs.org (Mark Seiden via TUHS) Date: Mon, 18 May 2026 18:30:46 -0700 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: Message-ID: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> depends what you mean by “this” and “interact”. he has mostly been retired after many years if you look at this: https://en.wikipedia.org/wiki/Peter_H._Salus you will discover that peter was not just an eminent linguist (by training, vocation and scholarship) but was also executive director of usenix assn for many years, so responsibile for a lot of community building. i first met peter in 1971, when we shared a group house in santa cruz at a summer linguistics institute, and cooked up numerous complicated group meals. he was a joyful connector and a delight to hang out with. and full of stories, which is why he wrote several books about the history of unix and the early history of the internet. (he was there and knew everybody, so the books are authoritative…) at some point peter registered the domain name pedant.com. he had (and touted) an encyclopedic knowledge of facts both useless and useful, so he fit that descriptor. also a sense of humor that was abundant (and sometimes, as linguists sometimes do, overstep the comfortable boundaries of ordinary civilians accustomed to using language more conventionally.) peter was a longtime friend of lou katz (since the 1960s), who told me a couple weeks ago that peter was in hospice, cheerful, but suffering from congestive heart failure. (i cc lou on this). (peter was predeceased by his wife, mary salus.) peter and mary’s daughter emily is at https://www.linkedin.com/in/ewsalus/ and i believe her current email address is emily at openprisetech.com. (personally very sad to lose both peter neumann and peter salus during the same week, two mentors, men of infinite jest, and there will never be anyone like them again.) > On May 18, 2026, at 5:38 PM, Kevin Bowling via TUHS wrote: > > RIP. Did he ever interact with this community? > > On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS wrote: >> >> I just found out that Peter Salus passed away on May 15. His "Quarter >> Century of Unix" is required reading for any serious student of Unix >> history. >> >> - Dan C. From tuhs at tuhs.org Tue May 19 13:13:18 2026 From: tuhs at tuhs.org (Mark Seiden via TUHS) Date: Mon, 18 May 2026 20:13:18 -0700 Subject: [TUHS] RIP Peter Salus In-Reply-To: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> References: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> Message-ID: i must correct an error in what’s below (though not particularly relevant except for Lou or others who know the family: emily salus (which i have now twice typed as “emaily”, sigh) tells me mary salus is still suffering from two ailments that have her in a memory unit since the time when peter went into the hospital in march. > On May 18, 2026, at 6:30 PM, Mark Seiden wrote: > > depends what you mean by “this” and “interact”. > he has mostly been retired after many years > > if you look at this: > https://en.wikipedia.org/wiki/Peter_H._Salus > you will discover that peter was not just an eminent linguist (by training, vocation and scholarship) > but was also executive director of usenix assn for many years, so responsibile for a lot > of community building. > > i first met peter in 1971, when we shared a group house in santa cruz at a summer linguistics institute, and cooked > up numerous complicated group meals. he was a joyful connector and a delight to hang out with. > > and full of stories, which is why he wrote several books about the history of unix and the early history of the internet. > (he was there and knew everybody, so the books are authoritative…) > > at some point peter registered the domain name pedant.com. he had (and touted) an encyclopedic knowledge of > facts both useless and useful, so he fit that descriptor. also a sense of humor that was abundant (and sometimes, as linguists > sometimes do, overstep the comfortable boundaries of ordinary civilians accustomed to using language more conventionally.) > > peter was a longtime friend of lou katz (since the 1960s), who told me a couple weeks ago that peter was in hospice, > cheerful, but suffering from congestive heart failure. (i cc lou on this). > > (peter was predeceased by his wife, mary salus.) > > peter and mary’s daughter emily is at > https://www.linkedin.com/in/ewsalus/ > and i believe her current email address is emily at openprisetech.com. > > (personally very sad to lose both peter neumann and peter salus during the same week, two mentors, men of infinite jest, and there > will never be anyone like them again.) > >> On May 18, 2026, at 5:38 PM, Kevin Bowling via TUHS wrote: >> >> RIP. Did he ever interact with this community? >> >> On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS wrote: >>> >>> I just found out that Peter Salus passed away on May 15. His "Quarter >>> Century of Unix" is required reading for any serious student of Unix >>> history. >>> >>> - Dan C. > From tuhs at tuhs.org Tue May 19 14:04:42 2026 From: tuhs at tuhs.org (Charles H. Sauer via TUHS) Date: Mon, 18 May 2026 23:04:42 -0500 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> Message-ID: Beyond “Quarter Century” and USENIX, two non-TUHS notes about Peter 1. Peter wrote Casting the net: from ARPANET to Internet and beyond (https://archive.org/details/castingnetfromar0000salu) 2. Peter was extraodinarily helpful to me and Joe Duran with our Mainstream Videoconferencing book (https://notes.technologists.com/notes/2008/02/14/mainstream-videoconferencing-available-again/), helping get us the contract with Addison-Wesley, assisting with editing of the work in progress, posting very nice reviews, … Charlie > On May 18, 2026, at 10:13 PM, Mark Seiden via TUHS wrote: > > i must correct an error in what’s below (though not particularly relevant > except for Lou or others who know the family: > > emily salus (which i have now twice typed as “emaily”, sigh) tells me > mary salus is still suffering from two ailments that have > her in a memory unit since the time when peter went into the > hospital in march. > >> On May 18, 2026, at 6:30 PM, Mark Seiden wrote: >> >> depends what you mean by “this” and “interact”. >> he has mostly been retired after many years >> >> if you look at this: >> https://en.wikipedia.org/wiki/Peter_H._Salus >> you will discover that peter was not just an eminent linguist (by training, vocation and scholarship) >> but was also executive director of usenix assn for many years, so responsibile for a lot >> of community building. >> >> i first met peter in 1971, when we shared a group house in santa cruz at a summer linguistics institute, and cooked >> up numerous complicated group meals. he was a joyful connector and a delight to hang out with. >> >> and full of stories, which is why he wrote several books about the history of unix and the early history of the internet. >> (he was there and knew everybody, so the books are authoritative…) >> >> at some point peter registered the domain name pedant.com. he had (and touted) an encyclopedic knowledge of >> facts both useless and useful, so he fit that descriptor. also a sense of humor that was abundant (and sometimes, as linguists >> sometimes do, overstep the comfortable boundaries of ordinary civilians accustomed to using language more conventionally.) >> >> peter was a longtime friend of lou katz (since the 1960s), who told me a couple weeks ago that peter was in hospice, >> cheerful, but suffering from congestive heart failure. (i cc lou on this). >> >> (peter was predeceased by his wife, mary salus.) >> >> peter and mary’s daughter emily is at >> https://www.linkedin.com/in/ewsalus/ >> and i believe her current email address is emily at openprisetech.com. >> >> (personally very sad to lose both peter neumann and peter salus during the same week, two mentors, men of infinite jest, and there >> will never be anyone like them again.) >> >>> On May 18, 2026, at 5:38 PM, Kevin Bowling via TUHS wrote: >>> >>> RIP. Did he ever interact with this community? >>> >>> On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS wrote: >>>> >>>> I just found out that Peter Salus passed away on May 15. His "Quarter >>>> Century of Unix" is required reading for any serious student of Unix >>>> history. >>>> >>>> - Dan C. >> > -- 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 Tue May 19 21:49:07 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Tue, 19 May 2026 07:49:07 -0400 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> Message-ID: Peter was Executive Director of USENIX for a number of years. I think Lou Katz was on the USENIX board at the time and recommended him. Peter was a marvelous cook. He'd call me up on the phone and invite me over to eat "dog food", by which he meant organ meats. Some years ago he asked me to teach his daughter Emily calculus. I said, "But you know calculus. Why don't you teach her?" He replied, "Yes, but when I try to teach her, we fight." It was an interesting experience because I could write down the answers to her homework by inspection, but I had to delve into her text to remind myself how to explain it. I relearned the basic underpinnings. I think she got an A. Marc ===== mindthegapdialogs.com north-fork.info On Tue, May 19, 2026 at 12:05 AM Charles H. Sauer via TUHS wrote: > Beyond “Quarter Century” and USENIX, two non-TUHS notes about Peter > 1. Peter wrote Casting the net: from ARPANET to Internet and beyond ( > https://archive.org/details/castingnetfromar0000salu) > 2. Peter was extraodinarily helpful to me and Joe Duran with our > Mainstream Videoconferencing book ( > https://notes.technologists.com/notes/2008/02/14/mainstream-videoconferencing-available-again/), > helping get us the contract with Addison-Wesley, assisting with editing of > the work in progress, posting very nice reviews, … > > Charlie > > > On May 18, 2026, at 10:13 PM, Mark Seiden via TUHS > wrote: > > > > i must correct an error in what’s below (though not particularly > relevant > > except for Lou or others who know the family: > > > > emily salus (which i have now twice typed as “emaily”, sigh) tells me > > mary salus is still suffering from two ailments that have > > her in a memory unit since the time when peter went into the > > hospital in march. > > > >> On May 18, 2026, at 6:30 PM, Mark Seiden wrote: > >> > >> depends what you mean by “this” and “interact”. > >> he has mostly been retired after many years > >> > >> if you look at this: > >> https://en.wikipedia.org/wiki/Peter_H._Salus > >> you will discover that peter was not just an eminent linguist (by > training, vocation and scholarship) > >> but was also executive director of usenix assn for many years, so > responsibile for a lot > >> of community building. > >> > >> i first met peter in 1971, when we shared a group house in santa cruz > at a summer linguistics institute, and cooked > >> up numerous complicated group meals. he was a joyful connector and a > delight to hang out with. > >> > >> and full of stories, which is why he wrote several books about the > history of unix and the early history of the internet. > >> (he was there and knew everybody, so the books are authoritative…) > >> > >> at some point peter registered the domain name pedant.com. he had > (and touted) an encyclopedic knowledge of > >> facts both useless and useful, so he fit that descriptor. also a sense > of humor that was abundant (and sometimes, as linguists > >> sometimes do, overstep the comfortable boundaries of ordinary civilians > accustomed to using language more conventionally.) > >> > >> peter was a longtime friend of lou katz (since the 1960s), who told me > a couple weeks ago that peter was in hospice, > >> cheerful, but suffering from congestive heart failure. (i cc lou on > this). > >> > >> (peter was predeceased by his wife, mary salus.) > >> > >> peter and mary’s daughter emily is at > >> https://www.linkedin.com/in/ewsalus/ > >> and i believe her current email address is emily at openprisetech.com. > >> > >> (personally very sad to lose both peter neumann and peter salus during > the same week, two mentors, men of infinite jest, and there > >> will never be anyone like them again.) > >> > >>> On May 18, 2026, at 5:38 PM, Kevin Bowling via TUHS > wrote: > >>> > >>> RIP. Did he ever interact with this community? > >>> > >>> On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS > wrote: > >>>> > >>>> I just found out that Peter Salus passed away on May 15. His "Quarter > >>>> Century of Unix" is required reading for any serious student of Unix > >>>> history. > >>>> > >>>> - Dan C. > >> > > > > -- > 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 Tue May 19 22:59:15 2026 From: tuhs at tuhs.org (William Cheswick via TUHS) Date: Tue, 19 May 2026 08:59:15 -0400 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> Message-ID: Some parents find this to be a problem when teaching driving to their kids. For me, the actual useful answer to “why am I taking calculus” was because I could teach integration by parts to my daughter 16 years later. You use doc Harrison’s “chinese poem number one”. I plan to fly out and attend PGN’s memorial if I can. ches > On May 19, 2026, at 7:49 AM, Marc Donner via TUHS wrote: > > He replied, "Yes, but > when I try to teach her, we fight." From tuhs at tuhs.org Wed May 20 03:12:12 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 19 May 2026 17:12:12 +0000 Subject: [TUHS] Acquired 4 Binders of early 80s ESS/SCCS UNIX Manuals Message-ID: Another exciting find, in the mail currently but will hit my scanner when it arrives. Managed to land 4 binders from the early 80s that appear to contain Pidents and various other OSDD documents pertaining to the No. 2 Switching Control Center System and ESS-related UNIX (and possibly ESS-CC sources) listings. The pictures were brief but I saw PG- and PR- series documents and source listings. Anywho, will update when I know what all is contained therein but the SCCS (switching control, not source control) bits represent the forerunner of CB-UNIX and look awfully similar to comparable USG Program Generic listing documents (which in turn resemble other switching stored program control documents from AT&T). With any luck this'll help settle the deltas a bit between USG, SCCS, AND CB UNIX branches. The current understanding is SCCS became CB-UNIX, but given these SCCS-specific documents as of the early 80s I'm now curious if both survived in their own parallel streams quite a bit longer. More to come! I'll reply to this thread with more info when the stack of binders arrives. - Matt G. From tuhs at tuhs.org Wed May 20 09:04:15 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 19 May 2026 17:04:15 -0600 Subject: [TUHS] RIP Peter Salus In-Reply-To: References: Message-ID: <202605192304.64JN4Gnv070349@freefriends.org> Dan Cross via TUHS wrote: > I just found out that Peter Salus passed away on May 15. His "Quarter > Century of Unix" is required reading for any serious student of Unix > history. > > - Dan C. That's sad. I met him a few times at USENIX conferences and enjoyed talking with him. Arnold From tuhs at tuhs.org Wed May 20 15:39:37 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 20 May 2026 05:39:37 +0000 Subject: [TUHS] Curly braces: An evolution of UNIX and C Message-ID: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> I was asked today whether the Teletype Model 33 was really used for C development, because it lacks the curly braces required, and wrote a post about it. https://thalia.dev/blog/unix-braces/ Since I've been digging into artifacts in Dennis_Tapes from when NB was evolving into C, this turned into a history of C with close attention to that critical period. I cover B and BCPL's %( %) syntax, the kernel's \( \) handling for teletypes, C89 ??< ??>, and C95 <% %>, and show an evolution of "hello, world" as a case study. It has many citation and much source analysis, and I think the dates are pretty solid. The real answer is that braces just weren't used in the PDP-7 era, with BCPL syntax used for B. Then, early in UNIX V1 development, the Teletype Model 37 became popular, which supported the whole ASCII character set, so B and C programs could be written with braces. Thalia From tuhs at tuhs.org Wed May 20 20:17:30 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 20 May 2026 10:17:30 +0000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: Hi Thalia, Many thanks for sharing your post, I found it a super interesting read. It should maybe carry a warning, about the potential rabbit holes it contains. I've already fallen down the ASCII one! I especially enjoyed the Appendix: hello, world, showing the evolution of the syntax from BCPL through to modern C. Thank you, Cameron -------- Original Message -------- On Wednesday, 05/20/26 at 06:40 Thalia Archibald via TUHS wrote, in part: I was asked today whether the Teletype Model 33 was really used for C development, because it lacks the curly braces required, and wrote a post about it. https://thalia.dev/blog/unix-braces/ From tuhs at tuhs.org Thu May 21 02:07:34 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Wed, 20 May 2026 12:07:34 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: Thalia — this is outstanding work. Beautifully structured, meticulously cited, and written with the clarity of someone who has actually read the code. Well done. -- Briam R. On 5/20/26 1:39 AM, Thalia Archibald via TUHS wrote: > I was asked today whether the Teletype Model 33 was really used for C > development, because it lacks the curly braces required, and wrote a post about > it. > https://thalia.dev/blog/unix-braces/ > > Since I've been digging into artifacts in Dennis_Tapes from when NB was evolving > into C, this turned into a history of C with close attention to that critical > period. I cover B and BCPL's %( %) syntax, the kernel's \( \) handling for > teletypes, C89 ??< ??>, and C95 <% %>, and show an evolution of "hello, world" > as a case study. It has many citation and much source analysis, and I think the > dates are pretty solid. > > The real answer is that braces just weren't used in the PDP-7 era, with BCPL > syntax used for B. Then, early in UNIX V1 development, the Teletype Model 37 > became popular, which supported the whole ASCII character set, so B and C > programs could be written with braces. > > Thalia From tuhs at tuhs.org Thu May 21 04:16:52 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 20 May 2026 18:16:52 +0000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: On Wednesday, May 20th, 2026 at 03:12, sjenkin wrote: > Thalia, > You've knocked it out of the park, again! > > You posed a question I'd not even thought of.  > [once used an ASR-33 on a Nova, then years using Telex in 1980's - same m/c ]. > > read your piece, excellent. > > It took me ages to track down DMR's (?) list of tty's he'd used, > only to find it was you that posted the note to TUHS. > > That list might belong in the current article, as it provides some context. > > Was it Dennis who wrote that list, because it doesn't include the ASR-33 attached to the PDP-7. > > all my best > steve j > > ============== > > Teletypes used for early Unix > 21 Jul 2025 > > > DMR's list of terminals > That's Dennis' list of personal terminals at home. I'd then consider the 1970 date for the Teletype Model 37 an approximate upper bound for when they started using the Model 37 at work. Dereferencing to the post in alt.folklore.computers, this could yield an even more precise date: > It is true that word-processing and formatting (using Teletype model 37s) for > the Bell Labs patent group was the first productive application of Unix > outside our immediate group. I had actually forgotten about that list. At the time I posted, I was looking for the specific sub-model number of the Model 37s they were using, so it didn't quite answer what I wanted. I already knew they were using the Model 37 and the 1970 date didn't help for that project. But it is useful for this post. The sub-model configuration can be somewhat inferred through artifact analysis: > - Two-color was optional I don't recall seeing indication of red color use. I'll have to look further. > - The shift-out character set was configurable UNIX has Greek SO/SI character tables and Dennis_Tapes has a directory named J for pi. > - An ASR could come without a tape reader/puncher I don't know what I meant by this; that's just a KSR. I'd think I'd've known that, but perhaps I'm referring to something else. > - Half-line forward and reverse was optional > - Character sizes varied, e.g., 72 chars per line at 10 chars per inch, > adjustable up to 80 per line; or 86 per line at 12 per inch They used half-forward and -reverse line feeds for sub- and superscripts in the UNIX "V0" mid-1971 manual that was printed by a 37. This document has 65 characters per line, though probably with artificial margins. I could determine the character size by measuring it. > - The paper could be roll paper (friction feed)or flat-folded, form-feed paper > with marginal perforations (sprocket feed) At VCF 2025, Brian Kernighan said they used fan fold, and sprocket feed was more common, in my experience. > - Paper sizes varied, e.g., 3 to 8-1/2 wide or, for sprocket feed, up to 11 > inches long and 9-1/2 wide My Model 43s use 12" wide x 8x5" long paper. It's landscape 8x5"x11", but with 0.5" sprocket perforations. Perhaps that what the 11" means, but I'm sure my sources would make it clear. I would expect they'd've used the widest option. But the mid-1971 manual is regular letter sheets, not continuous or perforated. The perforated edges could have been removed and they could be cut apart. Given that the patent group was using the 37, presumably also for letter or legal output, I think it's reasonable to say this still used a 37, since it uses somewhat exotic features of that model (half-forward and -reverse). > - Some printed control characters; most didn’t I doubt they had a character set for printed control characters. We'd think of control characters differently now, if they were routinely printed. > - Holding a key could be configured to repeat the character No idea. This one couldn't be determined through source analysis. Probably only a niche case like a game requiring character repetition for some control. I figure they used the default set of repeating characters. It's a strange set of characters: space, NEW LINE, BACKSPACE, NULL, DELETE, period ., hyphen - or equals =, underscore _, colon : or asterisk *, upper case X or lower case x https://github.com/thaliaarchi/tty37-docs/blob/main/tty37.md#character-repeat-feature > - They could operate half-duplex (transmitted data is copied by the sender) or > full-duplex (only received data is copied) UNIX was half-duplex so passwords weren't echoed. > - They could receive and transmit at various speeds They probably used the default of 150 baud. Additionally: They used 8-space tabs. I don't know of vertical tab usage, but sources may indicate. Thalia From tuhs at tuhs.org Thu May 21 04:27:44 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 20 May 2026 18:27:44 +0000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: On Wednesday, May 20th, 2026 at 11:37, Phil Budne wrote: > For my two fractional monetary units (the US no longer mints > new cent pieces): > > The trigraphs and later digraphs are a footnote, and don't deserve to > be featured/discussed up at the top. Of course. But this is all footnotes. > I think historical BCPL, using $( and $) is the place to start, moving > on to PDP-7 B. > > In fact, I think I'd find a strictly chronological presentation (early > structs before UNIX 4th edition terminal driver) would be clearest. I presented it working backwards from our modern assumptions. It's related periods progressing forwards, then jumping back to the next period. The B to NB to C section really needed to be forwards. I wrote this piece fairly linearly in one (long) sitting and it follows my research direction. I agree that it would be better chronological. > ISTR the UNIX terminal driver also allowed entering displaying both > upper and lower case via escaping, tho the "upper case" versions of > the (curly) braces are the (square) brackets. I should have added it, but I decided against it, since UNIX style was to use lowercase and I didn't want to change it to "Hello, world!". It would work with the ed session. > In the B section, instead of > > The 1973 B language tutorial for the H6070 had the first-ever “hello, world” program > > I'd say that it was the first known/documented example of hello world. > > https://research.swtch.com/b-lang > From 2008 says > > Brian Kernighan's 1973 B tutorial contains what is probably the very first “hello, world” program. > > which makes the same conclustion but hedges whether it was in fact THE FIRST. Good point. Thalia From tuhs at tuhs.org Thu May 21 07:25:57 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 17:25:57 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: below, I sent this comment to Thalia privately, but since Phill brought it up I'll bring it here too: On Wed, May 20, 2026 at 2:27 PM Thalia Archibald via TUHS wrote: > > I should have added it, but I decided against it, since UNIX style was to > use > lowercase and I didn't want to change it to "Hello, world!". It would work > with > the ed session. > > > In the B section, instead of > > > The 1973 B language tutorial for the H6070 had the first-ever “hello, > world” program > > > > I'd say that it was the first known/documented example of hello world. > > > > https://research.swtch.com/b-lang > > From 2008 says > > > Brian Kernighan's 1973 B tutorial contains what is probably the very > first “hello, world” program. > > > > which makes the same conclustion but hedges whether it was in fact THE > FIRST. > > Good point. > The "hello world" idea is from Martin Richards early BCPL documentation/papers, which preceded bwk's tutorial. That said, Brian says he didn't read any of them, but they're also there in Richard's later BCPL book, which was made by taking documents that Martin or his collaborators had written earlier. But as the great Tom Lehrer noted in his song: "Lobachevsky" — *"My name in Dnepropetrovsk is cursed, When he finds out I publish first."* From tuhs at tuhs.org Thu May 21 07:53:03 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 20 May 2026 14:53:03 -0700 Subject: [TUHS] Fwd: [multicians] Peter Neumann has died In-Reply-To: References: Message-ID: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> Some published obituaries/memorials: https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ https://www.nytimes.com/2026/05/17/technology/peter-g-neumann-dead.html https://www.sri.com/press/story/peter-neumann-saw-the-internets-dangers-before-the-internet-existed/ From tuhs at tuhs.org Thu May 21 08:04:14 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 20 May 2026 18:04:14 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: <20260520220415.A3F9310BCF054@ary.qy> It appears that Thalia Archibald via TUHS said: >I was asked today whether the Teletype Model 33 was really used for C >development, because it lacks the curly braces required, and wrote a post about >it. > https://thalia.dev/blog/unix-braces/ Nice post but I can tell you from experience that Model 37 Teletypes were quite rare outside the Bell companies. I think I saw one once. Other than that we all used the Model 33 because it was cheap and reliable and we typed \( \) and dealt with it. R's, John From tuhs at tuhs.org Thu May 21 08:10:05 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 18:10:05 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <02FB19C4-4C36-4548-8AC4-396F74C5F753@serissa.com> References: <02FB19C4-4C36-4548-8AC4-396F74C5F753@serissa.com> Message-ID: Brian writing it for the early BCPL docs makes so much sense. As mentioned, it appears in the BCPL "line printer" style docs before B exists. On Wed, May 20, 2026 at 5:44 PM Serissa wrote: > According to this post on Stack Overflow by Chuck Herbert, he corresponded > with both Martin Richards and BWK and found that BWK wrote Hello World for > the IO section of the BCPL doc. > > [image: apple-touch-icon at 2.png] > > Where does 'Hello world' come from? > > stackoverflow.com > > > > > > On May 20, 2026, at 5:26 PM, Clem Cole via TUHS wrote: > > below, I sent this comment to Thalia privately, but since Phill brought > it > up I'll bring it here too: > > On Wed, May 20, 2026 at 2:27 PM Thalia Archibald via TUHS > wrote: > > > I should have added it, but I decided against it, since UNIX style was to > > use > > lowercase and I didn't want to change it to "Hello, world!". It would work > > with > > the ed session. > > > In the B section, instead of > > The 1973 B language tutorial for the H6070 had the first-ever “hello, > > world” program > > > I'd say that it was the first known/documented example of hello world. > > > https://research.swtch.com/b-lang > > From 2008 says > > Brian Kernighan's 1973 B tutorial contains what is probably the very > > first “hello, world” program. > > > which makes the same conclustion but hedges whether it was in fact THE > > FIRST. > > > Good point. > > > The "hello world" idea is from Martin Richards early BCPL > documentation/papers, which preceded bwk's tutorial. That said, Brian > says he didn't read any of them, but they're also there in Richard's later > BCPL book, which was made by taking documents that Martin or his > collaborators had written earlier. But as the great Tom Lehrer noted in > his song: "Lobachevsky" — *"My name in Dnepropetrovsk is cursed, When he > finds out I publish first."* > > From tuhs at tuhs.org Thu May 21 08:29:40 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 18:29:40 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <20260520220415.A3F9310BCF054@ary.qy> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> Message-ID: below On Wed, May 20, 2026 at 6:04 PM John Levine via TUHS wrote: > Nice post but I can tell you from experience that Model 37 Teletypes were > quite > rare outside the Bell companies. Definitely true > I think I saw one once. I did see them in some places. Microsoft's 11/70 (Miss Piggy) had one as its console (I suspect it still does, I have to ask Stephen Jones as he has the system at the ICM). > Other than that we all used the Model 33 because it was cheap and > reliable and we typed \( \) and dealt with it. > I disagree here. By November 1973 (Research Fourth Edition release date), many/most of us might have used an ~$1500 ASR-33 as the console, while, most often (though somewhat pricey - often $3K-$5 - think the DEC VT05), glass terminals had already been widely adopted. They were the primary terminals at every institution I was part of during that time. For reference, in 1970, the Tek 4010s were going for $4K-$10K, and they could not make them fast enough. You should also consider that Research Sixth Edition was released in May of 1975, and Lear Siegler announced the ADM-3A in July of 1976 for $995 as a kit or $1045 assembled. From tuhs at tuhs.org Thu May 21 09:07:28 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 20 May 2026 18:07:28 -0500 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> Message-ID: <20260520230728.7vp7sx6kilms7kbz@illithid> Hi Clem, At 2026-05-20T18:29:40-0400, Clem Cole via TUHS wrote: > On Wed, May 20, 2026 at 6:04 PM John Levine via TUHS wrote: > > Nice post but I can tell you from experience that Model 37 Teletypes > > were quite rare outside the Bell companies. > > Definitely true > > > I think I saw one once. > > I did see them in some places. Microsoft's 11/70 (Miss Piggy) had one > as its console (I suspect it still does, I have to ask Stephen Jones > as he has the system at the ICM). > > > Other than that we all used the Model 33 because it was cheap and > > reliable and we typed \( \) and dealt with it. > > I disagree here. By November 1973 (Research Fourth Edition release > date), many/most of us might have used an ~$1500 ASR-33 as the > console, while, most often (though somewhat pricey - often $3K-$5 - > think the DEC VT05), glass terminals had already been widely adopted. > They were the primary terminals at every institution I was part of > during that time. For reference, in 1970, the Tek 4010s were going > for $4K-$10K, and they could not make them fast enough. You should > also consider that Research Sixth Edition was released in May of 1975, > and Lear Siegler announced the ADM-3A in July of 1976 for $995 as a > kit or $1045 assembled. Thanks for raising this. When I'm explaining to people why groff works the way it does--and why I support Werner Lemberg's decision about 25 years ago to start assuming that a "terminal device" to which nroff writes is much more likely to be [an emulator of] a vaguely ECMA-48-compliant video terminal than of a hammer-or-typeball-or-chain- and-paper terminal--I often find myself having to explain that AT&T nroff was never a termcap or terminfo application. (This less surprises people than it reveals that they hadn't even considered the possibility in the first place. Whole generations of Unix people have come up not knowing that a Teletype machine was a "terminal", and at least one now that hasn't seen a CRT.) I'm aware that by the 1980s, the Bell Labs CSRC was interested in developing a graphical terminal--namely the portrait-mode Jerq/Blit/DMD 5620. And early (mid-'70s) troff did support document previewing on Tektronix 4014 terminals. I had thought that the CSRC's hands-off approach to video terminals was that (a) it "wasn't research", and (b) more a matter of the DEC VT100 showing up and commencing to eat the world, and Berkeley manifesting a resolve to attack the problem of character-cell video terminal support with its termcap library. Your comment extends my timeline backward, which isn't inconsistent with my story but leaves me wondering what the thinking was in earlier days, prior to 1978/9. AT&T did in fact hire the termcap developer away from Berkeley to craft terminfo--but that was in the 1980s. What's the mid-1970s rationale for AT&T ignoring this segment of the market, when it cannot have been a secret that people were using these devices to interface with Unix? I think I get why Research didn't dirty their hands with it. But it should have been solidly within USG/ "Program Generic"'s wheelhouse. And eventually it was, but took something like 7 years to get there. What gives? 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 tuhs at tuhs.org Thu May 21 10:04:53 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 20 May 2026 20:04:53 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> Message-ID: <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> On Wed, 20 May 2026, Clem Cole wrote: >> Other than that we all used the Model 33 because it was cheap and >> reliable and we typed \( \) and dealt with it. >> > I disagree here. By November 1973 (Research Fourth Edition release date), > many/most of us might have used an ~$1500 ASR-33 as the console, while, > most often (though somewhat pricey - often $3K-$5 - think the DEC VT05), > glass terminals had already been widely adopted. ... Everyone's experience was different. The Unix system I used in a lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had the TTY console and a bunch of unique homebrewed bitmap terminals that I wrote up in an article in Software Practice and Experience. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Thu May 21 10:23:22 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 20 May 2026 17:23:22 -0700 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> Message-ID: <20260521002322.GB26412@mcvoy.com> On Wed, May 20, 2026 at 08:04:53PM -0400, John R Levine via TUHS wrote: > On Wed, 20 May 2026, Clem Cole wrote: > >>Other than that we all used the Model 33 because it was cheap and > >>reliable and we typed \( \) and dealt with it. > >> > >I disagree here. By November 1973 (Research Fourth Edition release date), > >many/most of us might have used an ~$1500 ASR-33 as the console, while, > >most often (though somewhat pricey - often $3K-$5 - think the DEC VT05), > >glass terminals had already been widely adopted. ... > > Everyone's experience was different. The Unix system I used in a lab at > Princeton only had the ASR-33 TTY. The one I ran at Yale had the TTY > console and a bunch of unique homebrewed bitmap terminals that I wrote up in > an article in Software Practice and Experience. I don't have a lot to add to this other than there was some terminal, I think a VT-something, that had the standard 80x24 but it had a 25th line that was the status line. I think BSD had a Ctrl-T that dug info out of the kernel and displayed it on that line. When you are in a terminal room with 30-40 people on a 4MB VAX, Ctrl-T was your friend. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu May 21 10:36:06 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 21 May 2026 00:36:06 +0000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <20260520230728.7vp7sx6kilms7kbz@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> Message-ID: On Wednesday, May 20th, 2026 at 16:07, G. Branden Robinson via TUHS wrote: > But it should have been solidly within USG/ > "Program Generic"'s wheelhouse. And eventually it was, but took > something like 7 years to get there. > > What gives? So one of the earlier attempts at expanding the terminal support at USG was addition of line disciplines, I *think* in an evolutionary dead-end fashion, but I don't know enough about terminal drivers in AT&T offerings to be sure whether it died in the 70s or was incorporated in later efforts. In any case, the tty(IV) page of the USG Program Generic Issue 3[1] manual is informative. My understanding is that some of the work was done to specifically support half-duplex terminals[2], among them the Dataspeed/TTY 40/1. The USG Issue 3 manual explicitly adds bits to How to Get Started, the tty driver page, and a few others describing the new TTY 40 compatibility. Indeed in much AT&T promotional photography and the 3B20S UNIX 4.1 User's Manual[4], the terminal in use at the turn of the 80s is often pictured as a TTY 40 of some kind. There were 4 models, with the 40/1 being half-duplex, the 40/2 supporting both half and full, and the 40/4 being synchronous instead of async (I don't recall what set the 40/3 apart). As an aside Teletype also produced hardened models for the USDOD Tempest program, some advertisements for these are floating around the net. A nice design factor in the Teletype 40 is it shares a lot in common with the Dataphone modems of the time (black on aluminum, silver outline accents on bezels) that then showed up briefly in some post-divestiture commercial products such as the Sceptre videotex terminal. Their hardware design language at the time appeared to be blue metal paneling (ala 3B20S) for large compute hardware and then this silver-on-black-on-aluminum facade for peripherals and user devices a welcome change from the "everything is grey and beige" look of most telco offices of the time. Granted these are cursory observations, running down "fact" on these design languages and decisions is proving nigh impossible. I wonder if any of those design specs will ever surface.... But yeah in conclusion, the mid 70's Dataspeed 40 line is one I rarely see mentioned or talked about in terminal discussions but so much leads me to believe Ma Bell was trying to push the 40/1 and 40/2 as the "new standard" in UNIX terminals, at least internally, in the late 70s and early 80s. - Matt G. P.S. Where Thalia you are on the hunt for a TTY 37, I'm looking for its younger cousin the 40/2. Should your own search yield any TTY 40 stuff, could you shoot me a headsup? Will do the same if I spot a 37, I comb around internet auctions for TTY stuff from time to time. Many 40 parts on eBay right now...but just some boards, power supply, and keyboard. [1] - https://www.tuhs.org/Archive/Documentation/Manuals/Program_Generic_Issue_3/UNIX_Programmers_Manual_Program_Generic_Issue_3.pdf [2] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1077_UNIX_DH_11_Driver_to_Support_Both_TTY_and_Dataspeed_40_Terminals.pdf [3] - https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQH68WMstdCtpSbj0_kIqhEtfiJK-iKKpnEsxxxEk1sfjwd8C6x_WP3Sw-i&s=10 [4] - https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/UNIX4.1UsersManualCover.png/960px-UNIX4.1UsersManualCover.png From tuhs at tuhs.org Thu May 21 11:20:53 2026 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Thu, 21 May 2026 11:20:53 +1000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> Message-ID: <04831C76-4185-4965-AECD-3639729B7CF7@canb.auug.org.au> > On 21 May 2026, at 10:04, John R Levine via TUHS wrote: > > On Wed, 20 May 2026, Clem Cole wrote: >>> Other than that we all used the Model 33 because it was cheap and >>> reliable and we typed \( \) and dealt with it. >>> >> I disagree here. By November 1973 (Research Fourth Edition release date), >> many/most of us might have used an ~$1500 ASR-33 as the console, while, >> most often (though somewhat pricey - often $3K-$5 - think the DEC VT05), >> glass terminals had already been widely adopted. ... > > Everyone's experience was different. The Unix system I used in a lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had the TTY console and a bunch of unique homebrewed bitmap terminals that I wrote up in an article in Software Practice and Experience. > > Regards, > John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly Prof Murray Allen had a hardware background - he authorised a lot of interesting projects there. They built their own terminals to save money compared to commercial offerings. UNSW's Serge Poplavsky designed and built terminals using DRAM - new at the time. [ with 4096 bits chips, 80x25 x 8 bit = 16,000 bits, 'mode' bits were extra ] First model was TTL, 2nd model was a microprocessor. Could've been a 3rd model. I couldn't find a reference to the 1st rollout. John Lions had been using one for some time before his 1978 Sabbatical at Bell Labs. A serial-switched network was added in 1980 to connect multiple hosts. The Serge Terminals were designed to last: students wore the paint off the sheet metal next to the keyboard from resting their arms. Student lab terminals replaced by Apollo's and a LAN in 1988. I have an undated Oral History note: "Serge Terminals - replaced Kleinschmidt terminals". Kleinschmidt were an ASR-33 like printing terminal. Can't find good refs to them. =============== DMR's list of home terminals When John Lions was at Bell Labs on sabbatical: "Up till now I have been using a tty 43 (this listing) ... there is a noticeable preponderance of hard copy and lack of CRT terminals." John Lions, 15 August 1978 AUUGN Vol 1, No 1, p 21 =============== UNSW Archive file 08_224_01 Recollections_John-Lions_1992 In 1972 there were two projects under way: AR-16 and VisiCom. AR-16 (Allen-Ruting) was a 16-bit computer not unlike the PDP-11 in many respects. Its construction and development was the concern of two graduate students, John Hurst and Bob Zeltzer. VisiCom (Visible Computer) was a simplified version of the AR-16 designed for teaching basic programming. The entire memory contents was displayed in rows as groups of 4 hexadecimal characters. As I recall, its development was entrusted to Serge Poplavsky. [ Serge's ME thesis: A display computer for education and system research. - He'd experience in video & char-gen ] =============== from Ken Robinson's UNSW homepage: kenr_CSE-Timeline-2_2007 1988: Apollo workstation laboratory opened in Electrical Engineering undercroft. With the introduction of the Computer Engineering program in 1989 the Departmen chose to move to workstation laboratories, and the Apollo workstation laboratory was opened in 1988. Since then the School has managed a large number of workstation laboratories and individual workstations to support undergraduate, postgraduate and staff computing. 1980 A switching network was designed and began operation within the School of Electrical Engineering computer facilities. ‘The dramatic development came when a switching network (Local Automatic Computer Exchange) was designed and began operation in 1980. The LACE – as it was called – was an asynchronous terminal switch using time division multiplexing. This enabled all of the terminals to be able to be connected to any of the ever expanding number of host computers via a star architecture of seven nodes (in computing centres) and over two hundred extensions throughout. It was finally switched off in 1997.’ [KW Titmuss, ‘The History of Computing at the University of NSW’, December 1997, SRF – Computing Science, UNSW Archives] =============== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From tuhs at tuhs.org Thu May 21 11:22:50 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 20 May 2026 20:22:50 -0500 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: <20260521002322.GB26412@mcvoy.com> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> Message-ID: <20260521012250.qqrgwyl7ddza3gg5@illithid> At 2026-05-20T17:23:22-0700, Larry McVoy via TUHS wrote: > > Everyone's experience was different. The Unix system I used in a > > lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had > > the TTY console and a bunch of unique homebrewed bitmap terminals > > that I wrote up in an article in Software Practice and Experience. > > I don't have a lot to add to this other than there was some terminal, > I think a VT-something, that had the standard 80x24 but it had a 25th > line that was the status line. Yup, that was a DEC VT220 or maybe 320 feature. (Others had them, but DEC's VT series wagged a great deal of the dog.) https://vt100.net/docs/tp83/chapter4.html It's possible that the status line on the 25th row didn't become entrenched until the DEC VT320, or was not host-programmable until then; Thomas Dickey's terminfo database exhibits an "hs" capability for the "vt320" terminal type description but not for "vt220". https://invisible-island.net/ncurses/man/terminfo.5.html https://invisible-island.net/ncurses/terminfo.src.html If the database is inaccurate, maybe someone can help Thomas improve it. > I think BSD had a Ctrl-T that dug info out of the kernel and displayed > it on that line. Yup. With that factoid, not long ago I surprised a colleague at UNSW who was much closer to being Present at the Creation than I could have been. He knew Research Unix backwards and forwards, but not BSD. > When you are in a terminal room with 30-40 people on a 4MB VAX, Ctrl-T > was your friend. Unless _everybody_ learns that trick and exhibits undergrad patience, whacking it several times a second, and all those traps into the kernel just make the problem worse. ;-) 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 tuhs at tuhs.org Thu May 21 11:23:47 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 21:23:47 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <20260520230728.7vp7sx6kilms7kbz@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> Message-ID: below On Wed, May 20, 2026 at 7:07 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Clem, > > ... > Thanks for raising this. You're welcome. > ... > > I had thought that the CSRC's hands-off approach to video terminals was > that (a) it "wasn't research", and (b) more a matter of the DEC VT100 > showing up and commencing to eat the world, and Berkeley manifesting a > resolve to attack the problem of character-cell video terminal support > with its termcap library. > Well, it probably was a number of things. As I said for a long time, inside the Bell System, well into the 1970s, many/most people used a WE212 and a phone line to access the system down the hall. That was just the way the phone company did things (think about hammers and everything being a nail). Also, Teletype is an AT&T company. So getting one of their products was different from buying something from an outside vendor. This was different from the way Universities and others. By the late 70's, most places I experienced had started to switch. I'm sure there were pockets, but as I said, by July 1976, an ADM3A "glass tty" was the least expensive way to attach to any timesharing system, not just UNIX-based ones. Even in the Bell system, things did start to change by the mid-last 70s - you started seeing TI "Silent 700s" which were introduced in 1971 for $2780, in offices within the Bell System. By the late 70s, the HP 2621A and 2621P [which cost $1450 and $2550 in 1978] were definitely popular at the Labs, as they were slightly cheaper than DEC's August 1978 VT-100 release at $1900. The point is, as late as the development of Research Seventh Edition, the use of a "glass tty" was less common within the Bell System, while the Universities had already started to switch, and at many places (certainly my experience at CMU and USB) had already switched nearly 100%. But that was the problem. Most "video" editors like Cornell's Fred (friendly ed) or the Rand Editor were hard-coded for specific terminals. Joy's termcap was a huge (and practical) solution to an issue that was felt outside the Bell System before it was really needed inside it. > > Your comment extends my timeline backward, which isn't inconsistent with > my story but leaves me wondering what the thinking was in earlier days, > prior to 1978/9. AT&T did in fact hire the termcap developer away from > Berkeley to craft terminfo--but that was in the 1980s. > I think Mary Ann is on this list, so I let her comment directly. Certainly, by the late 1970s and early 1980s, the older scheme was beginning to change within the Bell System, but in my experience, it was lagging behind the outside. > > What's the mid-1970s rationale for AT&T ignoring this segment of the > market, when it cannot have been a secret that people were using these > devices to interface with Unix? There are a couple of things. First, please remember that AT&T is not allowed to be in the computer business. They had "abandoned on your doorstep" the sources to UNIX and left it to you to figure out what you wanted to do with it. So the only pressure they would have felt was from internal customers within the Bell System. AT&T "products" were from Teletype Corp. The interesting thing is that Teletype did make a "rugged" terminal targeted to the Bell System, insurance firms, and the US Military, called the Model 40 or Dataspeed 40, and sold in 1973 between $3K-4.5K. This was a modular, heavy-duty industrial data terminal. It featured a large, character-driven cathode ray tube (CRT) display, a detached keyboard, and an optional high-speed friction or tractor-feed line printer, and of course, could run up to 120 cps, just like what a WE212 modem could support. In the early 1980s, after ANSI X3.64 was released, Teletype tried again with the 4400 and 5000 families. The 1983 release of the 5410 and 5418 were traditional text-only character mode terminals that conformed to the ANSI X3.64 standard and cost $995 and ~$1300. They had no bit-mapped graphics capability, but they could switch between 80 and 132 columns of text and featured horizontal split-screen functions. The 1984 release of the 5420 and 5425 were intended for line-oriented data entry, allowing an operator to type out a full screen of text locally into memory before sending the raw text block to the host computer all at once — IBM mainframe style and cost $1495 and $2215. Of course, by 1983, the Wyse-50 was selling for $695 in ones and twos and substantially less in quantity ($350 was typical). By 1986, Wyse had their 100% ANSI-compliant Wyse-60 [VT-100s are only partially ANSI-compliant BTW, Wyse-60s could "dumb down" to be VT-100 too], which was listed at $599 with a street price in the $400-$450 range. To be fair, Pike and Locanthi created the JERQ in 1981. By 1984, it had been reengineered by Teletype to become the DMD 5620 [Dot Matrix Display] with a list price of $6115, and by 1986, you could get one from a VAR for around $4K. But fate would have it for Teletype again, as in Sept 1985, Sun released the Sun 3/50 for $8K sans disk and $14.9K as a standalone system. So, back to your question: by the time AT&T realized that "glass ttys" would be important, they were still inwardly focused as they developed products for their traditional market. Once they were allowed to be in the computer business officially (*i.e*., post Jan 1, 1984) the products they had were not competitive. > I think I get why Research didn't dirty > their hands with it. But it should have been solidly within USG/ > "Program Generic"'s wheelhouse. And eventually it was, but took > something like 7 years to get there. > It really was "TPC" in action. The development and bringing-to-market thinking inside AT&T was based on a history of having a captive market that told its customers what was needed. When the chains of the consent decree were cut, the problem was that they did not have a structure to recognize, much less understand and value, the same things their new customers wanted. The best example of that was the AT&T System V "UNIX Consider it Standard" campaign. The actual users outside of the Bell system scratched their heads, and so no. That was not something that AT&T's internal mechanism could handle. From tuhs at tuhs.org Thu May 21 11:25:42 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 20 May 2026 18:25:42 -0700 Subject: [TUHS] Fwd: [multicians] Peter Neumann has died In-Reply-To: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> Message-ID: <20260521012542.GC26412@mcvoy.com> My dad, a physist, said there is no after life. You are only alive if people are still talking about you. A nod to my dad, I miss him, but a huge nod to Peter Neumann, he is still here. On Wed, May 20, 2026 at 02:53:03PM -0700, Alan Coopersmith via TUHS wrote: > Some published obituaries/memorials: > > https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ > https://www.nytimes.com/2026/05/17/technology/peter-g-neumann-dead.html > https://www.sri.com/press/story/peter-neumann-saw-the-internets-dangers-before-the-internet-existed/ -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu May 21 11:37:36 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 20 May 2026 20:37:36 -0500 Subject: [TUHS] the history of termcap (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> Message-ID: <20260521013736.uzyipzqduglb5dey@illithid> Hi Clem, Splitting off one topic here... At 2026-05-20T21:23:47-0400, Clem Cole wrote: > The point is, as late as the development of Research Seventh Edition, > the use of a "glass tty" was less common within the Bell System, while > the Universities had already started to switch, and at many places > (certainly my experience at CMU and USB) had already switched nearly > 100%. But that was the problem. Most "video" editors like Cornell's > Fred (friendly ed) or the Rand Editor were hard-coded for specific > terminals. Joy's termcap was a huge (and practical) solution to an > issue that was felt outside the Bell System before it was really > needed inside it. I think this account might be positioning Joy such that he eclipses the contributions of others. Here's the history of the termcap library in the relevant ncurses man page nowadays. HISTORY Bill Joy originated a forerunner of termcap called “ttycap”, dated September 1977, and released in 1BSD (March 1978). It used many of the same function names as the later termcap, such as tgetent, tgetflag, tgetnum, and tgetstr. A clear descendant, the termlib library, followed in 2BSD (May 1979), adding tgoto and tputs. The former applied at that time only to cursor positioning capabilities, thus the overly specific name. Little changed in 3BSD (late 1979) except the addition of test programs and a termlib man page, which documented the API shown in section “SYNOPSIS” above. 4BSD (November 1980) renamed termlib to termcap and added another test program. The library remained much the same through 4.3BSD (June 1986). 4.4BSD‐Lite (June 1994) refactored it, leaving the API unchanged. ... Full disclosure: I've worked on that very content--with Thomas Dickey, of course. If there are incorrect claims, I'm keen to get them fixed. 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 tuhs at tuhs.org Thu May 21 11:39:43 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 20 May 2026 18:39:43 -0700 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: <20260521012250.qqrgwyl7ddza3gg5@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: On May 20, 2026, at 6:22 PM, G. Branden Robinson via TUHS wrote: > >> >> I think BSD had a Ctrl-T that dug info out of the kernel and displayed >> it on that line. > > Yup. With that factoid, not long ago I surprised a colleague at UNSW > who was much closer to being Present at the Creation than I could have > been. He knew Research Unix backwards and forwards, but not BSD. Ctrl-T performed a similar function on TOPS-10. [I used it at USC in '70s] On curly braces: lack of the same on European typewriters is why Pascal has (* ... *) as an alternative syntax to { ... } for comments. From tuhs at tuhs.org Thu May 21 11:42:46 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 01:42:46 +0000 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: I remember writing my first C program on a model 33. Had to use \( and \) for the curly braces. From tuhs at tuhs.org Thu May 21 11:44:18 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 20 May 2026 19:44:18 -0600 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: <20260521012250.qqrgwyl7ddza3gg5@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: On Wed, May 20, 2026, 7:22 PM G. Branden Robinson via TUHS wrote: > At 2026-05-20T17:23:22-0700, Larry McVoy via TUHS wrote: > > > Everyone's experience was different. The Unix system I used in a > > > lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had > > > the TTY console and a bunch of unique homebrewed bitmap terminals > > > that I wrote up in an article in Software Practice and Experience. > > > > I don't have a lot to add to this other than there was some terminal, > > I think a VT-something, that had the standard 80x24 but it had a 25th > > line that was the status line. > > Yup, that was a DEC VT220 or maybe 320 feature. (Others had them, but > DEC's VT series wagged a great deal of the dog.) > > https://vt100.net/docs/tp83/chapter4.html > > It's possible that the status line on the 25th row didn't become > entrenched until the DEC VT320, or was not host-programmable until then; > Thomas Dickey's terminfo database exhibits an "hs" capability for the > "vt320" terminal type description but not for "vt220". > > https://invisible-island.net/ncurses/man/terminfo.5.html > https://invisible-island.net/ncurses/terminfo.src.html > > If the database is inaccurate, maybe someone can help Thomas improve it. > > > I think BSD had a Ctrl-T that dug info out of the kernel and displayed > > it on that line. > > Yup. With that factoid, not long ago I surprised a colleague at UNSW > who was much closer to being Present at the Creation than I could have > been. He knew Research Unix backwards and forwards, but not BSD. > Close. ^T didn't display in that extra line. The tty driver didn't know terminal types... unless it was a local hack. Warner > When you are in a terminal room with 30-40 people on a 4MB VAX, Ctrl-T > > was your friend. > > Unless _everybody_ learns that trick and exhibits undergrad patience, > whacking it several times a second, and all those traps into the kernel > just make the problem worse. ;-) > > Regards, > Branden > From tuhs at tuhs.org Thu May 21 11:49:09 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 20 May 2026 20:49:09 -0500 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: <20260521014909.gqga4tngyvtslyvt@illithid> At 2026-05-20T19:44:18-0600, Warner Losh wrote: > Close. ^T didn't display in that extra line. The tty driver didn't > know terminal types... unless it was a local hack. Ah, good point. Doing so via termcap/terminfo would have been a waste anyway,[1] as the main motivation to whack Control+T in the first place is because your userland program is jammed up/swapped out. Regards, Branden [1] To say nothing of the tedium of setting up a "mailbox" for the kernel to drop the information into for later retrieval by the userland program, again missing the point of interrupting the kernel to demand basic performance stats from it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Thu May 21 11:54:26 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Thu, 21 May 2026 11:54:26 +1000 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: On Wed, May 20, 2026 at 06:16:52PM +0000, Thalia Archibald via TUHS wrote: > On Wednesday, May 20th, 2026 at 03:12, sjenkin wrote: > > Thalia, > > You've knocked it out of the park, again! > > > > You posed a question I'd not even thought of.  > > [once used an ASR-33 on a Nova, then years using Telex in 1980's - same m/c ]. > > > > read your piece, excellent. > > > > It took me ages to track down DMR's (?) list of tty's he'd used, > > only to find it was you that posted the note to TUHS. > > > > That list might belong in the current article, as it provides some context. > > > > Was it Dennis who wrote that list, because it doesn't include the ASR-33 attached to the PDP-7. > > > > all my best > > steve j > > > > ============== > > > > Teletypes used for early Unix > > 21 Jul 2025 > > > > > > DMR's list of terminals > > > > That's Dennis' list of personal terminals at home. I'd then consider the 1970 > date for the Teletype Model 37 an approximate upper bound for when they started > using the Model 37 at work. Dereferencing to the post in alt.folklore.computers, > this could yield an even more precise date: > > > It is true that word-processing and formatting (using Teletype model 37s) for > > the Bell Labs patent group was the first productive application of Unix > > outside our immediate group. > > I had actually forgotten about that list. At the time I posted, I was looking > for the specific sub-model number of the Model 37s they were using, so it didn't > quite answer what I wanted. I already knew they were using the Model 37 and the > 1970 date didn't help for that project. But it is useful for this post. Perhaps also mention the GRAPHIC-2 keyboard and IBM terminal support? "Our PDP-7 also had a full-ASCII keyboard that was part of the locally-built Graphics-II processor attached to the PDP-7, used for Space Travel, for example, and also for development once Unix was self-supporting." Dennis Ritchie, Feb 12 2011, alt.folklore.computers "Console input devices are a light pen, an ASCII-code keyboard (full seven-bit code), and eight pushbuttons." William H. Ninke A Satellite Display Console for a Multi-Access Central Computer bitsavers pdf/att/Bell_Labs/graphics-2/Graphic-2_Overview.pdf "Still, quite early Unix supported the half-duplex IBM 1050 and 2741 terminals, as had Multics and CTSS before that. It was a bit of a struggle, but it worked." Dennis Ritchie, Oct 31 2001, alt.folklore.computers 2741 is mentioned in the getty.s from the s1 tape https://www.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/getty.s From tuhs at tuhs.org Thu May 21 12:02:31 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Wed, 20 May 2026 22:02:31 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <20260520230728.7vp7sx6kilms7kbz@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> Message-ID: <202605210202.64L22V5N047643@ultimate.com> Regarding roff, 4.2BSD roff and v7 had "device" support by reading an a.out file (with an initialized struct) with spacing and character set info, pretty much oriented to PRINTING devices (Diablos and such) TTY37 was definitely one of the profiles, "lp" was another. The first Unix system I saw was an 11/40 in the EE department of Stevens Tech somewhere in the 79-81 time window. The console was a DECwriter I (LA33) and there was one (or more) VT05's (UC only, I swear they must have been made from cast iron). In the same time window the computer center ran a DEC-10. Only the two full-time programmers had VT100's. The terminal room had one VT52, four Datamedia Elite 1500's (with APL support), and a mess of ADM-3A's and DECwriters (III's?). I think a populat terminal on ITS at the time was the Datamedia Elite 2500. I started at DEC in 1981, and we all got VT100's in our cubes, BUT take home loaner terminals were VT05's at the time (ooof!), and not TOO long after that we got VT52's. A friend from a Cost Center with more money to burn got a home VT100 not too long after that... So while the ECMA 48 may have come out in 1976, the VT100 in 1978, and the ANSI standard in 1979, it took a NUMBER of year before the it was the dominant paradigm, and many of us were dealing with the fact that just about ANY VT100 escape sequence put a VT52 into "paged" mode, or some such dain bramage. Regarding any idea that "vaguely ECMA-48-compliant video terminals" were always the majority, or "the DEC VT100 showing up and commencing to eat the world", there was a (seemingly) long interval where terminals were a pretty unrully bunch thru the 1970's and early 80's, and it's little wonder that termcap was invented to tame them. To bring things firmly back into TUHS territory: In the early 80's I took a Harvard Extension class, and remember the Harvard Science Center 11/70 UNIX systems; ISTR them as being v6 based, and terminal types were all two characters (presumably passed around as two bytes, without the benefit of environment variables). And that termcap had two-char aliases as well... Am I remembering this correctly? From tuhs at tuhs.org Thu May 21 12:06:00 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 22:06:00 -0400 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: <20260521012250.qqrgwyl7ddza3gg5@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: There is great story about this. Control-T came from Tenex One of the items that would come back was the status: Core Execution States - *RUNNING*: The program was currently executing code on the CPU. - *IO WAIT*: The program was temporarily paused, waiting for an input or output operation to complete (most frequently waiting for the user to type something on the terminal). - *SLEEP*: The program was intentionally paused for a set duration, usually via a programmed delay or timer call. - *FORK WAIT*: The parent process was suspended, waiting for a subordinate parallel process (a "fork" in TENEX/TOPS-20 terminology) to finish execution or change state. - Blocked and Sub-System States Depending on the specific resource or kernel function blocking the process, the monitor could also return more specialized wait states: - *JSYS WAIT*: Waiting on the completion of a specific *Jump to System* (JSYS) monitor call. - *PAGE WAIT*: Blocked while the operating system's demand-paging architecture retrieved a required memory page from the disk swap space into physical core memory. - *LOCK WAIT*: Waiting to acquire a system lock or a shared internal resource that was currently in use by another job. - *DEVICE WAIT*: Waiting specifically on a non-terminal hardware device, such as a magnetic tape drive or line printer Control States - *HALT*: The program had encountered an explicit halt instruction or hit a hard breakpoint and was no longer running. - *^C DETACHED*: The process had been interrupted by the user typing Ctrl-C to escape back to the EXEC command level, leaving the background program in a paused, unattached state. Stanford migrated from IBM 360 systems to DEC systems to provide timesharing cycles for the undergraduates - Pascal programming and doc prep mostly. After they started up the first TOPS-20 folks customized (hacked) OS so that depending what the load average, control-T returned different messages telling you a bit more than “Running.” So instead of saying “Running” it started saying “Jogging”, “Walking” or “Crawling” but the administration got upset when it was most often stating “Dying.” On the other hand one of my friends that was an undergraduate there at the time said, the students were able to use it as evidence that there was not enough compute power to serve the students. I believe, like CMU at the same time, Stanford ended up with 4 2060s to replace their mainframe for undergrad computes. Sent from a handheld expect more typos than usual On Wed, May 20, 2026 at 9:22 PM G. Branden Robinson via TUHS wrote: > At 2026-05-20T17:23:22-0700, Larry McVoy via TUHS wrote: > > > Everyone's experience was different. The Unix system I used in a > > > lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had > > > the TTY console and a bunch of unique homebrewed bitmap terminals > > > that I wrote up in an article in Software Practice and Experience. > > > > I don't have a lot to add to this other than there was some terminal, > > I think a VT-something, that had the standard 80x24 but it had a 25th > > line that was the status line. > > Yup, that was a DEC VT220 or maybe 320 feature. (Others had them, but > DEC's VT series wagged a great deal of the dog.) > > https://vt100.net/docs/tp83/chapter4.html > > It's possible that the status line on the 25th row didn't become > entrenched until the DEC VT320, or was not host-programmable until then; > Thomas Dickey's terminfo database exhibits an "hs" capability for the > "vt320" terminal type description but not for "vt220". > > https://invisible-island.net/ncurses/man/terminfo.5.html > https://invisible-island.net/ncurses/terminfo.src.html > > If the database is inaccurate, maybe someone can help Thomas improve it. > > > I think BSD had a Ctrl-T that dug info out of the kernel and displayed > > it on that line. > > Yup. With that factoid, not long ago I surprised a colleague at UNSW > who was much closer to being Present at the Creation than I could have > been. He knew Research Unix backwards and forwards, but not BSD. > > > When you are in a terminal room with 30-40 people on a 4MB VAX, Ctrl-T > > was your friend. > > Unless _everybody_ learns that trick and exhibits undergrad patience, > whacking it several times a second, and all those traps into the kernel > just make the problem worse. ;-) > > Regards, > Branden > From tuhs at tuhs.org Thu May 21 12:15:26 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Wed, 20 May 2026 22:15:26 -0400 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> Message-ID: <202605210215.64L2FQl8047893@ultimate.com> JSG wrote: > Perhaps also mention the GRAPHIC-2 keyboard and IBM terminal support? > > "Our PDP-7 also had a full-ASCII keyboard that was part of the > locally-built Graphics-II processor attached to the PDP-7, used for > Space Travel, for example, and also for development once Unix was > self-supporting." > Dennis Ritchie, Feb 12 2011, alt.folklore.computers ISTR my reading of the UNIX-7 kernel support for Graphics-II was as a glass TTY: When you got to the bottom of the screen you had to push a button to clear the screen and start over! I wrote a G2TTY emulation for SimH that allows a second user to TELNET in (the emulation pushed the button for you as needed!) From tuhs at tuhs.org Thu May 21 12:36:55 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 20 May 2026 22:36:55 -0400 Subject: [TUHS] the history of termcap (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: <20260521013736.uzyipzqduglb5dey@illithid> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> <20260521013736.uzyipzqduglb5dey@illithid> Message-ID: Believe me when I state, I wasn’t trying to suggest more of Joy’s work than other than he started it all. His ex(1) edited was different than fred(1), ned(1) and the like. The terminal support was in an external ascii db for ex(1). For instance I hacked fred(1) to support the Perkin Elmer Fox terminal which CMU standardized on in 1978 [they a great volume price - my memory is $750-$800]. WRT to the full history of term cap, the person you need to talk to is Mary Ann Horton (off line). I was at UCB for some of its history, but arrived earlier than I did and she was integral it all of it. She started with Joys work and took it to a new level I believe she is the one that broke it out of ex(1), but she was not the one that did that, she will know who did. Note curses(3) was much later - and instead ex(1) being the driver, rogue(1) was. In that case, you need to talk to Ken Arnold who adapted his library for Mine Toy. Sent from a handheld expect more typos than usual On Wed, May 20, 2026 at 9:37 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Clem, > > Splitting off one topic here... > > At 2026-05-20T21:23:47-0400, Clem Cole wrote: > > The point is, as late as the development of Research Seventh Edition, > > the use of a "glass tty" was less common within the Bell System, while > > the Universities had already started to switch, and at many places > > (certainly my experience at CMU and USB) had already switched nearly > > 100%. But that was the problem. Most "video" editors like Cornell's > > Fred (friendly ed) or the Rand Editor were hard-coded for specific > > terminals. Joy's termcap was a huge (and practical) solution to an > > issue that was felt outside the Bell System before it was really > > needed inside it. > > I think this account might be positioning Joy such that he eclipses the > contributions of others. Here's the history of the termcap library in > the relevant ncurses man page nowadays. > > HISTORY > Bill Joy originated a forerunner of termcap called “ttycap”, dated > September 1977, and released in 1BSD (March 1978). It used many of > the same function names as the later termcap, such as tgetent, > tgetflag, tgetnum, and tgetstr. > > A clear descendant, the termlib library, followed in 2BSD (May > 1979), adding tgoto and tputs. The former applied at that time > only to cursor positioning capabilities, thus the overly specific > name. Little changed in 3BSD (late 1979) except the addition of > test programs and a termlib man page, which documented the API > shown in section “SYNOPSIS” above. > > 4BSD (November 1980) renamed termlib to termcap and added another > test program. The library remained much the same through 4.3BSD > (June 1986). 4.4BSD‐Lite (June 1994) refactored it, leaving the > API unchanged. > ... > > Full disclosure: I've worked on that very content--with Thomas Dickey, > of course. If there are incorrect claims, I'm keen to get them fixed. > > Regards, > Branden > From tuhs at tuhs.org Thu May 21 15:29:30 2026 From: tuhs at tuhs.org (r.stricklin via TUHS) Date: Wed, 20 May 2026 22:29:30 -0700 Subject: [TUHS] Project Release Announcement - Vintage UNIX (and others) Online Manuals Message-ID: I've been working on this project for ages. It is not complete. It may never be complete. It is, however, finally in a state that I consider to be eminently usable. A "beta" or "soft opening" - there are absolutely some visibly unfinished areas. But, it can absolutely be used while I continue improving the typesetter and the indexer, polishing the presentation, and adding manuals for new systems. http://www.typewritten.org/Manual/ Some folks were given access to previous development versions and asked not to share the URLs. If you were one of them, please transition to this URL instead; this one can be considered fully public. ok bear. ps. since joining the list a year or so ago, I’ve discovered I’m hardly the only one working on a project along these lines. here’s my contribution to the party. I don’t know if I should admit that "for ages" =~ "off and on for more than 15 years"? pps. this announcement was also sent to the VCFED forum and the classiccmp-l mailing list From tuhs at tuhs.org Thu May 21 16:02:47 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Thu, 21 May 2026 06:02:47 +0000 Subject: [TUHS] early Unix terminals In-Reply-To: (Clem Cole via TUHS's message of "Wed, 20 May 2026 22:06:00 -0400") References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: <7wtss1e1vc.fsf@junk.nocrew.org> Clem Cole wrote: > There is great story about this. Control-T came from Tenex And Tenex got it from BBN LISP on the 940. > the first TOPS-20 folks customized (hacked) OS so that depending what > the load average, control-T returned different messages telling you a > bit more than “Running.” So instead of saying “Running” it started > saying “Jogging”, “Walking” or “Crawling” but the administration got > upset when it was most often stating “Dying.” On ITS, the system monitor PEEK reports the speed of a running job with the fastest being WARP, then ZOOM, FLY, RUN, WALK, TENEX, and the slowest being MULTIX. (The latter two used to be CRAWL and CREEP.) Follow-ups should go to COFF. From tuhs at tuhs.org Thu May 21 17:49:06 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Thu, 21 May 2026 03:49:06 -0400 Subject: [TUHS] early Unix terminals (was: Re: Curly braces: An evolution of UNIX and C) In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: On Wed, May 20, 2026, 10:06 PM Clem Cole via TUHS wrote: > > So instead of saying > “Running” it started saying “Jogging”, “Walking” or “Crawling” but the > administration got upset when it was most often stating “Dying.” > I never used Tenex or Tops-20, but I remember this feature from Tops-10 (as well as from RSTS/E later on). But it may have been an update or local (UPenn) hack. > > On the other hand one of my friends that was an undergraduate there at the > time said, the students were able to use it as evidence that there was not > enough compute power to serve the students. I believe, like CMU at the > same time, Stanford ended up with 4 2060s to replace their mainframe for > undergrad computes. > > Sent from a handheld expect more typos than usual > > On Wed, May 20, 2026 at 9:22 PM G. Branden Robinson via TUHS < > tuhs at tuhs.org> > wrote: > > > At 2026-05-20T17:23:22-0700, Larry McVoy via TUHS wrote: > > > > Everyone's experience was different. The Unix system I used in a > > > > lab at Princeton only had the ASR-33 TTY. The one I ran at Yale had > > > > the TTY console and a bunch of unique homebrewed bitmap terminals > > > > that I wrote up in an article in Software Practice and Experience. > > > > > > I don't have a lot to add to this other than there was some terminal, > > > I think a VT-something, that had the standard 80x24 but it had a 25th > > > line that was the status line. > > > > Yup, that was a DEC VT220 or maybe 320 feature. (Others had them, but > > DEC's VT series wagged a great deal of the dog.) > > > > https://vt100.net/docs/tp83/chapter4.html > > > > It's possible that the status line on the 25th row didn't become > > entrenched until the DEC VT320, or was not host-programmable until then; > > Thomas Dickey's terminfo database exhibits an "hs" capability for the > > "vt320" terminal type description but not for "vt220". > > > > https://invisible-island.net/ncurses/man/terminfo.5.html > > https://invisible-island.net/ncurses/terminfo.src.html > > > > If the database is inaccurate, maybe someone can help Thomas improve it. > > > > > I think BSD had a Ctrl-T that dug info out of the kernel and displayed > > > it on that line. > > > > Yup. With that factoid, not long ago I surprised a colleague at UNSW > > who was much closer to being Present at the Creation than I could have > > been. He knew Research Unix backwards and forwards, but not BSD. > > > > > When you are in a terminal room with 30-40 people on a 4MB VAX, Ctrl-T > > > was your friend. > > > > Unless _everybody_ learns that trick and exhibits undergrad patience, > > whacking it several times a second, and all those traps into the kernel > > just make the problem worse. ;-) > > > > Regards, > > Branden > > > From tuhs at tuhs.org Thu May 21 18:26:34 2026 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Thu, 21 May 2026 01:26:34 -0700 Subject: [TUHS] early Unix terminals In-Reply-To: <7wtss1e1vc.fsf@junk.nocrew.org> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: most of the unix people used an ibm 134.5 baud terminal. i think the designation was 1050. it was a desk of electronics with a selectric typewriter on top. it preceded the tty 37. On Wed, May 20, 2026 at 11:02 PM Lars Brinkhoff via TUHS wrote: > Clem Cole wrote: > > There is great story about this. Control-T came from Tenex > > And Tenex got it from BBN LISP on the 940. > > > the first TOPS-20 folks customized (hacked) OS so that depending what > > the load average, control-T returned different messages telling you a > > bit more than “Running.” So instead of saying “Running” it started > > saying “Jogging”, “Walking” or “Crawling” but the administration got > > upset when it was most often stating “Dying.” > > On ITS, the system monitor PEEK reports the speed of a running job > with the fastest being WARP, then ZOOM, FLY, RUN, WALK, TENEX, and > the slowest being MULTIX. (The latter two used to be CRAWL and CREEP.) > > Follow-ups should go to COFF. > From tuhs at tuhs.org Thu May 21 20:24:41 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Thu, 21 May 2026 11:24:41 +0100 Subject: [TUHS] early Unix terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: Editing on paper output devices had it's upsides in terms of how you had to think about what you were doing. I liked using the decwriter with a line mode editor. From tuhs at tuhs.org Thu May 21 21:00:21 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 11:00:21 +0000 Subject: [TUHS] early Unix terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: The same argument was made about having to punch cards and submit them by batch, but I think people got over it. Oddly, I stuck with “ed” for a long time (until the first emacs variants hit BRL). I never really learned vi. If there was no emacs on a machine, I used ed. If there was only vi, then I ran it in “ex” mode. You did get good at regular expressions. My employees were always amazed at how fast I could edit documents with only ed. ------ Original Message ------ >From "George Michaelson via TUHS" To "The Eunuchs Hysterical Society" Date 5/21/2026 6:24:41 AM Subject [TUHS] Re: early Unix terminals >Editing on paper output devices had it's upsides in terms of how you had to >think about what you were doing. > >I liked using the decwriter with a line mode editor. From tuhs at tuhs.org Thu May 21 21:02:48 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 11:02:48 +0000 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: When Mike Muuss was playing with enhancing the UNIX scheduler in our (largely V6 based) kernels, we had access to some of the DEC-10 OS’s that did have control-T. Mike added that to our kernel (llisting all the processes running on the terminal) so he could get some feedback on what his tweaks were doing. -Ron From tuhs at tuhs.org Thu May 21 21:38:37 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Thu, 21 May 2026 07:38:37 -0400 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: My recollection is that Chris Torek at University of Maryland added control t to the bsd tty driver and it was made available in 4.3 or so. It was posted to Usenet which is where I read about it On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > When Mike Muuss was playing with enhancing the UNIX scheduler in our > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > that did have control-T. > Mike added that to our kernel (llisting all the processes running on the > terminal) so he could get some feedback on what his tweaks were doing. > > -Ron > > From tuhs at tuhs.org Thu May 21 22:35:38 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 21 May 2026 08:35:38 -0400 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: Steve Zimmerman also put a Tenex style control-T into the Masscomp terminal driver in 1985 if I remember the date correctly. He also had some other useful ideas/features that I believe were from ITS and maybe MIT’s SUPDUP. But it was nice. I’ve forgotten the details, but he had the whole thing set it up so when running on the console, it was hooked into kdb, too. Sent from a handheld expect more typos than usual On Thu, May 21, 2026 at 7:38 AM Rich Salz via TUHS wrote: > My recollection is that Chris Torek at University of Maryland added control > t to the bsd tty driver and it was made available in 4.3 or so. It was > posted to Usenet which is where I read about it > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > that did have control-T. > > Mike added that to our kernel (llisting all the processes running on the > > terminal) so he could get some feedback on what his tweaks were doing. > > > > -Ron > > > > > From tuhs at tuhs.org Thu May 21 23:09:02 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 21 May 2026 09:09:02 -0400 Subject: [TUHS] [COFF] Community 'deprecation' of gets(3) In-Reply-To: <87pl2pbgzk.fsf@gmail.com> References: <87pl2pbgzk.fsf@gmail.com> Message-ID: On Wed, May 20, 2026 at 11:04 PM Alexis via COFF wrote: > Wasn't entirely sure whether this would be appropriate for TUHS, > so erring on the side of caution and posting here. :-) If it _is_ > appropriate, please loop TUHS in on any replies. [I think this is perfectly acceptable for TUHS; Cc'ed there] > At what point did the use of gets(3) become 'deprecated' by the C > / Unix / whatever communities, for security and general buginess > reasons? In the sense that there was a general consensus that it > shouldn't be used, particularly due to the security implications, > despite still being permitted by specs? I don't know when people first started thinking about it, but after the November 1988 Morris Internet worm, it was generally understood that it was a bad idea to use `gets()`, particularly in programs that were exposed to untrusted input. Especially if those were privileged. Levy's, "Smashing the Stack for Fun and Profit" appeared in Phrack 8 years later, in November 1996, and opened the flood gates for a whole slew of buffer overrun bugs turned into security exploits. The bulk of those took a couple of years to address, with new variations on the theme seemingly discovered every few months: it wasn't just `gets()`, but `strcpy`/`strcat`, `sprintf`, `printf(buf)` (e.g., without a format string), and so on, leading to a flurry of activity to try and introduce safe(r) string operations into C. After that, people who hadn't before got the message: "gets() is dangerous; don't use it" along with a few other best practices ("always use an explicit format string for `printf` etc). Incidentally, `snprintf` came around that time, and a lot of buggy code was written to try and use `strncpy` and `strncat`; eventually we got `strlcpy` and `strlcat`, which the world seems to have mostly settled on: those are in POSIX now. The long tail of all of that is still with us, though, and new issues of that class are introduced regularly; sigh. > gets(3) was: > > * included in Issue 1, but i can't find an online copy of that (or > of Issue 1 of the SVID)[a]; > * deprecated in C99, removed in C11; and > * obsoleted by POSIX Issue 7 / .1-2008. Personally, I am amazed it remained in the C standard and POSIX for as long as it did. - Dan C. From tuhs at tuhs.org Thu May 21 23:31:32 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 13:31:32 +0000 Subject: [TUHS] [COFF] Community 'deprecation' of gets(3) In-Reply-To: References: <87pl2pbgzk.fsf@gmail.com> Message-ID: While the Morris Worm certainly gave a lot of press to such security issues, the problems with gets buffer overruns were well know before that. Those of us who worked with UNIX security issues had found people trying to exploit these on local scale (gets predates the internet deployment by quite some time), if not just to obtain access, but at least to crashdisrupt system operations. From tuhs at tuhs.org Thu May 21 23:34:05 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Thu, 21 May 2026 09:34:05 -0400 Subject: [TUHS] early Unix terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: I switched from Teco to ex when I started using Eunice and I remain with it to this day. I occasionally switch to vi mode to bounce on the % key when writing Lisp. Otherwise I describe myself as an "ex" troglodyte. On Thu, May 21, 2026, 7:00 AM Ron Natalie via TUHS wrote: > The same argument was made about having to punch cards and submit them > by batch, but I think people got over it. > > Oddly, I stuck with “ed” for a long time (until the first emacs variants > hit BRL). I never really learned vi. If there was no emacs on a > machine, I used ed. If there was only vi, then I ran it in “ex” mode. > You did get good at regular expressions. My employees were always > amazed at how fast I could edit documents with only ed. > > > > ------ Original Message ------ > From "George Michaelson via TUHS" > To "The Eunuchs Hysterical Society" > Date 5/21/2026 6:24:41 AM > Subject [TUHS] Re: early Unix terminals > > >Editing on paper output devices had it's upsides in terms of how you had > to > >think about what you were doing. > > > >I liked using the decwriter with a line mode editor. > From tuhs at tuhs.org Thu May 21 23:42:58 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 21 May 2026 09:42:58 -0400 Subject: [TUHS] early Unix terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: Thanks. I knew there were IBM terminals around the labs, but I don’t know how extensive they were. The 1050 pre-dated the 2741 IIRC. And it was ½ duplex and still needed to be attached to a modem, right. FWIW: Ted Kowalski was the first person I knew that had a TI Silent 700 which he brought with him on his OYOC year at CMU and kept in his room to dial into places. IIRC He also had a second telephone line that I seem to remember was provisioned so he could dial into the USG systems without running up huge phone charges. He and Armando told me the TI terminals were fairly widely used in USG. I can say I personally noticed that when visited Summit later, that seemed about right. Plus when I spent time in Whippany, the HP 2621s seemed to be the most common. A quick question for you. I suspect it was not just site related, but probably also management chain; when did actual direct hardwares connections begin to occur? I noticed them in Redman’s crew in WH, but the folks I was working with were running their HP’s over phone lines and a modem to their vaxen. I saw much of the same thing in both IH and Columbus the few times I was at those sites. That said and thinking a bit more, I think I saw some people in IH using ISDN links, too. But coming from outside of the Bell System, I thought it was unusual to me. I also remember talking to ber about it once in the early 1980s. FWIW: I’ve a picture somewhere that I took in the fall of 1979, of a large pallet of around 75 custom cables that were 7-wire + gnd and shield, terminated with DB25P on one end and DB25S the other., being delivered to hall outside my office area. We had a cable company make for my Tek Labs group. We eventually ran them from our 11/70 to the open air offices of our team [raised floor in the computer room a floor above and down through the ceiling and into cable races on our floor]. We were doing networking research at the time and had created a small z80 based box, we called the “Network Interface Black Box” that could talk to an Ethernet like wire. I remember Rick LeFairve, head of CSG, seeing it and remarking that the pile of cables was why we had to get the per unit cost out of something like the NIBB. Clem As I said, their clearly the phone line culture was prevalent. Sent from a handheld expect more typos than usual On Thu, May 21, 2026 at 4:26 AM Ken Thompson via TUHS wrote: > most of the unix people used an ibm > 134.5 baud terminal. i think the designation > was 1050. it was a desk of electronics with > a selectric typewriter on top. it preceded > the tty 37. > > On Wed, May 20, 2026 at 11:02 PM Lars Brinkhoff via TUHS > wrote: > > > Clem Cole wrote: > > > There is great story about this. Control-T came from Tenex > > > > And Tenex got it from BBN LISP on the 940. > > > > > the first TOPS-20 folks customized (hacked) OS so that depending what > > > the load average, control-T returned different messages telling you a > > > bit more than “Running.” So instead of saying “Running” it started > > > saying “Jogging”, “Walking” or “Crawling” but the administration got > > > upset when it was most often stating “Dying.” > > > > On ITS, the system monitor PEEK reports the speed of a running job > > with the fastest being WARP, then ZOOM, FLY, RUN, WALK, TENEX, and > > the slowest being MULTIX. (The latter two used to be CRAWL and CREEP.) > > > > Follow-ups should go to COFF. > > > From tuhs at tuhs.org Fri May 22 00:00:41 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 14:00:41 +0000 Subject: [TUHS] More ruminations on terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: I got started with UNIX, like many, at various Universities. Model 33’s were indeed de rigeur, but they started to be replaced by the LA-36 DecWriters (University of MD put a bunch in because these had APL as an optional character set and I spent one summer learning APL which I’ve never used again). We did have various CRTs including the LSI ADM-1’s (all upper case, but did have cursor addressing) and later the popular ADM-3. U of M also had a Tektronix of some sort and the Hazeltine. The latter used tilde rather than escape for the command character, to get a real tilde on the screen, you had to send two. This led to a mod in the TTY driver referred to as “brain-damaged Hazeltine mode” with a source code comment of “leave poor tilde alone). While the Model 33 could return the type element to the left in the time it took for the next 110 baud character to come around, other printers required addition of delays in the tty driver to accomodate this. The later Decwriters had the ability to catch up (in addition to printing in both directions). Hopkins had a Model 37 in the EE building in the room referred to as “the KSR room.” This one had a greek box, and it was where most of us did our NROFF + EQN report generation. The thing knew how to deal with all those fun ESC 8 and ESC 9 things that nroff liked to send out without the need for an output filter. It also had a large NEWLINE key and returned the type box on Thank you for reaching out. so you didn’t have to have crmod turned on. It was eventually replaced with a diablo printer which was a bit neater. This held us until the early eighties when laser printers started to appear. When I was working for Martin Marietta in Denver, I used to peruse the surplus depot at the company. One day I found an ASR-37 (marked property of Rocky Flats for some reason). I decided I had to have it, so it sat in my apartment for some time. I had it on a modem, and it was amusing because it woulldn’t start the motors until DSR signal from the modem came on. When the CD line came on it lit up a “PROCEED” button (an array of buttons on the front of the device much like the line buttons on a key-station telephone). RS finally took it off my hands and I think he left it blocking someone’s car in a parking space at MCI or Sprint or something like that as a hoax. We spent a lot of time at the Army trying to craft terminal procurements to get ones we like. Mostly at the time, we wanted to get ones that put CONTROL next to the A rather than caps lock, but that ended up being a losing battle. Our last dedicated UNIX terminals were the AT&T 5620 DMDs, the outgrowth of the Bell BLiT terminals, aka Jerq (the latter coined by Tom Duff if I’m remembering, never made it into the official documentation, however many of the underlying driver code referenced J_ this or that). From tuhs at tuhs.org Fri May 22 00:01:54 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 21 May 2026 14:01:54 +0000 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: The ^T process list was also very handy when I was hacking JOB control into the Bourrne Shell. From tuhs at tuhs.org Fri May 22 01:01:42 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 21 May 2026 11:01:42 -0400 Subject: [TUHS] early Unix terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> Message-ID: On 5/20/26 9:39 PM, Bakul Shah via TUHS wrote: > Ctrl-T performed a similar function on TOPS-10. [I used it at USC in '70s] The BSD implementation was inspired by TOPS-20's, I think, which was quite similar. I used TOPS-20 in the 80s. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri May 22 01:48:27 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Thu, 21 May 2026 11:48:27 -0400 Subject: [TUHS] More ruminations on terminals In-Reply-To: References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <7wtss1e1vc.fsf@junk.nocrew.org> Message-ID: On Thu, May 21, 2026 at 10:00 AM Ron Natalie via TUHS wrote: > While the Model 33 could return the type element to the left in the time > it took for the next 110 baud character to come around, other printers > required addition of delays in the tty driver to accomodate this. A Teletype Model 33 actually took two character times to complete a carriage return. The most common way to do perform a newline operation was the sequence CR/LF/NUL. Not doing this risked the next character being printed in the wrong column. > The > later Decwriters had the ability to catch up (in addition to printing in > both directions). > The LA36 DECwriter II did this, although it was unidirectional. It could print steadily at 300 baud without the need for fill characters. There was a circuit board hack to cause the LA36 to print in catch-up mode all the time. If XON/XOFF protocol was enabled in the OS's terminal driver, this allowed the LA36 to operate at double the normal baud rate. DEC field service discouraged use of this hack because it dramatically increased the wear-and-tear on the hardware. -Paul W. From tuhs at tuhs.org Fri May 22 02:11:49 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Thu, 21 May 2026 12:11:49 -0400 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: Regarding ^T, VAX/VMS borrowed it from TOPS-20/TENEX. It is implemented in the terminal driver and can be enabled/disabled. When enabled the terminal driver does not treat ^T as part of the terminal's data stream. Instead it calls the asynchronous system trap (AST) routine that the process has set up to capture ^T. The DCL command interpreter's ^T AST routine sends a broadcast message to the terminal containing the current date/time and process status information. -Paul W. From tuhs at tuhs.org Fri May 22 02:36:02 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 21 May 2026 12:36:02 -0400 Subject: [TUHS] More ruminations on terminals In-Reply-To: References: <7wtss1e1vc.fsf@junk.nocrew.org> <20260521002322.GB26412@mcvoy.com> <20260521012250.qqrgwyl7ddza3gg5@illithid> <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260520220415.A3F9310B Message-ID: <20260521163602.EC23910C0F4E7@ary.qy> It appears that Paul Winalski via TUHS said: >On Thu, May 21, 2026 at 10:00 AM Ron Natalie via TUHS wrote: > >> While the Model 33 could return the type element to the left in the time >> it took for the next 110 baud character to come around, other printers >> required addition of delays in the tty driver to accomodate this. > >A Teletype Model 33 actually took two character times to complete a >carriage return. The most common way to do perform a newline operation was >the sequence CR/LF/NUL. Not doing this risked the next character being >printed in the wrong column. Nitpick: on a Teletype, CR/LF was fine, no NUL needed. The LF gave the carriage time to return. As I recall the 5th and 6th edition terminal drivers could delay between characters if you had a CR or tab without an LF to let it catch up, rather than sending NUL. R's, John From tuhs at tuhs.org Fri May 22 05:05:10 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 21 May 2026 13:05:10 -0600 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> Message-ID: <202605211905.64LJ5Al9033970@freefriends.org> In > https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ It's brought down that some stories credit Peter Neumann with the Unics pun on Multics. It's plausible as he as involved in Multics for Bell Labs, (apparently) was still around when Ken started working on the PDP-7 in 1969-1970, and he had a penchant for puns. Other histories I've seen credit Brian Kernighan with the naming. When I asked BWK some time back, he said he didn't remember. Doug and/or Ken, do either of you happen to remember definitively? Thanks, Arnold From tuhs at tuhs.org Fri May 22 05:23:02 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 21 May 2026 13:23:02 -0600 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: Message-ID: <202605211923.64LJN281035690@freefriends.org> It was indeed posted to USENET, but didn't (IIRC) make it into the official 4.3 BSD release. Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I put it into 4.3BSD + Mt. Xinu at Emory. At GT, I remember a professor who came from MIT being pleasantly surprised to learn that we had ^T on the vax. :-) Rich Salz via TUHS wrote: > My recollection is that Chris Torek at University of Maryland added control > t to the bsd tty driver and it was made available in 4.3 or so. It was > posted to Usenet which is where I read about it > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > that did have control-T. > > Mike added that to our kernel (llisting all the processes running on the > > terminal) so he could get some feedback on what his tweaks were doing. > > > > -Ron > > > > From tuhs at tuhs.org Fri May 22 05:51:38 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 21 May 2026 15:51:38 -0400 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: <202605211905.64LJ5Al9033970@freefriends.org> References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> <202605211905.64LJ5Al9033970@freefriends.org> Message-ID: In Dennis's Oct 1984 BSTJ paper: "The Evolution of the Unix Operating System" ( https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf), in the last paraphraph of the section entired "Origins" on page 3, he says: *"Up to this time all the programs were written using GECOS and files were transferred to the PDP-7 on paper tape; but once an assembler was completed the system was able to support itself. Although it was not until well into 1970 that Brian Kernighan suggested the name 'Unix,' in a somewhat treacherous pun on 'Multics,' the operating system we know today was born." * On Thu, May 21, 2026 at 3:05 PM Arnold Robbins via TUHS wrote: > In > > > https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ > > It's brought down that some stories credit Peter Neumann with the Unics > pun on Multics. It's plausible as he as involved in Multics for Bell Labs, > (apparently) was still around when Ken started working on the PDP-7 in > 1969-1970, and he had a penchant for puns. > > Other histories I've seen credit Brian Kernighan with the naming. When > I asked BWK some time back, he said he didn't remember. > > Doug and/or Ken, do either of you happen to remember definitively? > > Thanks, > > Arnold > From tuhs at tuhs.org Fri May 22 06:25:27 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 21 May 2026 16:25:27 -0400 Subject: [TUHS] rsync from minnie? Message-ID: <202605212025.64LKPS60043052@freefriends.org> Hi. I'm in the US, and trying to rsync from minnie. It's not doing anything, and when I ping minnie.tuhs.org I get an IPv6 address: 2600:3c01::2000:a0ff:fead:bc2f Any ideas? It's not crucial for right now. Also, I'll be offline the next two days, but will eventually see any replies. Thanks, Arnold From tuhs at tuhs.org Fri May 22 06:29:27 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 21 May 2026 14:29:27 -0600 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> <202605211905.64LJ5Al9033970@freefriends.org> Message-ID: <202605212029.64LKTRVI043799@freefriends.org> Much thanks. That sounds pretty definitive. Arnold Clem Cole wrote: > In Dennis's Oct 1984 BSTJ paper: "The Evolution of the Unix Operating > System" ( > https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf), > in the last paraphraph of the section entired "Origins" on page 3, he says: > > *"Up to this time all the programs were written using GECOS and files were > transferred to the PDP-7 on paper tape; but once an assembler was completed > the system was able to support itself. Although it was not until well into > 1970 that Brian Kernighan suggested the name 'Unix,' in a somewhat > treacherous pun on 'Multics,' the operating system we know today was > born." * > > > > On Thu, May 21, 2026 at 3:05 PM Arnold Robbins via TUHS > wrote: > > > In > > > > > https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ > > > > It's brought down that some stories credit Peter Neumann with the Unics > > pun on Multics. It's plausible as he as involved in Multics for Bell Labs, > > (apparently) was still around when Ken started working on the PDP-7 in > > 1969-1970, and he had a penchant for puns. > > > > Other histories I've seen credit Brian Kernighan with the naming. When > > I asked BWK some time back, he said he didn't remember. > > > > Doug and/or Ken, do either of you happen to remember definitively? > > > > Thanks, > > > > Arnold > > From tuhs at tuhs.org Fri May 22 06:55:48 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Thu, 21 May 2026 16:55:48 -0400 Subject: [TUHS] terminal types in 1BSD In-Reply-To: <202605210202.64L22V5N047643@ultimate.com> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <20260520230728.7vp7sx6kilms7kbz@illithid> <202605210202.64L22V5N047643@ultimate.com> Message-ID: <202605212055.64LKtm8L072755@ultimate.com> > To bring things firmly back into TUHS territory: In the early 80's I > took a Harvard Extension class, and remember the Harvard Science > Center 11/70 UNIX systems; ISTR them as being v6 based, and terminal > types were all two characters (presumably passed around as two bytes, > without the benefit of environment variables). And that termcap had > two-char aliases as well... Am I remembering this correctly? Answering my own question, looking at: https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/ex-1.1/ex_init.c the initoptions function has: ttyno = ttyn(f); if (ttyno != 'x') { if (hget(ttyno) == 0) isetterm(hsgettype()); } https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/s7/htmpg.c has the hget function to read /etc/htmp: struct htmp { int uid; char home[28]; int ttytype; } hentry; indexed by the ttyno char passed in, and also contains hgethome(), hgetuid() and h(s)gettype functions (depending on whether you want an int, or a string with the two terminal type bytes!) ttyn is a standard library function, present as early as v3: https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man3/ttyn.3 still in assembler in v6: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s3/ttyn.s Further down initoptions calls: uid = getuid() & mask; H = hgethome(); if (uid == 0) strcpy(H, "/"); else if (uid != hgetuid()) return; https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/etc/READ_ME says: November 17, 1977 This directory contains prototype data files for /etc. Htmp is here simply to indicate that it must exist... it can be created via cp /dev/null /etc/htmp chown bin /etc/htmp chmod 644 /etc/htmp The file ttytype should be modified to conform to your configuration, and new entries should be added to ttycap for the terminals which you have. Note that the programs "sethome", "tset" and "ttytype" must be able to write on htmp so they must either be setuid or /etc/htmp must be mode 666 (safe only if you have a completely friendly community of users.) https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/etc/ttycap is the primordial termcap file (each entry is a one-liner): l1|11/10:0:0:? ca|adm3a|3a:0177440:0000332:li#24:co#80:cl=^z:ho=\036:nd=^l:up=^k:am:bs:ca cl|adm3|3:0177440:0000332:li#24:co#80:cl=^z:am:bs bh|beehiveIIIm:0177440:0000330:li#20:co#80:cl=^e^r:ho=^e:nd=^l:up=^k:bs:ca:am:pt cm|datamedia|dm:0177440:0000332:li#24:co#80:cl=^l:am:bs td|decwriter|dw2:0177444:0000332:co#132:bs:os: pd|dtc300s|diablo|dtc:0137446:0000330:if=/usr/lib/tset.dtc_tabs:co#132:hu=\EH:hd=\Eh:up=^z:bs:it:os:pt:pl du|dialup:0:0: cf|fox:0177440:0000332:li#24:co#80:cl=\EK\1\1\1\1:ho=\EH:nd=\EC:up=\EA:am:bs:ca pg|gsi:0137446:0000330:is#1:co#132:hu=\EH:hd=\Eh:up=^z:bs:it:os:pt:pl g0|gt40:0177444:0000332:li#30:co#72:bs:os g2|gt42|42:0177444:0000332:li#40:co#72:bs:os ch|hazeltine|2000:0177440:0000332:bs:ca lh|hp21mx:0:0:? cH|hp2645|2645:0177440:0000332:li#24:co#80:cl=\E&a00c00Y\EJ:ho?:nd=\EC:up=\EA:am:bs:ca:it:ce=\Ek:pt:al=\EL:dl=\EM:ce=\EK:cd=\EJ gk|tek4014:0177444:0040332:co#120:li#56:bs:os:cl=\E^l:is=\E\: ct|teleray:0177440:0000332:co#80:li#24:cl=^l:bs ti|ti700|ti|ti733|7:0151440:0020332:co#80:bs:os t3|teletype|tty|33|35:0157440:0020336:co#72 t7|tty37|37:0115044:0062732:bs:os:hu?:hd?:up? t4|tty43|43:0177444:0000332:bs:os:am:co#132 un|unknown|u:0:0: https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/READ_ME says: The trek game in "trek" uses the rewritten portable library in "portlib". It (and the program tset) were written by Eric Allman whose address is in the trek setup instructions in "trek". Digging further has been delayed by not being able to extract all the cont.a archives in the 1bsd tar file, so I don't yet understand how/when the htentry uid field was set! From tuhs at tuhs.org Fri May 22 07:01:36 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 21 May 2026 21:01:36 +0000 Subject: [TUHS] BRE Grouping in Sed? Message-ID: <07Lb8tqEazxepNt1_ncXqt_qTzcyX6VDhAgT--ptSph3FoNuoM1T9jnIzgEwMv10sXibL5wy-LBWlHaUBg6FQJU6dgLg29Qdy90Qep-ZwdA=@protonmail.com> So I've been playing around with portability testing various bits of software I've written over the years and have run into an interesting scenario. On all modern UNIX-like platforms I've tried, the following is an example sed script and the result I get anywhere I've used it: > $ echo beep | sed 's/b\(..\)p/j\1p/g' > jeep I use group replacement like this all over the place. Well, as part of my experiments, I exported "POSIXLY_CORRECT" on one of my GNU setups, and with this set, GNU sed complains: > sed: warning: using "\(" in the 's' command is not portable POSIX's section on BRE does list these as grouping operators, and indeed trying this in a V7 emulation it also behaves as expected. Is there some historic implementation that this grouping does *not* work in when using BREs (as opposed to -E EREs)? I'm struggling to find where this is documented to cause portability problems, usually my portability check these days is the gaggle of GNU, FreeBSD, macOS, and Solaris with an occasional V7 check when I'm feeling really paranoid...and this checks out on all of those. For the record, in GNU sed this warning is triggered, when POSIXLY_CORRECT, under any s command where an escaped character other than '&', '\\', '[0-9]', '\n', or the separator character ('/' default) is found. Testing this, it'll also balk at, for instance, '\?'. For the record, section 9.3.6 of Base Definitions states: > A subexpression can be defined within a BRE by enclosing it between the character pairs "\(" and "\)". Am I missing something obvious here? Is there some weird but prominent historic sed (and/or BRE implementation) I'm overlooking? Thanks for any insight, searching for this on the web is proving difficult and fruitless. - Matt G. From tuhs at tuhs.org Fri May 22 07:43:18 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 21 May 2026 17:43:18 -0400 Subject: [TUHS] BRE Grouping in Sed? In-Reply-To: <07Lb8tqEazxepNt1_ncXqt_qTzcyX6VDhAgT--ptSph3FoNuoM1T9jnIzgEwMv10sXibL5wy-LBWlHaUBg6FQJU6dgLg29Qdy90Qep-ZwdA=@protonmail.com> References: <07Lb8tqEazxepNt1_ncXqt_qTzcyX6VDhAgT--ptSph3FoNuoM1T9jnIzgEwMv10sXibL5wy-LBWlHaUBg6FQJU6dgLg29Qdy90Qep-ZwdA=@protonmail.com> Message-ID: <98925cbf-2bed-45f5-92bd-491af6b7ad8d@case.edu> On 5/21/26 5:01 PM, segaloco via TUHS wrote: > For the record, in GNU sed this warning is triggered, when POSIXLY_CORRECT, under any s command where an escaped character other than '&', '\\', '[0-9]', '\n', or the separator character ('/' default) is found. Testing this, it'll also balk at, for instance, '\?'. The standard does say: "The meaning of an unescaped immediately followed by any character other than '&', , a digit, , or the delimiter character used for this command, is unspecified." but I think they're referring to the replacement string, not the pattern. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri May 22 08:43:00 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 21 May 2026 18:43:00 -0400 Subject: [TUHS] rsync from minnie? In-Reply-To: <202605212025.64LKPS60043052@freefriends.org> References: <202605212025.64LKPS60043052@freefriends.org> Message-ID: On Thu, May 21, 2026 at 4:25 PM Arnold Robbins via TUHS wrote: > I'm in the US, and trying to rsync from minnie. It's not doing anything, > and when I ping minnie.tuhs.org I get an IPv6 address: > 2600:3c01::2000:a0ff:fead:bc2f > > Any ideas? > > It's not crucial for right now. > > Also, I'll be offline the next two days, but will eventually > see any replies. Try the hostname, `oldminnie.tuhs.org`. Minnie is being replaced/upgraded/transplanted, and transitioned to being solely Warren's personal machine. The TUHS infrastructure is being redone, and will switched to new kit in a couple of months. In the meantime, the system-formerly-known-as-minnie is now `oldminnie` and running most of the TUHS services (web, mail, FTP, and rsync). Sorry, I'm afraid this is a bit vague and I'm not trying to be evasive, it is just that things are sort of in flux and not easily describable just yet. We'll send a proper announcement once everything is up and running in its new home. - Dan C. From tuhs at tuhs.org Fri May 22 08:51:23 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Thu, 21 May 2026 22:51:23 +0000 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: <202605211905.64LJ5Al9033970@freefriends.org> References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> <202605211905.64LJ5Al9033970@freefriends.org> Message-ID: Ken wrote the following to a Redditor earlier this month: On 9 May 2026 at 12:08, Ken Thompson wrote: > unix was named (phonetically) by bwk. > i dont think he ever spelled it, but, since > it was a play on multics, he thought it was > unics. (you can ask him) > > at the time, unix was compiled on the central > computer at bell labs (GE-625) that produced > a PDP-7 paper tape. usually i just ran the tape > and threw it away. when i needed to save a tape, > i wrote "unix" on the tape. it stuck after that. https://www.reddit.com/r/unix/comments/1t826y8/emailed_ken_thompson_about_the_unics_to_unix/ The tape part I hadn't heard before and completes the story. Thalia From tuhs at tuhs.org Fri May 22 09:52:46 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Fri, 22 May 2026 09:52:46 +1000 Subject: [TUHS] Don't use minnie any more (was: rsync from minnie?) In-Reply-To: References: <202605212025.64LKPS60043052@freefriends.org> Message-ID: On Thursday, 21 May 2026 at 18:43:00 -0400, The UNIX Heritage Society wrote: > On Thu, May 21, 2026 at 4:25 PM Arnold Robbins via TUHS wrote: >> I'm in the US, and trying to rsync from minnie. It's not doing anything, >> and when I ping minnie.tuhs.org I get an IPv6 address: >> 2600:3c01::2000:a0ff:fead:bc2f >> >> Any ideas? >> >> It's not crucial for right now. >> >> Also, I'll be offline the next two days, but will eventually >> see any replies. > > Try the hostname, `oldminnie.tuhs.org`. Minnie is being > replaced/upgraded/transplanted, and transitioned to being solely > Warren's personal machine. To add to Dan's reply: minnie is now only Warren's personal machine, and it will never be anything else. "Nothing to be found here". It has been separated from the old minnie (currently oldminnie.tuhs.org). But as the "new" name suggests, oldminnie will probably not last long. You should get all access from tuhs.org (same IP addresses as the current oldminnie), which will remain. > Sorry, I'm afraid this is a bit vague and I'm not trying to be > evasive, it is just that things are sort of in flux and not easily > describable just yet. We'll send a proper announcement once > everything is up and running in its new home. I'm guessing that this will be early next month. 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 22 11:35:06 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 22 May 2026 11:35:06 +1000 Subject: [TUHS] rsync from minnie? In-Reply-To: <202605212025.64LKPS60043052@freefriends.org> References: <202605212025.64LKPS60043052@freefriends.org> Message-ID: On Thu, May 21, 2026 at 04:25:27PM -0400, Arnold Robbins via TUHS wrote: > I'm in the US, and trying to rsync from minnie. It's not doing anything ... > Any ideas? Just a follow to both Dan's and Greg's e-mails. I've been using the same machine, "minnie", as both the TUHS web server and a repository for my personal stuff (e-mails, files etc) since 1994. Now that we have a TUHS team of volunteers, I decided to split my personal stuff away from the TUHS stuff. So now we have a machine called www.tuhs.org (also "oldminnie") for the TUHS stuff, and I now have minnie.tuhs.org for my personal stuff. I thought that we had done the separation quite cleanly, as in "nobody noticed!". I'd forgotten about the TUHS mirrors using rsync :-) So, yes, if the mirrors could replace minnie.tuhs.org with www.tuhs.org, that would be great. I've also just put in a rsync port forward on minnie -> www.tuhs.org for those mirrors that haven't changed yet. This also gives the TUHS team to chance to build a server replacment which brings the OS and applications up to date, and which is _theirs_ and not _mine_! Cheers, Warren From tuhs at tuhs.org Fri May 22 11:45:41 2026 From: tuhs at tuhs.org (Aiden Thomas via TUHS) Date: Fri, 22 May 2026 01:45:41 +0000 Subject: [TUHS] Any good 6502 assembly references? Message-ID: Hello! I'm fairly new here (just got on the mailing list). You guys got me really excited about continuing the legacy of computing. I'm planning out an interpreter onto my website, most likely 6502 based. So if anyone knew any good manuals or open sourced design documents of the 6502 CPU I'd love to hear! I'm also open to other architectures that would be fun to write interpreters for. Thank you so much for your time, Aiden Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 322 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri May 22 11:50:31 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 22 May 2026 11:50:31 +1000 Subject: [TUHS] rsync from minnie? In-Reply-To: References: <202605212025.64LKPS60043052@freefriends.org> Message-ID: On Fri, May 22, 2026 at 11:35:06AM +1000, Warren Toomey via TUHS wrote: > This also gives the TUHS team to chance to build a server replacment > which brings the OS and applications up to date, and which is _theirs_ > and not _mine_! And by "theirs" I mean "ours" :-) I'm not disappearing just yet :-) Cheers, Warren From tuhs at tuhs.org Fri May 22 11:55:47 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Thu, 21 May 2026 21:55:47 -0400 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: References: Message-ID: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> Your favorite search engine will probably find more than enough information. On 5/21/26 21:45, Aiden Thomas via TUHS wrote: > Hello! > I'm fairly new here (just got on the mailing list). You guys got me really excited about continuing the legacy of computing. I'm planning out an interpreter onto my website, most likely 6502 based. So if anyone knew any good manuals or open sourced design documents of the 6502 CPU I'd love to hear! I'm also open to other architectures that would be fun to write interpreters for. > Thank you so much for your time, > Aiden Thomas From tuhs at tuhs.org Fri May 22 12:01:02 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 21 May 2026 22:01:02 -0400 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> <202605211905.64LJ5Al9033970@freefriends.org> Message-ID: Regardless of who cracked the pun, we were all surprised by Ken's x. Doug On Thu, May 21, 2026 at 6:51 PM Thalia Archibald via TUHS wrote: > Ken wrote the following to a Redditor earlier this month: > > On 9 May 2026 at 12:08, Ken Thompson wrote: > > unix was named (phonetically) by bwk. > > i dont think he ever spelled it, but, since > > it was a play on multics, he thought it was > > unics. (you can ask him) > > > > at the time, unix was compiled on the central > > computer at bell labs (GE-625) that produced > > a PDP-7 paper tape. usually i just ran the tape > > and threw it away. when i needed to save a tape, > > i wrote "unix" on the tape. it stuck after that. > > > https://www.reddit.com/r/unix/comments/1t826y8/emailed_ken_thompson_about_the_unics_to_unix/ > > The tape part I hadn't heard before and completes the story. > > Thalia > From tuhs at tuhs.org Fri May 22 12:04:39 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Thu, 21 May 2026 22:04:39 -0400 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> References: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> Message-ID: (My apologies, I hit the wrong key and sent this before I was done. I did not intend to be that terse.) https://archive.org/details/mos_6500_mpu_preliminary_may_1976 https://6502.org/ https://www.cpcwiki.eu/index.php/MOS_6502 https://gunkies.org/wiki/MOS_Technology_6502 http://retro.hansotten.nl/6502-sbc/ There are emulators in github and I'd bet that simh will do that CPU too. Good luck and have fun!  (My OSI single board computer [6502+1kB RAM+1702A EPROM with a keyboard monitor; serial port speed can be adjusted with a trimpot] is somewhere around the house.) - Aron On 5/21/26 21:55, Aron Insinga wrote: > Your favorite search engine will probably find more than enough > information. > > On 5/21/26 21:45, Aiden Thomas via TUHS wrote: >> Hello! >> I'm fairly new here (just got on the mailing list). You guys got me >> really excited about continuing the legacy of computing. I'm planning >> out an interpreter onto my website, most likely 6502 based. So if >> anyone knew any good manuals or open sourced design documents of the >> 6502 CPU I'd love to hear! I'm also open to other architectures that >> would be fun to write interpreters for. >> Thank you so much for your time, >> Aiden Thomas > From tuhs at tuhs.org Fri May 22 12:09:25 2026 From: tuhs at tuhs.org (Alexis via TUHS) Date: Fri, 22 May 2026 12:09:25 +1000 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: (Aiden Thomas via TUHS's message of "Fri, 22 May 2026 01:45:41 +0000") References: Message-ID: <87ecj4b3fu.fsf@gmail.com> Aiden Thomas via TUHS writes: > Hello! > I'm fairly new here (just got on the mailing list). You guys got > me > really excited about continuing the legacy of computing. I'm > planning > out an interpreter onto my website, most likely 6502 based. So > if > anyone knew any good manuals or open sourced design documents of > the > 6502 CPU I'd love to hear! I'm also open to other architectures > that > would be fun to write interpreters for. Well, this list is about _Unix_ history, not about computing history in general, so your request as it stands might be considered off-topic (but i'm not a mod). That said, i'm interested in 6502 myself - as someone who actually used 6502 machines at the time, e.g. the BBC Micro B - and would be interested in a discussion about historic attempts to have a Unix-ish system on the 6502. The Wikipedia page for GeckOS, which is: > a multitasking operating system for MOS 6502, and compatible > processors such as the MOS 6510 ... [and] one of the few > successful attempts to implement a Unix-like operating system on > the 6502 architecture has a section titled "Unix on 6502 architecture": > While early versions of Unix ran on for example early model > PDP-11 > computers that were comparable to Commodore 64 in terms of > memory and > processor performance there were architecture differences in > terms of > lack of a kernel mode, only 3 8-bit registers versus eight > 16-bit > general registers, and a fixed stack. These architectural > limitations > make implementing a Unix-like operating system on the 6502 > challenging. > > The possible non-exhaustive list of other viable Unix-like > implementations on 6502 are LUnix, Asterix (Chris Baird) and ACE > (Chris "Polar" Baird). GeckOS arguably is more complete in some > respects, with ACE being stronger in terms of standard Unix > utilities > but weaker in the operating system area. Alexis. From tuhs at tuhs.org Fri May 22 12:13:53 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Thu, 21 May 2026 22:13:53 -0400 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: References: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> Message-ID: <046098f9-6a2d-479d-a376-0ba3f4c5c31d@insinga.com> p.s. And if you're writing your own simulator, that's cool. Depending on your interests, you may find an assembler to use for it in those places, and/or a monitor or tiny BASIC to put in your simulated machine's memory.  One of the sites below has a list of books, and archive.org may have some too.  [Long ago I wrote an assembler for the RCA CDP1802 microprocessor and a friend wrote a simulator for it.  It's pretty different from the common 8080 or Z80 chips.  And when learning to program, I did both in BASIC-Plus for the DEC PDP-8 minicomputer.] - Aron On 5/21/26 22:04, Aron Insinga wrote: > (My apologies, I hit the wrong key and sent this before I was done. I > did not intend to be that terse.) > > https://archive.org/details/mos_6500_mpu_preliminary_may_1976 > https://6502.org/ > https://www.cpcwiki.eu/index.php/MOS_6502 > https://gunkies.org/wiki/MOS_Technology_6502 > http://retro.hansotten.nl/6502-sbc/ > > There are emulators in github and I'd bet that simh will do that CPU too. > > Good luck and have fun!  (My OSI single board computer [6502+1kB > RAM+1702A EPROM with a keyboard monitor; serial port speed can be > adjusted with a trimpot] is somewhere around the house.) > > - Aron > > > On 5/21/26 21:55, Aron Insinga wrote: >> Your favorite search engine will probably find more than enough >> information. >> >> On 5/21/26 21:45, Aiden Thomas via TUHS wrote: >>> Hello! >>> I'm fairly new here (just got on the mailing list). You guys got me >>> really excited about continuing the legacy of computing. I'm >>> planning out an interpreter onto my website, most likely 6502 based. >>> So if anyone knew any good manuals or open sourced design documents >>> of the 6502 CPU I'd love to hear! I'm also open to other >>> architectures that would be fun to write interpreters for. >>> Thank you so much for your time, >>> Aiden Thomas >> > From tuhs at tuhs.org Fri May 22 13:18:30 2026 From: tuhs at tuhs.org (Aiden Thomas via TUHS) Date: Fri, 22 May 2026 03:18:30 +0000 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: <046098f9-6a2d-479d-a376-0ba3f4c5c31d@insinga.com> References: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> <046098f9-6a2d-479d-a376-0ba3f4c5c31d@insinga.com> Message-ID: On Thu, May 21, 2026 at 10:14 PM, Aron Insinga via TUHS <tuhs at tuhs.org> wrote: p.s. And if you're writing your own simulator, that's cool. Depending on your interests, you may find an assembler to use for it in those places, and/or a monitor or tiny BASIC to put in your simulated machine's memory. One of the sites below has a list of books, and archive.org may have some too. [Long ago I wrote an assembler for the RCA CDP1802 microprocessor and a friend wrote a simulator for it. It's pretty different from the common 8080 or Z80 chips. And when learning to program, I did both in BASIC-Plus for the DEC PDP-8 minicomputer.] - Aron Hi Aron, Thank you for the notes! I'll be looking into these documents for sure. > Your favorite search engine will probably find > more than enough information.You are right about that, I found some good documentation on the ATXMega, just nothing on the 6502 aside from broken hyperlinks. I was hoping to get enough of it emulated to run an older micro kernel Long ago I wrote an assembler for the RCA CDP1802 Oh interesting, I've never heard of that chip, I'll have to find some information on that! Thank you,Aiden Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 322 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri May 22 13:30:59 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 22 May 2026 13:30:59 +1000 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: References: Message-ID: On Fri, May 22, 2026 at 01:45:41AM +0000, Aiden Thomas via TUHS wrote: > I'm planning out an interpreter onto my website, most likely 6502 based. To bring this back to Unix(-ish), way back in 1987 I ported Xinu (a Unix-like kernel) to the 6502: https://minnie.tuhs.org/ftp/pub/apple2/apple2xinu.tar.gz These days, for the 6502, I'd recommend FUZIX instead: https://www.fuzix.org/ And just for fun, a port of xv6 (another Unix-like kernel) I did to the 6809 (with an MMU): https://github.com/DoctorWkt/MMU09 Cheers, Warren From tuhs at tuhs.org Fri May 22 13:33:53 2026 From: tuhs at tuhs.org (Ben Kallus via TUHS) Date: Fri, 22 May 2026 03:33:53 +0000 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: References: <759ef4f3-9e17-44b8-9e66-c324bceedd73@insinga.com> <046098f9-6a2d-479d-a376-0ba3f4c5c31d@insinga.com> Message-ID: A couple years ago I wrote an NES emulator: https://github.com/kenballus/nespump The NES's CPU is basically a 6502 with a few extra things and no BCD mode. Emulating the CPU was the fun part. The graphics part was not as fun :( Game Boy is also pretty fun to emulate. The CPU is a pared-down Z80, more or less. Here's the Game Boy emulator I wrote last year: https://github.com/kenballus/gb Again, the CPU was mostly pretty fun (except the DAA instruction...), but the graphics were annoying. Maybe this is a pattern. I'd be happy to take any questions about 6502 emulation off-list if you have any. -Ben From tuhs at tuhs.org Fri May 22 13:34:11 2026 From: tuhs at tuhs.org (Aiden Thomas via TUHS) Date: Fri, 22 May 2026 03:34:11 +0000 Subject: [TUHS] Fw: Re: Re: Any good 6502 assembly references? In-Reply-To: <5qKLAIb5gcuYA2AkgVHLJAqoVpDSVqOFM0dmnwdsjsUDLIxuUmr2XuVZVQFBGpeYVD9TlkrnNkw-I3rKbOuuhcHtDHZ0dlVn-HxTha0Lmlk=@starprograms.dev> References: <87ecj4b3fu.fsf@gmail.com> <5qKLAIb5gcuYA2AkgVHLJAqoVpDSVqOFM0dmnwdsjsUDLIxuUmr2XuVZVQFBGpeYVD9TlkrnNkw-I3rKbOuuhcHtDHZ0dlVn-HxTha0Lmlk=@starprograms.dev> Message-ID: On Thu, May 21, 2026 at 10:09 PM, Alexis via TUHS < tuhs at tuhs.org> wrote: Aiden Thomas via TUHS <tuhs at tuhs.org> writes: > Hello! > I'm fairly new here (just got on the mailing list). You guys got > me > really excited about continuing the legacy of computing. I'm > planning > out an interpreter onto my website, most likely 6502 based. So > if > anyone knew any good manuals or open sourced design documents of > the > 6502 CPU I'd love to hear! I'm also open to other architectures > that > would be fun to write interpreters for. Well, this list is about _Unix_ history, not about computing history in general, so your request as it stands might be considered off-topic (but i'm not a mod). That said, i'm interested in 6502 myself - as someone who actually used 6502 machines at the time, e.g. the BBC Micro B - and would be interested in a discussion about historic attempts to have a Unix-ish system on the 6502. The Wikipedia page for GeckOS, which is: > a multitasking operating system for MOS 6502, and compatible > processors such as the MOS 6510 ... [and] one of the few > successful attempts to implement a Unix-like operating system on > the 6502 architecture has a section titled "Unix on 6502 architecture": > While early versions of Unix ran on for example early model > PDP-11 > computers that were comparable to Commodore 64 in terms of > memory and > processor performance there were architecture differences in > terms of > lack of a kernel mode, only 3 8-bit registers versus eight > 16-bit > general registers, and a fixed stack. These architectural > limitations > make implementing a Unix-like operating system on the 6502 > challenging. > > The possible non-exhaustive list of other viable Unix-like > implementations on 6502 are LUnix, Asterix (Chris Baird) and ACE > (Chris "Polar" Baird). GeckOS arguably is more complete in > respects, with ACE being stronger in terms of standard Unix > utilities > but weaker in the operating system area. Alexis. the BBC Micro B I remember that family of computer, Elite was such a great game to deconstruct. Really showed how you can get around a lot of limitations of the hardware with ingenuity. Do you remember if the BBC Micro ever got flashed with a POSIX compliant OS? history in general, so your request as it stands might be considered off-topic (but i'm not a mod) Thank goodness! In seriousness, I'll be more careful about how I word my messages here. I was hoping to eventually emulate an older Unix system to better understand its workings, and the creators design decisions. Versus what the kernel book I have has as the standards in 2011. (college never really went into that) Thank you for the OS's I can hopefully use in the future! Aiden Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 322 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri May 22 13:46:26 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 22 May 2026 03:46:26 +0000 Subject: [TUHS] UNIX 6502 General (was: Any good 6502 assembly references?) Message-ID: Quoteless reply to just spur some UNIXx6502 discussion. I've inquired about UNIX history re: 6502 here before and the general vibe I got was that there just wasn't as much UNIX stuff going on in the 6502 ecosystem vs Z80. Neither have the full set of features to really support UNIX as originally designed on the PDP-11. Indeed in BTL, the Intel 8080, Z80, and MAC-8 were the most common 8-bits. I don't recall seeing any 6502 stuff in BTL literature I've read, but I think some labs tinkered with its ancestor the M6800. [1] is a fantastic resource on what microprocessor use at BTL looked like in the thick of the BTL UNIX period. BSTJ is also littered with articles describing various inventions based on microprocessors (both internal BellMAC stuff and well known CPUs). Now, fast forwarding to the present day, the LUnix (yes that is spelled right) project has been ported to, among others, the NES, a (roughly) 6502-based platform. There are many SDKs, but among them, the cc65 suite in particular is quite UNIX-y, featuring separate compilation, assembly, and linking utilities with semantics comparable to UNIX. However, word of warning: cc65 is uncanny valley, there are a lot of similarities to, say, GNU binutils, but subtle differences like ".export" rather than ".globl", some label differences in linker scripting, and cheap local labels that are positional rather than numerical (hard to explain briefly, see relevant documentation if really curious). I have personally been focused on developing tools and techniques based in canonical UNIX practices concerning both 6502 development and disassembly/reverse engineering. If you're looking to talk more 6502 general, I'm happy to carry on personally (or I also recommend the sister COFF mailing list). But yeah joining the chorus that there isn't anything particularly UNIX-history-ish with general 6502 simulation so probably not the right venue. Shoot me a reply personally though if you're trying to talk 6502. - Matt G. [1] - https://bitsavers.org/pdf/westernElectric/BTL_WE_Microcomputer_Symposium_Dec76.pdf From tuhs at tuhs.org Fri May 22 15:05:54 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Fri, 22 May 2026 05:05:54 +0000 Subject: [TUHS] So who named Unix? [was multicians] Peter Neumann has died] In-Reply-To: (Thalia Archibald via TUHS's message of "Thu, 21 May 2026 22:51:23 +0000") References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> <202605211905.64LJ5Al9033970@freefriends.org> Message-ID: <7wlddcvxsd.fsf@junk.nocrew.org> Thalia Archibald wrote: > https://www.reddit.com/r/unix/comments/1t826y8/emailed_ken_thompson_about_the_unics_to_unix/ That's a link to a Reddit post that contains a screenshot of an email thread. Sic transit. For the record, I will type it in and send it to TUHS. ---------------------------------------------------------------------- Subject: UNICS to UNIX name change Hello Ken. Firstly, I really admire your contributions towards the UNIX/Linux community. Without you, all of what we have now would not have been possible. I just have this burning question. I am aware of "UNICS" eventually being changed to "UNIX". But what a lot of us are wondering is, why did this name change occur? As far as I know, the exact reason for this change is has never been officially confirmed. I hope you, as one of the founding fathers, can enlighten us. Thank you so much for everything you've done, ---------------------------------------------------------------------- >From Ken Thompson To Date 9 Man 2026, 12:03 am unix was named (phonetically) by bwk. i dont think he ever spelled it, but, since it was a play on multics, he thought it was unics. (you can ask him) at the time, unix was compiled on the central computer at bell labs (GE-635) that produced a PDP-7 paper tape. ususally i just ran the tape and threw it away. when i needed to save a tape, i wrote "unix" on the tape. it stuck after that. ---------------------------------------------------------------------- Hi Ken Thank you so much for responding!! That's very interesting. Is it okay if I share this on the internet, or would you rather keep this private? Thanks in advance ---------------------------------------------------------------------- sure From tuhs at tuhs.org Fri May 22 22:38:37 2026 From: tuhs at tuhs.org (Andrew Lynch via TUHS) Date: Fri, 22 May 2026 12:38:37 +0000 (UTC) Subject: [TUHS] Vintage Unix on NS32016 board homebrew projects References: <344372977.4473558.1779453517868.ref@mail.yahoo.com> Message-ID: <344372977.4473558.1779453517868@mail.yahoo.com> Several years ago, I started a couple of NS32016 homebrew projects based on recreations of late 1980's amateur Unix computers.  However, I've run out of time and energy to complete them, and a practical retirement is years away.  I don't see any path to get to finish these projects myself barring some miracle, so I am offering them up in case someone wants to take them on. The PCB designs are KiCAD recreations of the original projects.  No attempt at building and debugging them yet however since they were working for the original authors, I think it is feasible with some effort they will run.  I advise if you are considering taking on one or both of these projects to start gathering parts soonest since the NS32016 and associated support chips were never particularly common and supply is fading away with time. Please note, I am not suggesting these would be easy projects or "turnkey" because a lot of effort would be required to build, test, debug, and ultimately get software running.  Definitely a hobby project for someone or someone(s) with plenty of time and skill to finish.  PD32 (Micro Cornicopia article claims System V capable, but I am skeptical)  https://hackaday.io/project/189965-isa-bus-slave-ns32016-processor-board Bruce Culbertson (documentation claims there is a Minix or at least a start)  GitHub - lynchaj/NS32016-BC: Bruce Culbertson NS32016 Single Board Computer From tuhs at tuhs.org Fri May 22 22:42:19 2026 From: tuhs at tuhs.org (Andrew Lynch via TUHS) Date: Fri, 22 May 2026 12:42:19 +0000 (UTC) Subject: [TUHS] Vintage Unix on NS32016 board homebrew projects In-Reply-To: <344372977.4473558.1779453517868@mail.yahoo.com> References: <344372977.4473558.1779453517868.ref@mail.yahoo.com> <344372977.4473558.1779453517868@mail.yahoo.com> Message-ID: <1227765329.4483617.1779453739776@mail.yahoo.com> NS32016-BC URL got munged:  https://github.com/lynchaj/NS32016-BC On Friday, May 22, 2026 at 08:38:48 AM EDT, Andrew Lynch via TUHS wrote: Several years ago, I started a couple of NS32016 homebrew projects based on recreations of late 1980's amateur Unix computers.  However, I've run out of time and energy to complete them, and a practical retirement is years away.  I don't see any path to get to finish these projects myself barring some miracle, so I am offering them up in case someone wants to take them on. The PCB designs are KiCAD recreations of the original projects.  No attempt at building and debugging them yet however since they were working for the original authors, I think it is feasible with some effort they will run.  I advise if you are considering taking on one or both of these projects to start gathering parts soonest since the NS32016 and associated support chips were never particularly common and supply is fading away with time. Please note, I am not suggesting these would be easy projects or "turnkey" because a lot of effort would be required to build, test, debug, and ultimately get software running.  Definitely a hobby project for someone or someone(s) with plenty of time and skill to finish.  PD32 (Micro Cornicopia article claims System V capable, but I am skeptical)  https://hackaday.io/project/189965-isa-bus-slave-ns32016-processor-board Bruce Culbertson (documentation claims there is a Minix or at least a start)  GitHub - lynchaj/NS32016-BC: Bruce Culbertson NS32016 Single Board Computer From tuhs at tuhs.org Fri May 22 22:56:30 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 22 May 2026 07:56:30 -0500 Subject: [TUHS] Any good 6502 assembly references? In-Reply-To: References: Message-ID: Hi Aron, On how it relates to unix, that's a bit of a stretch, but I'll offer this - in order to understand the v6 and v7 source code and Lions book, I spent 6 months with the 6502 and walked away with a much, much clearer understanding of the research unixes after returning :). For refs, the manuals are hard to beat: https://pickledlightprojects.com/documents/ Look for MCS6500 Hardware Manual and MCS6500 Programming Manual fro high res, reproduced versions of the original manuals. For lists of books and other resources: http://retro.hansotten.nl/6502-sbc/ https://6502.org/ My favorite books for doing stuff with it involve either the PAL-1 (a kim 1-alike) kit, or an apple iie emulation (on linux, I run apple iie via applewin, there are others): https://ct6502.org/product/assembly-lines-the-complete-book/ and Don Lancaster's Machine Lang Programming I & II if you're really new to how moving bits around a micro works: https://www.tinaja.com/ebksamp1old.shtml I put together stuff on this kinda thing, too: https://decuser.github.io/tags/pal-1/ https://decuser.github.io/tags/assembly/ https://www.youtube.com/playlist?list=PL_z8XUfqFSXH7jHealImDooWhO9IzcdOV On 5/21/26 20:45, Aiden Thomas via TUHS wrote: > Hello! > I'm fairly new here (just got on the mailing list). You guys got me really excited about continuing the legacy of computing. I'm planning out an interpreter onto my website, most likely 6502 based. So if anyone knew any good manuals or open sourced design documents of the 6502 CPU I'd love to hear! I'm also open to other architectures that would be fun to write interpreters for. > Thank you so much for your time, > Aiden Thomas From tuhs at tuhs.org Sat May 23 05:55:20 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Fri, 22 May 2026 12:55:20 -0700 Subject: [TUHS] Curly braces: An evolution of UNIX and C In-Reply-To: <20260521002322.GB26412@mcvoy.com> References: <99BFEB3F-DC45-4639-9A2E-2D84C252FB19@archibald.dev> <20260520220415.A3F9310BCF054@ary.qy> <00fbfb06-44a0-ff77-ff58-1b2062d5c500@taugh.com> <20260521002322.GB26412@mcvoy.com> Message-ID: Larry McVoy via TUHS writes: > I don't have a lot to add to this other than there was some terminal, I think > a VT-something, that had the standard 80x24 but it had a 25th line that was > the status line. I think BSD had a Ctrl-T that dug info out of the kernel > and displayed it on that line. That sounds a lot like the 'sysline' command. It took over the last screen line and displayed the 1/5/15 load averages, time, number of users logged in, and announced who had just logged in or out. It worked on more than VT terminals. If the termcap entry provided enough glue to allow manupulating the active screen area, sysline could co-opt the bottom line and use it. It ran happily on my Ann Arbor Ambassador terminal in 132x66 mode. --lyndon From tuhs at tuhs.org Sat May 23 06:15:49 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Fri, 22 May 2026 13:15:49 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain Message-ID: I was searching troff.org for a couple of papers. These are behind links to cm.bell-labs.com which now points to some VPN provider. Does anyone know if Ralph is still maintaining that page? It says to contact him with updates, but lists no contact information. --lyndon From tuhs at tuhs.org Sat May 23 06:19:29 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Fri, 22 May 2026 13:19:29 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: Message-ID: More specifically, it's cm.bell-labs.com that points to the vpn service. bell-labs.com still gets you to Nokia's web site. --lyndon From tuhs at tuhs.org Sat May 23 09:07:39 2026 From: tuhs at tuhs.org (Ralph Corderoy via TUHS) Date: Sat, 23 May 2026 00:07:39 +0100 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: Message-ID: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> Hi Lyndon, > Does anyone know if Ralph is still maintaining that page? Yes, I'm not dead yet. I'll reply more off-list. -- Cheers, Ralph. From tuhs at tuhs.org Sat May 23 11:42:51 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Fri, 22 May 2026 18:42:51 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> Message-ID: <20260523014251.GC14835@mcvoy.com> I think that LaTex won because of marketing. I'm a huge troff fan, the BitKeeper logo was done in troff, I've done a lot of good things in troff, I modernized the -ms macros to look better and they did. All that said, my nerd son has gone all in on LaTex and he makes stuff look good. I think LaTex won, I'm not happy about it but it is what it is. I fully support anything that makes troff better. Back when my first son was born, 2019, I was program committee chair for Linux Expo, which was not a big deal, it meant that I formatted all the papers into a book. I tried to get people to do troff, only a few did, but they said "holy shit, it's so fast". I think LaTex does multiple passes so they can do a table of contents, troff was faster. But even though I had some sucess at pushing people to troff, it was not the winner. I wish it was. On Sat, May 23, 2026 at 12:07:39AM +0100, Ralph Corderoy via TUHS wrote: > Hi Lyndon, > > > Does anyone know if Ralph is still maintaining that page? > > Yes, I'm not dead yet. I'll reply more off-list. > > -- > Cheers, Ralph. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat May 23 13:06:48 2026 From: tuhs at tuhs.org (Reese Johnson via TUHS) Date: Fri, 22 May 2026 23:06:48 -0400 Subject: [TUHS] Control-T in UNIX In-Reply-To: <202605211923.64LJN281035690@freefriends.org> References: <202605211923.64LJN281035690@freefriends.org> Message-ID: Wow! Thank you so much. I'm a bit younger but I really love Unix. I am located in Georgia too. I use ^T all the time still on FreeBSD. I had no idea GT had something to do with it. Nice to meet you all. This list is so amazing. Thanks Reese KN4NTU 73 On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > It was indeed posted to USENET, but didn't (IIRC) make it into the > official 4.3 BSD release. > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > put it into 4.3BSD + Mt. Xinu at Emory. > > At GT, I remember a professor who came from MIT being pleasantly > surprised to learn that we had ^T on the vax. :-) > > Rich Salz via TUHS wrote: > > > My recollection is that Chris Torek at University of Maryland added control > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > posted to Usenet which is where I read about it > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > that did have control-T. > > > Mike added that to our kernel (llisting all the processes running on the > > > terminal) so he could get some feedback on what his tweaks were doing. > > > > > > -Ron > > > > > > From tuhs at tuhs.org Sat May 23 13:29:03 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 22 May 2026 21:29:03 -0600 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: <202605211923.64LJN281035690@freefriends.org> Message-ID: ^T was in 4.3Reno and NET/2. Or rather, CSTATUS was, as was the stty status command. It looks like it wasn't on by default in the BSD distributions. It wasn't in 4.3BSD or 4.3Tahoe though. However, having said that, I remember using ^T on the VAX 11/750 we had at the New Mexico Tech CS department that was running a 4.3BSD with a hacked kernel (^T from USENET was one of the patches). Warner On Fri, May 22, 2026 at 9:06 PM Reese Johnson via TUHS wrote: > Wow! Thank you so much. I'm a bit younger but I really love Unix. I am > located in Georgia too. I use ^T all the time still on FreeBSD. I had no > idea GT had something to do with it. Nice to meet you all. This list is so > amazing. > > Thanks > Reese KN4NTU > 73 > > On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > > It was indeed posted to USENET, but didn't (IIRC) make it into the > > official 4.3 BSD release. > > > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > > put it into 4.3BSD + Mt. Xinu at Emory. > > > > At GT, I remember a professor who came from MIT being pleasantly > > surprised to learn that we had ^T on the vax. :-) > > > > Rich Salz via TUHS wrote: > > > > > My recollection is that Chris Torek at University of Maryland added > control > > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > > posted to Usenet which is where I read about it > > > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS > wrote: > > > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > > that did have control-T. > > > > Mike added that to our kernel (llisting all the processes running on > the > > > > terminal) so he could get some feedback on what his tweaks were > doing. > > > > > > > > -Ron > > > > > > > > > From tuhs at tuhs.org Sat May 23 15:08:56 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sat, 23 May 2026 05:08:56 +0000 Subject: [TUHS] Control-T in UNIX In-Reply-To: (Warner Losh via TUHS's message of "Fri, 22 May 2026 21:29:03 -0600") References: <202605211923.64LJN281035690@freefriends.org> Message-ID: <7wcxymww47.fsf@junk.nocrew.org> Warner Losh via TUHS writes: > ^T was in 4.3Reno and NET/2. Maybe ^T was independently brought in from various places running TOPS-10, TOPS-20, TENEX, VMS, RSTS/E, etc? From tuhs at tuhs.org Sat May 23 15:17:32 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 22 May 2026 23:17:32 -0600 Subject: [TUHS] Control-T in UNIX In-Reply-To: <7wcxymww47.fsf@junk.nocrew.org> References: <202605211923.64LJN281035690@freefriends.org> <7wcxymww47.fsf@junk.nocrew.org> Message-ID: On Fri, May 22, 2026, 11:08 PM Lars Brinkhoff wrote: > Warner Losh via TUHS writes: > > ^T was in 4.3Reno and NET/2. > > Maybe ^T was independently brought in from various places running > TOPS-10, TOPS-20, TENEX, VMS, RSTS/E, etc? > I'm sure it was. I was just reporting where it entered the BSD source stream. I know lots of prior art for ^T for quick status of the current job. I also have a vague memory of a few different versions of patches posted to USENET back in the day and I don't know if they are what went into BSD or not. I've not gone that far down the rabit hole. Warner > From tuhs at tuhs.org Sat May 23 15:44:01 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 23 May 2026 15:44:01 +1000 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: <202605211923.64LJN281035690@freefriends.org> Message-ID: Mark Kampe's UCLA terminal driver from 1976 had CSTATUS Code was previously available at https://github.com/markkampe/ucla_tty but the repository is now gone (I have it locally). tty.h:#define CSTATUS 024 /* ^t, the default system status character */ Derived versions show up in the UCLA DSU kernel and the QMC terminal driver in the usenix 80.1 and spencer uk1 tapes. On Fri, May 22, 2026 at 09:29:03PM -0600, Warner Losh via TUHS wrote: > ^T was in 4.3Reno and NET/2. Or rather, CSTATUS was, as was the stty status > command. It looks like it wasn't on by default in the BSD distributions. It > wasn't in 4.3BSD or 4.3Tahoe though. > > However, having said that, I remember using ^T on the VAX 11/750 we had at > the New Mexico Tech CS department that was running a 4.3BSD with a hacked > kernel (^T from USENET was one of the patches). > > Warner > > On Fri, May 22, 2026 at 9:06 PM Reese Johnson via TUHS > wrote: > > > Wow! Thank you so much. I'm a bit younger but I really love Unix. I am > > located in Georgia too. I use ^T all the time still on FreeBSD. I had no > > idea GT had something to do with it. Nice to meet you all. This list is so > > amazing. > > > > Thanks > > Reese KN4NTU > > 73 > > > > On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > > > It was indeed posted to USENET, but didn't (IIRC) make it into the > > > official 4.3 BSD release. > > > > > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > > > put it into 4.3BSD + Mt. Xinu at Emory. > > > > > > At GT, I remember a professor who came from MIT being pleasantly > > > surprised to learn that we had ^T on the vax. :-) > > > > > > Rich Salz via TUHS wrote: > > > > > > > My recollection is that Chris Torek at University of Maryland added > > control > > > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > > > posted to Usenet which is where I read about it > > > > > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS > > wrote: > > > > > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > > > that did have control-T. > > > > > Mike added that to our kernel (llisting all the processes running on > > the > > > > > terminal) so he could get some feedback on what his tweaks were > > doing. > > > > > > > > > > -Ron > > > > > > > > > > > > From tuhs at tuhs.org Sat May 23 18:00:28 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 23 May 2026 08:00:28 +0000 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523014251.GC14835@mcvoy.com> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> Message-ID: On Friday, May 22nd, 2026 at 18:42, Larry McVoy via TUHS wrote: > I fully support anything that makes troff better. This. The TeXbook not only taught me TeX, it made me a better troff user. - Matt G. From tuhs at tuhs.org Sat May 23 19:02:43 2026 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sat, 23 May 2026 19:02:43 +1000 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? Message-ID: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> I'm not criticising MULTICS, I couldn't have come close to what they did: with what they had, PL/1 & GE-645 hardware, they came up with a working design that had decades of use including 'Security' with many features, like file systems, now standard. They started with very large budgets, many people and 'stretch' goals - always red flags for projects. Perhaps they suffered "Second System" effect and over-designed it - but this isn't a critique, just a hypothetical on the impact of language choice. The project delivered, it was far better software than IBM OS/360 and gave credence to high-level language kernels & designing for security. IBM was first to prove Software Quality was secondary to Marketing for product sales. Ken & Dennis spent years coming up with C, slowly evolving it to meet their very precise needs: small, efficient & performant. Everyone but MULTICS & Burroughs opted for assembler, if they even built a full O/S, not just program loaders. Thinking of rewriting the kernel in non-assembler was a major invention - a significant research outcome. I don't believe we'd have had C without Unix, especially rewriting the kernel. Doug worked on the PL/1 compiler, from memory, and certainly on MULTICS and might have a view: could something like C have improved MULTICS or helped it's success in the marketplace? The team & project structure of MULTICS was quite formal - full designs were to be submitted before coding began, opposite to Ken & Dennis' rapid iterative development [ not to say they didn't design carefully ]. Hamming's "Research is what I'm doing when I don't know what I'm doing" matches this style perfectly, IMO. After SEL4 / L4.verified, do we still think "You can't write a 'secure' kernel in C"? The Verification was a huge effort, far more than writing the kernel. Perhaps another language would've lessened the effort, though at what cost? We can't change history, the MULTICS experience & the Bell Labs management reaction was necessary for Unix to begin. Doing kernels on tiny machines forced a very compact, crisp language design, which was then tried 'everywhere', working incredibly well. Turned out to be a perfect fit for the next generation of small computing: PC's. ============ The only reasonable quality comment I found on the question: Schneier: The Multics Operating System [ 2007 ] - minimal post, lots of comments Linked to: Karger & Schell, 2002 Thirty Years Later: Lessons from the Multics Security Evaluation Several Multicians / Multics admins responded: Ian Mason Tom Van Vleck Jim Lippard handle 'ranz' signed as 'ear' There's a link to Myths about Multics ============ There's a Quora thread on the reverse question, what if Unix was built in PL/1, with Multics mentioned in the Q and some answers. The longest, most complete answer by their Bot [ 611 lines, 4,000 wds ], who's posts have no permalink :( No idea what the AI scrapped to come up with that response, there's a lot of Unix material to use. Google's AI used this answer as the basis for its answer on "Multics & C" :) Why was UNIX written in C instead of PL/1? Multics was written in PL/1 which is equally capable and was more mainstream than C. =========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From tuhs at tuhs.org Sat May 23 21:26:15 2026 From: tuhs at tuhs.org (Paul Manno via TUHS) Date: Sat, 23 May 2026 07:26:15 -0400 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: <202605211923.64LJN281035690@freefriends.org> Message-ID: Hello Reese, I think you’ll find a large collection of UNIX experiences in Georgia clustered around GT. I was one of those early users / admins who installed v5 (not system 5) Bell Labs UNIX on PDP 11s receiving the tape directly from Ken Thompson. I’m still good friends with Arnold and many others living and those sadly gone but memories and stories still happily linger. If you can find a copy, you might find it interesting reading Peter Salus’s book “A Quarter Century of Unix” still on Amazon. You may even find some other interesting projects done at GT. ;-) Congrats on the ham radio license too! Paul KG4UVU On Fri, May 22, 2026 at 23:06 Reese Johnson via TUHS wrote: > Wow! Thank you so much. I'm a bit younger but I really love Unix. I am > located in Georgia too. I use ^T all the time still on FreeBSD. I had no > idea GT had something to do with it. Nice to meet you all. This list is so > amazing. > > Thanks > Reese KN4NTU > 73 > > On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > > It was indeed posted to USENET, but didn't (IIRC) make it into the > > official 4.3 BSD release. > > > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > > put it into 4.3BSD + Mt. Xinu at Emory. > > > > At GT, I remember a professor who came from MIT being pleasantly > > surprised to learn that we had ^T on the vax. :-) > > > > Rich Salz via TUHS wrote: > > > > > My recollection is that Chris Torek at University of Maryland added > control > > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > > posted to Usenet which is where I read about it > > > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS > wrote: > > > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > > that did have control-T. > > > > Mike added that to our kernel (llisting all the processes running on > the > > > > terminal) so he could get some feedback on what his tweaks were > doing. > > > > > > > > -Ron > > > > > > > > > From tuhs at tuhs.org Sun May 24 00:12:25 2026 From: tuhs at tuhs.org (Theodore Tso via TUHS) Date: Sat, 23 May 2026 10:12:25 -0400 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523014251.GC14835@mcvoy.com> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> Message-ID: <20260523141225.GC18663@macsyma-wired.lan> On Fri, May 22, 2026 at 06:42:51PM -0700, Larry McVoy via TUHS wrote: > I think that LaTex won because of marketing. I'm a huge troff fan, the > BitKeeper logo was done in troff, I've done a lot of good things in troff, > I modernized the -ms macros to look better and they did. I'm sure a lot of it is what you're used to, but I think many people found: \[ s = \sqrt{\frac{\sum_{i=1}^N (x_i - \bar{x})^2}{N - 1}} \] simpler than: .EQ s = sqrt { { sum from i=1 to N ( x sub i - x bar ) sup 2 } over { N - 1 } } .EN I suspect that people also found it simpler to right macros in TeX/LaTex compared to troff. For example. consider: \def\highlight#1{\bf #1} This allows you to write something like: This is \highlight{important} where important will be bolded. The rough equivalent in groff would be something like .DE HIGHLIGHT \fB\\$1\fR .. And: This is .HIGHLIGHT important And of course, in classical troff macro identifiers could only be two characters, which did macro packages no favors in terms of readability.... I don't think it's say that LaTeX one out over troff just because of "marketing". - Ted From tuhs at tuhs.org Sun May 24 00:32:49 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Sat, 23 May 2026 07:32:49 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523141225.GC18663@macsyma-wired.lan> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> Message-ID: <20260523143249.GE14835@mcvoy.com> On Sat, May 23, 2026 at 10:12:25AM -0400, Theodore Tso wrote: > On Fri, May 22, 2026 at 06:42:51PM -0700, Larry McVoy via TUHS wrote: > > I think that LaTex won because of marketing. I'm a huge troff fan, the > > BitKeeper logo was done in troff, I've done a lot of good things in troff, > > I modernized the -ms macros to look better and they did. > > I'm sure a lot of it is what you're used to, but I think many people found: > > \[ s = \sqrt{\frac{\sum_{i=1}^N (x_i - \bar{x})^2}{N - 1}} \] > > simpler than: > > .EQ > s = sqrt { { sum from i=1 to N ( x sub i - x bar ) sup 2 } over { N - 1 } } > .EN Maybe it's my history but I find the troff version much easier to read. I like pic(1) and it reads a lot like that. Part of the beauty of pic is that it was invented when getting a print out was likely an over night thing. And there were no bit mapped displays so you had to be able to look at the code and imagine it in your brain. If you couldn't you were in for a long slow slog before you got things right. > I suspect that people also found it simpler to right macros in > TeX/LaTex compared to troff. For example. consider: > > \def\highlight#1{\bf #1} > > This allows you to write something like: > > This is \highlight{important} > > where important will be bolded. > > The rough equivalent in groff would be something like > > .DE HIGHLIGHT > \fB\\$1\fR > .. > > And: > > This is > .HIGHLIGHT important Again, I like the troff one better. It's probably because I'm a source management person and the troff thing of starting a macro on a new line means you break up the text. LaTex lets you make the whole document in one line if you like, and that is a nightmare for version control. > I don't think it's say that LaTeX one out over troff just because of > "marketing". I shouldn't have said marketing, that's not quite it. For a long time, the troff documentation was locked up. I had it in paper form because UW-Madison made me buy it. But I couldn't make a copy and hand it to someone because $LICENSES. I think that gave an opening to LaTex and LaTex took it. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sun May 24 00:49:27 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Sat, 23 May 2026 08:49:27 -0600 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523141225.GC18663@macsyma-wired.lan> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> Message-ID: On Sat, May 23, 2026, 8:13 AM Theodore Tso via TUHS wrote: > On Fri, May 22, 2026 at 06:42:51PM -0700, Larry McVoy via TUHS wrote: > > I think that LaTex won because of marketing. I'm a huge troff fan, the > > BitKeeper logo was done in troff, I've done a lot of good things in > troff, > > I modernized the -ms macros to look better and they did. > > I'm sure a lot of it is what you're used to, but I think many people found: > > \[ s = \sqrt{\frac{\sum_{i=1}^N (x_i - \bar{x})^2}{N - 1}} \] > > simpler than: > > .EQ > s = sqrt { { sum from i=1 to N ( x sub i - x bar ) sup 2 } over { N - 1 } } > .EN > > > I suspect that people also found it simpler to right macros in > TeX/LaTex compared to troff. For example. consider: > > \def\highlight#1{\bf #1} > > This allows you to write something like: > > This is \highlight{important} > > where important will be bolded. > > The rough equivalent in groff would be something like > > .DE HIGHLIGHT > \fB\\$1\fR > .. > > And: > > This is > .HIGHLIGHT important > > And of course, in classical troff macro identifiers could only be two > characters, which did macro packages no favors in terms of > readability.... > > I don't think it's say that LaTeX one out over troff just because of > "marketing". > Two letter macros was the main reason I jumped to TeX... it was impossible to do commplex thongs that you could pick back up later. TeX is a n eldrige horror to write macros for (until it clicks), but the resulting docs are easier to come back to later (at least for LaTeX). And essier to share. Raw TeX isn't why LaTeX won. It was the ease you can pull in dozens of packages to tweak everything in document. Troff can't do that without importing .eps files created outside the tool, making Makefiles a lot more complex. I'm working on the next edition of The Design and Implementation of FreeBSD and we are converting from troff to LaTex and the crazy hoops you have to jump through are somewhat easier in LaTeX... but not without it's own headaches. So I'd frame TeX as winning for much the same reason as python, pearl or rust winning: they all have add-in packages that are easy to mix and match in a relatively seamless way. Troff has never had more than a few nacro packages and aux tools for its pipeline. And many of those were mix and match from here and there rather than cpan mumble. Warner - Ted > From tuhs at tuhs.org Sun May 24 01:33:37 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 23 May 2026 08:33:37 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> Message-ID: On May 23, 2026, at 7:49 AM, Warner Losh via TUHS wrote: > > working on the next edition of The Design and Implementation of FreeBSD and > we are converting from troff to LaTex and the crazy hoops you have to jump > through are somewhat easier in LaTeX... but not without it's own headaches. Great! > So I'd frame TeX as winning for much the same reason as python, pearl or > rust winning: they all have add-in packages that are easy to mix and match > in a relatively seamless way. Troff has never had more than a few nacro > packages and aux tools for its pipeline. And many of those were mix and > match from here and there rather than cpan mumble. IMHO it is more than that. - public domain from the get go but tight quality control - behaves the same way on any machine/arch - device independent from the get go - more flexible - thoroughly documented - superior at typesetting mathematics - a simple base model (boxes and glue) - better at typesetting non-western languages - latex was simple enough for articles, tech reports and such - high extensible (which is why there are so many packages) - the output is far less opinionated than troff (troff documents have a particular "look" -- may be I haven't seen enough samples). - a responsive author who paid up for every reported bug! etc. Larry mentioned you can write a whole article in one line using LaTeX but nobody does that - just as nobody really writes a C program in one line (except for IOCCC)! Étienne Ghys puts Knuth in the company of Gutenburg, Pacioli, Da Vinci. Only time will tell but we can be sure that a Tex/LaTeX document created today will still produce the same output 100 years from now. https://tex.stackexchange.com/questions/1319/showcase-of-beautiful-typography-done-in-tex-friends https://tug.org/texshowcase/ Ghys - The Shape of Letters: From Leonardo Da Vinci to Donald Knuth https://www.youtube.com/watch?v=1OIxzewWilc From tuhs at tuhs.org Sun May 24 01:44:13 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Sat, 23 May 2026 11:44:13 -0400 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523143249.GE14835@mcvoy.com> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> <20260523143249.GE14835@mcvoy.com> Message-ID: The text-block architecture of Tex (not Latex, which is just a macro package with a nice manual) beats the line-oriented architecture of troff by supporting recursion. You can embed math in pictures in tables to any depth in any combination in Tex, but not in troff. In math, Tex's representations of sub and sup are a definite improvement, as is its representation of matrices--directly rather than transposed. Eqn is otherwise much cleaner and easier to read than Tex's backslash-strewn style, not least because eqn matches the spoken language of math. Who would utter, "frac of a b" in preference to "a over b"? And pic is beyond compare (though afflicted with the nesting issue I mentioned at the outset). Finally, Tex's "interactive" interface and execution-time chatter are awful. Roughly speaking, Tex cleaned up the architecture but botched the aesthetics. Doug On Sat, May 23, 2026 at 10:33 AM Larry McVoy via TUHS wrote: > On Sat, May 23, 2026 at 10:12:25AM -0400, Theodore Tso wrote: > > On Fri, May 22, 2026 at 06:42:51PM -0700, Larry McVoy via TUHS wrote: > > > I think that LaTex won because of marketing. I'm a huge troff fan, the > > > BitKeeper logo was done in troff, I've done a lot of good things in > troff, > > > I modernized the -ms macros to look better and they did. > > > > I'm sure a lot of it is what you're used to, but I think many people > found: > > > > \[ s = \sqrt{\frac{\sum_{i=1}^N (x_i - \bar{x})^2}{N - 1}} \] > > > > simpler than: > > > > .EQ > > s = sqrt { { sum from i=1 to N ( x sub i - x bar ) sup 2 } over { N - 1 > } } > > .EN > > Maybe it's my history but I find the troff version much easier to read. > I like pic(1) and it reads a lot like that. > > Part of the beauty of pic is that it was invented when getting a print out > was likely an over night thing. And there were no bit mapped displays so > you had to be able to look at the code and imagine it in your brain. If > you couldn't you were in for a long slow slog before you got things right. > > > I suspect that people also found it simpler to right macros in > > TeX/LaTex compared to troff. For example. consider: > > > > \def\highlight#1{\bf #1} > > > > This allows you to write something like: > > > > This is \highlight{important} > > > > where important will be bolded. > > > > The rough equivalent in groff would be something like > > > > .DE HIGHLIGHT > > \fB\\$1\fR > > .. > > > > And: > > > > This is > > .HIGHLIGHT important > > Again, I like the troff one better. It's probably because I'm a source > management person and the troff thing of starting a macro on a new line > means you break up the text. LaTex lets you make the whole document in > one line if you like, and that is a nightmare for version control. > > > I don't think it's say that LaTeX one out over troff just because of > > "marketing". > > I shouldn't have said marketing, that's not quite it. For a long time, > the troff documentation was locked up. I had it in paper form because > UW-Madison made me buy it. But I couldn't make a copy and hand it to > someone because $LICENSES. I think that gave an opening to LaTex and > LaTex took it. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Sun May 24 03:26:52 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Sat, 23 May 2026 17:26:52 +0000 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523014251.GC14835@mcvoy.com> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> Message-ID: I was never overly fond of the typography that Tex generated. I could always spot a document produced by it. Troff’s rooting in proper typesetting meant that it generated more conventional appearing text. The only dead giveaway was the little pumps that the pic driver for some of the printers did on the boxes outlining the table output. There was a couple of pixel overshoot on the vertical lines that gave a telltale bump at the top corners. ------ Original Message ------ >From "Larry McVoy via TUHS" To tuhs at tuhs.org Date 5/22/2026 9:42:51 PM Subject [TUHS] Re: troff.org and the old bell-labs.com domain >I think that LaTex won because of marketing. I'm a huge troff fan, the >BitKeeper logo was done in troff, I've done a lot of good things in troff, >I modernized the -ms macros to look better and they did. > >All that said, my nerd son has gone all in on LaTex and he makes stuff >look good. I think LaTex won, I'm not happy about it but it is what it >is. > >I fully support anything that makes troff better. > >Back when my first son was born, 2019, I was program committee chair for >Linux Expo, which was not a big deal, it meant that I formatted all the >papers into a book. I tried to get people to do troff, only a few did, >but they said "holy shit, it's so fast". I think LaTex does multiple >passes so they can do a table of contents, troff was faster. > >But even though I had some sucess at pushing people to troff, it was >not the winner. I wish it was. > >On Sat, May 23, 2026 at 12:07:39AM +0100, Ralph Corderoy via TUHS wrote: >> Hi Lyndon, >> >> > Does anyone know if Ralph is still maintaining that page? >> >> Yes, I'm not dead yet. I'll reply more off-list. >> >> -- >> Cheers, Ralph. > >-- >--- >Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sun May 24 04:50:25 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Sat, 23 May 2026 14:50:25 -0400 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523141225.GC18663@macsyma-wired.lan> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> Message-ID: On Sat, May 23, 2026 at 10:22 AM Theodore Tso via TUHS wrote: > On Fri, May 22, 2026 at 06:42:51PM -0700, Larry McVoy via TUHS wrote: > > I think that LaTex won because of marketing. I'm a huge troff fan, the > > BitKeeper logo was done in troff, I've done a lot of good things in troff, > > I modernized the -ms macros to look better and they did. > > I'm sure a lot of it is what you're used to, but I think many people found: > > \[ s = \sqrt{\frac{\sum_{i=1}^N (x_i - \bar{x})^2}{N - 1}} \] > > simpler than: > > .EQ > s = sqrt { { sum from i=1 to N ( x sub i - x bar ) sup 2 } over { N - 1 } } > .EN Maybe. I kind of prefer the `eqn` version, to be honest, but `eqn` was too limited compared to the full generality of TeX. If you need to typeset serious mathematics, the latter is just better. Sorry; that's just how it is. > I suspect that people also found it simpler to right macros in > TeX/LaTex compared to troff. For example. consider: > > \def\highlight#1{\bf #1} > > This allows you to write something like: > > This is \highlight{important} > > where important will be bolded. > > The rough equivalent in groff would be something like > > .DE HIGHLIGHT > \fB\\$1\fR > .. > > And: > > This is > .HIGHLIGHT important Here, I kind of prefer the TeX version. > And of course, in classical troff macro identifiers could only be two > characters, which did macro packages no favors in terms of > readability.... > > I don't think it's say that LaTeX one out over troff just because of > "marketing". I think the notion of "winning" here is a misnomer. TeX and LaTeX are good for some things; troff is good for some things. Personally, I am rather fond of the aesthetics of troff output, but LaTeX is superior for typesetting mathematics. Doug brings up some great points, giving voice to some of my own latent frustrations with TeX: the output verbosity, the poorly-understood interactive mode, and I find the error messages to be poor. One wonders whether how the design of TeX would have been different if, say, Knuth had had more exposure to Unix when he was building it. - Dan C. From tuhs at tuhs.org Sun May 24 07:27:48 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 23 May 2026 17:27:48 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: <20260523212748.DE61B10CABD9D@ary.qy> It appears that steve jenkin via TUHS said: > > could something like C have improved MULTICS or helped it's success in the marketplace? I doubt it. Multics was doomed because it was tied to the GE 645. The addresses were too small (18 bit offset per segment, about a megabyte) and everyone was moving to 8 bit byte addressed architectures. Changing the programming language wouldn't have made any difference. Unix was portable partly because it was written in C, but just as much becase the targets were all 8 bit machines with addressing and data formats similar to the PDP-11. PL/I was a surprisingly popular system programming language. At the same time Ken and Dennis were rewriting Unix in C, IBM was rewriting OS/360 in PL/S, which was a PL/I subset with some extensions for system programming. R's, John From tuhs at tuhs.org Sun May 24 13:02:39 2026 From: tuhs at tuhs.org (Blake McBride via TUHS) Date: Sat, 23 May 2026 22:02:39 -0500 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: <20260523014251.GC14835@mcvoy.com> References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> Message-ID: On Fri, May 22, 2026 at 8:52 PM Larry McVoy via TUHS wrote: > I think that LaTex won because of marketing. I'm a huge troff fan, the > BitKeeper logo was done in troff, I've done a lot of good things in troff, > I modernized the -ms macros to look better and they did. > > All that said, my nerd son has gone all in on LaTex and he makes stuff > look good. I think LaTex won, I'm not happy about it but it is what it > is. > > I fully support anything that makes troff better. > > Back when my first son was born, 2019, I was program committee chair for > Linux Expo, which was not a big deal, it meant that I formatted all the > papers into a book. I tried to get people to do troff, only a few did, > but they said "holy shit, it's so fast". I think LaTex does multiple > passes so they can do a table of contents, troff was faster. > > But even though I had some sucess at pushing people to troff, it was > not the winner. I wish it was. > I have a long and deep love of troff. Years ago I created a set of macros that produced HP PCL for HP printers. With it, a team produced thousands of mortgage forms for years. Troff just made sense to me, and I've always loved it. When TeX came out I was eager to try it. Two things I discovered: 1. When troff produced a document, I could tell it was produced by troff. It looked uniquely troff to me. I'm not sure why. When I produced a document with TeX/LaTeX it looked just like a modern book. It was a thing of beauty and perfection. 2. While I found troff straightforward to understand, after close to 30 years with TeX/LaTeX and reading every book I could get my hands on, I still have little understanding of it. I could spend hours trying to do the simplest thing. I am clearly not smart enough for TeX/LaTeX. I have now published a few books. All were written with LyX - a GUI front-end for LaTeX. My books come out looking like all other books you'd buy at any bookstore. I use troff when I can. I use LyX whenever I am writing something for publication. Blake McBride blakemcbride.us From tuhs at tuhs.org Sun May 24 23:31:05 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Sun, 24 May 2026 09:31:05 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: [This is really better on COFF; TUHS to Bcc:] On Sat, May 23, 2026 at 5:12 AM steve jenkin via TUHS wrote: > I'm not criticising MULTICS, I couldn't have come close to what they did: Note: it's Multics, not MULTICS. > with what they had, PL/1 & GE-645 hardware, > they came up with a working design that had decades of use > including 'Security' with many features, like file systems, now standard. > > They started with very large budgets, many people and 'stretch' goals - always red flags for projects. > Perhaps they suffered "Second System" effect and over-designed it - but this isn't a critique, just a hypothetical on the impact of language choice. > > The project delivered, it was far better software than IBM OS/360 and gave credence to high-level language kernels & designing for security. I don't think Multics was trying to compete with OS/360 at all: the latter was a batch system, Multics was a timesharing system. Melinda Varian's (excellent, highly recommended) history of IBM's VM system (https://www.leeandmelindavarian.com/Melinda/neuvm.pdf) goes into some detail here: from IBM's perspective, they fully expected to get the nod for project MAC and Multics, going as far as to set up the Cambridge Scientific Center in Tech Square in anticipation of supporting that work. But project MAC reacted badly to the 360 announcement, in particular, the lack of planned "address translation" (read: virtual memory) hardware; something that Doug has mentioned here in the past. A meeting was arranged between Fernando Corbato and Gene Amdahl, designed to put oil on the troubled waters; Corby tried to impress upon Amdahl the importance of virtual memory for timesharing, and Amdahl told Corby to get bent. Project MAC gave the nod to GE, and IBM was apparently rather shocked by the loss; ironically, the 360/67 was announced shortly after. Anyway, if anything, IBM started work on TSS to compete with Multics; now THAT was a second system and never really gained much success: VM was far more popular. > IBM was first to prove Software Quality was secondary to Marketing for product sales. > > Ken & Dennis spent years coming up with C, slowly evolving it to meet their very precise needs: small, efficient & performant. > Everyone but MULTICS & Burroughs opted for assembler, if they even built a full O/S, not just program loaders. > > Thinking of rewriting the kernel in non-assembler was a major invention - a significant research outcome. > I don't believe we'd have had C without Unix, especially rewriting the kernel. > > Doug worked on the PL/1 compiler, from memory, and certainly on MULTICS and might have a view: > > could something like C have improved MULTICS or helped it's success in the marketplace? I think John was spot on in his response: Multics was very tightly coupled to the GE-645, H6180, DPS/8m line of architectures. It was written (mostly) in a high-level language because that was more productive and less error-prone, but it wasn't portable in any significant sense, and that hardware architecture was a dead-end. Being written in C wouldn't have helped that. Ironically, if it had been targeted to the S/360, it might have been portable to other machines; at least it would have had power-of-two data sizes and byte addressing. > [snip] > After SEL4 / L4.verified, do we still think "You can't write a 'secure' kernel in C"? > > The Verification was a huge effort, far more than writing the kernel. > Perhaps another language would've lessened the effort, though at what cost? "Cost" is the key here. You can absolutely write a 'secure' kernel in C, but the key design question is, is the effort required to do so worth it? Or is some other language available that lowers the cost? Bear in mind that costs are abstract; it's not just programming effort required to avoid bugs, but also expertise in the language, quality of the compiler and its output, and surrounding tooling. The SeL4 experience is not representative. Verification covered a restricted subset of system functionality (I dimly remember that they cut out DMA), and involved translation into Haskell. Moreover, "secure" is not well-defined in this context. seL4 wasn't verified to be "secure" in all respects; rather, verification showed that it operates correctly with respect to its specification, and that the security properties in that specification hold. Back to Multics, I'll wager cookies to cake that in aggregate it has plenty of buffer overruns, race conditions, and straight-up logic bugs. What makes Multics more "secure" than Unix is the overall architecture (aided and abetted by the hardware's ring architecture) and overall approach, which emphasizes least-privilege, and so on. But it surely has bugs; presumably at least some of those could be leveraged to increase a process's privilege level: entire categories of security attacks have been discovered since Multics was designed. > We can't change history, the MULTICS experience & the Bell Labs management reaction was necessary for Unix to begin. > > Doing kernels on tiny machines forced a very compact, crisp language design, which was then tried 'everywhere', working incredibly well. I would say that doing _compilers_ within the limitations of those early machines forced a compact language. > [snip] > Why was UNIX written in C instead of PL/1? > Multics was written in PL/1 which is equally capable and was more mainstream than C. > Trying to squeeze a full PL/1 compiler onto a PDP-7 would have been akin to putting ten pounds of nuts into a five pound bag; assuming self-hosting was a goal, BCPL was decently expressive, and B obviously fit on the machine available. The B -> nb -> C transition came about from that, by which point I suspect few people were terribly interested in a PL/1 compiler. There's also a matter of taste. I don't know, but I never got the impression that PL/1 was a _popular_ language with the Unix folks after Multics. Perhaps Doug or Ken can comment? - Dan C. From tuhs at tuhs.org Mon May 25 06:58:56 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 24 May 2026 14:58:56 -0600 Subject: [TUHS] Control-T in UNIX In-Reply-To: References: <202605211923.64LJN281035690@freefriends.org> Message-ID: <202605242058.64OKwue2064652@freefriends.org> To be clear, it was Chris Torek's patch that we put into 4.2 and 4.3. I didn't develop it. Reese Johnson via TUHS wrote: > Wow! Thank you so much. I'm a bit younger but I really love Unix. I am > located in Georgia too. I use ^T all the time still on FreeBSD. I had > no idea GT had something to do with it. Nice to meet you all. This list > is so amazing. > > Thanks > Reese KN4NTU > 73 > > On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > > It was indeed posted to USENET, but didn't (IIRC) make it into the > > official 4.3 BSD release. > > > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > > put it into 4.3BSD + Mt. Xinu at Emory. > > > > At GT, I remember a professor who came from MIT being pleasantly > > surprised to learn that we had ^T on the vax. :-) > > > > Rich Salz via TUHS wrote: > > > > > My recollection is that Chris Torek at University of Maryland added control > > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > > posted to Usenet which is where I read about it > > > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > > > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > > that did have control-T. > > > > Mike added that to our kernel (llisting all the processes running on the > > > > terminal) so he could get some feedback on what his tweaks were doing. > > > > > > > > -Ron > > > > > > > > From tuhs at tuhs.org Mon May 25 07:15:40 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 24 May 2026 15:15:40 -0600 Subject: [TUHS] rsync from minnie? In-Reply-To: References: <202605212025.64LKPS60043052@freefriends.org> Message-ID: <202605242115.64OLFe9U066390@freefriends.org> Dan, Thanks for the explanation. Normally, I'd just change my script and go on with life, but I have a vested interest in "minnie.tuhs.org" continuing to work as it has for decades. In the fall of last year I published a second edition of my book on Unix/Linux programming, which pulls code from both old Unix sources and GNU sources. As part of the intro material, it provides a script for mirroring TUHS, using "minnie.tuhs.org". The change in hostname breaks my book. :-( Is it reasonable for "new minnie" to become something like minnie.drwkt.org or some such, so that "minnie.tuhs.org" can go back to working as it has for literally decades? Thanks, Arnold P.S. I'm only dealing with email intermittently. I'm in the US helping out with family issues. Dan Cross wrote: > On Thu, May 21, 2026 at 4:25 PM Arnold Robbins via TUHS wrote: > > I'm in the US, and trying to rsync from minnie. It's not doing anything, > > and when I ping minnie.tuhs.org I get an IPv6 address: > > 2600:3c01::2000:a0ff:fead:bc2f > > > > Any ideas? > > > > It's not crucial for right now. > > > > Also, I'll be offline the next two days, but will eventually > > see any replies. > > Try the hostname, `oldminnie.tuhs.org`. Minnie is being > replaced/upgraded/transplanted, and transitioned to being solely > Warren's personal machine. The TUHS infrastructure is being redone, > and will switched to new kit in a couple of months. In the meantime, > the system-formerly-known-as-minnie is now `oldminnie` and running > most of the TUHS services (web, mail, FTP, and rsync). > > Sorry, I'm afraid this is a bit vague and I'm not trying to be > evasive, it is just that things are sort of in flux and not easily > describable just yet. We'll send a proper announcement once > everything is up and running in its new home. > > - Dan C. From tuhs at tuhs.org Mon May 25 08:20:14 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 25 May 2026 08:20:14 +1000 Subject: [TUHS] rsync from minnie? In-Reply-To: <202605242115.64OLFe9U066390@freefriends.org> References: <202605212025.64LKPS60043052@freefriends.org> <202605242115.64OLFe9U066390@freefriends.org> Message-ID: On Sun, May 24, 2026 at 03:15:40PM -0600, Arnold Robbins via TUHS wrote: > In the fall of last year I published a second edition of my book on > Unix/Linux programming, which pulls code from both old Unix sources > and GNU sources. As part of the intro material, it provides a script > for mirroring TUHS, using "minnie.tuhs.org". > > The change in hostname breaks my book. :-( > > Is it reasonable for "new minnie" to become something like minnie.drwkt.org > or some such, so that "minnie.tuhs.org" can go back to working as it > has for literally decades? Arnold, I put in a TCP port forwarder for rsync, so that if you do rsync minnie.tuhs.org:: then things will still work. Hopefully, your script isn't broken! I've been using "minnie" since 1991, see https://minnie.tuhs.org/Blog/Docs/minannounce.txt and I've tried to keep the personal (minnie) side of things separate from the TUHS (www) side of things. I definitely want to keep the personal/TUHS split moving forward. That said, if there is a web link which is now broken, I can easily put in a redirect on the new minnie to point at the www page. I've been 404 grepping in the past week and I haven't seen many. Cheers, Warren From tuhs at tuhs.org Mon May 25 08:47:08 2026 From: tuhs at tuhs.org (Stuff Received via TUHS) Date: Sun, 24 May 2026 18:47:08 -0400 Subject: [TUHS] rsync from minnie? In-Reply-To: References: <202605212025.64LKPS60043052@freefriends.org> <202605242115.64OLFe9U066390@freefriends.org> Message-ID: Greetings, Warrne. On 2026-05-24 18:20, Warren Toomey via TUHS wrote (in part): [...] > That said, if there is a web link which is now broken, I can > easily put in a redirect on the new minnie to point at the www page. > I've been 404 grepping in the past week and I haven't seen many. W3 has a link checker (here https://www.w3.org/developers/tools/) that may help. I have not used for a while, though. Sincerely, S. > > Cheers, Warren From tuhs at tuhs.org Mon May 25 10:14:10 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 24 May 2026 18:14:10 -0600 Subject: [TUHS] rsync from minnie? In-Reply-To: References: <202605212025.64LKPS60043052@freefriends.org> <202605242115.64OLFe9U066390@freefriends.org> Message-ID: <202605250014.64P0EA30083033@freefriends.org> Warren, Warren Toomey via TUHS wrote: > On Sun, May 24, 2026 at 03:15:40PM -0600, Arnold Robbins via TUHS wrote: > > In the fall of last year I published a second edition of my book on > > Unix/Linux programming, which pulls code from both old Unix sources > > and GNU sources. As part of the intro material, it provides a script > > for mirroring TUHS, using "minnie.tuhs.org". > > > > The change in hostname breaks my book. :-( > > > > Is it reasonable for "new minnie" to become something like minnie.drwkt.org > > or some such, so that "minnie.tuhs.org" can go back to working as it > > has for literally decades? > > Arnold, I put in a TCP port forwarder for rsync, so that if you do > rsync minnie.tuhs.org:: then things will still work. Hopefully, your > script isn't broken! I just tried it, and it works fine. So a big T H A N K Y O U for setting this up. And of course, a continuing "thank you" for all you've done. Arnold From tuhs at tuhs.org Mon May 25 10:15:27 2026 From: tuhs at tuhs.org (Greg A. Woods via TUHS) Date: Sun, 24 May 2026 17:15:27 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: At Sat, 23 May 2026 19:02:43 +1000, steve jenkin via TUHS wrote: Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? > Regarding the question in your Subject line: Well of course it could have, though some minor extensions may have helped. There was, in the end, a C compiler and runtime for Multics. > could something like C have improved MULTICS or helped > it's success in the marketplace? I think early on PL/1 was still acceptable to the marketplace. The problem was more the Honeywell hardware wasn't widely accepted (as much as say IBM hardware was, obviously, or even DEC hardware). In the end-days of Multics, when Unix was gaining steam, a C re-implementation may have helped, but of course it would also have had to be written for, and/or portable to, more modern CPUs in order for it to go anywhere at all. I think it would be possible to write a Multics-like system for the Intel 80386, (i.e. IA-32) though such a system would have some constraints due to the limitations of the 386. I feel sad that the support for segmentation was dropped from the amd64 architecture. Since I'm enamoured with the idea of files just being (virtual) memory locations and getting rid of the sucking/blowing-through-a-straw read/write API for files, I've written some half-baked thoughts on writing a "modern" multics-like system: http://www.robohack.ca/~woods/multics.txt See also: http://www.robohack.ca/~woods/C.txt -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From tuhs at tuhs.org Mon May 25 10:36:38 2026 From: tuhs at tuhs.org (Greg A. Woods via TUHS) Date: Sun, 24 May 2026 17:36:38 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> <20260523143249.GE14835@mcvoy.com> Message-ID: At Sat, 23 May 2026 11:44:13 -0400, Douglas McIlroy via TUHS wrote: Subject: [TUHS] Re: troff.org and the old bell-labs.com domain > > Roughly speaking, Tex cleaned up the architecture but botched the > aesthetics. I don't find TeX as one uses it to be "clean" in any aesthetic way, though I agree its underlying architecture is a thing of beauty. A mentor of mine strongly preferred PlainTeX (Knuth's own macro package) over LaTeX, and I found it was indeed quite a bit easier to work with. Meanwhile though I mostly continued using troff for quite some time, including publishing a newsletter with 2-column format (using mm). However at some point in the early 1990's I switched to Lout, which I think in some ways is the best of both worlds thrown together and then cleaned up and simplified as much as possible. http://jeffreykingston.id.au/lout/ It is reasonably fast and has many/most(?) of the capabilities of troff, including tables, equations, and pic-like diagram drawing, and of course works well on Unix and Unix-like systems. It generates PostScript or PDF output. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From tuhs at tuhs.org Mon May 25 10:43:43 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 25 May 2026 10:43:43 +1000 Subject: [TUHS] Control-T in UNIX In-Reply-To: <202605242058.64OKwue2064652@freefriends.org> References: <202605211923.64LJN281035690@freefriends.org> <202605242058.64OKwue2064652@freefriends.org> Message-ID: inexpensive twenex-style ^T for 4.2 (and 4.1) Rehmi Post in net.unix-wizards, Mar 29, 1985 https://groups.google.com/g/net.unix-wizards/c/wt3mEa_KhFg/m/rM6F4uDL4UgJ (offers to send patches) Twenex-Like ^T for 4.1BSD Chris Torek in net.sources, Jun 20, 1985 https://groups.google.com/g/net.sources/c/lPpvF_3sC2o/m/3D9bkufBBBUJ Twenex-Like ^T for 4.2BSD Vax Chris Torek in net.sources, Jun 20, 1985 https://groups.google.com/g/net.sources/c/BfyFp1p_-t0/m/jbKhhVGQKhsJ Twenex-Like ^T for Pyramid kernel Chris Torek in net.sources, Jun 20, 1985 https://groups.google.com/g/net.sources/c/VKBnM6hIPRU/m/O5UwiKoXnIAJ control-T for 4.3BSD Chris Torek in comp.bugs.4bsd, May 28, 1987 https://groups.google.com/g/comp.bugs.4bsd/c/IeMLfBjx4JM/m/uOgCAgXMrusJ Quite different to what went into 4.3BSD-Reno. Chris on the history via stackoverflow, included below https://stackoverflow.com/questions/39883417/what-info-does-ctrl-t-show-during-a-terminal-git-push "This status-printing, and the existence of the status character itself, is derived from code written by myself and Rehmi Post (with input from several others; Fred Blonder quite possibly had a hand in it, plus of course the grad students we had that came from Stanford and MIT) back when I was at the University of Maryland, in the mid-to-late 1980s. The SIGINFO signal and the NOKERNINFO control flag were added later, in the 1990s (or perhaps even a bit later). (As I recall, ITS, TOPS-10, TOPS-20, and/or TENEX/TWENEX all had something like this. I never used any of those myself but that is where the idea came from.)" On Sun, May 24, 2026 at 02:58:56PM -0600, Arnold Robbins via TUHS wrote: > To be clear, it was Chris Torek's patch that we put into 4.2 and 4.3. > I didn't develop it. > > Reese Johnson via TUHS wrote: > > > Wow! Thank you so much. I'm a bit younger but I really love Unix. I am > > located in Georgia too. I use ^T all the time still on FreeBSD. I had > > no idea GT had something to do with it. Nice to meet you all. This list > > is so amazing. > > > > Thanks > > Reese KN4NTU > > 73 > > > > On Thu, May 21, 2026 at 01:23:02PM -0600, Arnold Robbins via TUHS wrote: > > > It was indeed posted to USENET, but didn't (IIRC) make it into the > > > official 4.3 BSD release. > > > > > > Scott Lee and I put it in to 4.2 BSD at Georgia Tech, and I think I > > > put it into 4.3BSD + Mt. Xinu at Emory. > > > > > > At GT, I remember a professor who came from MIT being pleasantly > > > surprised to learn that we had ^T on the vax. :-) > > > > > > Rich Salz via TUHS wrote: > > > > > > > My recollection is that Chris Torek at University of Maryland added control > > > > t to the bsd tty driver and it was made available in 4.3 or so. It was > > > > posted to Usenet which is where I read about it > > > > > > > > On Thu, May 21, 2026, 7:02 AM Ron Natalie via TUHS wrote: > > > > > > > > > When Mike Muuss was playing with enhancing the UNIX scheduler in our > > > > > (largely V6 based) kernels, we had access to some of the DEC-10 OS’s > > > > > that did have control-T. > > > > > Mike added that to our kernel (llisting all the processes running on the > > > > > terminal) so he could get some feedback on what his tweaks were doing. > > > > > > > > > > -Ron > > > > > > > > > > From tuhs at tuhs.org Mon May 25 11:01:54 2026 From: tuhs at tuhs.org (Theodore Tso via TUHS) Date: Sun, 24 May 2026 20:01:54 -0500 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> Message-ID: <20260525010154.GB51941@macsyma.local> On Sat, May 23, 2026 at 10:02:39PM -0500, Blake McBride via TUHS wrote: > > 1. When troff produced a document, I could tell it was produced by troff. > It looked uniquely troff to me. I'm not sure why. When I produced a > document with TeX/LaTeX it looked just like a modern book. It was a thing > of beauty and perfection. > > 2. While I found troff straightforward to understand, after close to 30 > years with TeX/LaTeX and reading every book I could get my hands on, I > still have little understanding of it. I could spend hours trying to do > the simplest thing. I am clearly not smart enough for TeX/LaTeX. I have > now published a few books. All were written with LyX - a GUI front-end for > LaTeX. My books come out looking like all other books you'd buy at any > bookstore. I'd suggest the two is related. If you just use standard LaTeX without any customizations, it's quite easy to understand: \documentclass{article} \title{A sample LaTeX document} \author{Theodore Tso} \date{May 2026} \begin{document} \maketitle \section{Introduction} This is a sample document. \section{Easy peasy lemon squeezy} Isn't it simple to understand? \end{document} .... but the resulting document will *obviously* look like LaTeX. There is definitely a default LaTeX look, just as there is a default troff look. The reason why you can make it look "like a modern book" is because it's possible to customize the bejeesus out of it. This is probably possible in troff as well, but I've never been smart enough to figure out how to do the kind of extreme customizations that I've done by breaking out of LaTeX and using raw TeX macros. But at that point, it can very easily become Forth-like in terms of being a write-only document. :-) - Ted From tuhs at tuhs.org Mon May 25 12:46:58 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Sun, 24 May 2026 19:46:58 -0700 Subject: [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> <20260523143249.GE14835@mcvoy.com> Message-ID: Seems like a lot of the cool kids are using typst these days. https://github.com/typst/typst or https://typst.app Adam On Sun, May 24, 2026 at 5:36 PM Greg A. Woods via TUHS wrote: > At Sat, 23 May 2026 11:44:13 -0400, Douglas McIlroy via TUHS < > tuhs at tuhs.org> wrote: > Subject: [TUHS] Re: troff.org and the old bell-labs.com domain > > > > Roughly speaking, Tex cleaned up the architecture but botched the > > aesthetics. > > I don't find TeX as one uses it to be "clean" in any aesthetic way, > though I agree its underlying architecture is a thing of beauty. > > A mentor of mine strongly preferred PlainTeX (Knuth's own macro package) > over LaTeX, and I found it was indeed quite a bit easier to work with. > > Meanwhile though I mostly continued using troff for quite some time, > including publishing a newsletter with 2-column format (using mm). > > However at some point in the early 1990's I switched to Lout, which I > think in some ways is the best of both worlds thrown together and then > cleaned up and simplified as much as possible. > > http://jeffreykingston.id.au/lout/ > > It is reasonably fast and has many/most(?) of the capabilities of troff, > including tables, equations, and pic-like diagram drawing, and of course > works well on Unix and Unix-like systems. It generates PostScript or > PDF output. > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > From tuhs at tuhs.org Mon May 25 13:14:40 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Sun, 24 May 2026 20:14:40 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: That tracks: Melinda's husband Lee is the only person I know who really used TSS. Adam On Sun, May 24, 2026 at 5:15 PM Greg A. Woods via TUHS wrote: > At Sat, 23 May 2026 19:02:43 +1000, steve jenkin via TUHS > wrote: > Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if > available? > > > > Regarding the question in your Subject line: > > Well of course it could have, though some minor extensions may have > helped. > > There was, in the end, a C compiler and runtime for Multics. > > > could something like C have improved MULTICS or helped > > it's success in the marketplace? > > I think early on PL/1 was still acceptable to the marketplace. The > problem was more the Honeywell hardware wasn't widely accepted (as much > as say IBM hardware was, obviously, or even DEC hardware). > > In the end-days of Multics, when Unix was gaining steam, a C > re-implementation may have helped, but of course it would also have had > to be written for, and/or portable to, more modern CPUs in order for it > to go anywhere at all. > > I think it would be possible to write a Multics-like system for the > Intel 80386, (i.e. IA-32) though such a system would have some > constraints due to the limitations of the 386. I feel sad that the > support for segmentation was dropped from the amd64 architecture. > > Since I'm enamoured with the idea of files just being (virtual) memory > locations and getting rid of the sucking/blowing-through-a-straw > read/write API for files, I've written some half-baked thoughts on > writing a "modern" multics-like system: > > http://www.robohack.ca/~woods/multics.txt > > See also: > > http://www.robohack.ca/~woods/C.txt > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > From tuhs at tuhs.org Mon May 25 13:23:45 2026 From: tuhs at tuhs.org (Jon Steinhart via TUHS) Date: Sun, 24 May 2026 20:23:45 -0700 Subject: [TUHS] For what it's worth... In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: <202605250323.64P3NjK52247764@darkstar.fourwinds.com> Was nearby so visited Heinz yesterday. Got to lay hands on an actual paper MERT manual. For those of you that don't know, Heinz was one of the three Explorer Scout advisors at Bell Labs Murray Hill when I was in high school. Jon From tuhs at tuhs.org Mon May 25 16:16:19 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 25 May 2026 06:16:19 +0000 Subject: [TUHS] UNIX Program Generic Issue 3 Successfully Resurrected In-Reply-To: References: <8RXzBCPKUd716n5Z2c7c7LzIfQyMJ4K4HI2hx1J8Q3Jt2LP7lrRT7IHWPPolEafiZxGLfRcs2AcwTghc3TK6E-R2UD6PGQcoSvyXq1pzZ_c=@protonmail.com> Message-ID: <4Bs0U1Fk7FlmldZ-ne4xGZNbDRrcmWULmQikNImr9_toarjfMj1wMCOlVRZs-ADqRv003e7M-m9ycduPITptOZqQJ9RBc3c5pkJpfjw8Bc0=@protonmail.com> Just a little PG3 update, I've finished the first pass of my manpage sources reconstruction for the manual. This will serve as the substrate of a more accurate reconstruction which I'll be taking a bit more time on. Errors are numerous, the second pass will be more worthy of regular on-line reference, but the important bits are there. https://gitlab.com/segaloco/usg_man/-/tags There are tags for the V6 manual I started with as well as PG2 and PG3 revisions. There are at least 5 typos I know of as of the pg2 tag... meaning more I don't know of probably. I plan on doing a second pass with proper verification via groff and maybe a V6 emu. Curiously the Program Generic manuals lack a man(I) command, and indeed no manpage sources were found amongst the PG3 materials discovered. The sources were obviously maintained somewhere but out of general distribution. Unfortunately I can't guarantee a 1:1 reconstruction, just quite close typesetting reproduction, but my main reason for this exercise was machine readable (and temporally diff-able) sources for incorporation in larger efforts to reconstruct other manuals as well as trace development of features. Anywho, figured I'd share. The second pass will hopefully also result in reconstructions of the MERT Release 0 and CB-UNIX 2.3 manuals, as both are genetically related to the PG3 manual. With this done I'll also beef up the PG3 wiki page[1] with detailed changes. - Matt G. From tuhs at tuhs.org Tue May 26 00:07:38 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 25 May 2026 10:07:38 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? Message-ID: > Multics was written in PL/1 which is equally capable and was more mainstream than C. IBM hoped it would become mainstream, but when Multics adopted PL/I, it was only a draft spec. It had some radical features, e.g. pointers, that broke away from the mainstream of the time. > Trying to squeeze a full PL/1 compiler onto a PDP-7 would have been > akin to putting ten pounds of nuts into a five pound bag Amusingly, IBM's goal of compatibility across the whole 360 spectrum forced them to do just that. The compiler came in various memory sizes. I heard that the version for the smallest 360/20s ran as some 60 overlays. > There's also a matter of taste. I don't know, but I never got the > impression that PL/1 was a _popular_ language with the Unix folks > after Multics. Perhaps Doug or Ken can comment? True. As I told Steve Jenkin, my PL/I oeuvre comprises exactly one working program, despite the fact that I helped design the language. Other Unix people had even less motivation to jump on the PL/I bandwagon. Doug From tuhs at tuhs.org Tue May 26 10:24:13 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 25 May 2026 20:24:13 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: below On Sun, May 24, 2026 at 11:14 PM Adam Thornton via TUHS wrote: > That tracks: Melinda's husband Lee is the only person I know who really > used TSS. > You might be surprised. A number of us used TSS and MTS extensively before we saw UNIX, and they influenced many things. For instance, Ted Kowaski and Bill Joy were MTS hackers before they saw UNIX. I had been working on TSS [supporting York/APL at the time]. Ted and I had both used tools like IBM's disk scavenger tools. The creation of fsck(8) was a direct result of that [it was also why the error messages were all UPPER CASE - that was how we had been taught earlier]. I'll let Tom Lyon speak for himself, but he also had extensive mainframe experience, and I expect it influenced his thinking later on. The point is that what we think of as Unix is clearly unique. But, as with most man-made things, standing on the shoulders of others was not unheard of, and influences from previous and current systems certainly guided many of the choices made by different UNIX developers. [Of course, Hamming is said to have quipped: *"Mathematicians stand on each other's shoulders while computer scientists stand on each other's toes." ].* Coming back to the question of PL/1 *vs. *C, I have a longer responce on quora: https://www.quora.com/What-makes-the-C-language-powerful that I will crib here. When PL/1 and Algol68 were being created, and frankly, later with Ada and others, there was always a tendency to go overboard. But to me, the less-is-more rule applies: C is powerful not only because of what is in the language but also because of what Dennis (and Ken) left out. C was not trying to be all things. But it does mean that part of the power of C is that it is the programmer's responsibility to write appropriate code. The C programming language was a tool they needed and would work well for them. Its staying power has been because it was so good at what it did. As Doug pointed out, IBM had envisioned PL/1 as its grand solution. Both Scientific folks and Commericial folks had one tool. Remember what wisdom Dennis once offered: *"When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd."* The fact is, B lived a long time on the GE/Honeywell systems, even with alternatives such as PL/1. The 36-bit nature of the GE hardware was less natural for C, but I suspect common solutions to some of the problems would have become mainstream if the 36-bit world had lived longer at either Honeywell or DEC. Although I thank Fred Brooks, who was right in about 1963 when he tossed Gene Amdahl out of his office and told him he did not care if Gene thought it was a waste of hardware. *"Any size that was not a power of two was too difficult to program,"* and he should *"not come back until bytes and words are powers of two".* From tuhs at tuhs.org Tue May 26 10:40:34 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Mon, 25 May 2026 17:40:34 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: IBM's TSO (on OS/MVT and MVS) was awful ("like kicking a dead whale down the beach" - scj) but it worked - I used it for 3 summers. Princeton tried hard to get TSS/67 working (before my time) but gave up. VM/370, otoh, was a fine system that IBM tried to kill several times because it came from the skunkworks, not the giant software organization. Shoutout to both Varians for their fine work. TSS development was killed and revived a couple of times. The only serious user I ever heard of was Bell Labs, (10+ years after initial promises) and they did their port of UNIX to it. On Mon, May 25, 2026 at 5:24 PM Clem Cole via TUHS wrote: > below > > On Sun, May 24, 2026 at 11:14 PM Adam Thornton via TUHS > wrote: > > > That tracks: Melinda's husband Lee is the only person I know who really > > used TSS. > > > You might be surprised. A number of us used TSS and MTS extensively before > we saw UNIX, and they influenced many things. For instance, Ted Kowaski > and Bill Joy were MTS hackers before they saw UNIX. I had been working on > TSS [supporting York/APL at the time]. Ted and I had both used tools like > IBM's disk scavenger tools. The creation of fsck(8) was a direct result of > that [it was also why the error messages were all UPPER CASE - that was how > we had been taught earlier]. I'll let Tom Lyon speak for himself, but he > also had extensive mainframe experience, and I expect it influenced his > thinking later on. > > The point is that what we think of as Unix is clearly unique. But, as > with most man-made things, standing on the shoulders of others was not > unheard of, and influences from previous and current systems certainly > guided many of the choices made by different UNIX developers. [Of course, > Hamming is said to have quipped: *"Mathematicians stand on each other's > shoulders while computer scientists stand on each other's toes." ].* > > Coming back to the question of PL/1 *vs. *C, I have a longer responce on > quora: https://www.quora.com/What-makes-the-C-language-powerful that I > will crib here. When PL/1 and Algol68 were being created, and frankly, > later with Ada and others, there was always a tendency to go overboard. > But to me, the less-is-more rule applies: C is powerful not only because of > what is in the language but also because of what Dennis (and Ken) left out. > C was not trying to be all things. But it does mean that part of the power > of > C is that it is the programmer's responsibility to write appropriate code. > The > C programming language was a tool they needed and would work well for them. > Its staying power has been because it was so good at what it did. As Doug > pointed out, IBM had envisioned PL/1 as its grand solution. Both > Scientific folks and Commericial folks had one tool. Remember what wisdom > Dennis once offered: *"When I read commentary about suggestions for where C > should go, I often think back and give thanks that it wasn't developed > under the advice of a worldwide crowd."* > > The fact is, B lived a long time on the GE/Honeywell systems, even with > alternatives such as PL/1. The 36-bit nature of the GE hardware was less > natural for C, but I suspect common solutions to some of the problems would > have become mainstream if the 36-bit world had lived longer at either > Honeywell or DEC. Although I thank Fred Brooks, who was right in about 1963 > when he tossed Gene Amdahl out of his office and told him he did not care > if Gene thought it was a waste of hardware. *"Any size that was not a > power of two was too difficult to program,"* and he should *"not come back > until bytes and words are powers of two".* > From tuhs at tuhs.org Tue May 26 10:55:51 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 25 May 2026 17:55:51 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> On May 25, 2026, at 5:24 PM, Clem Cole via TUHS wrote: > > Coming back to the question of PL/1 *vs. *C, I have a longer responce on > quora: https://www.quora.com/What-makes-the-C-language-powerful that I > will crib here. When PL/1 and Algol68 were being created, and frankly, > later with Ada and others, there was always a tendency to go overboard. > But to me, the less-is-more rule applies: C is powerful not only because of > what is in the language but also because of what Dennis (and Ken) left out. IMHO it is less less-is-more and more the *low-level* nature of C. Didn't IBM too used a "high level" low level language PL/S for MVS? Other languages like PL/M, ESPOL etc. allowed low leve access to machine specific features. Other HLLs used for kernel coding likely provided a machine specific way to access low level features. Also recall that Sun used C++ for its Spring (research) OS. And no one accuses C++ of "less-is-more"! From tuhs at tuhs.org Tue May 26 11:45:41 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Mon, 25 May 2026 18:45:41 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> Message-ID: <20260526014541.GA28587@mcvoy.com> On Mon, May 25, 2026 at 05:55:51PM -0700, Bakul Shah via TUHS wrote: > On May 25, 2026, at 5:24???PM, Clem Cole via TUHS wrote: > > > > Coming back to the question of PL/1 *vs. *C, I have a longer responce on > > quora: https://www.quora.com/What-makes-the-C-language-powerful that I > > will crib here. When PL/1 and Algol68 were being created, and frankly, > > later with Ada and others, there was always a tendency to go overboard. > > But to me, the less-is-more rule applies: C is powerful not only because of > > what is in the language but also because of what Dennis (and Ken) left out. > > IMHO it is less less-is-more and more the *low-level* nature of C. I have a son who is more about theory, he's a math guy. I nudged him towards programming, he of course went to python. I nudged him towards C and he came back with the best statement ever that I have gotten from him: In C, you can feel the machine. Yes, Travis, yes you can. That's part of what makes C great. I'm an old dude, I really love C, I get that it is hard to do things right in C, I get what all all the haters say about it. But I had a team that used C in the right way, it really, really worked well for us. There is stuff you can do in C that is really hard to do in the "better" languages and we took full advantage of that. It seems like people want to move away from C to stuff like Go and Rust and whatever. They are probably right. C is not for the casual people, if you aren't paying attention C is not for you. We paid attention and it worked for us. --lm From tuhs at tuhs.org Tue May 26 12:25:51 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 25 May 2026 19:25:51 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526014541.GA28587@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: On May 25, 2026, at 6:45 PM, Larry McVoy wrote: > > I have a son who is more about theory, he's a math guy. I nudged him > towards programming, he of course went to python. I nudged him towards > C and he came back with the best statement ever that I have gotten from > him: In C, you can feel the machine. That is exactly it! > It seems like people want to move away from C to stuff like Go and Rust > and whatever. They are probably right. C is not for the casual people, > if you aren't paying attention C is not for you. We paid attention and > it worked for us. I have been looking at R9 (a reimplementation of plan9 kernel in Rust -- not sure of the current state but not self-hosting as yet). There are 268 unsafe blocks/expressions in 9.6K lines of rust (counted using wc). Now I am not a fan of Rust but 268 unsafes is not bad at all as it shows what you need at a minimum to "feel to the machine"! And yet, today the game has changed; security is of paramount importance to anything that can be connected to the net. Attention has to be paid, no matter what PL or tool (such as LLMs) you use! From tuhs at tuhs.org Tue May 26 12:52:01 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Mon, 25 May 2026 19:52:01 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526014541.GA28587@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: On Mon, May 25, 2026 at 6:52 PM Larry McVoy via TUHS wrote: > > I have a son who is more about theory, he's a math guy. I nudged him > towards programming, he of course went to python. I nudged him towards > C and he came back with the best statement ever that I have gotten from > him: In C, you can feel the machine. Yes, Travis, yes you can. That's > part of what makes C great. > > But in this day and age, *can* you? You can feel the machine if that machine is a PDP-11. But with a modern pipelined SMP architecture, with prefetch and speculative execution and all that stuff...I don't think any human *can* feel the machine anymore. And I kind of mourn that, which is why I do retrocomputing and why my heart will always belong to the 6502, but...while C is an accurate match for what's going on in a single-processor system without any fancy caching, is it really "feeling the machine" anymore? Note: I like C. I like Go even more. I have not had to use Rust in anger yet so I don't really know it. 90% of my day job is Python, and the rest is mostly TypeScript. I'm not arguing this from a Luddite perspective, I'm just saying that it has been quite some time since "what the processor is actually doing" crossed the "human ability to understand it in detail" threshold. Or at least, *my* human ability. I'm not often the smartest bear in the room, but I'm usually not the dumbest either. Adam From tuhs at tuhs.org Tue May 26 12:54:53 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 25 May 2026 22:54:53 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: <20260526025454.2136210D90FFA@ary.qy> It appears that Greg A. Woods via TUHS said: >I think it would be possible to write a Multics-like system for the >Intel 80386, (i.e. IA-32) though such a system would have some >constraints due to the limitations of the 386. I feel sad that the >support for segmentation was dropped from the amd64 architecture. You're probably right but the performance would have been terrible because loading segment registers on the 386 was very slow, and there was a single page mapped linear address space into which all of the active segments had to fit, which meant that the practical size limit on a segment was a lot less than 32 bits. R's, John From tuhs at tuhs.org Tue May 26 13:09:07 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 26 May 2026 03:09:07 -0000 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> Message-ID: <10v32sj$srf$1@gal.iecc.com> According to Clem Cole via TUHS : >On Sun, May 24, 2026 at 11:14 PM Adam Thornton via TUHS >wrote: > >> That tracks: Melinda's husband Lee is the only person I know who really >> used TSS. >> >You might be surprised. I used it when I was in high school in Princeton around 1970. >Coming back to the question of PL/1 *vs. *C, I have a longer responce on >quora: https://www.quora.com/What-makes-the-C-language-powerful that I >will crib here. When PL/1 and Algol68 were being created, and frankly, >later with Ada and others, there was always a tendency to go overboard. >But to me, the less-is-more rule applies: C is powerful not only because of >what is in the language but also because of what Dennis (and Ken) left out. PL/I was a surprisingly good language given its creation story, hacked together in a hurry and intended to handle everything you could do in Fortran, Cobol, and/or Algol, but it did indeed have a case of kitchen sink-itis. IBM had system programming subsets PL/S, used in OS/360, and PL.8 used in the 801 project. I see that Multics was bootstrapped through a subset called EPL and suspect even after there was a full compiler, the system code stayed close to what that subset allowed. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Tue May 26 13:11:44 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 25 May 2026 23:11:44 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> Message-ID: <20260526031144.DC2AB10D913D7@ary.qy> It appears that Bakul Shah via TUHS said: >On May 25, 2026, at 5:24 PM, Clem Cole via TUHS wrote: >> >> Coming back to the question of PL/1 *vs. *C, I have a longer responce on >> quora: https://www.quora.com/What-makes-the-C-language-powerful that I >> will crib here. When PL/1 and Algol68 were being created, and frankly, >> later with Ada and others, there was always a tendency to go overboard. >> But to me, the less-is-more rule applies: C is powerful not only because of >> what is in the language but also because of what Dennis (and Ken) left out. > >IMHO it is less less-is-more and more the *low-level* nature of C. >Didn't IBM too used a "high level" low level language PL/S for MVS? PL/S was quite stripped down ahd had ways to referece specific registers and even include in-line assember. It looked like PL/I but was if anything lower level than C. You are right there were lots of other similar languages like PL/M. I liked PL360, which was a high level assembler using Algolish syntax used to develop Algol W. R's, John From tuhs at tuhs.org Tue May 26 13:27:15 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Mon, 25 May 2026 22:27:15 -0500 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: <20260526032715.keyproidanvcb33o@illithid> [taking a break from the humongous reply I'm writing to the "troff.org" thread] At 2026-05-25T19:52:01-0700, Adam Thornton via TUHS wrote: > On Mon, May 25, 2026 at 6:52 PM Larry McVoy via TUHS > wrote: > > I have a son who is more about theory, he's a math guy. I nudged > > him towards programming, he of course went to python. I nudged him > > towards C and he came back with the best statement ever that I have > > gotten from him: In C, you can feel the machine. Yes, Travis, yes > > you can. That's part of what makes C great. > > > But in this day and age, *can* you? You can feel the machine if that > machine is a PDP-11. But with a modern pipelined SMP architecture, > with prefetch and speculative execution and all that stuff...I don't > think any human *can* feel the machine anymore. > > And I kind of mourn that, which is why I do retrocomputing and why my > heart will always belong to the 6502, but...while C is an accurate > match for what's going on in a single-processor system without any > fancy caching, is it really "feeling the machine" anymore? I agree. I grew up with the somewhat fancier (read: more complicated) Z80 and 6809. It was pretty neat how we could take real-time programming for granted because the processors were wholly deterministic. You could count T-states and you'd be right. No pipelines, no caches, no hardware multiplier that took a variable number of T-states to retire the instruction. When I started my formal education I was terrified of ever taking an analysis of algorithms class because I knew the 80386, which I strongly disliked, was a much more complicated processor than the ones I grew up on. I had a gigantic sense of dread because I thought we were going to be held responsible for predicting on exams the T-state counts the machine would take to retire a whole C function's worth of instructions. A EE major gently informed me that that was in fact crazily hard to do with modern processors, and they didn't behave deterministically anyway, because caches. (The 386 was superscalar but most or all of its successors were, as I recall.) With misconception dispelled, cyclomatic complexity and Big-O notation proved to be a huge relief, and the subject came to more closely resemble the rest of my engineering education: look first at the lowest-order terms! Doug pointed out to me in a conversation a while back that early C was deterministic in the way simple CPUs were. that. I then got to point out that it may well have been...up until the language added structure copying by assignment. (Real 8-bit microcomputer grognards will notice that I've fibbed a little by not mentioning the Z80's LDIR and LDDR instructions and their counterparts that dealt with I/O ports. It'd be a fair point, but I don't remember ever using them in my callow youth. I might have been working from examples written for the 8080, which lacked those instructions. I don't remember using the alternate register set either, which seems crazily negligent to me now.) > Note: I like C. I like Go even more. I have not had to use Rust in > anger yet so I don't really know it. 90% of my day job is Python, and > the rest is mostly TypeScript. I'm not arguing this from a Luddite > perspective, I'm just saying that it has been quite some time since > "what the processor is actually doing" crossed the "human ability to > understand it in detail" threshold. Or at least, *my* human ability. This seems like a good time for me to flog one of my favorite pieces. https://spawn-queue.acm.org/doi/10.1145/3212477.3212479 > I'm not often the smartest bear in the room, but I'm usually not the > dumbest either. Your observation some time ago about "the secret" being that "no one reads the literature" is enough to convince me that you seldom open the office door with the goat behind it. ;-) And since someone mentioned Ada, my favorite language that I've never done real work in...I think that if you took Ada 83 and simply removed the tasking subsystem from it--not because it's bad but because it added weight to the language runtime and because its concurrency model is simply not one the bulk of the industry converged on, even if it was (AIUI) a better fit for hard real-time and high-assurance systems--you'd have a language that would compare favorably to Seventh Edition C and even ANSI C89--except, I think, for line-oriented teletype-style I/O. For some reason, the Ada Committee got literally a bit too precious about the page, and insisted that the output channel maintain a concept of pagination. That's a poor fit with Doug's pipeline paradigm, and adds needless complexity. But I suspect that even with those modifications, no C programmer in the 1980s would have defected to Ada. Mysterious sigils good; intelligible variable names bad. Have a "bflag"ged day! 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 tuhs at tuhs.org Tue May 26 13:30:08 2026 From: tuhs at tuhs.org (Alexis via TUHS) Date: Tue, 26 May 2026 13:30:08 +1000 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: (Adam Thornton via TUHS's message of "Mon, 25 May 2026 19:52:01 -0700") References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: <87ldd6kfun.fsf@gmail.com> Adam Thornton via TUHS writes: > But in this day and age, *can* you? You can feel the machine if > that > machine is a PDP-11. But with a modern pipelined SMP > architecture, with > prefetch and speculative execution and all that stuff...I don't > think any > human *can* feel the machine anymore. Obligatory link to the 2018 piece "C is Not a Low-level Language": https://queue.acm.org/detail.cfm?id=3212479&doi=10.1145%2F3212477.3212479 Alexis. From tuhs at tuhs.org Tue May 26 13:41:47 2026 From: tuhs at tuhs.org (Brian Stuart via TUHS) Date: Tue, 26 May 2026 03:41:47 +0000 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526014541.GA28587@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: On Tue, May 26, 2026 at 1:52 AM Larry McVoy via TUHS wrote: > I have a son who is more about theory, he's a math guy. I nudged him > towards programming, he of course went to python. I nudged him towards > C and he came back with the best statement ever that I have gotten from > him: In C, you can feel the machine. Yes, Travis, yes you can. That's > part of what makes C great. As it should be. It's just as why I always prefer to drive a sports car to a luxury car, why when I did photography, I used my eyes and hands in the darkroom, and why when I play a musical instrument, I play the instrument instead of an abstraction that prevents me from making mistakes. If I can't feel the connection to the car, its designer, and the road, driving stops being fun. If I can't feel the connection to the instrument, I'm fighting against it, rather than it pulling the music out of me. If I can't feel the connection between the language and the transistors, programming stops being fun and becomes a chore, and life is too short to write code that's not fun. As retirement approaches, the chance to withdraw into my own hardware and my own languages is irresistable. BLS P.S. Kids, get off my lawn! And you'll only get my PDP-11 when you pry it from my cold, dead hands! From tuhs at tuhs.org Tue May 26 13:54:27 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Mon, 25 May 2026 22:54:27 -0500 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526032715.keyproidanvcb33o@illithid> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526032715.keyproidanvcb33o@illithid> Message-ID: <20260526035427.ywcg7tfwj5qg2twv@illithid> [self-follow-up to clarify] At 2026-05-25T22:27:19-0500, G. Branden Robinson wrote: > With misconception dispelled, cyclomatic complexity and Big-O notation > proved to be a huge relief, and the subject came to more closely > resemble the rest of my engineering education: look first at the > lowest-order terms! That might be unclear. I mean the lowest-_degree_ terms, in the sense that one constructs a Taylor polynomial to model the function representing runtime or storage consumption. Where the change in the independent variable is near zero, as is routine in differential analysis, higher-degree terms in the polynomial go to zero more quickly than the lower-degree terms. That clarification may not have been an improvement. I know--I'll blame the Sean Carroll book I'm reading. 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 tuhs at tuhs.org Tue May 26 16:38:42 2026 From: tuhs at tuhs.org (Jason Stevens via TUHS) Date: Tue, 26 May 2026 07:38:42 +0100 Subject: [TUHS] Mach 2.6 X113 cross compiled from Win32 as a multiboot ELF module Message-ID: For anyone that's interested I've made a project on github: https://github.com/neozeed/mach25-X113 no new features, I'm using GCC 1.40 or 2.5.8 with an ELF backend to compile the kernel as ELF. This way I can use a GRUB ISO & Qemu to do debugging which has greatly simplified the build/debug loop. It boots into single/multiuser so it's on parity with the old a.out/mach_o kernel. But being able to edit local/compile it. There wasn't all that many changes needed, more so the bootloader patches arguments into the ELF image as it loads, which has greatly aided in this whole thing. I did use AI to make the multiboot bootloader, as I'm no ELF/multiboot wizard. I suspect this would let me do the same with 386BSD for people who like that kind of thing. From tuhs at tuhs.org Tue May 26 23:57:48 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Tue, 26 May 2026 06:57:48 -0700 Subject: [TUHS] [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: <20260526135748.GB16425@mcvoy.com> On Mon, May 25, 2026 at 07:52:01PM -0700, Adam Thornton wrote: > On Mon, May 25, 2026 at 6:52???PM Larry McVoy via TUHS wrote: > > > > > I have a son who is more about theory, he's a math guy. I nudged him > > towards programming, he of course went to python. I nudged him towards > > C and he came back with the best statement ever that I have gotten from > > him: In C, you can feel the machine. Yes, Travis, yes you can. That's > > part of what makes C great. > > > > > But in this day and age, *can* you? Well, you feel it in C a heck of a lot more than in Python. And I think you will always feel it in C. C is a very thin layer over the machine, it's been described as a portable assembly language and I think that is accurate. In higher level languages, a single statement can do a lot, go play with C++ and then come back to C, you will feel the machine. From tuhs at tuhs.org Wed May 27 00:01:48 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Tue, 26 May 2026 07:01:48 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: <20260526140148.GC16425@mcvoy.com> On Tue, May 26, 2026 at 03:41:47AM +0000, Brian Stuart wrote: > On Tue, May 26, 2026 at 1:52???AM Larry McVoy via TUHS wrote: > > I have a son who is more about theory, he's a math guy. I nudged him > > towards programming, he of course went to python. I nudged him towards > > C and he came back with the best statement ever that I have gotten from > > him: In C, you can feel the machine. Yes, Travis, yes you can. That's > > part of what makes C great. > > As it should be. It's just as why I always prefer to drive a sports car to > a luxury car, why when I did photography, I used my eyes and hands in the > darkroom, and why when I play a musical instrument, I play the instrument > instead of an abstraction that prevents me from making mistakes. If I can't > feel the connection to the car, its designer, and the road, driving stops being > fun. If I can't feel the connection to the instrument, I'm fighting against it, > rather than it pulling the music out of me. If I can't feel the connection > between the language and the transistors, programming stops being fun > and becomes a chore, and life is too short to write code that's not fun. > > As retirement approaches, the chance to withdraw into my own hardware > and my own languages is irresistable. > > BLS > > P.S. Kids, get off my lawn! And you'll only get my PDP-11 when you pry > it from my cold, dead hands! Amen to all of this. And I think I've posted this but it is worth a repeat since you mentioned sports cars. When Travis was looking at C, I told him that C is like driving a sports car on a narrow, twisty road with no guard rails and a there is a cliff on one side of the road. So it is not for people who want to look at their phone while driving, that's how you die. On the other hand, if you are a good driver, that narrow, twisty road and that car are glorious. Languages like Rust are all the rage, but they take away a lot of the joy of making stuff work well in C. I get it, there are far more programmers that want to look at their phone than there are programmers who are good enough to program in C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed May 27 00:38:44 2026 From: tuhs at tuhs.org (John P. Linderman via TUHS) Date: Tue, 26 May 2026 10:38:44 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> Message-ID: The observation that "In C, you can feel the machine" resonates with me, but I have a different take. When I am trying to understand a non-trivial program, I need to break it into comprehensible chunks. When a statement is "close to the machine", I can assume it does what I think it does. Since it relies only on hardware, the odds of it being done incorrectly are miniscule. Each such statement is a comprehensible chunk. The way it interacts with variables in the routine containing it are relatively obvious. If a C statement doesn't include something that looks like a subroutine call, it can be understood on its own. If a statement invokes another routine, because that routine is done in software, I may not understand what it does, and it is much more susceptible to being done incorrectly. I dislike call by reference, because it may mess with local variables, increasing the cognitive load on understanding the routine I am looking at. External variables can similarly complicate understanding. If a routine doesn't expose its variables to other routines, I can hope to understand what it does, and "prove" its correctness in isolation; I can defer understanding other routines it calls. Because C doesn't make any sneaky subroutine calls, you can identify such calls lexically. If a statement doesn't explicitly make a call, operation remains "close to the hardware". I couldn't look at a PL/1 statement and determine if it made subroutine calls. I found nasty PL/1 bugs hiding behind apparently simple statements. C code was, for me, much easier to understand. On Mon, May 25, 2026 at 11:42 PM Brian Stuart via TUHS wrote: > On Tue, May 26, 2026 at 1:52 AM Larry McVoy via TUHS > wrote: > > I have a son who is more about theory, he's a math guy. I nudged him > > towards programming, he of course went to python. I nudged him towards > > C and he came back with the best statement ever that I have gotten from > > him: In C, you can feel the machine. Yes, Travis, yes you can. That's > > part of what makes C great. > > As it should be. It's just as why I always prefer to drive a sports car to > a luxury car, why when I did photography, I used my eyes and hands in the > darkroom, and why when I play a musical instrument, I play the instrument > instead of an abstraction that prevents me from making mistakes. If I > can't > feel the connection to the car, its designer, and the road, driving stops > being > fun. If I can't feel the connection to the instrument, I'm fighting > against it, > rather than it pulling the music out of me. If I can't feel the connection > between the language and the transistors, programming stops being fun > and becomes a chore, and life is too short to write code that's not fun. > > As retirement approaches, the chance to withdraw into my own hardware > and my own languages is irresistable. > > BLS > > P.S. Kids, get off my lawn! And you'll only get my PDP-11 when you pry > it from my cold, dead hands! > From tuhs at tuhs.org Wed May 27 00:42:38 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 26 May 2026 07:42:38 -0700 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526140148.GC16425@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> Message-ID: <4D7CFA4B-6126-4665-8757-8610A12060BB@iitbombay.org> On May 26, 2026, at 7:01 AM, Larry McVoy via TUHS wrote: > > Languages like Rust are all the rage, but they take away a lot of the joy > of making stuff work well in C. I get it, there are far more programmers > that want to look at their phone than there are programmers who are good > enough to program in C. That really depends on what is joy to a programmer! At different times in my life I have enjoyed using high level to low level languages. Some just to play with, some for real (or paying) work. They all have their strengths and weaknesses. Writing assembly language code for a regular instruction set machine like Motorola 68K or AMD 29K was an absolute joy, but I wouldn't want to write or maintain large programs in them. I really like Scheme as well as array languages for exploring ideas or algorithms but I wouldn't want to write kernel code in them (though I do think that a researchy OS in Scheme would be a fun exercise, to explore or teach OS concepts). From tuhs at tuhs.org Wed May 27 03:30:35 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Tue, 26 May 2026 13:30:35 -0400 (EDT) Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? Message-ID: <20260526173035.08A0918C075@mercury.lcs.mit.edu> {BCC'ing to TUHS, in an attempt to move to COff} > From: Steve Jenkin > could something like C have improved MULTICS or helped it's success in > the marketplace? The biggest problem of Multics (i.e. the large system of code, as existing and installed at about 100 sites) was i) (to echo John Levine) that it was tied very strongly to Honeywell hardware, and ii) Honeywell management were total bozos, and could/would not produce new, improved, cost-effective hardware. See here: https://multicians.org/hill-mgt.html and related links (e,g, the Palyn report) for a lot more about that. In short, Multics' biggest problem(s), in the real world, were not technical, so technical solutions would not have helped. The 'tie to Honeywell hardware' existed at two levels. First, at a high, conceptual level, Multics was (in the eye of a user) a single-level memory system (_everything_ was an addressable segment), with hardware support. Now, it's true that any Turing machine could emulate any other, but the performance may be considerably slower (there's an example below). Second, at a low level, the Multics PL/1 code was crammed to the gills with declarations like: dcl global_handle bit(36) aligned static; with the word length of the machine in the source. (It's true that C has the opposite prolem - one that's a real issue in writing networking code - other than bit fields, C declarations don't let you be explicit about data sizes.) Multics PL/1 also had extensions (effectively) to support the Multics high-level conceptual model. One is that saying 'foo$bar(arg1, arg2)' called entry point 'bar' in segment 'foo'. Clearly, to do something similar in C, one could write: long_call("foo", "bar", arg1, arg2); where 'long_call()' is an assembler routine that 'does the right thing' - but that will necessarily be considerably slower than the original Multics/PL/1 equialent, which is a single subroutine-call instruction. If one wrote it somewhat differently, as: subr_pointr = long_get_subr_addr("foo", "bar"); (*subr_pointr)(arg1, arg2); then if one only did the call to long_get_subr_addr() once, it would only be slowish the first time one called foo$bar. (That's the inter-segment code syntax; I forget how data worked.) Multics also makes considerable use of conditions (in the 'throw'/'catch' meaning of that). One _can_ add conditions to C (I did it, for a compiler with a recursive descent parser I wrote, and I know of another implementation, using longjmp - mine used assembler versions of 'on()'/'signal()', using standard C subroutine call semantics, along with an 'enhanced' stack frame format [condition handlers stack, so that way I got free unstacking of handlers on subroutine exit]), but it's not part of 'standard' C. In short, it wouldn't be simple to use 'stock' C for Multics (for doing the whole thing, including the OS and system tools, not just applications - the way it used PL/1). Noel From tuhs at tuhs.org Wed May 27 07:04:19 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Wed, 27 May 2026 07:04:19 +1000 Subject: [TUHS] [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526135748.GB16425@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526135748.GB16425@mcvoy.com> Message-ID: On Wed, 27 May 2026 at 00:07, Larry McVoy via TUHS wrote: > In higher level languages, a single statement can do a lot, go play with > C++ and then come back to C, you will feel the machine. > It rather depends on how one writes C++. For an interesting comparison, you should look at Tom Cargill's code in `pi', the source for which is in all research versions from 8th on. That said, you will not find anyone writing C++ like Tom Cargill anymore. From tuhs at tuhs.org Thu May 28 01:50:34 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 27 May 2026 11:50:34 -0400 Subject: [TUHS] Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526140148.GC16425@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> Message-ID: On Tue, May 26, 2026 at 10:02 AM Larry McVoy via TUHS wrote: > [snip BLS's comments about cars, instruments, and programs] > Amen to all of this. And I think I've posted this but it is worth a repeat > since you mentioned sports cars. > > When Travis was looking at C, I told him that C is like driving a sports > car on a narrow, twisty road with no guard rails and a there is a cliff > on one side of the road. So it is not for people who want to look at their > phone while driving, that's how you die. On the other hand, if you are a > good driver, that narrow, twisty road and that car are glorious. But you have also said that if you take someone out on your boat, and they won't wear a flotation device, that's the last time they're going out on your boat. Sports cars can be fun! So can motorcycles. I once raced another jarhead to the main gate at 29 Palms; he was in a Ford Cobra and I was on a Triumph; British engineering on a lean bike versus a V8 in a sleek form factor: who would win?! I let off the throttle when I hit 110 MPH and it was clear that I had. In retrospect, however, that was not a good idea. My Harley can hit that without breaking a sweat, but going that fast simply isn't smart: if I'd hit a pothole wrong? It could have been a bad day; I probably wouldn't have cared since I'd be dead, though. > Languages like Rust are all the rage, but they take away a lot of the joy > of making stuff work well in C. I get it, there are far more programmers > that want to look at their phone than there are programmers who are good > enough to program in C. The framing of "good enough to program in C" is the wrong way to look at it. If the sports car goes off the side of the mountain, 99 times out of 100 the only one who ends up in the morgue is the driver: tragic, perhaps, but one's own damn fault. On the other hand, if the school bus goes off the road, the consequences are far worse. Most of the time software is Not a sports car; it's more like a school bus loaded with kids. Side note: when I was stationed in Twentynine Palms, I'd ride over to LA on the weekends occasionally to see friends. Coming down out of the high desert heading towards Palm Springs, you went through a series of very twisty roads; lots of tire marks along the highway where people drove fast for "fun", drifted around curves; that kind of thing. And one set I always remember that went OFF the road, and disappeared over the edge of a cliff; a 30 foot drop on the other side: I'm pretty sure no one survived that. You sure you want to take that risk? Rust isn't for people who want to look at their phones; it's for people who value life jackets and seatbelts and think that school buses should be as safe as we can make them. I would argue that it demands _more_ of the programmer to write correct Rust than it does to write correct C, particularly if any amount of `unsafe` is involved; but if you do, the guarantees that the language gives you are much stronger. Safe Rust code cannot segfault or have data races; period. On the other hand, it's super easy to inadvertently stumble into undefined behavior and segfaults, even in extremely well-written C. Here's an example from the bitkeeper source. I randomly looked at https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/bkd_server.c, and notice the following on lines 58 and 59: ``` | while (nav[i++] = av[j++]); | assert(i < 100); ``` Here, the contents of the string array `av` are copied into `nav`, which is defined as, `char *nav[100];`. Near as I can tell, this is called directly with an only slightly-modified version of the arguments to `main`, but nothing checks that the input argument vector will not overflow `nav` before the loop. The `assert` is obviously meant to catch this, but since it happens _after_ the loop, by the time you run into it, you've probably already clobbered what was around `nav` on the stack; indeed, I can trigger this on a local build, and the resulting stack frame is junk. Moreover, the code as written is wrong: the array has space for 100 elements, thus indices 0..99 are valid. Suppose that i==99'th element is the terminating nil pointer, then the `i++` index expression would set nav[99] and then set i to 100; that's perfectly valid, but in that case, the `assert` will still fire: that is, the last element in `nav` is inaccessible as written. By contrast, in Rust, if one were copying into `nav: [*mut std::ffi::c_char; 100]`, then in a build with array bounds checking turned on (the default), this would trap on an attempt to access an element beyond the end of the array. More idiomatically, however, one would probably use a `Vec<*mut std::ffi::c_char>` and copy into it, letting it handle the details of dynamically sizing the underlying vector. Of course, this is kind of a silly example: only a jerk is going to give more than 100 arguments to `bk` in order to trigger this bug, but the point is, you're going to invariably find this kind of thing in _any_ large C code base, even ones written by legitimate experts extremely familiar with the language. - Dan C. From tuhs at tuhs.org Thu May 28 02:51:01 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Wed, 27 May 2026 09:51:01 -0700 Subject: [TUHS] UNIX at $(YOUR_UNIVERSITY) Message-ID: Last weekend, we had great fun on a panel at Princeton Reunions about UNIX before, during, and after Princeton. https://reunions.princeton.edu/event/unix-before-during-and-after-princeton-adventures-in-computer-science/ I had posted the notice on socials, and Norm W. said "do Toronto next". Which is a great idea! Toronto, Berkeley, Wollongong, CMU, ... I'd travel just to attend! (well, maybe not down under) Any volunteers? From tuhs at tuhs.org Thu May 28 04:01:05 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 27 May 2026 11:01:05 -0700 Subject: [TUHS] [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> Message-ID: <20260527180105.GA29244@mcvoy.com> On Wed, May 27, 2026 at 11:50:34AM -0400, Dan Cross wrote: > On Tue, May 26, 2026 at 10:02???AM Larry McVoy via TUHS wrote: > > [snip BLS's comments about cars, instruments, and programs] > > Amen to all of this. And I think I've posted this but it is worth a repeat > > since you mentioned sports cars. > > > > When Travis was looking at C, I told him that C is like driving a sports > > car on a narrow, twisty road with no guard rails and a there is a cliff > > on one side of the road. So it is not for people who want to look at their > > phone while driving, that's how you die. On the other hand, if you are a > > good driver, that narrow, twisty road and that car are glorious. > > But you have also said that if you take someone out on your boat, and > they won't wear a flotation device, that's the last time they're going > out on your boat. Yep. It's a liability thing, if I don't get them home safe, I can be sued for loss of life. > If the sports car goes off the side of the mountain, 99 times out of > 100 the only one who ends up in the morgue is the driver: tragic, > perhaps, but one's own damn fault. On the other hand, if the school > bus goes off the road, the consequences are far worse. Most of the > time software is Not a sports car; it's more like a school bus loaded > with kids. Fair point. > On the other hand, it's super easy to inadvertently stumble into > undefined behavior and segfaults, even in extremely well-written C. > Here's an example from the bitkeeper source. I randomly looked at > https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/bkd_server.c, > and notice the following on lines 58 and 59: > > ``` > | while (nav[i++] = av[j++]); > | assert(i < 100); > ``` We have regression tests that throw all sort of random noise at every bk command. > Here, the contents of the string array `av` are copied into `nav`, > which is defined as, `char *nav[100];`. Near as I can tell, this is > called directly with an only slightly-modified version of the > arguments to `main`, but nothing checks that the input argument vector > will not overflow `nav` before the loop. The `assert` is obviously > meant to catch this, but since it happens _after_ the loop, by the > time you run into it, you've probably already clobbered what was > around `nav` on the stack; indeed, I can trigger this on a local > build, and the resulting stack frame is junk. Moreover, the code as > written is wrong: the array has space for 100 elements, thus indices > 0..99 are valid. Suppose that i==99'th element is the terminating nil > pointer, then the `i++` index expression would set nav[99] and then > set i to 100; that's perfectly valid, but in that case, the `assert` > will still fire: that is, the last element in `nav` is inaccessible as > written. And yet, that code has been running for decades with out problems. Yeah, it could be cleaner, but we had other work to do. You are all worked up about a non-problem. > Of course, this is kind of a silly example: only a jerk is going to > give more than 100 arguments to `bk` in order to trigger this bug, but > the point is, you're going to invariably find this kind of thing in > _any_ large C code base, even ones written by legitimate experts > extremely familiar with the language. Indeed. Except it was not ever a problem. Your stance reminds me a little of Bart Miller's fuzz paper. Yep, you pass random garbage to every program in /usr/bin and you will find all sorts of bugs. But is that useful information if everyone is using those programs without triggering those bugs? Back in the day, Coverity used BitKeeper and we got to use their tool on our source base. It was useless, it found all sorts of stuff, but it was all like your example, a bug in theory but not in practice. If it had found any real bugs, we would have been pleased. It did not. You are welcome to Rust, given the caliber of many programmers today, I can see the value. I took a different approach, we hired excellent programmers and our stuff worked. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu May 28 05:56:52 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Wed, 27 May 2026 12:56:52 -0700 Subject: [TUHS] [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527180105.GA29244@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: On Wed, May 27, 2026 at 11:01 AM Larry McVoy via TUHS wrote: > I took a different approach, we hired excellent programmers > and our stuff worked. > > This is probably a COFF question, but I'm interested in your process for hiring excellent programmers. CCing to COFF and I suggest we continue it there. Through too much of my career, choosing whom to hire has been plagued by "we end up picking people a lot like the people already on the team," which, while it maybe helps team cohesion, isn't a great way to get fresh blood and new perspectives, but also by the even-less-tractable problem of "people who are good at interviewing, know their algorithms, whatever, but once they start working, they're not really very good at thinking in the context of the actual problem before them." And that itself can come in several flavors. One is the person who interviews well but doesn't actually do good software engineering, because they've optimized for interviewing, not for shipping maintainable code, or working on a team where their output has to play nice with other people's output, or whatever, the point being, they sounded good for the two or three hours you sent with them, but they don't actually produce good work. Another is even worse: the person who really *is* all that good, but who's a jerk that no one wants to work with. Figuring out who's going to work well as an addition to an existing team seems like a really difficult problem, particularly the Toxic Genius problem. I'd *much* rather work with someone who's OK-to-good at their job and is easy to work with, doesn't get defensive if you ask "why X rather than Y?", et cetera, than someone who's absolutely brilliant but everyone dreads getting their code reviewed by them, or even worse, reviewing code that the Toxic Genius has put a lot of ego into (which is generally all of it). My current boss is really good at hiring people who genuinely like working together (and in my estimation, we're a highly competent team), and she's written down some of her methodology down in https://sqr-081.lsst.io/, but I'm very interested in how other people do this as well. Adam From tuhs at tuhs.org Thu May 28 06:42:54 2026 From: tuhs at tuhs.org (Jeffrey H. Johnson via TUHS) Date: Wed, 27 May 2026 16:42:54 -0400 Subject: [TUHS] [COFF] Re: Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: I'm going to jump in here and say that it is absolutely possible to write perfectly good C code that doesn't have these kinds of bugs or issues that is also incredibly portable, free of all undefined behaviors, and can run on every platform, including the really weird ones, and anyone who says it doesn't or you can't do so is cutting corners. Does it take a lot more time and discipline, yes. It also takes a lot longer to accomplish a lot less, but C absolutely gives you the tools you need to produce bug-free code. In fact, if you really want to get into it, you can produce code that is not only bug-free, but tools exist in the formal verification realm that allow you to prove mathematically the absence of bugs, including memory safety, in C code. You can take a look at this CRC utility that I recently wrote, because it's more an example of how I would a write universally portable utility of this type that's intended to be bug-free, but not going to the expense of formal verification to make it provably so. https://gitlab.com/dps8m/crc It was carefully constructed to be portable and correct on every platform with a standard s-onforming C compiler. It works equally on ancient pre‑ANSI / "C86" / K&R C compilers, environments providing deficient stdio implementations, environments with broken (or completely missing) division or modulo math operations, systems where NULL is not equal to zero (e.g. Honeywell 600/6000‑series), systems using one's‑complement integer representation (e.g., Unisys ClearPath Dorado / OS 2200 with UCS C), systems with character sizes other than 8 bits (e.g., DEC PDP‑10, H6000, Unisys), and systems using non‑ASCII character sets (e.g., IBM mainframes, Unisys MCP), or even systems using non-ASCII/non-EBCDIC character sets. It has it's own internal implementation of arbitrary precision math code that's slow but stable that I use elsewhere. It only needs the C compiler to provide one storage type with a width at least as wide as the 32‑bit CRC. Even compilers for the Commodore 64 and Apple II such as Vbcc can fit the bill here. It supports systems with characters types of least 8 bits, but is happy with 9 bits, or 12 bits, 17-bit bit or even 32-bit chars. The same source file works on Multics, TOPS-20, CP/M-86, CP/M-80, MS-DOS, Windows, ELKS, Atari ST, Amiga, and every UNIX system, and really should be free bugs and undefined behavior on all platforms. C can do it all. -- Jeffrey H. Johnson trnsz at pobox.com From tuhs at tuhs.org Thu May 28 07:07:28 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 27 May 2026 17:07:28 -0400 Subject: [TUHS] C vs the world (was Re: Hypothetical: Could MULTICS have been written in C, if available?) Message-ID: On Tue, May 27, 2026 Larry McVoy via TUHS wrote: > On Wed, May 27, 2026 at 11:50:34AM -0400, Dan Cross wrote: > > On Tue, May 26, 2026 at 10:02???AM Larry McVoy via TUHS wrote: > > > [snip BLS's comments about cars, instruments, and programs] > > > Amen to all of this. And I think I've posted this but it is worth a repeat > > > since you mentioned sports cars. > > > > > > When Travis was looking at C, I told him that C is like driving a sports > > > car on a narrow, twisty road with no guard rails and a there is a cliff > > > on one side of the road. So it is not for people who want to look at their > > > phone while driving, that's how you die. On the other hand, if you are a > > > good driver, that narrow, twisty road and that car are glorious. > > > > But you have also said that if you take someone out on your boat, and > > they won't wear a flotation device, that's the last time they're going > > out on your boat. > > Yep. It's a liability thing, if I don't get them home safe, I can be > sued for loss of life. One hopes the consequences for a crashing program are not nearly so dire. However, we find software running in all sorts of strange places now; how many of the regulars on this list have code running on Mars? I'll bet more than one has something that made it onto a rover. > > If the sports car goes off the side of the mountain, 99 times out of > > 100 the only one who ends up in the morgue is the driver: tragic, > > perhaps, but one's own damn fault. On the other hand, if the school > > bus goes off the road, the consequences are far worse. Most of the > > time software is Not a sports car; it's more like a school bus loaded > > with kids. > > Fair point. > > > On the other hand, it's super easy to inadvertently stumble into > > undefined behavior and segfaults, even in extremely well-written C. > > Here's an example from the bitkeeper source. I randomly looked at > > https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/bkd_server.c, > > and notice the following on lines 58 and 59: > > > > ``` > > | while (nav[i++] = av[j++]); > > | assert(i < 100); > > ``` > > We have regression tests that throw all sort of random noise at every bk > command. I believe you. The code I'm looking at is good, solid, readable C. It also has errors. But that's not a dig on bitkeeper; pretty much any large source base has errors. > > Here, the contents of the string array `av` are copied into `nav`, > > which is defined as, `char *nav[100];`. Near as I can tell, this is > > called directly with an only slightly-modified version of the > > arguments to `main`, but nothing checks that the input argument vector > > will not overflow `nav` before the loop. The `assert` is obviously > > meant to catch this, but since it happens _after_ the loop, by the > > time you run into it, you've probably already clobbered what was > > around `nav` on the stack; indeed, I can trigger this on a local > > build, and the resulting stack frame is junk. Moreover, the code as > > written is wrong: the array has space for 100 elements, thus indices > > 0..99 are valid. Suppose that i==99'th element is the terminating nil > > pointer, then the `i++` index expression would set nav[99] and then > > set i to 100; that's perfectly valid, but in that case, the `assert` > > will still fire: that is, the last element in `nav` is inaccessible as > > written. > > And yet, that code has been running for decades with out problems. Yeah, > it could be cleaner, but we had other work to do. You are all worked up > about a non-problem. I am hardly "all worked up about" it. It was just something I saw when I casually looked at the code and it jumped out to me as clearly a bug. If I saw it in a code review, I would flag it, whether it was likely to happen in practice or not. > > Of course, this is kind of a silly example: only a jerk is going to > > give more than 100 arguments to `bk` in order to trigger this bug, but > > the point is, you're going to invariably find this kind of thing in > > _any_ large C code base, even ones written by legitimate experts > > extremely familiar with the language. > > Indeed. Except it was not ever a problem. Your stance reminds me a little > of Bart Miller's fuzz paper. Yep, you pass random garbage to every program > in /usr/bin and you will find all sorts of bugs. But is that useful > information if everyone is using those programs without triggering those > bugs? That's the thing: `gets` wasn't a serious problem until rtm used it to overflow the stack and execute arbitrary code on a bunch of VAXen and Sun3s. So it is with most software bugs; they're never really a problem until they are. The argument that an unrealized bug isn't really a bug feels compelling until you realize that it might be a timebomb waiting to happen; and in particular when you consider that software is often used in ways that no one foresees when it's first written (see Paul's note). It's easy to deride Miller's thing as impractical or frivolous, but that is cold comfort if a bug hsi report highlighted turned into a root exploit because someone exec'ed an affected program from a setuid binary with unsanitized user input. Surely we all remember the bugs back in the 1990s where people got root by setting `$PATH` and `$IFS` before running a setuid binary that invoked `system()` or `popen()`? One wonders how many of the bugs Miller mentioned ended up used in exploits after the stack smashing paper 6 years later? > Back in the day, Coverity used BitKeeper and we got to use their tool on > our source base. It was useless, it found all sorts of stuff, but it was > all like your example, a bug in theory but not in practice. *Yet*. A bug in theory but not in practice *yet*. But this begs the question, why `assert` at all? The `assert` here is simply not correct. Besides, fixing this is trivial: | while (i < 100 && nav[i++] = av[j++]); | assert(0 < i && i <= 100 && nav[i - 1] == NULL); Or even better: |/* stuff this in a header somewhere */ |#define nitems(A) (sizeof(A)/sizeof((A)[0])) | | ... | | while (i < nitems(nav) && nav[i++] = av[j++]); | assert(0 < i && i <= nitems(nav) && nav[i - 1] == NULL); Anyway, it seems to me that if you have a tool flagging things like that, where the fixes are easy, there's no reason not to just implement them. I consider it an insurance policy against the future. The situation is even worse in C, because the language is only informally specified, the specification is not tied to the behavior of real computers, UB is so non-obvious, and for whatever weird reason, the compiler people now have this sadistic hatred of their users and will take advantage of any and every instance of UB to make a microbenchmark go faster at the expense of real world code. That program that's worked _perfectly_ for decades may well delete a bunch of data when built with some point revision of a compiler and invoked in an unexpected way that wasn't covered in the test suite, all because there was some random bit of UB lurking somewhere. And if you complain to the compiler people? "Tough; you're the one who added the UB." No matter how we may feel about the language, this is a real problem. See also, Yodaiken's paper: https://arxiv.org/pdf/2201.07845 Though in defense of C, people who are fed up with the situation are joining the committee and trying to address this. There's a UB working group that's actively trying to reduce it the amount of it in the language and the effects it can actually have. > If it had found any real bugs, we would have been pleased. It did not. See above. Bluntly, this sounds like hubris. > You are welcome to Rust, given the caliber of many programmers today, I can > see the value. I took a different approach, we hired excellent programmers > and our stuff worked. I have every confidence that the team was stellar, that it did work, and beyond that that it worked very, very well. That said, there is a tendency on this list to comment on the "caliber of many programmers today", and not in a good way. I would invite people who do that to perhaps take a moment to consider their preconceptions, and to reflect on whether things are really as different now as they were back then, and to the extent that they are, ask what has actually changed? Perhaps it's less that the kids these days are lacking the intrinsic motivation, focus, and intestinal fortitude to competently program in C, but that they're doing so in an environment that is actively hostile to them, and is far, far more complex than it was 30 years ago. The blunt reality is that the C of today is not the C of your (or even my: I have no brown left in my hair; this color is silver, thank you very much) youth. Anyway, all I'm really saying is that maybe, just maybe, the folks in the trenches have a perspective worth more than I often see it given credit for. - Dan C. From tuhs at tuhs.org Thu May 28 07:28:05 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 27 May 2026 14:28:05 -0700 Subject: [TUHS] [SPAM] Re: Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: <20260527212805.GB29244@mcvoy.com> On Wed, May 27, 2026 at 12:56:52PM -0700, Adam Thornton wrote: > On Wed, May 27, 2026 at 11:01???AM Larry McVoy via TUHS wrote: > > > I took a different approach, we hired excellent programmers > > and our stuff worked. > > > > > This is probably a COFF question, but I'm interested in your process for > hiring excellent programmers. CCing to COFF and I suggest we continue it > there. Strangely enough, a lot of the same stuff your current boss wrote up. The technical part is pretty easy, the core of my team were all top 1% programmers. Those people tend to recognize that talent up front. We had two compatibility tests and one question (that well over 90% of programmers fail). If we needed you to sweep the floors, would you? We asked ourselves if the recruit passed the super market test. If you saw them at Safeway do you want to go talk to them or do you want to hide in another isle? The technical (sort of) question was from me and it had a lot to do with the fact that we were a small team and I wasn't interested in managing a large team: Tell me about something that you built, at least 10 other people have used it without contacting you other than to thank you. By "built" I mean you identified the problem, came up with a solution, packaged it up, announced it on comp.sources.whatever (or hackernews for you youngsters). You did the README, the man pages, any web support needed. You wrote test cases. You did *everything*. No support staff. I had an example that I did as a student, I wanted to have regexp version of mv/cp. I called them move.c and copy.c and did a shell function like so: function mv { case "$1" in *=*) move $*;; *) /bin/mv $* esac } and then you could do $ mv =.c =.c++ # bad example, in poor taste :-) I wrote the code and docs and packaged them up into a shar file and announced on comp.sources decades ago. My example was delibrately choosen to be something simple. Complexity was not the point, completeness was. Very, very few people passed this test. I hired people who didn't but I liked working with the people who did, better. There is something satisfying about working with someone who understands what "it's done" actually means. All the engineers interviewed every engineering candidate so other folks may have had other questions. I remember there being widespread agreement on the sweep the floors thing and the supermarket thing. I believe both of those came from Bill Moore (ZFS guy), he had gotten them from other startups. --lm From tuhs at tuhs.org Thu May 28 08:12:02 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 27 May 2026 15:12:02 -0700 Subject: [TUHS] [SPAM] Re: C vs the world (was Re: Hypothetical: Could MULTICS have been written in C, if available?) In-Reply-To: References: Message-ID: <20260527221202.GC29244@mcvoy.com> On Wed, May 27, 2026 at 05:07:28PM -0400, Dan Cross wrote: > *Yet*. A bug in theory but not in practice *yet*. But this begs the > question, why `assert` at all? The `assert` here is simply not > correct. The assert was there in case this ever turns into an actual bug. I'm sure there are 100s or 1000s of "bugs" like this, if nobody ever hits it, why expend resources on a perceived problem? > > If it had found any real bugs, we would have been pleased. It did not. > > See above. Bluntly, this sounds like hubris. Not gonna engage any more deeply, I'm retired, especially from bike shed arguments like this. > That said, there is a tendency on this list to comment on the "caliber > of many programmers today", and not in a good way. I would invite > people who do that to perhaps take a moment to consider their > preconceptions, and to reflect on whether things are really as > different now as they were back then, and to the extent that they are, > ask what has actually changed? I base my comments on discussion I've had with a bright young kid who worked on some tool that finds bugs in binaries. It all sounded very difficult to me. When I asked wouldn't it be easier to hire people that didn't create these bugs. He insisted that programmers like that were nowhere to found. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu May 28 09:03:10 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 27 May 2026 16:03:10 -0700 Subject: [TUHS] UUNET Message-ID: https://en.wikipedia.org/wiki/UUNET Does someone (maybe Rich Salz?) know how it transformed from a USENIX infused non-profit to a for-profit? Controversial at the time? From tuhs at tuhs.org Thu May 28 09:07:02 2026 From: tuhs at tuhs.org (David Arnold via TUHS) Date: Thu, 28 May 2026 09:07:02 +1000 Subject: [TUHS] [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527180105.GA29244@mcvoy.com> References: <20260527180105.GA29244@mcvoy.com> Message-ID: <55A3420F-7D74-45C7-BE43-73B4F92FC52D@pobox.com> > On 28 May 2026, at 04:01, Larry McVoy via TUHS wrote: <…> > And yet, that code has been running for decades with out problems. Yeah, > it could be cleaner, but we had other work to do. You are all worked up > about a non-problem. One of the biggest mindset changes required of programmers today is to assume malicious intent on the part of every user. d From tuhs at tuhs.org Thu May 28 09:25:38 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 27 May 2026 19:25:38 -0400 Subject: [TUHS] UUNET In-Reply-To: References: Message-ID: I’ll try to offer a better answer when I’m near my computer, but the short answer is not at all. It was planned that way. I’ll have to peak at what Wikipedia says and see what they have reported. But as a USENIX BOD member, the hope was that it would be “self sufficient.” We couldn’t have been more pleased to see it work out. As it says on my shirt and silver watch: “President Emeritus USENIX” 😉 Sent from a handheld expect more typos than usual On Wed, May 27, 2026 at 7:03 PM Kevin Bowling via TUHS wrote: > https://en.wikipedia.org/wiki/UUNET > > Does someone (maybe Rich Salz?) know how it transformed from a USENIX > infused non-profit to a for-profit? Controversial at the time? > From tuhs at tuhs.org Thu May 28 10:23:47 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 27 May 2026 19:23:47 -0500 Subject: [TUHS] C vs the world (was Re: Hypothetical: Could MULTICS have been written in C, if available?) In-Reply-To: References: Message-ID: <20260528002347.is4xttziyyibikj4@illithid> At 2026-05-27T17:07:28-0400, Dan Cross via TUHS wrote: > The situation is even worse in C, because the language is only > informally specified, the specification is not tied to the behavior of > real computers, UB is so non-obvious, and for whatever weird reason, > the compiler people now have this sadistic hatred of their users and > will take advantage of any and every instance of UB to make a > microbenchmark go faster at the expense of real world code. You ask what the reason for that is. Why have we seen contretemps like that over the Dhrystone and Whetstone benchmarks in the 1980s? Why have we seen outright scandals like those of Volkswagen and BMW with respect to diesel engine emissions anti-pollution compliance standards? At what level were the decisions to "sex up" the results of these metrics? What sort of role makes a mission of proving Goodhart's Law time and again? Maybe the compiler writers were, more often than not, duty-minded folks who stopped what they were programming (or thinking), and swept the floors when you told them to. Maybe they were affable folks to meet in the aisle at Safeway, and would reflect your coolness back at you as you bent their ear. If you seek the root cause of the sadism, I suggest it's easily found. > Though in defense of C, people who are fed up with the situation are > joining the committee and trying to address this. There's a UB > working group that's actively trying to reduce it the amount of it in > the language and the effects it can actually have. And, we're told, making the language "suck more" with every proposal. > > If it had found any real bugs, we would have been pleased. It did > > not. > > See above. Bluntly, this sounds like hubris. Yup. > That said, there is a tendency on this list to comment on the "caliber > of many programmers today", and not in a good way. I would invite > people who do that to perhaps take a moment to consider their > preconceptions, and to reflect on whether things are really as > different now as they were back then, and to the extent that they are, > ask what has actually changed? > > Perhaps it's less that the kids these days are lacking the intrinsic > motivation, focus, and intestinal fortitude to competently program in > C, but that they're doing so in an environment that is actively > hostile to them, and is far, far more complex than it was 30 years > ago. The blunt reality is that the C of today is not the C of your > (or even my: I have no brown left in my hair; this color is silver, > thank you very much) youth. Anyway, all I'm really saying is that > maybe, just maybe, the folks in the trenches have a perspective worth > more than I often see it given credit for. One of the slides in Paul Krugman's Nobel Prize lecture said simply this: * Listen to the gentiles. I expect that advice is about as well-received as Krugman himself is, in certain quarters. But I like think that this viewpoint was internal, implicit wisdom at the Bell Labs CSRC. But possibly I, too, am romanticizing the past... 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 tuhs at tuhs.org Thu May 28 11:36:33 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Wed, 27 May 2026 21:36:33 -0400 Subject: [TUHS] UUNET In-Reply-To: References: Message-ID: Clem will know the details, but the only controversy was when uunet reincorporated and was no longer a not-for-profit entity as I recall. On Wed, May 27, 2026, 7:25 PM Clem Cole via TUHS wrote: > I’ll try to offer a better answer when I’m near my computer, but the short > answer is not at all. It was planned that way. I’ll have to peak at what > Wikipedia says and see what they have reported. But as a USENIX BOD member, > the hope was that it would be “self sufficient.” We couldn’t have been > more pleased to see it work out. > > As it says on my shirt and silver watch: “President Emeritus USENIX” 😉 > > > Sent from a handheld expect more typos than usual > > On Wed, May 27, 2026 at 7:03 PM Kevin Bowling via TUHS > wrote: > > > https://en.wikipedia.org/wiki/UUNET > > > > Does someone (maybe Rich Salz?) know how it transformed from a USENIX > > infused non-profit to a for-profit? Controversial at the time? > > > From tuhs at tuhs.org Thu May 28 11:43:09 2026 From: tuhs at tuhs.org (al kossow via TUHS) Date: Wed, 27 May 2026 18:43:09 -0700 Subject: [TUHS] the true reason why c++ always wins Message-ID: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> https://www.youtube.com/watch?v=I7fEsbksKRE this video is disturbing at so many levels if you follow the Gabriel paper links, the one missing is https://blog.reverberate.org/2011/04/eintr-and-pc-loser-ing-is-better-case.html look... pretty flowers From tuhs at tuhs.org Thu May 28 12:40:59 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 27 May 2026 21:40:59 -0500 Subject: [TUHS] Seeking troff sources for "The C Book" by Mike Banahan, Declan Brady, and Mark Doran Message-ID: <20260528024059.23b3obcwhsnruoot@illithid> Hi folks, The aforementioned authors put the book under a permissive license some years ago, roughly along BSD 2-clause ("Simplified") or MIT/Expat terms. https://publications.gbdirect.co.uk/c_book/copyright.html While originally written using troff--and looking stylistically quite similar to works by Kernighan in the 1980s--the authors converted it to TeX at somepoint. I have a notion to convert it back, and embark upon a project with it. I tried emailing the contact address at the aforementioned site but got a permanent failure. Does anyone have those troff sources, or have a connection to one of the authors that might make it possible to obtain them? 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 tuhs at tuhs.org Thu May 28 14:01:37 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 27 May 2026 23:01:37 -0500 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> Message-ID: <20260528040137.p6ebgcz6nyi7ldpt@illithid> At 2026-05-27T18:43:09-0700, al kossow via TUHS wrote: > https://www.youtube.com/watch?v=I7fEsbksKRE > > this video is disturbing at so many levels Lacking patience, I read the transcript instead. > if you follow the Gabriel paper links, the one missing is > > https://blog.reverberate.org/2011/04/eintr-and-pc-loser-ing-is-better-case.html This is a good resource, and sheds much light on a frustrating problem. For me, the heart of the matter is this quote of Stevens's _APUE_: >> A characteristic of earlier UNIX systems is that if a process caught >> a signal while the process was blocked in a "slow" system call, the >> system call was interrupted. The system call returned an error and >> `errno` was set to `EINTR`. This was done under the assumption that >> since a signal occurred and the process caught it, there is a good >> chance that something has happened that should wake up the blocked >> system call. [...] The problem with interrupted system calls is that >> we now have to handle the error return explicitly. I submit that there are couple of ways to cut this Gordian Knot, one "pragmatic", and one fundamental. The pragmatic one could have been done, to all our benefit, ages ago. The pragmatic solution ---------------------- Better libraries. Period. Userspace programs generally shouldn't be making system calls directly. Instead you should have a library that handles interfacing with the system for you. A library API has more flexibility than the OS kernel, and (paradoxically) can _permit_ more flexibility in the system call interface by advertising "legacy" entry points for system calls that change their signatures or disappear. (I propose that Unix's historical failure to provide any such thing is what prompted Linux Torvalds to proclaim his Iron Rule about not ever breaking userspace.[1] With a library layer and a bit more type discipline than early C had, lseek(2) could have remained simply seek(2). I think I've heard someone on this list observe that this is how Microsoft Windows (NT and its successors?) works. I can imagine the objections. (1) If Microsoft's doing it, it must be wrong. Well, that's not a bad way to bet, but sometimes Microsoft does the right thing after first trying every wrong way they can think of, and eventually tiring of getting burned. (2) "I'm a C programmer and I'm close to the metal and therefore I go straight to system calls". Fine, but then your app needs to do what the library would have been doing: having shims to abstract the version of the OS kernel, handling interrupted system calls, and so forth. I think I've posted here before about how the grudging acceptance of a `-u` flag to cat(1) in Eighth Edition Unix, and the vigorous rejection of any _other_ flags to it, was a symptom of people not really thinking of that program as an application, but as a test apparatus for the kernel. The latter is not, I submit, an appropriate first-order purpose for a user-facing application. By _all_ means, ship a kernel-testing apparatus with the OS! But it doesn't need to live in the $PATH. If one accepts that perspective, the flutter of other flags waving from cat's tail becomes less offensive. The fundamental solution ------------------------ ...arises from consideration of this clause of Stevens. 'if a process caught a signal while the process was blocked in a "slow" system call' My thesis: An OS kernel should not _have_ "slow" system calls. The modern Linux kernel is festooned with things called "worker threads" in an attempt to solve the same problem.[2] (I presume successfully.) But because Linux is still monolithic--and has to be, lest its lead author's now largely achieved objective of "world domination"[3] be squandered--it has an ever-growing set of worker threads as its revisions steadily find more things for idle cores to do. This strategy isn't wrong or stupid, but in my view it quietly concedes an argument that Torvalds and his acolytes declared themselves as having prevailed in over 30 years ago. You _could_ reach the same point, with more easily managed permission/ security boundaries (I claim), by employing a microkernel design. And let us please forever erase, or at least suffix a fat asterisk to, the name "Mach" from association with microkernels. That was indeed the status its promulgators hoped for, but by starting with the BSD kernel and cutting it down, instead of building one up from nothing, they picked an approach that frustrated their objectives. https://cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93improving.pdf Thus my enthusiasm for microkernels. Yes, context switches are costly, and mode switches are more costly still. Where these costs are unbearable, you either need more CPU, more memory, or to move away from a general-purpose OS kernel. Solve your problem in a free-standing, not a hosted, runtime environment. As we've seen, any proper engineering problem requires making tradeoffs somewhere. (If it doesn't, it's an arithmetic problem.) An OS kernel, in days of yore a "job monitor", was supposed to be a small, lean thing of minimal footprint that perturbed the availability of CPU cycles and RAM storage to the "real programs"--the _jobs_--as little as possible. But if we count lines of code, monolithic (or semi-monolthic, "modular") kernels are some of the biggest software projects in the world, with the ones we've all heard of weighing in at tens of millions of lines. https://interestingengineering.com/lists/whats-the-biggest-software-package-by-lines-of-code Zero-copy operations are not a silver bullet, either. They can be beautiful but you then have to spend more time considering whose responsibility it is to the validate the data in shared buffers, lest you end up with _no one_ taking responsibility for it...and suffering security pwnage. While researching this message I happened across the following paper proposing a dedicated memory allocator for I/O operations in the Linux kernel. https://netdevconf.info/0x15/papers/1/maio_netdev0x15.pdf I don't know what has become of that work. To me, the very existence of {e,}BPF is a concession that monokernels are too complex, and the proposed MAIO (from the foregoing paper) suggests the same. All right, tell me how I'm wrong! :) Regards, Branden [1] https://lkml.org/lkml/2012/12/23/75 As is the way of iron rules, people have found ways to game them. https://lwn.net/Articles/1070072/ [2] https://docs.kernel.org/core-api/workqueue.html [3] https://www.linuxjournal.com/article/36 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Thu May 28 15:41:41 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 27 May 2026 22:41:41 -0700 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <20260528040137.p6ebgcz6nyi7ldpt@illithid> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> Message-ID: <2A034B99-B753-4412-9668-290039E52DAF@iitbombay.org> While I am a fan of microkernels, they won't solve the problem of EINTR. The real issue is that completion of such a syscall is *beyond* the control of the process. The call is not necessarily *slow*, it is just that it may or not eventually finish. No matter how you construct your software, this situation doesn't go away. If you only return control *after* reading an entire buffer's worth from the net, the user will be quite frustrated their ^C will have no effect. There is no timeout constant that is right either. Let the user decide whether they want to wait for ever or abort. > On May 27, 2026, at 9:01 PM, G. Branden Robinson via TUHS wrote: > > At 2026-05-27T18:43:09-0700, al kossow via TUHS wrote: >> https://www.youtube.com/watch?v=I7fEsbksKRE >> >> this video is disturbing at so many levels > > Lacking patience, I read the transcript instead. > >> if you follow the Gabriel paper links, the one missing is >> >> https://blog.reverberate.org/2011/04/eintr-and-pc-loser-ing-is-better-case.html > > This is a good resource, and sheds much light on a frustrating problem. > > For me, the heart of the matter is this quote of Stevens's _APUE_: > >>> A characteristic of earlier UNIX systems is that if a process caught >>> a signal while the process was blocked in a "slow" system call, the >>> system call was interrupted. The system call returned an error and >>> `errno` was set to `EINTR`. This was done under the assumption that >>> since a signal occurred and the process caught it, there is a good >>> chance that something has happened that should wake up the blocked >>> system call. [...] The problem with interrupted system calls is that >>> we now have to handle the error return explicitly. > > I submit that there are couple of ways to cut this Gordian Knot, one > "pragmatic", and one fundamental. The pragmatic one could have been > done, to all our benefit, ages ago. > > The pragmatic solution > ---------------------- > > Better libraries. Period. Userspace programs generally shouldn't be > making system calls directly. Instead you should have a library that > handles interfacing with the system for you. A library API has more > flexibility than the OS kernel, and (paradoxically) can _permit_ more > flexibility in the system call interface by advertising "legacy" entry > points for system calls that change their signatures or disappear. (I > propose that Unix's historical failure to provide any such thing is what > prompted Linux Torvalds to proclaim his Iron Rule about not ever > breaking userspace.[1] With a library layer and a bit more type > discipline than early C had, lseek(2) could have remained simply > seek(2). I think I've heard someone on this list observe that this is > how Microsoft Windows (NT and its successors?) works. > > I can imagine the objections. (1) If Microsoft's doing it, it must be > wrong. Well, that's not a bad way to bet, but sometimes Microsoft does > the right thing after first trying every wrong way they can think of, > and eventually tiring of getting burned. (2) "I'm a C programmer and > I'm close to the metal and therefore I go straight to system calls". > Fine, but then your app needs to do what the library would have been > doing: having shims to abstract the version of the OS kernel, handling > interrupted system calls, and so forth. > > I think I've posted here before about how the grudging acceptance of a > `-u` flag to cat(1) in Eighth Edition Unix, and the vigorous rejection > of any _other_ flags to it, was a symptom of people not really thinking > of that program as an application, but as a test apparatus for the > kernel. The latter is not, I submit, an appropriate first-order purpose > for a user-facing application. By _all_ means, ship a kernel-testing > apparatus with the OS! But it doesn't need to live in the $PATH. > > If one accepts that perspective, the flutter of other flags waving from > cat's tail becomes less offensive. > > The fundamental solution > ------------------------ > > ...arises from consideration of this clause of Stevens. > > 'if a process caught a signal while the process was blocked in a "slow" > system call' > > My thesis: An OS kernel should not _have_ "slow" system calls. > > The modern Linux kernel is festooned with things called "worker threads" > in an attempt to solve the same problem.[2] (I presume successfully.) > But because Linux is still monolithic--and has to be, lest its lead > author's now largely achieved objective of "world domination"[3] be > squandered--it has an ever-growing set of worker threads as its > revisions steadily find more things for idle cores to do. > > This strategy isn't wrong or stupid, but in my view it quietly concedes > an argument that Torvalds and his acolytes declared themselves as having > prevailed in over 30 years ago. > > You _could_ reach the same point, with more easily managed permission/ > security boundaries (I claim), by employing a microkernel design. > > And let us please forever erase, or at least suffix a fat asterisk to, > the name "Mach" from association with microkernels. That was indeed the > status its promulgators hoped for, but by starting with the BSD kernel > and cutting it down, instead of building one up from nothing, they > picked an approach that frustrated their objectives. > > https://cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93improving.pdf > > Thus my enthusiasm for microkernels. Yes, context switches are costly, > and mode switches are more costly still. Where these costs are > unbearable, you either need more CPU, more memory, or to move away from > a general-purpose OS kernel. Solve your problem in a free-standing, not > a hosted, runtime environment. > > As we've seen, any proper engineering problem requires making tradeoffs > somewhere. (If it doesn't, it's an arithmetic problem.) An OS kernel, > in days of yore a "job monitor", was supposed to be a small, lean thing > of minimal footprint that perturbed the availability of CPU cycles and > RAM storage to the "real programs"--the _jobs_--as little as possible. > > But if we count lines of code, monolithic (or semi-monolthic, "modular") > kernels are some of the biggest software projects in the world, with the > ones we've all heard of weighing in at tens of millions of lines. > > https://interestingengineering.com/lists/whats-the-biggest-software-package-by-lines-of-code > > Zero-copy operations are not a silver bullet, either. They can be > beautiful but you then have to spend more time considering whose > responsibility it is to the validate the data in shared buffers, lest > you end up with _no one_ taking responsibility for it...and suffering > security pwnage. > > While researching this message I happened across the following paper > proposing a dedicated memory allocator for I/O operations in the Linux > kernel. > > https://netdevconf.info/0x15/papers/1/maio_netdev0x15.pdf > > I don't know what has become of that work. To me, the very existence of > {e,}BPF is a concession that monokernels are too complex, and the > proposed MAIO (from the foregoing paper) suggests the same. > > All right, tell me how I'm wrong! :) > > Regards, > Branden > > [1] https://lkml.org/lkml/2012/12/23/75 > > As is the way of iron rules, people have found ways to game them. > > https://lwn.net/Articles/1070072/ > > [2] https://docs.kernel.org/core-api/workqueue.html > [3] https://www.linuxjournal.com/article/36 From tuhs at tuhs.org Thu May 28 21:34:55 2026 From: tuhs at tuhs.org (Theodore Tso via TUHS) Date: Thu, 28 May 2026 06:34:55 -0500 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <20260528040137.p6ebgcz6nyi7ldpt@illithid> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> Message-ID: In addition to Bakul's observation that microkernels don't really solve the interruptible system call problem, the other thing I'd note is that microkernels have an economics problem, and that's something that you've largely ignored in your arguments. I'm trying to remember to exact meeting, but if I recall correctly it was a file system meeting that was called by the DOE at Sandia National Labs, where they were trying to motivate the industry into investing in a massive parallel file system because it was patriotic duty to help the DOE build the next generation nuclear bombs, which they would have to simulate since the test ban treaty wasn't letting them test real ones. (Spoilsports....) They also explained that they couldn't pay for the investment, but surely the market would buy such a product if the industry were to invest in this critical peace of technology so we could continue to build nukes. Needless to say, the industry didn't bite. At the meeting, a lot of people disputed the assertion that the commercial market had the need for the kind of specs that the DOE was proposing. Anyway, at a side conversation the topic of microkernels came up, and Rick Rashid, who was at Microsoft at the time, stated that he didn't believe that microkernels were really going to be viable, for the simple reason that while it was *possible* for microkernels to be as efficient as the monolithic kernel design, it took a lot more time and engineering to implement, since it requires a lot of really clever tricks. And in the intervening time, the people investing in the monolithic kernel could make further performance improvements and add new features, and the microkernel could simply never keep up. And yes, you said that it's all about engineering, and maybe we should give up on some of the performance to get a better architecture. But unfortunately the market and customer choice doesn't work that way. There's a reason Oracle used to plaster the back cover of Business Week magazines with Oracle DB benchmark numbers. (I'll ignore here whether the benchmark numbers were real, or very carefully curated benchmarketing numbers.) And I've personslly seen that users will always choose the file syystem with the best possible performance numbers --- whether they need the performance or not, and whether their workload has any reationship with the actual workload that they need to run. That's why the word "benchmarketing" exists in the lexicon. The other thing to remember is that the economic imperatives change over time. In the early days of Unix, or even the early days of Linux, high CPU core counts were not really economically viable. Or if they were, it was massive tradeoffs like NUMA which had other tradeoffs. In those early days, Linux's sweet spot was scale out, and not sale up, where you would use hundreds or even thousands of cheap PC class hardware, instead of expensive iron systems because they had a better price / performance reason. Google's early system of bare motherboards sitting on cardboard as an insulator may have been ugly, but it was way cheaper than buying Sun E10K's..... Of course, the technology and economic imperatives keep changing, and Google doesn't do bare motherboards sitting on cardboard any more. For mobile devices (which weren't a thing in the early days of Unix or even the early days of Linux), power efficiency absolutely matters. So having tons of kernel threads sitting in polling loops might not really be viable. Even in data centers, where that sort of thing was more interesting, now power efficiency is more important than CPU efficiency, because hyperscaler needs to save their power and cooling budget for GPU's, and in many cases, the CPU is sitting their twiddling its fingers while the GPU is getting on with the important work of vibe coding a Snake game. (And of course, getting Open AI and SpaceX to their IPO, and to make sure Google can have a truly stunning of demos at Google I/O.) The TL;DR of my whole reaction to your argument is, "It's complicated...." :-) - Ted From tuhs at tuhs.org Thu May 28 22:38:23 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Thu, 28 May 2026 07:38:23 -0500 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <2A034B99-B753-4412-9668-290039E52DAF@iitbombay.org> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> <2A034B99-B753-4412-9668-290039E52DAF@iitbombay.org> Message-ID: So much fun, let me count the ways: top posting, subject: ... c++ always wins, microkernels don't / won't solve EINTR, single space after the period, space instead of tabs, emacsen are superior, mac's rock... Not that these are all present in the document here, but they evoke every flamewar that's ever existed. A thought on complexity in the open.... Why do you suppose the use of AI (large model llms, chat) is being successfully engaged with Linux at the kernel level right now. Could it be that a monolithic kernel that is open source  and has millions upon millions upon millions of lines of code is a ripe target? Do you think it will be losing its savor anytime soon? I'm a huge proponent of open source code, but this is one lane of exposure I, for one, didn't see coming. Also, I never thought I'd see such a strong argument for microkernels or small languages show up so suddenly. Will On 5/28/26 00:41, Bakul Shah via TUHS wrote: > While I am a fan of microkernels, they won't solve the > problem of EINTR. The real issue is that completion of such > a syscall is *beyond* the control of the process. The call is > not necessarily *slow*, it is just that it may or not > eventually finish. No matter how you construct your software, > this situation doesn't go away. If you only return control > *after* reading an entire buffer's worth from the net, the > user will be quite frustrated their ^C will have no effect. > There is no timeout constant that is right either. Let the > user decide whether they want to wait for ever or abort. > > >> On May 27, 2026, at 9:01 PM, G. Branden Robinson via TUHS wrote: >> >> At 2026-05-27T18:43:09-0700, al kossow via TUHS wrote: >>> https://www.youtube.com/watch?v=I7fEsbksKRE >>> >>> this video is disturbing at so many levels >> Lacking patience, I read the transcript instead. >> >>> if you follow the Gabriel paper links, the one missing is >>> >>> https://blog.reverberate.org/2011/04/eintr-and-pc-loser-ing-is-better-case.html >> This is a good resource, and sheds much light on a frustrating problem. >> >> For me, the heart of the matter is this quote of Stevens's _APUE_: >> >>>> A characteristic of earlier UNIX systems is that if a process caught >>>> a signal while the process was blocked in a "slow" system call, the >>>> system call was interrupted. The system call returned an error and >>>> `errno` was set to `EINTR`. This was done under the assumption that >>>> since a signal occurred and the process caught it, there is a good >>>> chance that something has happened that should wake up the blocked >>>> system call. [...] The problem with interrupted system calls is that >>>> we now have to handle the error return explicitly. >> I submit that there are couple of ways to cut this Gordian Knot, one >> "pragmatic", and one fundamental. The pragmatic one could have been >> done, to all our benefit, ages ago. >> >> The pragmatic solution >> ---------------------- >> >> Better libraries. Period. Userspace programs generally shouldn't be >> making system calls directly. Instead you should have a library that >> handles interfacing with the system for you. A library API has more >> flexibility than the OS kernel, and (paradoxically) can _permit_ more >> flexibility in the system call interface by advertising "legacy" entry >> points for system calls that change their signatures or disappear. (I >> propose that Unix's historical failure to provide any such thing is what >> prompted Linux Torvalds to proclaim his Iron Rule about not ever >> breaking userspace.[1] With a library layer and a bit more type >> discipline than early C had, lseek(2) could have remained simply >> seek(2). I think I've heard someone on this list observe that this is >> how Microsoft Windows (NT and its successors?) works. >> >> I can imagine the objections. (1) If Microsoft's doing it, it must be >> wrong. Well, that's not a bad way to bet, but sometimes Microsoft does >> the right thing after first trying every wrong way they can think of, >> and eventually tiring of getting burned. (2) "I'm a C programmer and >> I'm close to the metal and therefore I go straight to system calls". >> Fine, but then your app needs to do what the library would have been >> doing: having shims to abstract the version of the OS kernel, handling >> interrupted system calls, and so forth. >> >> I think I've posted here before about how the grudging acceptance of a >> `-u` flag to cat(1) in Eighth Edition Unix, and the vigorous rejection >> of any _other_ flags to it, was a symptom of people not really thinking >> of that program as an application, but as a test apparatus for the >> kernel. The latter is not, I submit, an appropriate first-order purpose >> for a user-facing application. By _all_ means, ship a kernel-testing >> apparatus with the OS! But it doesn't need to live in the $PATH. >> >> If one accepts that perspective, the flutter of other flags waving from >> cat's tail becomes less offensive. >> >> The fundamental solution >> ------------------------ >> >> ...arises from consideration of this clause of Stevens. >> >> 'if a process caught a signal while the process was blocked in a "slow" >> system call' >> >> My thesis: An OS kernel should not _have_ "slow" system calls. >> >> The modern Linux kernel is festooned with things called "worker threads" >> in an attempt to solve the same problem.[2] (I presume successfully.) >> But because Linux is still monolithic--and has to be, lest its lead >> author's now largely achieved objective of "world domination"[3] be >> squandered--it has an ever-growing set of worker threads as its >> revisions steadily find more things for idle cores to do. >> >> This strategy isn't wrong or stupid, but in my view it quietly concedes >> an argument that Torvalds and his acolytes declared themselves as having >> prevailed in over 30 years ago. >> >> You _could_ reach the same point, with more easily managed permission/ >> security boundaries (I claim), by employing a microkernel design. >> >> And let us please forever erase, or at least suffix a fat asterisk to, >> the name "Mach" from association with microkernels. That was indeed the >> status its promulgators hoped for, but by starting with the BSD kernel >> and cutting it down, instead of building one up from nothing, they >> picked an approach that frustrated their objectives. >> >> https://cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93improving.pdf >> >> Thus my enthusiasm for microkernels. Yes, context switches are costly, >> and mode switches are more costly still. Where these costs are >> unbearable, you either need more CPU, more memory, or to move away from >> a general-purpose OS kernel. Solve your problem in a free-standing, not >> a hosted, runtime environment. >> >> As we've seen, any proper engineering problem requires making tradeoffs >> somewhere. (If it doesn't, it's an arithmetic problem.) An OS kernel, >> in days of yore a "job monitor", was supposed to be a small, lean thing >> of minimal footprint that perturbed the availability of CPU cycles and >> RAM storage to the "real programs"--the _jobs_--as little as possible. >> >> But if we count lines of code, monolithic (or semi-monolthic, "modular") >> kernels are some of the biggest software projects in the world, with the >> ones we've all heard of weighing in at tens of millions of lines. >> >> https://interestingengineering.com/lists/whats-the-biggest-software-package-by-lines-of-code >> >> Zero-copy operations are not a silver bullet, either. They can be >> beautiful but you then have to spend more time considering whose >> responsibility it is to the validate the data in shared buffers, lest >> you end up with _no one_ taking responsibility for it...and suffering >> security pwnage. >> >> While researching this message I happened across the following paper >> proposing a dedicated memory allocator for I/O operations in the Linux >> kernel. >> >> https://netdevconf.info/0x15/papers/1/maio_netdev0x15.pdf >> >> I don't know what has become of that work. To me, the very existence of >> {e,}BPF is a concession that monokernels are too complex, and the >> proposed MAIO (from the foregoing paper) suggests the same. >> >> All right, tell me how I'm wrong! :) >> >> Regards, >> Branden >> >> [1] https://lkml.org/lkml/2012/12/23/75 >> >> As is the way of iron rules, people have found ways to game them. >> >> https://lwn.net/Articles/1070072/ >> >> [2] https://docs.kernel.org/core-api/workqueue.html >> [3] https://www.linuxjournal.com/article/36 From tuhs at tuhs.org Fri May 29 03:59:45 2026 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Thu, 28 May 2026 10:59:45 -0700 Subject: [TUHS] UUNET In-Reply-To: References: Message-ID: I wondered about this, and based on communication with Rick Adams, Peter Salus has the best description of the evolution of UUnet: https://www.usenix.org/system/files/login/articles/login_aug15_09_salus.pdf#:~:text=First%20designed%20to%20operate%20over,to%20a%20need%20for%20improvements . Adams asked for seed money, used to set up a gateway to the ARPAnet so that people could send email once they moved on from universities that had access. The UUnet portion of this article begins on page 41, column 2. Rik On Wed, May 27, 2026 at 4:03 PM Kevin Bowling via TUHS wrote: > https://en.wikipedia.org/wiki/UUNET > > Does someone (maybe Rich Salz?) know how it transformed from a USENIX > infused non-profit to a for-profit? Controversial at the time? > From tuhs at tuhs.org Fri May 29 08:24:36 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 28 May 2026 18:24:36 -0400 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <20260528040137.p6ebgcz6nyi7ldpt@illithid> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> Message-ID: On Thu, May 28, 2026 at 12:01 AM G. Branden Robinson via TUHS wrote: > [snip; PCLSRing] > The fundamental solution > ------------------------ > > ...arises from consideration of this clause of Stevens. > > 'if a process caught a signal while the process was blocked in a "slow" > system call' > > My thesis: An OS kernel should not _have_ "slow" system calls. Bakul hit this; "slow" and "fast" system calls are a misnomer. The real distinction is "interruptible" and "non-interruptible" operations in the kernel initiated by system calls. This is relevant when it comes to deciding when you deliver a signal: if you're blocked in an interruptible operation and a signal arrives, then the system call is effectively aborted and the kernel delivers the signal (approximately) immediately. After the signal is handled, presuming the process continues running, the system call returns to the user program with an error and errno is set to `EINTR`. On the other hand, if a process is blocked in a non-interruptible operation and a signal arrives, then signal delivery is deferred until after the after that completes. Often we refer to non-interruptible operations as "fast" because the expectation is that they'll complete quickly, and trying to interrupt them to deliver a signal (...and possibly clean up a bunch of state) is not worth it. A problem is that many of the same system calls are overloaded for both interruptible and non-interruptible operations. So for example, reading a disk block is (presumably) pretty quick; if the process is waiting for a block to be read from a storage device, don't bother interrupting that operation since it'll be unblocked pretty soon anyway. By contrast, if the process is blocked waiting on a data read a network connection, or a pipe, or a terminal device, go ahead and interrupt that, since the read may not by fulfilled any time soon: the distant end might have gone down; the program writing to the pipe might be waiting for something, or the user might have gone out to lunch or left for the day...who knows when someone might wander by and type a character? It could be hours or days. Btw, this touches on an earlier topic (https://www.tuhs.org/pipermail/tuhs/2026-May/033745.html); I don't know if you saw that, however, as I wrote it right around the time the list had a hiccup. > The modern Linux kernel is festooned with things called "worker threads" > in an attempt to solve the same problem.[2] (I presume successfully.) Not really. "Worker threads" are a means for structuring _concurrency_, that is multiple logical flows of execution in a program. They're implemented in Linux, as in a bunch of other systems, because they're a convenient programming abstraction, and having a schedulable execution context is useful. But they're largely orthogonal to the whole fast vs slow thing and how those interact with signals (and thus `EINTR`): if every system call was asynchronous, having threads in a kernel would still be handy. But the link you referred to in your footnote is about "workqueues", which are built with pool of worker threads, but that's different again. Threads might be thought of as synchronous primitives: or at least they can be used as a building block for writing synchronous programs. They do something, and then the next thing, in program order. Sure, something a thread does might block, and that will usually result in the thread "yielding" control of execution to a scheduler, which may pick some other (runnable) thread and context switching to some it, but that's fine: from a logical perspective, the thread doesn't really know. Work queues are different: they're an asynchronous thing. You wrap up a little description of some work you want to have done and toss it to someone else to run on your behalf, asynchronously. You don't wait for it to be done before you move on to the next thing in your synchronous thread of execution. > But because Linux is still monolithic--and has to be, lest its lead > author's now largely achieved objective of "world domination"[3] be > squandered--it has an ever-growing set of worker threads as its > revisions steadily find more things for idle cores to do. This is conflating parallelism and concurrency; the two are not the same. Concurrency is a way to structure the flow of a program; threads, flow through state machines, and similar _software_ constructs are the basic unit of work there. Parallelism is distinct, and is about simultaneity: hardware threads, usually cores or CPUs or some other _hardware_ computing block are the unit of work there. The number of threads that exist purely within the Linux kernel increases because people keep discovering that there are things that that kernel needs to do concurrently, and which are conveniently expressed as threads: threads have nice properties, like independent scheduling, and the ability to block, and so on, that you _don't_ have if (say) you try to do everything directly from an interrupt handler like in Unix systems of yore. > This strategy isn't wrong or stupid, but in my view it quietly concedes > an argument that Torvalds and his acolytes declared themselves as having > prevailed in over 30 years ago. > > You _could_ reach the same point, with more easily managed permission/ > security boundaries (I claim), by employing a microkernel design. Eh....I don't know about that. Unix has been "multithreaded" since the early- or mid-1970s; we've been overlapping IO with computation since '72 or '73 or something. The situation in Linux isn't all that different. But I wouldn't call early Unix or Linux "microkernels" as that term is generally known; that's more about explicit control flow via passing messages, and separation of responsibilities into discrete tasks that are mutually ignorant of one another. Is that a "better" organization? Maybe, but consider that early versions of Minix didn't even use an MMU, so you don't always have an address space boundary between those tasks; and of course usually messages are implemented using shared memory. ';-} Put another way, the existence of threads or asynchronous work queues in a monolithic kernel isn't really an argument for or against microkernels conceptually; they're orthogonal. > And let us please forever erase, or at least suffix a fat asterisk to, > the name "Mach" from association with microkernels. That was indeed the > status its promulgators hoped for, but by starting with the BSD kernel > and cutting it down, instead of building one up from nothing, they > picked an approach that frustrated their objectives. > > https://cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93improving.pdf > > Thus my enthusiasm for microkernels. Yes, context switches are costly, > and mode switches are more costly still. Where these costs are > unbearable, you either need more CPU, more memory, or to move away from > a general-purpose OS kernel. Solve your problem in a free-standing, not > a hosted, runtime environment. > > As we've seen, any proper engineering problem requires making tradeoffs > somewhere. (If it doesn't, it's an arithmetic problem.) An OS kernel, > in days of yore a "job monitor", was supposed to be a small, lean thing > of minimal footprint that perturbed the availability of CPU cycles and > RAM storage to the "real programs"--the _jobs_--as little as possible. This is a definitional question. I like Roscoe's definition: the operating system is, "that body of software that, 1) multiplexes the machine's hardware sources, 2) abstracts the hardware pratform, and 3) protects software principals from each other (using the hardware)". [https://www.usenix.org/conference/osdi21/presentation/fri-keynote] Nothing in there says that it has to be a priori small, though of course it should strive for efficiency. The point is to provide useful abstractions for software. I think saying, "if the cost is unbearable you need more hardware" is imposing an unreasonable burden on that software. > But if we count lines of code, monolithic (or semi-monolthic, "modular") > kernels are some of the biggest software projects in the world, with the > ones we've all heard of weighing in at tens of millions of lines. > > https://interestingengineering.com/lists/whats-the-biggest-software-package-by-lines-of-code > > Zero-copy operations are not a silver bullet, either. They can be > beautiful but you then have to spend more time considering whose > responsibility it is to the validate the data in shared buffers, lest > you end up with _no one_ taking responsibility for it...and suffering > security pwnage. It's interesting that you mention L4, then, which made use of zero-copy techniques to speed up message passing. This is a performance thing, however, and the issues transcend issues of the design metaphor for the kernel writ large. Consider DMA; if a program wants to cancel an IO operation that is in flight, then you've got to be able to reliably cancel it _or_ pin the memory it's using until the operation is done. That's the same whether the kernel is a ukernel or not. > While researching this message I happened across the following paper > proposing a dedicated memory allocator for I/O operations in the Linux > kernel. > > https://netdevconf.info/0x15/papers/1/maio_netdev0x15.pdf > > I don't know what has become of that work. To me, the very existence of > {e,}BPF is a concession that monokernels are too complex, and the > proposed MAIO (from the foregoing paper) suggests the same. Well, eBPF et al are attempts to add flexibility to systems by dynamically instrumenting or changing their behavior. Again, I suspect that's largely orthogonal to microkernel vs monolithic kernel. Perhaps you are suggesting that a microkernel could swap in a new task something that you want to change the behavior of, but the ukernel might not allow you to do that; perhaps the task is compiled in, or perhaps it must be specially blessed in some way; instrumenting it as one might with eBPF or something similar may be administratively banned. > All right, tell me how I'm wrong! :) Wrong? I don't know. Rather, I think this is jumping around between multiple places and drawing conclusions that don't necessarily follow. - Dan C. > [1] https://lkml.org/lkml/2012/12/23/75 > > As is the way of iron rules, people have found ways to game them. > > https://lwn.net/Articles/1070072/ > > [2] https://docs.kernel.org/core-api/workqueue.html > [3] https://www.linuxjournal.com/article/36 From tuhs at tuhs.org Fri May 29 09:01:01 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Thu, 28 May 2026 16:01:01 -0700 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: <20260528040137.p6ebgcz6nyi7ldpt@illithid> References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> Message-ID: <3fcfdcd9-d477-4d13-9414-195379c7025b@oracle.com> On 5/27/26 21:01, G. Branden Robinson via TUHS wrote: > Better libraries. Period. Userspace programs generally shouldn't be > making system calls directly. Instead you should have a library that > handles interfacing with the system for you. A library API has more > flexibility than the OS kernel, and (paradoxically) can _permit_ more > flexibility in the system call interface by advertising "legacy" entry > points for system calls that change their signatures or disappear. (I > propose that Unix's historical failure to provide any such thing is what > prompted Linux Torvalds to proclaim his Iron Rule about not ever > breaking userspace.[1] With a library layer and a bit more type > discipline than early C had, lseek(2) could have remained simply > seek(2). I think I've heard someone on this list observe that this is > how Microsoft Windows (NT and its successors?) works. This is also the Solaris model - both at Sun & Oracle, the binary compatibility guarantee only applied at the library level. Actual system calls are a private implementation detail between libc & the kernel, and sometimes changed between releases. For instance, system calls like open, stat, chown, chmod, etc. were removed by Roger Faulkner in Solaris 11, and the functions for them in libc modified to call the openat, statat, etc. system calls instead: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/dtrace-guide/deleted-system-calls.html Programs linked against a static copy of libc were expected to break when moved to a different release, up until the static libc was removed completely in Solaris 10 to end that problem. This of course means that libc is the Solaris ABI and libraries for all other languages have to go through libc instead of making system calls directly from their implementations, and sometimes causes added work when porting those languages to Solaris. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Fri May 29 09:39:21 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 28 May 2026 16:39:21 -0700 Subject: [TUHS] the true reason why c++ always wins In-Reply-To: References: <6d11f0a3-fd3c-4b19-88c9-44e1efb6d4e0@bitsavers.org> <20260528040137.p6ebgcz6nyi7ldpt@illithid> Message-ID: <22A0AA1F-3AD1-4E45-BE18-C74EF6516C07@iitbombay.org> On May 28, 2026, at 3:24 PM, Dan Cross via TUHS wrote: > > Not really. "Worker threads" are a means for structuring > _concurrency_, that is multiple logical flows of execution in a > program. They're implemented in Linux, as in a bunch of other systems, > because they're a convenient programming abstraction, and having a > schedulable execution context is useful. But they're largely > orthogonal to the whole fast vs slow thing and how those interact with > signals (and thus `EINTR`): if every system call was asynchronous, > having threads in a kernel would still be handy. More specifically, or at least the way I used them in the past, some background kernel task may need to wait to gain some resource or on some event. If you use a thread, you can write sequential code (wait for X; do Y; wait for Z; do W etc.). Without such a thread you must not make any blocking calls, so you have to break up this code in a bunch of callbacks (when X happens, callback a fn to do Y and associate a callback for "do W" with Z etc.) -- this is the usual simulate threads in an event loop scenario. Multiple such threads may be added for increased concurrency. From tuhs at tuhs.org Fri May 29 10:53:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 28 May 2026 20:53:26 -0400 Subject: [TUHS] UUNET In-Reply-To: References: Message-ID: Thanks, Rick - much of what I started to write, you have in Peter's document. But let me add a little more to it that he left out, before and a bit after the UUNET experiment. - In the late 1979/early 1980 timeframe at the Winter Usenix in Colorado [we were in a rented movie theatre - that was featuring the new Sci-Fi Thriller: "The Black Hole"]. Steve delivered his first report on the UNC/Duke link. - One of the more amusing things that I remember about that was that we asked him how he was dialing. Remember the funny Hayes "in band signaling" ( the later industry standard AT cruft) has not been invented. Also, remember that Unix is from TPC (The Telephone Company). So, to have a computer source a phone call using the Bell System's "Direct Distance Dialing Network", you needed what was called an "Automatic Call Unit" (ACU), which the WE 801 was pretty much the TelCo standard, and DEC made the DN11, which provided the required RS-366 [ https://en.wikipedia.org/wiki/RS-366 ] interface to the 801. - So UUCP, of course, assumes each PDP-11 (or later Vax) that wants to dial another system uses a DN11 and an 801 (and compatible WE212 modems). Hopefully, this picture from the "DEC-11-HDNAA-B-D DN11 Automatic Calling Unit Interface Manual" - will pass through [if not, search for the PDF and its page 2-1] [image: ACU-Picture.png] - WE212s and 801s were fairly expensive. An many/most Universities tended to use Vadic VA3467 or VA3480 modems anyway. But a few places did have Vadic's 801 equivalent, the VA811 installed in that modem rack to dial the phone lines for the modems. - Lacking an ACU, Steve and Tom, like all good phone system hackers of that time (*mei culpa*), took a DR-11C [DEC's programmed I/O 16-bit parallel unibus interface] and connected a relay to it. They then connected the "business side" of the relay across the TIP and RING wires of each phone line, so when the relay closed, it shorted TIP and RING together. They knew that when you used a dial telephone, the pulses for each digit generated by the "finger wheel" on a traditional handset were a 40 ms "make" (close), followed by a 60 ms "Break" (open), with another "inter-digit pause" of 800 ms between numbers being dialed. - So they replaced the UUCP code to talk to DN11, to talk to their DR-11C dialer hack. - I know both decvax and teklabs 11/70 had Vadic gear with a DN11s and a proper ACU, but I'm not sure how many other sites use the Bellevin hack (it was cute, just lucky the local phone company never found out). - An important point to remember about this time is that those who had experienced ARPANET access, particularly people like myself who no longer had it, knew the power of a widespread mail system. - While Peter does a good job of explaining how *news took off*, the first 50-100 UUCP sites outside of the Bell System were *created just to move e-mail*. Except for a very small number of places, connecting to the ARPANet was "unobtainium." Even at UCB, ucbvax was not on the ARPANET; Ing70 was (their connection was a 960-cps serial link called Berknet). While decvax could connect via DECnet to DEC's PDP-20 (which was on the ARPAnet), mail could not flow via that link. - So after hearing Steve's talk, I came back to Oregon, and personally set up the teklabs to ucbvax link, since we had a number of students from the UCB CAD group (which I would later join) working in Teklabs. I also set up teklabs to decvax, ihnp4, as well as what would become known as the "marx" machines that Brian Redman had in Whippany. I was hardly unique. I think many UNIX folks left that USENIX with the same idea. I know Armando set up a number of uucp connections to different sites after that. - But that was the point; *we just wanted an email connection.* - Another point, if you were coming from the ARPANET world, you had likely experienced mailing lists like scify-lovers or risks-digest. So when we heard about the Duke/UNC news system, a lot of us thought we could recreate that experience [little did we know what would happen]. So within a year or so after that USENIX talk, those same 50-100 sites started to exchange "news" also - it was only about 25 articles a day, but a few e-mail messages. 120 cps WE212-style modems were more than adequate. - For the first few years, the ARPAnet and USENET basically existed without each other. But at some point, a couple of places, such as UC Berkeley, started to forward email between the two networks. - I do remember there was pushback from some of the ARPANET sites. In fact, the 1981 creation of "CSNET" was part of that, and CSNET had its own UUCP-like scheme called PhoneNet. - By 1982, BBN ran a mail router, and CSNET at some sites (particularly those that were not ARPANET-connected) had both PhoneNET and UUCP connections. - Also, MaryAnn and Matt Glickman had released BNEWS, which had become what we all called "net news," and was now using way more bandwidth than E-MAIL did. - Another important thing happened in 1982. Concord Data Systems and Racal-Vadic introduced the first modems to break the 1200-baud limit of POTS (their solution would become the V.22bis standard). They did this, actually sending data at 600 baud, but since " baud " does not mean "bits," it means "information", they managed to send 4 bits in each baud and added error correction. Plus, since these modems, unlike their earlier purely analog devices, had a microprocessor inside, they could do "smart" things. - As Peter tells you, by 1984, the amount of news traffic had started to get bad. Even with the new Vadic modems that are twice as fast (240 cps), the transmission time was still way too long (I'll come back to modems in a bit). - Peter mentions, but really does not explain, the big ugly truth of the time. A couple of very large sites (decvax, ihnp4, and seismo) were handling the long-distance load. - When Lauren Weinstien ran his experiment, Armando had to report to a few of us what was happening at decvax. It turns out the way DEC handled telephones was like heat, a utility for each site. So the actual phone bills for decvax, which was the central server for the DEC Telephone Industry Group (which had been created years earlier to serve DEC's #1 customer, the Bell System), were never directly examined. Armando's boss, Bill Munson, told us that he had looked into it at one point and estimated that decvax was running about $500K/yr in phone charges, and at that point, when it was not being directly noticed, he stopped asking, not wanting to draw more attention to it. - I don't remember who it was, it may have been Mary Ann, but it turns out somebody at AT&T did look into the ihnp4 charges, but then calculated that for every phone call it made, they generated between 10-20 downstream, so it was actually a good thing for AT&T. - I was running teklabs, and while we had some long-distance UUCP connections to places like ucbvax and decvax, we did not exchange news directly with either, only email. I don't remember now who we got our primary feed from, but ISTR we sent news downstream only to reasonably local sites, such as Reed College and Portland State. - BTW: By now, UC Berkeley had become an informal gateway between the two networks. IIRC, they had very few outbound UUCP connections. But sites like decvax and teklabs called them. - Rick Adams was working within the "Center for Seismic Studies," which was part of a DoD contractor [I believe it was Science Applications International Corporation (SAIC), but I do not know if I have that right]. - Their work was global, so his team had already incurred heavy telecommunications charges. But I have no idea how much they were spending. And it was also through this work that he became familiar with Tymnet and CompuServe - Tymnet was a private, commercial, packet-switched data network that operated as a public utility, connecting remote computer terminals to central mainframe systems [I'm going to ignore a ton of technical details here that aren't pertinent to USENET history]. They set up what they called Tymsats, which were terminal interface processors like the ARPANET TACs around the world. They supplied what they called Tycoms or host interface processors (think the ARPANET IMP) that interfaced to the major players' equipment (DEC, IBM, Burroughs, and the like). Someone like SAIC obtained a Tycom and could attach their computers (primarily mainframes). SAIC's customers, like the ones Rick was working with a seismo, could dial into local numbers and access the remote (SAIC) mainframe without incurring long-distance charges. I don't know the fee structure, as I was never involved with that side of it, but it was significantly cheaper (more in a minute). - Similarly, CompuServer worked like Tymnet; the difference was that, instead of a Tycom, they used X.25 PAD, and instead of Tymsats, they had a custom PDP-11-based system that did the same thing but ran their SW, which they called Nodes and T-Nodes. - UUNET would eventually use both services. - So the USENIX membership is now a little concerned. We knew that at some point, the gravy train of decvax, ihnp4, *etc.* could not last — particularly at the rate that the amount of data news was creating daily was getting extremely large (megabytes). At 120 cps, that was almost 2 hrs and 30 minutes per megabyte, and that does not include any overhead, so it ended up being closer to 3 hrs. Even at 240 cps, you were looking at about 90 minutes. - Coming back to USENET itself, by the summer of 1984, news delivery had become a huge issue. Peter described Lauren's solution. He came to the USENIX BOD with a proposal, which the BOD eventually backed. I don't remember why it never really caught on, other than that decoding the transmission required some specialized hardware, which a few people were comfortable with. Lauren, who worked in LA with broadcasters and other content creators, and a few others were, but I was at Masscomp by then, and when I looked into it, it was not going to be easy. And the other issue was that Lauren solved the broadcast issue, but we still did not have a way to get replies sent back up the chain. - So the membership is a bit of a buzz, and the board was aware that we were all worried. The good news for all of us at the time was that because of the "UNIX Wars," USENIX was fairly flush with cash from its conferences. - I don't know if Rick had siesmo on either Tymnet or CompuServe yet, but he did understand the cost structure and had a good idea of how it might work when he mentioned his idea to a few people in the summer of 1985. - It's interesting that the Telebit Trailblazer also came out in 1985. They quickly became the UUCP standard, because they were able to send 1800 cps using a radical, proprietary modulation scheme called Packetized Ensemble Protocol (PEP). Rather than relying on a single carrier frequency, as standard modems do, PEP dynamically splits the phone line into up to 512 separate micro-channels. The modem constantly analyzed the telephone line, automatically disabling individual micro-channels affected by static or line noise while keeping the clear channels wide open. But its designers were really smart and embedded Greg Chesson's "g" protocol (the UUCP standard) into the firmware. Each side of the UUCP link thought it was running the transfer protocol (without any modifications), and then the Trailblazer created an error-free connection over a standard POTS line. - So starting in 1985, if you administered a site serving the USENET via UUCP, you tended to run at least one Trailblazer. - As Peter says, in late May/June "*;login*" the BOD started asking people for proposals, which Rick replied to first in the fall, and by the Spring had put together a reason business plan. But I should note that between his original October 1986 BOD presentation and the BOD's insistence, one of the things the BOD insisted on was that there had to be a reasonable plan for self-sufficiency. The Association wanted to find a real solution and was willing to use its resources to help to seed a solution to the UUCP/USENET problem, but it could not be responsible for the solution itself. The BOD didn't want the Association to be seen as providing any direct service that took away from its mission of creating a place for the community to come together. - I probably should mention that at that time. There was consideration of how it was different by providing a place to come together electronically, like news, different from putting on conferences and publishing proceedings and papers? Again, this is before things like what we know today as social media. I think the board really felt that the optics of being a place that could support someone/head start things (like the mapping project, helping to fund "FOSS" versions of both pax and terminfo, etc.) were in their charter. But how far out of that could/should it reasonably go? - The idea of backing Rick and cosigning/being a financial guarantor was a bold step. Remember that Rick needed to negotiate a data transit deal with someone (CompuServe was first), and because the monthly data traffic costs were projected to be incredibly high, CompuServe required a financial safety net. The Association, which had a few million in assets by then, was that guarantor. Frankly, that action did worry some folks on the BOD. - What started all this was a question about it being for-profit. To the Association, it was an experiment to see if this would pan out. While they were the guarantor, they wanted a legal separation, so UUNET also set up a non-profit as a separate entity. The hope was that it would pay for itself, but some feared that it might not. So, in two years, when UUNET was more than self-sufficient, it was time for the Association and UUNET to cut ties. I think most of us were thrilled that Rick had succeeded. The community had a real solution that seemed to have worked. - One thing I slightly disagree with in Peter's piece is his claim that Rick "created a service to fill the need" for anyone to access USENET. The real driver, certainly as far as the Association was concerned, was how USENET would survive if the few large sites stopped passing data for free. - Rick is right that by the mid-1980s, finding a cooperative site to give you a news feed started to get harder. - From that standpoint, I had become an independent consultant around that time. I actually had a local news feed, but I still wanted to call into the local Tymnet Tysat with an unlimited access POTS line and my own Telebit to connect to UUNET, so email to me was never more than one hop. My business cards said: ...uunet!ccc!clemc [which morphed into clemc at ccc.com when we finally combined the two separate namespaces]. My fees to Tymnet and to Rick were small enough that I could handle them — this was exactly the kind of outcome the Association had hoped to obtain. Any site could be just one away from a major hub; the cost to do so was reasonable, and it was working. - To Rick's credit, he did not stop with UUCP. He created AlterNet as the first ISP was coming to bear. The service he offered was the same core idea, just a new protocol. He turned a number of his original UUCP connections to be AlterNet soon thereafter. On Thu, May 28, 2026 at 2:00 PM Rik Farrow via TUHS wrote: > I wondered about this, and based on communication with Rick Adams, Peter > Salus has the best description of the evolution of UUnet: > > > https://www.usenix.org/system/files/login/articles/login_aug15_09_salus.pdf#:~:text=First%20designed%20to%20operate%20over,to%20a%20need%20for%20improvements > . > > Adams asked for seed money, used to set up a gateway to the ARPAnet so that > people could send email once they moved on from universities that had > access. The UUnet portion of this article begins on page 41, column 2. > > Rik > > > On Wed, May 27, 2026 at 4:03 PM Kevin Bowling via TUHS > wrote: > > > https://en.wikipedia.org/wiki/UUNET > > > > Does someone (maybe Rich Salz?) know how it transformed from a USENIX > > infused non-profit to a for-profit? Controversial at the time? > > > From tuhs at tuhs.org Sat May 30 03:06:58 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 29 May 2026 17:06:58 +0000 Subject: [TUHS] Acquired 4 Binders of early 80s ESS/SCCS UNIX Manuals In-Reply-To: References: Message-ID: On Tuesday, May 19th, 2026 at 10:12, segaloco via TUHS wrote: > Another exciting find, in the mail currently but will hit my scanner when it arrives. Managed to land 4 binders from the early 80s that appear to contain Pidents and various other OSDD documents pertaining to the No. 2 Switching Control Center System and ESS-related UNIX (and possibly ESS-CC sources) listings. Following up that these have now arrived. One binder is a number of PR documents, in other words, complete source to the following 1981 Issue of No. 2 SCCS utilities: occ (Old/PDP-11 cc) sacopy sed sh (Bourne) tp nroff nroff fonts Another binder, although not labeled a PR binder, has sources to awk, bc, and a few other bits. Unfortunately between them the whole standard UNIX userspace is not there, but part is at least. Two more of the binders contain the /usr/sccbin scripts and sources, so the meat of the Switching Control Center System userland. Among some of the more intriguing scripts are one to lock/unlock doors in one of the facilities and some directory scripts containing personnel lists. Finally, one more binder was added to the mix which contains, among other things, manual pages and scripts related to the Polaris 4.0 database. I believe this to be some internal AT&T thing with no relation to other products called Polaris but I haven't done much research yet. Anywho, some significant findings from some cursory glances: - There are a mishmash of scripts, some targeting the Bourne shell, others targeting the "SCC Shell" which appears to describe a descendent of the shell most recently preserved in USG PG3. Given the nomenclature and flow of ideas (for instance these scripts use >% for stderr redirect, similar to the % redirect seen in early USG releases), I now am suspicious of whether this shell variant should be called the USG or SCC shell, whether USG modified it first and tossed it over at SCC or if SCC wrote the mods and USG sampled that. - A /dev listing is given, listing no tty(xx) files, but plenty of ln(xx) entries. Additionally, references are made to /etc/lines, so this follows in the init and terminal traditions currently seen earliest in 1977's PG3. This, I suspect, is an SCC invention that rolled into PG3 and CB-UNIX. In fact, many Program Generic differences with research appear to be Columbus/SCC influenced. This is a lot of material, almost all fanfold terminal output, so will take a little while to scan. What I may do in the meantime, at least for the PRs, is nab some extant sources and just "patch" them to the No. 2 SCC version to document changes. Hopefully 2026 continues to be the year of cracking open USG and Columbus UNIX activities. - Matt G. From tuhs at tuhs.org Sat May 30 22:16:43 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Sat, 30 May 2026 14:16:43 +0200 Subject: [TUHS] maintainer for bsd 2.11? Message-ID: <42b8825232611890b1e306401f74232e@vanheusden.com> Hi, Does anyone know who currently maintains bsd for the pdp? I found a memory leak in telnetd and have a patch for that (free(utmp) at line 1285). Also question: where can I find the bootloader sources? It currently waits for enter (or a device) and I would like to simply go on. -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com From tuhs at tuhs.org Sat May 30 23:04:04 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sat, 30 May 2026 13:04:04 +0000 Subject: [TUHS] maintainer for bsd 2.11? In-Reply-To: <42b8825232611890b1e306401f74232e@vanheusden.com> (Folkert van Heusden via TUHS's message of "Sat, 30 May 2026 14:16:43 +0200") References: <42b8825232611890b1e306401f74232e@vanheusden.com> Message-ID: <7wqzmtqcaj.fsf@junk.nocrew.org> Steven Schultz and Johnny Billquist. sms (at) 2bsdcom bqt (at) softjar.se From tuhs at tuhs.org Sat May 30 23:06:29 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Sat, 30 May 2026 15:06:29 +0200 Subject: [TUHS] maintainer for bsd 2.11? In-Reply-To: <7wqzmtqcaj.fsf@junk.nocrew.org> References: <42b8825232611890b1e306401f74232e@vanheusden.com> <7wqzmtqcaj.fsf@junk.nocrew.org> Message-ID: On 2026-05-30 15:04, Lars Brinkhoff wrote: > Steven Schultz and Johnny Billquist. > sms (at) 2bsdcom > bqt (at) softjar.se Thanks! -- www.vanheusden.com From tuhs at tuhs.org Sun May 31 01:35:26 2026 From: tuhs at tuhs.org (John D. Bruner via TUHS) Date: Sat, 30 May 2026 15:35:26 +0000 Subject: [TUHS] maintainer for bsd 2.11? In-Reply-To: References: <42b8825232611890b1e306401f74232e@vanheusden.com> <7wqzmtqcaj.fsf@junk.nocrew.org> Message-ID: For your other question, /usr/src/sys/mdec --John On Saturday, May 30th, 2026 at 06:06, Folkert van Heusden via TUHS wrote: > On 2026-05-30 15:04, Lars Brinkhoff wrote: > > Steven Schultz and Johnny Billquist. > > sms (at) 2bsdcom > > bqt (at) softjar.se > > Thanks! > > -- > www.vanheusden.com > From tuhs at tuhs.org Sun May 31 01:43:59 2026 From: tuhs at tuhs.org (John D. Bruner via TUHS) Date: Sat, 30 May 2026 15:43:59 +0000 Subject: [TUHS] maintainer for bsd 2.11? In-Reply-To: References: <42b8825232611890b1e306401f74232e@vanheusden.com> <7wqzmtqcaj.fsf@junk.nocrew.org> Message-ID: Hit enter too soon... That's the primary bootstrap. The source for /boot is in /usr/src/sys/pdpstand --John On Saturday, May 30th, 2026 at 08:35, John D. Bruner via TUHS wrote: > For your other question, /usr/src/sys/mdec > > --John > > On Saturday, May 30th, 2026 at 06:06, Folkert van Heusden via TUHS wrote: > > > On 2026-05-30 15:04, Lars Brinkhoff wrote: > > > Steven Schultz and Johnny Billquist. > > > sms (at) 2bsdcom > > > bqt (at) softjar.se > > > > Thanks! > > > > -- > > www.vanheusden.com > > > From tuhs at tuhs.org Sun May 31 15:52:49 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sun, 31 May 2026 05:52:49 +0000 Subject: [TUHS] Harvard's PPL, Polymorphic Programming Language Message-ID: <7w4ijoqg5q.fsf@junk.nocrew.org> Hello, I recently discovered a copy of the PPL "Polymorphic Programming Langauge". https://github.com/PDP-10/harvard-ppl Even though it seems to have enjoyed over a decade as an educational tool, it seems to have dissapeared almost without a trace. The Wikipedia page is very sparse. On topic for TUHS, PPL was ported to Unix and used at "several universities". Has anyone seen this programming language in the archives? From tuhs at tuhs.org Sun May 31 16:50:57 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 31 May 2026 16:50:57 +1000 Subject: [TUHS] Harvard's PPL, Polymorphic Programming Language In-Reply-To: <7w4ijoqg5q.fsf@junk.nocrew.org> References: <7w4ijoqg5q.fsf@junk.nocrew.org> Message-ID: On Sun, May 31, 2026 at 05:52:49AM +0000, Lars Brinkhoff via TUHS wrote: > Hello, > > I recently discovered a copy of the PPL "Polymorphic Programming Langauge". > https://github.com/PDP-10/harvard-ppl > > Even though it seems to have enjoyed over a decade as an educational > tool, it seems to have dissapeared almost without a trace. The > Wikipedia page is very sparse. > > On topic for TUHS, PPL was ported to Unix and used at "several > universities". Has anyone seen this programming language in the > archives? tuhs Applications/Usenix_77/ug091377.tar.gz h/ppl/ has 66 files, so I won't list them all 'PPL Version 7(30)' h/ppl/read_me 'news for version v.6(13) of ppl' h/help/ppl From tuhs at tuhs.org Sun May 31 17:03:00 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 31 May 2026 17:03:00 +1000 Subject: [TUHS] Harvard's PPL, Polymorphic Programming Language In-Reply-To: References: <7w4ijoqg5q.fsf@junk.nocrew.org> Message-ID: On Sun, May 31, 2026 at 04:50:57PM +1000, Jonathan Gray via TUHS wrote: > On Sun, May 31, 2026 at 05:52:49AM +0000, Lars Brinkhoff via TUHS wrote: > > Hello, > > > > I recently discovered a copy of the PPL "Polymorphic Programming Langauge". > > https://github.com/PDP-10/harvard-ppl > > > > Even though it seems to have enjoyed over a decade as an educational > > tool, it seems to have dissapeared almost without a trace. The > > Wikipedia page is very sparse. > > > > On topic for TUHS, PPL was ported to Unix and used at "several > > universities". Has anyone seen this programming language in the > > archives? > > tuhs Applications/Usenix_77/ug091377.tar.gz > h/ppl/ has 66 files, so I won't list them all > > 'PPL Version 7(30)' > h/ppl/read_me > > 'news for version v.6(13) of ppl' > h/help/ppl distrib.note also mentions a terminal mode for it: 'We have rewritten the teletype input routine to allow 3 additional "modes" of operation, "teco," "ppl," and "ddt."' tty code is also included From tuhs at tuhs.org Sun May 31 17:54:57 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sun, 31 May 2026 07:54:57 +0000 Subject: [TUHS] Harvard's PPL, Polymorphic Programming Language In-Reply-To: (Jonathan Gray's message of "Sun, 31 May 2026 16:50:57 +1000") References: <7w4ijoqg5q.fsf@junk.nocrew.org> Message-ID: <7wzf1govxq.fsf@junk.nocrew.org> Jonathan Gray wrote: > tuhs Applications/Usenix_77/ug091377.tar.gz > h/ppl/ has 66 files, so I won't list them all Yes, that's it. Thanks!