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: <CAC20D2M49mGfaxsRuuuS-YBGF7397w4OAx+Pfe7DZVsGyrHL+Q@mail.gmail.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <CAC20D2M49mGfaxsRuuuS-YBGF7397w4OAx+Pfe7DZVsGyrHL+Q@mail.gmail.com>
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 <tuhs at tuhs.org>
> 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>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
 <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.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: <gBSN.1779038879013219171.rW3N@groups.io>
References: <gBSN.1779038879013219171.rW3N@groups.io>
Message-ID: <CAEoi9W7rpLzdJzYJ3-F0KVJo-wQXa7UawUYtUoUUYy36m5e_3Q@mail.gmail.com>

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 <thvv=multicians.org at groups.io>
Date: Sun, May 17, 2026, 1:27 PM
Subject: [multicians] Peter Neumann has died
To: <multicians at groups.io>


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) <https://groups.io/g/multicians/message/5960> | Reply
to Group
<multicians at groups.io?subject=Re:%20%5Bmulticians%5D%20Peter%20Neumann%20has%20died>
| Reply to Sender
<thvv at multicians.org?subject=Private:%20Re:%20%5Bmulticians%5D%20Peter%20Neumann%20has%20died>
| Mute This Topic <https://groups.io/mt/119360690/481017> | New Topic
<https://groups.io/g/multicians/post>
------------------------------
-- sent via multicians at groups.io -- more Multics info at
https://multicians.org/
------------------------------
Your Subscription <https://groups.io/g/multicians/editsub/481017> | Contact
Group Owner <multicians+owner at groups.io> | Unsubscribe
<https://groups.io/g/multicians/leave/5961246/481017/1924879241/xyzzy> [
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: <CAEoi9W7wcGNneMjZihO=ePM0od8MtUHyTDCH_ChqB1SNCsM7Ew@mail.gmail.com>

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: <C10F9C84-D9D4-4772-822D-3EFBC561BBBE@seiden.com>
References: <CAEoi9W7wcGNneMjZihO=ePM0od8MtUHyTDCH_ChqB1SNCsM7Ew@mail.gmail.com>
 <CAK7dMtBBhNq+-hreveG++qEvbTLHSUTuevkzhapULbTXXvqxQg@mail.gmail.com>
 <019F9537-2333-45C8-8ADB-34F06FB3F1F9@seiden.com>
 <C10F9C84-D9D4-4772-822D-3EFBC561BBBE@seiden.com>
Message-ID: <FA2AB9D3-2ABC-40C5-9EA0-60B996869E3A@technologists.com>

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 <tuhs at tuhs.org> 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 <mis at seiden.com> 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 <tuhs at tuhs.org> wrote:
>>> 
>>> RIP.  Did he ever interact with this community?
>>> 
>>> On Mon, May 18, 2026 at 5:20 PM Dan Cross via TUHS <tuhs at tuhs.org> 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: <CAEoi9W7wcGNneMjZihO=ePM0od8MtUHyTDCH_ChqB1SNCsM7Ew@mail.gmail.com>
References: <CAEoi9W7wcGNneMjZihO=ePM0od8MtUHyTDCH_ChqB1SNCsM7Ew@mail.gmail.com>
Message-ID: <202605192304.64JN4Gnv070349@freefriends.org>

Dan Cross via TUHS <tuhs at tuhs.org> 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: <gBSN.1779038879013219171.rW3N@groups.io>
 <CAEoi9W7rpLzdJzYJ3-F0KVJo-wQXa7UawUYtUoUUYy36m5e_3Q@mail.gmail.com>
 <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: <ag5n1txPpVk0aQ3C@minnie.tuhs.org>

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: <NjQjeHpUvOLB0ywrHslMoccqu5XwZdVbcheG8lzKnKRK23aNptkCQVcQR7jX5bdX_ynt0ZEnoSVLISe4kaocTbkmAAGBbG_nbLvo83_n2_4=@protonmail.com>

