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: From coff at tuhs.org Fri Apr 17 08:40:18 2026 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 16 Apr 2026 22:40:18 +0000 Subject: [COFF] [TUHS] Re: Old Unix tapes from University of Nottingham In-Reply-To: <39b01ae9-993b-6880-d1ca-c6440558a2a4@bitsavers.org> References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> <39b01ae9-993b-6880-d1ca-c6440558a2a4@bitsavers.org> Message-ID: On Thursday, April 16th, 2026 at 15:22, Al Kossow via TUHS wrote: > On 4/16/26 3:07 PM, Matt Day wrote: > > I haven't tried them yet, but Howard Atherton at Apex Technology in Sandbach, Cheshire, UK claims to have had some success at recovering > > from QIC: > > https://disktransfer.co.uk/tape.php > > > > I would REALLY be interested in what they would quote you to do this. > > Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery > that was inferior to the one we did of the same tape. > > > I would REALLY be interested in what they would charge to do this. > > Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery > that was inferior to the one we did of the same tape. > > Moving to COFF re: QIC tapes. I still have that box of 17 QIC from BTL from the early 90s. I recently got a real cheap QIC drive (wrong size, mini) but mostly to just play with the read head, see how it responds to manual transport of the tape over the head. If that works out all fine and good, given how stupid QIC backup is currently, vs the mountain of tapes out there in the world...it seems like there might be a need for a modified piece of hardware to just pull the reels out of the cartridge entirely and let something else do the transport. Granted I'm still kinda green in this area, but I snagged a 7-track Kennedy read-write unit I'm also experimenting with. I'm hoping between the two of them I might be able to fashion something that'll pass the tape over the head properly. There's still the matter of serpentine reading on a single track head, but the hacky solution may just be track at a time, read, tick the head up to the next track with a knob or lever, read, wash rinse repeat. Broaching the topic as discussions over time have me convinced a good QIC recovery solution is pretty direly needed. I want to contribute what I can to that effort. - Matt G. From coff at tuhs.org Sat Apr 18 03:36:27 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Fri, 17 Apr 2026 13:36:27 -0400 Subject: [COFF] Michael O Rabin has died Message-ID: I just heard that Michael O Rabin passed away a few days ago, on April 14th. In addition to producing a number of advances in cryptography and computability, he shared the 1976 ACM Turing Award with Dana S Scott for their joint paper titled, "Finite Automata and Their Decision Problems", that introduced non-deterministic finite automata. These machines are, of course, familiar to TUHS and COFF readers because of their applications to practical software implementations of pattern matching with regular expressions. I was fortunate to be able to take his introductory cryptography course during one of the semesters when he taught it at Columbia[*]. It was an amazing experience: for someone so eminent, he was a phenomenal instructor who was clearly animated by the joy of teaching. One presumes he didn't have to teach that course, but he wanted to, and rather obviously enjoyed doing so. Condolences to his friends and family, and, as I believe it is customary to say in Judaism, may his memory be a blessing. - Dan C. [*] Rabin's daughter, Tal Rabin, is herself a respected computer scientist and is at IBM TJ Watson in Yorktown Heights; her father would venture down to New York City for a semester here and there, teach at Columbia, and spend time with his grand children, who he would occasionally mention in class: I remember a discussion of some primitive that would be resilient to data loss, and he mentioned "grandchildren stuffing peanut butter and jelly sandwiches into computers" as a concrete example of such loss: it was unclear whether he meant it literally. From coff at tuhs.org Tue Apr 21 02:43:38 2026 From: coff at tuhs.org (Steffen Nurpmeso via COFF) Date: Mon, 20 Apr 2026 18:43:38 +0200 Subject: [COFF] [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <2013c705-3885-4730-a01b-1f6dfbf70b0b@spamtrap.tnetconsulting.net> References: <42833F9E-52B4-4298-812E-479D3A01FFBF@alchemistowl.org> <2013c705-3885-4730-a01b-1f6dfbf70b0b@spamtrap.tnetconsulting.net> Message-ID: <20260420164338.GLnQ43Tq@steffen%sdaoden.eu> [i went to coff@ as requested.] Grant Taylor via TUHS wrote in <2013c705-3885-4730-a01b-1f6dfbf70b0b at spamtrap.tnetconsulting.net>: |On 4/18/26 10:20 AM, Kenneth Goodwin via TUHS wrote: |> On your physical firewall, block the entire subnet range that |> they were assigned by their ISP using a single access control list |> statement with ip address and appropriate subnet mask. Drop all packets |> from this range. Its been awhile, but I believe IANA maintains a |> list of ip address ranges per internet client. Other organizations |> might as well. It makes your site disappear from their view. They |> may automatically stop connecting once enough failed attempts are |> registered at their end. | |The last time I looked IANA maintained a list of which IP ranges were |handed out to the Regional Internet Registries (RIRs). You'd need to go |(multiple hops) deeper to find a viable subnet for the offending IP(s). | |I found that (access to) a (read-only) BGP (monitoring) feed can be very |useful for this. The BGP feed will have down to the /24 for the network |the offending IP is in. What's more is you can see what other prefixes |the ASN is advertising and block them as well if you want to. | |> If you are using a server based firewall such as iptables or |> a successor, do the above ACL there. Instead of one ACL per ip |> address. It's one ACL per offender blocking everything. ... Great ipset tip, from an iptables lover. (Successor, bah!) But note i would be careful, the fossies.org software archive (at times one of the most widely visited pages of the internet) was not accessible from wide ranges of the internet last year, and for quite some time, because Jens Schleusener, the instance behind, actually seem to have fetched provider info, and then blocked providers or at least larger ranges thereof. (Some providers have hundreds of IP ranges, from little to big.) (Not to mention that most attacks *i* see come via some clowd.) What i (my TUHS clone still requires better firewall settings) have found valuable is excluding crawlers without reverse DNS. So i had written a script which can easily be adapted (especially on Linux for which it is meant, with two caveats, first of all it creates a database file : ${DB:=/run/.fw-ss-http} that is *not flocked*, and then the final action from within awk(1) needs to be adapted. And note reverse DNS may hang! What it does is that it checks any current connection nips=$($SS -H -Q -t '( sport = :http or sport = :https )' | and performs DNS reverse lookup (i have a local dnsmasq cache) eval l=\$ipdns_$ipm ipdns_$ipm=y if [ -n "$l" ]; then [ -n "$DBG" ] && echo >&2 '.. DNS lookup cached: '$ip continue elif [ -n "$DBG" ]; then echo >&2 'DNS PTR lookup: '$NSLOOKUP' '$ip else m=$($NSLOOKUP "$ip" 2>/dev/null) fi That results in a stream of "$?/$ip/$ipm" tuples, which is consumed in a then protocol-independent m=$MASK4 [ "${a}" != "${a%:*}" ] && m=$MASK6 an=$($IPCALC -n $a/$m) if [ $? -ne 0 ]; then echo >&2 'ipcalc failed for '$a/$m continue fi furtherly analzyed as "listing: DNS failure" or "listing: multiple IP/network" via : ${MASK4:=24} : ${MASK6:=64} you know. The appropriates steps are then taken. This is all shell : ${AWK:=awk} : ${IPCALC:=ipcalc} : ${NSLOOKUP:=nslookup} : ${SED:=sed} : ${SS:=ss} ep=$(date +%s) and run from cron. I had at times more than hundred networks blocked like that, but half a dozen is at practice minimum. Maybe someone finds it useful. Doing this from scratch in some real programming language is an option, though; especially with non-blocking DNS lookups... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From coff at tuhs.org Tue Apr 21 02:57:06 2026 From: coff at tuhs.org (Steffen Nurpmeso via COFF) Date: Mon, 20 Apr 2026 18:57:06 +0200 Subject: [COFF] [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <20260420164338.GLnQ43Tq@steffen%sdaoden.eu> References: <42833F9E-52B4-4298-812E-479D3A01FFBF@alchemistowl.org> <2013c705-3885-4730-a01b-1f6dfbf70b0b@spamtrap.tnetconsulting.net> <20260420164338.GLnQ43Tq@steffen%sdaoden.eu> Message-ID: <20260420165706.J5OZB7U6@steffen%sdaoden.eu> Steffen Nurpmeso via COFF wrote in <20260420164338.GLnQ43Tq at steffen%sdaoden.eu>: |[i went to coff@ as requested.] and that does not allow .sh attachments. Wasn't source code sharing a major part of UUCP? Maybe someone finds it useful, i share like so. #!/bin/sh - #@ /root/bin/cron-fw.sh -- act for #@ - IPs with NXDOMAIN reverse DNS #@ - multiple IPs per $MASK4/6 network (with $DISALLOW_MULTI_IP_MASK) #@ - TODO should use file-locking for DB # DBG: dry-run if non-empty; if value is "y", use example address set : ${DBG=} : ${DISALLOW_MULTI_IP_MASK=y} # whether we also blacklist networks with multiple different IP currently sucking : ${LOG=y} : ${DB:=/run/.fw-ss-http} : ${DBTYPE:=httpnodom} : ${LOGFAC:=daemon.notice} : ${MASK4:=24} : ${MASK6:=64} : ${SECS:=21000} : ${TBL:=drop} : ${AWK:=awk} : ${IPCALC:=ipcalc} : ${NSLOOKUP:=nslookup} : ${SED:=sed} : ${SS:=ss} ep=$(date +%s) ipa_prep() { ip=$1 ws_trim ip "$ip" if [ "$ip" = "${ip#*[^0-9.]}" ]; then : elif [ "$ip" != "${ip%]*}" ] || [ "$ip" = "${ip#*[!0-9a-fA-F:]}" ]; then ip=${ip%]*} ip=${ip#*[*} ws_trim ip "$ip" [ "$ip" != "${ip#*[!0-9a-fA-F:]}" ] && ip= else ip= fi echo "$ip" } keyit() { echo $* | $SED -E -e 's/\./Y/g' -e 's/:/Z/g' } ws_trim() { __ws__=$2 __ws__=${__ws__#${__ws__%%[! ]*}} __ws__=${__ws__%${__ws__##*[! ]}} eval $1=\"$__ws__\" } nips= act_dbg() { nips= xips='1/10.1.2.3 0/1:3:4::FF 0/10.1.3.1 0/10.1.3.33 0/10.1.4.100' for ip in $xips; do t=${ip%/*} ip=${ip#*/} ip="$t/$ip/"$(keyit "$ip") nips="$nips $ip" done } act_httpnodom() { nips=$($SS -H -Q -t '( sport = :http or sport = :https )' | while read l; do ip=$(echo "$l" | $SED -E 's/.*[[:space:]]+([^[:space:]]+):[[:alnum:]_-]+$/\1/') if [ $? -ne 0 ]; then echo >&2 'Failure extracting IP address: '$l continue fi ip=$(ipa_prep "$ip") if [ -z "$ip" ]; then echo >&2 'IP address extaction error: '$ip': '$l continue fi ipm=$(keyit "$ip") eval l=\$ipdns_$ipm ipdns_$ipm=y if [ -n "$l" ]; then [ -n "$DBG" ] && echo >&2 '.. DNS lookup cached: '$ip continue elif [ -n "$DBG" ]; then echo >&2 'DNS PTR lookup: '$NSLOOKUP' '$ip else m=$($NSLOOKUP "$ip" 2>/dev/null) fi echo $?/$ip/$ipm done) } if [ "$DBG" = y ]; then act_dbg elif [ "$DBTYPE" = httpnodom ]; then act_httpnodom else echo >&2 'unknown DBTYPE: '$DBTYPE exit 64 fi if [ -n "$nips" ]; then nnips= for a in $nips; do t=${a%%/*} a=${a#*/} am=${a#*/} a=${a%/*} m=$MASK4 [ "${a}" != "${a%:*}" ] && m=$MASK6 an=$($IPCALC -n $a/$m) if [ $? -ne 0 ]; then echo >&2 'ipcalc failed for '$a/$m continue fi an=${an##NETWORK=} anm=$(keyit "$an") eval i=\$a_$anm if [ -n "$i" ]; then [ -n "$DBG" ] && echo >&2 '.. network already listed: '$an continue fi # PTR failure if [ "$t" -ne 0 ]; then nnips="$nnips $an" eval a_$anm=y [ -n "$DBG" ] && echo >&2 '+ listing: DNS failure: '$an elif [ -n "$DISALLOW_MULTI_IP_MASK" ]; then eval aem=\$xi_$am [ -z "$aem" ] && aem=0 aem=$((aem + 1)) eval xi_$am=$aem eval anem=\$xi_$anm [ -z "$anem" ] && anem=0 anem=$((anem + 1)) eval xi_$anm=$anem if [ $aem -ne $anem ]; then nnips="$nnips $an" eval a_$anm=y [ -n "$DBG" ] && echo >&2 '+ listing: multiple IP/network: '$an fi fi done nips=$nnips fi [ -f "$DB" ] || > "$DB" < "$DB" > "$DB".new \ $AWK -v DBG="$DBG" -v DBTYPE="$DBTYPE" -v EP="$ep" \ -v LOG="$LOG" -v LOGFAC="$LOGFAC" \ -v MASK4="$MASK4" -v MASK6="$MASK6" -v NE="$nips" \ -v SECS="$SECS" -v TBL="$TBL" ' BEGIN{ split("", xa); split("", da); } { if($2 + SECS > EP) xa[$1] = $2 else da[$1] = $2 } END{ oen = length(xa) den = length(da) split(NE, pnxa) split("", nxa) for(n in pnxa){ n = pnxa[n] if(!nxa[n]) nxa[n] = n } nen = length(nxa) # Any new one that actually is not is neither deleted nor readded if(nen > 0 && (oen > 0 || den > 0)){ for(e in nxa){ i = 0 if(xa[e]) i = 1 if(da[e]){ xa[e] = EP ++oen --den i = 1 } if(i){ delete nxa[e] if(--nen == 0) break } } } # stock m = "=" oen for(e in xa){ if(!xa[e]) continue print e " " xa[e] } act = "" # removals m = m ", -" den if(den > 0){ des = "" for(e in da){ if(!da[e]) continue if(des) des = des " " if(e ~ ":") des = des e "/" MASK6 else des = des e "/" MASK4 } if(des){ #if(act) act = act " " act = act "del " TBL " " des if(DBG) m = m " (" des ")" } } # additions m = m ", +" nen if(nen > 0){ nes = "" for(e in nxa){ if(!nxa[e]) continue if(nes) nes = nes " " if(e ~ ":") nes = nes e "/" MASK6 else nes = nes e "/" MASK4 print e " " EP } if(nes){ if(act) act = act " " act = act " add " TBL " " nes if(DBG) m = m " (" nes ")" } } if(DBG){ if(act) print "/root/bin/net-qos.sh adddel " act >> "/dev/stderr" print "logger -p " LOGFAC " -t /root/bin/cron-fw.sh:" DBTYPE " \"" m "\"" >> "/dev/stderr" }else{ if(act) system("/root/bin/net-qos.sh adddel " act) if(LOG) system("logger -p " LOGFAC " -t /root/bin/cron-fw.sh:" DBTYPE " \"" m "\"") } }' mv "$DB".new "$DB" # s-sht-mode --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)