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 >> >