From coff at tuhs.org Thu May 7 07:58:48 2026 From: coff at tuhs.org (Aron Insinga via COFF) Date: Wed, 6 May 2026 17:58:48 -0400 Subject: [COFF] [TUHS] Re: DECtapes under the UNIX room floor In-Reply-To: References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> Message-ID: <9c21baea-2b95-45d3-8d76-f7f1bd04ea1f@insinga.com> Hence the term "jiffy" for a power line frequency clock period: https://hackersdictionary.com/html/entry/jiffy.html With the possible exception of a system with only interpreted languages you need some sort of clock interrupt in order to implement time-sharing.  So there had to be one to allow TSS/8, the various PDP-6 time-sharing systems, and the PDP-11 time-sharing systems such as RSTS(/E) and Unix.  (This is actually a reply to the Unix mailing list, but the connection may be too thin.) In related news, https://blog.tephra.me/pdp-11-dl-11-repair-uart-2/https://archive.org/details/ [Remove '-2' from the URL to get the previous post which was actually about the serial interface.] At the time, I was told that the [never completed]  "minnow" or "tiny" PDP-10 would be the KT20 instead of the KT10 (like the KS10 etc.) because there was an existing option named KT10.  IIRC that person believed it was perhaps a clock, but I see now that it was the "KT10 Memory Protection and Relocation" option ('T' for time-sharing??) for the KA10.  The clock was actually the DK10. https://ftp.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/pdp10/KA10/PDP-10_InstallationMan.pdf https://archive.org/details/bitsavers_decpdp10peealTimeClockMaintenanceManualJul73_2436338/mode/2up - Aron On 5/6/26 14:19, Clem Cole via TUHS wrote: > 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 coff at tuhs.org Thu May 7 16:28:43 2026 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Thu, 07 May 2026 06:28:43 +0000 Subject: [COFF] [TUHS] Re: DECtapes under the UNIX room floor In-Reply-To: <202605061813.646IDYhk082929@ultimate.com> (Phil Budne via TUHS's message of "Wed, 06 May 2026 14:13:34 -0400") References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev> <20260506083214.un4cgnw7xzkevbm3@illithid> <202605061725.646HPaad081924@ultimate.com> <202605061813.646IDYhk082929@ultimate.com> Message-ID: <7wv7czlomc.fsf@junk.nocrew.org> Phil Budne wrote: > 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. Fun fact. Early ITS had a modem device, and used it to dial out to CTSS to get the time and date from the login prompt. Later ITS got its own clock device with a separate power supply. From coff at tuhs.org Thu May 14 08:34:37 2026 From: coff at tuhs.org (Mike Markowski via COFF) Date: Wed, 13 May 2026 18:34:37 -0400 Subject: [COFF] Masscomp 9-track tape Message-ID: <1fad591e-4509-46b1-b600-2ff9bc35925a@gmail.com> I just found an old Masscomp-created round 9-track tape from around 1990.  It has been stored in a temperature controlled lab, but this is the era I believe when tapes got sticky over time.  Can anyone recommend a place that can retrieve the data, if possible?  It's nothing extraordinary.  I spent my career in RF, both radar and comms, and is likely fortran software related to projectile tracking. Thanks! Mike Markowski From coff at tuhs.org Sat May 16 03:31:42 2026 From: coff at tuhs.org (emanuel stiebler via COFF) Date: Fri, 15 May 2026 13:31:42 -0400 Subject: [COFF] Masscomp 9-track tape In-Reply-To: <1fad591e-4509-46b1-b600-2ff9bc35925a@gmail.com> References: <1fad591e-4509-46b1-b600-2ff9bc35925a@gmail.com> Message-ID: <3a8e52a1-d10e-4d53-97cf-34eed5fdb429@e-bbes.com> On 2026-05-13 18:34, Mike Markowski via COFF wrote: > I just found an old Masscomp-created round 9-track tape from around > 1990.  It has been stored in a temperature controlled lab, but this is > the era I believe when tapes got sticky over time.  Can anyone recommend > a place that can retrieve the data, if possible?  It's nothing > extraordinary.  I spent my career in RF, both radar and comms, and is > likely fortran software related to projectile tracking. > > Thanks! > Mike Markowski And you are where? From coff at tuhs.org Sat May 16 04:51:18 2026 From: coff at tuhs.org (Mike Markowski via COFF) Date: Fri, 15 May 2026 14:51:18 -0400 Subject: [COFF] Masscomp 9-track tape In-Reply-To: <3a8e52a1-d10e-4d53-97cf-34eed5fdb429@e-bbes.com> References: <1fad591e-4509-46b1-b600-2ff9bc35925a@gmail.com> <3a8e52a1-d10e-4d53-97cf-34eed5fdb429@e-bbes.com> Message-ID: <4548bd40-84d8-4f66-93e7-7273cf72268a@gmail.com> On 5/15/26 1:31 PM, emanuel stiebler wrote: > On 2026-05-13 18:34, Mike Markowski via COFF wrote: >> I just found an old Masscomp-created round 9-track tape from around >> 1990.  It has been stored in a temperature controlled lab, but this >> is the era I believe when tapes got sticky over time.  Can anyone >> recommend a place that can retrieve the data, if possible?  It's >> nothing extraordinary.  I spent my career in RF, both radar and >> comms, and is likely fortran software related to projectile tracking. >> >> Thanks! >> Mike Markowski > And you are where? I'm in southeastern Pennsylvania.   -Mike From coff at tuhs.org Sat May 16 15:08:32 2026 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 16 May 2026 05:08:32 +0000 Subject: [COFF] AT&T MAC-4 Specimens Identified Message-ID: <7ZIwR8Svao1FjtAwOAe0ok891bLCAhRlDUljuj9E8xr5JKZ6XA8o8D7xRfIq4fLy8KcMdNAD77-BpGboCCDrSkG5OYRnwpLOj-_zPxBcAnI=@protonmail.com> Emailing with some exciting news, I've finally run down the chip code for the MAC-4 microcontroller: https://telecomarchive.s3.us-east-2.amazonaws.com/cc/pdf/circuits%20-%20integrated/circuits%20-%20integrated,%20293,%201,%201984-02-29.pdf The 293-series of ICs are MAC-4-based 4-bit microcontrollers for various applications. I had previously archived the datasheet here: https://archive.org/details/mac-4-specification-sheet Well, upon finding the former document I then realized that number sounded familiar. I have a lot of 5 various DIP-40 chips from AT&T, among them a 212C MAC-8 CPU and 229B peripheral controller. I hadn't identified the others but two of them might just be MAC-4s (if WECo didn't have other 293 family members). I have both a 293EC and 293ED, both in BTL 971-type ceramic DIP-40 carriers. I am now of the assumption these are both MAC-4 chips, representing the only MAC-4 specimens I'm aware of in the hands of anyone doing computing history research. In any case, I won't completely know until I build a checkout circuit. No MAC-4 applications survive, nor does the documentation on the assembly language, but I have been drafting a reconstruction of it based on cross-examination of the MAC-8 and MAC-4 binary opcodes and available MAC-8 documentation, so if nothing else will plan to make a MAC-4 version of SGS pretty closely based on the MAC-8 one I'm working on. Anywho just thought I'd share. Like UNIX 4.O, the MAC-4 has been a bit of a white whale for me...and now I finally hold not one but two potential specimens in my hands. I hope soon I'll be reporting back with the good news that it all works and that I've got an SGS built for it. Whatever hardware rig I build probably won't come close to a PROMAC or MAC-Mate (the period MAC-4 devkits) but one can dream... - Matt G. From coff at tuhs.org Mon May 18 03:58:33 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Sun, 17 May 2026 13:58:33 -0400 Subject: [COFF] Fwd: [multicians] Peter Neumann has died In-Reply-To: References: Message-ID: Tom van Vleck just passed the below forwarded message on the Multics mailing list. Very sad news. - Dan C. ---------- Forwarded message --------- From: Tom Van Vleck via groups.io Date: Sun, May 17, 2026, 1:27 PM Subject: [multicians] Peter Neumann has died To: Robert Watson wrote me Unfortunately, I email with the heartbreaking news that Peter Neumann passed away in his sleep last night, at the hospital in Santa Clara, due to complications arising from his fall and subsequent surgery a few weeks ago. His daughter Hellie was with him at the hospital at the time, and they had been listening to classical music together — as you may know, music was another of his great loves in life beyond computer security, with Peter an accomplished player of the piano, French horn, and various other instruments. Hellie has asked me to reach out to his friends and colleagues with this news — it’s still early in the morning in California and I will send on more information in due course, but it is currently believed that SRI will host a memorial service for him in Menlo Park in a month or so. https://www.csl.sri.com/~neumann/ is Peter's SRI home page. He was a wonderful friend and colleague. _._,_._,_ ------------------------------ Groups.io Links: You receive all messages sent to this group. View/Reply Online (#5960) | Reply to Group | Reply to Sender | Mute This Topic | New Topic ------------------------------ -- sent via multicians at groups.io -- more Multics info at https://multicians.org/ ------------------------------ Your Subscription | Contact Group Owner | Unsubscribe [ crossd at gmail.com] _._,_._,_ From coff at tuhs.org Tue May 19 10:20:01 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Mon, 18 May 2026 20:20:01 -0400 Subject: [COFF] RIP Peter Salus Message-ID: I just found out that Peter Salus passed away on May 15. His "Quarter Century of Unix" is required reading for any serious student of Unix history. - Dan C. From coff at tuhs.org Tue May 19 14:04:42 2026 From: coff at tuhs.org (Charles H. Sauer via COFF) Date: Mon, 18 May 2026 23:04:42 -0500 Subject: [COFF] [TUHS] RIP Peter Salus In-Reply-To: References: <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com> Message-ID: Beyond “Quarter Century” and USENIX, two non-TUHS notes about Peter 1. Peter wrote Casting the net: from ARPANET to Internet and beyond (https://archive.org/details/castingnetfromar0000salu) 2. Peter was extraodinarily helpful to me and Joe Duran with our Mainstream Videoconferencing book (https://notes.technologists.com/notes/2008/02/14/mainstream-videoconferencing-available-again/), helping get us the contract with Addison-Wesley, assisting with editing of the work in progress, posting very nice reviews, … Charlie > On May 18, 2026, at 10:13 PM, Mark Seiden via TUHS wrote: > > i must correct an error in what’s below (though not particularly relevant > except for Lou or others who know the family: > > emily salus (which i have now twice typed as “emaily”, sigh) tells me > mary salus is still suffering from two ailments that have > her in a memory unit since the time when peter went into the > hospital in march. > >> On May 18, 2026, at 6:30 PM, Mark Seiden wrote: >> >> depends what you mean by “this” and “interact”. >> he has mostly been retired after many years >> >> if you look at this: >> https://en.wikipedia.org/wiki/Peter_H._Salus >> you will discover that peter was not just an eminent linguist (by training, vocation and scholarship) >> but was also executive director of usenix assn for many years, so responsibile for a lot >> of community building. >> >> i first met peter in 1971, when we shared a group house in santa cruz at a summer linguistics institute, and cooked >> up numerous complicated group meals. he was a joyful connector and a delight to hang out with. >> >> and full of stories, which is why he wrote several books about the history of unix and the early history of the internet. >> (he was there and knew everybody, so the books are authoritative…) >> >> at some point peter registered the domain name pedant.com. he had (and touted) an encyclopedic knowledge of >> facts both useless and useful, so he fit that descriptor. also a sense of humor that was abundant (and sometimes, as linguists >> sometimes do, overstep the comfortable boundaries of ordinary civilians accustomed to using language more conventionally.) >> >> peter was a longtime friend of lou katz (since the 1960s), who told me a couple weeks ago that peter was in hospice, >> cheerful, but suffering from congestive heart failure. (i cc lou on this). >> >> (peter was predeceased by his wife, mary salus.) >> >> peter and mary’s daughter emily is at >> https://www.linkedin.com/in/ewsalus/ >> and i believe her current email address is emily at openprisetech.com. >> >> (personally very sad to lose both peter neumann and peter salus during the same week, two mentors, men of infinite jest, and there >> will never be anyone like them again.) >> >>> On May 18, 2026, at 5:38 PM, Kevin Bowling via TUHS wrote: >>> >>> RIP. Did he ever interact with this community? >>> >>> On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS wrote: >>>> >>>> I just found out that Peter Salus passed away on May 15. His "Quarter >>>> Century of Unix" is required reading for any serious student of Unix >>>> history. >>>> >>>> - Dan C. >> > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From coff at tuhs.org Wed May 20 09:04:15 2026 From: coff at tuhs.org (Arnold Robbins via COFF) Date: Tue, 19 May 2026 17:04:15 -0600 Subject: [COFF] [TUHS] RIP Peter Salus In-Reply-To: References: Message-ID: <202605192304.64JN4Gnv070349@freefriends.org> Dan Cross via TUHS wrote: > I just found out that Peter Salus passed away on May 15. His "Quarter > Century of Unix" is required reading for any serious student of Unix > history. > > - Dan C. That's sad. I met him a few times at USENIX conferences and enjoyed talking with him. Arnold From coff at tuhs.org Thu May 21 11:25:42 2026 From: coff at tuhs.org (Larry McVoy via COFF) Date: Wed, 20 May 2026 18:25:42 -0700 Subject: [COFF] [TUHS] Re: Fwd: [multicians] Peter Neumann has died In-Reply-To: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> References: <0120bad7-0b7c-4290-a71c-cdb56119045b@oracle.com> Message-ID: <20260521012542.GC26412@mcvoy.com> My dad, a physist, said there is no after life. You are only alive if people are still talking about you. A nod to my dad, I miss him, but a huge nod to Peter Neumann, he is still here. On Wed, May 20, 2026 at 02:53:03PM -0700, Alan Coopersmith via TUHS wrote: > Some published obituaries/memorials: > > https://cacm.acm.org/news/in-memoriam-peter-g-neumann-1932-2026/ > https://www.nytimes.com/2026/05/17/technology/peter-g-neumann-dead.html > https://www.sri.com/press/story/peter-neumann-saw-the-internets-dangers-before-the-internet-existed/ -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From coff at tuhs.org Thu May 21 12:03:02 2026 From: coff at tuhs.org (Warren Toomey via COFF) Date: Thu, 21 May 2026 12:03:02 +1000 Subject: [COFF] Virtual OS Museum Message-ID: All, I've just seen this and I thought it would be relevant here: https://virtualosmuseum.org/ This is a virtual museum of operating systems (and standalone applications) running under emulation, implemented as a Linux VM for QEMU, VirtualBox, or UTM. A custom emulator-independent launcher is provided, and all OSes and emulators are pre-installed and pre-configured. The launcher includes a snapshot feature to quickly revert broken installations back to a working state. Hypervisor installers and shortcuts to run the VM on Windows, macOS, and Linux are also included. Cheers, Warren From coff at tuhs.org Thu May 21 13:04:31 2026 From: coff at tuhs.org (Alexis via COFF) Date: Thu, 21 May 2026 13:04:31 +1000 Subject: [COFF] Community 'deprecation' of gets(3) Message-ID: <87pl2pbgzk.fsf@gmail.com> Hi all, Wasn't entirely sure whether this would be appropriate for TUHS, so erring on the side of caution and posting here. :-) If it _is_ appropriate, please loop TUHS in on any replies. At what point did the use of gets(3) become 'deprecated' by the C / Unix / whatever communities, for security and general buginess reasons? In the sense that there was a general consensus that it shouldn't be used, particularly due to the security implications, despite still being permitted by specs? gets(3) was: * included in Issue 1, but i can't find an online copy of that (or of Issue 1 of the SVID)[a]; * deprecated in C99, removed in C11; and * obsoleted by POSIX Issue 7 / .1-2008. Alexis. [a] My search-fu has been failing in general of late, so i wouldn't be surprised if someone said "It's /here/; that took me 10 seconds to find." :-P From coff at tuhs.org Thu May 21 13:50:18 2026 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 21 May 2026 03:50:18 +0000 Subject: [COFF] Community 'deprecation' of gets(3) In-Reply-To: <87pl2pbgzk.fsf@gmail.com> References: <87pl2pbgzk.fsf@gmail.com> Message-ID: On Wednesday, May 20th, 2026 at 20:04, Alexis via COFF wrote: > > Hi all, > > Wasn't entirely sure whether this would be appropriate for TUHS, > so erring on the side of caution and posting here. :-) If it _is_ > appropriate, please loop TUHS in on any replies. > > At what point did the use of gets(3) become 'deprecated' by the C > / Unix / whatever communities, for security and general buginess > reasons? In the sense that there was a general consensus that it > shouldn't be used, particularly due to the security implications, > despite still being permitted by specs? > > gets(3) was: > > * included in Issue 1, but i can't find an online copy of that (or > of Issue 1 of the SVID)[a]; > * deprecated in C99, removed in C11; and > * obsoleted by POSIX Issue 7 / .1-2008. > > > Alexis. > > [a] My search-fu has been failing in general of late, so i > wouldn't be surprised if someone said "It's /here/; that took me > 10 seconds to find." :-P > I feel like I've seen earlier guidance, but 1985's SVID Issue 1 gives an "Application Usage" entry of: > Reading too long a line through gets causes gets to break. > The use of fgets is recommended. This note is also in the X/Open Portability Guide, but not the /usr/group standard. I don't see this in the SVR2 manuals (which the SVID is based on) nor 4.3BSD. So I've got a confirmed backstop of official guidance in 1985 not to use gets(3), but I feel like I've seen earlier mentions in some BTL-adjacent paper or manpage. - Matt G. From coff at tuhs.org Thu May 21 15:31:56 2026 From: coff at tuhs.org (Andrew Warkentin via COFF) Date: Wed, 20 May 2026 23:31:56 -0600 Subject: [COFF] Virtual OS Museum In-Reply-To: References: Message-ID: I'm the curator of this. Been on this list for a while actually but I'm barely active; I've got a tendency to stay quiet that has been pretty crippling, not due to social anxiety but rather inertia and a lack of stuff to say (sometimes real, sometimes merely perceived). I posted about it in a few other places, but totally forgot about this list. Basically every OS you can think of is included in some form; I've been collecting emulator images since 2003 and have built up a massive collection (and I've still got lots more stuff to install; I have enough to go from the current ~1700 installations to well over 2000). From coff at tuhs.org Thu May 21 16:05:45 2026 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Thu, 21 May 2026 06:05:45 +0000 Subject: [COFF] Virtual OS Museum In-Reply-To: (Andrew Warkentin via COFF's message of "Wed, 20 May 2026 23:31:56 -0600") References: Message-ID: <7wpl2pe1qe.fsf@junk.nocrew.org> Andrew Warkentin wrote: > Basically every OS you can think of is included in some form Can confirm. I haven't seen the full list yet, but from what I have learned so far the coverage is exhaustive. From coff at tuhs.org Thu May 21 19:12:18 2026 From: coff at tuhs.org (Ori Kuttner via COFF) Date: Thu, 21 May 2026 12:12:18 +0300 Subject: [COFF] Virtual OS Museum In-Reply-To: <7wpl2pe1qe.fsf@junk.nocrew.org> References: <7wpl2pe1qe.fsf@junk.nocrew.org> Message-ID: Hi Andrew, Regarding the Virtual OS Museum, I was wondering if it is necessary to download the VM to use it, or if there is an online version available for use directly in the browser? -- Ori Kuttner CEO Helicon Books http://www.heliconbooks.com On Thu, May 21, 2026 at 9:05 AM Lars Brinkhoff via COFF wrote: > Andrew Warkentin wrote: > > Basically every OS you can think of is included in some form > > Can confirm. I haven't seen the full list yet, but from what I have > learned so far the coverage is exhaustive. > From coff at tuhs.org Thu May 21 23:09:02 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Thu, 21 May 2026 09:09:02 -0400 Subject: [COFF] Community 'deprecation' of gets(3) In-Reply-To: <87pl2pbgzk.fsf@gmail.com> References: <87pl2pbgzk.fsf@gmail.com> Message-ID: On Wed, May 20, 2026 at 11:04 PM Alexis via COFF wrote: > Wasn't entirely sure whether this would be appropriate for TUHS, > so erring on the side of caution and posting here. :-) If it _is_ > appropriate, please loop TUHS in on any replies. [I think this is perfectly acceptable for TUHS; Cc'ed there] > At what point did the use of gets(3) become 'deprecated' by the C > / Unix / whatever communities, for security and general buginess > reasons? In the sense that there was a general consensus that it > shouldn't be used, particularly due to the security implications, > despite still being permitted by specs? I don't know when people first started thinking about it, but after the November 1988 Morris Internet worm, it was generally understood that it was a bad idea to use `gets()`, particularly in programs that were exposed to untrusted input. Especially if those were privileged. Levy's, "Smashing the Stack for Fun and Profit" appeared in Phrack 8 years later, in November 1996, and opened the flood gates for a whole slew of buffer overrun bugs turned into security exploits. The bulk of those took a couple of years to address, with new variations on the theme seemingly discovered every few months: it wasn't just `gets()`, but `strcpy`/`strcat`, `sprintf`, `printf(buf)` (e.g., without a format string), and so on, leading to a flurry of activity to try and introduce safe(r) string operations into C. After that, people who hadn't before got the message: "gets() is dangerous; don't use it" along with a few other best practices ("always use an explicit format string for `printf` etc). Incidentally, `snprintf` came around that time, and a lot of buggy code was written to try and use `strncpy` and `strncat`; eventually we got `strlcpy` and `strlcat`, which the world seems to have mostly settled on: those are in POSIX now. The long tail of all of that is still with us, though, and new issues of that class are introduced regularly; sigh. > gets(3) was: > > * included in Issue 1, but i can't find an online copy of that (or > of Issue 1 of the SVID)[a]; > * deprecated in C99, removed in C11; and > * obsoleted by POSIX Issue 7 / .1-2008. Personally, I am amazed it remained in the C standard and POSIX for as long as it did. - Dan C. From coff at tuhs.org Sun May 24 02:24:19 2026 From: coff at tuhs.org (Steffen Nurpmeso via COFF) Date: Sat, 23 May 2026 18:24:19 +0200 Subject: [COFF] [TUHS] troff.org and the old bell-labs.com domain In-Reply-To: References: <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk> <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan> Message-ID: <20260523162419.yY6zi8rp@steffen%sdaoden.eu> Bakul Shah via TUHS wrote in : |On May 23, 2026, at 7:49 AM, Warner Losh via TUHS wrote: |Étienne Ghys puts Knuth in the company of Gutenburg, Pacioli, Da Vinci. Gutenberg. |Only time will tell but we can be sure that a Tex/LaTeX document created |today will still produce the same output 100 years from now. | |https://tex.stackexchange.com/questions/1319/showcase-of-beautiful-typog\ |raphy-done-in-tex-friends | |https://tug.org/texshowcase/ | |Ghys - The Shape of Letters: From Leonardo Da Vinci to Donald Knuth |https://www.youtube.com/watch?v=1OIxzewWilc The n-t-roff/heirloom-doctools at github can use the same layout algorithm; or .. there was a big thing (issue) saying "Add typographical enhancements for paragraph composition and letter adjustment" in 2017, so it possibly is even better. (I am only tracking it, i stopped using it before; anything that is, i only write some letters for which i have simple macros, and i use an elder groff that "can" the mdoc enhancements i wrote.) Btw one can do .als ALIAS als .ALIAS STRING ds .STRING B \\fB\\$*\\fP and then say \*[B bold text] inline. Should be nice on american keyboard. And other than that, as soon as references, anchors, index entries etc come into play, everything gets sick. Here some TeX from 2000-05-31: \open{section}[subsec:refs] \title{Cross--References} \close{section} The cross--references are built very similar to the way described in \ref{sec:tocs}, which means they allow a very flexible way of formatting themselves. However, this time this can be configured by only five (5) macros. \mli[start] \mac|\setRefPrefersTocTitle{X}| \idx{1~~Macros~~Cross--References~~\setRefPrefersTocTitle}% \idx{1~~(Ungrouped) Macros~~\setRefPrefersTocTitle}% can be set to the usual \var|\TRUE| or \var|\FALSE| (\val|\TRUE|). It defines-- assumed you've used the \mac|\toctxt| macro as described in \idx{1~~Macros~~Sectioning~~\toctxt}% \idx{1~~(Ungrouped) Macros~~\toctxt}% \ref{sec:sectioning:toctxt} --if the content of this element should be used instead of the content of the sectioning title. All lost. But compare with nice roff letter: .\"ds DBG .mso s-letter.tmac .mso s-hw_german.tmac .LETTER . .BODY .SENDER Steffen ... Darmstadt .SENDER END .SENDERMEDIA Web:\t... Mail:\t... Phone:\t+49 ... .SENDERMEDIA END . .RECEIVER Firma ... GmbH & Co. KG z. Hd. Frau ... 58123 Hagen .RECEIVER END . .DATE "......2005" .SUBJECT "Danke" .TITLELINE_SUBJECT "Danke" .GREETING Sehr geehrte Damen und Herren, sehr geehrte Frau ..., vielen Dank für ,,die Entschädigung für meine Unannehmlichkeiten``. Damit hatte ich gar nicht gerechnet, und es wäre auch wirklich nicht nötig gewesen \*[---] lecker war das Zeug aber trotzdem, und zwar gänzlich, insbesondere aber die Schokoladen-Zwiebäcke und die Biscotte, da die ,,Milch-Minis`` \*[EM doch] extrem süß und fett sind. (Unter uns: um wieder auf einen ausgeglichenen Kalorienstand zu kommen, werde ich mir eine Woche lang mein morgendliches Croissant vom Bäcker verkneifen müssen. Argh!) ... Mit freundlichen Grüßen, . .BODY END It is unfair. Nothing compared to Gutenberg, from Mainz, not far away from here. All those little letters. And lead is also poisoning. Just a couple of days ago i had read that americans in the past -- time span covering the members of this list! -- lost 5 points IQ because of lead water pipes! All of you! By sheer luck that is a thing of the past. --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 Wed May 27 03:30:35 2026 From: coff at tuhs.org (Noel Chiappa via COFF) Date: Tue, 26 May 2026 13:30:35 -0400 (EDT) Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? Message-ID: <20260526173035.08A0918C075@mercury.lcs.mit.edu> {BCC'ing to TUHS, in an attempt to move to COff} > From: Steve Jenkin > could something like C have improved MULTICS or helped it's success in > the marketplace? The biggest problem of Multics (i.e. the large system of code, as existing and installed at about 100 sites) was i) (to echo John Levine) that it was tied very strongly to Honeywell hardware, and ii) Honeywell management were total bozos, and could/would not produce new, improved, cost-effective hardware. See here: https://multicians.org/hill-mgt.html and related links (e,g, the Palyn report) for a lot more about that. In short, Multics' biggest problem(s), in the real world, were not technical, so technical solutions would not have helped. The 'tie to Honeywell hardware' existed at two levels. First, at a high, conceptual level, Multics was (in the eye of a user) a single-level memory system (_everything_ was an addressable segment), with hardware support. Now, it's true that any Turing machine could emulate any other, but the performance may be considerably slower (there's an example below). Second, at a low level, the Multics PL/1 code was crammed to the gills with declarations like: dcl global_handle bit(36) aligned static; with the word length of the machine in the source. (It's true that C has the opposite prolem - one that's a real issue in writing networking code - other than bit fields, C declarations don't let you be explicit about data sizes.) Multics PL/1 also had extensions (effectively) to support the Multics high-level conceptual model. One is that saying 'foo$bar(arg1, arg2)' called entry point 'bar' in segment 'foo'. Clearly, to do something similar in C, one could write: long_call("foo", "bar", arg1, arg2); where 'long_call()' is an assembler routine that 'does the right thing' - but that will necessarily be considerably slower than the original Multics/PL/1 equialent, which is a single subroutine-call instruction. If one wrote it somewhat differently, as: subr_pointr = long_get_subr_addr("foo", "bar"); (*subr_pointr)(arg1, arg2); then if one only did the call to long_get_subr_addr() once, it would only be slowish the first time one called foo$bar. (That's the inter-segment code syntax; I forget how data worked.) Multics also makes considerable use of conditions (in the 'throw'/'catch' meaning of that). One _can_ add conditions to C (I did it, for a compiler with a recursive descent parser I wrote, and I know of another implementation, using longjmp - mine used assembler versions of 'on()'/'signal()', using standard C subroutine call semantics, along with an 'enhanced' stack frame format [condition handlers stack, so that way I got free unstacking of handlers on subroutine exit]), but it's not part of 'standard' C. In short, it wouldn't be simple to use 'stock' C for Multics (for doing the whole thing, including the OS and system tools, not just applications - the way it used PL/1). Noel From coff at tuhs.org Wed May 27 10:11:29 2026 From: coff at tuhs.org (Larry McVoy via COFF) Date: Tue, 26 May 2026 17:11:29 -0700 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260526173035.08A0918C075@mercury.lcs.mit.edu> References: <20260526173035.08A0918C075@mercury.lcs.mit.edu> Message-ID: <20260527001129.GC28587@mcvoy.com> On Tue, May 26, 2026 at 01:30:35PM -0400, Noel Chiappa via COFF wrote: > dcl global_handle bit(36) aligned static; > > with the word length of the machine in the source. (It's true that C has the > opposite prolem - one that's a real issue in writing networking code - > other than bit fields, C declarations don't let you be explicit about > data sizes.) >From BitKeeper's libc/style.h which you can see at http://mcvoy.com/lm/tmp/style.h /* types */ typedef unsigned char u8; typedef unsigned short u16; typedef unsigned int u32; typedef unsigned long long u64; typedef signed char i8; typedef signed short i16; typedef signed int i32; typedef signed long long i64; those have worked for the last 27 years on pretty much every platform, we never had to ifdef those. I'm not saying they will work forever but they have worked for a long time. And I've always found it annoying that modern C didn't have those so I made them for our source. --lm From coff at tuhs.org Wed May 27 16:30:06 2026 From: coff at tuhs.org (Peter Pentchev via COFF) Date: Wed, 27 May 2026 09:30:06 +0300 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527001129.GC28587@mcvoy.com> References: <20260526173035.08A0918C075@mercury.lcs.mit.edu> <20260527001129.GC28587@mcvoy.com> Message-ID: On Tue, May 26, 2026 at 05:11:29PM -0700, Larry McVoy via COFF wrote: > On Tue, May 26, 2026 at 01:30:35PM -0400, Noel Chiappa via COFF wrote: > > dcl global_handle bit(36) aligned static; > > > > with the word length of the machine in the source. (It's true that C has the > > opposite prolem - one that's a real issue in writing networking code - > > other than bit fields, C declarations don't let you be explicit about > > data sizes.) > > From BitKeeper's libc/style.h which you can see at > > http://mcvoy.com/lm/tmp/style.h > > /* types */ > typedef unsigned char u8; > typedef unsigned short u16; > typedef unsigned int u32; > typedef unsigned long long u64; > typedef signed char i8; > typedef signed short i16; > typedef signed int i32; > typedef signed long long i64; > > those have worked for the last 27 years on pretty much every platform, we > never had to ifdef those. I'm not saying they will work forever but they > have worked for a long time. > > And I've always found it annoying that modern C didn't have those so I > made them for our source. Yeah, C99 introduced the stdint.h header, but before that everyone and their pet smeerp carried those around. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- 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 Wed May 27 20:49:42 2026 From: coff at tuhs.org (Noel Chiappa via COFF) Date: Wed, 27 May 2026 06:49:42 -0400 (EDT) Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? Message-ID: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> > From: Larry McVoy > From BitKeeper's libc/style.h > ... > typedef signed char i8; > typedef signed short i16; > typedef signed int i32; > typedef signed long long i64; As I've mentioned before, I did something similar for portable networking code we wrote at MIT; our types were all 'xxxy', where 'xxx' were the semantics (signed integer, unsigned integer, none, etc) and 'y' was the size - but richer than the above list: in addition to 8,16,32 (used for giving packet formats) we also had 'f' (at least 16 bits, but whatever was fastest on the architecture/compiler at hand - 16 bits on the early MC68000's); 'w' (the word lenth - address size - of the machine); etc. The resultant code was wonderfully portable; I once, on a bet, managed to move our portable real-time OS (written with these declarations) to a new machine (the AMD 29000) literally overnight; I pulled an all-nighter, and it was runing when people got there the next morning. > those have worked for the last 27 years on pretty much every platform, In that later era, OK. They would not have worked in mine; on a PDP-11, an 'int' was 16 bits. (I wonder how long an 'int' is on modern 64-bit architectures? They probably had to keep it at 32 bits, or it would have broken too much code - or was it defined to always be 32 bits in later C specs?) Noel From coff at tuhs.org Wed May 27 23:15:03 2026 From: coff at tuhs.org (Peter Pentchev via COFF) Date: Wed, 27 May 2026 16:15:03 +0300 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> Message-ID: On Wed, May 27, 2026 at 06:49:42AM -0400, Noel Chiappa via COFF wrote: > > From: Larry McVoy > > > From BitKeeper's libc/style.h > > ... > > typedef signed char i8; > > typedef signed short i16; > > typedef signed int i32; > > typedef signed long long i64; > > As I've mentioned before, I did something similar for portable networking > code we wrote at MIT; our types were all 'xxxy', where 'xxx' were the > semantics (signed integer, unsigned integer, none, etc) and 'y' was the size > - but richer than the above list: in addition to 8,16,32 (used for giving > packet formats) we also had 'f' (at least 16 bits, but whatever was fastest > on the architecture/compiler at hand - 16 bits on the early MC68000's); 'w' > (the word lenth - address size - of the machine); etc. > > The resultant code was wonderfully portable; I once, on a bet, managed to > move our portable real-time OS (written with these declarations) to a new > machine (the AMD 29000) literally overnight; I pulled an all-nighter, and > it was runing when people got there the next morning. > > > those have worked for the last 27 years on pretty much every platform, > > In that later era, OK. They would not have worked in mine; on a PDP-11, an > 'int' was 16 bits. (I wonder how long an 'int' is on modern 64-bit > architectures? They probably had to keep it at 32 bits, or it would have > broken too much code Correct, it is 32 bits on most architectures. > - or was it defined to always be 32 bits in later C specs?) No, the C standard has never mandated exact sizes for any of those types. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- 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 Wed May 27 23:16:25 2026 From: coff at tuhs.org (Peter Pentchev via COFF) Date: Wed, 27 May 2026 16:16:25 +0300 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> Message-ID: On Wed, May 27, 2026 at 04:15:03PM +0300, Peter Pentchev wrote: > On Wed, May 27, 2026 at 06:49:42AM -0400, Noel Chiappa via COFF wrote: > > > From: Larry McVoy > > > > > From BitKeeper's libc/style.h > > > ... > > > typedef signed char i8; > > > typedef signed short i16; > > > typedef signed int i32; > > > typedef signed long long i64; > > > > As I've mentioned before, I did something similar for portable networking > > code we wrote at MIT; our types were all 'xxxy', where 'xxx' were the > > semantics (signed integer, unsigned integer, none, etc) and 'y' was the size > > - but richer than the above list: in addition to 8,16,32 (used for giving > > packet formats) we also had 'f' (at least 16 bits, but whatever was fastest > > on the architecture/compiler at hand - 16 bits on the early MC68000's); 'w' > > (the word lenth - address size - of the machine); etc. > > > > The resultant code was wonderfully portable; I once, on a bet, managed to > > move our portable real-time OS (written with these declarations) to a new > > machine (the AMD 29000) literally overnight; I pulled an all-nighter, and > > it was runing when people got there the next morning. > > > > > those have worked for the last 27 years on pretty much every platform, > > > > In that later era, OK. They would not have worked in mine; on a PDP-11, an > > 'int' was 16 bits. (I wonder how long an 'int' is on modern 64-bit > > architectures? They probably had to keep it at 32 bits, or it would have > > broken too much code > > Correct, it is 32 bits on most architectures. > > > - or was it defined to always be 32 bits in later C specs?) > > No, the C standard has never mandated exact sizes for any of those types. ...of course, with the exception, mentioned in my previous e-mail, of the stdint.h header in C99 and later which defines uint32_t, int16_t, etc. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- 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 Thu May 28 00:16:29 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Wed, 27 May 2026 10:16:29 -0400 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> Message-ID: On Wed, May 27, 2026 at 6:49 AM Noel Chiappa via COFF wrote: > [snip] > In that later era, OK. They would not have worked in mine; on a PDP-11, an > 'int' was 16 bits. (I wonder how long an 'int' is on modern 64-bit > architectures? They probably had to keep it at 32 bits, or it would have > broken too much code - or was it defined to always be 32 bits in later C > specs?) On most (??) 64-bit machines, `int` is 32-bits. During the 32->64 bit transition, there was a lot of variation and debate around the "ILP" widths: that is, what the widths of `int`, `long`, and pointers should be. I think most Unix-y systems settled on I32LP64 (usually just written, "LP64"), where `int` is 32-bits and long and pointers are both 64-bits; some systems were ILP64 (`int`, `long`, and pointers are all 64-bits), and several are "LLP64" where `int` and `long` are 32-bits, but `long long` and pointers are 64-bits. There are several other variations on the theme; old Crays also made `short` 64-bits. I asked a person working on clang and LLVM about 32-bit `int` on 64-bit machines once; why not make `int` 64-bits? The response was that that was "too big" for most things and there was no significant advantage otherwise. It might have also been marginally slower for stores on some machines around that time. On the other hand, the exact-width integer types, as defined in ``, are exactly what they say: integers of an exact width, with names like `int32_t`, `uint64_t`, and so on. A sort of annoying issue with them is that their introduction was not accompanied by `printf`-family formatting directives; instead, implementations are expected to provide ``, which defines macros that expand to short strings holding the format specifiers for each type; one is expected to use string concatenation behavior to use them. E.g., uint64_t foo = 0xdeadbeefcafeULL; /* Is ULL correct here? Probably. */ printf("foo is %#"PRIx64" in hex\n", foo); When run, this prints, "foo is 0xdeadbeefcafe in hex". But man, the code looks like someone whacked it with an ugly stick. - Dan C. From coff at tuhs.org Thu May 28 01:35:02 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Wed, 27 May 2026 11:35:02 -0400 Subject: [COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu> Message-ID: On Wed, May 27, 2026 at 10:17 AM Dan Cross via COFF wrote: > > During the 32->64 bit transition, there was a lot of variation and > debate around the "ILP" widths: that is, what the widths of `int`, > `long`, and pointers should be. I was in DEC's compiler back end group and indeed there was a big debate about it. > I think most Unix-y systems settled > on I32LP64 (usually just written, "LP64"), where `int` is 32-bits and > long and pointers are both 64-bits; some systems were ILP64 (`int`, > `long`, and pointers are all 64-bits), and several are "LLP64" where > `int` and `long` are 32-bits, but `long long` and pointers are > 64-bits. There are several other variations on the theme; old Crays > also made `short` 64-bits. > DEC's Tru64 Unix decided to go with ILP64 (int, long, pointer all 64 bits). IIRC they did end up adding a LP64 (int 32 bits, long and pointer 64 bits) compiler option later on. The C compiler for 64 bit OpenVMS is LP64. Microsoft's 64 bit Windows C compiler is LLP64 (int and long 32 bits, long long and pointer 64 bits). > > I asked a person working on clang and LLVM about 32-bit `int` on > 64-bit machines once; why not make `int` 64-bits? The response was > that that was "too big" for most things and there was no significant > advantage otherwise. It might have also been marginally slower for > stores on some machines around that time. > It was a lot more than marginally slower. It was very significantly slower. And the problem existed with fetches as well as stores. The issue was the small (by modern standards) cache sizes on early 64 bit processors. Building a large application with 64 bit rather than 32 bit ints often meant much larger data structure sizes and greatly increased memory traffic and cache contention. DEC ended up building their 64 bit compilers as 32 bit applications because the compilers didn't need more than a 32 bit address space and ran a lot faster that way. With larger modern cache sizes this usually is no longer an issue. -Paul W. From coff at tuhs.org Thu May 28 05:56:52 2026 From: coff at tuhs.org (Adam Thornton via COFF) Date: Wed, 27 May 2026 12:56:52 -0700 Subject: [COFF] [TUHS] Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527180105.GA29244@mcvoy.com> References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: On Wed, May 27, 2026 at 11:01 AM Larry McVoy via TUHS wrote: > I took a different approach, we hired excellent programmers > and our stuff worked. > > This is probably a COFF question, but I'm interested in your process for hiring excellent programmers. CCing to COFF and I suggest we continue it there. Through too much of my career, choosing whom to hire has been plagued by "we end up picking people a lot like the people already on the team," which, while it maybe helps team cohesion, isn't a great way to get fresh blood and new perspectives, but also by the even-less-tractable problem of "people who are good at interviewing, know their algorithms, whatever, but once they start working, they're not really very good at thinking in the context of the actual problem before them." And that itself can come in several flavors. One is the person who interviews well but doesn't actually do good software engineering, because they've optimized for interviewing, not for shipping maintainable code, or working on a team where their output has to play nice with other people's output, or whatever, the point being, they sounded good for the two or three hours you sent with them, but they don't actually produce good work. Another is even worse: the person who really *is* all that good, but who's a jerk that no one wants to work with. Figuring out who's going to work well as an addition to an existing team seems like a really difficult problem, particularly the Toxic Genius problem. I'd *much* rather work with someone who's OK-to-good at their job and is easy to work with, doesn't get defensive if you ask "why X rather than Y?", et cetera, than someone who's absolutely brilliant but everyone dreads getting their code reviewed by them, or even worse, reviewing code that the Toxic Genius has put a lot of ego into (which is generally all of it). My current boss is really good at hiring people who genuinely like working together (and in my estimation, we're a highly competent team), and she's written down some of her methodology down in https://sqr-081.lsst.io/, but I'm very interested in how other people do this as well. Adam From coff at tuhs.org Thu May 28 06:42:54 2026 From: coff at tuhs.org (Jeffrey H. Johnson via COFF) Date: Wed, 27 May 2026 16:42:54 -0400 Subject: [COFF] [TUHS] Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au> <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: I'm going to jump in here and say that it is absolutely possible to write perfectly good C code that doesn't have these kinds of bugs or issues that is also incredibly portable, free of all undefined behaviors, and can run on every platform, including the really weird ones, and anyone who says it doesn't or you can't do so is cutting corners. Does it take a lot more time and discipline, yes. It also takes a lot longer to accomplish a lot less, but C absolutely gives you the tools you need to produce bug-free code. In fact, if you really want to get into it, you can produce code that is not only bug-free, but tools exist in the formal verification realm that allow you to prove mathematically the absence of bugs, including memory safety, in C code. You can take a look at this CRC utility that I recently wrote, because it's more an example of how I would a write universally portable utility of this type that's intended to be bug-free, but not going to the expense of formal verification to make it provably so. https://gitlab.com/dps8m/crc It was carefully constructed to be portable and correct on every platform with a standard s-onforming C compiler. It works equally on ancient pre‑ANSI / "C86" / K&R C compilers, environments providing deficient stdio implementations, environments with broken (or completely missing) division or modulo math operations, systems where NULL is not equal to zero (e.g. Honeywell 600/6000‑series), systems using one's‑complement integer representation (e.g., Unisys ClearPath Dorado / OS 2200 with UCS C), systems with character sizes other than 8 bits (e.g., DEC PDP‑10, H6000, Unisys), and systems using non‑ASCII character sets (e.g., IBM mainframes, Unisys MCP), or even systems using non-ASCII/non-EBCDIC character sets. It has it's own internal implementation of arbitrary precision math code that's slow but stable that I use elsewhere. It only needs the C compiler to provide one storage type with a width at least as wide as the 32‑bit CRC. Even compilers for the Commodore 64 and Apple II such as Vbcc can fit the bill here. It supports systems with characters types of least 8 bits, but is happy with 9 bits, or 12 bits, 17-bit bit or even 32-bit chars. The same source file works on Multics, TOPS-20, CP/M-86, CP/M-80, MS-DOS, Windows, ELKS, Atari ST, Amiga, and every UNIX system, and really should be free bugs and undefined behavior on all platforms. C can do it all. -- Jeffrey H. Johnson trnsz at pobox.com From coff at tuhs.org Thu May 28 07:28:05 2026 From: coff at tuhs.org (Larry McVoy via COFF) Date: Wed, 27 May 2026 14:28:05 -0700 Subject: [COFF] [SPAM] Re: [TUHS] Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: References: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> Message-ID: <20260527212805.GB29244@mcvoy.com> On Wed, May 27, 2026 at 12:56:52PM -0700, Adam Thornton wrote: > On Wed, May 27, 2026 at 11:01???AM Larry McVoy via TUHS wrote: > > > I took a different approach, we hired excellent programmers > > and our stuff worked. > > > > > This is probably a COFF question, but I'm interested in your process for > hiring excellent programmers. CCing to COFF and I suggest we continue it > there. Strangely enough, a lot of the same stuff your current boss wrote up. The technical part is pretty easy, the core of my team were all top 1% programmers. Those people tend to recognize that talent up front. We had two compatibility tests and one question (that well over 90% of programmers fail). If we needed you to sweep the floors, would you? We asked ourselves if the recruit passed the super market test. If you saw them at Safeway do you want to go talk to them or do you want to hide in another isle? The technical (sort of) question was from me and it had a lot to do with the fact that we were a small team and I wasn't interested in managing a large team: Tell me about something that you built, at least 10 other people have used it without contacting you other than to thank you. By "built" I mean you identified the problem, came up with a solution, packaged it up, announced it on comp.sources.whatever (or hackernews for you youngsters). You did the README, the man pages, any web support needed. You wrote test cases. You did *everything*. No support staff. I had an example that I did as a student, I wanted to have regexp version of mv/cp. I called them move.c and copy.c and did a shell function like so: function mv { case "$1" in *=*) move $*;; *) /bin/mv $* esac } and then you could do $ mv =.c =.c++ # bad example, in poor taste :-) I wrote the code and docs and packaged them up into a shar file and announced on comp.sources decades ago. My example was delibrately choosen to be something simple. Complexity was not the point, completeness was. Very, very few people passed this test. I hired people who didn't but I liked working with the people who did, better. There is something satisfying about working with someone who understands what "it's done" actually means. All the engineers interviewed every engineering candidate so other folks may have had other questions. I remember there being widespread agreement on the sweep the floors thing and the supermarket thing. I believe both of those came from Bill Moore (ZFS guy), he had gotten them from other startups. --lm From coff at tuhs.org Thu May 28 09:48:31 2026 From: coff at tuhs.org (G. Branden Robinson via COFF) Date: Wed, 27 May 2026 18:48:31 -0500 Subject: [COFF] good job interview questions In-Reply-To: <20260527212805.GB29244@mcvoy.com> References: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> <20260527212805.GB29244@mcvoy.com> Message-ID: <20260527234831.ubsp32bcvy3m2a5z@illithid> At 2026-05-27T14:28:05-0700, Larry McVoy via COFF wrote: > On Wed, May 27, 2026 at 12:56:52PM -0700, Adam Thornton wrote: > > On Wed, May 27, 2026 at 11:01???AM Larry McVoy via TUHS > > wrote: > > > > > I took a different approach, we hired excellent programmers > > > and our stuff worked. > > > > > This is probably a COFF question, but I'm interested in your process > > for hiring excellent programmers. CCing to COFF and I suggest we > > continue it there. > > Strangely enough, a lot of the same stuff your current boss wrote up. > The technical part is pretty easy, the core of my team were all top 1% > programmers. Those people tend to recognize that talent up front. > > We had two compatibility tests and one question (that well over 90% of > programmers fail). Good interview questions! Here's how I'd fail: > If we needed you to sweep the floors, would you? If the floor needed sweeping--for instance if there were shards of broken glass right in the middle of a common pathway; contrast behind a rack in the server room--certainly and immediately, because that's an overt safety hazard. My colleagues or guests could get hurt if they put a foot wrong. But that's _my assessment_ of what makes a floor need sweeping in an engineering/research lab, and let's be frank: _my assessment_ is likely not of interest to my interviewer. Let's craft some more revealing variants on that question: Will you disengage from the responsibilities of your position to engage in others for which you were not, by implicit or explicit contract, hired, at an instant and without obvious or stated justification? When a member of the leadership team appears at your desk to direct you to undertake routine sweeping, do you have the sense not to ask that leader why he's not doing it himself, given that he appears to be the one with free time? In practice--I say this because I've seen it happen personally--the reason for drafting engineers into service as ad hoc custodians, like dragooned privates in the U.S. Army, is because (a) the building staff inadequately performs this function, which might be contractually the responsibility of the management of the building from which your firm's office space is leased; or (b) your firm is facing a serious cash crunch and is desperately trying to reduce operating expenses, but the owners have better things to do than to secretly sweep the floors themselves on nights and weekends. Being a "thought leader" relieves one of such labor even in extremis. Putting some "extra" spit and polish on the premises is commonly done when ownership is shopping the company on the street, an expects an on-site visit from a suitor. To the right kind of buyer, the re-tasking of engineers from production to custodial services moreover sends a highly positive signal about the abject pliability of the labor force one is acquiring. One doesn't need to waste money on buyout packages for them after the M&A deal is done; you can put them on street immediately without severance, wagering--probably correctly--that they are too cowed to bring a lawsuit. So, if it were me, I'd probably look at the boss for a moment to see if he--yes, he, as a woman manager has never pulled this stunt on me--was attempting a joke or to wind me up, and if they weren't, go do it, and then start planning my exit in short order. If I have the backstop, I'd announce my resignation the next day. The manager has served as a valuable information channel--the company I worked for is not what I thought it was, and/or will be winding up operations on the basis I signed up to work quite soon, by getting acquired or halting altogether. > We asked ourselves if the recruit passed the super market test. If > you saw them at Safeway do you want to go talk to them or do you want > to hide in another isle? That's a good question, too, about work/life balance. When I see a colleague at the grocery store, especially by themselves, I infer that they are seeing to life's basic needs--for themselves or for family or friends. (Maybe they're a caregiver. Maybe a friends of theirs has just lost their home.) Do I want to buttonhole them to talk shop, to assign (or let them infer from my "hints") tasking while they're not even "on the clock"? Or do I want to BS with them about NASCAR or UFC in their meager little "free" time--which they're already spending on the "custodial" labors of own life outside the office? My approach is to smile, say hello, and keep pushing the basket. > Very, very few people passed this test. I hired people who didn't but > I liked working with the people who did, better. There is something > satisfying about working with someone who understands what "it's done" > actually means. For a greenfield project, above the small scale, "it's done" can be a challenging question to answer. Ever done consulting work? Personally, for compensated efforts, I prefer a written SOW to a roomful of people who sit back in their seats, nod at each other a lot, and contrive a sense of fraternity over their shared coolness and superiority to the jerks and losers lurking in the aisles at Safeway. That camaraderie can prove surprisingly shallow when it's time to pay the invoice. By now I've sat on the hiring side of the interviewing table more often than the candidate side. The reason I think these are good interview questions despite my critiques of them is that they provide priceless insight _to the candidate_ about the culture of the workplace they're petitioning to enter. In our PR-saturated field, few firms are gifted with a CEO happy to stand on stage brandishing a chainsaw. Self-satisfaction and self-glorification don't ship code. Workers do. 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 Thu May 28 10:44:20 2026 From: coff at tuhs.org (Adam Thornton via COFF) Date: Wed, 27 May 2026 17:44:20 -0700 Subject: [COFF] [SPAM] Re: [TUHS] Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available? In-Reply-To: <20260527212805.GB29244@mcvoy.com> References: <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org> <20260526014541.GA28587@mcvoy.com> <20260526140148.GC16425@mcvoy.com> <20260527180105.GA29244@mcvoy.com> <20260527212805.GB29244@mcvoy.com> Message-ID: "Sweep the floors" is an interesting one (I think you've mentioned it here before). I mean, yeah, sure, if it needs doing, it needs doing, even if it's not in my job description. Hand me the broom. But really that opens a whole host of other contingent questions. I've worked at startups where, yeah, we were all expected to clean up the place, and answer the phone, and take the outgoing mail down to the post office, and shovel snow, because it was like four people in a rented shop in a strip mall (or sometimes a townhouse that was definitely not zoned for business, but hey, whatever) and there was no provided-with-the-rent facilities maintenance. A little skunkworks place like that, yeah, that's not even a strange request (although I would find it weird and off-putting if I were the *only* person asked to do various jobs that larger offices tend to have staff for). But if it's a Fortune 500 company operating out of a standard professional office park somewhere, it *would* be bizarre if it were a habitual request (stuff can always go wrong: the janitor called in sick one day, or whatever, sure, gimme the broom; I'm talking about, I'm often being asked to sweep up). Why does someplace like that not have someone assigned to the site whose job it is to make sure there's toilet paper in the bathrooms and to keep the floor clean? I'd probably take that as an alarming sign if I was interviewing. (In retrospect, I should have been more wary about an IT job I took--in the healthcare industry!--where the toilets were just about the filthiest I've ever seen in a developed nation. That should have been a red flag the day I interviewed.) Likewise, if it's somehow become my job to be the facilities maintenance guy, it feels like there's a management problem, in that if I'm cleaning up the place, I'm probably not developing software at the same time[*] and in general you don't have to pay janitors as much as you do software engineers, so every minute I'm scrubbing a toilet is a minute you're paying me way too much to do that and paying me, at least as importantly, *not* to solve your software engineering problems. Adam [*] Actually I'm not certain about that. It often is the case that if I'm stuck, it helps if I get up and walk around and do something that isn't programming (sometimes, in fact, just pacing the building halls) in order to let my back-brain chew on a problem, and then when I get back to my desk, I have some ideas I didn't when I got up, so it's plausible that taking a sweeping break would do something similar for me. On Wed, May 27, 2026 at 2:28 PM Larry McVoy via COFF wrote: > On Wed, May 27, 2026 at 12:56:52PM -0700, Adam Thornton wrote: > > On Wed, May 27, 2026 at 11:01???AM Larry McVoy via TUHS > wrote: > > > > > I took a different approach, we hired excellent programmers > > > and our stuff worked. > > > > > > > > This is probably a COFF question, but I'm interested in your process for > > hiring excellent programmers. CCing to COFF and I suggest we continue it > > there. > > Strangely enough, a lot of the same stuff your current boss wrote up. > The technical part is pretty easy, the core of my team were all top 1% > programmers. Those people tend to recognize that talent up front. > > We had two compatibility tests and one question (that well over 90% of > programmers fail). > > If we needed you to sweep the floors, would you? > > We asked ourselves if the recruit passed the super market test. If you > saw them at Safeway do you want to go talk to them or do you want to > hide in another isle? > > The technical (sort of) question was from me and it had a lot to do with > the fact that we were a small team and I wasn't interested in managing a > large team: Tell me about something that you built, at least 10 other > people have used it without contacting you other than to thank you. By > "built" I mean you identified the problem, came up with a solution, > packaged it up, announced it on comp.sources.whatever (or hackernews > for you youngsters). You did the README, the man pages, any web support > needed. You wrote test cases. You did *everything*. No support staff. > > I had an example that I did as a student, I wanted to have regexp version > of mv/cp. I called them move.c and copy.c and did a shell function like > so: > > function mv { > case "$1" in > *=*) move $*;; > *) /bin/mv $* > esac > } > > and then you could do > > $ mv =.c =.c++ # bad example, in poor taste :-) > > I wrote the code and docs and packaged them up into a shar file and > announced on comp.sources decades ago. > > My example was delibrately choosen to be something simple. Complexity was > not the point, completeness was. > > Very, very few people passed this test. I hired people who didn't but > I liked working with the people who did, better. There is something > satisfying about working with someone who understands what "it's done" > actually means. > > All the engineers interviewed every engineering candidate so other > folks may have had other questions. I remember there being widespread > agreement on the sweep the floors thing and the supermarket thing. > I believe both of those came from Bill Moore (ZFS guy), he had gotten > them from other startups. > > --lm > From coff at tuhs.org Sun May 31 09:46:45 2026 From: coff at tuhs.org (steve jenkin via COFF) Date: Sun, 31 May 2026 09:46:45 +1000 Subject: [COFF] Background on Bell Labs and impact on patents produced after 1956 consent decress Message-ID: I'd never understood how important the Patent group was at Bell Labs. Or how busy... [ ~500 patents a year ] The CRC / Unix group were very astute in pitching them a typesetting system. Some things I didn't know: - all pre-1956 patents, including for transistors, became royalty-free after the consent decree - Shockley wasn't the only key transistor research to leave Bell Labs, Teal left for (then small) Texas Instruments. Whilst this is an economics paper looking at a non technical issues, the summaries provided neatly encapsulate the Research Machine that was Bell Labs. ================================= pg 8 Figure B4. : Number and Share of Telecommunications Patents chart shows ~1,000 telecomms patents issued by Bell Labs 1955-1970 ================================= How Antitrust Enforcement Can Spur Innovation: Bell Labs and the 1956 Consent Decree https://www.aeaweb.org/articles?id=10.1257/pol.20190086 Watzinger, Fackler, Nagler, Schnitzer Abstract Is compulsory licensing an effective antitrust remedy to increase innovation? To answer this question, we analyze the 1956 consent decree that settled an antitrust lawsuit against Bell, a vertically integrated monopolist charged with foreclosing the telecommunications equipment market. Bell was forced to license all its existing patents royalty-free, including those not related to telecommunications. We identify the effect of the consent decree on follow-on innovations building on Bell patents by using exactly matched non-Bell patents as control group. We show that the consent decree led to a lasting increase in innovation but only in markets outside the telecommunications sector. ----------------- How Antitrust Enforcement Can Spur Innovation: Bell Labs and the 1956 Consent Decree Online Appendices https://assets.aeaweb.org/asset-server/files/13359.pdf Appendix A1. The History of the Bell System and the Antitrust Lawsuit As described in Section I, the Bell System was the dominant provider of telecommunications services in the United States. In terms of assets, AT&T was by far the largest private corporation in the world in 1956. AT&T, together with all companies in the Bell system, employed 746,000 people [ 1.16% adult workforce ] with a total revenue of $5.3 billion or 1.9% of the U.S. GDP at the time. [ US pop. 1956, 111M, adult workforce, 64M ] [ ] It was also one of the most innovative companies in the world: Between 1940 and 1970, Bell filed on average ~503 patents or 1% of all U.S. patents each year. The 1950 staff of Bell Labs alone consisted of four future Nobel Laureates in physics, one Turing Award winner, five future U.S. National Medals of Science recipients, and ten future IEEE Medals of Honor recipients. In 1950, Bell Labs employed 6,000 people, one-third of whom were professional scientists and engineers. This was 1% of the entire science and engineering workforce in the U.S. at the time. After the complaint was filed in January 1949, Bell sought and obtained a freeze of the antitrust lawsuit in early 1952 with the support of the Department of Defense (DoD), on the grounds that the DoD relied on the research of Bell Labs for the war effort in Korea. In World War II, the Bell Labs had been instrumental in inventing the superior radar systems of the Allies. They also engaged in around a thousand different war-related projects, from tank radio communications to enciphering machines for scrambling secret messages. In Figure A1, we show two examples of Bell's war-related technologies: radar and cryptography In these two technologies, Bell filed a total of 251 patents. In the following years, Bell Labs continued to work for the DoD, for example by operating the Sandia National Laboratories, one of the main development facilities for nuclear weapons. ---- In May 1954, AT&T presented and in June 1954 submitted to the Department of Justice a checklist of concessions that would be an acceptable basis for a consent decree. The only major remedy suggested was the compulsory licensing of all Bell patents for reasonable royalties. The case ended with a consent decree on January 24, 1956, containing two remedies. First, the Bell System had to license all its patents issued prior to the decree royalty-free to any applicant, with the exception of RCA, General Electric, and Westinghouse, who already had cross licensing agreements with Bell (the so-called B-2 agreements). All subsequently published patents had to be licensed for reasonable royalties. As a consequence of the consent decree, 7,820 patents in 266 USPC technology classes and 35 technology subcategories or 1.3% of all unexpired U.S. patents became freely available. Second, the Bell System was barred from engaging in any business other than telecommunications. ---- Historical accounts also report that there was an exodus of important Bell researchers from Bell Labs around the time of the consent decree. In 1953, for example, Gordon Teal, the inventor of a method to improve transistor performance, joined the then small Texas Instruments Inc. Similarly, William Shockley, one of the inventors of the transistor, left Bell in 1956 to start Shockley Semiconductors Laboratory. So, secular changes at the Bell Laboratories unrelated to the consent decree might have led to more spin-offs and, consequently, to more follow-on innovation by small and young companies. In our data, there are 5,613 former Bell employees with 35,589 patents, 4,477 co-inventors of former Bell employees with 28,569 patents, and 12,068 co-inventors of co-inventors who were never active at Bell and who filed 87,148 patents in total. This pattern suggests that the increase in follow-on innovation was even negative for former Bell employees. We define a high-quality patent as a patent with a value of more than $3.07 million, the median dollar value of a Bell patent according to Kogan et al. (2017). For example, shortly after the Bell consent decree there were two other consent decrees issued that used compulsory licensing as a remedy: IBM in 1956 and of RCA in 1958. One potential concern might be that our estimates do not capture an increase in follow-on innovation, but merely reflect a substitution effect. Due to the free availability of Bell technology, companies might have substituted away from other, potentially more expensive technologies. We find no effect, implying that the citation substitution is either small or homogeneous to patents of these companies and the control group. ================================= -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin