From coff at tuhs.org Wed Apr 1 13:20:47 2026 From: coff at tuhs.org (Warren Toomey via COFF) Date: Wed, 1 Apr 2026 13:20:47 +1000 Subject: [COFF] Problems with TUHS and COFF mailing lists Message-ID: Hi all, I'm back from a 3 1/2 week overseas holiday. Of course, partway through the trip the TUHS server "minnie" decided to hit 0% free disk space. I was able to clean things out remotely using a tablet and Bluetooth keyboard. However, since then I've had a few e-mails saying that submissions to TUHS and COFF have gone to /dev/null. I haven't deduced the issue yet. So, if in the next few weeks you post to TUHS or COFF and you don't see your posting, please e-mail with as much details as you can provide; a copy of the logs from your mail server would be wonderful! Thanks, Warren From coff at tuhs.org Sat Apr 4 23:41:35 2026 From: coff at tuhs.org (Douglas McIlroy via COFF) Date: Sat, 4 Apr 2026 09:41:35 -0400 Subject: [COFF] GE-635 GECOS? Message-ID: Clem wrote > Check out > https://www.multicians.org/ge635.html > From what I can tell GCOS has been lost to time The Multicians timeline shows Bell Labs joining the project after GE was chosen as the vendor. This may be the date of some formal agreement. However, the Labs was in on the final confirmation of GE. IBM had been ruled out over the issue of virtual memory. GE was happy to offer a VM variant of the 635. In contrast, IBM's chief architect, Gene Amdahl, adamantly maintained that VM was unacceptably inefficient. When it became clear that GE was winning, IBM revealed Gerrit Blaauw's 360 model 67 with VM, which had been kept under wraps. The option was considered, but found to offer no advantage from a programming standpoint. Nevertheless, time-sharing on the IBM machine made it into the field well before Multics; MTS, the Michigan Terminal System, went live in 1967. the same year that GE delivered the 645. A completely unsung project at Bell Labs during the Multics era was Joel Sturman's GUTS, GE User Time Sharing on the 635. Joel built this without any specific kernel support. I'm sorry I don't know more about it, in particular how it did scheduling. Way off topic, but apropos of the 360 vs contemporary 36-bit machines, a member of the design team for the Apollo mission once told me that it was fortunate they were using IBM 700/7000 equipment rather than the new-fangled 360s. 36-bit floating-point precision was just enough to calculate trajectories to the moon without resorting to slow software double precision. The 32-bit floating point of the 360 would have forced the slow alternative. I suspect also that hex rounding would have exacerbated the difference. Doug From coff at tuhs.org Sun Apr 5 02:35:05 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Sat, 4 Apr 2026 12:35:05 -0400 Subject: [COFF] GE-635 GECOS? In-Reply-To: References: Message-ID: On Sat, Apr 4, 2026 at 9:42 AM Douglas McIlroy via COFF wrote: > IBM had been ruled out over the issue of virtual memory. GE was happy > to offer a VM variant of the 635. In contrast, IBM's chief architect, > Gene Amdahl, adamantly maintained that VM was unacceptably > inefficient. > Gene Amdahl was a notorious opponent of the concept of virtual memory. He famously stated that virtual memory merely magnified the need for real memory. Amdahl also had big fights with Fred Brooks over the word size for S/360. Brooks insisted that the machine word size be a power of two. Amdahl favored a 24-bit design. They eventually compromised: the word size, registers, and arithmetic operations on S/360 would be 32-bit but the addressing would be 24-bit (16 MB). Given that the biggest main storage ever shipped on a S/360 was 8 MB, 24-bit address circuitry was more than adequate and reduced the manufacturing costs for the machines significantly. -Paul W. From coff at tuhs.org Sun Apr 5 04:59:03 2026 From: coff at tuhs.org (Clem Cole via COFF) Date: Sat, 4 Apr 2026 14:59:03 -0400 Subject: [COFF] GE-635 GECOS? In-Reply-To: References: Message-ID: First, a side note. Seymour felt the same way WRT to VM. The truth is, VM lets the OS and HW *manage the program overlays automatically,* so the programmer doesn't have to think about it. For generations of programmers who have never used overlays and thunks, it seems strange not to have a VM. But supporting VMs takes a lot of resources (in both the HW and the OS), and to many people like Gene and Seymour, it seems like sloppy programming to rely on them. Remember, in 1965 dollars, the price per bit was $2.52 ($25.26 in 2026), whereas modern DRAM is $0.000000007 per bit. Also, a Model 65 installation was often 512 KB or sometimes 1 MB. Wikipedia suggests that configurations exceeding 1 MB were considered "unusual" during the mid-to-late 1960s. CMU's 67 (that I used to program) had 4M, and I think many university sites like Stanford, Michigan, Cornell, and Princeton were likely similar. And to scale the size, a 1M core box was multiple cabinets and about the size of the later DEC 11/780 cabinet. WRT the S/360 architecture, my friend Russ Robelen led the Model 50 hardware team (and was also the guy who convinced Amdahl and Brooks to use microcode for the S/360 project). Some years ago, Russ told me the story of how bytes and words were defined for the S/360. The core of what Paul says is true, but the full facts are even more interesting, and I think it makes a great story. While we think of Brooks for his impact on the software, he was the lead of everything on the project, both hardware and software. Gene led the hardware team. Gene made it clear that he felt anything larger than a 6-bit byte and 24 bits for words and addresses was "a waste of hardware" and would add unreasonable cost and complexity for no real reason. As Paul mentioned, Brooks believed that bytes and words needed to be powers of two "because anything else is just too difficult to program." From what I understand, Gene was not handling that choice well. Russ says, every time Gene brought it up, he got tossed out of Brooks' office and told not to come back. Again, as Paul reported, Fred did relent on the address being 24 bits, but told Gene, "to make damned sure you store them a full word." So, except for the Model 67 [which was a Model 65 plus the VM hardware called "DAT box" [Data Address and Translation], plus some new microcode, all had 8-bit bytes, 16-bit ½ words, and 32-bit full words]. But because the 24-bit addresses were stored and primarily passed as 32-bit words, the 67 could run code targeted for the other models with straightforward changes [67 had a couple of new user space instructions - Branch and Store (BAS), Branch and Store Register (BASR)†, and some new privileged operations specific to the data translation hardware.] Years later, Gordon Bell would state that the #1 issue limiting the longevity of an ISA was too few address bits. IBM started System 370 with the same 24 bits, but by the 370-XA, it finally made everything 32 bits. That architecture survived from 1964-1978 as S/360, 1970-1990 as S/370, and 1990-2000 as S/390. It was not until the zSeries 900 that IBM broke stride and introduced a 64-bit variant, but they do have a level of compatibility that allows 60-year-old binaries to continue running. † Have spent much of my youth moving OS/360 code to TSS. Besides things like different OS Service interfaces and system control blocks, the ugliest thing you had to deal with was how programming used the "wasted" high-order byte when manipulating or storing an address. Because TSS/360 and MTS/360 used 32-bit virtual addresses, some programs that performed manual address arithmetic or "dirty" pointer tricks (like using the high-order byte of a 32-bit register for flags) often broke because the system might need to use those bits for extended addressing. On Sat, Apr 4, 2026 at 12:35 PM Paul Winalski via COFF wrote: > On Sat, Apr 4, 2026 at 9:42 AM Douglas McIlroy via COFF > wrote: > > > IBM had been ruled out over the issue of virtual memory. GE was happy > > to offer a VM variant of the 635. In contrast, IBM's chief architect, > > Gene Amdahl, adamantly maintained that VM was unacceptably > > inefficient. > > > > Gene Amdahl was a notorious opponent of the concept of virtual memory. He > famously stated that virtual memory merely magnified the need for real > memory. > > Amdahl also had big fights with Fred Brooks over the word size for S/360. > Brooks insisted that the machine word size be a power of two. Amdahl > favored a 24-bit design. They eventually compromised: the word size, > registers, and arithmetic operations on S/360 would be 32-bit but the > addressing would be 24-bit (16 MB). Given that the biggest main storage > ever shipped on a S/360 was 8 MB, 24-bit address circuitry was more than > adequate and reduced the manufacturing costs for the machines > significantly. > > -Paul W. > From coff at tuhs.org Mon Apr 6 01:43:59 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Sun, 5 Apr 2026 11:43:59 -0400 Subject: [COFF] GE-635 GECOS? In-Reply-To: References: Message-ID: On Sat, Apr 4, 2026 at 2:59 PM Clem Cole wrote: > > So, except for the Model 67 [which was a Model 65 plus the VM hardware > called "DAT box" [Data Address and Translation], plus some new microcode, > all had 8-bit bytes, 16-bit ½ words, and 32-bit full words]. But because > the 24-bit addresses were stored and primarily passed as 32-bit words, the > 67 could run code targeted for the other models with straightforward > changes [67 had a couple of new user space instructions - Branch and > Store (BAS), Branch and Store Register (BASR)†, and some new privileged > operations specific to the data translation hardware.] > The System/360/370 architecture had two branch instructions designed for subroutine calls: BAL (Branch And Link) and its two-register counterpart BALR (Branch And Link Register). The instructions take two operands: a target address (in base/displacement form for BAL; a register number for BALR), and a register to receive the link information. The low 24 bits of the target address are the address of the next instruction to be executed, i.e., the first instruction of the routine to be called. The address of the instruction immediately following the BAL/BALR, i.e., the subroutine return address, is stored in the low 24 bits of the link register. Into the high 8 bits of the link register are stored the current instruction length code, the condition code, and the program mask bits. This allows the callee to restore the caller's condition code and exception handling information before returning to the caller. But the use of the high 8 bits of the link register became a problem when the S/360-67 expanded addressing to 32 bits. They had to add two new instructions--BAS and BASR (Branch and Store)--that stored all 32 bits of the return address versus using the top 8 bits for program status information. > Years later, Gordon Bell would state that the #1 issue limiting the > longevity of an ISA was too few address bits. IBM started System 370 with > the same 24 bits, but by the 370-XA, it finally made everything 32 bits. > S/370 -XA was actually 31 bits. The highest order bit of the return address indicated the addressing mode in use by the caller: 0=24-bit mode, 1=31-bit mode. This was necessary to allow mixing of 31-bit and 24-bit addressing. -Paul W. From coff at tuhs.org Fri Apr 10 10:48:38 2026 From: coff at tuhs.org (Greg 'groggy' Lehey via COFF) Date: Fri, 10 Apr 2026 10:48:38 +1000 Subject: [COFF] Don't be too secure Message-ID: Warren seems to have found the reason why my posts haven't been reaching TUHS (and presumably this list too): they're GPG signed, and that's too secure for the latest version of mailman! This message is partially to grumble and partially to check whether the messages now go through. Warren sent me this link: https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/thread/B7BQKRQMA6LOE7RZJCEOOEW7MUEQH7U7/ I'm not overly secure, but cryptographic signatures have so far been only refused by systems in the Microsoft space. The only problem with this: so far our changes haven't worked. If you get this message, we have finally succeeded on try 4. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From coff at tuhs.org Fri Apr 10 11:28:46 2026 From: coff at tuhs.org (G. Branden Robinson via COFF) Date: Thu, 9 Apr 2026 20:28:46 -0500 Subject: [COFF] Don't be too secure In-Reply-To: References: Message-ID: <20260410012846.nurogqqpohdyotu7@illithid> Hi Greg, At 2026-04-10T10:48:38+1000, Greg 'groggy' Lehey via COFF wrote: > Warren seems to have found the reason why my posts haven't been > reaching TUHS (and presumably this list too): they're GPG signed, and > that's too secure for the latest version of mailman! This message is > partially to grumble and partially to check whether the messages now > go through. Warren sent me this link: > > https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/thread/B7BQKRQMA6LOE7RZJCEOOEW7MUEQH7U7/ > > I'm not overly secure, but cryptographic signatures have so far been > only refused by systems in the Microsoft space. > > The only problem with this: so far our changes haven't worked. If you > get this message, we have finally succeeded on try 4. My mails have the same property and seem to have suffered the same problem. Warren ventured that fixing your issue might fix mine. Since I did in fact see your message, I'm hopeful. 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 coff at tuhs.org Fri Apr 10 11:40:43 2026 From: coff at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_COFF?=) Date: Fri, 10 Apr 2026 01:40:43 +0000 Subject: [COFF] Don't be too secure In-Reply-To: References: Message-ID: <_7_HmbM8xLsHphC4aWpNVdX0HTtKHCsSamFVt4ptFZ_FpzWjUQoxGNA9u1Eu4hsOTKUAoNbP3n1kVhAy0E-8gtVlJmKuq2OKzdUpQPsUHj4=@protonmail.ch> Greg / Warren, Greg's try no.4 has reached Scotland :) Cameron On Friday, April 10th, 2026 at 1:48 AM, Greg 'groggy' Lehey via COFF wrote: > Warren seems to have found the reason why my posts haven't been > reaching TUHS (and presumably this list too): they're GPG signed, and > that's too secure for the latest version of mailman! This message is > partially to grumble and partially to check whether the messages now > go through. Warren sent me this link: > > https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/thread/B7BQKRQMA6LOE7RZJCEOOEW7MUEQH7U7/ > > I'm not overly secure, but cryptographic signatures have so far been > only refused by systems in the Microsoft space. > > The only problem with this: so far our changes haven't worked. If you > get this message, we have finally succeeded on try 4. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > From coff at tuhs.org Fri Apr 10 11:51:41 2026 From: coff at tuhs.org (Greg 'groggy' Lehey via COFF) Date: Fri, 10 Apr 2026 11:51:41 +1000 Subject: [COFF] Latest delivery problem worked around (was: Don't be too secure) In-Reply-To: <20260410012846.nurogqqpohdyotu7@illithid> References: <20260410012846.nurogqqpohdyotu7@illithid> Message-ID: On Thursday, 9 April 2026 at 20:28:46 -0500, COFF wrote: > Hi Greg, > > At 2026-04-10T10:48:38+1000, Greg 'groggy' Lehey via COFF wrote: >> Warren seems to have found the reason why my posts haven't been >> reaching TUHS (and presumably this list too): they're GPG signed, and >> that's too secure for the latest version of mailman! This message is >> partially to grumble and partially to check whether the messages now >> go through. Warren sent me this link: >> >> https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/thread/B7BQKRQMA6LOE7RZJCEOOEW7MUEQH7U7/ >> >> I'm not overly secure, but cryptographic signatures have so far been >> only refused by systems in the Microsoft space. >> >> The only problem with this: so far our changes haven't worked. If you >> get this message, we have finally succeeded on try 4. > > My mails have the same property and seem to have suffered the same > problem. Warren ventured that fixing your issue might fix mine. > > Since I did in fact see your message, I'm hopeful. Thanks! It seems that this attempt FINALLY produced something, and in particular that your message also got through. Background: I'm doing this because Warren is busy with a Real Life. mailman3 rejects certain MIME types, including application/pgp-signature and apparently multipart/signed. Warren had already allowed application/pgp-signature, and I allowed multipart/signed, which seems to have done the trick. We had been trying to second-guess, not made any easier by some mailman3 peculiarities. In particular, it should inform the sender when a message gets rejected, but I have never seen that. And the log messages describing the rejection are also too polite to mention the attachment type to which it objects. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From coff at tuhs.org Fri Apr 10 12:04:01 2026 From: coff at tuhs.org (Alexis via COFF) Date: Fri, 10 Apr 2026 12:04:01 +1000 Subject: [COFF] Latest delivery problem worked around In-Reply-To: (Greg Lehey via COFF's message of "Fri, 10 Apr 2026 11:51:41 +1000") References: <20260410012846.nurogqqpohdyotu7@illithid> Message-ID: <874ilj4lm6.fsf@gmail.com> Greg 'groggy' Lehey via COFF writes: > And the log > messages describing the rejection are also too polite to mention > the > attachment type to which it objects. Ah, the old "don't give users any information that might let them solve the problem" trick. "File not found, aborting." Which file? "If you don't know how to use strace to work it out yourself, you shouldn't be using a computer." Alexis. From coff at tuhs.org Fri Apr 10 12:50:45 2026 From: coff at tuhs.org (G. Branden Robinson via COFF) Date: Thu, 9 Apr 2026 21:50:45 -0500 Subject: [COFF] Latest delivery problem worked around In-Reply-To: <874ilj4lm6.fsf@gmail.com> References: <20260410012846.nurogqqpohdyotu7@illithid> <874ilj4lm6.fsf@gmail.com> Message-ID: <20260410025045.7qm3hmo2fwfeksjq@illithid> At 2026-04-10T12:04:01+1000, Alexis via COFF wrote: > Greg 'groggy' Lehey via COFF writes: > > And the log messages describing the rejection are also too polite to > > mention the attachment type to which it objects. > > Ah, the old "don't give users any information that might let them > solve the problem" trick. Yup. One of the many themes of my work on groff is that I've found myself writing change log entries that use the verb "disclose" to record occasions where the program knew damn well the specifics of what was wrong with the input, but had been churlishly refusing to share that information with the (likely frustrated) user. Some examples: * src/roff/troff/reg.cpp (number_value_to_ascii): When diagnosing a value beyond representatable Roman numeral range, disclose the specific format demanded. ... * When an artifact is present but the page count is wrong, disclose the expected value. * src/utils/xtotroff/xtotroff.c (MapFont): Make fatal error diagnostic on memory allocation failure disclose how many bytes we attempted to grab from the heap. This way the user can better distinguish system starvation scenarios from attempted denial-of-service attacks (or worse). (Admittedly, few people ever run xtotroff at all, let alone in scenarios where a busy system is so pinned that `malloc(PATH_MAX)` is likely to fail. But I feel that since we have this information, we should disclose it.) * src/devices/grohtml/post-html.cpp (html_printer::set_style): Disclose name of font description file lacking `internalname` directive in fatal diagnostic when this is the case. * src/roff/troff/node.cpp (mount_font_no_translate): Clarify error diagnostic when the `fp` request is given a too-huge mounting position; disclose both the rejected argument and value of the next available font position. 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 coff at tuhs.org Fri Apr 10 13:54:23 2026 From: coff at tuhs.org (Greg 'groggy' Lehey via COFF) Date: Fri, 10 Apr 2026 13:54:23 +1000 Subject: [COFF] Latest delivery problem worked around In-Reply-To: <20260410025045.7qm3hmo2fwfeksjq@illithid> References: <20260410012846.nurogqqpohdyotu7@illithid> <874ilj4lm6.fsf@gmail.com> <20260410025045.7qm3hmo2fwfeksjq@illithid> Message-ID: On Thursday, 9 April 2026 at 21:50:45 -0500, COFF wrote: > At 2026-04-10T12:04:01+1000, Alexis via COFF wrote: >> Greg 'groggy' Lehey via COFF writes: >>> And the log messages describing the rejection are also too polite to >>> mention the attachment type to which it objects. >> >> Ah, the old "don't give users any information that might let them >> solve the problem" trick. > > Yup. One of the many themes of my work on groff is that I've found > myself writing change log entries that use the verb "disclose" to record > occasions where the program knew damn well the specifics of what was > wrong with the input, but had been churlishly refusing to share that > information with the (likely frustrated) user. :-) Have you thought of using the term "divulge" when you're not talking about your own software? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From coff at tuhs.org Fri Apr 10 14:08:31 2026 From: coff at tuhs.org (G. Branden Robinson via COFF) Date: Thu, 9 Apr 2026 23:08:31 -0500 Subject: [COFF] Latest delivery problem worked around In-Reply-To: References: <20260410012846.nurogqqpohdyotu7@illithid> <874ilj4lm6.fsf@gmail.com> <20260410025045.7qm3hmo2fwfeksjq@illithid> Message-ID: <20260410040831.hi5jpdgmojwkjzgt@illithid> At 2026-04-10T13:54:23+1000, Greg 'groggy' Lehey wrote: > :-) Have you thought of using the term "divulge" when you're not > talking about your own software? Sounds like a good name for a command in a symbolic debugger... Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: