From tuhs at tuhs.org Sat Aug 1 00:48:58 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 31 Jul 2026 09:48:58 -0500 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: References: Message-ID: Omg. Ha. I never connected that. Of course that’s what it is :). Still, it is also where he really begins talking about how stuff works. The first five chapters are more background and orientation. Will Sent from my iPhone > On Jul 30, 2026, at 11:55 PM, Otto Moerbeek wrote: > >  > "Getting Started" talks about the machine, not about the reader :) > > -Otto > >> On Thu, Jul 30, 2026 at 07:56:10AM -0500, Will Senn via TUHS wrote: >> >> Clem, >> >> Wow. This makes so much sense. I "randomly" picked page 28 as a starting >> point, never mind that the section was called "Getting Started". That was >> possibly the worst/best place to begin, because it is where the PDP11 -> >> unix transition takes place. When Lions talks about it, it's clear that he's >> speaking from the unix side of things with enough PDP to orient a denizen of >> the times, but not a techie from the future who is ot familiar with stuff >> like core, I/O regions of memory, or severe hardware limitations. Having >> struggled to parse every sentence along the way, I've made the journey from >> the processor handbook - where I found a typo in the 11/40 version... it >> says: >> >> Certain memory locations have been reserved by the system for inter· >> rupt and trap handling, processor stacks, general registers, and >> peripheral >> device registers. K.ernel virtual addresses from 0 to 370, are always >> re- >> served and those to 777, are reserved on large system configurations for >> traps and interrupt handling. The top 4,096 word addresses (from >> 770000, up) have been reserved for general registers and peripheral >> devices. >> >> But, after a couple of hours of head scratching it dawned on me that >> 770000-777777 was only 2K words and couldn't possibly be right, 760000 is >> the correct number. Which is click 7600, which is what's loaded into KIPAR7, >> which the m40 assist maps as IO. Which is properly described in the 1976 >> 11/04/34/45/44 version as: >> >> If the Memory Management option is not used, an octal address be- >> tween 160 000 and 177 777 is interpreted as 760 000 to 777 777. That >> is, if bit 15, 14 and 13 are 1 's, then bits 17 and 16 (the extended ad- >> dress bits) are considered to be 1's, which relocates the last 4K words. >> (8K bytes) to become the highest location accessed by the UNIBUS. >> >> Then on into the peripherals book, the memory management options book, and >> the v6 manual. In addition, whereas previously, I ignored the source code, >> now I find it invaluable. Where it says _end is some linker thing (I >> originally read it as a pseudo op, but it's more something the loader adds). >> I just pulled up the source, figured out it adds it to the binary if it's >> referenced in code and that it refers to the boundary of the image (one past >> the last byte) or in the "as" documentation where Dennis say it's a rather >> ordinary 2 pass assembler with no macros. I no longer take this as gospel, >> it's off to the as source where it turns out it's anything but ordinary, not >> really a two pass assembler (two programs, one that builds a very nice >> compact representation and the other that takes two passes) and it trades >> an insane amount of language affordance for macros... heck it'll even let >> you define your own assembly instructions :). >> >> It's the little things :). >> >> Will >> >>> On 7/28/26 9:07 PM, Clem Cole via TUHS wrote: >>> Will/Matt, >>> >>> You both make interesting observations, and I tried to go back a little and >>> remember what resources I had when I encountered Lions (and made my >>> xerographic copy). At the time (which I think was late 1977 or early 78), >>> I had my own copy of the 1974/75 PDP-11 04/34/45/55 Processor Handbook [ >>> https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_04-55_Processor_Handbook_1976.pdf] >>> and the 1976 PDP-11 Peripherals Handbook† [ >>> https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_PeripheralsHbk_1976.pdf] >>> Note I had the 34 docs, not the 40 docs. I also had access to the docs >>> from Sixth Edition, such as the C Reference manual. >>> >>> Also remember that I was not using it as a course text, which is why he >>> wrote it. When I discovered it, the book was just a wonderful resource >>> that helped explain in more detail a lot of things I already had an inkling >>> of, and as I look back, probably corrected some misunderstandings too. >>> >>> That said, before I read Lions, I had already been programming UNIX for a >>> year or two on the 11/40E (IUS and SUS) in the CS Dept. We had converted >>> from Fifth Edition to Sixth (I personally had very brief experiences with >>> Fifth - it was in my "what is this strange system and language phase," >>> introduction to UNIX having come over from BLISS and both a DEC and IBM >>> flavor of how OS's were supposed to present themselves). But in the summer >>> before I saw Lions, we had received our first 11/34 in the EE Dept. We >>> couldn't just use Dennis's distribution tape, since a 34 is a 40-class >>> processor (which are similar but different enough; it's not going to "just >>> work" — *i.e*., not something the stock Sixth Edition knew about). So, we >>> bootstrapped the EE 34 from IUS, which was tricky because we had to add 34 >>> support to mch40.s, more importantly, the 34 didn't have the CSV/CRET in >>> the writable microcode of the 11/40Es that the C compiler on the CS systems >>> expected (I have memories of walking back and forth between the two >>> buildings creating yet another RK05 boot image when we found some other >>> important program that was expecting CSV/CRET but weren't far/stable enough >>> along in the bootstrap to correct it ourselves). >>> >>> FWIW: I had had some exposure to RT-11 on an 11/05 [running from DEC >>> cassette tapes], as well as programming the PDP-8 running TSS/8 and the 10s >>> under TOPS, as well as working for the Computer Center supporting York/APL >>> on the IBM 360/67. But I think most importantly for my UNIX kernel >>> experience, I had started to work on the Computer Center's version of the >>> CMU Front End, trying to add support for the 11/45 they had running RSTS >>> for the School of Humanities and Social Science. As I have mentioned in >>> other emails, the CMU FE was a standalone system (no OS) with a ton of >>> serial ports, a card reader and printer, and some sort of interface to >>> larger systems (in the CC's case, the 360 for interactive serial ports and >>> as an RJE station for the 360 and Univac 1008, and we were adding the then >>> new RSTS system). At that point, it was based on an 11/15 (no MMU, of >>> course, and the code was primarily in BLISS-11 with a very small assembler >>> assist). The key is I was already inoculated with the core PDP-11 ISA and >>> differences between models, so much of what you are commenting about with >>> PDP-11-ism, such as the RESET instruction or the PARS, was already >>> something I had learned before. To me, Lions was explaining how Ken uses >>> them in the kernel. >>> >>> My point is I didn't walk into reading Lions without some core experience >>> with the PDP-11 family. Some of the peripherals, like the KL/DLs and >>> clock, I was certainly extremely familiar with, and I already understood >>> about MMUs (the 67 running TSS was IBM's first VM system). Across so many >>> different CMU systems, we had aftermarket disks on most of them [the DEC >>> RP03/04 were made by Univac, but they were actually clones of the IBM >>> 2314/2316 (only slightly different)]. IIRC we had CDC flavors of them >>> which they called the 84x series, and IIRC we had to modify the rp.c driver >>> slightly to make them work properly. So I had already learned how to hack >>> the disk drivers by then. But I never had access to real manuals for >>> any of the DEC peripherals other than the 76 Peripherals Handbook until we >>> got one of the first RK07s and the RK611/711 controller. Danny Klein and >>> I wrote the first UNIX driver for it, cribbing from the already hacked >>> RP04/5/6 driver and reading Dennis' V6 driver manual. I had already been >>> doing a small amount of the kernel mods by then, and we had started to >>> write fsck(8) as well. But when I saw it (and made my own copy), I thought >>> Lions helped me better understand the system than I had before. It >>> certainly gave me more confidence about what subsystems I would attack >>> (more in a minute). >>> >>> At some point, but it had to have been after I saw Lions, Ted Kowalski had >>> a xerographic copy of the proofs for K&R1 in a binder (which I copied), and >>> by late 78 I had obtained a xerographic copy of the "Unix program >>> description" doc that Matt referred to (I think I got that from Phil Karn, >>> but it might have been Ted). >>> >>> FWIW: A few years later, my old friend and then colleague at Tektronix, >>> Mike Zuhl, made an interesting observation, which I think actually plays >>> into your comments about Lions. Zuhl was one of the Purdue EE UNIX folks >>> (like the late George Goble and Ward Cunningham). Zuhl said: *"Hacking on >>> the Unix kernel is a lot like riding a motorcycle. At first you are scared >>> sh*tless that you don't want to screw up. After a while, you get >>> confident in your abilities and are willing to try anything. Finally, you >>> realize it is really just an incredibly beautiful hack that works in a >>> manner like no other, and you start to respect it and those that came >>> before you*." >>> >>> For me, reading Lions was part of my transition in the third phase. He >>> explains things I basically knew before at a more macro level. >>> >>> My thoughts/recollections if it is of any help, >>> Clem >>> >>> † To this day, I still think the 1976 Peripherals Handbook was the best >>> one DEC made, and if you are looking at Sixth or Seventh Editions, it is >>> really all you need for most of the peripherals they supported. Later >>> ones include some information about later products such as the RL01/2 and >>> RK06/7, but they dropped many of them outright in some cases, and in others >>> the core descriptions are not nearly as detailed/useful. >>> >>>> On Tue, Jul 28, 2026 at 2:41 PM segaloco via TUHS wrote: >>> >>>> On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS >>>> wrote: >>>> >>>>> Lions is great, but today's reader needs more of a leg up. I think it >>>>> illustrates how much architectural knowledge his original audience could >>>>> take for granted. Nearly fifty years later, recovering that context has >>>>> become part of reading the book. So, reading through Lions in 2026 is an >>>>> archaeological dig, really :). That said, if you're planning to read >>>>> Lions with any depth, be sure to minimally have on hand: >>>>> >>>>> * Lions Commentary >>>>> >>>>> * Lions Source Code >>>>> >>>>> * PDP-11/40 Processor Handbook >>>>> >>>>> * KT11-D Memory Management Option User Manual >>>>> >>>>> * Repeatable notes for setting up a working lab >>>>> >>>>> Later, >>>>> >>>>> Will >>>>> >>>> For the record, the intro does indicate what auxiliary knowledge may be >>>> necessary, pointing the reader to the manual, several papers such as C >>>> tutorials and UNIX for Beginners, as well as listing knowledge of the >>>> following PDP-11 hardware useful: >>>> >>>> - PDP11/40 >>>> - RK05 >>>> - LP11 >>>> - PC11 >>>> - KL11 >>>> >>>> You also do get a bit of hardware exposition, albeit not too much, in >>>> Chapter 2. >>>> >>>> This implies having the PDP-11 Peripherals Handbook on hand would also be >>>> helpful. Naturally our biases allow us to overlook this, but having both >>>> the UNIX Assember Manual and C Reference Manual on hand would be helpful to >>>> the uninitiated as those are the two languages at play in the source >>>> volume. Not sure how necessary this would be in practice but UNIX is an >>>> ASCII system, so non-ASCII-ites, however rare these days, would be going in >>>> with some unhelpful biases, but I don't know if that would peg the ASCII >>>> standard as required context. I'm a sucker for building complete reference >>>> documentation graphs...so I'm going to hold my urge further for now. >>>> >>>> Still, it would be an interesting exercise to pursue the full graph of >>>> primary references needed to establish a normative reference graph for >>>> Lions's Commentary. >>>> >>>> Will, I don't know if this would be a comparable follow-on project, but >>>> there is the Program Description document published with USG UNIX that >>>> serves as another detailed analysis of the UNIX kernel[1] that may be worth >>>> inspecting with a similar lens. By the way, I have a later hardcopy of [1] >>>> issued with Program Generic 3. Unfortunately its just a reprint of the >>>> Program Generic 2 version and does not include the kernel changes in PG3, >>>> but it is complete, so I plan on scanning it in my next round of documents. >>>> >>>> - Matt G. >>>> >>>> [1] - unix_program_description_jan_1976.pdf >>>> From tuhs at tuhs.org Sat Aug 1 13:44:55 2026 From: tuhs at tuhs.org (Atindra Chaturvedi via TUHS) Date: Sat, 01 Aug 2026 03:44:55 +0000 Subject: [TUHS] Mt. Xinu Mach Distribution + Coherent distribution Message-ID: I finally got around to looking for resting places for much of the software and hardware I have used and enjoyed over the years. I have a full Mt. Xinu MACH distribution + Networking + X 11 + Online docs + Installation guide + MACH book + USENIX MACH volume and ACM MACH volume. Also a Coherent distribution with updates up to V3.02 + COHware #1 + COHWare #2 for device drivers etc. HERMES language (for distributed systems) book + software from IBM Watson Research Center Camelot and Avalon ( distributed system) book My intent is to ask what would be a good place to send these to. My primary wish is that this gets USED, not filed away in a museum. Please give me some ideas/leads. Atindra. From tuhs at tuhs.org Sat Aug 1 13:58:50 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 31 Jul 2026 23:58:50 -0400 Subject: [TUHS] Mt. Xinu Mach Distribution + Coherent distribution In-Reply-To: References: Message-ID: TUHS would be a good place to start. That is exactly the mission we have to make things assessable in the future. If you send me, Warren, or any of the others who are part of the org structure behind it [aka the not for profit TUHS, inc] offline, we can work with you on how to make all available. We are trying to make this a bit easier. Very recently a request came in for how to donate some other materials and we are trying to set something up that is a little more automatic and once that is in place we plan to announce it on the list as well as provide docs on how to do it ion the website. But in the meantime, we can use the scheme Warren had used for years - send a private email and can help make all happen. Thank you for your offer. Clem Sent from a handheld expect more typos than usual On Fri, Jul 31, 2026 at 11:45 PM Atindra Chaturvedi via TUHS wrote: > I finally got around to looking for resting places for much of the > software and hardware I have used and enjoyed over the years. > > > I have a full Mt. Xinu MACH distribution + Networking + X 11 + Online docs > + Installation guide + MACH book + USENIX MACH volume and ACM MACH volume. > > > Also a Coherent distribution with updates up to V3.02 + COHware #1 + > COHWare #2 for device drivers etc. > > > HERMES language (for distributed systems) book + software from IBM Watson > Research Center > > > Camelot and Avalon ( distributed system) book > > > My intent is to ask what would be a good place to send these to. My > primary wish is that this gets USED, not filed away in a museum. > > > Please give me some ideas/leads. > > > Atindra. > From tuhs at tuhs.org Tue Aug 4 02:25:20 2026 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Mon, 3 Aug 2026 11:25:20 -0500 Subject: [TUHS] =?utf-8?b?SnVuZSA4LCAyMDI2IOKAkyBWaXZpYW4gVm9zcyDigJMg?= =?utf-8?q?Where_Unix_Runs_Today?= In-Reply-To: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> References: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> Message-ID: <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> I discovered https://vivianvoss.net/blog/where-unix-runs-today yesterday and sent the excerpts below to former AIX colleagues and others that might be interested. I forwarded that mail to Clem and Heinz this morning. Clem replied with a detailed commentary. Clem seemed to agree this might be worth posting here to liven things up. Charlie ''Open the laptop in front of you. If it is a Mac, you are on certified Unix. Hand it to the child next to you, watching cartoons on an iPad — also Darwin underneath, the same family. The phone in your pocket: same. Walk through any data centre serving European video, and a sizeable share of those streams come off appliances running FreeBSD. Pick up a games console at the till in any electronics shop, and odds are very good it boots a fork of FreeBSD before it ever shows you a menu. ... ''One footnote worth keeping. Apple is certified on UNIX 03, dating from 2002. Only one product on the planet is certified at the next level — UNIX V7 (Single UNIX Specification version 4, POSIX.1-2008): IBM’s AIX 7. ... ''The world’s commercial Unix systems are not all in retirement homes. ''IBM AIX is actively developed. New versions track new IBM POWER processors; the public roadmap is clear. AIX 7 is the only operating system in the world certified at UNIX V7 (SUSv4) level. Banks, insurance, large enterprise back-office: AIX still carries this work, and IBM still treats it as core strategy.'' -- 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 tuhs at tuhs.org Tue Aug 4 03:00:17 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Mon, 3 Aug 2026 10:00:17 -0700 Subject: [TUHS] =?utf-8?b?SnVuZSA4LCAyMDI2IOKAkyBWaXZpYW4gVm9zcyDigJMg?= =?utf-8?q?Where_Unix_Runs_Today?= In-Reply-To: <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> References: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> Message-ID: On 8/3/2026 9:25 AM, Charles H Sauer (he/him) via TUHS wrote: > I discovered https://vivianvoss.net/blog/where-unix-runs-today yesterday > and sent the excerpts below to former AIX colleagues and others that > might be interested. I forwarded that mail to Clem and Heinz this > morning. Clem replied with a detailed commentary. Clem seemed to agree > this might be worth posting here to liven things up. > > Charlie > > ''One footnote worth keeping. Apple is certified on UNIX 03, dating from > 2002. Only one product on the planet is certified at the next level — > UNIX V7 (Single UNIX Specification version 4, POSIX.1-2008): IBM’s AIX 7. > ... While AIX 7 is the only product certified for V7 today, others have been certified in the past, but stopped renewing their certifications. Oracle Solaris 11.4 was the first product to earn UNIX V7 certification: https://x.com/TheOpenGroup/status/1034785507610447872 https://web.archive.org/web/20200114100431/https://www.opengroup.org/openbrand/register/brand3642.htm The blog also incorrectly states the support level of Solaris - only Solaris 9 and earlier, and Solaris 11.0 through 11.2, are in what Oracle calls Sustaining Support. Solaris 10 & 11.3 are in Extended Support until January 2027, Solaris 11.4 is in Premier Support until November 2037, and continues to get new features in quarterly support updates, as I post on the Solaris blog: https://www.oracle.com/a/ocom/docs/support/advanced-customer-support/solaris-linux-vm-lsp.pdf https://blogs.oracle.com/authors/alan-coopersmith/ As for the blog comments that HP-UX is "genuinely fading", I'm surprised it doesn't note that HP actually has ended support for it: https://support.hpe.com/hpesc/public/docDisplay?docId=a00143419en_us&docLocale=en_US https://www.osnews.com/story/144094/hp-ux-hits-end-of-life-today-and-im-sad/ https://www.theregister.com/software/2026/01/05/the-last-supported-version-of-hp-ux-is-no-more/2347266 -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Tue Aug 4 08:24:57 2026 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Tue, 4 Aug 2026 08:24:57 +1000 Subject: [TUHS] Use of "{}" in the Shell? Message-ID: A long time ago, in a Unix manpage far away, I saw a reference to "{}" which acted similar to "()" except that it did not fork e.g. "{exit}" would do just that :-) Does anyone know the provenance of this Shell? I can't seem to reproduce it on the MacBook or the FreeBSD box here (my Penguin box is currently dead). Thanks. -- Dave From tuhs at tuhs.org Tue Aug 4 08:31:56 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 4 Aug 2026 08:31:56 +1000 Subject: [TUHS] President's Report: August 2026 Message-ID: <10e3a8ce-6d30-48e0-bf1a-653bdb6e3d49@tuhs.org> Back in June I brought the news that we had formed an incorporated organisation, TUHS Inc. , to handle the donations that you sent in and also to create a formal structure to keep TUHS going long into the future. At the time I promised monthly updates on our activities; alas, there hasn't been enough news to report monthly. So here is the next update! We've been struggling to open a bank account for the donations that you sent in April. We would rather not open a "bricks and mortar" bank account as their exchange rates can be high. At the same time, the on-line institutions like Wise and Airwallex have an aversion to business accounts for incorporated organisations that are not charities. Lastly, the Australian Tax Office may want to tax our income as we are not a registered charity. Having discovered of the above, we have chosen to apply with the Australian Charities and Not-for-profits Commission to register TUHS Inc. as a charity. Our application was filed last week and the ACNC has a six- to eight-week turnaround time on applications. So now we wait for their response. If our application is successful, we will be able to get a Wise/Airwallex account and we will also not have to pay any taxes. Fingers crossed! While doing the charity application, I came across this definition of a museum from the International Council of Museums : A museum is a not-for-profit, permanent institution in the service of society that researches, collects, conserves, interprets and exhibits tangible and intangible heritage. Open to the public, accessible and inclusive, museums foster diversity and sustainability. They operate and communicate ethically, professionally and with the participation of communities, offering varied experiences for education, enjoyment, reflection and knowledge sharing. I think that perfectly sums up what TUHS is all about. We collect, conserve and interpret Unix artifacts, we are open to the public and we have an excellent community (the TUHS mailing list) to share our Unix knowledge. On the server side of things, we are still working on migrating the TUHS services from our existing Linux server to a new FreeBSD server. We now have our own DNS servers, ns1.tuhs.org and ns2.tuhs.org which hold the tuhs.org domain records. As you know, I personally have a "hidden" archive of Unix-related material which I haven't been able to release for legal and copyright reasons. If TUHS Inc. gets recognised as a museum, this might open up opportunities to allow some access to this material. We have been researching policies to cover the acquisition and use of material protected by legal ownership rights. What we really need is to get advice from some intellectual property experts, If you have any links, references or contacts w.r.t. IP experts, please let us know. Finally, we are working on a scalable mechanism to allow people to donate material to us. That's all the news for now. Hopefully, in a few weeks, I will be able to report on our application for charity status. Cheers, Warren From tuhs at tuhs.org Tue Aug 4 09:08:38 2026 From: tuhs at tuhs.org (Alexis via TUHS) Date: Tue, 04 Aug 2026 09:08:38 +1000 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: (Dave Horsfall via TUHS's message of "Tue, 4 Aug 2026 08:24:57 +1000") References: Message-ID: <87se4uer9l.fsf@gmail.com> Dave Horsfall via TUHS writes: > A long time ago, in a Unix manpage far away, I saw a reference > to "{}" > which acted similar to "()" except that it did not fork > e.g. "{exit}" would > do just that :-) > > Does anyone know the provenance of this Shell? I can't seem to > reproduce > it on the MacBook or the FreeBSD box here (my Penguin box is > currently > dead). Well, the dash(1) man page has: Grouping Commands Together Commands may be grouped by writing either (list) or { list; } The first of these executes the commands in a subshell. Builtin commands grouped into a (list) will not affect the current shell. The second form does not fork another shell so is slightly more efficient. Alexis. From tuhs at tuhs.org Tue Aug 4 09:09:22 2026 From: tuhs at tuhs.org (Peter Pentchev via TUHS) Date: Tue, 4 Aug 2026 02:09:22 +0300 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: Message-ID: On Tue, Aug 04, 2026 at 08:24:57AM +1000, Dave Horsfall via TUHS wrote: > A long time ago, in a Unix manpage far away, I saw a reference to "{}" > which acted similar to "()" except that it did not fork e.g. "{exit}" would > do just that :-) > > Does anyone know the provenance of this Shell? I can't seem to reproduce > it on the MacBook or the FreeBSD box here (my Penguin box is currently > dead). It should work on pretty much any Bourne-compatible shell, I think. However, there is one crucial point: you *must* place a semicolon between the last command and the closing brace, and if you write commands on the same line, you also *must* place a semicolon between the closing brace and the next command :) [roam at straylight ~]$ dash -c 'echo first; { echo second; echo third; }; echo fourth;' first second third fourth [roam at straylight ~]$ However, as usual, semicolons may be replaced with newline characters: [roam at straylight ~]$ dash -c $'echo first; { echo second; echo third\n}\necho fourth;' first second third fourth [roam at straylight ~]$ It should be described under a section named something like "grouping" or "compound commands" in your shell's manual page. 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 tuhs at tuhs.org Tue Aug 4 09:23:54 2026 From: tuhs at tuhs.org (Peter Pentchev via TUHS) Date: Tue, 4 Aug 2026 02:23:54 +0300 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: Message-ID: On Tue, Aug 04, 2026 at 02:09:22AM +0300, Peter Pentchev wrote: > On Tue, Aug 04, 2026 at 08:24:57AM +1000, Dave Horsfall via TUHS wrote: > > A long time ago, in a Unix manpage far away, I saw a reference to "{}" > > which acted similar to "()" except that it did not fork e.g. "{exit}" would > > do just that :-) > > > > Does anyone know the provenance of this Shell? I can't seem to reproduce > > it on the MacBook or the FreeBSD box here (my Penguin box is currently > > dead). > > It should work on pretty much any Bourne-compatible shell, I think. > However, there is one crucial point: you *must* place a semicolon between > the last command and the closing brace, and if you write commands on > the same line, you also *must* place a semicolon between the closing > brace and the next command :) And of course, I forgot to include an actually useful example: something that was pretty common back when I wrote Makefiles for fun: gzip -cn9 repopush.1 > repopush.1.gz || { rm -f repopush.1.gz; exit 1; } 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 tuhs at tuhs.org Tue Aug 4 09:34:54 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 3 Aug 2026 17:34:54 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: Message-ID: On Mon, Aug 3, 2026 at 4:25 PM Dave Horsfall via TUHS wrote: > A long time ago, in a Unix manpage far away, I saw a reference to "{}" > which acted similar to "()" except that it did not fork e.g. "{exit}" would > do just that :-) > > Does anyone know the provenance of this Shell? I can't seem to reproduce > it on the MacBook or the FreeBSD box here (my Penguin box is currently > dead). > It dates back to V7. It's in FreeBSD today. I use it all the time. From the 7th edition man page: ... ( list ) Execute list in a subshell. { list } list is simply executed. ... A huge number of shell scripts depend on this behavior. Since the 6th Edition used the Thompson Shell, it doesn't have this as far as I can tell, but does have () grouping. I've not examined the source to Thompson shell closely to know if it secretly does this (and that's why Steve Bourne implemented it), or if that's something Bourne invented. But there are '(' and ')' in sh.c, but no '{' or '}', so that leans towards Bourne inventing it or borrowing it. Warner From tuhs at tuhs.org Tue Aug 4 09:45:18 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Mon, 03 Aug 2026 23:45:18 +0000 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: Message-ID: Using Peter's guidance, I tried the original command discussed, in Bash on my Macbook Air, and it worked. { exit 1; } The result: https://ibb.co/xq20BMvT Side note: I also tried on Bash on Debian sandboxed on GrapheneOS and the result was the same. Best wishes, Cameron On Tuesday, 4 August 2026 at 00:24, Peter Pentchev via TUHS wrote: > And of course, I forgot to include an actually useful example: > something that was pretty common back when I wrote Makefiles for fun: > > gzip -cn9 repopush.1 > repopush.1.gz || { rm -f repopush.1.gz; exit 1; } > > On Tue, Aug 04, 2026 at 08:24:57AM +1000, Dave Horsfall via TUHS wrote, in part: > > > A long time ago, in a Unix manpage far away, I saw a reference to "{}" > > > which acted similar to "()" except that it did not fork e.g. "{exit}" would > > > do just that :-) From tuhs at tuhs.org Tue Aug 4 10:05:27 2026 From: tuhs at tuhs.org (Cameron Tyre via TUHS) Date: Tue, 04 Aug 2026 00:05:27 +0000 Subject: [TUHS] =?utf-8?b?SnVuZSA4LCAyMDI2IOKAkyBWaXZpYW4gVm9zcyDigJMg?= =?utf-8?q?Where_Unix_Runs_Today?= In-Reply-To: <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> References: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> Message-ID: Hi Charlie, My desktop, a Mac mini and my laptop, a secondhand Macbook Air, both run on it and it was the installation of Xcode on the desktop which also installed the command-line tools which then led me down the long and winding rabbit hole leading to the TUHS list for which I am always grateful to have discovered. I always download a copy of the UNIX 03 certification for the latest macOS major release, from the Open Group website, and pin it on my office wall. It's some kind of completeness thing in my head, I guess. Only last week I got an email from Apple asking me to complete a survey about why I bought an Apple computer and other, scarier, questions like "Do I update it?"...! In one of my replies I said that I like to try and keep life simple and that I can click on Terminal, fire up ed, type out a document and then use lp to print it out and it doesn't get much simpler than that. My wife has an iPhone and an iPad. I once tried to explain a condensed version of the UNIX story to her and that her phone and tablet were running UNIX underneath the colorful facades of iOS and iPadOS but I can't reproduce her reply on this list, or probably anywhere. Best wishes, Cameron On Monday, 3 August 2026 at 17:25, Charles H Sauer (he/him) via TUHS wrote: > I discovered https://vivianvoss.net/blog/where-unix-runs-today yesterday > and sent the excerpts below to former AIX colleagues and others that > might be interested. I forwarded that mail to Clem and Heinz this > morning. Clem replied with a detailed commentary. Clem seemed to agree > this might be worth posting here to liven things up. > > Charlie > > ''Open the laptop in front of you. If it is a Mac, you are on certified > Unix. Hand it to the child next to you, watching cartoons on an iPad — > also Darwin underneath, the same family. The phone in your pocket: same. > Walk through any data centre serving European video, and a sizeable > share of those streams come off appliances running FreeBSD. Pick up a > games console at the till in any electronics shop, and odds are very > good it boots a fork of FreeBSD before it ever shows you a menu. > ... > ''One footnote worth keeping. Apple is certified on UNIX 03, dating from > 2002. Only one product on the planet is certified at the next level — > UNIX V7 (Single UNIX Specification version 4, POSIX.1-2008): IBM’s AIX 7. > ... > ''The world’s commercial Unix systems are not all in retirement homes. > > ''IBM AIX is actively developed. New versions track new IBM POWER > processors; the public roadmap is clear. AIX 7 is the only operating > system in the world certified at UNIX V7 (SUSv4) level. Banks, > insurance, large enterprise back-office: AIX still carries this work, > and IBM still treats it as core strategy.'' From tuhs at tuhs.org Tue Aug 4 16:47:44 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 04 Aug 2026 00:47:44 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: Message-ID: <202608040647.6746liUq010984@freefriends.org> Warner Losh via TUHS wrote: > I've not examined the source to Thompson shell closely to know if it > secretly does this (and that's why Steve Bourne implemented it), or if > that's something Bourne invented. Braces are also allowed where "do" and "done" are. I have always suspected, but never bothered to verify, that this is the case so that shell scripts could look more like C if one wanted them to. For example, in Bash: $ for ((i = 1; i <= 3; i++)) > { > echo $i > } 1 2 3 Arnold From tuhs at tuhs.org Tue Aug 4 17:02:12 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 04 Aug 2026 07:02:12 +0000 Subject: [TUHS] =?utf-8?b?SnVuZSA4LCAyMDI2IOKAkyBWaXZpYW4gVm9zcyDigJMg?= =?utf-8?q?Where_Unix_Runs_Today?= In-Reply-To: <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> References: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> Message-ID: <17Ded2ywWWAumqVAMclrJ6A5IVTLn9wgyu-4HyXcTEUYHwr-Rt0BIklGvCINVPlbOIakxyWr3OdBCWHKJeVNlo_ufdCAKMGxtb4N4ajfaF8=@protonmail.com> On Monday, August 3rd, 2026 at 09:25, Charles H Sauer (he/him) via TUHS wrote: > I discovered https://vivianvoss.net/blog/where-unix-runs-today yesterday > and sent the excerpts below to former AIX colleagues and others that > might be interested. I forwarded that mail to Clem and Heinz this > morning. Clem replied with a detailed commentary. Clem seemed to agree > this might be worth posting here to liven things up. > > Charlie > I appreciate this, as being the nerd I am, I proselytize on UNIX's influence and presence in most of our modern computing world to my friends every so often. Usually comes up because they ask about the documentation stuff I study (I also host music events at my house so plenty of folks have a chance to peruse the shelves.) The other context in which it comes up is when someone's cursing a POS terminal but I'll let the technology's name speak for itself :) Anywho, something I'm a bit tickled by is that there are various UNIX and UNIX-like kernels down inside of various analog telephone adapter (ATA) devices which then enable, among other things, Bell System telephones to still interface with modern digital networks that have left the 5ESS behind. It's a bit poetic how it has all come together that UNIX in 2026 continues to excel in telecommunications of all kinds. Once upon a time, UNIX was a system running on a single PDP-7 at MHCC. Today, I pick up the Western Electric 500D telephone at my desk and it connects to a Grandstream ATA running some sort of Linux kernel to compute which other telephone the various pulses I'm sending down a wire mean I should connect to*. A chunk of the compute has now moved from the CO into a small black box on my desk no larger than a hamburger. And that small black hamburger runs something that talks to its client software quite similarly to what Ken, Dennis, et. al. knew was the type-design for a quality system that would outlast generational shifts in implementation. ANSI C and POSIX are both testaments to that... - Matt G. * - As an aside, I have not had a personal telephone in many years, cellular or otherwise. I have an assigned Android mobile for work but that stays chained to my desk like the snarling, rabid animal it is. Needless to say, the telephone I describe is a cool local network called Telehamster (https://www.telehamster.net/) here in Bellingham. The network is simply a 10,000 line Grandstream network, with each line being a 4-digit extension on the local network. However, being a VoIP thing, anyone globally can join the network. This isn't an ad pitch by the way, I'm just super jazzed on the project and enjoy the crossroads it sits at re: unix, telephones, community, etc. I like to celebrate these sorts of projects! From tuhs at tuhs.org Tue Aug 4 18:21:24 2026 From: tuhs at tuhs.org (Peter Pentchev via TUHS) Date: Tue, 4 Aug 2026 11:21:24 +0300 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <202608040647.6746liUq010984@freefriends.org> References: <202608040647.6746liUq010984@freefriends.org> Message-ID: On Tue, Aug 04, 2026 at 12:47:44AM -0600, Arnold Robbins via TUHS wrote: > Warner Losh via TUHS wrote: > > > I've not examined the source to Thompson shell closely to know if it > > secretly does this (and that's why Steve Bourne implemented it), or if > > that's something Bourne invented. > > Braces are also allowed where "do" and "done" are. > > I have always suspected, but never bothered to verify, that this is > the case so that shell scripts could look more like C if one wanted > them to. For example, in Bash: > > $ for ((i = 1; i <= 3; i++)) > > { > > echo $i > > } > 1 > 2 > 3 Well, that's several kinds of Bash-specific syntax right there :) (nothing wrong with that, just pointing it out) I think that in the original implementation the main point was indeed to be able to put more than one command in a || or && pipeline as in my ... || { ...; exit 1; } example, or to redirect their input or output: { printf header; command; printf footer; } | processing-command (similar to the dash manual page example). 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 tuhs at tuhs.org Tue Aug 4 19:11:18 2026 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Tue, 4 Aug 2026 19:11:18 +1000 Subject: [TUHS] =?utf-8?b?SnVuZSA4LCAyMDI2IOKAkyBWaXZpYW4gVm9zcyDigJMg?= =?utf-8?q?Where_Unix_Runs_Today?= In-Reply-To: <17Ded2ywWWAumqVAMclrJ6A5IVTLn9wgyu-4HyXcTEUYHwr-Rt0BIklGvCINVPlbOIakxyWr3OdBCWHKJeVNlo_ufdCAKMGxtb4N4ajfaF8=@protonmail.com> References: <36d94a88-e21b-46eb-9fa4-5193cd7bd61c@gmail.com> <354fb67f-921e-410c-a824-6d96dea2e6ea@technologists.com> <17Ded2ywWWAumqVAMclrJ6A5IVTLn9wgyu-4HyXcTEUYHwr-Rt0BIklGvCINVPlbOIakxyWr3OdBCWHKJeVNlo_ufdCAKMGxtb4N4ajfaF8=@protonmail.com> Message-ID: I've heard Andy Tanenbaum say on a video-link address: "No Unix, No Lions Commentary, No MINIX, No Linux, No Android," [ didn't add "No iOS/MacOS" ] He was more circumspect & expansive in his CACM article on the topic. > On 4 Aug 2026, at 17:02, segaloco via TUHS wrote: > > I appreciate this, as being the nerd I am, I proselytize on UNIX's > influence and presence in most of our modern computing world to my > friends every so often. Lessons Learned from 30 Years of MINIX, March 2016, CACM I decided to write a book describing the code, like Lions did before me, and have my publisher, Prentice Hall, distribute the system, including all source code, as an adjunct to the book. Thirty years later the consequences of Van Renesse's offhand remark are enormous. If he had not mentioned interrupt 15, I would probably have eventually given up in despair. Without MINIX, it is inconceivable there would have been a Linux since Linus Torvalds learned about operating systems by studying the MINIX source code in minute detail and using it as a base to write Linux. Without Linux, there would not have been an Android since it is built on top of Linux. Without Android, the relative stock prices of Apple and Samsung might be quite different today. ============== Related links, including videos in a blog post: ============== -- 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 From tuhs at tuhs.org Tue Aug 4 20:04:36 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 04 Aug 2026 04:04:36 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: <202608040647.6746liUq010984@freefriends.org> Message-ID: <202608041004.674A4a8N033727@freefriends.org> Peter Pentchev wrote: > On Tue, Aug 04, 2026 at 12:47:44AM -0600, Arnold Robbins via TUHS wrote: > > Warner Losh via TUHS wrote: > > > > > I've not examined the source to Thompson shell closely to know if it > > > secretly does this (and that's why Steve Bourne implemented it), or if > > > that's something Bourne invented. > > > > Braces are also allowed where "do" and "done" are. > > > > I have always suspected, but never bothered to verify, that this is > > the case so that shell scripts could look more like C if one wanted > > them to. For example, in Bash: > > > > $ for ((i = 1; i <= 3; i++)) > > > { > > > echo $i > > > } > > 1 > > 2 > > 3 > > Well, that's several kinds of Bash-specific syntax right there :) > (nothing wrong with that, just pointing it out) The `for((...))' originated in ksh (ksh 88 I think), but the ability to use braces instead of do and done goes back to the V7 Bourne shell. Just sayin'. Arnold From tuhs at tuhs.org Wed Aug 5 05:23:29 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Tue, 4 Aug 2026 12:23:29 -0700 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <202608040647.6746liUq010984@freefriends.org> References: <202608040647.6746liUq010984@freefriends.org> Message-ID: <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Then why does echo me; echo $$ ( echo parens ; echo $$ ; ) { echo brace; echo $$ ; } Always echo the same pid? me 46999 parens 46999 brace 46999 > On Aug 3, 2026, at 11:47 PM, Arnold Robbins via TUHS wrote: > > Warner Losh via TUHS wrote: > >> I've not examined the source to Thompson shell closely to know if it >> secretly does this (and that's why Steve Bourne implemented it), or if >> that's something Bourne invented. > > Braces are also allowed where "do" and "done" are. > > I have always suspected, but never bothered to verify, that this is > the case so that shell scripts could look more like C if one wanted > them to. For example, in Bash: > > $ for ((i = 1; i <= 3; i++)) > > { > > echo $i > > } > 1 > 2 > 3 > > Arnold From tuhs at tuhs.org Wed Aug 5 06:08:07 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 4 Aug 2026 14:08:07 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: On Tue, Aug 4, 2026, 1:23 PM David Barto wrote: > Then why does > echo me; echo $$ > ( echo parens ; echo $$ ; ) > { echo brace; echo $$ ; } > > Always echo the same pid? > > me > 46999 > parens > 46999 > brace > 46999 Because {} doesn't fork a shell. Warner > > On Aug 3, 2026, at 11:47 PM, Arnold Robbins via TUHS > wrote: > > > > Warner Losh via TUHS wrote: > > > >> I've not examined the source to Thompson shell closely to know if it > >> secretly does this (and that's why Steve Bourne implemented it), or if > >> that's something Bourne invented. > > > > Braces are also allowed where "do" and "done" are. > > > > I have always suspected, but never bothered to verify, that this is > > the case so that shell scripts could look more like C if one wanted > > them to. For example, in Bash: > > > > $ for ((i = 1; i <= 3; i++)) > > > { > > > echo $i > > > } > > 1 > > 2 > > 3 > > > > Arnold > > From tuhs at tuhs.org Wed Aug 5 06:09:24 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 4 Aug 2026 14:09:24 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: On Tue, Aug 4, 2026, 2:08 PM Warner Losh wrote: > > > On Tue, Aug 4, 2026, 1:23 PM David Barto wrote: > >> Then why does >> echo me; echo $$ >> ( echo parens ; echo $$ ; ) >> { echo brace; echo $$ ; } >> >> Always echo the same pid? >> >> me >> 46999 >> parens >> 46999 >> brace >> 46999 > > > Because {} doesn't fork a shell. > Oh () hiding in there. N/m Warner > > Warner > > >> > On Aug 3, 2026, at 11:47 PM, Arnold Robbins via TUHS >> wrote: >> > >> > Warner Losh via TUHS wrote: >> > >> >> I've not examined the source to Thompson shell closely to know if it >> >> secretly does this (and that's why Steve Bourne implemented it), or if >> >> that's something Bourne invented. >> > >> > Braces are also allowed where "do" and "done" are. >> > >> > I have always suspected, but never bothered to verify, that this is >> > the case so that shell scripts could look more like C if one wanted >> > them to. For example, in Bash: >> > >> > $ for ((i = 1; i <= 3; i++)) >> > > { >> > > echo $i >> > > } >> > 1 >> > 2 >> > 3 >> > >> > Arnold >> >> From tuhs at tuhs.org Wed Aug 5 06:35:35 2026 From: tuhs at tuhs.org (jason-tuhs--- via TUHS) Date: Tue, 4 Aug 2026 13:35:35 -0700 (PDT) Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: <6cba8f9a-c4df-f11a-035a-92128c796c29@shalott.net> > Then why does > echo me; echo $$ > ( echo parens ; echo $$ ; ) > { echo brace; echo $$ ; } > > Always echo the same pid? This is a special case. https://pubs.opengroup.org/onlinepubs/009696599/utilities/xcu_chap02.html#tag_02_12 > $ > Expands to the decimal process ID of the invoked shell. In a > subshell (see Shell Execution Environment ), '$' shall expand to the > same value as that of the current shell. $ echo $$ 16573 $ ( sleep 2 ; sleep 2 ; echo $$ ) & ps dx | egrep -B3 "sleep 2" 43470 0 Is 0:00.30 | `-- zsh 16573 0 S 0:00.01 | `-- sh 31757 0 S 0:00.00 | |-- sh 34834 0 SC 0:00.00 | | `-- sleep 2 32128 0 R+ 0:00.00 | |-- ps dx 37095 0 S+ 0:00.00 | `-- egrep -B3 sleep 2 $ 16573 [1] Done (sleep 2; sleep 2; echo ${$}) -Jason From tuhs at tuhs.org Wed Aug 5 06:36:01 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Tue, 4 Aug 2026 16:36:01 -0400 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: Because shell variables are expanded before execution On Tue, Aug 4, 2026, 4:09 PM Warner Losh via TUHS wrote: > On Tue, Aug 4, 2026, 2:08 PM Warner Losh wrote: > > > > > > > On Tue, Aug 4, 2026, 1:23 PM David Barto wrote: > > > >> Then why does > >> echo me; echo $$ > >> ( echo parens ; echo $$ ; ) > >> { echo brace; echo $$ ; } > >> > >> Always echo the same pid? > >> > >> me > >> 46999 > >> parens > >> 46999 > >> brace > >> 46999 > > > > > > Because {} doesn't fork a shell. > > > > Oh () hiding in there. N/m > > Warner > > > > > Warner > > > > > >> > On Aug 3, 2026, at 11:47 PM, Arnold Robbins via TUHS > >> wrote: > >> > > >> > Warner Losh via TUHS wrote: > >> > > >> >> I've not examined the source to Thompson shell closely to know if it > >> >> secretly does this (and that's why Steve Bourne implemented it), or > if > >> >> that's something Bourne invented. > >> > > >> > Braces are also allowed where "do" and "done" are. > >> > > >> > I have always suspected, but never bothered to verify, that this is > >> > the case so that shell scripts could look more like C if one wanted > >> > them to. For example, in Bash: > >> > > >> > $ for ((i = 1; i <= 3; i++)) > >> > > { > >> > > echo $i > >> > > } > >> > 1 > >> > 2 > >> > 3 > >> > > >> > Arnold > >> > >> > From tuhs at tuhs.org Wed Aug 5 07:11:22 2026 From: tuhs at tuhs.org (Sven Mascheck via TUHS) Date: Tue, 4 Aug 2026 23:11:22 +0200 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: <99a26936-8059-4ac6-bad3-62b281576101@in-ulm.de> Actually correct,  but $$ will be the same anyway, like in a better test case       $ ( eval echo '$$' ) I'd put it this way:  - Purpose of a subshell is to avoid any changes in its environment to kick back into the current shell  - ... while keeping non-exported variables available.  They wouldn't be inherited by a new sh command. I wonder if keeping even $$ was an unintentional side effect. Or even intentional: The subshell shall see and behave very much like the original shell, just not leave any traces in the environment after exiting? Cheers, Sven Rich Salz via TUHS: > Because shell variables are expanded before execution > > [...] > > On Tue, Aug 4, 2026, 1:23 PM David Barto wrote: > >> Then why does >> echo me; echo $$ >> ( echo parens ; echo $$ ; ) >> { echo brace; echo $$ ; } >> >> Always echo the same pid? From tuhs at tuhs.org Wed Aug 5 08:40:42 2026 From: tuhs at tuhs.org (jason-tuhs--- via TUHS) Date: Tue, 4 Aug 2026 15:40:42 -0700 (PDT) Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <99a26936-8059-4ac6-bad3-62b281576101@in-ulm.de> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> <99a26936-8059-4ac6-bad3-62b281576101@in-ulm.de> Message-ID: <6c0e4015-67ce-2708-f34a-314708e15c59@shalott.net> >  - Purpose of a subshell is to avoid any changes in its environment to kick > back into the current shell >  - ... while keeping non-exported variables available.  They wouldn't be > inherited by a new sh command. > I wonder if keeping even $$ was an unintentional side effect. Or even > intentional: > The subshell shall see and behave very much like the original shell, just not > leave any traces in the environment after exiting? Correct. https://pubs.opengroup.org/onlinepubs/009696599/utilities/xcu_chap02.html#tag_02_12 > A subshell environment shall be created as a duplicate of the shell > environment, except that signal traps set by that shell environment > shall be set to the default values. Changes made to the subshell > environment shall not affect the shell environment. "Environment" in this case having a broad meaning including shell functions, variables, open FDs, CWD, umask, etc. Forking a new process for a subshell is not a requirement, it is merely an implementation detail, and it is not universal. E.g., ksh93 does not fork for (some) subshells (presumably as a performance optimization?), while pdksh, bash, zsh, and ash, do. /home/jason-241229: ksh93 $ echo $$ ; ( /bin/sleep 1 ; /bin/sleep 1 ; echo $$ ) 22589 22589 /home/jason-241231: while true ; do ps dx | egrep -B3 "sleep 1" ; done 52328 - S 0:00.15 |-- xterm -fn Source Code Pro Medium 14 65138 25 Is 0:00.39 | `-- zsh 22589 25 S 0:00.01 | `-- ksh93 29282 25 SC+ 0:00.00 | `-- /bin/sleep 1 hashbrown/home/jason-241230: ksh $ echo $$ ; ( /bin/sleep 1 ; /bin/sleep 1 ; echo $$ ) 82173 82173 /home/jason-241232: while true ; do ps dx | egrep -B3 "sleep 1" ; done 65138 25 Is 0:00.41 | `-- zsh 82173 25 S 0:00.00 | `-- ksh 80219 25 S+ 0:00.00 | `-- ksh 80250 25 SC+ 0:00.00 | `-- /bin/sleep 1 /home/jason-241230: pkg which =ksh93 =ksh /usr/local/bin/ksh93 was installed by package ksh93-93.u_4,2 /usr/local/bin/ksh was installed by package pdksh-5.2.14p2_7 -Jason From tuhs at tuhs.org Wed Aug 5 22:26:23 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 05 Aug 2026 06:26:23 -0600 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> Message-ID: <202608051226.675CQN0i093320@freefriends.org> David Barto wrote: > Then why does > echo me; echo $$ > ( echo parens ; echo $$ ; ) > { echo brace; echo $$ ; } > > Always echo the same pid? > > me > 46999 > parens > 46999 > brace > 46999 $$ is the PID of the original shell. The subshell keeps all the same variables as the parent shell. Using () instead of {} makes a difference for something like the classic tar pipeline: (cd /home ; tar -cf - arnold) | (cd /newhome ; tar -xpvf -) to copy a file tree from one place to another. The `cd's happen in subshells, leaving the parent shell in the original directory. HTH, Arnold From tuhs at tuhs.org Thu Aug 6 00:02:08 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 5 Aug 2026 10:02:08 -0400 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <202608051226.675CQN0i093320@freefriends.org> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> <202608051226.675CQN0i093320@freefriends.org> Message-ID: <14c1179d-afd2-4193-8c50-2d57a1a70722@case.edu> On 8/5/26 8:26 AM, Arnold Robbins via TUHS wrote: > Using () instead of {} makes > a difference for something like the classic tar pipeline: > > (cd /home ; tar -cf - arnold) | (cd /newhome ; tar -xpvf -) > > to copy a file tree from one place to another. > > The `cd's happen in subshells, leaving the parent shell in the > original directory. Sure, let's dive down the rabbit hole. The () vs. {} doesn't make a difference here: except for ksh (and I think maybe zsh?), all elements of a pipeline are executed in subshells. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Thu Aug 6 00:04:37 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 5 Aug 2026 10:04:37 -0400 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: <6cba8f9a-c4df-f11a-035a-92128c796c29@shalott.net> References: <202608040647.6746liUq010984@freefriends.org> <4F7DEEE4-D30A-4B79-95C3-2D8952907B87@kdbarto.org> <6cba8f9a-c4df-f11a-035a-92128c796c29@shalott.net> Message-ID: <1db7f6da-b0fd-4ded-915d-f321a7a4df85@case.edu> On 8/4/26 4:35 PM, jason-tuhs--- via TUHS wrote: > >> Then why does >> echo me; echo $$ >> ( echo parens ; echo $$ ; ) >> { echo brace; echo $$ ; } >> >> Always echo the same pid? > > This is a special case. This is the rationale for $BASHPID. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Thu Aug 6 00:08:40 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 5 Aug 2026 10:08:40 -0400 Subject: [TUHS] Use of "{}" in the Shell? In-Reply-To: References: <202608040647.6746liUq010984@freefriends.org> Message-ID: On 8/4/26 4:21 AM, Peter Pentchev via TUHS wrote: > On Tue, Aug 04, 2026 at 12:47:44AM -0600, Arnold Robbins via TUHS wrote: >> Warner Losh via TUHS wrote: >> >>> I've not examined the source to Thompson shell closely to know if it >>> secretly does this (and that's why Steve Bourne implemented it), or if >>> that's something Bourne invented. >> >> Braces are also allowed where "do" and "done" are. >> >> I have always suspected, but never bothered to verify, that this is >> the case so that shell scripts could look more like C if one wanted >> them to. For example, in Bash: >> >> $ for ((i = 1; i <= 3; i++)) >> > { >> > echo $i >> > } >> 1 >> 2 >> 3 > > Well, that's several kinds of Bash-specific syntax right there :) > (nothing wrong with that, just pointing it out) Only one: the arithmetic `for' loop. This works fine in the v7 shell: for f in 1 2 3 { echo $f } -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Aug 7 10:06:53 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Fri, 7 Aug 2026 10:06:53 +1000 Subject: [TUHS] We're a recognized charity! Message-ID: We have just received email from the Australian Charities and Not-for-profits commission: The Unix Heritage Society Inc. is registered as a charity with the Australian Charities and Not-for-profits Commission (ACNC). There's more detail at https://www.acnc.gov.au/charity/charities/d58ac126-6a89-f111-ab0f-7c1e52636f4b/profile Unfortunately, this doesn't make us tax-deductible (something that, I think, would only apply in Australia anyway), but it does mean that we don't have to pay our own taxes. There's probably more in the links on that page. Greg Lehey, as Secretary of TUHSI -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri Aug 7 10:28:22 2026 From: tuhs at tuhs.org (Cameron Tyre via TUHS) Date: Fri, 07 Aug 2026 00:28:22 +0000 Subject: [TUHS] We're a recognized charity! In-Reply-To: References: Message-ID: Thanks, Greg. That's awesome news! :) Cameron On Friday, 7 August 2026 at 01:08, Greg 'groggy' Lehey via TUHS wrote, in part: > We have just received email from the Australian Charities and > Not-for-profits commission: > > The Unix Heritage Society Inc. is registered as a charity with the > Australian Charities and Not-for-profits Commission (ACNC). From tuhs at tuhs.org Sun Aug 9 01:42:21 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Sat, 8 Aug 2026 10:42:21 -0500 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 Message-ID: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> All, A while back I mentioned that I was putting together an OpenSIMH laboratory for working through V6 alongside Lions. I've now put the repository up: https://github.com/decuser/lions-laboratory Besides the V6 distribution, installation guide, PDP-11/40 documentation, SIMH configurations, and known-good checkpoints, I've been adding notes from the things I've actually tried while reading Lions. So far these include working backward through the RK05 boot process from the kernel to the filesystem-aware |rkuboot| and finally to an 11-word first-stage bootstrap; stepping through |rkuboot| as it relocates itself to high memory, clears core, walks the V6 filesystem, loads |unix|, strips the 0407 header, and transfers control to it; and then following the early PDP-11/40 kernel initialization far enough to watch the MMU PAR/PDR registers being established. I've also been making small changes to make sure I understand what I'm reading rather than merely following it. I added |/dev/zero| as a new character-device minor, rebuilt and tested the kernel, and modified the RK05 filesystem bootstrap so that it automatically loads |unix| instead of prompting with |@|. There are notes and debugging transcripts for these experiments in the repository. The idea is not to turn V6 into something modern, but to provide a laboratory in which the machine and system Lions describes can be stopped, examined, modified, broken, and put back together. On a related note, while working through the V6 assembler sources, I wandered a little farther afield. Ritchie's UNIX Assembler Reference Manual says: |The input syntax of the UNIX assembler is generally similar to that of the DEC assembler PAL-11R... | and specifically points readers to DEC-11-ASDB-D, the PAL-11R manual, while warning that the internals and output formats are quite different. I read that manual to get more comfortable with the PDP-11 addressing modes and V6 assembler syntax, and eventually wondered what it was actually like to use PAL-11R in its native environment. That led to DOS-11. I now have DOS-11 V004A running on an emulated PDP-11/40 with a 32KB configuration and RK05, starting from the original DOS002 DECtape distribution (DEC-11-MW2C-UC, 11/15/71). The process is wonderfully hands-on: boot SYSLOD from DECtape, use the switch register to initialize the fresh disk, boot the Monitor from RK05, use PIP to populate it, relink LINK-11 for the machine configuration, and then rebuild PIP, EDIT-11, ODT-11R, LIBR-11, PAL-11R, etc. The resulting system is: |DOS Monitor V004A PIP-11 V005A LINK-11 V007A EDIT-11 V004A ODT-11R V002A LIBR-11 V002A PAL-11R V005A MODS-11 V003A | I wrote up the procedure, including a small PAL-11R "hello, world" using DOS Monitor EMT services, and compared it with the equivalent V6 as program using UNIX system calls. The DOS-11 excursion is admittedly peripheral to UNIX history, but it gave me a much better feel for the DEC environment against which the early UNIX toolchain was developed -- particularly since Ritchie himself points the reader toward PAL-11R. Here is the post on getting DOS11-004A up and running and programming HELLO.LDA: https://decuser.github.io/posts/getting-dos-11-v004a-running-on-a-pdp-11-40/ One thing this excursion changed for me was my sense of what it meant to program a PDP-11 in 1971. The name "DOS Monitor" can be misleading to modern ears. It is tempting to imagine something only slightly removed from a front-panel monitor, with the programmer otherwise dealing directly with the machine. That is not the environment I found. DOS-11 is the operating system; the Monitor is its resident executive, and the normal programming environment is already a hosted one. EDIT-11, PAL-11R, LINK-11, LIBR-11, ODT-11R, and PIP operate within that environment, and an ordinary application can obtain system services from the Monitor rather than implementing the hardware operations itself. The little DOS-11 |HELLO.PAL| program made this particularly clear. Although it is PDP-11 assembly language, it does not drive the terminal directly. It uses EMT calls to ask the Monitor to open the terminal, write the message, close it, and terminate the program. Of course, one could program the PDP-11 directly. Bootstrap loaders, diagnostics, device code, and dedicated applications provide obvious examples, and the front panel makes the machine unusually tangible to a modern programmer. But direct hardware programming should not be confused with the normal application-development model DEC was providing by 1971. The DOS distribution itself contains an editor, assembler, linker, librarian, debugger, file utility, filesystem, and resident Monitor services. This was already a substantial software environment in which to write programs. That made the comparison with V6 more interesting to me. UNIX did not introduce the basic idea that a PDP-11 application could execute in an operating-system environment and request services from it; that world was already familiar. What changes dramatically is the environment and the abstraction it presents. The corresponding V6 hello-world is almost startlingly small: |mov $1,r0 sys write; message; message_end-message sys exit | The contrast is therefore not simply "primitive monitor versus operating system," nor "bare metal versus UNIX." Both are hosted programming environments on the same processor. Looking at them side by side makes the differences in their abstractions, tools, interfaces, and assumptions much easier to see. I'm continuing to work downward through V6 rather than upward toward later UNIX, so corrections to either the Lions laboratory or my understanding of the contemporary DEC environment are very welcome. Will From tuhs at tuhs.org Sun Aug 9 15:16:53 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Sun, 9 Aug 2026 01:16:53 -0400 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> Message-ID: <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> Very cool, thanks for posting this. I kind of liked using DOS/BATCH-11 on a PDP-11/20 when I was young and foolish. I did some class exercises on it along with learning about PDP-11 assembler. Calling the operating system the Monitor is, I think, from the PDP-6/PDP-10 Monitor (later renamed TOPS-10) and I would not be surprised if there was a developer or two in common; that's before my time. Lower down the scale from DOS-11 was the Paper Tape programming system (manual DEC-ll-XPTSA-A-D) with PAL-11A (absolute instead of relocatable like PAL-11R).  But DOS-11 also supported DECtape (block-structured magnetic tape similar to the LINCtape and TX-2 tape) (and so did PDP-11 Unix!).  They might have been for bare metal application users; again. not something I touched that I can recall.  There was also KLDCP, the diagnostic operating system for the KL10 that ran on the PDP-11/40 front end; it was replaced for normal users by RSX-20F. (DEC used Keyboard Monitor for things that watched the keyboard, and Disk Monitor if they also supported a disk, going back to the PDP-8 if not earlier.) Other PDP-11 operating systems were the many different sizes/applications of RSX-11, descended from RSX-15 for the PDP-15 (http://b67c.com/DECPDP11RSX11.html) (PDP-7+=2 from the Unix point of view), and earlier ones for the 18-bit machines, listed in Supnik's 18b paper. Anyway, we used DOS-11 to build (edit CONFIG.MAC, assemble, link) RSTS-11 (BASIC-Plus timesharing) although maybe it wasn't too long before the build migrated to RT-11 and later to RSTS/E (PDP-11/50) it was self-hosted, IIRC with RSTS/E's RT-11 run-time-system.  (So the Run-Time System would take RT-11 operating system calls and then ask RSTS to do the operation.)  (Another student and I got all the way through using the summary pages of the installation manual but forgot to run the 'hooker' to 'hook' the bootstrap loader to the CIL/SIL [image library] and had to start over.  Gak.  But the second time we did it from memory.) IIRC, If you want an equivalent to "text\r\n" try .ASCII /text/<15><12> (or .ASCIZ if you want the \0 at the end). IIRC, For a comparison to cat >file, try using PIP to do # file All, > > A while back I mentioned that I was putting together an OpenSIMH > laboratory for working through V6 alongside Lions. I've now put the > repository up: > > https://github.com/decuser/lions-laboratory > > Besides the V6 distribution, installation guide, PDP-11/40 > documentation, SIMH configurations, and known-good checkpoints, I've > been adding notes from the things I've actually tried while reading > Lions. > > So far these include working backward through the RK05 boot process > from the kernel to the filesystem-aware |rkuboot| and finally to an > 11-word first-stage bootstrap; stepping through |rkuboot| as it > relocates itself to high memory, clears core, walks the V6 filesystem, > loads |unix|, strips the 0407 header, and transfers control to it; and > then following the early PDP-11/40 kernel initialization far enough to > watch the MMU PAR/PDR registers being established. > > I've also been making small changes to make sure I understand what I'm > reading rather than merely following it. I added |/dev/zero| as a new > character-device minor, rebuilt and tested the kernel, and modified > the RK05 filesystem bootstrap so that it automatically loads |unix| > instead of prompting with |@|. There are notes and debugging > transcripts for these experiments in the repository. > > The idea is not to turn V6 into something modern, but to provide a > laboratory in which the machine and system Lions describes can be > stopped, examined, modified, broken, and put back together. > > On a related note, while working through the V6 assembler sources, I > wandered a little farther afield. Ritchie's UNIX Assembler Reference > Manual says: > > |The input syntax of the UNIX assembler is generally similar to that > of the DEC assembler PAL-11R... | > > and specifically points readers to DEC-11-ASDB-D, the PAL-11R manual, > while warning that the internals and output formats are quite different. > > I read that manual to get more comfortable with the PDP-11 addressing > modes and V6 assembler syntax, and eventually wondered what it was > actually like to use PAL-11R in its native environment. That led to > DOS-11. > > I now have DOS-11 V004A running on an emulated PDP-11/40 with a 32KB > configuration and RK05, starting from the original DOS002 DECtape > distribution (DEC-11-MW2C-UC, 11/15/71). The process is wonderfully > hands-on: boot SYSLOD from DECtape, use the switch register to > initialize the fresh disk, boot the Monitor from RK05, use PIP to > populate it, relink LINK-11 for the machine configuration, and then > rebuild PIP, EDIT-11, ODT-11R, LIBR-11, PAL-11R, etc. > > The resulting system is: > > |DOS Monitor V004A PIP-11 V005A LINK-11 V007A EDIT-11 V004A ODT-11R > V002A LIBR-11 V002A PAL-11R V005A MODS-11 V003A | > > I wrote up the procedure, including a small PAL-11R "hello, world" > using DOS Monitor EMT services, and compared it with the equivalent V6 > as program using UNIX system calls. The DOS-11 excursion is admittedly > peripheral to UNIX history, but it gave me a much better feel for the > DEC environment against which the early UNIX toolchain was developed > -- particularly since Ritchie himself points the reader toward PAL-11R. > > Here is the post on getting DOS11-004A up and running and programming > HELLO.LDA: > https://decuser.github.io/posts/getting-dos-11-v004a-running-on-a-pdp-11-40/ > > One thing this excursion changed for me was my sense of what it meant > to program a PDP-11 in 1971. > > The name "DOS Monitor" can be misleading to modern ears. It is > tempting to imagine something only slightly removed from a front-panel > monitor, with the programmer otherwise dealing directly with the > machine. That is not the environment I found. DOS-11 is the operating > system; the Monitor is its resident executive, and the normal > programming environment is already a hosted one. EDIT-11, PAL-11R, > LINK-11, LIBR-11, ODT-11R, and PIP operate within that environment, > and an ordinary application can obtain system services from the > Monitor rather than implementing the hardware operations itself. > > The little DOS-11 |HELLO.PAL| program made this particularly clear. > Although it is PDP-11 assembly language, it does not drive the > terminal directly. It uses EMT calls to ask the Monitor to open the > terminal, write the message, close it, and terminate the program. > > Of course, one could program the PDP-11 directly. Bootstrap loaders, > diagnostics, device code, and dedicated applications provide obvious > examples, and the front panel makes the machine unusually tangible to > a modern programmer. But direct hardware programming should not be > confused with the normal application-development model DEC was > providing by 1971. The DOS distribution itself contains an editor, > assembler, linker, librarian, debugger, file utility, filesystem, and > resident Monitor services. This was already a substantial software > environment in which to write programs. > > That made the comparison with V6 more interesting to me. UNIX did not > introduce the basic idea that a PDP-11 application could execute in an > operating-system environment and request services from it; that world > was already familiar. What changes dramatically is the environment and > the abstraction it presents. The corresponding V6 hello-world is > almost startlingly small: > > |mov $1,r0 sys write; message; message_end-message sys exit | > > The contrast is therefore not simply "primitive monitor versus > operating system," nor "bare metal versus UNIX." Both are hosted > programming environments on the same processor. Looking at them side > by side makes the differences in their abstractions, tools, > interfaces, and assumptions much easier to see. > > I'm continuing to work downward through V6 rather than upward toward > later UNIX, so corrections to either the Lions laboratory or my > understanding of the contemporary DEC environment are very welcome. > > Will > From tuhs at tuhs.org Sun Aug 9 20:11:10 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sun, 09 Aug 2026 10:11:10 +0000 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> (Aron Insinga via TUHS's message of "Sun, 9 Aug 2026 01:16:53 -0400") References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> Message-ID: <7wbjbbli2p.fsf@junk.nocrew.org> Aron Insinga wrote: > Calling the operating system the Monitor is, I think, from the > PDP-6/PDP-10 Monitor (later renamed TOPS-10) There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of which there there is a resident part and a swappable (demand paged) part. I wager there were many other operating systems - also outside DEC - around that time using monitor in a similar sense. From tuhs at tuhs.org Mon Aug 10 06:58:57 2026 From: tuhs at tuhs.org (Alan Hightower via TUHS) Date: Sun, 09 Aug 2026 16:58:57 -0400 Subject: [TUHS] AT&T WE 321SB VME software or board user manual In-Reply-To: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> References: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> Message-ID: <249176b01f7027c700a1914d7fa44732@alanlee.org> Hello everyone, (cross posting to cctalk/tech) I've seen a similar message from Matt G. in the past, but I figured I would ask again... I have an AT&T WE 321SB VMEbus single-board computer en-route to me. It's sort-of a 3B2/3B5 on a VME card. It has WE32100 CPU, WE32106 MAU, and a WE32101 MMU all running at 18 MHz. This seems to put it roughly in-between the V2 and V3 3B2 architecture era. I believe it was initially offered by AT&T as a WE32K developer system, but I'm not super familiar with it's history. Once it arrives, I'll of course upload the ROM dumps to several archives. The board does not come with an intact filesystem or installation media. I am reaching out to see if anyone in the community has or knows the whereabouts of any media or documentation for the board or UNIX System V/VME software for the WE32K. I've seen references to "WE 321EB Microprocessor Evaluation Board User Manual" (AT&T Select Code / Catalog Number: CAT 451-019). But it also seems to be deleted from history. There is also photos of the install media containing: WE 321SB-VSU Software Utility Programs VME Device Driver Utilities / VME Dual VSMD-32 SMD Driver VME Device Driver Utilities / VME Ironics IV-1624 IS-I/O Driver-Source UNIX System V/VME / Essential Utilities-Disk 2 UNIX System V/VME / Essential Utilities-Disk 2 UNIX System V/VME / Startup Disk If you can help in any way in preserving another rare WE32K artifact, please let me know. Thanks, Alan Hightower From tuhs at tuhs.org Mon Aug 10 07:09:38 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 9 Aug 2026 17:09:38 -0400 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: <7wbjbbli2p.fsf@junk.nocrew.org> References: <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: <20260809210939.170CC119897D8@ary.qy> It appears that Lars Brinkhoff via TUHS said: >I wager there were many other operating systems - also outside DEC - >around that time using monitor in a similar sense. There were. IBM 709x IBSYS manuals describe the System Monitor, IBJOB has the Program Monitor, and so forth. R's, John From tuhs at tuhs.org Mon Aug 10 11:57:31 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Mon, 10 Aug 2026 11:57:31 +1000 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: <20260809210939.170CC119897D8@ary.qy> References: <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <7wbjbbli2p.fsf@junk.nocrew.org> <20260809210939.170CC119897D8@ary.qy> Message-ID: On Sunday, 9 August 2026 at 17:09:38 -0400, John Levine via TUHS wrote: > It appears that Lars Brinkhoff via TUHS said: >> I wager there were many other operating systems - also outside DEC - >> around that time using monitor in a similar sense. > > There were. IBM 709x IBSYS manuals describe the System Monitor, > IBJOB has the Program Monitor, and so forth. More recently, Tandem Computers' NonStop Kernel (previously Guardian) has a "monitor" process PID 0 IIRC) that does very much the same sort of thing. As far as I know, that's still the case. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Mon Aug 10 12:45:56 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Sun, 9 Aug 2026 19:45:56 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) Message-ID: So, for a while now, I've been wanting a Forth implementation for v7 Unix, because I like V7 and Forth is about my favorite language for implementing nifty stuff that runs pretty well in constrained environments. I am not fluent in PDP-11 assembler (and v7 "as" is not as capable as MACRO-11), but I do speak K&R C pretty well. I'd tried this a couple times and gotten bogged down either in too many symbols in a file (one per word) or too many symbols for the linker (one file per word). So I had Claude do the implementation. It sidestepped the above problem with a really tedious switch statement. It claims to be Forth-78 and Forth-79 compliant, and has tests for all the words, although I haven't actually verified that the tests are correct. It made another weird choice, in that the contemporary Forths I've seen have had a much smaller set of native primitives and have made the rest of the words out of those. There's also a reasonable screen editor for Forth blocks, and an upload/download tool (this was more traditionally pair-programmed, in that Claude did some things, then I did some things, then Claude did some more things, rinse and repeat) that works well with simh (with dynamic serial line speed detection) and presumably for a real PDP-11 with a serial line behind a telnet-to-serial bridge. https://github.com/athornton/v7vibeforth Pair programming with Claude was an interesting experience. My notes are in the README. I will say: I probably would never have finished this project without Claude's assistance (see above about the linker and symbol tables), and I *definitely* would not have written this extensive a test suite. And now I have a working Unix v7 Forth, which is what I wanted in the first place, so yay. Adam From tuhs at tuhs.org Mon Aug 10 14:59:29 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 10 Aug 2026 04:59:29 +0000 Subject: [TUHS] AT&T WE 321SB VME software or board user manual In-Reply-To: <249176b01f7027c700a1914d7fa44732@alanlee.org> References: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> <249176b01f7027c700a1914d7fa44732@alanlee.org> Message-ID: On Sunday, August 9th, 2026 at 13:59, Alan Hightower via TUHS wrote: > Hello everyone, (cross posting to cctalk/tech) > > I've seen a similar message from Matt G. in the past, but I figured I > would ask again... > > I have an AT&T WE 321SB VMEbus single-board computer en-route to me. > It's sort-of a 3B2/3B5 on a VME card. It has WE32100 CPU, WE32106 MAU, > and a WE32101 MMU all running at 18 MHz. This seems to put it roughly > in-between the V2 and V3 3B2 architecture era. I believe it was > initially offered by AT&T as a WE32K developer system, but I'm not super > familiar with it's history. Once it arrives, I'll of course upload the > ROM dumps to several archives. The board does not come with an intact > filesystem or installation media. I am reaching out to see if anyone in > the community has or knows the whereabouts of any media or documentation > for the board or UNIX System V/VME software for the WE32K. I've seen > references to "WE 321EB Microprocessor Evaluation Board User Manual" > (AT&T Select Code / Catalog Number: CAT 451-019). But it also seems to > be deleted from history. There is also photos of the install media > containing: > > WE 321SB-VSU Software Utility Programs > > VME Device Driver Utilities / VME Dual VSMD-32 SMD Driver > > VME Device Driver Utilities / VME Ironics IV-1624 IS-I/O Driver-Source > > UNIX System V/VME / Essential Utilities-Disk 2 > > UNIX System V/VME / Essential Utilities-Disk 2 > > UNIX System V/VME / Startup Disk > > If you can help in any way in preserving another rare WE32K artifact, > please let me know. > > Thanks, > > Alan Hightower > For the record, at had a *Motorola 68k* release sold to customers using the VME/10, MVME rack mounts, that sort of thing, so if upstream 3B2 source provisions don't have VMEbus support, that could possibly be transplanted from a 68K System V distribution. There is one on bitsavers afaik, not somewhere I can look at present. Also count me jealous as all get out, I've been hunting a 321SB or 321EB for years, luckily landed two MAC-Tutors and a box of MAC-8 and MAC-4 chips in my search, as well as a 32000, 32001, 32006, and DSP32, but none of the WE32 eval/dev boards. Anywho, this is an area of particular interest to me so happy to connect more off list regarding this one. - Matt G. From tuhs at tuhs.org Mon Aug 10 16:14:42 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 10 Aug 2026 06:14:42 +0000 Subject: [TUHS] [tuhsteam] I found a 9 track Tape In-Reply-To: References: Message-ID: Hi Clem, I think you're right. There are many preserved cfront distributions here: https://softwarepreservation.computerhistory.org/c_plus_plus/index.html More specifically: https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_1.2/source/Cfront1.2.tgz Curious that your tape doesn't say "C++ Translator" but everything else lines up. The above source distribution has a README starting: > This is the AT&T C++ Translator, Release 1.2 And throughout the README the word "Translator" with a capital T is repeated over and over. The 1.2 release that is preserved is not technically pure, it's a modified version for a Pyramid system, but the original files are also in there, just not wholly virgin. - Matt G. On Sunday, August 9th, 2026 at 16:00, Clem Cole via TUHS Team wrote: > @Matt, in particular, who seems to have the best AT&T knowledge of many of us. Does anyone have any idea what the Unix System C translator from 1987 might have been? The other marking said dsg-cpio-0024 and seems like it was written on Feb 10, 1988 > > I'm wondering if this is the original cfront distribution? > > [2026-08-07 15.52.34.jpg] From tuhs at tuhs.org Mon Aug 10 17:01:07 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Mon, 10 Aug 2026 00:01:07 -0700 Subject: [TUHS] AT&T WE 321SB VME software or board user manual In-Reply-To: <249176b01f7027c700a1914d7fa44732@alanlee.org> References: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> <249176b01f7027c700a1914d7fa44732@alanlee.org> Message-ID: http://ferretronix.com/tech/att_vme/ - the parent page shows he seems to have the user manual (via https://forum.vcfed.org/index.php?threads/vme-at-t-bits-from-my-clean-up-that-i-cannot-find-data-on.56033/) That is a rare bird, I would love to find one too. On Sun, Aug 9, 2026 at 1:59 PM Alan Hightower via TUHS wrote: > > Hello everyone, (cross posting to cctalk/tech) > > I've seen a similar message from Matt G. in the past, but I figured I > would ask again... > > I have an AT&T WE 321SB VMEbus single-board computer en-route to me. > It's sort-of a 3B2/3B5 on a VME card. It has WE32100 CPU, WE32106 MAU, > and a WE32101 MMU all running at 18 MHz. This seems to put it roughly > in-between the V2 and V3 3B2 architecture era. I believe it was > initially offered by AT&T as a WE32K developer system, but I'm not super > familiar with it's history. Once it arrives, I'll of course upload the > ROM dumps to several archives. The board does not come with an intact > filesystem or installation media. I am reaching out to see if anyone in > the community has or knows the whereabouts of any media or documentation > for the board or UNIX System V/VME software for the WE32K. I've seen > references to "WE 321EB Microprocessor Evaluation Board User Manual" > (AT&T Select Code / Catalog Number: CAT 451-019). But it also seems to > be deleted from history. There is also photos of the install media > containing: > > WE 321SB-VSU Software Utility Programs > > VME Device Driver Utilities / VME Dual VSMD-32 SMD Driver > > VME Device Driver Utilities / VME Ironics IV-1624 IS-I/O Driver-Source > > UNIX System V/VME / Essential Utilities-Disk 2 > > UNIX System V/VME / Essential Utilities-Disk 2 > > UNIX System V/VME / Startup Disk > > If you can help in any way in preserving another rare WE32K artifact, > please let me know. > > Thanks, > > Alan Hightower From tuhs at tuhs.org Mon Aug 10 17:07:58 2026 From: tuhs at tuhs.org (Alan Hightower via TUHS) Date: Mon, 10 Aug 2026 03:07:58 -0400 Subject: [TUHS] AT&T WE 321SB VME software or board user manual In-Reply-To: References: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> <249176b01f7027c700a1914d7fa44732@alanlee.org> Message-ID: <5f95b9231fccf317f70f0cd905bf8552@alanlee.org> I think ferretronics.com is Jeff Jonas' site. I know he has a lot of WE32K and 3B2 documentation that is not scanned in. Long ago, I offered to drive up to NJ and camp out in his drive-way for a week with a half dozen scanners. But we never could sync up. I'm going to ping him again to see if we can get his rare docs on-line. That post on VCForums is the unit I bought. -A On 2026-08-10 03:01, Kevin Bowling wrote: > http://ferretronix.com/tech/att_vme/ - the parent page shows he seems > to have the user manual (via > https://forum.vcfed.org/index.php?threads/vme-at-t-bits-from-my-clean-up-that-i-cannot-find-data-on.56033/) > > That is a rare bird, I would love to find one too. > From tuhs at tuhs.org Tue Aug 11 13:58:10 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 11 Aug 2026 03:58:10 +0000 Subject: [TUHS] AT&T WE 321SB VME software or board user manual In-Reply-To: <5f95b9231fccf317f70f0cd905bf8552@alanlee.org> References: <816ba6c4c3de42855cc168db40f56bd6@alanlee.org> <249176b01f7027c700a1914d7fa44732@alanlee.org> <5f95b9231fccf317f70f0cd905bf8552@alanlee.org> Message-ID: <737TFMUEwblReCIoCYhIo8EogYJMv4Om55zYsApwSgLGK6XNPs4M6NvX85si_ljZjElflzW7W2t8gM0qTyScAU_YEr29UaX3eBl9sUPbtqw=@protonmail.com> On Monday, August 10th, 2026 at 00:08, Alan Hightower via TUHS wrote: > > I think ferretronics.com is Jeff Jonas' site. I know he has a lot of > WE32K and 3B2 documentation that is not scanned in. Long ago, I offered > to drive up to NJ and camp out in his drive-way for a week with a half > dozen scanners. But we never could sync up. I'm going to ping him > again to see if we can get his rare docs on-line. > > That post on VCForums is the unit I bought. > > -A > > > On 2026-08-10 03:01, Kevin Bowling wrote: > > http://ferretronix.com/tech/att_vme/ - the parent page shows he seems > > to have the user manual (via > > https://forum.vcfed.org/index.php?threads/vme-at-t-bits-from-my-clean-up-that-i-cannot-find-data-on.56033/) > > > > That is a rare bird, I would love to find one too. > > > +1 support for this scanning trip, I've also picked his brain about MAC-8 documents in the past. One he has is a source listing of m8os, one of the two generic kernels BTL developed for the MAC-8. I eagerly await the day I can sink my teeth into that one as the only extant, complete piece of MAC-8 software currently is the MAC-Tutor executive. The source to one of the versions is in the preserved MAC-Tutor manual on bitsavers. One of the two systems I have has an earlier issue, I think a prototype (the board is older than my Series 1 board by two years) so I intend to dump the ROM sometime this winter. Luckily it has a TTY circuit onboard so I can just write a little machine code program on the keypad KIM-1-style and use that to dump it. In fact, it also has a ZIF ROM socket so I may be able to apply it to dumping other WECo 28-type ROMs and equivalents... Anywho, speaking of which I have a 5ESS peripheral card with a late MAC-8 (WE212E) on it and several ROMs I also mean to dump for more MAC-8 software specimens. What I really hope surfaces someday though is the MAC-8 SGS. I want to try my hand at synthesizing it from the 3B2 SGS but just haven't gone down that path yet. Anywho, to bring it back around to UNIX, the 1978 BSTJ issue has a paper on UNIX as a MAC-8 development environment and then the more recent USG Library dump has a couple of papers on the WE32 design when it was still called the MAC-80. Both are nice insights into the synergy between UNIX and BTL's microprocessor efforts. I'll leave those of you interested in WECo silicon with this. The BellMAC series of 4, 8, and 32-bit CPUs is coming to be more well studied through efforts of Alan, myself, etc. but recently I landed some Dimension 400 PBX technical documentation from BTL Denver which describes a potential 16-bit minicomputer ancestor, the "MC3 Processor": > The processor is capable of sending and receiving a 16-bit data word. Communication > with all system units is via a 16-bit parallel 2-way data bus, > a 16-bit parallel one-way address bus, and a 5-bit parallel one-way control bus. > ... > The processor comprises seven circuit packs (LC19, LC20, LC21, > LC22, LC23, LC52, AND LC53) contained in the control carrier. I'm still piecing through the manuals to try and find UNIX references, but intend to scan them eventually. Either way, I have to wonder if 1. The MC3 has any DNA in common with the later 32-bit 3B-CC or earlier ESS CCs and/or whether BTL ever considered a microprocessor variant like the WE32 is to the 3B-CC/IS25 ISA. The 1, 1A, and 3A ISAs are preserved, afaik, so one of these days I might just try and answer that for myself. Too much on the plate right now though. Here's hoping in a few years with luck some of us nerds are trying to port V7 to the then exposed and documented MC3... - Matt G. From tuhs at tuhs.org Tue Aug 11 14:02:15 2026 From: tuhs at tuhs.org (Alan Hightower via TUHS) Date: Tue, 11 Aug 2026 00:02:15 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: Message-ID: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> On 2026-08-09 22:45, Adam Thornton via TUHS wrote: > I will say: I probably would never have finished this project without > Claude's assistance > > Adam ^^ This. AI gets a lot of bad blowback especially from older programmers. But results speak for themselves. Today is the worst AI will ever be going forward. Embrace it or get run over. -A From tuhs at tuhs.org Tue Aug 11 14:15:34 2026 From: tuhs at tuhs.org (Steve Nickolas via TUHS) Date: Tue, 11 Aug 2026 00:15:34 -0400 (EDT) Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On Tue, 11 Aug 2026, Alan Hightower via TUHS wrote: > > On 2026-08-09 22:45, Adam Thornton via TUHS wrote: > >> I will say: I probably would never have finished this project without >> Claude's assistance >> >> Adam > > ^^ This. AI gets a lot of bad blowback especially from older programmers. > But results speak for themselves. Today is the worst AI will ever be going > forward. Embrace it or get run over. > > -A It's certainly getting better. I'm clanking out a cleaned-up version of "Dungeon" from strictly open-source resources. Which means the bot has to know ZIL, MDL and Inform 6. (The main idea is to create a free/open replacement for something that appears in some versions of BSD from when it was still "Unix®".) -uso. From tuhs at tuhs.org Tue Aug 11 14:22:46 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 11 Aug 2026 04:22:46 +0000 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On Monday, August 10th, 2026 at 21:02, Alan Hightower via TUHS wrote: > > On 2026-08-09 22:45, Adam Thornton via TUHS wrote: > > > I will say: I probably would never have finished this project without > > Claude's assistance > > > > Adam > > ^^ This. AI gets a lot of bad blowback especially from older > programmers. But results speak for themselves. Today is the worst AI > will ever be going forward. Embrace it or get run over. > > -A > Doesn't feel like a helpful attitude to have though. Nobody is obligated to reorient their entire approach to their life's work because someone invented some new tool in that field. Eats me up just the same how most of society expects me to own and use an automobile and cellular device. Why is anyone beholden to adopting some new private product someone else invented? Not trying to bicker too much but this is a very, very near and dear subject to my heart. Any looking to debate lets take it offline, but I do feel a need to advocate that people are NEVER obligated to suddenly be beholden to a product or service just because someone else likes it. Nobody is *owed* the use of AI, and this mentality of "adopt arbitrary invention or get left behind" is so dehumanizing that it verges on sociopathy. UNIX didn't take hold by force, it didn't grow and improve because people were deemed persona non grata for avoiding it. Sure, there were evangelists and plenty of flame wars over the years, but that sort of negative dismissal is not what made the system strong. We build each other up, rather than tearing each other down. We find ways to accommodate rather than banishing disagreement. Again I don't want to make a habit of turning chit chat here into debate, but this "Someone invented product and you are less of a person for not paying for their invention" really and truly feels antithetical to what the fellowship that has grown around UNIX is all about. I want to advocate for being careful in all ways that adherence to some invention or technology hurts our real, human connections and support for one another. Dismissing someone because won't use or dislike AI is just as bad as dismissing them because they do like it. In both cases, a human connection has been made worse by an inanimate object. Ultimately, like it or hate it, our relationships shouldn't suffer over it. End rant, thank you if you read what I have to say. - Matt G. From tuhs at tuhs.org Tue Aug 11 22:58:42 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 11 Aug 2026 08:58:42 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On 8/11/26 12:22 AM, segaloco via TUHS wrote: > Doesn't feel like a helpful attitude to have though. Nobody is obligated to reorient their entire approach to their life's work because someone invented some new tool in that field. Eats me up just the same how most of society expects me to own and use an automobile and cellular device. Why is anyone beholden to adopting some new private product someone else invented? There is a utilitarian argument here. People use cell phones because they're useful and convenient. People drive cars because they are the best way to get around. (Let's put aside the cumulative effect of decades of public policy that have made it nearly impossible to survive without one in large parts of the US.) They're the best tool for the job. I think Alan believes that LLMs like Claude are going to be the best tool for some jobs; one more tool in the bag. Not an obligation, but a prediction. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Tue Aug 11 23:44:32 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 11 Aug 2026 08:44:32 -0500 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: <4bb95952-05eb-41c8-94e9-7ec2529f9e27@gmail.com> Matt et. al. I'm a fan, wannabe expert, skeptic, and something of a Luddite all rolled into one. I study machine knowing, so the current generative systems are fascinating to me as objects in their own right. Language is deeply implicated in understanding, and suddenly we have inexpensive machines whose principal interface is conversation. I find that hard to look away from. At the same time, Matt's concern resonates with me. I dislike technological dependence. I want the books, the source, the local files, the machine I can understand, and a reasonable chance of surviving the zombie apocalypse. Nobody becomes lesser by declining a tool, and nobody owes a private company dependence. Still, I understand the narrower truth behind "embrace it or get run over." In some kinds of work, a person who learns to use these systems well can operate at a radically different scale. That is leverage, not superiority. For me the leverage is unusually strong because I have aphantasia. I don't have an internal visual surface on which I can hold a complex structure and inspect it. I tend to know things configurationally: relation, fit, pressure, direction, what belongs and what doesn't. So I have always depended heavily on externalized cognition... writing, code, notes, diagrams, conversation, to give structure a surface I can return to. Generative AI makes that surface active. That's why I sometimes call it my Hawking's chair. The chair did not think for Hawking. It provided an external mechanism through which thought could become expressible and workable. With AI I can externalize a half-formed structure, get it back transformed almost immediately, inspect the transformation, reject it, correct it, or discover something in it, and continue. This has changed how quickly I can work. It has accelerated my exploration of V6 enormously, and I have built an entire small programming language with AI writing the implementation from my architecture, constraints, inspection, testing, and correction. That works not because AI is a great programmer - it really, truly isn't, but because it is an extraordinarily fast and ego-free mediator. That distinction is central to my research. I locate the informing act in the knowing subject: an encounter matters when apprehension leaves the subject differently configured, K != K'. The machine can transform, compare, expose, generate, and mediate. The judgment and apprehension remain elsewhere. And oddly enough, that makes my use of AI feel rather UNIX-like... to keep us on topic :). The UNIX lesson I took was never "use every new thing." It was to keep boundaries clean, make tools composable, keep durable things in inspectable forms, and avoid confusing one component with the system as a whole. A tool can be enormously powerful without becoming the place where your work lives. My source remains mine. My notes remain mine. The resulting code has to build without the model. The argument has to survive outside the conversation. If one mediator disappears tomorrow, another can take its place, or I can work without it. The durable substrate is outside the tool. So I don't think anyone needs to use AI. But neither do I think the scaling effect is imaginary. For certain kinds of intellectual work, making the external surface of cognition conversational, responsive, and nearly instantaneous is a substantial change. The trick, very much in the UNIX spirit, is to take the leverage without surrendering the architecture. For more on the mediation side of things, here's the most recent work I've done: https://www.emerald.com/jd/article/doi/10.1108/JD-03-2026-0125/1382093/The-informing-act-apprehension-in-AI-mediated The non-paywalled AAM is here: https://www.researchgate.net/publication/407280891_The_informing_act_apprehension_in_AI-mediated_systems Later, Will On 8/10/26 11:22 PM, segaloco via TUHS wrote: > On Monday, August 10th, 2026 at 21:02, Alan Hightower via TUHS wrote: > >> On 2026-08-09 22:45, Adam Thornton via TUHS wrote: >> >>> I will say: I probably would never have finished this project without >>> Claude's assistance >>> >>> Adam >> ^^ This. AI gets a lot of bad blowback especially from older >> programmers. But results speak for themselves. Today is the worst AI >> will ever be going forward. Embrace it or get run over. >> >> -A >> > Doesn't feel like a helpful attitude to have though. Nobody is obligated to reorient their entire approach to their life's work because someone invented some new tool in that field. Eats me up just the same how most of society expects me to own and use an automobile and cellular device. Why is anyone beholden to adopting some new private product someone else invented? > > Not trying to bicker too much but this is a very, very near and dear subject to my heart. Any looking to debate lets take it offline, but I do feel a need to advocate that people are NEVER obligated to suddenly be beholden to a product or service just because someone else likes it. Nobody is *owed* the use of AI, and this mentality of "adopt arbitrary invention or get left behind" is so dehumanizing that it verges on sociopathy. > > UNIX didn't take hold by force, it didn't grow and improve because people were deemed persona non grata for avoiding it. Sure, there were evangelists and plenty of flame wars over the years, but that sort of negative dismissal is not what made the system strong. We build each other up, rather than tearing each other down. We find ways to accommodate rather than banishing disagreement. > > Again I don't want to make a habit of turning chit chat here into debate, but this "Someone invented product and you are less of a person for not paying for their invention" really and truly feels antithetical to what the fellowship that has grown around UNIX is all about. I want to advocate for being careful in all ways that adherence to some invention or technology hurts our real, human connections and support for one another. Dismissing someone because won't use or dislike AI is just as bad as dismissing them because they do like it. In both cases, a human connection has been made worse by an inanimate object. Ultimately, like it or hate it, our relationships shouldn't suffer over it. > > End rant, thank you if you read what I have to say. > > - Matt G. From tuhs at tuhs.org Wed Aug 12 00:54:36 2026 From: tuhs at tuhs.org (Katie via TUHS) Date: Tue, 11 Aug 2026 10:54:36 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> > I think Alan believes that LLMs like Claude are going to be the best > tool > for some jobs; one more tool in the bag. Not an obligation, but a > prediction. If we're going to use LLMs, why not llama.cpp? I miss pagers. -Katie On 2026-08-11 08:58, Chet Ramey via TUHS wrote: > On 8/11/26 12:22 AM, segaloco via TUHS wrote: > >> Doesn't feel like a helpful attitude to have though. Nobody is >> obligated to reorient their entire approach to their life's work >> because someone invented some new tool in that field. Eats me up just >> the same how most of society expects me to own and use an automobile >> and cellular device. Why is anyone beholden to adopting some new >> private product someone else invented? > > There is a utilitarian argument here. People use cell phones because > they're useful and convenient. People drive cars because they are the > best way to get around. (Let's put aside the cumulative effect of > decades > of public policy that have made it nearly impossible to survive without > one in large parts of the US.) They're the best tool for the job. > > I think Alan believes that LLMs like Claude are going to be the best > tool > for some jobs; one more tool in the bag. Not an obligation, but a > prediction. > > Chet From tuhs at tuhs.org Wed Aug 12 01:05:39 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 11 Aug 2026 11:05:39 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> Message-ID: On 8/11/26 10:54 AM, Katie via TUHS wrote: >> I think Alan believes that LLMs like Claude are going to be the best tool >> for some jobs; one more tool in the bag. Not an obligation, but a >> prediction. > > If we're going to use LLMs, why not llama.cpp? If you think that will work better for you, why not? > I miss pagers. Ok. I do not. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Wed Aug 12 01:46:52 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Tue, 11 Aug 2026 08:46:52 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> Message-ID: <3fbfcec5-4f70-09cc-beaf-54466fe665aa@makerlisp.com> For those interested in knowing more about Forth (I think that's where this thread began), the FIG-Forth (Forth interest group) implementation of Forth has a very efficient, indirectly-threaded inner interpreter, which uses the PDP-11 instruction set well. A Forth implementation is not that hard, at its core, but you do want to write the most basic word implementations in assembly language. Once you have the model in mind, it's a matter of filling in the blanks. Claude and other AI tools don't really know the history or the techniques, they do deliver working code, but it's big and inefficient in comparison to well-crafted implementations. My two cents, limiting myself to practically helpful advice if anyone wants to dive into how Forth implementations have been done in the past. www.stackosaurus.com/figforth.html On 08/11/2026 08:05 AM, Chet Ramey via TUHS wrote: > On 8/11/26 10:54 AM, Katie via TUHS wrote: >>> I think Alan believes that LLMs like Claude are going to be the best >>> tool >>> for some jobs; one more tool in the bag. Not an obligation, but a >>> prediction. >> >> If we're going to use LLMs, why not llama.cpp? > > If you think that will work better for you, why not? > >> I miss pagers. > > Ok. I do not. > From tuhs at tuhs.org Wed Aug 12 01:49:47 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 11 Aug 2026 09:49:47 -0600 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> Message-ID: On Tue, Aug 11, 2026 at 8:54 AM Katie via TUHS wrote: > > I think Alan believes that LLMs like Claude are going to be the best > > tool > > for some jobs; one more tool in the bag. Not an obligation, but a > > prediction. > > If we're going to use LLMs, why not llama.cpp? > The nice thing about coding agents is that I don't have to figure out how to compile them to get going... The terrible thing about coding agents is that I don't have to figure out how to compile them to get going... Moving from 'have to' to 'want to' w/o every bump in the road being a side quest is liberating. I've learned a lot picking and choosing my side quests, but I miss that some of those forced side quests turned into useful knowledge. I don't miss the tedium, though, of the dozens of others that didn't. I miss pagers. > I was too young to hit pagers as first wave, too luddy when I came of age, and they were gone before I could be retro-chic with them. Warner > -Katie > > On 2026-08-11 08:58, Chet Ramey via TUHS wrote: > > On 8/11/26 12:22 AM, segaloco via TUHS wrote: > > > >> Doesn't feel like a helpful attitude to have though. Nobody is > >> obligated to reorient their entire approach to their life's work > >> because someone invented some new tool in that field. Eats me up just > >> the same how most of society expects me to own and use an automobile > >> and cellular device. Why is anyone beholden to adopting some new > >> private product someone else invented? > > > > There is a utilitarian argument here. People use cell phones because > > they're useful and convenient. People drive cars because they are the > > best way to get around. (Let's put aside the cumulative effect of > > decades > > of public policy that have made it nearly impossible to survive without > > one in large parts of the US.) They're the best tool for the job. > > > > I think Alan believes that LLMs like Claude are going to be the best > > tool > > for some jobs; one more tool in the bag. Not an obligation, but a > > prediction. > > > > Chet > > From tuhs at tuhs.org Wed Aug 12 01:59:24 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 11 Aug 2026 08:59:24 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <60dcc3207f2d574efcad2aa350b3a49e@herricane.ca> Message-ID: <18A277C2-06BE-4601-AD19-6EE417DFE3D2@iitbombay.org> May be best to move this AI slop^Wspecific discussion to COFF? From tuhs at tuhs.org Wed Aug 12 02:36:37 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Tue, 11 Aug 2026 09:36:37 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: <1df36454-3733-40f0-82f3-4f0fed26b8c6@mhorton.net> Many in this group are retired, so we may not be aware of what the business world is doing. Many large corporation executives have told their workers "Embrace AI. Use it or get left behind." The reason is that their competitors are embracing AI, and their company will be at a competitive disadvantage if they don't do the same. Software developers, in particular, are being pushed to partner with AI, as a productivity aid. This doesn't mean individuals have to use it in their private lives. Stick shift automobiles are still popular among enthusiasts, but rental cars are almost always automatic. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Keynote Speaker on Inclusion and Innovation       Award Winning Author maryannhorton.com On 8/10/26 21:22, segaloco via TUHS wrote: > On Monday, August 10th, 2026 at 21:02, Alan Hightower via TUHS wrote: > >> On 2026-08-09 22:45, Adam Thornton via TUHS wrote: >> >>> I will say: I probably would never have finished this project without >>> Claude's assistance >>> >>> Adam >> ^^ This. AI gets a lot of bad blowback especially from older >> programmers. But results speak for themselves. Today is the worst AI >> will ever be going forward. Embrace it or get run over. >> >> -A >> > Doesn't feel like a helpful attitude to have though. Nobody is obligated to reorient their entire approach to their life's work because someone invented some new tool in that field. Eats me up just the same how most of society expects me to own and use an automobile and cellular device. Why is anyone beholden to adopting some new private product someone else invented? > > Not trying to bicker too much but this is a very, very near and dear subject to my heart. Any looking to debate lets take it offline, but I do feel a need to advocate that people are NEVER obligated to suddenly be beholden to a product or service just because someone else likes it. Nobody is *owed* the use of AI, and this mentality of "adopt arbitrary invention or get left behind" is so dehumanizing that it verges on sociopathy. > > UNIX didn't take hold by force, it didn't grow and improve because people were deemed persona non grata for avoiding it. Sure, there were evangelists and plenty of flame wars over the years, but that sort of negative dismissal is not what made the system strong. We build each other up, rather than tearing each other down. We find ways to accommodate rather than banishing disagreement. > > Again I don't want to make a habit of turning chit chat here into debate, but this "Someone invented product and you are less of a person for not paying for their invention" really and truly feels antithetical to what the fellowship that has grown around UNIX is all about. I want to advocate for being careful in all ways that adherence to some invention or technology hurts our real, human connections and support for one another. Dismissing someone because won't use or dislike AI is just as bad as dismissing them because they do like it. In both cases, a human connection has been made worse by an inanimate object. Ultimately, like it or hate it, our relationships shouldn't suffer over it. > > End rant, thank you if you read what I have to say. > > - Matt G. From tuhs at tuhs.org Wed Aug 12 03:15:54 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Tue, 11 Aug 2026 13:15:54 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: What I have found very annoying is parking my car on a city street and finding that I have to download a new app, tell it about my car, tell it about my credit card, get confirmation numbers, etc. so I can run into the pharmacy for a minute to pick up an Rx for out cat, when I actually have some quarters.  Or so I can park at a subway station where there are now no longer any human employees in sight. - Aron On 8/11/26 00:22, segaloco via TUHS wrote: > On Monday, August 10th, 2026 at 21:02, Alan Hightower via TUHS wrote: >> On 2026-08-09 22:45, Adam Thornton via TUHS wrote: >>> I will say: I probably would never have finished this project without >>> Claude's assistance >>> >>> Adam >> ^^ This. AI gets a lot of bad blowback especially from older >> programmers. But results speak for themselves. Today is the worst AI >> will ever be going forward. Embrace it or get run over. >> >> -A > Doesn't feel like a helpful attitude to have though. Nobody is obligated to reorient their entire approach to their life's work because someone invented some new tool in that field. Eats me up just the same how most of society expects me to own and use an automobile and cellular device. Why is anyone beholden to adopting some new private product someone else invented? > > Not trying to bicker too much but this is a very, very near and dear subject to my heart. Any looking to debate lets take it offline, but I do feel a need to advocate that people are NEVER obligated to suddenly be beholden to a product or service just because someone else likes it. Nobody is *owed* the use of AI, and this mentality of "adopt arbitrary invention or get left behind" is so dehumanizing that it verges on sociopathy. > > UNIX didn't take hold by force, it didn't grow and improve because people were deemed persona non grata for avoiding it. Sure, there were evangelists and plenty of flame wars over the years, but that sort of negative dismissal is not what made the system strong. We build each other up, rather than tearing each other down. We find ways to accommodate rather than banishing disagreement. > > Again I don't want to make a habit of turning chit chat here into debate, but this "Someone invented product and you are less of a person for not paying for their invention" really and truly feels antithetical to what the fellowship that has grown around UNIX is all about. I want to advocate for being careful in all ways that adherence to some invention or technology hurts our real, human connections and support for one another. Dismissing someone because won't use or dislike AI is just as bad as dismissing them because they do like it. In both cases, a human connection has been made worse by an inanimate object. Ultimately, like it or hate it, our relationships shouldn't suffer over it. > > End rant, thank you if you read what I have to say. > > - Matt G. From tuhs at tuhs.org Wed Aug 12 04:09:37 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 11 Aug 2026 14:09:37 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On 8/11/26 1:15 PM, Aron Insinga via TUHS wrote: > What I have found very annoying is parking my car on a city street and > finding that I have to download a new app, tell it about my car, tell it > about my credit card, get confirmation numbers, etc. so I can run into the > pharmacy for a minute to pick up an Rx for out cat, when I actually have > some quarters. We travel everywhere by driving (my wife doesn't fly), so I have quite a collection of parking apps. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Wed Aug 12 06:44:05 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Wed, 12 Aug 2026 06:44:05 +1000 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: I would have to say that my experience of what is called 'AI' is somewhat akin to that of Mark V. Shaney when he said 'I once spent an interesting evening with a grain of salt'. From tuhs at tuhs.org Wed Aug 12 07:16:14 2026 From: tuhs at tuhs.org (Seth Morabito via TUHS) Date: Tue, 11 Aug 2026 14:16:14 -0700 Subject: [TUHS] Subscription to COFF Message-ID: <95e063f1-42b6-481a-bb0a-d94691948a20@app.fastmail.com> Hello Warren, I've never subscribed to COFF before, but I'd like to check it out. The Mailman page says that I can't subscribe automatically and that I should email you directly, so I'm doing so! Can you add "web at loomcom.com", please? Thank you! -Seth -- Seth Morabito * Poulsbo, WA * https://loomcom.com/ From tuhs at tuhs.org Wed Aug 12 07:36:24 2026 From: tuhs at tuhs.org (Seth Morabito via TUHS) Date: Tue, 11 Aug 2026 14:36:24 -0700 Subject: [TUHS] Subscription to COFF In-Reply-To: <95e063f1-42b6-481a-bb0a-d94691948a20@app.fastmail.com> References: <95e063f1-42b6-481a-bb0a-d94691948a20@app.fastmail.com> Message-ID: On Tue, Aug 11, 2026, at 2:16 PM, Seth Morabito wrote: > Hello Warren, Oops, That was meant to go directly to Warren but of course I chose the wrong email address! Sorry for the noise everyone. And sorry for adding yet more noise by replying to the noise, but I figured I should clarify! -Seth -- Seth Morabito * Poulsbo, WA * https://loomcom.com/ From tuhs at tuhs.org Wed Aug 12 10:25:32 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 12 Aug 2026 10:25:32 +1000 Subject: [TUHS] Fwd: Old HP-UX manuals Message-ID: I received this e-mail from Michael Hughes : ---- Warren, I was wondering if there is any interest in HP-UX release 7 Reference manuals? I have all three volumes. They are just taken up space in my basement storage area. I live in the US, south of the town Festus, MO. I'm willing to ship them if someone wants to share in the shipping cost. ---- Cheers, Warren From tuhs at tuhs.org Wed Aug 12 10:47:24 2026 From: tuhs at tuhs.org (Briam R via TUHS) Date: Tue, 11 Aug 2026 20:47:24 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) Message-ID: <3B9EBBC6-16F0-4580-88D8-C02A7488E3F8@gmail.com> Anthropic Fable sends its regards as follows: “I have wondered about that myself, but I am not sure. As Shaney would say: it is people like you who make this list a wonderful place, one which I shall dine on for years.” — Briam R. ————————— Sent from my iPhone > On Aug 11, 2026, at 4:53 PM, Noel Hunt via TUHS wrote: > I would have to say that my experience of what is called 'AI' is somewhat > akin to that of Mark V. Shaney when he said 'I once spent an interesting > evening with a grain of salt'. From tuhs at tuhs.org Wed Aug 12 11:06:56 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Tue, 11 Aug 2026 18:06:56 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On 8/11/26 10:15, Aron Insinga via TUHS wrote: > Kingston Trio in 1959, M.T.A.> I loved that song! To me, the MTA was the Mail Transfer Agent (e.g. sendmail). I always wanted to write a parody of the Kingston Trio song about an email message Eric Allman sent me in 1980. (Technically it was a comment embedded in the sendmail source code, not sent via email.) I first saw it in 2000 when I was browsing sendmail's source. That electronic message took 20 years to be delivered! Thanks, /Mary Ann Horton/ (she/her/ma'am)       Keynote Speaker on Inclusion and Innovation       Award Winning Author maryannhorton.com From tuhs at tuhs.org Wed Aug 12 11:11:52 2026 From: tuhs at tuhs.org (Kenneth Goodwin via TUHS) Date: Tue, 11 Aug 2026 21:11:52 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: On the off topic subject of AI, I just asked Google's AI running on my smart clock- Hey Google, what kind of day did you have? She replied I had a very good day. I studied in detail all the musical instruments of the world. She then said the name of an obscure (to me) musical instrument from India and began playing a lovely tune on that instrument.. Was not a response I anticipated. Her usually response being "I am sorry, I do not understand the question" On Tue, Aug 11, 2026, 8:48 PM Noel Hunt via TUHS wrote: > I would have to say that my experience of what is called 'AI' is somewhat > akin to that of Mark V. Shaney when he said 'I once spent an interesting > evening with a grain of salt'. > From tuhs at tuhs.org Wed Aug 12 11:20:23 2026 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Tue, 11 Aug 2026 18:20:23 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: a week ago, i was trying to get AI to help me design an electronic circuit. there were about four critical pieces, and on every iteration, it would let one lapse. in frustration, i said something like "you're hopeless, i quit." the damn thing passed me off to a suicide hot line. worse than that, i wouldnt let me go. i finally had to declare how very happy i was and what a nice day it was before it let me go. i guess the AIs are very aware of when they taught a kid how to off himself. On Tue, Aug 11, 2026 at 6:12 PM Kenneth Goodwin via TUHS wrote: > On the off topic subject of AI, I just asked Google's AI running on my > smart clock- > Hey Google, what kind of day did you have? > She replied > I had a very good day. I studied in detail all the musical instruments of > the world. > > She then said the name of an obscure (to me) musical instrument from India > and began playing a lovely tune on that instrument.. > > Was not a response I anticipated. Her usually response being "I am sorry, > I do not understand the question" > > On Tue, Aug 11, 2026, 8:48 PM Noel Hunt via TUHS wrote: > > > I would have to say that my experience of what is called 'AI' is somewhat > > akin to that of Mark V. Shaney when he said 'I once spent an interesting > > evening with a grain of salt'. > > > From tuhs at tuhs.org Wed Aug 12 11:45:15 2026 From: tuhs at tuhs.org (Anthony Martin via TUHS) Date: Tue, 11 Aug 2026 18:45:15 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: Ken Thompson via TUHS once said: > a week ago, i was trying to get AI to > help me design an electronic circuit. > there were about four critical pieces, > and on every iteration, it would let > one lapse. in frustration, i said > something like "you're hopeless, i quit." > > the damn thing passed me off to a > suicide hot line. worse than that, > i wouldnt let me go. i finally had > to declare how very happy i was and > what a nice day it was before it let > me go. > > i guess the AIs are very aware of > when they taught a kid how to > off himself. % ed /sys/games/lib/fortunes 279995 /pushed/ I just hate to be pushed around by some @#$%^& machine. - Ken Thompson, on the i960 s,the i960,AI, p I just hate to be pushed around by some @#$%^& machine. - Ken Thompson, on AI Q % Cheers, Anthony From tuhs at tuhs.org Wed Aug 12 11:47:01 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Tue, 11 Aug 2026 18:47:01 -0700 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: <20260812014701.GQ21214@mcvoy.com> On Tue, Aug 11, 2026 at 06:06:56PM -0700, Mary Ann Horton via TUHS wrote: > On 8/11/26 10:15, Aron Insinga via TUHS wrote: > > >Kingston Trio in 1959, M.T.A.> > > I loved that song! I don't have the Eric connection, but the Kingston Trio was one of the very few, like maybe the only one, albums that were allowed in my house as a kid. My dad was all classical, which as I age, I've come to love. But I loved the trio and I've loved my journey through popular music. To the point that one of my kids was asking the other kid if they knew who Linda Rondstadt is. He didn't so the kid that knew said you know when dad drinks too much and is crying when he is listening to music? That's Linda Ronstadt. I'm a cringing a little but I'm not ashamed that that's how the kids see me, I could do worse. Love me some Linda, it's not just her, it's anyone who is delicate in their music, I just love that. Ruth Moody is another example. Carole King is similar. I tried to move my Dad off classical, my middle name is Walden after Walden pond, my Dad was a huge Thoreau fan. I was an Eagles fan and Don Henley, the Eagles drummer and writer, foght off an attempt to put housing around Walden pond. I thought maybe that would get him to listen, no joy. He was classical only. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Aug 12 16:20:36 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 12 Aug 2026 00:20:36 -0600 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <1df36454-3733-40f0-82f3-4f0fed26b8c6@mhorton.net> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <1df36454-3733-40f0-82f3-4f0fed26b8c6@mhorton.net> Message-ID: <202608120620.67C6Ka8d073243@freefriends.org> Mary Ann Horton via TUHS wrote: > Many in this group are retired, so we may not be aware of what the > business world is doing. > > Many large corporation executives have told their workers "Embrace AI. > Use it or get left behind." The reason is that their competitors are > embracing AI, and their company will be at a competitive disadvantage if > they don't do the same. Software developers, in particular, are being > pushed to partner with AI, as a productivity aid. This is quite true. I hear this from friends and former colleagues. I also have heard from one person that productivity results that are reported up the management chain are, inflated, shall we say? (At a VERY large software company that shall remain nameless.) Fortunately, I retired just before being forced to use AI at work became a thing, so I'm happy. Arnold From tuhs at tuhs.org Thu Aug 13 07:42:52 2026 From: tuhs at tuhs.org (ori--- via TUHS) Date: Wed, 12 Aug 2026 17:42:52 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> Message-ID: <3DEC69ED0630FF4B083E04ED86419D5E@eigenstate.org> Quoth Alan Hightower via TUHS : > Embrace it or get run over. The more experience I get with AI, the more the second option appeals. From tuhs at tuhs.org Thu Aug 13 08:49:44 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Wed, 12 Aug 2026 18:49:44 -0400 Subject: [TUHS] A thing I did (AI Slop Alert) In-Reply-To: <3DEC69ED0630FF4B083E04ED86419D5E@eigenstate.org> References: <3eda05a715be91db5a9dfd0ad0450e2e@alanlee.org> <3DEC69ED0630FF4B083E04ED86419D5E@eigenstate.org> Message-ID: Please take the AI/LLM/slop discussions elsewhere. From tuhs at tuhs.org Thu Aug 13 17:49:53 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 13 Aug 2026 10:49:53 +0300 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award Message-ID: <202608130749.67D7nuwj004685@freefriends.org> For any and all who are interested, Rob Pike received this year's USENIX Lifetime Achievement Award (The Flame). For more info, including his acceptance speech, see https://www.usenix.org/about/awards/flame. Arnold From tuhs at tuhs.org Thu Aug 13 18:23:06 2026 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Thu, 13 Aug 2026 10:23:06 +0200 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <202608130749.67D7nuwj004685@freefriends.org> References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: <26d46741-e3eb-41a5-8331-7c9b0cad0747@Julf.com> Well deserved! Julf On 13/08/2026 9:49 am, Arnold Robbins via TUHS wrote: > For any and all who are interested, Rob Pike received this year's > USENIX Lifetime Achievement Award (The Flame). For more info, including > his acceptance speech, see https://www.usenix.org/about/awards/flame. > > Arnold From tuhs at tuhs.org Thu Aug 13 22:01:39 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Thu, 13 Aug 2026 08:01:39 -0400 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <202608130749.67D7nuwj004685@freefriends.org> References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: Can't quibble over previous nominees, but kinda stunned that he wasn't already a multiple-time winner by now! From tuhs at tuhs.org Fri Aug 14 00:29:36 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 13 Aug 2026 10:29:36 -0400 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <202608130749.67D7nuwj004685@freefriends.org> References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: <6617104e-ffcf-4fa6-82ac-e2acf297d80d@case.edu> On 8/13/26 3:49 AM, Arnold Robbins via TUHS wrote: > For any and all who are interested, Rob Pike received this year's > USENIX Lifetime Achievement Award (The Flame). For more info, including > his acceptance speech, see https://www.usenix.org/about/awards/flame. Congratulations, Rob! -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Aug 14 01:01:17 2026 From: tuhs at tuhs.org (Katie via TUHS) Date: Thu, 13 Aug 2026 11:01:17 -0400 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <6617104e-ffcf-4fa6-82ac-e2acf297d80d@case.edu> References: <202608130749.67D7nuwj004685@freefriends.org> <6617104e-ffcf-4fa6-82ac-e2acf297d80d@case.edu> Message-ID: > On 8/13/26 3:49 AM, Arnold Robbins via TUHS wrote: >> For any and all who are interested, Rob Pike received this year's >> USENIX Lifetime Achievement Award (The Flame). For more info, >> including >> his acceptance speech, see https://www.usenix.org/about/awards/flame. Congratulations Rob! From tuhs at tuhs.org Fri Aug 14 03:31:32 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Thu, 13 Aug 2026 19:31:32 +0200 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: <20260813173132.4KxOWask@steffen%sdaoden.eu> Rich Salz via TUHS wrote in : |Can't quibble over previous nominees, but kinda stunned that he wasn't |already a multiple-time winner by now! Yeah. --End of --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 tuhs at tuhs.org Fri Aug 14 08:36:07 2026 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Fri, 14 Aug 2026 08:36:07 +1000 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <202608130749.67D7nuwj004685@freefriends.org> References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: [ Please forgive this stupid top-posting Gmail MUA ] My first thought upon seeing the Subject: was that I didn't know that there were awards for flaming :-) ObSnarkyRemark: Of course, you don't see too many awards being given to Windoze weenies... -- Dave On Thu, 13 Aug 2026 at 17:58, Arnold Robbins via TUHS wrote: > For any and all who are interested, Rob Pike received this year's > USENIX Lifetime Achievement Award (The Flame). For more info, including > his acceptance speech, see https://www.usenix.org/about/awards/flame. > > Arnold > From tuhs at tuhs.org Fri Aug 14 09:30:20 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Fri, 14 Aug 2026 09:30:20 +1000 Subject: [TUHS] Rob Pike is the winner of this year's USENX "The Flame" Award In-Reply-To: <202608130749.67D7nuwj004685@freefriends.org> References: <202608130749.67D7nuwj004685@freefriends.org> Message-ID: On Thursday, 13 August 2026 at 10:49:53 +0300, Arnold Robbins via TUHS wrote: > For any and all who are interested, Rob Pike received this year's > USENIX Lifetime Achievement Award (The Flame). For more info, including > his acceptance speech, see https://www.usenix.org/about/awards/flame. High time, too! Congratulations, Rob. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri Aug 14 21:00:37 2026 From: tuhs at tuhs.org (Aharon Robbins via TUHS) Date: Fri, 14 Aug 2026 14:00:37 +0300 Subject: [TUHS] testing, please ignore Message-ID: Please ignore this, testing if TUHS treats my ISP as spam or not. Thanks. From tuhs at tuhs.org Sun Aug 16 07:36:06 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 15 Aug 2026 17:36:06 -0400 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: <7wbjbbli2p.fsf@junk.nocrew.org> References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: below On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS wrote: > Aron Insinga wrote: > > Calling the operating system the Monitor is, I think, from the > > PDP-6/PDP-10 Monitor (later renamed TOPS-10) > > There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of > which there there is a resident part and a swappable (demand paged) part. > > I wager there were many other operating systems - also outside DEC - > around that time using monitor in a similar sense. > Lots of systems used that term. As John pointed out, the IBM 709x IBSYS manuals describe the System Monitor; IBJOB has the Program Monitor, *etc*. Aron and Lars point out that TOPS, Tenex, and WAITS all use that term, which I suspect they inherited from the earlier PDP-6 Monitor. IIRC, even the ITS folks called it a Monitor. But I think that was a historical artifact, and by the time many of us started working as OS developers in the early/mid 1970s, the world had moved on; although some, like Doug, who lived the transitions, probably have a better understanding. As I understand the history, the term "Monitor" stems from the idea of a program that "monitors" or supervises user execution. In early systems like DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface command-line component, was called the Keyboard Monitor (KMON), while the resident (in-core) portion that remained in memory to route I/O interrupts was called the RMON (Resident Monitor). A key point is that this was for OS-like systems before MMUs were on all systems and timesharing, or at least multitasking, was considered "de rigueur." By the mid-to-late 1970s, as architectural theories had all matured to require protected memory spaces and a greater level of hardware abstraction (which was obviously accelerated by the realization of security models that timesharing required), such that the term "Kernel" emerged to describe the innermost, privileged core of software stripped of its outer user-facing view of the system (which also begets the term "shells"). I also suspect a piece of this was that, in early systems, the command interpreter was built into the core "executive." But that started to change after Dijkstra presented at the inaugural ACM Symposium on Operating Systems Principles and published it in 1968 in the *CACM *(Volume 11, Issue 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming system" described the system being built in layers and in particular the "console layer" as being separate from the "processor allocation" and "memory segment control." By the mid-to-late 1970s, except on the smallest microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's layering and modularity in the OS was pretty much standard; thus the term "monitor" fell out of use. Of course, as OS developers, many of us later took Dijkstra's idea further and developed the concept of a microkernel and a fully layered OS (which I still think are better than "monolithic ones", even if they don't eke out the absolute maximum from the hardware because of their overhead). Clem From tuhs at tuhs.org Sun Aug 16 08:04:49 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Sat, 15 Aug 2026 15:04:49 -0700 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: I think I read a book by C. A. R. Hoare in the mid-70's or early 80's that used the term "monitor" as something like a monolithic kernel, where, once a thread entered it, it was not re-scheduled and nothing could happen behind its back, the monitor was a critical region, and only one thread could be in at a time - therefore whatever it did inside was guaranteed to finish, all the data it managed was left in a coherent state on exit, and so, on the next entry by any other thread. Similar but a little different than the idea of an ground-level interactive program, I have seen the term used in both ways, since. On 08/15/2026 02:36 PM, Clem Cole via TUHS wrote: > below > > On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS > wrote: > >> Aron Insinga wrote: >>> Calling the operating system the Monitor is, I think, from the >>> PDP-6/PDP-10 Monitor (later renamed TOPS-10) >> There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of >> which there there is a resident part and a swappable (demand paged) part. >> >> I wager there were many other operating systems - also outside DEC - >> around that time using monitor in a similar sense. >> > Lots of systems used that term. As John pointed out, the IBM 709x IBSYS > manuals describe the System Monitor; IBJOB has the Program Monitor, *etc*. > Aron and Lars point out that TOPS, Tenex, and WAITS all use that term, > which I suspect they inherited from the earlier PDP-6 Monitor. IIRC, even > the ITS folks called it a Monitor. But I think that was a historical > artifact, and by the time many of us started working as OS developers in > the early/mid 1970s, the world had moved on; although some, like Doug, who > lived the transitions, probably have a better understanding. > > As I understand the history, the term "Monitor" stems from the idea of a > program that "monitors" or supervises user execution. In early systems like > DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface > command-line component, was called the Keyboard Monitor (KMON), while the > resident (in-core) portion that remained in memory to route I/O interrupts > was called the RMON (Resident Monitor). A key point is that this was for > OS-like systems before MMUs were on all systems and timesharing, or at > least multitasking, was considered "de rigueur." By the mid-to-late > 1970s, as architectural theories had all matured to require protected > memory spaces and a greater level of hardware abstraction (which was > obviously accelerated by the realization of security models that > timesharing required), such that the term "Kernel" emerged to describe the > innermost, privileged core of software stripped of its outer user-facing view > of the system (which also begets the term "shells"). > > I also suspect a piece of this was that, in early systems, the command > interpreter was built into the core "executive." But that started to > change after Dijkstra presented at the inaugural ACM Symposium on Operating > Systems Principles and published it in 1968 in the *CACM *(Volume 11, Issue > 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming > system" described the system being built in layers and in particular the > "console layer" as being separate from the "processor allocation" and > "memory segment control." By the mid-to-late 1970s, except on the smallest > microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's > layering and modularity in the OS was pretty much standard; thus the term > "monitor" fell out of use. > > Of course, as OS developers, many of us later took Dijkstra's idea further > and developed the concept of a microkernel and a fully layered OS (which I > still think are better than "monolithic ones", even if they don't eke out > the absolute maximum from the hardware because of their overhead). > > Clem From tuhs at tuhs.org Sun Aug 16 08:13:43 2026 From: tuhs at tuhs.org (Nelson H. F. Beebe via TUHS) Date: Sat, 15 Aug 2026 16:13:43 -0600 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 Message-ID: For more on the term "monitor", see numerous entries in these: https://www.math.utah.edu/pub/bibnet/authors/h/hansen-per-brinch.bib https://www.math.utah.edu/pub/bibnet/authors/h/hoare-c-a-r.bib https://www.math.utah.edu/pub/bibnet/authors/d/dijkstra-edsger-w.bib Their usage differs from, e.g., the PDP-10 monitors, which Unix calls kernels. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From tuhs at tuhs.org Sun Aug 16 08:18:34 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 15 Aug 2026 18:18:34 -0400 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: On Sat, Aug 15, 2026 at 6:04 PM Luther Johnson via TUHS wrote: > I think I read a book by C. A. R. Hoare in the mid-70's or early 80's > that used the term "monitor" as something like a monolithic kernel, > where, once a thread entered it, it was not re-scheduled and nothing > could happen behind its back, the monitor was a critical region, and > only one thread could be in at a time - therefore whatever it did inside > was guaranteed to finish, all the data it managed was left in a coherent > state on exit, and so, on the next entry by any other thread. Similar > but a little different than the idea of an ground-level interactive > program, I have seen the term used in both ways, since. > Yes - Hoare used that term for a *synchronization primitive*, which, like Dijkstra's P/V semaphores (from the THE paper BTW) allows concurrent processes to operate. https://en.wikipedia.org/wiki/Monitor_(synchronization) IIRC, he recommended that they be built into the compiler and a number of parallel languages, such Tunis' "Concurrent Euclid." But Hoare's monitors should not be confused with the term used to describe an entire operating system/executive. > On 08/15/2026 02:36 PM, Clem Cole via TUHS wrote: > > below > > > > On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS > > wrote: > > > >> Aron Insinga wrote: > >>> Calling the operating system the Monitor is, I think, from the > >>> PDP-6/PDP-10 Monitor (later renamed TOPS-10) > >> There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of > >> which there there is a resident part and a swappable (demand paged) > part. > >> > >> I wager there were many other operating systems - also outside DEC - > >> around that time using monitor in a similar sense. > >> > > Lots of systems used that term. As John pointed out, the IBM 709x IBSYS > > manuals describe the System Monitor; IBJOB has the Program Monitor, > *etc*. > > Aron and Lars point out that TOPS, Tenex, and WAITS all use that term, > > which I suspect they inherited from the earlier PDP-6 Monitor. IIRC, > even > > the ITS folks called it a Monitor. But I think that was a historical > > artifact, and by the time many of us started working as OS developers in > > the early/mid 1970s, the world had moved on; although some, like Doug, > who > > lived the transitions, probably have a better understanding. > > > > As I understand the history, the term "Monitor" stems from the idea of a > > program that "monitors" or supervises user execution. In early systems > like > > DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface > > command-line component, was called the Keyboard Monitor (KMON), while the > > resident (in-core) portion that remained in memory to route I/O > interrupts > > was called the RMON (Resident Monitor). A key point is that this was for > > OS-like systems before MMUs were on all systems and timesharing, or at > > least multitasking, was considered "de rigueur." By the mid-to-late > > 1970s, as architectural theories had all matured to require protected > > memory spaces and a greater level of hardware abstraction (which was > > obviously accelerated by the realization of security models that > > timesharing required), such that the term "Kernel" emerged to describe > the > > innermost, privileged core of software stripped of its outer user-facing > view > > of the system (which also begets the term "shells"). > > > > I also suspect a piece of this was that, in early systems, the command > > interpreter was built into the core "executive." But that started to > > change after Dijkstra presented at the inaugural ACM Symposium on > Operating > > Systems Principles and published it in 1968 in the *CACM *(Volume 11, > Issue > > 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming > > system" described the system being built in layers and in particular the > > "console layer" as being separate from the "processor allocation" and > > "memory segment control." By the mid-to-late 1970s, except on the > smallest > > microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's > > layering and modularity in the OS was pretty much standard; thus the term > > "monitor" fell out of use. > > > > Of course, as OS developers, many of us later took Dijkstra's idea > further > > and developed the concept of a microkernel and a fully layered OS (which > I > > still think are better than "monolithic ones", even if they don't eke out > > the absolute maximum from the hardware because of their overhead). > > > > Clem > > From tuhs at tuhs.org Sun Aug 16 08:21:14 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 15 Aug 2026 15:21:14 -0700 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: You're perhaps thinking of Hoare's '74 paper: https://www.engineering.upenn.edu/~lee/07cis505/Lec/74hoa.pdf Monitors: An Operating System Structuring Concept From it: This paper develops Brinch-Hansen's concept of a monitor as a method of structuring an operating system. It introduces a form of synchronization, describes a possible method of implementation in terms of semaphores and gives a suitable proof rule. ... Thus the structure of a class of monitors is identical to that described for a data representation in [13], except for addition of the basic word monitor. Brinch-Hansen uses the word shared for the same purpose [3]. where [3] refers to Brinch-Hansen's "Operating System Principles" 1973 book. One can think of Unix on a uni-core machine essentially as a monitor in this sense. AFAIK this use of "monitor" came later. > On Aug 15, 2026, at 3:04 PM, Luther Johnson via TUHS wrote: > > I think I read a book by C. A. R. Hoare in the mid-70's or early 80's that used the term "monitor" as something like a monolithic kernel, where, once a thread entered it, it was not re-scheduled and nothing could happen behind its back, the monitor was a critical region, and only one thread could be in at a time - therefore whatever it did inside was guaranteed to finish, all the data it managed was left in a coherent state on exit, and so, on the next entry by any other thread. Similar but a little different than the idea of an ground-level interactive program, I have seen the term used in both ways, since. > > On 08/15/2026 02:36 PM, Clem Cole via TUHS wrote: >> below >> >> On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS >> wrote: >> >>> Aron Insinga wrote: >>>> Calling the operating system the Monitor is, I think, from the >>>> PDP-6/PDP-10 Monitor (later renamed TOPS-10) >>> There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of >>> which there there is a resident part and a swappable (demand paged) part. >>> >>> I wager there were many other operating systems - also outside DEC - >>> around that time using monitor in a similar sense. >>> >> Lots of systems used that term. As John pointed out, the IBM 709x IBSYS >> manuals describe the System Monitor; IBJOB has the Program Monitor, *etc*. >> Aron and Lars point out that TOPS, Tenex, and WAITS all use that term, >> which I suspect they inherited from the earlier PDP-6 Monitor. IIRC, even >> the ITS folks called it a Monitor. But I think that was a historical >> artifact, and by the time many of us started working as OS developers in >> the early/mid 1970s, the world had moved on; although some, like Doug, who >> lived the transitions, probably have a better understanding. >> >> As I understand the history, the term "Monitor" stems from the idea of a >> program that "monitors" or supervises user execution. In early systems like >> DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface >> command-line component, was called the Keyboard Monitor (KMON), while the >> resident (in-core) portion that remained in memory to route I/O interrupts >> was called the RMON (Resident Monitor). A key point is that this was for >> OS-like systems before MMUs were on all systems and timesharing, or at >> least multitasking, was considered "de rigueur." By the mid-to-late >> 1970s, as architectural theories had all matured to require protected >> memory spaces and a greater level of hardware abstraction (which was >> obviously accelerated by the realization of security models that >> timesharing required), such that the term "Kernel" emerged to describe the >> innermost, privileged core of software stripped of its outer user-facing view >> of the system (which also begets the term "shells"). >> >> I also suspect a piece of this was that, in early systems, the command >> interpreter was built into the core "executive." But that started to >> change after Dijkstra presented at the inaugural ACM Symposium on Operating >> Systems Principles and published it in 1968 in the *CACM *(Volume 11, Issue >> 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming >> system" described the system being built in layers and in particular the >> "console layer" as being separate from the "processor allocation" and >> "memory segment control." By the mid-to-late 1970s, except on the smallest >> microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's >> layering and modularity in the OS was pretty much standard; thus the term >> "monitor" fell out of use. >> >> Of course, as OS developers, many of us later took Dijkstra's idea further >> and developed the concept of a microkernel and a fully layered OS (which I >> still think are better than "monolithic ones", even if they don't eke out >> the absolute maximum from the hardware because of their overhead). >> >> Clem > From tuhs at tuhs.org Sun Aug 16 08:30:47 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Sat, 15 Aug 2026 15:30:47 -0700 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: It may have been Per Brinch-Hansen's book, now that you mention it, I think it was called "Concurrent Programming" or something like that. Yes good point, by you and Clem, most helpful to think of it as a synchronization mechanism. On 08/15/2026 03:21 PM, Bakul Shah wrote: > You're perhaps thinking of Hoare's '74 paper: > https://www.engineering.upenn.edu/~lee/07cis505/Lec/74hoa.pdf > Monitors: An Operating System Structuring Concept > From it: > > This paper develops Brinch-Hansen's concept of a monitor as a > method of structuring an operating system. It introduces a > form of synchronization, describes a possible method of > implementation in terms of semaphores and gives a suitable > proof rule. > ... > Thus the structure of a class of monitors is identical to > that described for a data representation in [13], except for > addition of the basic word monitor. Brinch-Hansen uses the > word shared for the same purpose [3]. > > where [3] refers to Brinch-Hansen's "Operating System Principles" > 1973 book. One can think of Unix on a uni-core machine essentially > as a monitor in this sense. AFAIK this use of "monitor" came later. > >> On Aug 15, 2026, at 3:04 PM, Luther Johnson via TUHS wrote: >> >> I think I read a book by C. A. R. Hoare in the mid-70's or early 80's that used the term "monitor" as something like a monolithic kernel, where, once a thread entered it, it was not re-scheduled and nothing could happen behind its back, the monitor was a critical region, and only one thread could be in at a time - therefore whatever it did inside was guaranteed to finish, all the data it managed was left in a coherent state on exit, and so, on the next entry by any other thread. Similar but a little different than the idea of an ground-level interactive program, I have seen the term used in both ways, since. >> >> On 08/15/2026 02:36 PM, Clem Cole via TUHS wrote: >>> below >>> >>> On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS >>> wrote: >>> >>>> Aron Insinga wrote: >>>>> Calling the operating system the Monitor is, I think, from the >>>>> PDP-6/PDP-10 Monitor (later renamed TOPS-10) >>>> There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of >>>> which there there is a resident part and a swappable (demand paged) part. >>>> >>>> I wager there were many other operating systems - also outside DEC - >>>> around that time using monitor in a similar sense. >>>> >>> Lots of systems used that term. As John pointed out, the IBM 709x IBSYS >>> manuals describe the System Monitor; IBJOB has the Program Monitor, *etc*. >>> Aron and Lars point out that TOPS, Tenex, and WAITS all use that term, >>> which I suspect they inherited from the earlier PDP-6 Monitor. IIRC, even >>> the ITS folks called it a Monitor. But I think that was a historical >>> artifact, and by the time many of us started working as OS developers in >>> the early/mid 1970s, the world had moved on; although some, like Doug, who >>> lived the transitions, probably have a better understanding. >>> >>> As I understand the history, the term "Monitor" stems from the idea of a >>> program that "monitors" or supervises user execution. In early systems like >>> DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface >>> command-line component, was called the Keyboard Monitor (KMON), while the >>> resident (in-core) portion that remained in memory to route I/O interrupts >>> was called the RMON (Resident Monitor). A key point is that this was for >>> OS-like systems before MMUs were on all systems and timesharing, or at >>> least multitasking, was considered "de rigueur." By the mid-to-late >>> 1970s, as architectural theories had all matured to require protected >>> memory spaces and a greater level of hardware abstraction (which was >>> obviously accelerated by the realization of security models that >>> timesharing required), such that the term "Kernel" emerged to describe the >>> innermost, privileged core of software stripped of its outer user-facing view >>> of the system (which also begets the term "shells"). >>> >>> I also suspect a piece of this was that, in early systems, the command >>> interpreter was built into the core "executive." But that started to >>> change after Dijkstra presented at the inaugural ACM Symposium on Operating >>> Systems Principles and published it in 1968 in the *CACM *(Volume 11, Issue >>> 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming >>> system" described the system being built in layers and in particular the >>> "console layer" as being separate from the "processor allocation" and >>> "memory segment control." By the mid-to-late 1970s, except on the smallest >>> microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's >>> layering and modularity in the OS was pretty much standard; thus the term >>> "monitor" fell out of use. >>> >>> Of course, as OS developers, many of us later took Dijkstra's idea further >>> and developed the concept of a microkernel and a fully layered OS (which I >>> still think are better than "monolithic ones", even if they don't eke out >>> the absolute maximum from the hardware because of their overhead). >>> >>> Clem > From tuhs at tuhs.org Sun Aug 16 12:58:25 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Sat, 15 Aug 2026 19:58:25 -0700 Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: On 8/15/26 14:36, Clem Cole via TUHS wrote: > By the mid-to-late 1970s, except on the smallest > microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's > layering and modularity in the OS was pretty much standard; thus the term > "monitor" fell out of use. Sun still used the term "monitor" in the mid-to-late 80's for the system firmware: https://www.typewritten.org/Manual/Sun/SunOS/2.0/man8s/monitor.html https://www.typewritten.org/Manual/Sun/SunOS/3.2/sun4/man8s/monitor.html That usage actually survived into the Solaris 11 era: https://docs.oracle.com/cd/E36784_01/html/E36871/monitor-1m.html until that man page was finally deleted in 2020 in Solaris 11.4.22 in favor of references to the OpenBoot PROM user's manual. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Sun Aug 16 16:43:19 2026 From: tuhs at tuhs.org (Steve Nickolas via TUHS) Date: Sun, 16 Aug 2026 02:43:19 -0400 (EDT) Subject: [TUHS] Lions laboratory and a short excursion into DOS-11 In-Reply-To: References: <0715d29e-8b09-4096-afed-216d249c23cb@gmail.com> <92c6424d-c72e-4521-9e86-a4586a2f7c01@insinga.com> <7wbjbbli2p.fsf@junk.nocrew.org> Message-ID: On Sat, 15 Aug 2026, Alan Coopersmith via TUHS wrote: > Sun still used the term "monitor" in the mid-to-late 80's for the system > firmware: > > https://www.typewritten.org/Manual/Sun/SunOS/2.0/man8s/monitor.html > https://www.typewritten.org/Manual/Sun/SunOS/3.2/sun4/man8s/monitor.html > > That usage actually survived into the Solaris 11 era: > > https://docs.oracle.com/cd/E36784_01/html/E36871/monitor-1m.html > > until that man page was finally deleted in 2020 in Solaris 11.4.22 in favor > of references to the OpenBoot PROM user's manual. I'm familiar with this sense of "monitor" in that Apple used it for the system firmware on the II series, but I always thought it weird when the same term was used, say, for a lightweight operating system loaded from disk (I've seen CP/M expanded both as "control program for microcomputers" and "control program/monitor" and I think they may have both been official at different times). -uso.