On Wednesday, May 20th, 2026 at 20:04, Alexis via COFF <coff at tuhs.org> 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: <ag5n1txPpVk0aQ3C@minnie.tuhs.org>
References: <ag5n1txPpVk0aQ3C@minnie.tuhs.org>
Message-ID: <CAD-qYGrrmMyRD6j21ZYuiaDLTY2doQ-E=kwcE2YKSFMtnhG1tg@mail.gmail.com>

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: <CAD-qYGrrmMyRD6j21ZYuiaDLTY2doQ-E=kwcE2YKSFMtnhG1tg@mail.gmail.com>
 (Andrew Warkentin via COFF's message of "Wed, 20 May 2026 23:31:56
 -0600")
References: <ag5n1txPpVk0aQ3C@minnie.tuhs.org>
 <CAD-qYGrrmMyRD6j21ZYuiaDLTY2doQ-E=kwcE2YKSFMtnhG1tg@mail.gmail.com>
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: <ag5n1txPpVk0aQ3C@minnie.tuhs.org>
 <CAD-qYGrrmMyRD6j21ZYuiaDLTY2doQ-E=kwcE2YKSFMtnhG1tg@mail.gmail.com>
 <7wpl2pe1qe.fsf@junk.nocrew.org>
Message-ID: <CACyhTRE7fTJNYdmg8qu0vinWspnhxp--6y61XVBihUgNjF-CSQ@mail.gmail.com>

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 <coff at tuhs.org>
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: <CAEoi9W5-FuoG8yNhzxwktLhq4TRv=SoXLYXwUL6iOfab3phrVA@mail.gmail.com>

On Wed, May 20, 2026 at 11:04 PM Alexis via COFF <coff at tuhs.org> 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: <A4873851-F73D-4FED-BE9C-401D7DC678C1@iitbombay.org>
References: <d75e3b8e65c69b21@orthanc.ca>
 <20260522230739.DC2ADBFA9C@hal.inputplus.co.uk>
 <20260523014251.GC14835@mcvoy.com> <20260523141225.GC18663@macsyma-wired.lan>
 <CANCZdfoc=Au6t2B9cbLBrZHrCqXLZDgCW_9UTEO56oXv2duQdA@mail.gmail.com>
 <A4873851-F73D-4FED-BE9C-401D7DC678C1@iitbombay.org>
Message-ID: <20260523162419.yY6zi8rp@steffen%sdaoden.eu>

Bakul Shah via TUHS wrote in
 <A4873851-F73D-4FED-BE9C-401D7DC678C1 at iitbombay.org>:
 |On May 23, 2026, at 7:49 AM, Warner Losh via TUHS <tuhs at tuhs.org> 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: <ahaPblqFARcHWDIT@straylight.m.ringlet.net>

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: <http://www.tuhs.org/pipermail/coff/attachments/20260527/30467e9a/attachment.sig>

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: <ahbuVwBveOxYXB63@straylight.m.ringlet.net>

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: <http://www.tuhs.org/pipermail/coff/attachments/20260527/967fb882/attachment.sig>

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: <ahbuVwBveOxYXB63@straylight.m.ringlet.net>
References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu>
 <ahbuVwBveOxYXB63@straylight.m.ringlet.net>
Message-ID: <ahbuqe9S1USBt39_@straylight.m.ringlet.net>

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: <http://www.tuhs.org/pipermail/coff/attachments/20260527/747e8ee0/attachment.sig>

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: <CAEoi9W48C6vFo1oR2SQ2hy+Vy_vPSAfQpDvy9qCNbEr079vdZg@mail.gmail.com>

On Wed, May 27, 2026 at 6:49 AM Noel Chiappa via COFF <coff at tuhs.org> 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
`<stdint.h>`, 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 `<inttypes.h>`, 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: <CAEoi9W48C6vFo1oR2SQ2hy+Vy_vPSAfQpDvy9qCNbEr079vdZg@mail.gmail.com>
References: <20260527104942.95ED518C07A@mercury.lcs.mit.edu>
 <CAEoi9W48C6vFo1oR2SQ2hy+Vy_vPSAfQpDvy9qCNbEr079vdZg@mail.gmail.com>
Message-ID: <CABH=_VQFf6bWxEmZz_krPbanqDVkAMBsgbaTfL50-E32oQ4B5Q@mail.gmail.com>

On Wed, May 27, 2026 at 10:17 AM Dan Cross via COFF <coff at tuhs.org> 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>
 <m1wRIyd-00Mo5fC@more.local>
 <CAP2nic2NadrGFcmw7FOJea3P4uXmijSxUBMOS7WoNP0uChfrvg@mail.gmail.com>
 <CAC20D2MPo3BPP-thoe5-SOHo1=ey8WtpKQUYdaQ+B+o_mSMrBg@mail.gmail.com>
 <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org>
 <20260526014541.GA28587@mcvoy.com>
 <CAO8UeJfszWrXcnVDB-hwjHvsJ_JMHTN67-7stuzVavnQtEjtQA@mail.gmail.com>
 <20260526140148.GC16425@mcvoy.com>
 <CAEoi9W7YBOmtunX_vFxqnDMXFbLxF5nGCWNx73AyMNih3d3ecA@mail.gmail.com>
 <20260527180105.GA29244@mcvoy.com>
Message-ID: <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.com>

On Wed, May 27, 2026 at 11:01 AM Larry McVoy via TUHS <tuhs at tuhs.org> 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: <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.com>
References: <5B66CECF-5667-49E6-9458-898E6C0D60D1@canb.auug.org.au>
 <m1wRIyd-00Mo5fC@more.local>
 <CAP2nic2NadrGFcmw7FOJea3P4uXmijSxUBMOS7WoNP0uChfrvg@mail.gmail.com>
 <CAC20D2MPo3BPP-thoe5-SOHo1=ey8WtpKQUYdaQ+B+o_mSMrBg@mail.gmail.com>
 <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org>
 <20260526014541.GA28587@mcvoy.com>
 <CAO8UeJfszWrXcnVDB-hwjHvsJ_JMHTN67-7stuzVavnQtEjtQA@mail.gmail.com>
 <20260526140148.GC16425@mcvoy.com>
 <CAEoi9W7YBOmtunX_vFxqnDMXFbLxF5nGCWNx73AyMNih3d3ecA@mail.gmail.com>
 <20260527180105.GA29244@mcvoy.com>
 <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.com>
Message-ID: <b0442558-6bca-4b45-8977-06d0eb42f073@app.fastmail.com>

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: <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.com>
References: <m1wRIyd-00Mo5fC@more.local>
 <CAP2nic2NadrGFcmw7FOJea3P4uXmijSxUBMOS7WoNP0uChfrvg@mail.gmail.com>
 <CAC20D2MPo3BPP-thoe5-SOHo1=ey8WtpKQUYdaQ+B+o_mSMrBg@mail.gmail.com>
 <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org>
 <20260526014541.GA28587@mcvoy.com>
 <CAO8UeJfszWrXcnVDB-hwjHvsJ_JMHTN67-7stuzVavnQtEjtQA@mail.gmail.com>
 <20260526140148.GC16425@mcvoy.com>
 <CAEoi9W7YBOmtunX_vFxqnDMXFbLxF5nGCWNx73AyMNih3d3ecA@mail.gmail.com>
 <20260527180105.GA29244@mcvoy.com>
 <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.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 <tuhs at tuhs.org> 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: <CAP2nic2NadrGFcmw7FOJea3P4uXmijSxUBMOS7WoNP0uChfrvg@mail.gmail.com>
 <CAC20D2MPo3BPP-thoe5-SOHo1=ey8WtpKQUYdaQ+B+o_mSMrBg@mail.gmail.com>
 <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org>
 <20260526014541.GA28587@mcvoy.com>
 <CAO8UeJfszWrXcnVDB-hwjHvsJ_JMHTN67-7stuzVavnQtEjtQA@mail.gmail.com>
 <20260526140148.GC16425@mcvoy.com>
 <CAEoi9W7YBOmtunX_vFxqnDMXFbLxF5nGCWNx73AyMNih3d3ecA@mail.gmail.com>
 <20260527180105.GA29244@mcvoy.com>
 <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.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
> > <tuhs at tuhs.org> 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: <http://www.tuhs.org/pipermail/coff/attachments/20260527/13b4f937/attachment.sig>

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: <m1wRIyd-00Mo5fC@more.local>
 <CAP2nic2NadrGFcmw7FOJea3P4uXmijSxUBMOS7WoNP0uChfrvg@mail.gmail.com>
 <CAC20D2MPo3BPP-thoe5-SOHo1=ey8WtpKQUYdaQ+B+o_mSMrBg@mail.gmail.com>
 <798A2248-0389-40B6-8A36-7B735634DE96@iitbombay.org>
 <20260526014541.GA28587@mcvoy.com>
 <CAO8UeJfszWrXcnVDB-hwjHvsJ_JMHTN67-7stuzVavnQtEjtQA@mail.gmail.com>
 <20260526140148.GC16425@mcvoy.com>
 <CAEoi9W7YBOmtunX_vFxqnDMXFbLxF5nGCWNx73AyMNih3d3ecA@mail.gmail.com>
 <20260527180105.GA29244@mcvoy.com>
 <CAP2nic3Rt2Vvb3_GtDx-CvGe41X5N_SfTwKM61EG8zafnBLZDQ@mail.gmail.com>
 <20260527212805.GB29244@mcvoy.com>
Message-ID: <CAP2nic3rK_a9HBron9AYuwsfySC-K9dhq66kkm=hXLQvEHmT=w@mail.gmail.com>

"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 <coff at tuhs.org> 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 <tuhs at tuhs.org>
> 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
>

