From kevin.bowling at kev009.com Thu Dec 1 16:10:15 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 30 Nov 2022 23:10:15 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: On Mon, Nov 28, 2022 at 6:51 PM Alan Glasser wrote: > A few 3B2 stories... > > In the late 1970's there were no 3B2's (yet), but there was the MAC 8 > processor. The name "MAC 8" was problematic to me and my coworkers: it > stood for Microprocessor Advisory Committee. It was a processor designed > by a committee! It was slow and more problematically, it was not hardware > compatible with Intel 8080 support chips. I don't remember all of the > details but it was an edge versus level set of problems. It was fun to > program. There was an evaluation box (called a MacTutor) that you > connected to an RS-232 line to connect it with a PDP-11 UNIX system for > cross-assembly/cross-compiling (the assembler language was as close to C as > an assembler language could get). The MacTutor was a fun toy. The MAC 8 > in production hardware (at least in Holmdel) was a disaster. See > https://archive.org/details/bitsavers_westernEleC8TUTORJul79_3968770/mode/2up > > In the early 1980's, I was a Bell Labs technical supervisor in a number of > different development (in contrast to research) organizations. There was > considerable pressure on my management (and me) to utilize 3B2's instead of > DEC hardware; a little later (about 1986) there was pressure to use 6300's > and later 6386's (which ran UNIX). > > My first experience with an original 3B2 (one without a model number) was > identical to that of John P Linderman's. Compiling a modest C program took > forever. A little later they gave that one a model number of 300 and came > out with a 400, which was almost reasonable and a 310 which, I believe, had > the same processor and clock as a 400 with less expansion slots. Later came > the 600 and 700, which were pretty reasonable and we used them for a number > of products (DEFINITY Manager 3 for administering a large PBX was one I > brought to market with my team). > There’s a 600G model that was used in large quantities by the US Government (DoD). The later models (600 to 1000) support multiple processors. I find these later machines fairly interesting but can see how the market would have been set for Sun and DEC. And then there were a couple 11xx models with MIPS CPUs.. > In October, 1996 I was promoted to development department head of Global > Messaging Services (GMS) which was better known as AT&T Mail. It was a > hectic time to be joining the organization as the job I took had been being > filled temporarily by another person (who was a friend of mine and, like > me, was new to the organization) and they were in the final throes of > development of a significant new release, about to go into system test (in > another department). One of the first things I learned is that the service > ran on many 3b2/600's mostly in two locations in the US, but had many small > worldwide locations (Hong Kong, Tokyo, Sydney, Tel Aviv, London, Moscow, > and some others I don't remember) all connected by DataKit. The US systems > had been running for many years and could not be powered off, because the > disk drives would seize and not spin up due to an absence of lubricant (as > I was told). This presented some challenges, as I liked to power cycle > systems I worked on and could not do this here. The release was deployed > on Valentine's Day, 1997. It was the worst deployment in the service's > history. Most everything broke. System test hadn't found these very many > latent bugs that were deployed. It was all hands on deck, working all > hours 7x24 with two conference calls a day with the Operations organization > (running the servers) and the Customer Care organization (fielding customer > complaints) until things quieted down towards the end of March. > > It was then that I was able to pay more attention to future plans, which > were to replace the 3B2's with Stratus hardware running their fault > tolerant unix (FTX). We had a number of their dual processor systems in > lab test and had just taken delivery of a four processor system, which is > what my predecessor had specified for purchase to replace all of the US > based 3B2's. A group of 3 engineers (one of whom I had hired in 1980) > worked on running benchmarks of GMS workloads on the Stratus systems and > working with Stratus engineers to get fixes to problems in their code when > they arose. They presented the first set of quad processor benchmarks to > me and they were all slower than the "twin" (or 2 processor) benchmarks. I > requested daily updates on the status of this as it was bizarre and indeed > a disaster for our plans. This culminated in my requesting that Stratus > send a small group of their FTX engineers to my location for (what I > called) a formal architecture review of the Quad and FTX. The review was > scheduled for a week. After the first morning, I told them that they > should go back to Stratus and that we'd be in touch. I wrote the following > in an email to my boss, my product manager peer and a handful of others: > > > Yesterday, 4/15/97, Stratus engineers from their hardware development, FTX > (UNIX) development and performance and design groups met with members of > GMS R&D and AT&T Labs to share information about the Stratus and GMS > architectures. > > > Executive summary: the Quad will never work for GMS. > > > The Stratus 1225 (aka "Twin"), is a true SMP (symmetric multi-processor). > The two CPUs each have a one megabyte instruction cache and a one megabyte > data cache, and they both share a memory system of 512 megabytes. Cache > coherency is maintained by a pair of custom chips (ASICs). When data is in > a processor's cache, there is no contention possible. When data is in > the memory system, there is an additional penalty of between 250-390 > nanoseconds. Input and output take place on a slower bus. > > > The Stratus 1245 (aka "Quad") consists of two twin boards that communicate > via the I/O (i.e., slow) bus. This is not symmetric, hence not SMP. Each > board contains 512MB of memory. All of the Unix kernel data resides on > one board (the boot board). When a processor on the non-boot board needs > to access memory on the boot board, the cost is 1700 nanoseconds (a penalty > of 4.4 to 6.8 times worse). > > > Since all Unix kernel data resides on the boot board, any software that > makes significant use of Unix system calls (e.g., GMS) will pay a high > penalty when running on the non-boot board. Further, if a program (e.g., > the GMS User Agent) is simultaneously running on both boards, its > instructions will reside in the memory of only one of the boards, thus > incurring significant overhead to access instructions for some processes. > > > It appears that the hardware designers never consulted with the Unix > designers. They are located in different locations (Massachusetts and > California), which can't help. They claim they've seen between 1.4 and > 1.6 times improvement in going from Twin to Quad for other customers. They > do note, however, that an optimal application for the Quad is > > one which needs to execute application user-mode instructions and make > very few system calls (e.g., a graphics rendering application). GMS, in > its current architecture, assumes free and easy access to system calls. GMS > can never run well on a Quad. > > > We should immediately abandon any efforts aimed at deploying Quads and > focus all of our attention on extracting compensatory Twins from Stratus. > > > Needless to say, we were able to get an appropriate number of Twins and > retired all of our 3B2s. > > Alan > > > > > > On Mon, Nov 28, 2022 at 5:45 PM Marc Donner wrote: > >> IBM built a major semiconductor fab up in Fishkill, NY. About two hours >> drive north of NYC. At one point (mid-1980s) it was the biggest fab in the >> world according to some metric. >> >> On Mon, Nov 28, 2022, 17:35 ron minnich wrote: >> >>> I was visiting Holmdel in 1981, and there was a tradeshow for the >>> BellMAC CPUs there, filling ground floor of the central atrium. There was >>> some swag, which I had for a few years, including refrigerator magnets. The >>> one I remember: >>> "Don't be alone, call MACphone!" >>> >>> I remember reading an article in the early 80s pointing out that, due to >>> the scale of the Bell System, the center of the universe of semiconductor >>> fabrication at that time was ... Allentown, PA. Western Electric had an ad, >>> along the lines of, "who will create the 256 Kb memory part? WE will" -- WE >>> as in Western Electric.Those parts would have been fabbed in Allentown >>> IIRC. >>> >>> It is a bit hard to recall, much less believe. but PA, land of dead >>> still mills, the Molly Maguires, and underground coal mine fires that will >>> burn for centuries, also had silicon. >>> >>> >>> >>> >>> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin < >>> kennethgoodwin56 at gmail.com> wrote: >>> >>>> That must be the 300 B superhive model CPU >>>> >>>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran >>>> wrote: >>>> >>>>> I have a 3b2/300. Anytime you run a command that is compute bound, >>>>> like factoring a large prime number, the CPU buzzes! >>>>> >>>>> >>>>> >>>>> Bill Corcoran >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 27, 2022, at 9:52 AM, John P. Linderman >>>>> wrote: >>>>> >>>>>  >>>>> >>>>> [EXTERNAL] >>>>> >>>>> >>>>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" >>>>> command in single user mode, and it took 20 seconds to run. >>>>> Our machine names were themed around bird names, so we christened the >>>>> 3B2 "junco". Our director said we had to get along, >>>>> so we renamed it "jay". But everyone knew what the J stood for. The >>>>> 3B2 served as a doorstop. >>>>> >>>>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: >>>>> >>>>>> Larry McVoy wrote: >>>>>> > I read the Wikipedia page on the 9000. It's sad that the 9000 >>>>>> > wasn't cancelled when they had better alternatives. >>>>>> >>>>>> In an oral history Bob Supnik described Ken Olsen couldn't get his >>>>>> head around the fact that the NVAX chip could equal the 9000: >>>>>> >>>>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>>>> >>>>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier >>>>>> predicted when the microprocessor performance curve would cross over >>>>>> minis and mainframes: >>>>>> >>>>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>>>> >>>>>> He also talks about how the company couldn't command the bsame gross >>>>>> margins as it did in the VAX era. >>>>>> >>>>> >>>>> >>>>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE >>>>> of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING >>>>> THIS EMAIL. >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Thu Dec 1 18:30:52 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 1 Dec 2022 00:30:52 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> i was working at building 5 at murray hill in system V development land when the first 3B20 arrived. the first order of business? running off to the local Sears store to buy 4 car batteries so it could power up. what a hoot! From arnold at skeeve.com Thu Dec 1 18:53:24 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 01 Dec 2022 01:53:24 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> Message-ID: <202212010853.2B18rOI8007094@freefriends.org> Andrew Hume wrote: > i was working at building 5 at murray hill in system V development land > when the first 3B20 arrived. the first order of business? running off to the > local Sears store to buy 4 car batteries so it could power up. what a hoot! So what did the 3B20s run when they were being used in a Telco? Unix? Or some other specialized OS? Or was said 3B20 a prototype before they'd been deployed to the Telcos? Thanks, Arnold From fariborz.t at gmail.com Thu Dec 1 19:19:13 2022 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Thu, 1 Dec 2022 01:19:13 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <202212010853.2B18rOI8007094@freefriends.org> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> <202212010853.2B18rOI8007094@freefriends.org> Message-ID: 3B20D's that were used for cellular switches used DMERT. I worked for McCaw Cellular (Cellular One) in mid-late 80's. They had several AT&T switches. The monitoring and management system at the NOC in Seattle was developed by BL (I think it was Indian Hill). It was called MFOS and ran on 3B2-400s and used Datakits for networking. On Thu, Dec 1, 2022, 12:54 AM wrote: > Andrew Hume wrote: > > > i was working at building 5 at murray hill in system V development land > > when the first 3B20 arrived. the first order of business? running off to > the > > local Sears store to buy 4 car batteries so it could power up. what a > hoot! > > So what did the 3B20s run when they were being used in a Telco? Unix? > Or some other specialized OS? > > Or was said 3B20 a prototype before they'd been deployed to the Telcos? > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Thu Dec 1 20:00:23 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 1 Dec 2022 02:00:23 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <202212010853.2B18rOI8007094@freefriends.org> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> <202212010853.2B18rOI8007094@freefriends.org> Message-ID: umm, we were porting System V to it. which was modestly straight forward. as Skip remarked, the duplex versions (3B20D) ran DMERT, but singular 3B20’s were also common, and the plan was for them to run System V. (as far as i can recall; this was around 1982 or so.) > On Dec 1, 2022, at 12:53 AM, arnold at skeeve.com wrote: > > Andrew Hume wrote: > >> i was working at building 5 at murray hill in system V development land >> when the first 3B20 arrived. the first order of business? running off to the >> local Sears store to buy 4 car batteries so it could power up. what a hoot! > > So what did the 3B20s run when they were being used in a Telco? Unix? > Or some other specialized OS? > > Or was said 3B20 a prototype before they'd been deployed to the Telcos? > > Thanks, > > Arnold From arnold at skeeve.com Thu Dec 1 20:17:01 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 01 Dec 2022 03:17:01 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> <2E7259F5-3881-49A2-8B07-BC0794052907@humeweb.com> <202212010853.2B18rOI8007094@freefriends.org> Message-ID: <202212011017.2B1AH1k8018115@freefriends.org> I see. Thanks! Andrew Hume wrote: > umm, we were porting System V to it. which was modestly straight forward. > as Skip remarked, the duplex versions (3B20D) ran DMERT, but singular > 3B20’s were also common, and the plan was for them to run System V. > (as far as i can recall; this was around 1982 or so.) > > > On Dec 1, 2022, at 12:53 AM, arnold at skeeve.com wrote: > > > > Andrew Hume wrote: > > > >> i was working at building 5 at murray hill in system V development land > >> when the first 3B20 arrived. the first order of business? running off to the > >> local Sears store to buy 4 car batteries so it could power up. what a hoot! > > > > So what did the 3B20s run when they were being used in a Telco? Unix? > > Or some other specialized OS? > > > > Or was said 3B20 a prototype before they'd been deployed to the Telcos? > > > > Thanks, > > > > Arnold > From brad at anduin.eldar.org Thu Dec 1 22:25:47 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Thu, 01 Dec 2022 07:25:47 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: (message from Skip Tavakkolian on Thu, 1 Dec 2022 01:19:13 -0800) Message-ID: Skip Tavakkolian writes: > 3B20D's that were used for cellular switches used DMERT. > > I worked for McCaw Cellular (Cellular One) in mid-late 80's. They had > several AT&T switches. The monitoring and management system at the NOC in > Seattle was developed by BL (I think it was Indian Hill). It was called > MFOS and ran on 3B2-400s and used Datakits for networking. Getting a bit off topic... MFOS was very much at 6200 Broad Street in Columbus at least in the later days (although Indian Hill certainly could have been involved). I walked by the MFOS offices every day going to lunch. The group I was a part of sort of spawned out of MFOS, but had other inputs too. MFOS and the product I was a part of was ported / converted / forced into to a lot of different hardware, and I believe that the last one for MFOS was HP and HP-UX. I pretty sure I remember them going through the Starserver (white box Tandem systems) phase. The product I worked on got to skip the 3B2 systems Because Of Reasons, but we had to interface to systems that ran on the 3B so we had one to three in our lab(s) running simulators of the systems we were suppose to talk to. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From tuhs at tuhs.org Fri Dec 2 15:04:24 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 02 Dec 2022 05:04:24 +0000 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual Message-ID: Exciting development in the process of finding lost documentation, just sealed this one on eBay: https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY After the link is a (now closed) auction for a Western Electric 3B20S UNIX User's Manual Release 4.1, something I thought I'd never see and wasn't sure actually exited: print manuals for 4.x. Once received I'll be curious to see what differences are obvious between this and the 3.0 manual, and this should be easy to scan given the comb binding. What a nice cover too! I always expected if a 4.x manual of some kind popped up it would feature the falling blocks motif of the two starter package sets of technical reports, but the picture of a 3B20S is nice. How auspicious given the recent discussion on the 3B series. I'm particularly curious to see what makes it specifically a 3B20S manual, if that's referring to it only having commands relevant to that one or omitting any commands/info specific to DEC machines. Either way, exciting times, this is one of those things that I had originally set out to even verify existed when I first started really studying the history of UNIX documentation, so it's vindicating to have found something floating around out there in the wild. Between this and the 4.0 docs we now should have a much clearer picture of that gulf between III and V. More to come once I receive it! - Matt G. From spedraja at gmail.com Fri Dec 2 19:36:48 2022 From: spedraja at gmail.com (Sergio Pedraja) Date: Fri, 2 Dec 2022 10:36:48 +0100 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: Congrats. I got this manual some years ago. Yes, it contains some references to commands used apparently to manage the use of phone and comm services by users of, I assume, AT&T services. Nice day, Sergio El vie, 2 dic 2022 6:04, segaloco via TUHS escribió: > Exciting development in the process of finding lost documentation, just > sealed this one on eBay: > https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY > > After the link is a (now closed) auction for a Western Electric 3B20S UNIX > User's Manual Release 4.1, something I thought I'd never see and wasn't > sure actually exited: print manuals for 4.x. > > Once received I'll be curious to see what differences are obvious between > this and the 3.0 manual, and this should be easy to scan given the comb > binding. What a nice cover too! I always expected if a 4.x manual of some > kind popped up it would feature the falling blocks motif of the two starter > package sets of technical reports, but the picture of a 3B20S is nice. How > auspicious given the recent discussion on the 3B series. I'm particularly > curious to see what makes it specifically a 3B20S manual, if that's > referring to it only having commands relevant to that one or omitting any > commands/info specific to DEC machines. > > Either way, exciting times, this is one of those things that I had > originally set out to even verify existed when I first started really > studying the history of UNIX documentation, so it's vindicating to have > found something floating around out there in the wild. Between this and > the 4.0 docs we now should have a much clearer picture of that gulf between > III and V. > > More to come once I receive it! > > - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Dec 8 01:12:29 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 7 Dec 2022 10:12:29 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS Message-ID: https://www.usenix.org/about/awards/flame Well deserved, Warren! We are all in your debt. Doug From chet.ramey at case.edu Thu Dec 8 01:16:04 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 7 Dec 2022 10:16:04 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <5dd7a75e-7967-9b73-482b-0031e5a6cc95@case.edu> On 12/7/22 10:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Congratulations, Warren! -- ``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 crossd at gmail.com Thu Dec 8 01:17:25 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Dec 2022 10:17:25 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: On Wed, Dec 7, 2022 at 10:14 AM Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Congratulations, Warren! Truly, you are on fire. - Dan C. From tuhs at keck.us Thu Dec 8 01:53:33 2022 From: tuhs at keck.us (Cornelius Keck) Date: Wed, 7 Dec 2022 09:53:33 -0600 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <1be3e157-5aa5-bc56-2695-5f1f65c233b5@keck.us> Nice!! Congratulations! -Cornelius On 2022-12-07 09:12, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug From nikke.karlsson at gmail.com Thu Dec 8 01:54:24 2022 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Wed, 7 Dec 2022 16:54:24 +0100 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Congratulations, Warren! Best regards, Niklas Den ons 7 dec. 2022 kl 16:14 skrev Douglas McIlroy < douglas.mcilroy at dartmouth.edu>: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Thu Dec 8 01:55:31 2022 From: jcapp at anteil.com (Jim Capp) Date: Wed, 7 Dec 2022 10:55:31 -0500 (EST) Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: Message-ID: <19517087.6024.1670428531495.JavaMail.root@zimbraanteil> Wow! That's an awesome recognition. Thanks for all the work over the years! J -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at lowryduda.com Thu Dec 8 02:07:00 2022 From: david at lowryduda.com (David Lowry-Duda) Date: Wed, 7 Dec 2022 11:07:00 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Congratulations Warren! - DLD From lists at irreal.org Thu Dec 8 02:07:40 2022 From: lists at irreal.org (jcs) Date: Wed, 07 Dec 2022 11:07:40 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Douglas McIlroy writes: > https://www.usenix.org/about/awards/flame Congratulations and thank you for helping keep the flame alive. From tuhs at tuhs.org Thu Dec 8 02:11:44 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Dec 2022 16:11:44 +0000 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Quite the honor, and a well-deserved one at that. Decades later and UNIX is still a system around which a fellowship forms. This community is proof of that. Congratulations Warren for all your hard work, my research would've never progressed without these resources. - Matt G. ------- Original Message ------- On Wednesday, December 7th, 2022 at 7:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug From rminnich at gmail.com Thu Dec 8 02:29:11 2022 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 Dec 2022 08:29:11 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: TUHS is a source of knowledge without equal in my experience. Where else would people trace down the link register to schematics from the 40s :-) eat your heart out chatgpt :-) On Wed, Dec 7, 2022 at 8:12 AM segaloco via TUHS wrote: > Quite the honor, and a well-deserved one at that. Decades later and UNIX > is still a system around which a fellowship forms. This community is proof > of that. Congratulations Warren for all your hard work, my research > would've never progressed without these resources. > > - Matt G. > > ------- Original Message ------- > On Wednesday, December 7th, 2022 at 7:12 AM, Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > > > > https://www.usenix.org/about/awards/flame > > > > Well deserved, Warren! We are all in your debt. > > > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Thu Dec 8 02:33:28 2022 From: david at kdbarto.org (David Barto) Date: Wed, 7 Dec 2022 08:33:28 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <3DFAAC13-A76B-4FCC-AF66-D66AC1803775@kdbarto.org> > On Dec 7, 2022, at 7:12 AM, Douglas McIlroy wrote: > > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug Chiming in to say “Congratulations” for a remarkable site and dedication to the craft. David From clemc at ccc.com Thu Dec 8 02:38:44 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Dec 2022 11:38:44 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Indeed - so pleased to see this On Wed, Dec 7, 2022 at 10:14 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Thu Dec 8 02:44:44 2022 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 7 Dec 2022 17:44:44 +0100 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: On Wednesday, December 7, 2022, Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Excellent news! Congratulations! Last year it was Chet, now Warren. TUHS is finally getting the attention it deserves. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Thu Dec 8 02:48:43 2022 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 7 Dec 2022 08:48:43 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <9246d54c-2ff1-2611-f8a5-9b0b0855e7dd@solar.stanford.edu> Warren, thank you so much for your tremendous gift to the Unix community.  A well-earned award!!! Deborah On 12/7/22 7:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug From marc.donner at gmail.com Thu Dec 8 02:49:43 2022 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 7 Dec 2022 11:49:43 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Nice! ===== nygeek.net mindthegapdialogs.com/home On Wed, Dec 7, 2022 at 10:14 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Thu Dec 8 03:10:32 2022 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Wed, 07 Dec 2022 18:10:32 +0100 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <1670433032.2555.20.camel@mni.thm.de> On Mi, 2022-12-07 at 10:12 -0500, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug Congratulations Warren, and thanks for your great work! Hellwig From tuhs at tuhs.org Thu Dec 8 04:21:07 2022 From: tuhs at tuhs.org (Sean Dwyer via TUHS) Date: Wed, 7 Dec 2022 13:21:07 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <20221207182107.mqoxqfqj3qsvlwku@mail.ewe2.ninja> Thankyou for TUHS Warren, your concern for computer history is vital and inspiring. -- I love deadlines. I love the whooshing noise as they fly by. From will.senn at gmail.com Thu Dec 8 04:26:53 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 7 Dec 2022 12:26:53 -0600 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: <20221207182107.mqoxqfqj3qsvlwku@mail.ewe2.ninja> References: <20221207182107.mqoxqfqj3qsvlwku@mail.ewe2.ninja> Message-ID: Oh, how many hours I've lost track of thanks to TUHS :)... But seriously, it's not often that the folks doing the hard work get duly recognized. Thanks Warren for bring TUHS to life and keeping it relevant and important through the years. -will From rich.salz at gmail.com Thu Dec 8 04:30:25 2022 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 7 Dec 2022 13:30:25 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Keep the flame alive, indeed. Thank you Warren! On Wed, Dec 7, 2022 at 10:14 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwindl at posteo.de Thu Dec 8 05:18:08 2022 From: schwindl at posteo.de (Tom Schwindl) Date: Wed, 07 Dec 2022 19:18:08 +0000 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Thanks for all of your great work and this community! Congratulations! -- Best Regards, Tom Schwindl From joshnatis0 at gmail.com Thu Dec 8 05:18:46 2022 From: joshnatis0 at gmail.com (josh) Date: Wed, 7 Dec 2022 14:18:46 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: Congratulations Warren!!! Thanks for everything, well deserved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenbob at gmail.com Thu Dec 8 05:23:37 2022 From: kenbob at gmail.com (Ken Thompson) Date: Wed, 7 Dec 2022 11:23:37 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: thank you, warren. On Wed, Dec 7, 2022 at 11:20 AM josh wrote: > Congratulations Warren!!! Thanks for everything, well deserved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Dec 8 05:27:51 2022 From: athornton at gmail.com (Adam Thornton) Date: Wed, 7 Dec 2022 12:27:51 -0700 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <2E341379-8D22-42B1-84BB-E1FEEA50FD6A@gmail.com> > On Dec 7, 2022, at 8:12 AM, Douglas McIlroy wrote: > > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Bravo! From tuhs at tuhs.org Thu Dec 8 05:29:43 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Wed, 7 Dec 2022 12:29:43 -0700 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <57e11085-4eeb-09a6-a326-3f6eb197c3b6@spamtrap.tnetconsulting.net> On 12/7/22 8:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Congratulations Warren. Another ""fan trying to help keep the flame going. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From heinz at osta.com Thu Dec 8 05:41:51 2022 From: heinz at osta.com (Heinz Lycklama) Date: Wed, 7 Dec 2022 11:41:51 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: <57e11085-4eeb-09a6-a326-3f6eb197c3b6@spamtrap.tnetconsulting.net> References: <57e11085-4eeb-09a6-a326-3f6eb197c3b6@spamtrap.tnetconsulting.net> Message-ID: <259362df-2e98-f1ce-a74e-9cda39a1ed91@osta.com> Thank you and congratulations Warren. On 12/7/2022 11:29 AM, Grant Taylor via TUHS wrote: > On 12/7/22 8:12 AM, Douglas McIlroy wrote: >> https://www.usenix.org/about/awards/flame >> >> Well deserved, Warren! We are all in your debt. From tuhs at tuhs.org Thu Dec 8 06:31:32 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 8 Dec 2022 06:31:32 +1000 Subject: [TUHS] Flame award Message-ID: All, thank you all for all the congratulations! I was going to pen an e-mail to the list last night but, after a few celebratory glasses of wine, I demurred. It still feels weird that Usenix chose me for the Flame award, given such greats as Doug, Margo, Radia and others have previously received the same award. In reality, the award belongs to every TUHS member who has contributed documents, source code, tape images, anecdotes, knowledge and wisdom, and who have given their time and energy to help others with problems. I've been a steward of a remarkable community over three decades and I feel honoured and humbled to receive recognition for it. Casey told me the names of the people who nominated me. Thank you for putting my name forward. Getting the e-mail from Casey sure was a surprise :-) https://www.tuhs.org/Images/flame.jpg Many thanks for all your support over the years! Warren From bakul at iitbombay.org Thu Dec 8 06:35:51 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 7 Dec 2022 12:35:51 -0800 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: Thank you & congratulations! > On Dec 7, 2022, at 12:31 PM, Warren Toomey via TUHS wrote: > > All, thank you all for all the congratulations! I was going to pen an e-mail > to the list last night but, after a few celebratory glasses of wine, I demurred. > > It still feels weird that Usenix chose me for the Flame award, given such > greats as Doug, Margo, Radia and others have previously received the > same award. In reality, the award belongs to every TUHS member who has > contributed documents, source code, tape images, anecdotes, knowledge > and wisdom, and who have given their time and energy to help others > with problems. I've been a steward of a remarkable community over three > decades and I feel honoured and humbled to receive recognition for it. > > Casey told me the names of the people who nominated me. Thank you for > putting my name forward. Getting the e-mail from Casey sure was a surprise :-) > > https://www.tuhs.org/Images/flame.jpg > > Many thanks for all your support over the years! > > Warren From marzhall.o at gmail.com Thu Dec 8 06:48:27 2022 From: marzhall.o at gmail.com (Marshall Conover) Date: Wed, 7 Dec 2022 15:48:27 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: <259362df-2e98-f1ce-a74e-9cda39a1ed91@osta.com> References: <57e11085-4eeb-09a6-a326-3f6eb197c3b6@spamtrap.tnetconsulting.net> <259362df-2e98-f1ce-a74e-9cda39a1ed91@osta.com> Message-ID: Congratulations and thanks! On Wed, Dec 7, 2022 at 2:42 PM Heinz Lycklama wrote: > Thank you and congratulations Warren. > > On 12/7/2022 11:29 AM, Grant Taylor via TUHS wrote: > > On 12/7/22 8:12 AM, Douglas McIlroy wrote: > >> https://www.usenix.org/about/awards/flame > >> > >> Well deserved, Warren! We are all in your debt. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Dec 8 06:51:21 2022 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Dec 2022 07:51:21 +1100 (EST) Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame Blimey; he's certainly changed from the long-haired bearded hippie that I knew in the 80s... > Well deserved, Warren! We are all in your debt. Well done, indeed! -- Dave From luther at makerlisp.com Thu Dec 8 07:17:15 2022 From: luther at makerlisp.com (Luther Johnson) Date: Wed, 7 Dec 2022 14:17:15 -0700 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <70b02ddc-4d80-2eff-5335-9ded90a41229@makerlisp.com> Thank you, Warren ! On 12/07/2022 08:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. > > Doug > From rtomek at ceti.pl Thu Dec 8 07:55:28 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Wed, 7 Dec 2022 22:55:28 +0100 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: On Thu, Dec 08, 2022 at 06:31:32AM +1000, Warren Toomey via TUHS wrote: > All, thank you all for all the congratulations! I was going to pen an e-mail > to the list last night but, after a few celebratory glasses of wine, > I demurred. [...] > Many thanks for all your support over the years! > > Warren > Congratulations and thank you for the much appreciated work! I am happy to have learned about this place some moons ago. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From imp at bsdimp.com Thu Dec 8 08:11:16 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 7 Dec 2022 15:11:16 -0700 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: On Wed, Dec 7, 2022, 1:32 PM Warren Toomey via TUHS wrote: > All, thank you all for all the congratulations! I was going to pen an > e-mail > to the list last night but, after a few celebratory glasses of wine, I > demurred. > > It still feels weird that Usenix chose me for the Flame award, given such > greats as Doug, Margo, Radia and others have previously received the > same award. In reality, the award belongs to every TUHS member who has > contributed documents, source code, tape images, anecdotes, knowledge > and wisdom, and who have given their time and energy to help others > with problems. I've been a steward of a remarkable community over three > decades and I feel honoured and humbled to receive recognition for it. > > Casey told me the names of the people who nominated me. Thank you for > putting my name forward. Getting the e-mail from Casey sure was a surprise > :-) > > https://www.tuhs.org/Images/flame.jpg > > Many thanks for all your support over the years! > I was momentarily jealous of this award. Then I thought for all the time and effort I'd put in, you've done 10 over the same time. And you've been doing it 20 times as long and with more gumption than I ever put towards things. You have been doing this since PUPS which only ever heard of due to a drinking buddy Dworkin Muller... So after a mere moment of jealousy, I realized that there is no one more deserving of this recognition and these accolades... well done Warren. Well earned. Warner Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Thu Dec 8 08:25:27 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 07 Dec 2022 14:25:27 -0800 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: Warren Toomey via TUHS wrote: > It still feels weird that Usenix chose me for the Flame award, given such > greats as Doug, Margo, Radia and others have previously received the > same award. In reality, the award belongs to every TUHS member who has > contributed documents, source code, tape images, anecdotes, knowledge > and wisdom, and who have given their time and energy to help others > with problems. I've been a steward of a remarkable community over three > decades and I feel honoured and humbled to receive recognition for it. As someone who’s stewarded (and cat-herded) smaller communities for less time, I can say that three decades of persistent community gardening is incredible. Sure, people show up, drop off their work, then disappear. Sometimes they hang around to chat, or show up when they need help, maybe even occasionally get HYPERFIXATED and invest tremendous effort into a thing as part of the group. And maybe they fall away only to return a decade later. But those people do it because they know the stability the organizer brings. How many random abandoned source drops are up in sourceforge or github? I’m sure there’s a super specific distributed crypto internet relay chat mobile watch app channel that’s focused on getting SVR4 derivatives bootstrapped onto ARM 64-bit platforms, but this mailing list existed before it and may well exist after. More importantly, so will its archives. Kudos! -- Joseph Holsten From cmhanson at eschatologist.net Thu Dec 8 09:45:53 2022 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 7 Dec 2022 15:45:53 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <63851D51-87D2-4BB0-87CE-95571C9B2057@eschatologist.net> On Dec 7, 2022, at 7:12 AM, Douglas McIlroy wrote: > > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Amen! -- Chris From arnold at skeeve.com Thu Dec 8 17:24:09 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 08 Dec 2022 00:24:09 -0700 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: <202212080724.2B87O9nk006508@freefriends.org> Warren, You certainly deserve this. Yes, TUHS wouldn't be what it is without all its contributors. But YOU were the one initiated it, YOU curate the collection and you steward the email list. You started the ball rolling, and thus you deserve this acknowledgement from the community at large. Congratulations! Arnold Warren Toomey via TUHS wrote: > All, thank you all for all the congratulations! I was going to pen an e-mail > to the list last night but, after a few celebratory glasses of wine, I demurred. > > It still feels weird that Usenix chose me for the Flame award, given such > greats as Doug, Margo, Radia and others have previously received the > same award. In reality, the award belongs to every TUHS member who has > contributed documents, source code, tape images, anecdotes, knowledge > and wisdom, and who have given their time and energy to help others > with problems. I've been a steward of a remarkable community over three > decades and I feel honoured and humbled to receive recognition for it. > > Casey told me the names of the people who nominated me. Thank you for > putting my name forward. Getting the e-mail from Casey sure was a surprise :-) > > https://www.tuhs.org/Images/flame.jpg > > Many thanks for all your support over the years! > > Warren From tuhs at tuhs.org Thu Dec 8 22:13:28 2022 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Thu, 08 Dec 2022 13:13:28 +0100 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: (Douglas McIlroy's message of "Wed, 7 Dec 2022 10:12:29 -0500") References: Message-ID: Congratulations, Warren! This is well-deserved recognition. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From martymcg at fastmail.com Fri Dec 9 00:38:39 2022 From: martymcg at fastmail.com (Marty, MIT Club of Princeton) Date: Thu, 08 Dec 2022 09:38:39 -0500 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <44e51884-3929-44b3-8cde-53fc7468b55d@app.fastmail.com> well deserved, and Alleluia! =*+[]+ Marty McGowan 908 230-3739 MIT Club of Princeton, VP Membership On Thu, Dec 8, 2022, at 07:13, Tom Ivar Helbekkmo via TUHS wrote: > Congratulations, Warren! This is well-deserved recognition. > > -tih > -- > Most people who graduate with CS degrees don't understand the significance > of Lisp. Lisp is the most important idea in computer science. --Alan Kay From lanciagreggori at gmail.com Fri Dec 9 02:53:39 2022 From: lanciagreggori at gmail.com (Lancia Greggori) Date: Thu, 8 Dec 2022 20:23:39 +0330 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: <44e51884-3929-44b3-8cde-53fc7468b55d@app.fastmail.com> References: <44e51884-3929-44b3-8cde-53fc7468b55d@app.fastmail.com> Message-ID: I have been a passive observer ( except for one message ) since I joined the TUHS mailing list around 2 months ago. I kept silent because I wasn't part of the wonderful history of UNIX and did not have anything to contribute to discussions. I felt like I had to break my silence for this one occasion since I felt incredibly indebted to Sir Warren Toomey and every other person here at TUHS. I had my passion for UNIX history before TUHS and was thrilled when I discovered that a whole society existed for preserving and discussing UNIX history. I spent many hours reading the mailing list discussions, both present and past ones at the archive. I also acquired a PDF of the book "Life With UNIX" ( much appreciation to their authors: Don Libes & Sandy Ressler ) from the UNIX archives and have been reading and enjoying it much ever since, the book opened my eyes as to what the climate around UNIX was in the 1980's. I have been learning a lot of valuable historical information that I would not have been able to get without TUHS. So a very special thanks from the bottom of my heart to Sir Warren Toomey and every other person who has made all of this possible, have a great day. On Thu, Dec 8, 2022 at 6:08 PM Marty, MIT Club of Princeton < martymcg at fastmail.com> wrote: > well deserved, and Alleluia! > > =*+[]+ Marty McGowan 908 230-3739 > MIT Club of Princeton, VP Membership > > On Thu, Dec 8, 2022, at 07:13, Tom Ivar Helbekkmo via TUHS wrote: > > Congratulations, Warren! This is well-deserved recognition. > > > > -tih > > -- > > Most people who graduate with CS degrees don't understand the > significance > > of Lisp. Lisp is the most important idea in computer science. --Alan > Kay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Dec 9 04:32:47 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 08 Dec 2022 18:32:47 +0000 Subject: [TUHS] C with Classes reference manual Message-ID: Here’s a stretch, but does anybody have a copy of the 1982-ish C With Classes Reference Manual kicking around. I can take it in n/troff or a more modern format if you have it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Dec 9 06:24:07 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 Dec 2022 20:24:07 +0000 Subject: [TUHS] Bell Office Automation System (OAS)? Message-ID: Good day all, this may be COFF instead, but I'm not joined over there yet, might need some Warren help/approval. In any case, received that 3B20S 4.1 manual in good shape, unpacked it, and out fell a little tri-fold titled "The Office Automation System (OAS) Editor-Formatter (ef) Reference Card" emblazoned with the usual Bell Laboratories, non-disclosure note abut the Bell System, and a nice little picture of a terminal I can't identify as well as the full manual for this OAS leaning against it: "The Office Automation System (OAS)" with a nice big Bell logo at the bottom of the spine. The latter is likely a manual I spotted in a video once and couldn't make out the name/title at the time, thought I was seeing another long-lost UNIX manual. I've never heard of this before, and Google isn't turning up much as Office Automation System appears to be a general industry term. I seem to recall hearing about ef itself once or twice, some sort of pre-vi screen editor from Bell methinks? Not super familiar with it though, I just seem to recall reading about that before somewhere. Anywho, dealing with a move in the near future that is hopefully into a home I own, so pretty distracted from that scanning I keep talking about, but hopefully when I'm settled in in a few months I can setup a proper scan bench in my new place and really go to town on things. - Matt G. From andrew at humeweb.com Fri Dec 9 07:03:21 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 8 Dec 2022 13:03:21 -0800 Subject: [TUHS] Bell Office Automation System (OAS)? In-Reply-To: References: Message-ID: when it matters, i was a part of the OAS team. i was technical lead, cathie brooks was our supervisor, and i can’t really remember the other folks. i wrote ef. it was not my proudest programming achievement. but denis ritchie helped me out by being a test user. andrew > On Dec 8, 2022, at 12:24 PM, segaloco via TUHS wrote: > > Good day all, this may be COFF instead, but I'm not joined over there yet, might need some Warren help/approval. > > In any case, received that 3B20S 4.1 manual in good shape, unpacked it, and out fell a little tri-fold titled "The Office Automation System (OAS) Editor-Formatter (ef) Reference Card" emblazoned with the usual Bell Laboratories, non-disclosure note abut the Bell System, and a nice little picture of a terminal I can't identify as well as the full manual for this OAS leaning against it: "The Office Automation System (OAS)" with a nice big Bell logo at the bottom of the spine. > > The latter is likely a manual I spotted in a video once and couldn't make out the name/title at the time, thought I was seeing another long-lost UNIX manual. I've never heard of this before, and Google isn't turning up much as Office Automation System appears to be a general industry term. > > I seem to recall hearing about ef itself once or twice, some sort of pre-vi screen editor from Bell methinks? Not super familiar with it though, I just seem to recall reading about that before somewhere. > > Anywho, dealing with a move in the near future that is hopefully into a home I own, so pretty distracted from that scanning I keep talking about, but hopefully when I'm settled in in a few months I can setup a proper scan bench in my new place and really go to town on things. > > - Matt G. From lproven at gmail.com Fri Dec 9 08:22:12 2022 From: lproven at gmail.com (Liam Proven) Date: Thu, 8 Dec 2022 23:22:12 +0100 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: <44e51884-3929-44b3-8cde-53fc7468b55d@app.fastmail.com> Message-ID: On Thu, 8 Dec 2022 at 17:52, Lancia Greggori wrote: > > I have been a passive observer ( except for one message ) since I joined the TUHS mailing list around 2 months ago. > I kept silent because I wasn't part of the wonderful history of UNIX and did not have anything to contribute to discussions. Much the same from this part. I'm a newbie on the list too, only going back as far as SCO Xenix, but I've found it fascinating and some heroes of mine post here. Thanks, Warren, and congratulations. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From pugs78 at gmail.com Fri Dec 9 09:39:50 2022 From: pugs78 at gmail.com (Tom Lyon) Date: Thu, 8 Dec 2022 15:39:50 -0800 Subject: [TUHS] Draft 1 of K&R C Book - scan available Message-ID: I finally got myself a decent scanner, and have scanned my most prized relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's "The C Programming Language". It's early enough that there are no tables of contents or index; of particular note is that "chapter 8" is a "C Reference Manual" by Dennis dated May 1, 1977. This dates from approx July 1977; it has my name on the cover and various scribbles pointing out typos throughout. Enjoy! https://drive.google.com/drive/folders/1OvgKikM8vpZGxNzCjt4BM1ggBX0dlr-y?usp=sharing p.s. I used a Fujitsu FI-8170 scanner, VueScan on Ubuntu, and pdftk-java to merge front and back pages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Dec 10 01:14:48 2022 From: tuhs at tuhs.org (Jay Logue via TUHS) Date: Fri, 9 Dec 2022 07:14:48 -0800 Subject: [TUHS] Warren wins Usenix award for TUHS In-Reply-To: References: Message-ID: <06f0b2fd-5832-4fbe-b810-41ea0d781690@toaster.com> On 12/7/2022 7:12 AM, Douglas McIlroy wrote: > https://www.usenix.org/about/awards/flame > > Well deserved, Warren! We are all in your debt. Indeed, congratulations Warren! Like others, I am largely a spectator in this group.  As such, I am immensely thankful for the ability to hear the stories of so many who were in the trenches as Unix was born.  The excellent Unix Archive has been a near endless source of understanding and diversion for me, and has even led me to make my own small contribution the Unix history preservation effort. Thank you, Warren, for all your hard work! --Jay From chet.ramey at case.edu Sat Dec 10 05:28:40 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 9 Dec 2022 14:28:40 -0500 Subject: [TUHS] Draft 1 of K&R C Book - scan available In-Reply-To: References: Message-ID: On 12/8/22 6:39 PM, Tom Lyon wrote: > I finally got myself a decent scanner, and have scanned my most prized > relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's "The > C Programming Language". This is great, thanks! -- ``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 marc.donner at gmail.com Sat Dec 10 06:01:31 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 9 Dec 2022 15:01:31 -0500 Subject: [TUHS] Draft 1 of K&R C Book - scan available In-Reply-To: References: Message-ID: I'll be talking with BWK by Zoom today at 4:30 PM. Should I share this with him? ===== nygeek.net mindthegapdialogs.com/home On Thu, Dec 8, 2022 at 6:41 PM Tom Lyon wrote: > I finally got myself a decent scanner, and have scanned my most prized > relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's "The > C Programming Language". > > It's early enough that there are no tables of contents or index; of > particular note is that "chapter 8" is a "C Reference Manual" by Dennis > dated May 1, 1977. > > This dates from approx July 1977; it has my name on the cover and various > scribbles pointing out typos throughout. > > Enjoy! > > > https://drive.google.com/drive/folders/1OvgKikM8vpZGxNzCjt4BM1ggBX0dlr-y?usp=sharing > > p.s. I used a Fujitsu FI-8170 scanner, VueScan on Ubuntu, and pdftk-java > to merge front and back pages. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sat Dec 10 06:24:39 2022 From: pugs78 at gmail.com (Tom Lyon) Date: Fri, 9 Dec 2022 12:24:39 -0800 Subject: [TUHS] Draft 1 of K&R C Book - scan available In-Reply-To: References: Message-ID: He may have it already, but give him my kind regards. On Fri, Dec 9, 2022 at 12:01 PM Marc Donner wrote: > I'll be talking with BWK by Zoom today at 4:30 PM. Should I share this > with him? > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Dec 8, 2022 at 6:41 PM Tom Lyon wrote: > >> I finally got myself a decent scanner, and have scanned my most prized >> relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's "The >> C Programming Language". >> >> It's early enough that there are no tables of contents or index; of >> particular note is that "chapter 8" is a "C Reference Manual" by Dennis >> dated May 1, 1977. >> >> This dates from approx July 1977; it has my name on the cover and various >> scribbles pointing out typos throughout. >> >> Enjoy! >> >> >> https://drive.google.com/drive/folders/1OvgKikM8vpZGxNzCjt4BM1ggBX0dlr-y?usp=sharing >> >> p.s. I used a Fujitsu FI-8170 scanner, VueScan on Ubuntu, and pdftk-java >> to merge front and back pages. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sat Dec 10 07:49:03 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 9 Dec 2022 16:49:03 -0500 Subject: [TUHS] Bringing a Chainsaw Message-ID: (Recently I mentioned to Doug McIlroy that I had infiltrated IBM East Fishkill, reputedly one of the largest semiconductor fabs in the world, with UNIX back in the 1980s. He suggested that I write it up and share it here, so here it is.) In 1986 I was working at IBM Research in Yorktown Heights, New York. I had rejoined in 1984 after completing my PhD in computer science at CMU. One day I got a phone call from Rick Dill. Rick, a distinguished physicist who had, among other things, invented a technique that was key to economically fabricating semiconductor lasers, had been my first boss at IBM Research. While I’d been in Pittsburgh he had taken an assignment at IBM’s big semiconductor fab up in East Fishkill. He was working to make production processes there more efficient. He was about to initiate a major project, with a large capital cost, that involved deploying a bunch of computers and he wanted a certified computer scientist at the project review. He invited me to drive up to Fishkill, about half an hour north of the research lab, to attend a meeting. I agreed. At the meeting I learned several things. First of all, the chipmaking process involved many steps - perhaps fifty or sixty for each wafer full of chips. The processing steps individually were expensive, and the amount spent on each wafer was substantial. Because processing was imperfect, it was imperative to check the results every few steps to make sure everything was OK. Each wafer included a number of test articles, landing points for test probes, scattered around the surface. Measurements of these test articles were carried out on a special piece of equipment, I think bought from Fairchild Semiconductor. It would take in a boat of wafers (identical wafers were grouped together on special ceramic holders called boats, for automatic handling, and all processed identically) and feed each wafer to the test station, and probe each test article in turn. The result was about a megabyte of data covering all of the wafers in the boat. At this point the data had to be analyzed. The analysis program comprised an interpreter called TAHOE along with a test program, one for each different wafer being fabricated. The results indicated whether the wafers in the boat were good, needed some rework, or had to be discarded. These were the days before local area networking at IBM, so getting the data from the test machine to the mainframe for analysis involved numerous manual steps and took about six hours. To improve quality control, each boat of wafers was only worked during a single eight-hour shift, so getting the test results generally meant a 24 hour pause in the processing of the boat, even though the analysis only took a couple of seconds of time on the mainframe. IBM had recently released a physically small mainframe based on customized CPU chips from Motorola. This machine, the size of a large suitcase and priced at about a million dollars, was suitable to locate next to each test machine, thus eliminating the six hour wait to see results. Because there were something like 50 of the big test machines at the Fishkill site, project represented a major capital expenditure. Getting funding of this size approved would take six to twelve months, and this meeting was the first step in seeking this approval. At the end of the meeting I asked for a copy of the manual for the TAHOE test language. Someone gave me a copy and I took it home over the weekend and read through it. The following Monday I called Rick up and told him that I thought I could implement an interpreter for the TAHOE language in about a month of work. That was a tiny enough investment that Rick simply wrote a letter to Ralph Gomory, then head of IBM Research, to requisition me for a month. I told the Fishkill folks that I needed a UNIX machine to do this work and they procured an RT PC running AIX 1. AIX 1 was based on System V. The critical thing to me was that it had lex, yacc, vi, and make. They set me up in an empty lab room with the machine and a work table. Relatively quickly I built a lexical analyzer for the language in lex and got an approximation to the grammar for the TAHOE language working in yacc. The rest was implementing the functions for each of the TAHOE primitives. I adopted rigorous test automation early, a practice people now call test driven development. Each time I added a capability to the interpreter I wrote a scrap of TAHOE code to test it along with a piece of reference input. I created a test target in the testing Makefile that ran the interpreter with the test program and the reference input. There were four directories, one for test scripts, one for input data, one for expected outputs, and one for actual outputs. There was a big make file that had a target for each test. Running all of the tests was simply a matter of typing ‘make test’ in the root of the testing tree. Only if all of the tests succeeded would I consider a build acceptable. As I developed the interpreter I learned to build tests also for bugs as I encountered them. This was because I discovered that I would occasionally reintroduce bugs, so these tests, with the same structure (test scrap, input data, reference output, make target) were very useful at catching backsliding before it got away from me. After a while I had implemented the entire TAHOE language. I named the interpreter MONO after looking at the maps of the area near Lake Tahoe and seeing Mono Lake, a small lake nearby. Lake Tahoe and Mono Lake, with walking routes between them. Source: Google Maps At this point I asked my handler at Fishkill for a set of real input data, a real test program, and a real set of output data. He got me the files and I set to work. The only tricky bit at this stage was the difference in floating point between the RT PC machine, which used the recently adopted IEEE 754 floating point standard and the idiosyncratic floating point implemented in the System 370 mainframes at the time. The problem was that the LSB rounding rules were different in the two machines, resulting in mismatches in results. These mismatches were way below the resolution of the actual data, but deciding how to handle this was tricky. At this point I had an interpreter, MONO, for the TAHOE language that took one specific TAHOE program, some real data, and produced output that matched the TAHOE output. Almost done. I asked my handler, a lovely guy whose name I am ashamed I do not remember, to get me the regression test suite for TAHOE. He took me over and introduced me to the woman who managed the team that was developing and maintaining the TAHOE interpreter. The TAHOE interpreter had been under development, I gathered, for about 25 years and was a large amount of assembler code. I asked her for the regression test suite for the TAHOE interpreter. She did not recognize the term, but I was not dismayed - IBM had their own names for everything (disk was DASD and a boot program was IPL) and I figured it would be Polka Dot or something equally evocative. I described what my regression test suite did and her face lit up. “What a great idea!” she exclaimed. Anyway, at that point I handed the interpreter code over to the Fishkill organization. C compilers were available for the PC by that time, so they were able to deploy it on PC-AT machines that they located at each testing machine. Since a PC-AT could be had for about $5,000 in those days the savings from the original proposal was about $50 million and about a year of elapsed time. The analysis of a boat’s worth of data on the PC-AT took perhaps a minute or two, so quite a bit slower than on the mainframe, but the elimination of the six-hour delay meant that a boat could progress forward in its processing on the same day rather than a day later. One of my final conversations with my Fishkill handler was about getting them some UNIX training. In those days the only way to get UNIX training was from AT&T. Doing business with AT&T at IBM in those days involved very high-level approvals - I think it required either the CEO or a direct report to the CEO. He showed me the form he needed to get approved in order to take this course, priced at about $1,500 at the time. It required twelve signatures. When I expressed horror he noted that I shouldn’t worry because the first six were based in the building we were standing in. That’s when I began to grasp how big IBM was in those days. Anyway, about five years later I left IBM. Just before I resigned the Fishkill folks invited me up to attend a celebratory dinner. Awards were given to many people involved in the project, including me. I learned that there was now a department of more than 30 people dedicated to maintaining the program that had taken me a month to build. Rick Dill noted that one of the side benefits of the approach that I had taken was the production of a formal grammar for the TAHOE language. At one point near the end of the project I had a long reflective conversation with my Fishkill minder. He spun a metaphor about what I had done with this project. Roughly speaking, he said, “We were a bunch of guys cutting down trees by beating on them with stones. We heard that there was this thing called an axe, and someone sent a guy we thought would show us how to cut down trees with an axe. Imagine our surprise when he whipped out a chainsaw.” ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sat Dec 10 07:49:54 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 9 Dec 2022 16:49:54 -0500 Subject: [TUHS] Draft 1 of K&R C Book - scan available In-Reply-To: References: Message-ID: He does and I did. Thanks. ===== nygeek.net mindthegapdialogs.com/home On Fri, Dec 9, 2022 at 3:24 PM Tom Lyon wrote: > He may have it already, but give him my kind regards. > > On Fri, Dec 9, 2022 at 12:01 PM Marc Donner wrote: > >> I'll be talking with BWK by Zoom today at 4:30 PM. Should I share this >> with him? >> ===== >> nygeek.net >> mindthegapdialogs.com/home >> >> >> On Thu, Dec 8, 2022 at 6:41 PM Tom Lyon wrote: >> >>> I finally got myself a decent scanner, and have scanned my most prized >>> relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's "The >>> C Programming Language". >>> >>> It's early enough that there are no tables of contents or index; of >>> particular note is that "chapter 8" is a "C Reference Manual" by Dennis >>> dated May 1, 1977. >>> >>> This dates from approx July 1977; it has my name on the cover and >>> various scribbles pointing out typos throughout. >>> >>> Enjoy! >>> >>> >>> https://drive.google.com/drive/folders/1OvgKikM8vpZGxNzCjt4BM1ggBX0dlr-y?usp=sharing >>> >>> p.s. I used a Fujitsu FI-8170 scanner, VueScan on Ubuntu, and >>> pdftk-java to merge front and back pages. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Sat Dec 10 08:49:09 2022 From: rdm at cfcl.com (Rich Morin) Date: Fri, 9 Dec 2022 14:49:09 -0800 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: > On Dec 9, 2022, at 13:49, Marc Donner wrote: > > ... I described what my regression test suite did and her face lit up. “What a great idea!” she exclaimed. ... Reminded me of this gem: “What a failure of imagination!” -- Dennis M. Ritchie, “The Evolution of the Unix Time-sharing System”, AT&T Bell Laboratories Technical Journal 63(6), Part 2, Oct. 1984, pp.1577–93 -r From kevin.bowling at kev009.com Sat Dec 10 11:57:16 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 9 Dec 2022 18:57:16 -0700 Subject: [TUHS] Flame award In-Reply-To: References: Message-ID: On Wed, Dec 7, 2022 at 1:31 PM Warren Toomey via TUHS wrote: > All, thank you all for all the congratulations! I was going to pen an > e-mail > to the list last night but, after a few celebratory glasses of wine, I > demurred. > > It still feels weird that Usenix chose me for the Flame award, given such > greats as Doug, Margo, Radia and others have previously received the > same award. In reality, the award belongs to every TUHS member who has > contributed documents, source code, tape images, anecdotes, knowledge > and wisdom, and who have given their time and energy to help others > with problems. I've been a steward of a remarkable community over three > decades and I feel honoured and humbled to receive recognition for it. > > Casey told me the names of the people who nominated me. Thank you for > putting my name forward. Getting the e-mail from Casey sure was a surprise > :-) > > https://www.tuhs.org/Images/flame.jpg > > Many thanks for all your support over the years! > Splendid, well done! > Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Dec 10 16:54:43 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 10 Dec 2022 01:54:43 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: On Fri, Dec 9, 2022 at 4:50 PM Marc Donner wrote: (Recently I mentioned to Doug McIlroy that I had infiltrated IBM East > Fishkill, reputedly one of the largest semiconductor fabs in the world, > with UNIX back in the 1980s. He suggested that I write it up and share it > here, so here it is.) > Some editions of the Jargon File contain an entry for _branch to Fishkill_, defined as "Any unexpected jump in a program that produces catastrophic or just plain weird results" and attributed to IBM. Are you familiar with this term? Did it have a specific reference within IBM? In any case, this is a great story! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sat Dec 10 19:10:26 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 10 Dec 2022 04:10:26 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: Interesting. I never heard “branch to Fishkill” until today. On Sat, Dec 10, 2022 at 1:54 AM John Cowan wrote: > > > On Fri, Dec 9, 2022 at 4:50 PM Marc Donner wrote: > > (Recently I mentioned to Doug McIlroy that I had infiltrated IBM East >> Fishkill, reputedly one of the largest semiconductor fabs in the world, >> with UNIX back in the 1980s. He suggested that I write it up and share it >> here, so here it is.) >> > > Some editions of the Jargon File contain an entry for _branch to > Fishkill_, defined as "Any unexpected jump in a program that produces > catastrophic or just plain weird results" and attributed to IBM. Are you > familiar with this term? Did it have a specific reference within IBM? > > In any case, this is a great story! > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From ats at offog.org Sun Dec 11 02:54:13 2022 From: ats at offog.org (Adam Sampson) Date: Sat, 10 Dec 2022 16:54:13 +0000 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: (John Cowan's message of "Sat, 10 Dec 2022 01:54:43 -0500") References: Message-ID: John Cowan writes: > Some editions of the Jargon File contain an entry for _branch to > Fishkill_, defined as "Any unexpected jump in a program that produces > catastrophic or just plain weird results" and attributed to IBM. Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth Edition was probably the source for this -- it includes both "branch to Fishkill" and "branch to Owego" with exactly this definition. -- Adam Sampson From marc.donner at gmail.com Sun Dec 11 03:15:24 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 10 Dec 2022 12:15:24 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: Mike is an old friend ... I will send him a copy of "Bringing a Chainsaw" and ask ... I don't think he was in Yorktown at the time but I probably told him about the work while it was happening. ===== nygeek.net mindthegapdialogs.com/home On Sat, Dec 10, 2022 at 11:56 AM Adam Sampson wrote: > John Cowan writes: > > > Some editions of the Jargon File contain an entry for _branch to > > Fishkill_, defined as "Any unexpected jump in a program that produces > > catastrophic or just plain weird results" and attributed to IBM. > > Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth > Edition was probably the source for > this -- it includes both "branch to Fishkill" and "branch to Owego" with > exactly this definition. > > -- > Adam Sampson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 11 05:38:45 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 10 Dec 2022 19:38:45 +0000 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? Message-ID: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> Good morning all. I've been doing some historical research on the UUCP cu utility this morning and have come across a little discrepancy between the various UNIX streams I was wondering if someone could illuminate. So cu as of V7 supported the ~$ escape, a means of calling a local procedure and emitting stdout over the TTY line to the remote machine, all fine and good for packaging a character stream to emit. However, what I'm not finding in that age of documentation is any means of requesting std*in* from the TTY line as input to a local procedure (in essence running a text filter or handshake-driven protocols over cu). The context in which I'm researching this is integrating cu into my bare-metal SBC programming using XMODEM so I can rest a little easier my process is based on tools I'll probably find in most places. So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no stdin. I did some further digging and it looks like different UUCP implementations cracked this nut with different escapes, with BSD eventually going with ~C and Taylor UUCP opting for ~+. Checking the current illumos manual pages (for a SVR4-ish example) doesn't turn up any command for this. This is indicative of there never being an agreed-upon mechanism for doing this, although I could see this being a very useful mechanism. What I'm curious about is if the lack of a bi-directional redirect in early cu is reflective of a lack of need for that sort of functionality at the time or that matters such as that were handled through a different mechanism. One thought I did have is that there wasn't file locking at the time (right?) and so theoretically nothing would prevent one from using a cu session on one terminal to send interactive commands and then a second using fd redirects in the shell to run filters/protocols separately of the interactive stream. - Matt G. From silent700 at gmail.com Sun Dec 11 10:07:33 2022 From: silent700 at gmail.com (Jason T) Date: Sat, 10 Dec 2022 18:07:33 -0600 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: On Thu, Dec 1, 2022 at 11:04 PM segaloco via TUHS wrote: > > Exciting development in the process of finding lost documentation, just sealed this one on eBay: https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY > > After the link is a (now closed) auction for a Western Electric 3B20S UNIX User's Manual Release 4.1, something I thought I'd never see and wasn't sure actually exited: print manuals for 4.x. This is quite cool, and I didn't know it existed, either. I'm looking forward to the scan of it, but if it's not too much trouble, I wonder if you could take a nice 600dpi color jpg scan of the cover as well? It might make a nice poster someday. -jt From clemc at ccc.com Sun Dec 11 10:22:35 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 10 Dec 2022 19:22:35 -0500 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> Message-ID: On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS wrote: > Good morning all. I've been doing some historical research on the UUCP cu > utility this morning and have come across a little discrepancy between the > various UNIX streams I was wondering if someone could illuminate. > Maybe. see below.... > > So cu as of V7 supported the ~$ escape, a means of calling a local > procedure and emitting stdout over the TTY line to the remote machine, all > fine and good for packaging a character stream to emit. However, what I'm > not finding in that age of documentation is any means of requesting std*in* > from the TTY line as input to a local procedure (in essence running a text > filter or handshake-driven protocols over cu). The context in which I'm > researching this is integrating cu into my bare-metal SBC programming using > XMODEM so I can rest a little easier my process is based on tools I'll > probably find in most places. > > So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no > stdin. I did some further digging and it looks like different UUCP > implementations cracked this nut with different escapes, with BSD > eventually going with ~C and Taylor UUCP opting for ~+. Checking the > current illumos manual pages (for a SVR4-ish example) doesn't turn up any > command for this. This is indicative of there never being an agreed-upon > mechanism for doing this, although I could see this being a very useful > mechanism. > maybe -- need to see more of what your session was like. I never remember missing anything I needed. > > What I'm curious about is if the lack of a bi-directional redirect in > early cu is reflective of a lack of need for that sort of functionality at > the time or that matters such as that were handled through a different > mechanism. I'm not sure I get the question. We did all sorts of redirection and used/abused cu and its friends all the time. I suspect I'm not understanding what you are trying to do. >From a history standpoint, cu(1) is just one of many programs in that family. In the mid/late 1970s, we used a program called 'connect' for Sixth Edition at CMU, IIRC the Purdue folks had a similar one which was called attach(1) and there was tip(1) which was from Case/UCB [Sam Leffler]. If you look in the USENIX archives, I bet you will find a 1/2 doz or so of programs in the ilk before V7. With V7 uucp. was delivered, so cu(1) began to make inroads as it had the advantage that it was set up to work on concert to uucico(8). Simply, V7 came out, and UUCP started to used and eventually the 'USENET' born, cu(1) sort of 'won' because most of the other programs tended to conflict with uucico(8) - plus since it was already there, people did not need something else. But if you had written one before V7, you often find sites sticking with what they had. There were a number of UNIX implementations of XMODEM and friends. The C version of Kermit (ckermit) was quite popular plus has connect(1)/tip(1)/cu(1) style functionality built into it, but .... IIRC does not obey the locks that uucico(8) wants so if you used it on TTYs that had a modem that uucico was trying grab, bad things happened. That said, in a microprocessor lab where you often dedicated. serial port to 'target' micro/pc, kermit worked well. My memory is there were also a bunch of two letter programs, rx/sx and rz/sz and the like. Frankly its been so long since I had any use for them, I've forgotten. Look in the both USENIX and the USENET source archives. Frankly, the last time I think I was trying to do this sort of thing, I was using Kermit. YMMV Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Sun Dec 11 10:42:14 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 10 Dec 2022 17:42:14 -0700 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? Message-ID: Clem Cole mentions kermit in connection with the question raised about the uses of the cu utility. As an FYI, Kermit's author, Frank da Cruz, is preparing a final release, version 10.0, and I've been working with him on testing builds in numerous environments. There are frequent updates during this work, and the latest snapshots can be found at https://kermitproject.org/ftp/kermit/pretest/ The x-YYYYMMDD.* bundles do not contain a leading directory, so be careful to unpack them in an empty directory. The build relies on a lengthy makefile with platform-specific target names, like irix65, linux, and solaris11: the leading comments in the makefile provide further guidance. ------------------------------------------------------------------------------- - 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: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From lm at mcvoy.com Sun Dec 11 12:16:28 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 10 Dec 2022 18:16:28 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: Message-ID: <20221211021628.GM8801@mcvoy.com> Wow, Kermit is still around? I think the last time I used that was around 1985. Are modems still a thing? On Sat, Dec 10, 2022 at 05:42:14PM -0700, Nelson H. F. Beebe wrote: > Clem Cole mentions kermit in connection with the question raised about > the uses of the cu utility. > > As an FYI, Kermit's author, Frank da Cruz, is preparing a final > release, version 10.0, and I've been working with him on testing > builds in numerous environments. There are frequent updates during > this work, and the latest snapshots can be found at > > https://kermitproject.org/ftp/kermit/pretest/ > > The x-YYYYMMDD.* bundles do not contain a leading directory, so be > careful to unpack them in an empty directory. The build relies on a > lengthy makefile with platform-specific target names, like irix65, > linux, and solaris11: the leading comments in the makefile provide > further guidance. > > ------------------------------------------------------------------------------- > - 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: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sun Dec 11 12:21:00 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Dec 2022 02:21:00 +0000 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: Here's the raw TIFFs of the quad-not-tri-fold. I don't know where cool kids upload their stuff these days, and I don't have a server on hand at present to pop them up on so here's the temporary service Google lottery turned up, these links are good for 5 days. These are just raws because I have no idea the "page order". I plan on doing another scan and proper PDF when I swing back around to my larger backlog of work. https://tempfile.io/en/UsIiCxdEX4GzNZD/preview https://tempfile.io/en/fBUARNk3iY7u2im/preview https://tempfile.io/en/oWlNbcWQDBXnD19/preview https://tempfile.io/en/CA51aK9E9AdOu7g/preview Btw if anyone has any hosting suggestions, I'm all ears. Part of the reason I've stuck with 300dpi in the past is simply finding somewhere that'll accept the behemoth of a scan a 600dpi of some of these hundred page manuals would be. Hosting is my main block. Granted, Warren has generally allowed space for the Documents for UNIX 4 collection, there's still the matter of me getting stuff to Warren in the first place. - Matt G. P.S. I didn't look at these, remembered at the last minute out the door so just scanned and uploaded. P.P.S. Scanned the 4.1 manual cover too.....in b/w, so need to do that one again. That won't be tonight, but I unbound it so will likely start on the formal scans once I'm moved. ------- Original Message ------- On Saturday, December 10th, 2022 at 4:07 PM, Jason T wrote: > On Thu, Dec 1, 2022 at 11:04 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > Exciting development in the process of finding lost documentation, just sealed this one on eBay: https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY > > > > After the link is a (now closed) auction for a Western Electric 3B20S UNIX User's Manual Release 4.1, something I thought I'd never see and wasn't sure actually exited: print manuals for 4.x. > > > This is quite cool, and I didn't know it existed, either. I'm looking > forward to the scan of it, but if it's not too much trouble, I wonder > if you could take a nice 600dpi color jpg scan of the cover as well? > It might make a nice poster someday. > > -jt From imp at bsdimp.com Sun Dec 11 12:26:09 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 10 Dec 2022 19:26:09 -0700 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211021628.GM8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> Message-ID: On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > Wow, Kermit is still around? I think the last time I used that was > around 1985. > > Are modems still a thing? > I used it last year... without a modem. Warner > On Sat, Dec 10, 2022 at 05:42:14PM -0700, Nelson H. F. Beebe wrote: > > Clem Cole mentions kermit in connection with the question raised about > > the uses of the cu utility. > > > > As an FYI, Kermit's author, Frank da Cruz, is preparing a final > > release, version 10.0, and I've been working with him on testing > > builds in numerous environments. There are frequent updates during > > this work, and the latest snapshots can be found at > > > > https://kermitproject.org/ftp/kermit/pretest/ > > > > The x-YYYYMMDD.* bundles do not contain a leading directory, so be > > careful to unpack them in an empty directory. The build relies on a > > lengthy makefile with platform-specific target names, like irix65, > > linux, and solaris11: the leading comments in the makefile provide > > further guidance. > > > > > ------------------------------------------------------------------------------- > > - 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: > http://www.math.utah.edu/~beebe/ - > > > ------------------------------------------------------------------------------- > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Dec 11 12:32:07 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 10 Dec 2022 18:32:07 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211021628.GM8801@mcvoy.com> Message-ID: <20221211023207.GN8801@mcvoy.com> On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > > > Wow, Kermit is still around? I think the last time I used that was > > around 1985. > > > > Are modems still a thing? > > I used it last year... without a modem. What problem does it solve that is not solved? From imp at bsdimp.com Sun Dec 11 12:33:54 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 10 Dec 2022 19:33:54 -0700 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211023207.GN8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> Message-ID: On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy wrote: > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > > > > > Wow, Kermit is still around? I think the last time I used that was > > > around 1985. > > > > > > Are modems still a thing? > > > > I used it last year... without a modem. > > What problem does it solve that is not solved? > Talking to my DEC Rainbow and downloading files to it? It was the go-to protocol of choice. Xmodem is available, but messes up file sizes. kermit just works with this device that's so slow it drops characters at 2400 baud. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 11 12:37:21 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Dec 2022 02:37:21 +0000 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> Message-ID: Luckily I can toss you my exact use-case with code. https://gitlab.com/segaloco/riscv-bits/-/blob/master/util/sxj.c Above is a little utility I spit out to very specifically perform XMODEM-CRC for the VisionFive RISC-V single-board computer. Word on the street is their recovery bootloader has a bug that prevents sx and other utilities from working properly. As far as I could tell, they don't send the standard ACK after each packet receipt, but instead some other character. I just opted to check for NAK and proceed if not received. In any case, the above should achieve XMODEM-CRC transmission to the JH7100 RISC-V chip over UART. The phenomenon I'm experiencing (and sorry, I'm not trying to turn this into Taylor UUCP troubleshooting, I promise) is that when using the ~$ escape, my code never receives the 'C' from the device to initiate XMODEM-CRC. I know it's reading local stdin still because if I type and submit a 'C', it picks up and starts transferring, likewise requiring me to submit a non-NAK character every packet. Otherwise it does work, so the stdout is going to the remote machine, but at least with ~$, the stdin from the serial line does stop showing on my screen, which made me think the redirect was happening, but it just seems to disappear off into the void (/dev/null?) while the local program reads local stdin and puts data out on the remote stdout. This does hold consistent with the manual verbiage for ~$, it only mentions stdout to remote, doesn't mention any ferrying of remote stdin into the local application being run. I know my utility works because I've used it in the place of sx in GNU screen and it works like a charm. Plus it does send​ to the device if I provide the expected acknowledgement characters from my local machine in cu. So this doesn't just turn into troubleshooting, all I hope to highlight here is getting stdin from the remote machine into a program launched via a ~ escape in cu, be it like the ~C option in BSD cu or ~+ option in Taylor. My curiosity is whether such a thing was in historic cu, and, if not, how it might have been accommodated otherwise. As always, thankful for the insight and feedback folks here provide! - Matt G. ------- Original Message ------- On Saturday, December 10th, 2022 at 4:22 PM, Clem Cole wrote: > On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS wrote: > >> Good morning all. I've been doing some historical research on the UUCP cu utility this morning and have come across a little discrepancy between the various UNIX streams I was wondering if someone could illuminate. > > Maybe. see below.... > >> So cu as of V7 supported the ~$ escape, a means of calling a local procedure and emitting stdout over the TTY line to the remote machine, all fine and good for packaging a character stream to emit. However, what I'm not finding in that age of documentation is any means of requesting std*in* from the TTY line as input to a local procedure (in essence running a text filter or handshake-driven protocols over cu). The context in which I'm researching this is integrating cu into my bare-metal SBC programming using XMODEM so I can rest a little easier my process is based on tools I'll probably find in most places. >> >> So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no stdin. I did some further digging and it looks like different UUCP implementations cracked this nut with different escapes, with BSD eventually going with ~C and Taylor UUCP opting for ~+. Checking the current illumos manual pages (for a SVR4-ish example) doesn't turn up any command for this. This is indicative of there never being an agreed-upon mechanism for doing this, although I could see this being a very useful mechanism. > > maybe -- need to see more of what your session was like. I never remember missing anything I needed. > >> What I'm curious about is if the lack of a bi-directional redirect in early cu is reflective of a lack of need for that sort of functionality at the time or that matters such as that were handled through a different mechanism. > > I'm not sure I get the question. We did all sorts of redirection and used/abused cu and its friends all the time. I suspect I'm not understanding what you are trying to do. > > From a history standpoint, cu(1) is just one of many programs in that family. In the mid/late 1970s, we used a program called 'connect' for Sixth Edition at CMU, IIRC the Purdue folks had a similar one which was called attach(1) and there was tip(1) which was from Case/UCB [Sam Leffler]. If you look in the USENIX archives, I bet you will find a 1/2 doz or so of programs in the ilk before V7. With V7 uucp. was delivered, so cu(1) began to make inroads as it had the advantage that it was set up to work on concert to uucico(8). Simply, V7 came out, and UUCP started to used and eventually the 'USENET' born, cu(1) sort of 'won' because most of the other programs tended to conflict with uucico(8) - plus since it was already there, people did not need something else. But if you had written one before V7, you often find sites sticking with what they had. > > There were a number of UNIX implementations of XMODEM and friends. The C version of Kermit (ckermit) was quite popular plus has connect(1)/tip(1)/cu(1) style functionality built into it, but .... IIRC does not obey the locks that uucico(8) wants so if you used it on TTYs that had a modem that uucico was trying grab, bad things happened. That said, in a microprocessor lab where you often dedicated. serial port to 'target' micro/pc, kermit worked well. My memory is there were also a bunch of two letter programs, rx/sx and rz/sz and the like. Frankly its been so long since I had any use for them, I've forgotten. Look in the both USENIX and the USENET source archives. > > Frankly, the last time I think I was trying to do this sort of thing, I was using Kermit. > > YMMV > Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Dec 11 12:39:55 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 10 Dec 2022 18:39:55 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> Message-ID: <20221211023955.GP8801@mcvoy.com> On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote: > On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy wrote: > > > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: > > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > > > > > > > Wow, Kermit is still around? I think the last time I used that was > > > > around 1985. > > > > > > > > Are modems still a thing? > > > > > > I used it last year... without a modem. > > > > What problem does it solve that is not solved? > > Talking to my DEC Rainbow and downloading files to it? It was the go-to > protocol of choice. Xmodem is available, but messes up file sizes. kermit > just works with this device that's so slow it drops characters at 2400 baud. OK, that is cool, but my question was what problem does it solve that we face today? Other than talking to 30-40 year old hardware. Why is Kermit still a thing? From bakul at iitbombay.org Sun Dec 11 12:49:12 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 10 Dec 2022 18:49:12 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211023955.GP8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> <20221211023955.GP8801@mcvoy.com> Message-ID: > On Dec 10, 2022, at 6:39 PM, Larry McVoy wrote: > > On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote: >> On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy wrote: >> >>> On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: >>>> On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: >>>> >>>>> Wow, Kermit is still around? I think the last time I used that was >>>>> around 1985. >>>>> >>>>> Are modems still a thing? >>>> >>>> I used it last year... without a modem. >>> >>> What problem does it solve that is not solved? >> >> Talking to my DEC Rainbow and downloading files to it? It was the go-to >> protocol of choice. Xmodem is available, but messes up file sizes. kermit >> just works with this device that's so slow it drops characters at 2400 baud. > > OK, that is cool, but my question was what problem does it solve that > we face today? Other than talking to 30-40 year old hardware. Why is > Kermit still a thing? I used it to connect to various RaspberryPis. Also to check what a GPS dongle was outputting. My ~/.kermrc has a date of Oct 2019. Later switched to minicom/picocom. Don't recall why. Kermit has a decent help system. From phil at ultimate.com Sun Dec 11 13:10:46 2022 From: phil at ultimate.com (Phil Budne) Date: Sat, 10 Dec 2022 22:10:46 -0500 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211023955.GP8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> <20221211023955.GP8801@mcvoy.com> Message-ID: <202212110310.2BB3AkSZ003506@ultimate.com> Larry McVoy asked: > Why is Kermit still a thing?> I've used it in recent-ish history to transfer files to ancient operating systems running under SimH. SimH will provide what looks like a serial mux to the ancient software and speaks TCP to the modern world. From crossd at gmail.com Sun Dec 11 14:17:43 2022 From: crossd at gmail.com (Dan Cross) Date: Sat, 10 Dec 2022 23:17:43 -0500 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211023955.GP8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> <20221211023955.GP8801@mcvoy.com> Message-ID: On Sat, Dec 10, 2022, 9:40 PM Larry McVoy wrote: > On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote: > > On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy wrote: > > > > > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: > > > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > > > > > > > > > Wow, Kermit is still around? I think the last time I used that was > > > > > around 1985. > > > > > > > > > > Are modems still a thing? > > > > > > > > I used it last year... without a modem. > > > > > > What problem does it solve that is not solved? > > > > Talking to my DEC Rainbow and downloading files to it? It was the go-to > > protocol of choice. Xmodem is available, but messes up file sizes. kermit > > just works with this device that's so slow it drops characters at 2400 > baud. > > OK, that is cool, but my question was what problem does it solve that > we face today? Other than talking to 30-40 year old hardware. Why is > Kermit still a thing? > Aside from talking to legacy systems, the Kermit protocol probably has little to recommend it (xmodem specifically still gets a bit of a workout in embedded/firmware spaces because it's dead simple). Kermit as a communications swiss army knife of a program is probably more useful. That said, I could see it for downloading bulk data from scada systems over a slow link (RF, serial, or maybe some weird 7 bit thing). I tend to doubt that's happening much with Kermit these days, though. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Dec 11 14:45:23 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 10 Dec 2022 22:45:23 -0600 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> <20221211023955.GP8801@mcvoy.com> Message-ID: <9f49e6b0-e12a-d4c5-a021-fdc4409c32c8@gmail.com> On 12/10/22 10:17 PM, Dan Cross wrote: > On Sat, Dec 10, 2022, 9:40 PM Larry McVoy wrote: > > On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote: > > On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy wrote: > > > > > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote: > > > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy wrote: > > > > > > > > > Wow, Kermit is still around?  I think the last time I used > that was > > > > > around 1985. > > > > > > > > > > Are modems still a thing? > > > > > > > > I used it last year... without a modem. > > > > > > What problem does it solve that is not solved? > > > > Talking to my DEC Rainbow and downloading files to it? It was > the go-to > > protocol of choice. Xmodem is available, but messes up file > sizes. kermit > > just works with this device that's so slow it drops characters > at 2400 baud. > > OK, that is cool, but my question was what problem does it solve that > we face today?  Other than talking to 30-40 year old hardware.  Why is > Kermit still a thing? > > > Aside from talking to legacy systems, the Kermit protocol probably has > little to recommend it (xmodem specifically still gets a bit of a > workout in embedded/firmware spaces because it's dead simple). Kermit > as a communications swiss army knife of a program is probably more useful. > > That said, I could see it for downloading bulk data from scada systems > over a slow link (RF, serial, or maybe some weird 7 bit thing). I tend > to doubt that's happening much with Kermit these days, though. It works, it's not flaky and it will talk to practically anything. I use it for talking with virtual systems running older OSes (Mac, unix, etc) where other stuff doesn't or just sorta works, if you can run kermit and theres a path, it'll prolly work more often than not, and certainly more than more exotic stuff. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Dec 11 16:28:03 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 11 Dec 2022 01:28:03 -0500 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: Okay, I've done a quick and dirty conversion to PDF and put it on line. My public Google Drive folder is , and the file is oap-ef.pdf (all four pages). On Sat, Dec 10, 2022 at 9:21 PM segaloco via TUHS wrote: > Here's the raw TIFFs of the quad-not-tri-fold. I don't know where cool > kids upload their stuff these days, and I don't have a server on hand at > present to pop them up on so here's the temporary service Google lottery > turned up, these links are good for 5 days. These are just raws because I > have no idea the "page order". I plan on doing another scan and proper PDF > when I swing back around to my larger backlog of work. > > https://tempfile.io/en/UsIiCxdEX4GzNZD/preview > https://tempfile.io/en/fBUARNk3iY7u2im/preview > https://tempfile.io/en/oWlNbcWQDBXnD19/preview > https://tempfile.io/en/CA51aK9E9AdOu7g/preview > > Btw if anyone has any hosting suggestions, I'm all ears. Part of the > reason I've stuck with 300dpi in the past is simply finding somewhere > that'll accept the behemoth of a scan a 600dpi of some of these hundred > page manuals would be. Hosting is my main block. Granted, Warren has > generally allowed space for the Documents for UNIX 4 collection, there's > still the matter of me getting stuff to Warren in the first place. > > - Matt G. > > P.S. I didn't look at these, remembered at the last minute out the door so > just scanned and uploaded. > > P.P.S. Scanned the 4.1 manual cover too.....in b/w, so need to do that one > again. That won't be tonight, but I unbound it so will likely start on the > formal scans once I'm moved. > > ------- Original Message ------- > On Saturday, December 10th, 2022 at 4:07 PM, Jason T > wrote: > > > > On Thu, Dec 1, 2022 at 11:04 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > > > Exciting development in the process of finding lost documentation, > just sealed this one on eBay: > https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY > > > > > > After the link is a (now closed) auction for a Western Electric 3B20S > UNIX User's Manual Release 4.1, something I thought I'd never see and > wasn't sure actually exited: print manuals for 4.x. > > > > > > This is quite cool, and I didn't know it existed, either. I'm looking > > forward to the scan of it, but if it's not too much trouble, I wonder > > if you could take a nice 600dpi color jpg scan of the cover as well? > > It might make a nice poster someday. > > > > -jt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e5655f30a07f at ewoof.net Sun Dec 11 23:59:20 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 11 Dec 2022 13:59:20 +0000 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> Message-ID: <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> On 10 Dec 2022 19:22 -0500, from clemc at ccc.com (Clem Cole): > My memory is there were also a bunch of two > letter programs, rx/sx and rz/sz and the like. Frankly its been so long > since I had any use for them, I've forgotten. I remember at least sz/rz from my early (for me) forays into UNIX, back when ZModem was pretty much state of the art at least on micros and I had files locally that I wanted remotely or vice versa. The mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of course, being local to the remote host, so the opposite sense of what one would do with the terminal emulator program that one interacted with locally. So "sz " at the prompt, then activate the "receive ZModem transfer" function locally; or "rz ", then activate the "send using ZModem" function locally. I think the host I was on at the time (which appears to have been some Solaris) also offered XModem and YModem variants as [rs][xy], but I never used those because someone had at some point told me that ZModem was better. :-) -- ✍  Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From usotsuki at buric.co Mon Dec 12 00:28:13 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 11 Dec 2022 09:28:13 -0500 (EST) Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> Message-ID: On Sun, 11 Dec 2022, Michael Kjörling wrote: > On 10 Dec 2022 19:22 -0500, from clemc at ccc.com (Clem Cole): >> My memory is there were also a bunch of two >> letter programs, rx/sx and rz/sz and the like. Frankly its been so long >> since I had any use for them, I've forgotten. > > I remember at least sz/rz from my early (for me) forays into UNIX, > back when ZModem was pretty much state of the art at least on micros > and I had files locally that I wanted remotely or vice versa. The > mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of > course, being local to the remote host, so the opposite sense of what > one would do with the terminal emulator program that one interacted > with locally. So "sz " at the prompt, then activate the > "receive ZModem transfer" function locally; or "rz ", then > activate the "send using ZModem" function locally. > > I think the host I was on at the time (which appears to have been some > Solaris) also offered XModem and YModem variants as [rs][xy], but I > never used those because someone had at some point told me that ZModem > was better. :-) Kind-of a pain to type as I'm SSHing in from my phone, but they still exist and I have "lrzsz" installed on my Debian box. -uso. From crossd at gmail.com Mon Dec 12 01:04:54 2022 From: crossd at gmail.com (Dan Cross) Date: Sun, 11 Dec 2022 10:04:54 -0500 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> Message-ID: On Sun, Dec 11, 2022 at 9:28 AM Steve Nickolas wrote: > On Sun, 11 Dec 2022, Michael Kjörling wrote: > > On 10 Dec 2022 19:22 -0500, from clemc at ccc.com (Clem Cole): > >> My memory is there were also a bunch of two > >> letter programs, rx/sx and rz/sz and the like. Frankly its been so long > >> since I had any use for them, I've forgotten. > > > > I remember at least sz/rz from my early (for me) forays into UNIX, > > back when ZModem was pretty much state of the art at least on micros > > and I had files locally that I wanted remotely or vice versa. The > > mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of > > course, being local to the remote host, so the opposite sense of what > > one would do with the terminal emulator program that one interacted > > with locally. So "sz " at the prompt, then activate the > > "receive ZModem transfer" function locally; or "rz ", then > > activate the "send using ZModem" function locally. > > > > I think the host I was on at the time (which appears to have been some > > Solaris) also offered XModem and YModem variants as [rs][xy], but I > > never used those because someone had at some point told me that ZModem > > was better. :-) > > Kind-of a pain to type as I'm SSHing in from my phone, but they still > exist and I have "lrzsz" installed on my Debian box. And as I mentioned earlier, they're still very much used. I recently wrote the initial bootstrap program that runs when the x86 cores on our machine come out of reset (https://github.com/oxidecomputer/phbl/). However, that's for production use; for internal engineering use we have _another_ tool, also written in Rust, that is an interactive standalone program. This lets us do things like poke at physical memory, read/write MSRs, and all of that fun stuff, before loading an operating system. So how does one load the OS? Our machine has a part that includes a 3 MBAUD-capable UART, and we use xmodem to transfer the kernel (and a ramdisk image!) over that, where the engineering tool can load and jump into it. The standalone program implements xmodem internally, whereas we use `sx` on the dev host side. Basically, there is a built-in commands to perform the transfer, another that effectively says "there's an ELF image in physical memory $here: load it and return the entry point" and finally another command that can jump to an arbitrary virtual address (yes, we load the host OS in 64-bit mode and treat the kernel like any old "normal" ELF binary). As the ramdisk image has grown (more and more debugging tools are included as we move ever forward in the bringup and development process), latency here is annoying. I added support for compressed kernel and ramdisk images, which gave a 2.5x speedup (directly proportional to the usual compression ratio we see on these images) which ameliorated but did not eliminate the pain. We briefly tossed around the idea of implementing zmodem, but decided it wasn't worth it. We _could_, in theory, make use of the enhanced kermit with sliding windows and so on, but again decided it wasn't worth the effort for an engineering tool. Incidentally, my colleague Matt Keeter ran into performance and reliability issues with xmodem over the USB serial driver in macOS, and wrote a small shim that side-stepped the host OS device. He did a nice write-up of it here: https://www.mattkeeter.com/blog/2022-05-31-xmodem/ I think this is in line with Larry's question about non-legacy use-cases for these ancient serial transfer protocols in late 2022. - Dan C. From athornton at gmail.com Mon Dec 12 03:18:38 2022 From: athornton at gmail.com (Adam Thornton) Date: Sun, 11 Dec 2022 10:18:38 -0700 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> Message-ID: In the late 1990s I did a brief consulting project to move files between sites. Something to do with customer billing and record transmission, from some large system that was not Internet-connected. It ended up being a terrible teetering tower of kermit, sz or sx, and expect. But it got the job done! The funny thing about that...the project spanned the July 4th weekend. I didn't get it working before the 4th. Then when I went in very hungover after the weekend, I couldn't figure out quite what I had been trying to do, because it was something that was attempting to be very clever. So in my dulled state, I rewrote the bottom layers to be much more straightforward. Worked the first time. That taught me the virtue of not overthinking it. Adam From ralph at inputplus.co.uk Mon Dec 12 03:40:07 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 11 Dec 2022 17:40:07 +0000 Subject: [TUHS] Bell Office Automation System (OAS)? In-Reply-To: References: Message-ID: <20221211174007.5BEA721FDD@orac.inputplus.co.uk> Hi andrew, > i wrote ef. Was its name from ed → ee → ef or something else? -- Cheers, Ralph. From e5655f30a07f at ewoof.net Mon Dec 12 04:54:22 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 11 Dec 2022 18:54:22 +0000 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> Message-ID: <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> On 11 Dec 2022 10:18 -0700, from athornton at gmail.com (Adam Thornton): > The funny thing about that...the project spanned the July 4th > weekend. I didn't get it working before the 4th. Then when I went in > very hungover after the weekend, I couldn't figure out quite what I > had been trying to do, because it was something that was attempting > to be very clever. So in my dulled state, I rewrote the bottom > layers to be much more straightforward. Worked the first time. That > taught me the virtue of not overthinking it. By definition, if you write code as cleverly as you can, then you aren't clever enough to debug it... There's something to be said for simplicity unless for some reason you really need to be clever. Let's save the clever for the, say, 1% where it's actually needed; premature application of cleverness is the root of much evil. -- ✍  Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From dave at horsfall.org Mon Dec 12 05:55:31 2022 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 12 Dec 2022 06:55:31 +1100 (EST) Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> Message-ID: On Sun, 11 Dec 2022, Michael Kjörling wrote: > By definition, if you write code as cleverly as you can, then you aren't > clever enough to debug it... Indeed... I've always used the maxim "Write code as though the next person to maintain it is an axe-wielding psychopath who knows where you live". -- Dave From lm at mcvoy.com Mon Dec 12 06:03:27 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 11 Dec 2022 12:03:27 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> Message-ID: <20221211200327.GC8801@mcvoy.com> On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote: > On Sun, 11 Dec 2022, Michael Kj??rling wrote: > > > By definition, if you write code as cleverly as you can, then you aren't > > clever enough to debug it... > > Indeed... > > I've always used the maxim "Write code as though the next person to > maintain it is an axe-wielding psychopath who knows where you live". My main job, for the 20 years until I retired, was to keep telling people that code that you wrote 6 months ago might as well have been written by someone else. Optimize for reading the code, not writing the code. It's read many. 99.9% of the time, I detest clever code. .1% of the time, I need it. The problem is that smart engineers adore writing clever code. They usually, eventually, wise up. From marc.donner at gmail.com Mon Dec 12 08:23:00 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 11 Dec 2022 17:23:00 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: I heard from Mike Cowlishaw about the IBM jargon items "branch to Fishkill" and "branch to Owego" They reflect a set of site pairs within IBM in which one site designed and made hardware (Fishkill, Owego) and another site designs and builds software (Kingston, Endicott). To the software folks the hardware world was esoteric and weird, hence the branch targets for weirdness were the hardware sites. ===== nygeek.net mindthegapdialogs.com/home On Sat, Dec 10, 2022 at 12:15 PM Marc Donner wrote: > Mike is an old friend ... I will send him a copy of "Bringing a Chainsaw" > and ask ... I don't think he was in Yorktown at the time but I probably > told him about the work while it was happening. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sat, Dec 10, 2022 at 11:56 AM Adam Sampson wrote: > >> John Cowan writes: >> >> > Some editions of the Jargon File contain an entry for _branch to >> > Fishkill_, defined as "Any unexpected jump in a program that produces >> > catastrophic or just plain weird results" and attributed to IBM. >> >> Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth >> Edition was probably the source for >> this -- it includes both "branch to Fishkill" and "branch to Owego" with >> exactly this definition. >> >> -- >> Adam Sampson >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Mon Dec 12 08:47:20 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 11 Dec 2022 17:47:20 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: Thanks again! I'll pass this on to Eric Raymond, current maintainer of the Jargon File. On Sun, Dec 11, 2022 at 5:24 PM Marc Donner wrote: > I heard from Mike Cowlishaw about the IBM jargon items "branch to > Fishkill" and "branch to Owego" > > They reflect a set of site pairs within IBM in which one site designed and > made hardware (Fishkill, Owego) and another site designs and builds > software (Kingston, Endicott). To the software folks the hardware world > was esoteric and weird, hence the branch targets for weirdness were the > hardware sites. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sat, Dec 10, 2022 at 12:15 PM Marc Donner > wrote: > >> Mike is an old friend ... I will send him a copy of "Bringing a Chainsaw" >> and ask ... I don't think he was in Yorktown at the time but I probably >> told him about the work while it was happening. >> ===== >> nygeek.net >> mindthegapdialogs.com/home >> >> >> On Sat, Dec 10, 2022 at 11:56 AM Adam Sampson wrote: >> >>> John Cowan writes: >>> >>> > Some editions of the Jargon File contain an entry for _branch to >>> > Fishkill_, defined as "Any unexpected jump in a program that produces >>> > catastrophic or just plain weird results" and attributed to IBM. >>> >>> Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth >>> Edition was probably the source for >>> this -- it includes both "branch to Fishkill" and "branch to Owego" with >>> exactly this definition. >>> >>> -- >>> Adam Sampson >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Mon Dec 12 08:50:23 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 11 Dec 2022 17:50:23 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: If so, please rewrite my garbling of Mike's comments into something resembling English :-) ===== nygeek.net mindthegapdialogs.com/home On Sun, Dec 11, 2022 at 5:47 PM John Cowan wrote: > Thanks again! I'll pass this on to Eric Raymond, current maintainer of > the Jargon File. > > On Sun, Dec 11, 2022 at 5:24 PM Marc Donner wrote: > >> I heard from Mike Cowlishaw about the IBM jargon items "branch to >> Fishkill" and "branch to Owego" >> >> They reflect a set of site pairs within IBM in which one site designed >> and made hardware (Fishkill, Owego) and another site designs and builds >> software (Kingston, Endicott). To the software folks the hardware world >> was esoteric and weird, hence the branch targets for weirdness were the >> hardware sites. >> ===== >> nygeek.net >> mindthegapdialogs.com/home >> >> >> On Sat, Dec 10, 2022 at 12:15 PM Marc Donner >> wrote: >> >>> Mike is an old friend ... I will send him a copy of "Bringing a >>> Chainsaw" and ask ... I don't think he was in Yorktown at the time but I >>> probably told him about the work while it was happening. >>> ===== >>> nygeek.net >>> mindthegapdialogs.com/home >>> >>> >>> On Sat, Dec 10, 2022 at 11:56 AM Adam Sampson wrote: >>> >>>> John Cowan writes: >>>> >>>> > Some editions of the Jargon File contain an entry for _branch to >>>> > Fishkill_, defined as "Any unexpected jump in a program that produces >>>> > catastrophic or just plain weird results" and attributed to IBM. >>>> >>>> Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth >>>> Edition was probably the source for >>>> this -- it includes both "branch to Fishkill" and "branch to Owego" with >>>> exactly this definition. >>>> >>>> -- >>>> Adam Sampson >>> > >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Dec 12 09:22:14 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Dec 2022 23:22:14 +0000 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211200327.GC8801@mcvoy.com> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> <20221211200327.GC8801@mcvoy.com> Message-ID: Readable code also contributes to easier documentation. It's easier to maintain a manual when you can just translate the code into the local language. My current team started small and I learned pretty soon that time invested in a habit of readable code meant less time spent providing the person assigned documentation the juicy details. - Matt G. ------- Original Message ------- On Sunday, December 11th, 2022 at 12:03 PM, Larry McVoy wrote: > On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote: > > > On Sun, 11 Dec 2022, Michael Kj??rling wrote: > > > > > By definition, if you write code as cleverly as you can, then you aren't > > > clever enough to debug it... > > > > Indeed... > > > > I've always used the maxim "Write code as though the next person to > > maintain it is an axe-wielding psychopath who knows where you live". > > > My main job, for the 20 years until I retired, was to keep telling > people that code that you wrote 6 months ago might as well have been > written by someone else. Optimize for reading the code, not writing > the code. It's read many. > > 99.9% of the time, I detest clever code. .1% of the time, I need it. > The problem is that smart engineers adore writing clever code. They > usually, eventually, wise up. From cowan at ccil.org Mon Dec 12 11:32:45 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 11 Dec 2022 20:32:45 -0500 Subject: [TUHS] Bringing a Chainsaw In-Reply-To: References: Message-ID: Will do! On Sun, Dec 11, 2022 at 5:50 PM Marc Donner wrote: > If so, please rewrite my garbling of Mike's comments into something > resembling English :-) > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sun, Dec 11, 2022 at 5:47 PM John Cowan wrote: > >> Thanks again! I'll pass this on to Eric Raymond, current maintainer of >> the Jargon File. >> >> On Sun, Dec 11, 2022 at 5:24 PM Marc Donner >> wrote: >> >>> I heard from Mike Cowlishaw about the IBM jargon items "branch to >>> Fishkill" and "branch to Owego" >>> >>> They reflect a set of site pairs within IBM in which one site designed >>> and made hardware (Fishkill, Owego) and another site designs and builds >>> software (Kingston, Endicott). To the software folks the hardware world >>> was esoteric and weird, hence the branch targets for weirdness were the >>> hardware sites. >>> ===== >>> nygeek.net >>> mindthegapdialogs.com/home >>> >>> >>> On Sat, Dec 10, 2022 at 12:15 PM Marc Donner >>> wrote: >>> >>>> Mike is an old friend ... I will send him a copy of "Bringing a >>>> Chainsaw" and ask ... I don't think he was in Yorktown at the time but I >>>> probably told him about the work while it was happening. >>>> ===== >>>> nygeek.net >>>> mindthegapdialogs.com/home >>>> >>>> >>>> On Sat, Dec 10, 2022 at 11:56 AM Adam Sampson wrote: >>>> >>>>> John Cowan writes: >>>>> >>>>> > Some editions of the Jargon File contain an entry for _branch to >>>>> > Fishkill_, defined as "Any unexpected jump in a program that produces >>>>> > catastrophic or just plain weird results" and attributed to IBM. >>>>> >>>>> Mike Cowlishaw's IBM Jargon and General Computing Dictionary, Tenth >>>>> Edition was probably the source >>>>> for >>>>> this -- it includes both "branch to Fishkill" and "branch to Owego" >>>>> with >>>>> exactly this definition. >>>>> >>>>> -- >>>>> Adam Sampson < >>>>> http://offog.org/> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Dec 12 11:56:51 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 12 Dec 2022 11:56:51 +1000 Subject: [TUHS] Archive search down? In-Reply-To: References: Message-ID: On Fri, Nov 25, 2022 at 11:55:14AM -0800, Joseph Holsten wrote: > Is the search page supposed to be down at https://minnie.tuhs.org/cgi-bin/mailman/tuhs.cgi? It's fixed now :-) Thanks to Joseph and Greg Lehey for reminding me! Cheers, Warren From bakul at iitbombay.org Mon Dec 12 12:15:47 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 11 Dec 2022 18:15:47 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211200327.GC8801@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> Message-ID: <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> On Dec 11, 2022, at 12:04 PM, Larry McVoy wrote: > > > > On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote: >> On Sun, 11 Dec 2022, Michael Kj??rling wrote: >> >>> By definition, if you write code as cleverly as you can, then you aren't >>> clever enough to debug it... >> >> Indeed... >> >> I've always used the maxim "Write code as though the next person to >> maintain it is an axe-wielding psychopath who knows where you live". > > My main job, for the 20 years until I retired, was to keep telling > people that code that you wrote 6 months ago might as well have been > written by someone else. Optimize for reading the code, not writing > the code. It's read many. > > 99.9% of the time, I detest clever code. .1% of the time, I need it. > The problem is that smart engineers adore writing clever code. They > usually, eventually, wise up. Agree that clear code is preferable to complicated code. But in practice people sacrifice clarity for performance improvement all the time. Look at the kernel code of any modern os. Everybody pays lip service to this but most anything other than toy programs ends up getting needlessly complicated over time. As an example, building "Unix as a service" as user processes on top of a small microkernel could provide the same functionality using much clearer and much less code but it would be slower so we don't do it. Plan9 sort of went in that direction and it is much simpler (but that could also be because it is not hacked on so much). I do prefer clever/smart design to locally clever/smart code. For example, using Schönhage-Strassen algorithm for multiplying very large numbers. Or transforming a problem to use a much more efficient data structure or making equivalent transforms which may be more efficient to compute. Such code may not be immediately clear but with proper documentation it is not difficult + you can solve much larger problems. But agreed these come up much less often. From tuhs at tuhs.org Mon Dec 12 12:17:31 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 12 Dec 2022 12:17:31 +1000 Subject: [TUHS] Draft 1 of K&R C Book - scan available In-Reply-To: References: Message-ID: On Thu, Dec 08, 2022 at 03:39:50PM -0800, Tom Lyon wrote: > I finally got myself a decent scanner, and have scanned my most prized > relic from my summer at Bell Labs - Draft 1 of Kernighan and Ritchie's > "The C Programming Language". Many thanks for the scan, Tom. I've taken a copy and put it in the Unix Archive here: https://www.tuhs.org/Archive/Documentation/Books/ Cheers, Warren From usotsuki at buric.co Mon Dec 12 12:44:20 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 11 Dec 2022 21:44:20 -0500 (EST) Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> Message-ID: On Sun, 11 Dec 2022, Bakul Shah wrote: > Agree that clear code is preferable to complicated code. But in practice > people sacrifice clarity for performance improvement all the time. Look > at the kernel code of any modern os. Everybody pays lip service to this > but most anything other than toy programs ends up getting needlessly > complicated over time. As an example, building "Unix as a service" as > user processes on top of a small microkernel could provide the same > functionality using much clearer and much less code but it would be > slower so we don't do it. Plan9 sort of went in that direction and it > is much simpler (but that could also be because it is not hacked on so > much). > > I do prefer clever/smart design to locally clever/smart code. For example, > using Schönhage-Strassen algorithm for multiplying very large numbers. > Or transforming a problem to use a much more efficient data structure > or making equivalent transforms which may be more efficient to compute. > Such code may not be immediately clear but with proper documentation > it is not difficult + you can solve much larger problems. But agreed > these come up much less often. My attitude is: if I'm doing an ugly on nonobvious hack, I'll drop a comment saying what it does. Most recently I wrote code that set a "magic flag" - and the comment explained why the flag was set (so that it would be immediately altered, forcing a redraw). -uso. From andreww591 at gmail.com Mon Dec 12 13:09:32 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Sun, 11 Dec 2022 20:09:32 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> Message-ID: On 12/11/22, Bakul Shah wrote: > > > Agree that clear code is preferable to complicated code. But in practice > people sacrifice clarity for performance improvement all the time. Look > at the kernel code of any modern os. Everybody pays lip service to this > but most anything other than toy programs ends up getting needlessly > complicated over time. As an example, building "Unix as a service" as > user processes on top of a small microkernel could provide the same > functionality using much clearer and much less code but it would be > slower so we don't do it. Plan9 sort of went in that direction and it > is much simpler (but that could also be because it is not hacked on so > much). > It's not necessarily true that microkernels are significantly slower. They mostly got that reputation because of Mach and kernels like it with their heavyweight IPC. Lightweight microkernels like QNX and the L4 family generally have significantly better performance (in fact, QNX 4 outperformed SysV/386 back in the 90s on certain benchmarks, and a proof-of-concept network driver on a current version of seL4 is significantly faster than a Linux network driver). From lm at mcvoy.com Mon Dec 12 13:34:53 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 11 Dec 2022 19:34:53 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> Message-ID: <20221212033453.GE8801@mcvoy.com> On Sun, Dec 11, 2022 at 08:09:32PM -0700, Andrew Warkentin wrote: > On 12/11/22, Bakul Shah wrote: > > > > > > Agree that clear code is preferable to complicated code. But in practice > > people sacrifice clarity for performance improvement all the time. Look > > at the kernel code of any modern os. Everybody pays lip service to this > > but most anything other than toy programs ends up getting needlessly > > complicated over time. As an example, building "Unix as a service" as > > user processes on top of a small microkernel could provide the same > > functionality using much clearer and much less code but it would be > > slower so we don't do it. Plan9 sort of went in that direction and it > > is much simpler (but that could also be because it is not hacked on so > > much). > > > > It's not necessarily true that microkernels are significantly slower. > They mostly got that reputation because of Mach and kernels like it > with their heavyweight IPC. Lightweight microkernels like QNX and the > L4 family generally have significantly better performance (in fact, > QNX 4 outperformed SysV/386 back in the 90s on certain benchmarks, and > a proof-of-concept network driver on a current version of seL4 is > significantly faster than a Linux network driver). I was friends with one of the 3 people who were allowed to commit to QNX kernel, Dan Hildebrandt (RIP 1998). Those 3 people actually understood the "micro" in "microkernel". Early versions of QNX kernel fit in the 4K instruction cache and left space for user programs. They had benchmarks that measured cache misses and refused commits that added to the number of cache misses. I met Dan because I had 10 terminals on a 80286 with I think 256KB of memory and we were all editing and compiling and it worked way the heck better than a 11/780 with 4MB with 30-40 students trying to do the same thing. I just wanted to talk to the people who made that possible, it was after I had made a connection to Dennis. The early QNX people were special. Dan and I had many conversations about the mono kernel vs micro kernel, it was super fun because we weren't trying to convince each other, we were comparing approaches. I've never seen a team like Dan's team that cared as much as they did about "micro" actually being micro. That's the only way that that approach works. I can not state that enough, if you want to have a micro kernel with message passing, if you don't fit in L1 cache, you are a joke compared to a mono kernel. You have to embrace micro. I had hoped that Mach would be like that but it was a giant mess. I know my opinion is not liked but I so wanted to like Mach, read the papers, loved it, then read the code, hated it, a few years ago I was working with the BSD team at Netflix, looked through the VM system from Mach and it was a mess, it was the exact opposite of my experience at Sun where I looked and looked and things came in focus and it made sense. The Mach stuff has never made sense to me, I know Clem says it was a research platform, OK, but the platform never got to a nice clean place. If you think of microkernels and think Mach is it, nope, look at QNX. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From kevin.bowling at kev009.com Mon Dec 12 15:00:22 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 11 Dec 2022 22:00:22 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221212033453.GE8801@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: On Sun, Dec 11, 2022 at 8:35 PM Larry McVoy wrote: > > On Sun, Dec 11, 2022 at 08:09:32PM -0700, Andrew Warkentin wrote: > > On 12/11/22, Bakul Shah wrote: > > > > > > > > > Agree that clear code is preferable to complicated code. But in practice > > > people sacrifice clarity for performance improvement all the time. Look > > > at the kernel code of any modern os. Everybody pays lip service to this > > > but most anything other than toy programs ends up getting needlessly > > > complicated over time. As an example, building "Unix as a service" as > > > user processes on top of a small microkernel could provide the same > > > functionality using much clearer and much less code but it would be > > > slower so we don't do it. Plan9 sort of went in that direction and it > > > is much simpler (but that could also be because it is not hacked on so > > > much). > > > > > > > It's not necessarily true that microkernels are significantly slower. > > They mostly got that reputation because of Mach and kernels like it > > with their heavyweight IPC. Lightweight microkernels like QNX and the > > L4 family generally have significantly better performance (in fact, > > QNX 4 outperformed SysV/386 back in the 90s on certain benchmarks, and > > a proof-of-concept network driver on a current version of seL4 is > > significantly faster than a Linux network driver). > > I was friends with one of the 3 people who were allowed to commit to QNX > kernel, Dan Hildebrandt (RIP 1998). Those 3 people actually understood > the "micro" in "microkernel". Early versions of QNX kernel fit in > the 4K instruction cache and left space for user programs. They had > benchmarks that measured cache misses and refused commits that added to > the number of cache misses. > > I met Dan because I had 10 terminals on a 80286 with I think 256KB > of memory and we were all editing and compiling and it worked way the > heck better than a 11/780 with 4MB with 30-40 students trying to do the > same thing. I just wanted to talk to the people who made that possible, > it was after I had made a connection to Dennis. The early QNX people > were special. Dan and I had many conversations about the mono kernel > vs micro kernel, it was super fun because we weren't trying to convince > each other, we were comparing approaches. > > I've never seen a team like Dan's team that cared as much as they did > about "micro" actually being micro. That's the only way that that > approach works. I can not state that enough, if you want to have a > micro kernel with message passing, if you don't fit in L1 cache, > you are a joke compared to a mono kernel. You have to embrace > micro. > > I had hoped that Mach would be like that but it was a giant mess. I know > my opinion is not liked but I so wanted to like Mach, read the papers, > loved it, then read the code, hated it, a few years ago I was working > with the BSD team at Netflix, looked through the VM system from Mach > and it was a mess, it was the exact opposite of my experience at Sun > where I looked and looked and things came in focus and it made sense. > The Mach stuff has never made sense to me, I know Clem says it was a > research platform, OK, but the platform never got to a nice clean place. Mach seems not incompatible to me to Windows NT ideas of layering, especially in modern macOS guise, more so than a microkernel I'd call it something like a "macrokernel" with a variety of ways to do things.. dealer's choice for better and worse. It is interesting to note the success, often overlooked by more hardline *nix people, that macOS (and iOS and tvOS and watchOS etc) is indeed mach (more so than it is BSD as some people claim) and wildly successful. > If you think of microkernels and think Mach is it, nope, look at QNX. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From andreww591 at gmail.com Mon Dec 12 15:26:37 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Sun, 11 Dec 2022 22:26:37 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221212033453.GE8801@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: On 12/11/22, Larry McVoy wrote: > > If you think of microkernels and think Mach is it, nope, look at QNX. > And yet, for some reason, QNX has had almost no influence on anything else besides a few hobby OSes (only one of which ever reached a reasonably mature state) as far as I can tell. I really don't get why that is. As far as I know, I'm the only one who's working on a QNX-like OS that's not QNX itself. From tuhs at tuhs.org Mon Dec 12 16:15:22 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 Dec 2022 06:15:22 +0000 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: Analysis time now that I've actually sat down with the 3.0, 4.1, and 5.0 manuals and looked at several things side-by-side. Very raw notes are here: https://pastebin.com/m7K4jxn5 The first and most obvious thing is that the 4.1 manual does not include the 1M, 7, and 8 manual sections, just like the 5.0 manual, so I unfortunately still do not have a complete picture of the userland environment available in UNIX 4.x. That means there is a second manual, the 3B20S UNIX Administrator's Manual Release 4.1, somewhere out there in the wild. Maybe I'll come across it someday, who knows. In any case, 4.1 sees the manual page sections swap from their 3.0 to their 5.0 configuration, so special files moved to 7 and those before it shuffled a bit. The title page has minor changes. 4.1 sees the removal of the editor names and Laboratory 364 address, moves the Bell Labs trademark notice to the front page, and adds the not for disclosure text. 5.0 only seems to add "System" to the title name. The intro undergoes several changes between 3.0 and 4.1, but relatively few between 4.1 and 5.0, meaning the wealth of the rewrite was in the 4.x period. Notable changes include: - Hardware-specific pages will be noted in the page mast - Obsolete functions will be marked as such - References to dpr and fget as example networking applications are replaced with send and uucp, moving from RJE to UUCP? - A reference to UNIX as a "supervisor" is updated to "kernel" As for utilities, this manual is indeed 3B20 specific in that it omits many pieces that either weren't available on 3B20 yet at the time or weren't relevant to the platform. Notable omissions include SNOBOL, Fortran, and BASIC. We see IPC start to take form here, with all SysV IPC interfaces except icprm provided in 4.1. Icprm is then provided in 5.0. 4.1 also marks the replacement of cref and xref with cxref, which survives to this day in the POSIX standard. Another POSIX utility, cflow, is also added to 4.1. The LP printing service also finds its start in 4.1. A few 3B20 development tools such as a disassembler and C source listing application are added. Unknown to what degree this sort of thing was supported on various architectures. There is a slight adjustment to the Virtual Protocol Machine (vpm) interface in 4.1, dropping vpmstart for vpmsave and vpmset. 4.1 sees the removal of mmcheck and typo utilities, presumably starting to be split off towards WWB/DWB-land, although the UNIX 5.0 Bell Labs manual I have does have more of those sorts of commands. I didn't pull that one in this analysis, I'll compare that one to the Western Electric 5.0 at a later time. An application in 3.0 called dump for some sort of filesystem dumping is replaced with a wholly different application, also called dump, for dumping parts of object files. UNIX 4.1 also includes a handful of library function additions, and, aside from IPC, the plock and sys3b syscalls for locking and 3B-specific system calls respectively. The added library functions are: drand48, getcwd, hsearch, regcmp, stdipc, strtol, tsearch, and a number of ld-prefixed object file functions. These all survive into 5.0. Two new errnos are added for IPC: ENOMSG and EIDRM. A terminal interface called termio is briefly introduced in 4.1, but doesn't appear in my 5.0 manuals. A couple of macro packages, mosd and mptx, are added in 4.1. Finally, a game called jotto is added to the games list. On to 5.0. Without a 4.1 Administrator's Manual, it's hard to tell what in those sections originated where, but as far as differences, the 5.0 manual contains pages describing general versions of ar, as, ld, size, and strip, as well as PDP-11-specific versions. What I can't tell yet is if this common + PDP vs one-tool-per-arch approach came about in 4.1 or 5.0, as in 3.0 there are, for instance, as.pdp and as.vax. Somewhere between 4.1 and 5.0 the KMC11 tools become KMC11B tools. The machid command is added to identify system architectures. NROFF and TROFF are on the same manual page in 4.1 but split to two separate ones in 5.0, perhaps indicating ditroff developments. I haven't looked at the differences in the actual pages yet. 5.0 introduces the 'se' screen editor and ststat for synchronous terminal reporting. 5.0 also adds another slew of library function pages: clock, erf, ftw, getut, matherr, memory, sputl, ttyslot, and some BX.25 link management bits. 5.0 introduces data file format pages for the common a.out format (as opposed to PDP-11 format). There are pages for the a.out itself, ar changes, filehdr, ldfcn, and linenum. Additionally, there are added files for gettydefs and issue for the new init/getty (sysvinit) system. In fact, that touches on one major change, 5.0 does indeed represent the first instance of the ubiquitous init system being present in the commercial line. From what I can tell, sysvinit was borrowed into 5.0 from the latest CB-UNIX at the time. While I don't have the Administrator's Manual here, I do have the inittab description in section 4, and the description in 4.1 describes the same file as 3.0 rather than 5.0. In other words, this manual confirms that the init currently implemented by the sysvinit project and used since 5.0 truly did start with System V, as 4.1 used the older inittab format from 3.0. I've been curious for a while now where this particular init comes from, because it isn't the research init that consumes /etc/rc and /etc/ttys but neither is it the sysvinit that eats id:runlevel:flags:command inittab lines, but rather runlevel:id:flags:command. I've had a hunch that this represents an earlier USG init that perhaps CB borrowed as well but further developed after they branched it off and it eventually got worked back into 5.0. Either way, it's nice putting that to bed with solid proof, 4.1 never used sysvinit and it really did break out of Bell with System V. So the general picture I'm seeing start to form is: UNIX 4.1 was a user experience somewhere between UNIX 3.0 and UNIX 5.0, as one would expect, but closer to 5.0 than 3.0. The system incorporated the new IPC, cflow, cxref, LP printing, several portability improvements, changes to the Virtual Protocol Machine, process/text/data locking, 3B support, mosd and mptx macros, and began moving away from the PDP-11 as the primary platform. Documentation changes would've largely been the split of the User's Manual sections 1M, 7, and 8 out into a separate Administrator's Manual and the production of two volumes of Documents for UNIX (vs the 1 Volume? of UNIX 3.0). UNIX 5.0 then shows these trends continuing, more generality of commands, addition of a new init/getty system from CB-UNIX. The 'se' screen editor is added, object file processing applications are generalized (this could've happened sometime before 5.0), and some sort of synchronous terminal interface is added. Also, an auto call unit is added. Several drivers show up for storage devices sometime between 3.0 and 5.0 and 3B20 administrative documentation is added. Humorously, a sentence is removed from the intro to the games section after 3.0 stating to consider using cron(1) to prevent abuse of the games section during working hours. Perhaps Bell management acquiesced to routine games of wump. As an aside, wump was one of the first programs I ran on a real UNIX, I had figured out how to rsh into an old RS/6000 in the server closet at a lab I was working in at the time, played many rounds of wump and quiz on it. I remember setting up a SVR4/386 machine out of an old instrument computer that was lying around there too, I miss that server room... Well I think that's certainly enough for one email. Wanted to get some analysis on the matter out since it'll be a while before I've got the manual scanned, wanted to give folks some stuff to crunch on. I'll be slowly and lazily comparing applications themselves as I work through the manual but I certainly don't intend to read every single line, so it'll just be spot checking for typesetting consistency, if a page "looks" like everything is identical, I probably won't pay it any mind. ------- Original Message ------- On Saturday, December 10th, 2022 at 10:28 PM, John Cowan wrote: > Okay, I've done a quick and dirty conversion to PDF and put it on line. My public Google Drive folder is , and the file is oap-ef.pdf (all four pages). > > On Sat, Dec 10, 2022 at 9:21 PM segaloco via TUHS wrote: > >> Here's the raw TIFFs of the quad-not-tri-fold. I don't know where cool kids upload their stuff these days, and I don't have a server on hand at present to pop them up on so here's the temporary service Google lottery turned up, these links are good for 5 days. These are just raws because I have no idea the "page order". I plan on doing another scan and proper PDF when I swing back around to my larger backlog of work. >> >> https://tempfile.io/en/UsIiCxdEX4GzNZD/preview >> https://tempfile.io/en/fBUARNk3iY7u2im/preview >> https://tempfile.io/en/oWlNbcWQDBXnD19/preview >> https://tempfile.io/en/CA51aK9E9AdOu7g/preview >> >> Btw if anyone has any hosting suggestions, I'm all ears. Part of the reason I've stuck with 300dpi in the past is simply finding somewhere that'll accept the behemoth of a scan a 600dpi of some of these hundred page manuals would be. Hosting is my main block. Granted, Warren has generally allowed space for the Documents for UNIX 4 collection, there's still the matter of me getting stuff to Warren in the first place. >> >> - Matt G. >> >> P.S. I didn't look at these, remembered at the last minute out the door so just scanned and uploaded. >> >> P.P.S. Scanned the 4.1 manual cover too.....in b/w, so need to do that one again. That won't be tonight, but I unbound it so will likely start on the formal scans once I'm moved. >> >> ------- Original Message ------- >> On Saturday, December 10th, 2022 at 4:07 PM, Jason T wrote: >> >>> On Thu, Dec 1, 2022 at 11:04 PM segaloco via TUHS tuhs at tuhs.org wrote: >>> >>> > Exciting development in the process of finding lost documentation, just sealed this one on eBay: https://www.ebay.com/itm/385266550881?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=abbj5srltbk&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY >>> > >>> > After the link is a (now closed) auction for a Western Electric 3B20S UNIX User's Manual Release 4.1, something I thought I'd never see and wasn't sure actually exited: print manuals for 4.x. >>> >>> >>> This is quite cool, and I didn't know it existed, either. I'm looking >>> forward to the scan of it, but if it's not too much trouble, I wonder >>> if you could take a nice 600dpi color jpg scan of the cover as well? >>> It might make a nice poster someday. >>> >>> -jt -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Mon Dec 12 16:38:52 2022 From: andrew at humeweb.com (Andrew Hume) Date: Sun, 11 Dec 2022 22:38:52 -0800 Subject: [TUHS] Bell Office Automation System (OAS)? In-Reply-To: <20221211174007.5BEA721FDD@orac.inputplus.co.uk> References: <20221211174007.5BEA721FDD@orac.inputplus.co.uk> Message-ID: <525C07D4-84A7-4848-AF9D-C49E22432563@humeweb.com> regrettably, i do not recall this. as far as i could guess,i simply went with a short name and most likely e stood for editor. > On Dec 11, 2022, at 9:40 AM, Ralph Corderoy wrote: > > Hi andrew, > >> i wrote ef. > > Was its name from ed → ee → ef or something else? > > -- > Cheers, Ralph. From e5655f30a07f at ewoof.net Mon Dec 12 19:48:12 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 12 Dec 2022 09:48:12 +0000 Subject: [TUHS] Clever code In-Reply-To: <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> Message-ID: <2e17a845-5541-445f-a7f2-7b98879cd488@home.arpa> On 11 Dec 2022 18:15 -0800, from bakul at iitbombay.org (Bakul Shah): > Agree that clear code is preferable to complicated code. But in practice > people sacrifice clarity for performance improvement all the time. Look > at the kernel code of any modern os. Everybody pays lip service to this > but most anything other than toy programs ends up getting needlessly > complicated over time. Performant code does not need to stand in opposition to clear code. And if you are writing performance-critical or size-critical code (such as the QNX microkernel that someone brought up), then of course you might end up needing to do things in non-obvious ways; that's not the point here. Clever is fine IMO _where the cleverness provides an actual benefit in a real-world scenario_, and an operating system kernel (and a language standard library) is a rather special type of program where sometimes you have to do things in somewhat non-obvious ways because of the environment the code is meant to execute in. But a significant portion of the time, where I see "clever" code there is _no_ significant benefit to the cleverness; it's often more about "showing off", or saving a few source code characters at the expense of at-a-glance readability, than it is about actual usefulness and necessity. Necessary complexity in order to solve the problem, combined with things like performance requirements, may sometimes require clever code. At that point, there is a benefit to the cleverness. But one can still aim to write the clever code _clearly_, with everything from comments to good variable and function names to formatting that enhances readability by for example grouping related operations together in the source code to keeping related parts grouped together and separate from other code. Just such a simple thing as that I often add extra parenthesis over and beyond what's actually required based on operator precedence, because doing so makes it clearer what goes together and unless the compiler is severely braindead by modern standards, doing so costs _nothing_ past the compilation stage. -- ✍  Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From g.branden.robinson at gmail.com Mon Dec 12 23:38:21 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 12 Dec 2022 07:38:21 -0600 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: References: Message-ID: <20221212133821.nbrwjql5ebvoyr2l@illithid> At 2022-12-12T06:15:22+0000, segaloco via TUHS wrote: > NROFF and TROFF are on the same manual page in 4.1 but split to two > separate ones in 5.0, perhaps indicating ditroff developments. I > haven't looked at the differences in the actual pages yet. If you have scans of these specific pages, I'd be curious to see them. Thanks to my avocation, my brain's working set has a significant amount of *roff history in it; maybe I can be useful here.[1] (The Unix 4.0 documentation with its January 1981 snapshot of newborn device-independent troff was a fantastic find, in my opinion.) I can guess what mptx is but I am curious about this "osd" macro package. What was it for? Regards, Branden [1] The pages might also help me identify and correct errors in groff documentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ralph at inputplus.co.uk Tue Dec 13 00:05:48 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 12 Dec 2022 14:05:48 +0000 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: <20221212133821.nbrwjql5ebvoyr2l@illithid> References: <20221212133821.nbrwjql5ebvoyr2l@illithid> Message-ID: <20221212140548.2648621CFF@orac.inputplus.co.uk> Hi Branden, > I am curious about this "osd" macro package. What was it for? >From mosd(5) in http://www.bitsavers.org/pdf/altos/3068/690-15843-001_Altos_Unix_System_V_Documenters_Workbench_Vol_1_Jul85.pdf NAME mosd - the OSDD adapter macro package for formatting documents DESCRIPTION The OSDD adapter macro package is a tool used in conjunction with the MM macro package to prepare Operations Systems Deliverable Documentation. Many of the OSOD Standards are different from the default format provided by MM. The OSOD adapter package sets the appropriate MM options for automatic production of the OSDO Standards. The OSOO adapter package also generates the correct OSDD page headers and footers, heading styles, Table of Contents format, etc. -- Cheers, Ralph. From g.branden.robinson at gmail.com Tue Dec 13 00:25:09 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 12 Dec 2022 08:25:09 -0600 Subject: [TUHS] Found and Purchased Unix 4.1 3B20S Manual In-Reply-To: <20221212140548.2648621CFF@orac.inputplus.co.uk> References: <20221212133821.nbrwjql5ebvoyr2l@illithid> <20221212140548.2648621CFF@orac.inputplus.co.uk> Message-ID: <20221212142509.oo7cev6o6yzvh4gs@illithid> At 2022-12-12T14:05:48+0000, Ralph Corderoy wrote: > > I am curious about this "osd" macro package. What was it for? > > From mosd(5) in > http://www.bitsavers.org/pdf/altos/3068/690-15843-001_Altos_Unix_System_V_Documenters_Workbench_Vol_1_Jul85.pdf > > NAME > mosd - the OSDD adapter macro package for formatting documents > > DESCRIPTION > The OSDD adapter macro package is a tool used in conjunction with > the MM macro package to prepare Operations Systems Deliverable > Documentation. Many of the OSOD Standards are different from > the default format provided by MM. The OSOD adapter package > sets the appropriate MM options for automatic production of the > OSDO Standards. The OSOO adapter package also generates the > correct OSDD page headers and footers, heading styles, Table of > Contents format, etc. Thanks, Ralph! Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Tue Dec 13 01:02:54 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Dec 2022 07:02:54 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: <20221212150254.GG8801@mcvoy.com> On Sun, Dec 11, 2022 at 10:26:37PM -0700, Andrew Warkentin wrote: > On 12/11/22, Larry McVoy wrote: > > > > If you think of microkernels and think Mach is it, nope, look at QNX. > > > And yet, for some reason, QNX has had almost no influence on anything > else besides a few hobby OSes (only one of which ever reached a > reasonably mature state) as far as I can tell. I really don't get why > that is. As far as I know, I'm the only one who's working on a > QNX-like OS that's not QNX itself. It influenced me. Lots of things that were the right answer failed to achieve success. Beta vs VHS. Plan 9. Does that mean they were worthless? I don't think so. From clemc at ccc.com Tue Dec 13 01:29:04 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Dec 2022 10:29:04 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin wrote: > And yet, for some reason, QNX has had almost no influence on anything > Be careful with a statement like that. It's likely running in something in your car. and very likely to be running in something in the last Boeing or Airbus-based flight you took, and it was used when Amazon made the last delivery to you. It has long been popular in process control/materials handling/robotics/fly-by-wire systems. When a small, very lightweight UNIX-style programming API needed to be used, QNX was often a favorite. I sometimes think QNX must have had a really good salesperson in the 'Rust-Belt.' I know I talked to several fans in companies doing that work. I do know of a least one firm that still uses it. An inexpensive x86 can be designed into a custom controller, and the only 'development' is the customer interface to private HW. The development system is a PC or Vmware on an engineer's desk. After Blackberry bought the company, it's interesting that they seem to be all that is left of BB. But they are still going strong: QNX Neutrino RTOS Funny, I loved Mach (still do), but it tried to be all things to all people. The QNX guys did not. I also think it help in their success -- by the fact that the QNX folks concentrated on RT, while Mach tried to be the replacement for all of BSD. They both have their place ... I'm typing this on my macOS 13.0.1 (Ventura) M1 system, which is just the current flavor of Mach. As Tru64 hacker, as well as one of the folks that work on Intel Paragon, which was OSF/1, all three are Mach based. I also did some work with QNX back in the day and, like Larry, was always very impressed. At one time, I did some consulting in the Rust-Belt, and the executive (*i.e.* -- Havard Business. School types) asked me if *"this QNX thing their engineers were using -- after all it was not from Microsoft, IBM or DEC, of course.''* [they had converted/were in the process of converting from DEC PMAX-based controllers running Ultrix to PCs running QNX]. My analysis at the time, for a bunch of ex-Fortran Mech E's, had done extremely well. I told the execs then that this is good stuff; it's going to save them buckets of money as it 'just works' (that was the core SW in the automatic 'sorter' that at the time was being done under contract for Amazon -- I know the CEO of that firm and they sold the same basic system to UPS/FedEx/USPS -- they used to have a very cool movie taken during the testing at FedEx with glasses full of champagne moving at 45 miles through the sorter without spilling -- the PMAX would never have been able to do that). Frankly, for anyone learning either about microkernels or RT, I would certainly tell them to look at QNX. Neither topic are what we call 'research' projects as much these days, but both have extremely practical applications. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Dec 13 01:39:37 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 12 Dec 2022 10:39:37 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: On Mon, Dec 12, 2022 at 10:30 AM Clem Cole wrote: > > On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin wrote: >> >> And yet, for some reason, QNX has had almost no influence on anything > > Be careful with a statement like that. It's likely running in something in your car. and very likely to be running in something in the last Boeing or Airbus-based flight you took, and it was used when Amazon made the last delivery to you. It has long been popular in process control/materials handling/robotics/fly-by-wire systems. > > When a small, very lightweight UNIX-style programming API needed to be used, QNX was often a favorite. > > I sometimes think QNX must have had a really good salesperson in the 'Rust-Belt.' I know I talked to several fans in companies doing that work. I do know of a least one firm that still uses it. An inexpensive x86 can be designed into a custom controller, and the only 'development' is the customer interface to private HW. The development system is a PC or Vmware on an engineer's desk. > > After Blackberry bought the company, it's interesting that they seem to be all that is left of BB. But they are still going strong: QNX Neutrino RTOS For a while, Neutrino was open source, but that seemed to change quietly at some point. I can't seem to find the source code online anywhere, which surprises me a bit: I'd have assumed anyone who got a copy of the code under the OSS license would still be able to treat it as open source, but maybe I'm just wrong. - Dan C. From lm at mcvoy.com Tue Dec 13 02:04:03 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Dec 2022 08:04:03 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: <20221212160403.GI8801@mcvoy.com> On Mon, Dec 12, 2022 at 10:29:04AM -0500, Clem Cole wrote: > On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin > wrote: > > > And yet, for some reason, QNX has had almost no influence on anything > > > Be careful with a statement like that. It's likely running in something > in your car. and very likely to be running in something in the last Boeing > or Airbus-based flight you took, and it was used when Amazon made the last > delivery to you. It has long been popular in process control/materials > handling/robotics/fly-by-wire systems. > > When a small, very lightweight UNIX-style programming API needed to be > used, QNX was often a favorite. Thanks for that Clem. One question though, all those companies want support. Is there anyone still providing support? I see QNX.com is a thing but is there an actual team of good people working on it? From tuhs at tuhs.org Tue Dec 13 02:10:58 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 Dec 2022 16:10:58 +0000 Subject: [TUHS] Bell Office Automation System (OAS)? In-Reply-To: <525C07D4-84A7-4848-AF9D-C49E22432563@humeweb.com> References: <20221211174007.5BEA721FDD@orac.inputplus.co.uk> <525C07D4-84A7-4848-AF9D-C49E22432563@humeweb.com> Message-ID: The quadfold itself lists "Editor-Formatter" as the expansion. - Matt G. ------- Original Message ------- On Sunday, December 11th, 2022 at 10:38 PM, Andrew Hume wrote: > regrettably, i do not recall this. > as far as i could guess,i simply went with a short name > and most likely e stood for editor. > > > On Dec 11, 2022, at 9:40 AM, Ralph Corderoy ralph at inputplus.co.uk wrote: > > > > Hi andrew, > > > > > i wrote ef. > > > > Was its name from ed → ee → ef or something else? > > > > -- > > Cheers, Ralph. From clemc at ccc.com Tue Dec 13 02:26:51 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Dec 2022 11:26:51 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221212160403.GI8801@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221212160403.GI8801@mcvoy.com> Message-ID: I don't know. I'll try to poke and ask. The engineer I used to work with at the Mill and later Intelligrated has retired (a lot of that with our generation). But I still know some of the execs at the former Intelligrated (now part of Honeywell), so I'll see if I can find out who owns that product these days. If I learn anything interesting, I'll pass it back. FWIW: BB is offering support: i.e.: https://blackberry.qnx.com/en/support claims such, but what does that mean? Clem ᐧ On Mon, Dec 12, 2022 at 11:04 AM Larry McVoy wrote: > On Mon, Dec 12, 2022 at 10:29:04AM -0500, Clem Cole wrote: > > On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin > > wrote: > > > > > And yet, for some reason, QNX has had almost no influence on anything > > > > > Be careful with a statement like that. It's likely running in something > > in your car. and very likely to be running in something in the last > Boeing > > or Airbus-based flight you took, and it was used when Amazon made the > last > > delivery to you. It has long been popular in process control/materials > > handling/robotics/fly-by-wire systems. > > > > When a small, very lightweight UNIX-style programming API needed to be > > used, QNX was often a favorite. > > > Thanks for that Clem. One question though, all those companies want > support. Is there anyone still providing support? I see QNX.com is > a thing but is there an actual team of good people working on it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlyn at geeks.org Tue Dec 13 03:06:46 2022 From: merlyn at geeks.org (Doug McIntyre) Date: Mon, 12 Dec 2022 11:06:46 -0600 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211023955.GP8801@mcvoy.com> References: <20221211021628.GM8801@mcvoy.com> <20221211023207.GN8801@mcvoy.com> <20221211023955.GP8801@mcvoy.com> Message-ID: On Sat, Dec 10, 2022 at 06:39:55PM -0800, Larry McVoy wrote: > OK, that is cool, but my question was what problem does it solve that > we face today? Other than talking to 30-40 year old hardware. Why is > Kermit still a thing? Up until recent, I used kermit on my mac laptop to talk out multiple serial ports to control different devices configured over serial quite regularly. (Now I use the Serial.app) There were other ways to do it, but kermit was familure, and worked flawlessy. From beebe at math.utah.edu Tue Dec 13 03:42:47 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 12 Dec 2022 10:42:47 -0700 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? Message-ID: After my posting on Sat, 10 Dec 2022 17:42:14 -0700 about the recent work on kermit 10.0, some readers asked why a serial line connection and file transfer tool was still of interest, and a few others responded with use cases. Modern kermit has for several years supported ssh connections, and Unicode, as well: here is a top-level command list: % kermit (~/) C-Kermit>? Command, one of the following: add define hangup msleep resend telnet answer delete HELP open return touch apc dial if orientation rlogin trace array directory increment output rmdir translate ask disable input pause run transmit askq do INTRO pdial screen type assign echo kcd pipe script undeclare associate edit learn print send undefine back enable LICENSE pty server version browse end lineout purge set void bye evaluate log push shift wait cd exit login pwd show where change file logout quit space while check finish lookup read ssh who chmod for mail receive statistics write clear ftp manual redial status xecho close get message redirect stop xmessage connect getc minput redo SUPPORT convert getok mget reget suspend copy goto mkdir remote switch date grep mmove remove tail decrement head msend rename take or one of the tokens: ! # ( . ; : < @ ^ { Here are the descriptions of connection and character set translations: (~/) C-Kermit>help ssh Syntax: SSH [ options ] [ command ] Makes an SSH connection using the external ssh program via the SET SSH COMMAND string, which is "ssh -e none" by default. Options for the external ssh program may be included. If the hostname is followed by a command, the command is executed on the host instead of an interactive shell. (~/) C-Kermit>help connect Syntax: CONNECT (or C, or CQ) [ switches ] Connect to a remote computer via the serial communications device given in the most recent SET LINE command, or to the network host named in the most recent SET HOST command. Type the escape character followed by C to get back to the C-Kermit prompt, or followed by ? for a list of CONNECT-mode escape commands. Include the /QUIETLY switch to suppress the informational message that tells you how to escape back, etc. CQ is a synonym for CONNECT /QUIETLY. Other switches include: /TRIGGER:string One or more strings to look for that will cause automatic return to command mode. To specify one string, just put it right after the colon, e.g. "/TRIGGER:Goodbye". If the string contains any spaces, you must enclose it in braces, e.g. "/TRIGGER:{READY TO SEND...}". To specify more than one trigger, use the following format: /TRIGGER:{{string1}{string2}...{stringn}} Upon return from CONNECT mode, the variable \v(trigger) is set to the trigger string, if any, that was actually encountered. This value, like all other CONNECT switches applies only to the CONNECT command with which it is given, and overrides (temporarily) any global SET TERMINAL TRIGGER string that might be in effect. Your escape character is Ctrl-\ (ASCII 28, FS) (~/) C-Kermit>help translate Syntax: CONVERT file1 cs1 cs2 [ file2 ] Synonym: TRANSLATE Converts file1 from the character set cs1 into the character set cs2 and stores the result in file2. The character sets can be any of C-Kermit's file character sets. If file2 is omitted, the translation is displayed on the screen. An appropriate intermediate character-set is chosen automatically, if necessary. Synonym: XLATE. Example: CONVERT lasagna.txt latin1 utf8 lasagna-utf8.txt Multiple files can be translated if file2 is a directory or device name, rather than a filename, or if file2 is omitted. ------------------------------------------------------------------------------- - 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: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From dave at horsfall.org Tue Dec 13 07:34:47 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 13 Dec 2022 08:34:47 +1100 (EST) Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221211200327.GC8801@mcvoy.com> References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> <20221211200327.GC8801@mcvoy.com> Message-ID: On Sun, 11 Dec 2022, Larry McVoy wrote: > > I've always used the maxim "Write code as though the next person to > > maintain it is an axe-wielding psychopath who knows where you live". > > My main job, for the 20 years until I retired, was to keep telling > people that code that you wrote 6 months ago might as well have been > written by someone else. Optimize for reading the code, not writing the > code. It's read many. I should clarify that on the odd occasion that I write obscure code it's for efficiency, and I comment it well because *I* might be the one to maintain it six months hence :-) -- Dave From chet.ramey at case.edu Tue Dec 13 07:46:34 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 12 Dec 2022 16:46:34 -0500 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> <7e7aed8b-30c6-4704-8fbf-4faee5a48a79@home.arpa> <20221211200327.GC8801@mcvoy.com> Message-ID: <0ae81e0f-d41a-32a4-83d3-0263164d2035@case.edu> On 12/12/22 4:34 PM, Dave Horsfall wrote: >> My main job, for the 20 years until I retired, was to keep telling >> people that code that you wrote 6 months ago might as well have been >> written by someone else. Optimize for reading the code, not writing the >> code. It's read many. > > I should clarify that on the odd occasion that I write obscure code it's > for efficiency, and I comment it well because *I* might be the one to > maintain it six months hence :-) Six months? Try ten years. :-) -- ``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 lproven at gmail.com Tue Dec 13 08:20:02 2022 From: lproven at gmail.com (Liam Proven) Date: Mon, 12 Dec 2022 23:20:02 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221212160403.GI8801@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221212160403.GI8801@mcvoy.com> Message-ID: On Mon, 12 Dec 2022 at 17:04, Larry McVoy wrote: > > Thanks for that Clem. One question though, all those companies want > support. Is there anyone still providing support? I see QNX.com is > a thing but is there an actual team of good people working on it? QNX is alive and well and owned by Blackberry Ltd, the former Research in Motion. One big Canadian tech co bought another. They aren't doing _great_ but they're not dead by any means. https://en.wikipedia.org/wiki/BlackBerry_Limited -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From tuhs at tuhs.org Tue Dec 13 09:10:08 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 Dec 2022 23:10:08 +0000 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221212160403.GI8801@mcvoy.com> Message-ID: Well this has certainly piqued my curiosity on QNX. One of my more long-term projects is to write a kernel (micro or otherwise), initially for RISC-V that can, if nothing else, serve as a springboard for my own projects. I've thus far just been using AT&T and BSD UNIX kernels for research and inspiration, with a peek at Darwin every now and then to see how Apple/Mach does things, but could certainly stand to broaden my horizons. That said, if I was to straight up port something as an exercise, I'd probably go for V7 given its ubiquity and the fact that work done there would likely serve as a good template for doing the same with other AT&T and BSD variants. Plus, I think someone's already gone and done a V6 port to RISC-V, so I'd have stuff to refer to. - Matt G. ------- Original Message ------- On Monday, December 12th, 2022 at 2:20 PM, Liam Proven wrote: > On Mon, 12 Dec 2022 at 17:04, Larry McVoy lm at mcvoy.com wrote: > > > Thanks for that Clem. One question though, all those companies want > > support. Is there anyone still providing support? I see QNX.com is > > a thing but is there an actual team of good people working on it? > > > QNX is alive and well and owned by Blackberry Ltd, the former Research > in Motion. One big Canadian tech co bought another. > > They aren't doing great but they're not dead by any means. > > https://en.wikipedia.org/wiki/BlackBerry_Limited > > -- > Liam Proven ~ Profile: https://about.me/liamproven > Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com > Twitter/LinkedIn: lproven ~ Skype: liamproven > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lm at mcvoy.com Tue Dec 13 09:24:01 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Dec 2022 15:24:01 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221212160403.GI8801@mcvoy.com> Message-ID: <20221212232401.GL8801@mcvoy.com> It's been decades since I've used it, my comments are based on the QNX that predated their POSIX conformance. It was extremely light weight, fast, and used as little memory as possible. I literally had 10 active logins (tty) with people editing and compiling on a 256KB 80286. Nothing else came close. But it wasn't POSIX so it might be more bloated today. On Mon, Dec 12, 2022 at 11:10:08PM +0000, segaloco via TUHS wrote: > Well this has certainly piqued my curiosity on QNX. One of my more long-term projects is to write a kernel (micro or otherwise), initially for RISC-V that can, if nothing else, serve as a springboard for my own projects. I've thus far just been using AT&T and BSD UNIX kernels for research and inspiration, with a peek at Darwin every now and then to see how Apple/Mach does things, but could certainly stand to broaden my horizons. That said, if I was to straight up port something as an exercise, I'd probably go for V7 given its ubiquity and the fact that work done there would likely serve as a good template for doing the same with other AT&T and BSD variants. Plus, I think someone's already gone and done a V6 port to RISC-V, so I'd have stuff to refer to. > > - Matt G. > > ------- Original Message ------- > On Monday, December 12th, 2022 at 2:20 PM, Liam Proven wrote: > > > > On Mon, 12 Dec 2022 at 17:04, Larry McVoy lm at mcvoy.com wrote: > > > > > Thanks for that Clem. One question though, all those companies want > > > support. Is there anyone still providing support? I see QNX.com is > > > a thing but is there an actual team of good people working on it? > > > > > > QNX is alive and well and owned by Blackberry Ltd, the former Research > > in Motion. One big Canadian tech co bought another. > > > > They aren't doing great but they're not dead by any means. > > > > https://en.wikipedia.org/wiki/BlackBerry_Limited > > > > -- > > Liam Proven ~ Profile: https://about.me/liamproven > > Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com > > Twitter/LinkedIn: lproven ~ Skype: liamproven > > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Tue Dec 13 11:54:20 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Dec 2022 17:54:20 -0800 Subject: [TUHS] Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> Message-ID: <20221213015420.GA15726@mcvoy.com> On Sun, Dec 11, 2022 at 10:04:54AM -0500, Dan Cross wrote: > I think this is in line with Larry's question about non-legacy > use-cases for these ancient serial transfer protocols in late 2022. Indeed, this was just what I was looking for. I had no idea that serial transfer protocols were still useful. It makes me wish I had kept the source for quicknet, I wrote my own file transfer and remote terminal for CP/M in the middle 1980s. I did it just because I wanted things to work a certain way and none of the other options did what I wanted. quicknet was really pleasant on a 128K Z80 (not really 128K because the screen was mapped in there, but more than 64K). I spent many a pleasant hour logged in to uwvax in quicknet, got a lot of work done. Thanks to you and others who had shown that serial transfer still matters. Who knew? You did. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From andreww591 at gmail.com Tue Dec 13 12:00:34 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Mon, 12 Dec 2022 19:00:34 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: On 12/12/22, Clem Cole wrote: > On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin > wrote: > >> And yet, for some reason, QNX has had almost no influence on anything >> > Be careful with a statement like that. It's likely running in something > in your car. and very likely to be running in something in the last Boeing > or Airbus-based flight you took, and it was used when Amazon made the last > delivery to you. It has long been popular in process control/materials > handling/robotics/fly-by-wire systems. > I'm well aware that QNX has been extremely successful commercially and can be found in a wide range of embedded systems. I'm specifically talking about architectural influence on other OSes. The only OSes with significant QNX influence to reach anything resembling a mature state of which I am aware are VSTa and WiNGs , both of which have been abandoned for quite a while. Besides those two, there was also OpenBLT, which was able to run a simple shell and a few basic utilities from its boot image but not much more, and RadiOS, which was abandoned at a point where it couldn't run much more than a hello world. I'm also working on my own QNX-like OS like I said earlier, although it doesn't run user programs yet (I'm working on the VFS and IPC transport layer at the moment). The extensive commercial success of QNX makes it even more surprising to me that it has had so little architectural influence. Similarly, I don't get why people who bash microkernels always seem to think that all of them are like Mach despite QNX being quite successful. On 12/12/22, Larry McVoy wrote: > It's been decades since I've used it, my comments are based on the QNX that > predated their POSIX conformance. It was extremely light weight, fast, > and used as little memory as possible. I literally had 10 active logins > (tty) with people editing and compiling on a 256KB 80286. Nothing else > came close. But it wasn't POSIX so it might be more bloated today. > QNX 4 and Neutrino are heavier than QNX "Classic", but they're still fairly lightweight. QNX 4 had the fairly well-known demo disk with a Photon desktop and browser on a single 1.4M floppy. Neutrino never had anything quite like that (the smallest official live CD images of the early versions are something like 60M in size) but it's still possible to build images with it that are pretty small. From rudi.j.blom at gmail.com Tue Dec 13 13:30:59 2022 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Tue, 13 Dec 2022 10:30:59 +0700 Subject: [TUHS] Clever code Message-ID: I vaguely remember having read here about 'clever code' which took into account the time a magnetic drum needed to rotate in order to optimise access. Similarly I can imagine that with resource restraints you sometimes need to be clever in order to get your program to fit. Of course, any such cleverness needs extra documentation. I only ever programmed in user space but even then without lots of comment in my code I may already start wondering what I did after only a few months past. Cheers, uncle rubl -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Dec 13 13:41:01 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 12 Dec 2022 20:41:01 -0700 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: On Mon, Dec 12, 2022, 8:32 PM Rudi Blom wrote: > > I vaguely remember having read here about 'clever code' which took into > account the time a magnetic drum needed to rotate in order to optimise > access. > Yes. Many ways this was done. Biggest ones were interleaving and striding. Interleaving allowed one a little processing time for each sector while the disk fpu. So the next logical sector isn't the next physical... and the sectors are numbered in adjacent tracks to take into account rotation and seek times.... there is a lot of research here... Warner Similarly I can imagine that with resource restraints you sometimes need to > be clever in order to get your program to fit. Of course, any such > cleverness needs extra documentation. > > I only ever programmed in user space but even then without lots of comment > in my code I may already start wondering what I did after only a few months > past. > > Cheers, > uncle rubl > -- > The more I learn the better I understand I know nothing. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Dec 13 13:53:40 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 13 Dec 2022 14:53:40 +1100 (EST) Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022, Rudi Blom wrote: > I vaguely remember having read here about 'clever code' which took into > account the time a magnetic drum needed to rotate in order to optimise > access. Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program) on the IBM 650; the programmer wrote the code "straight down" and SOAP reordered it for rotational latency. > Similarly I can imagine that with resource restraints you sometimes need to > be clever in order to get your program to fit. Of course, any such > cleverness needs extra documentation. Try writing a bootstrap program in 512 bytes :-) Self-modifying code was the order of the day... > I only ever programmed in user space but even then without lots of comment > in my code I may already start wondering what I did after only a few months > past. You could be clever in kernel space too, such as taking advantage of the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e. read/modify/write. -- Dave From ggm at algebras.org Tue Dec 13 14:03:47 2022 From: ggm at algebras.org (George Michaelson) Date: Tue, 13 Dec 2022 14:03:47 +1000 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: The "sticky" bit was quite clever. tell the OS to keep something memory resident, so you can binary patch the back end without worrying. Copy on Write was enormously clever. Keeping FD open across fork/exec was fantastically clever. making a null pointer be a valid address was probably not clever (PDP11) but I expect somebody will explain to me why it was clever. On Tue, Dec 13, 2022 at 1:53 PM Dave Horsfall wrote: > > On Tue, 13 Dec 2022, Rudi Blom wrote: > > > I vaguely remember having read here about 'clever code' which took into > > account the time a magnetic drum needed to rotate in order to optimise > > access. > > Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program) > on the IBM 650; the programmer wrote the code "straight down" and SOAP > reordered it for rotational latency. > > > Similarly I can imagine that with resource restraints you sometimes need to > > be clever in order to get your program to fit. Of course, any such > > cleverness needs extra documentation. > > Try writing a bootstrap program in 512 bytes :-) Self-modifying code was > the order of the day... > > > I only ever programmed in user space but even then without lots of comment > > in my code I may already start wondering what I did after only a few months > > past. > > You could be clever in kernel space too, such as taking advantage of > the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e. > read/modify/write. > > -- Dave From ralph at inputplus.co.uk Tue Dec 13 17:47:33 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 13 Dec 2022 07:47:33 +0000 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: <20221213074733.583D9220FA@orac.inputplus.co.uk> Hi Dave, > Rudi Blom wrote: > > I vaguely remember having read here about 'clever code' which took > > into account the time a magnetic drum needed to rotate in order to > > optimise access. > > Sounds like you're referring to SOAP (Symbolic Optimal Assembly > Program) I'd have thought the most widespread tale of drum-rotation time is the wonderful prose version of ‘The Story of Mel’. -- Cheers, Ralph. From ralph at inputplus.co.uk Tue Dec 13 18:05:37 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 13 Dec 2022 08:05:37 +0000 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: <20221213080537.AF4E521911@orac.inputplus.co.uk> Hi George, > The "sticky" bit was quite clever. tell the OS to keep something > memory resident Was it ever more than a hint? I've not heard of it locking or pinning an executable to memory. > so you can binary patch the back end without worrying. I think it altered the worrying. :-) If not sticky, ‘chmod -x’ the file, ensure no process is running it from before the chmod, patch, ‘chmod +x’. If sticky then ‘chmod -tx’, ensure no process is running it from before the chmod, ‘chmod +x’, run it and exit to remove any stuck copy, ‘chmod -x’, patch, chmod ‘+tx’. I may have got the detail wrong but avoiding the unpatched copy lingering in memory is the aim. -- Cheers, Ralph. From dam at opencsw.org Tue Dec 13 19:45:21 2022 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Dec 2022 10:45:21 +0100 Subject: [TUHS] Clever code In-Reply-To: <20221213080537.AF4E521911@orac.inputplus.co.uk> References: <20221213080537.AF4E521911@orac.inputplus.co.uk> Message-ID: <7457C808-1BD0-4C21-A361-6E58D0F67783@opencsw.org> Hi Ralph, > Am 13.12.2022 um 09:05 schrieb Ralph Corderoy : > > Hi George, > >> The "sticky" bit was quite clever. tell the OS to keep something >> memory resident > > Was it ever more than a hint? I've not heard of it locking or pinning > an executable to memory. Funny thing is that it meant the opposite on Solaris: files with the sticky bit set avoided the file to go through the page cache and therefore would never be held in memory. This was e.g. set for swapfiles. Obviously it is counterproductive to cache stuff in memory which is going to be swapped out... Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jpl.jpl at gmail.com Tue Dec 13 21:46:49 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 13 Dec 2022 06:46:49 -0500 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: There was a story that old hands would torment newcomers to the IBM 650 by tinkering with the optimizer to make it as slow as possible (and, with rotating drums, that could be VERY slow). Then they'd look at the newcomer's code, make a trivial change, run it with the real optimizer, and get dazzling improvements. I also recall punched card bootstrap programs for the IBM 7094 that would load column binary when run column binary, and load row binary when run row binary. -- jpl On Mon, Dec 12, 2022 at 10:53 PM Dave Horsfall wrote: > On Tue, 13 Dec 2022, Rudi Blom wrote: > > > I vaguely remember having read here about 'clever code' which took into > > account the time a magnetic drum needed to rotate in order to optimise > > access. > > Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program) > on the IBM 650; the programmer wrote the code "straight down" and SOAP > reordered it for rotational latency. > > > Similarly I can imagine that with resource restraints you sometimes need > to > > be clever in order to get your program to fit. Of course, any such > > cleverness needs extra documentation. > > Try writing a bootstrap program in 512 bytes :-) Self-modifying code was > the order of the day... > > > I only ever programmed in user space but even then without lots of > comment > > in my code I may already start wondering what I did after only a few > months > > past. > > You could be clever in kernel space too, such as taking advantage of > the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e. > read/modify/write. > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Dec 13 23:37:26 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Dec 2022 05:37:26 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> Message-ID: <20221213133726.GA20511@mcvoy.com> On Mon, Dec 12, 2022 at 07:00:34PM -0700, Andrew Warkentin wrote: > On 12/12/22, Clem Cole wrote: > > On Mon, Dec 12, 2022 at 12:27 AM Andrew Warkentin > > wrote: > > > >> And yet, for some reason, QNX has had almost no influence on anything > >> > > Be careful with a statement like that. It's likely running in something > > in your car. and very likely to be running in something in the last Boeing > > or Airbus-based flight you took, and it was used when Amazon made the last > > delivery to you. It has long been popular in process control/materials > > handling/robotics/fly-by-wire systems. > > > > I'm well aware that QNX has been extremely successful commercially and > can be found in a wide range of embedded systems. I'm specifically > talking about architectural influence on other OSes. Minix? QNX predated that. From douglas.mcilroy at dartmouth.edu Wed Dec 14 00:07:02 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 13 Dec 2022 09:07:02 -0500 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: Apropos of accessing rotating storage, John Kelly used to describe the Packard-Bell 250, which had a delay-line memory, as a machine where addresses refer to time rather than space. The PB 250 had two instruction-sequencing modes. In one mode, each instruction included the address of its successor. In the other mode, whatever popped out the delay line when the current instruction completed would be executed next. Doug On Tue, Dec 13, 2022 at 6:48 AM John P. Linderman wrote: > > There was a story that old hands would torment newcomers to the IBM 650 > by tinkering with the optimizer to make it as slow as possible (and, with > rotating drums, that could be VERY slow). Then they'd look at the > newcomer's code, make a trivial change, run it with the real optimizer, > and get dazzling improvements. > > I also recall punched card bootstrap programs for the IBM 7094 that > would load column binary when run column binary, and load row binary > when run row binary. -- jpl > > On Mon, Dec 12, 2022 at 10:53 PM Dave Horsfall wrote: >> >> On Tue, 13 Dec 2022, Rudi Blom wrote: >> >> > I vaguely remember having read here about 'clever code' which took into >> > account the time a magnetic drum needed to rotate in order to optimise >> > access. >> >> Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program) >> on the IBM 650; the programmer wrote the code "straight down" and SOAP >> reordered it for rotational latency. >> >> > Similarly I can imagine that with resource restraints you sometimes need to >> > be clever in order to get your program to fit. Of course, any such >> > cleverness needs extra documentation. >> >> Try writing a bootstrap program in 512 bytes :-) Self-modifying code was >> the order of the day... >> >> > I only ever programmed in user space but even then without lots of comment >> > in my code I may already start wondering what I did after only a few months >> > past. >> >> You could be clever in kernel space too, such as taking advantage of >> the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e. >> read/modify/write. >> >> -- Dave From arnold at skeeve.com Wed Dec 14 00:31:12 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 13 Dec 2022 07:31:12 -0700 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: <202212131431.2BDEVCls018959@freefriends.org> Douglas McIlroy wrote: > Apropos of accessing rotating storage, John Kelly used to describe the > Packard-Bell 250, which had a delay-line memory, as a machine where > addresses refer to time rather than space. > > The PB 250 had two instruction-sequencing modes. In one mode, each > instruction included the address of its successor. In the other mode, > whatever popped out the delay line when the current instruction > completed would be executed next. > > Doug For us (relative) youngsters, can you explain some more how delay line memory worked? The second mode you describe sounds like it would be impossible to use if you wanted repeatable, reproducible runs of your program. Thanks, Arnold From ralph at inputplus.co.uk Wed Dec 14 00:48:11 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 13 Dec 2022 14:48:11 +0000 Subject: [TUHS] Clever code In-Reply-To: <202212131431.2BDEVCls018959@freefriends.org> References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: <20221213144811.3D98520152@orac.inputplus.co.uk> Hi Arnold, > > The PB 250 had two instruction-sequencing modes. In one mode, each > > instruction included the address of its successor. In the other > > mode, whatever popped out the delay line when the current > > instruction completed would be executed next. ... > The second mode you describe sounds like it would be impossible to use > if you wanted repeatable, reproducible runs of your program. How so? As long as the time taken by the current instruction was constant then it would be known what's popping out of the delay line when it's done. And if the time varied, say because of an operand or the need to carry, then that could be used to choose between addresses. Either way, it's repeatable. It is as if the PC register on today's CPU was steadily trundling through program memory in parallel to the execution of the current instruction and when the fetch cycle started, it got whatever PC was pointing at. BTW, there's https://en.wikipedia.org/wiki/Delay-line_memory if you don't know much about them, though I don't think it covers how the line's content was modified other than a simple block diagram showing taps for input and output. https://en.wikipedia.org/wiki/Delay-line_memory#/media/File:SEACComputer_010.png -- Cheers, Ralph. From douglas.mcilroy at dartmouth.edu Wed Dec 14 01:10:51 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 13 Dec 2022 10:10:51 -0500 Subject: [TUHS] Clever code In-Reply-To: <202212131431.2BDEVCls018959@freefriends.org> References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: A delay line is logically like a drum, with circulating data that is accessible only at one point on the circle. A delay line was effectively a linear channel along which a train of data pulses was sent. Pulses received at the far end were reshaped electronically. and reinjected at the sending end. One kind of delay line was a mercury column that carried acoustic pulses.. The PB 250 delay line was magnetostrictive (a technology I know nothing about). If instruction timing is known, then the next instruction to appear is predictable. The only caveat is that instruction times should not be data-dependent. You can lay out sequential code along the circle as long as no instruction steps on one already placed. When that happens you must switch modes to jump to an open spot, or perhaps insert nops to jiggle the layout. Doug On Tue, Dec 13, 2022 at 9:31 AM wrote: > > Douglas McIlroy wrote: > > > Apropos of accessing rotating storage, John Kelly used to describe the > > Packard-Bell 250, which had a delay-line memory, as a machine where > > addresses refer to time rather than space. > > > > The PB 250 had two instruction-sequencing modes. In one mode, each > > instruction included the address of its successor. In the other mode, > > whatever popped out the delay line when the current instruction > > completed would be executed next. > > > > Doug > > For us (relative) youngsters, can you explain some more how delay > line memory worked? The second mode you describe sounds like it > would be impossible to use if you wanted repeatable, reproducible > runs of your program. > > Thanks, > > Arnold From stuff at riddermarkfarm.ca Wed Dec 14 01:34:29 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 13 Dec 2022 10:34:29 -0500 Subject: [TUHS] Clever code In-Reply-To: References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: <206fc6bb-cb58-eb9b-ab4d-b472547aa890@riddermarkfarm.ca> On 2022-12-13 10:10, Douglas McIlroy wrote: > A delay line is logically like a drum, with circulating data that is > accessible only at one point on the circle. A delay line was > effectively a linear channel along which a train of data pulses was > sent. Pulses received at the far end were reshaped electronically. and > reinjected at the sending end. I had always thought of a delay line as a precursor to a register (or stack) for storing intermediate results. Is this not an accurate way of thinking about it? N. > One kind of delay line was a mercury > column that carried acoustic pulses.. The PB 250 delay line was > magnetostrictive (a technology I know nothing about). > > If instruction timing is known, then the next instruction to appear is > predictable. The only caveat is that instruction times should not be > data-dependent. You can lay out sequential code along the circle as > long as no instruction steps on one already placed. When that happens > you must switch modes to jump to an open spot, or perhaps insert nops > to jiggle the layout. > > Doug > > On Tue, Dec 13, 2022 at 9:31 AM wrote: >> >> Douglas McIlroy wrote: >> >>> Apropos of accessing rotating storage, John Kelly used to describe the >>> Packard-Bell 250, which had a delay-line memory, as a machine where >>> addresses refer to time rather than space. >>> >>> The PB 250 had two instruction-sequencing modes. In one mode, each >>> instruction included the address of its successor. In the other mode, >>> whatever popped out the delay line when the current instruction >>> completed would be executed next. >>> >>> Doug >> >> For us (relative) youngsters, can you explain some more how delay >> line memory worked? The second mode you describe sounds like it >> would be impossible to use if you wanted repeatable, reproducible >> runs of your program. >> >> Thanks, >> >> Arnold From bakul at iitbombay.org Wed Dec 14 01:52:49 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 13 Dec 2022 07:52:49 -0800 Subject: [TUHS] Clever code In-Reply-To: References: Message-ID: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> On Dec 12, 2022, at 7:30 PM, Rudi Blom wrote: > > I vaguely remember having read here about 'clever code' which took into account the time a magnetic drum needed to rotate in order to optimise access. Similar consideration applied in the early days of unix workstations. Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec (17 sectors/track of early ST412/ST506 disks) fast enough. As Warner said, one dealt with it by formatting the disk so that the logical blocks N & N+1 (from the OS PoV) were physically more than 1 sector apart. No clever coding needed! The "clever" coding we did was to use all 17 sectors rather than 16 + 1 spare as was intended. Since our first disks were only 5MB in size, we wanted to use all the space and typical error rate is much less than 6%. This complicated handling bad blocks and slowed things down as blocks with soft read errors were copied to blocks at the very end of the disk. I don't recall whose idea it was but I was the one who implemented it. I had an especially bad disk for testing on which I used to build V7 kernels.... > Similarly I can imagine that with resource restraints you sometimes need to be clever in order to get your program to fit. Of course, any such cleverness needs extra documentation. One has to be careful here as resource constraints change over time. An optimization for rev N h/w can be a *pessimization* for later revs. Even if you document code, people tend to leave "working code" alone. > I only ever programmed in user space but even then without lots of comment in my code I may already start wondering what I did after only a few months past. Over time comments tend to turn into fake news! Always go to the primary sources! From ralph at inputplus.co.uk Wed Dec 14 01:56:27 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 13 Dec 2022 15:56:27 +0000 Subject: [TUHS] Clever code In-Reply-To: <206fc6bb-cb58-eb9b-ab4d-b472547aa890@riddermarkfarm.ca> References: <202212131431.2BDEVCls018959@freefriends.org> <206fc6bb-cb58-eb9b-ab4d-b472547aa890@riddermarkfarm.ca> Message-ID: <20221213155627.EC37C22139@orac.inputplus.co.uk> Hi N., > I had always thought of a delay line as a precursor to a register (or > stack) for storing intermediate results. Is this not an accurate way > of thinking about it? As an example, https://en.wikipedia.org/wiki/EDVAC#Technical_description says Physically, the computer comprised the following components: - a magnetic tape reader-recorder (Wilkes 1956:36 describes this as a wire recorder.) ... - a dual memory unit consisting of two sets of 64 mercury acoustic delay lines of eight words capacity on each line [1 Ki words] - three temporary delay-line tanks each holding a single word It looks like the three temporaries were more akin to a stack or registers with the main delay lines providing working memory distinct from tape storage. Another analogy for a delay line might be a steadily turning Rolodex where the card on display can be read and then written, perhaps with a different value, before it disappears. -- Cheers, Ralph. From ralph at inputplus.co.uk Wed Dec 14 02:14:42 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 13 Dec 2022 16:14:42 +0000 Subject: [TUHS] Clever code In-Reply-To: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> References: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> Message-ID: <20221213161442.7A96422139@orac.inputplus.co.uk> Hi Bakul, > Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec > (17 sectors/track of early ST412/ST506 disks) fast enough. As Warner > said, one dealt with it by formatting the disk so that the logical > blocks N & N+1 (from the OS PoV) were physically more than 1 sector > apart. Sticking with ST506 hard drives, by the time the 8 MHz ARM2 from Acorn was reading a 56 MB Rodime, it was the drive which couldn't keep up so executables were stored compressed on disk so the CPU had something to do, uncompressing the sector's content, while it waited for the next sector to arrive. :-) -- Cheers, Ralph. From bakul at iitbombay.org Wed Dec 14 02:30:32 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 13 Dec 2022 08:30:32 -0800 Subject: [TUHS] Clever code In-Reply-To: <20221213161442.7A96422139@orac.inputplus.co.uk> References: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> <20221213161442.7A96422139@orac.inputplus.co.uk> Message-ID: <7373D902-BC96-4149-925F-FC6F29BC2290@iitbombay.org> On Dec 13, 2022, at 8:14 AM, Ralph Corderoy wrote: > > Hi Bakul, > >> Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec >> (17 sectors/track of early ST412/ST506 disks) fast enough. As Warner >> said, one dealt with it by formatting the disk so that the logical >> blocks N & N+1 (from the OS PoV) were physically more than 1 sector >> apart. > > Sticking with ST506 hard drives, by the time the 8 MHz ARM2 from Acorn > was reading a 56 MB Rodime, it was the drive which couldn't keep up so > executables were stored compressed on disk so the CPU had something to > do, uncompressing the sector's content, while it waited for the next > sector to arrive. :-) IIRC the slow part was due to running some common apps! Not much buffering allowed on a 256KB machine so by the time the app asks for the next block, on a 1:1 interleave the block would be past the read head and you had to spend an extra revolution to grab it! From jon at fourwinds.com Wed Dec 14 03:14:01 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 13 Dec 2022 09:14:01 -0800 Subject: [TUHS] Clever code [ really PB 250 ] Message-ID: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> Wow, this brings back memories. When I was a kid I remember visiting a guy who had a barn full of computers in or around Princeton, N.J. There was a Burroughs 500, a PB 250, and a PDP-8. The 500 was a vacuum tube and nixie display machine. That sucker used a lot of neon, and I seem to remember that it used about $100 worth of electricity in 1960s dollars just to warm it up. I think that the PB 250 was one of the first machines built using transistors. I assume that all of you know what a PDP-8 is. I remember using the PDP-8 using SNAP (simple numeric arithmetic processor) to crank out my math homework. Note that the PB 250 also had SNAP, but in that case it was their assembler. Some of the first serious programming that I did was later at BTL on 516-TSS using FSNAP (floating-point SNAP) written by Heinz. Maybe he can fill us in on whether it was derived from SNAP. Anyway, I could only visit the place occasionally because it was far from home. Does anyone else out there know anything about it? It's a vague memory brought back by the mention of the 250. Jon From jnc at mercury.lcs.mit.edu Wed Dec 14 03:58:11 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 13 Dec 2022 12:58:11 -0500 (EST) Subject: [TUHS] Clever code Message-ID: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> > From: Stuff Received > I had always thought of a delay line as a precursor to a register (or > stack) for storing intermediate results. Is this not an accurate way of > thinking about it? No, not at all. First: delay lines were a memory _technology_ (one that was inherently serial, not random-access). They preceded all others. Second: registers used to have two aspects - one now gone (and maybe the second too). The first was that the _technology_ used to implement them (latches built out of tubes, then transistors) was faster than main memory - a distinction now mostly gone, especially since caches blur the speed distinction between today's main memory and registers. The second was that registers, being smaller in numbers, could be named with a few bits, allowing them to be named with a small share of the bits in an instruction. (This one still remains, although instructions are now so long it's probably less important.) Some delay-line machines had two different delay line sizes (since size is equivalent to average access time) - what one might consider 'registers' were kept in the small ones, for fast access at all times, whereas main memory used the longer ones. Noel From jnc at mercury.lcs.mit.edu Wed Dec 14 04:02:22 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 13 Dec 2022 13:02:22 -0500 (EST) Subject: [TUHS] Clever code Message-ID: <20221213180222.E351818C09A@mercury.lcs.mit.edu> > From: Bakul Shah > one dealt with it by formatting the disk so that the logical blocks N & > N+1 (from the OS PoV) were physically more than 1 sector apart. No > clever coding needed! An old hack. ('Nothing new', and all that.) DEC Rx01/02 floppies used the same thing, circa 1976. Noel From g.branden.robinson at gmail.com Wed Dec 14 04:51:09 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 13 Dec 2022 12:51:09 -0600 Subject: [TUHS] Clever code In-Reply-To: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> References: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> Message-ID: <20221213185109.663zv3usi5ey5jx6@illithid> At 2022-12-13T12:58:11-0500, Noel Chiappa wrote: > ... registers used to have two aspects - one now gone (and maybe > the second too). The first was that the _technology_ used to implement > them (latches built out of tubes, then transistors) was faster than > main memory - a distinction now mostly gone, especially since caches > blur the speed distinction between today's main memory and registers. > The second was that registers, being smaller in numbers, could be > named with a few bits, allowing them to be named with a small share of > the bits in an instruction. (This one still remains, although > instructions are now so long it's probably less important.) Maybe less important on x86, but the amount of space in the instruction for encoding registers seems to me to have played a major role in the design of the RV32I/E and C (compressed) extension instruction formats of RISC-V. https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dave at horsfall.org Wed Dec 14 05:56:10 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 Dec 2022 06:56:10 +1100 (EST) Subject: [TUHS] Clever code In-Reply-To: <20221213074733.583D9220FA@orac.inputplus.co.uk> References: <20221213074733.583D9220FA@orac.inputplus.co.uk> Message-ID: On Tue, 13 Dec 2022, Ralph Corderoy wrote: > I'd have thought the most widespread tale of drum-rotation time is the > wonderful prose version of ‘The Story of Mel’. Ah yes, a classic! -- Dave From tuhs at tuhs.org Wed Dec 14 06:14:07 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 13 Dec 2022 20:14:07 +0000 Subject: [TUHS] Clever code In-Reply-To: <20221213185109.663zv3usi5ey5jx6@illithid> References: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> <20221213185109.663zv3usi5ey5jx6@illithid> Message-ID: Where RISC-V is very intentional on this, my reading has lead me to understand that many previous CPU architectures simply passed pieces of the opcode to further hardware in the microarchitecture, so it wasn't so much of a design a register system to fit in a specific bit width but rather a matter of bits 3-5 and 7-9 are connected directly to the two inputs of the ALU internally or something to that effect. Hearsay of course, I wasn't there, but that's the explanation I've heard in the past. Now how much settling on a bit width for the register field of opcodes influences the number of registers or vice versa, hard to say. Did Motorola want a 3 bit register field in opcodes or a resolution of 8 registers per addressing mode in the 68k first for instance, and which decision then followed? I don't know, maybe someone does? In fact, that makes me now wonder if there are CPUs with non-power-of-two register counts outside of the early days. Anything else would waste values in a bitfield. - Matt G. ------- Original Message ------- On Tuesday, December 13th, 2022 at 10:51 AM, G. Branden Robinson wrote: > At 2022-12-13T12:58:11-0500, Noel Chiappa wrote: > > > ... registers used to have two aspects - one now gone (and maybe > > the second too). The first was that the technology used to implement > > them (latches built out of tubes, then transistors) was faster than > > main memory - a distinction now mostly gone, especially since caches > > blur the speed distinction between today's main memory and registers. > > The second was that registers, being smaller in numbers, could be > > named with a few bits, allowing them to be named with a small share of > > the bits in an instruction. (This one still remains, although > > instructions are now so long it's probably less important.) > > > Maybe less important on x86, but the amount of space in the instruction > for encoding registers seems to me to have played a major role in the > design of the RV32I/E and C (compressed) extension instruction formats > of RISC-V. > > https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf > > Regards, > Branden From tuhs at tuhs.org Wed Dec 14 06:58:59 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 14 Dec 2022 06:58:59 +1000 Subject: [TUHS] Clever code In-Reply-To: References: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> <20221213185109.663zv3usi5ey5jx6@illithid> Message-ID: <582d2a37-d86a-960d-e830-e37f38310925@tuhs.org> I think we might move the discussion on memory technologies, CPU architectures etc. to COFF 😁 Thanks, Warren From douglas.mcilroy at dartmouth.edu Wed Dec 14 08:49:40 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 13 Dec 2022 17:49:40 -0500 Subject: [TUHS] Clever code [ really PB 250 ] In-Reply-To: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> References: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> Message-ID: That would be Claude Kagan. A bunch of kids called the R.E.S.I.S.T.O.R.S met there regularly to play with the computers. Claude, who worked for Western Electric, implemented a version of Calvin Mooers's TRAC macroprocessor. Mooers sued for infringing the copyright on a journal article. AT&T settled, out of fear of the consequences of an (unlikely) win for Mooers. The issue remained in the air until a Supreme Court case (Google v Oracle) about a year ago, which fortunately came down against copyrights on software interfaces. Doug On Tue, Dec 13, 2022 at 12:14 PM Jon Steinhart wrote: > > Wow, this brings back memories. When I was a kid I remember visiting > a guy who had a barn full of computers in or around Princeton, N.J. > There was a Burroughs 500, a PB 250, and a PDP-8. The 500 was a vacuum > tube and nixie display machine. That sucker used a lot of neon, and I > seem to remember that it used about $100 worth of electricity in 1960s > dollars just to warm it up. I think that the PB 250 was one of the > first machines built using transistors. I assume that all of you know > what a PDP-8 is. I remember using the PDP-8 using SNAP (simple numeric > arithmetic processor) to crank out my math homework. Note that the PB > 250 also had SNAP, but in that case it was their assembler. > > Some of the first serious programming that I did was later at BTL on > 516-TSS using FSNAP (floating-point SNAP) written by Heinz. Maybe he > can fill us in on whether it was derived from SNAP. > > Anyway, I could only visit the place occasionally because it was far > from home. Does anyone else out there know anything about it? It's a > vague memory brought back by the mention of the 250. > > Jon From andreww591 at gmail.com Wed Dec 14 09:00:46 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Tue, 13 Dec 2022 16:00:46 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221213133726.GA20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> Message-ID: On 12/13/22, Larry McVoy wrote: > >> >> I'm well aware that QNX has been extremely successful commercially and >> can be found in a wide range of embedded systems. I'm specifically >> talking about architectural influence on other OSes. > > Minix? QNX predated that. > Yes, QNX predated Minix by several years, but Minix was completely independent and there was no QNX influence on it at all AFAIK. From skogtun at gmail.com Wed Dec 14 09:02:56 2022 From: skogtun at gmail.com (Harald Arnesen) Date: Wed, 14 Dec 2022 00:02:56 +0100 Subject: [TUHS] Clever code In-Reply-To: References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: <516e29ac-ae8f-e210-a277-82e285aa52c1@gmail.com> Douglas McIlroy [13/12/2022 16.10]: > A delay line is logically like a drum, with circulating data that is > accessible only at one point on the circle. A delay line was > effectively a linear channel along which a train of data pulses was > sent. Pulses received at the far end were reshaped electronically. and > reinjected at the sending end. One kind of delay line was a mercury > column that carried acoustic pulses. And according to Alan Turing, it might have been implemented with Gin and Tonic. From lm at mcvoy.com Wed Dec 14 11:05:31 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Dec 2022 17:05:31 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> Message-ID: <20221214010531.GK20511@mcvoy.com> On Tue, Dec 13, 2022 at 04:00:46PM -0700, Andrew Warkentin wrote: > On 12/13/22, Larry McVoy wrote: > > > >> > >> I'm well aware that QNX has been extremely successful commercially and > >> can be found in a wide range of embedded systems. I'm specifically > >> talking about architectural influence on other OSes. > > > > Minix? QNX predated that. > > > Yes, QNX predated Minix by several years, but Minix was completely > independent and there was no QNX influence on it at all AFAIK. Have you talked to Andy and confirmed that? I'd be quite surprised if he hadn't played with QNX but who knows. I wouldn't assume he hadn't. And forgive me for asking, do you have some axe to grind against QNX or something? To me, it's not that surprising that the rest of the world didn't copy QNX because the rest of the world was either a mono-kernel or it was Mach. Don't get me started on Mach, it has defenders but I absolutely hate it. Mach is more of a distributed research OS that advertised itself as a microkernel. There is _nothing_ micro about Mach. It's a big bloated mess. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Dec 14 11:40:05 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 14 Dec 2022 01:40:05 +0000 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221214010531.GK20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> Message-ID: Has anything material come of later Mach work other than knowledge and influence on other systems? I don't have a complete picture but it's my understanding that there were plenty of developments after NeXT and OSF had their way with it that aren't reflected in, say, macOS. Something about said OSs being forked before Mach 3, which is listed in some references as being more true to the micro kernel architecture. As an aside, I wish Apple would actually engage with their "open source" nature more. I'd love to plink around in the Darwin kernel but even with Google-fu have never managed to actually get a kernel build all the way through. Their lack of documentation is a painful matter. I'd love to bootstrap it on RISC-V if I could get there... - Matt G. ------- Original Message ------- On Tuesday, December 13th, 2022 at 5:05 PM, Larry McVoy wrote: > On Tue, Dec 13, 2022 at 04:00:46PM -0700, Andrew Warkentin wrote: > > > On 12/13/22, Larry McVoy lm at mcvoy.com wrote: > > > > > > I'm well aware that QNX has been extremely successful commercially and > > > > can be found in a wide range of embedded systems. I'm specifically > > > > talking about architectural influence on other OSes. > > > > > > Minix? QNX predated that. > > > > Yes, QNX predated Minix by several years, but Minix was completely > > independent and there was no QNX influence on it at all AFAIK. > > > Have you talked to Andy and confirmed that? I'd be quite surprised if > he hadn't played with QNX but who knows. I wouldn't assume he hadn't. > > And forgive me for asking, do you have some axe to grind against QNX > or something? > > To me, it's not that surprising that the rest of the world didn't copy > QNX because the rest of the world was either a mono-kernel or it was > Mach. Don't get me started on Mach, it has defenders but I absolutely > hate it. Mach is more of a distributed research OS that advertised > itself as a microkernel. There is nothing micro about Mach. It's > a big bloated mess. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From andreww591 at gmail.com Wed Dec 14 12:01:46 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Tue, 13 Dec 2022 19:01:46 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221214010531.GK20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> Message-ID: On 12/13/22, Larry McVoy wrote: > > Have you talked to Andy and confirmed that? I'd be quite surprised if > he hadn't played with QNX but who knows. I wouldn't assume he hadn't. > I haven't actually talked to him about it. He definitely is aware of QNX since he's mentioned it on a few occasions, but I'm not sure if he was aware of it when he wrote the first version of Minix. Personally I don't see a lot of resemblance between the two, besides both being single-personality Unix-like microkernel OSes with lightweight IPC. Minix is more akin to a "serverized" conventional Unix, whereas QNX seems to embrace its microkernel-ness more fully with its focus on extensibility and its fairly tight integration of IPC transport layer and filesystem. There may have been a little bit of influence, but it's not all that obvious to me. The pre-3.x versions seem especially un-QNX-like with their more or less closed set of servers. Even in 3.x, the kernel still seems to have quite a bit of knowledge about what servers are present and what messages they accept. QNX does colocate the process server in the kernel, but it makes very few assumptions about user-mode servers. > > And forgive me for asking, do you have some axe to grind against QNX > or something? > Quite the opposite, hence why I'm writing my own OS with a similar architecture. > > To me, it's not that surprising that the rest of the world didn't copy > QNX because the rest of the world was either a mono-kernel or it was > Mach. Don't get me started on Mach, it has defenders but I absolutely > hate it. Mach is more of a distributed research OS that advertised > itself as a microkernel. There is _nothing_ micro about Mach. It's > a big bloated mess. > Yes, I agree 100% that Mach is a complete and utter failure as a microkernel, and seems to have almost single-handedly destroyed the reputation of microkernels. I don't get why everyone was so focused on Mach-like kernels when there was a better alternative that had been around in some form for almost a decade before Mach (QNX wasn't the first of its kind; it seems to have had pretty significant influence from Thoth). From luther at makerlisp.com Wed Dec 14 12:28:56 2022 From: luther at makerlisp.com (Luther Johnson) Date: Tue, 13 Dec 2022 19:28:56 -0700 Subject: [TUHS] Clever code In-Reply-To: References: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> <20221213185109.663zv3usi5ey5jx6@illithid> Message-ID: The CPU I have designed and (implemented, it's running in a Lattice FPGA right now) has three general purpose registers, a frame pointer, and a stack pointer. But the encoding problem you mention is real. So instead of designing a scheme where the instruction word is split up into fields, I have the first byte as the instruction type, and then however many immediate data bytes (in this instruction set, 1, or 3) are necessary following. The first byte, after it is fetched, is simply fed to a lookup table, which then results in a 12 bit value, 6 bits for operation, and two 3 bit fields for the a and b registers - these 12 bits go to the execution stage. This is a two register address, 24 bit machine - I designed it as a replacement for the Zilog eZ80, which has become hard to get. Anyhow, I get good code density and I've got lots of spare codes left. I've attached the ISA description. I did go through lots of design alternatives to reach the parameters of this ISA - they key one was if I wanted to have the operations I needed, available across all the general purpose registers, that limited how many general purpose registers I could have and keep all the enumerations in less than 256 codes, with some to spare. Another set of of choices relates to how I wanted to implement C on this machine, and that I did not intend for it to support all possible styles of assembly language programming - it is meant to support code generated by the C compiler, with a minimum of assembly required. This machine is called "COR24". I can describe the machine in further detail, or show you some sample code, if you're interested. Luther On 12/13/2022 01:14 PM, segaloco via TUHS wrote: > Where RISC-V is very intentional on this, my reading has lead me to understand that many previous CPU architectures simply passed pieces of the opcode to further hardware in the microarchitecture, so it wasn't so much of a design a register system to fit in a specific bit width but rather a matter of bits 3-5 and 7-9 are connected directly to the two inputs of the ALU internally or something to that effect. Hearsay of course, I wasn't there, but that's the explanation I've heard in the past. > > Now how much settling on a bit width for the register field of opcodes influences the number of registers or vice versa, hard to say. Did Motorola want a 3 bit register field in opcodes or a resolution of 8 registers per addressing mode in the 68k first for instance, and which decision then followed? I don't know, maybe someone does? In fact, that makes me now wonder if there are CPUs with non-power-of-two register counts outside of the early days. Anything else would waste values in a bitfield. > > - Matt G. > > ------- Original Message ------- > On Tuesday, December 13th, 2022 at 10:51 AM, G. Branden Robinson wrote: > > >> At 2022-12-13T12:58:11-0500, Noel Chiappa wrote: >> >>> ... registers used to have two aspects - one now gone (and maybe >>> the second too). The first was that the technology used to implement >>> them (latches built out of tubes, then transistors) was faster than >>> main memory - a distinction now mostly gone, especially since caches >>> blur the speed distinction between today's main memory and registers. >>> The second was that registers, being smaller in numbers, could be >>> named with a few bits, allowing them to be named with a small share of >>> the bits in an instruction. (This one still remains, although >>> instructions are now so long it's probably less important.) >> >> Maybe less important on x86, but the amount of space in the instruction >> for encoding registers seems to me to have played a major role in the >> design of the RV32I/E and C (compressed) extension instruction formats >> of RISC-V. >> >> https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf >> >> Regards, >> Branden -------------- next part -------------- Inst Description Op a,b 6+3+3 binary Hex ---- ----------- -- --- --------------- --- 00 add r0,r0 00 0,0 00 0000 000 000 | 000 01 add r0,r1 00 0,1 00 0000 000 001 | 001 02 add r0,r2 00 0,2 00 0000 000 010 | 002 03 add r1,r0 00 1,0 00 0000 001 000 | 008 04 add r1,r1 00 1,1 00 0000 001 001 | 009 05 add r1,r2 00 1,2 00 0000 001 010 | 00a 06 add r2,r0 00 2,0 00 0000 010 000 | 010 07 add r2,r1 00 2,1 00 0000 010 001 | 011 08 add r2,r2 00 2,2 00 0000 010 010 | 012 09 add r0,dd 01 0,7 00 0001 000 111 | 047 0a add r1,dd 01 1,7 00 0001 001 111 | 04f 0b add r2,dd 01 2,7 00 0001 010 111 | 057 0c add sp,dd 01 4,7 00 0001 100 111 | 067 0d and r0,r1 02 0,1 00 0010 000 001 | 081 0e and r0,r2 02 0,2 00 0010 000 010 | 082 0f and r1,r0 02 1,0 00 0010 001 000 | 088 10 and r1,r2 02 1,2 00 0010 001 010 | 08a 11 and r2,r0 02 2,0 00 0010 010 000 | 090 12 and r2,r1 02 2,1 00 0010 010 001 | 091 13 bra dd 03 7,7 00 0011 111 111 | 0ff 14 brf dd 04 7,7 00 0100 111 111 | 13f 15 brt dd 05 7,7 00 0101 111 111 | 17f 16 ceq r0,r1 06 0,1 00 0110 000 001 | 181 17 ceq r0,r2 06 0,2 00 0110 000 010 | 182 18 ceq r1,r2 06 1,2 00 0110 001 010 | 18a 19 cls r0,r1 07 0,1 00 0111 000 001 | 1c1 1a cls r0,r2 07 0,2 00 0111 000 010 | 1c2 1b cls r1,r0 07 1,0 00 0111 001 000 | 1c8 1c cls r1,r2 07 1,2 00 0111 001 010 | 1ca 1d cls r2,r0 07 2,0 00 0111 010 000 | 1d0 1e cls r2,r1 07 2,1 00 0111 010 001 | 1d1 1f clu r0,r1 08 0,1 00 1000 000 001 | 201 20 clu r0,r2 08 0,2 00 1000 000 010 | 202 21 clu r1,r0 08 1,0 00 1000 001 000 | 208 22 clu r1,r2 08 1,2 00 1000 001 010 | 20a 23 clu r2,r0 08 2,0 00 1000 010 000 | 210 24 clu r2,r1 08 2,1 00 1000 010 001 | 211 25 jal r1,(r0) 09 1,0 00 1001 001 000 | 248 26 jmp (r0) 0a 0,7 00 1010 000 111 | 287 27 jmp (r1) 0a 1,7 00 1010 001 111 | 28f 28 jmp (r2) 0a 2,7 00 1010 010 111 | 297 29 la r0,dddddd 0b 0,7 00 1011 000 111 | 2c7 2a la r1,dddddd 0b 1,7 00 1011 001 111 | 2cf 2b la r2,dddddd 0b 2,7 00 1011 010 111 | 2d7 2c lb r0,dd(r0) 0c 0,0 00 1100 000 000 | 300 2d lb r0,dd(r1) 0c 0,1 00 1100 000 001 | 301 2e lb r0,dd(r2) 0c 0,2 00 1100 000 010 | 302 2f lb r0,dd(fp) 0c 0,3 00 1100 000 011 | 303 30 lb r1,dd(r0) 0c 1,0 00 1100 001 000 | 308 31 lb r1,dd(r1) 0c 1,1 00 1100 001 001 | 309 32 lb r1,dd(r2) 0c 1,2 00 1100 001 010 | 30a 33 lb r1,dd(fp) 0c 1,3 00 1100 001 011 | 30b 34 lb r2,dd(r0) 0c 2,0 00 1100 010 000 | 310 35 lb r2,dd(r1) 0c 2,1 00 1100 010 001 | 311 36 lb r2,dd(r2) 0c 2,2 00 1100 010 010 | 312 37 lb r2,dd(fp) 0c 2,3 00 1100 010 011 | 313 38 lbu r0,dd(r0) 0d 0,0 00 1101 000 000 | 340 39 lbu r0,dd(r1) 0d 0,1 00 1101 000 001 | 341 3a lbu r0,dd(r2) 0d 0,2 00 1101 000 010 | 342 3b lbu r0,dd(fp) 0d 0,3 00 1101 000 011 | 343 3c lbu r1,dd(r0) 0d 1,0 00 1101 001 000 | 348 3d lbu r1,dd(r1) 0d 1,1 00 1101 001 001 | 349 3e lbu r1,dd(r2) 0d 1,2 00 1101 001 010 | 34a 3f lbu r1,dd(fp) 0d 1,3 00 1101 001 011 | 34b 40 lbu r2,dd(r0) 0d 2,0 00 1101 010 000 | 350 41 lbu r2,dd(r1) 0d 2,1 00 1101 010 001 | 351 42 lbu r2,dd(r2) 0d 2,2 00 1101 010 010 | 352 43 lbu r2,dd(fp) 0d 2,3 00 1101 010 011 | 353 44 lc r0,dd 0e 0,7 00 1110 000 111 | 387 45 lc r1,dd 0e 1,7 00 1110 001 111 | 38f 46 lc r2,dd 0e 2,7 00 1110 010 111 | 397 47 lcu r0,dd 0f 0,7 00 1111 000 111 | 3c7 48 lcu r1,dd 0f 1,7 00 1111 001 111 | 3cf 49 lcu r2,dd 0f 2,7 00 1111 010 111 | 3d7 4a lw r0,dd(r0) 10 0,0 01 0000 000 000 | 400 4b lw r0,dd(r1) 10 0,1 01 0000 000 001 | 401 4c lw r0,dd(r2) 10 0,2 01 0000 000 010 | 402 4d lw r0,dd(fp) 10 0,3 01 0000 000 011 | 403 4e lw r1,dd(r0) 10 1,0 01 0000 001 000 | 408 4f lw r1,dd(r1) 10 1,1 01 0000 001 001 | 409 50 lw r1,dd(r2) 10 1,2 01 0000 001 010 | 40a 51 lw r1,dd(fp) 10 1,3 01 0000 001 011 | 40b 52 lw r2,dd(r0) 10 2,0 01 0000 010 000 | 410 53 lw r2,dd(r1) 10 2,1 01 0000 010 001 | 411 54 lw r2,dd(r2) 10 2,2 01 0000 010 010 | 412 55 lw r2,dd(fp) 10 2,3 01 0000 010 011 | 413 56 mov r0,r1 11 0,1 01 0001 000 001 | 441 57 mov r0,r2 11 0,2 01 0001 000 010 | 442 58 mov r0,fp 11 0,3 01 0001 000 011 | 443 59 mov r0,sp 11 0,4 01 0001 000 100 | 444 5a mov r1,r0 11 1,0 01 0001 001 000 | 448 5b mov r1,r2 11 1,2 01 0001 001 010 | 44a 5c mov r1,fp 11 1,3 01 0001 001 011 | 44b 5d mov r1,sp 11 1,4 01 0001 001 100 | 44c 5e mov r2,r0 11 2,0 01 0001 010 000 | 450 5f mov r2,r1 11 2,1 01 0001 010 001 | 451 60 mov r2,fp 11 2,3 01 0001 010 011 | 453 61 mov r2,sp 11 2,4 01 0001 010 100 | 454 62 mov r0,c 11 0,5 01 0001 000 101 | 445 63 mov r1,c 11 1,5 01 0001 001 101 | 44d 64 mov r2,c 11 2,5 01 0001 010 101 | 455 65 mov fp,sp 11 3,4 01 0001 011 100 | 45c 66 mov sp,r0 11 4,0 01 0001 100 000 | 460 67 mov sp,r1 11 4,1 01 0001 100 001 | 461 68 mov sp,r2 11 4,2 01 0001 100 010 | 462 69 mov sp,fp 11 4,3 01 0001 100 011 | 463 6a mul r0,r0 12 0,0 01 0010 000 000 | 480 6b mul r0,r1 12 0,1 01 0010 000 001 | 481 6c mul r0,r2 12 0,2 01 0010 000 010 | 482 6d mul r1,r0 12 1,0 01 0010 001 000 | 488 6e mul r1,r1 12 1,1 01 0010 001 001 | 489 6f mul r1,r2 12 1,2 01 0010 001 010 | 48a 70 mul r2,r0 12 2,0 01 0010 010 000 | 490 71 mul r2,r1 12 2,1 01 0010 010 001 | 491 72 mul r2,r2 12 2,2 01 0010 010 010 | 492 73 or r0,r1 13 0,1 01 0011 000 001 | 4c1 74 or r0,r2 13 0,2 01 0011 000 010 | 4c2 75 or r1,r0 13 1,0 01 0011 001 000 | 4c8 76 or r1,r2 13 1,2 01 0011 001 010 | 4ca 77 or r2,r0 13 2,0 01 0011 010 000 | 4d0 78 or r2,r1 13 2,1 01 0011 010 001 | 4d1 79 pop r0 14 0,4 01 0100 000 100 | 504 7a pop r1 14 1,4 01 0100 001 100 | 50c 7b pop r2 14 2,4 01 0100 010 100 | 514 7c pop fp 14 3,4 01 0100 011 100 | 51c 7d push r0 15 0,4 01 0101 000 100 | 544 7e push r1 15 1,4 01 0101 001 100 | 54c 7f push r2 15 2,4 01 0101 010 100 | 554 80 push fp 15 3,4 01 0101 011 100 | 55c 81 sb r0,dd(r1) 16 0,1 01 0110 000 001 | 581 82 sb r0,dd(r2) 16 0,2 01 0110 000 010 | 582 83 sb r0,dd(fp) 16 0,3 01 0110 000 011 | 583 84 sb r1,dd(r0) 16 1,0 01 0110 001 000 | 588 85 sb r1,dd(r2) 16 1,2 01 0110 001 010 | 58a 86 sb r1,dd(fp) 16 1,3 01 0110 001 011 | 58b 87 sb r2,dd(r0) 16 2,0 01 0110 010 000 | 590 88 sb r2,dd(r1) 16 2,1 01 0110 010 001 | 591 89 sb r2,dd(fp) 16 2,3 01 0110 010 011 | 593 8a shl r0,r1 17 0,1 01 0111 000 001 | 5c1 8b shl r0,r2 17 0,2 01 0111 000 010 | 5c2 8c shl r1,r0 17 1,0 01 0111 001 000 | 5c8 8d shl r1,r2 17 1,2 01 0111 001 010 | 5ca 8e shl r2,r0 17 2,0 01 0111 010 000 | 5d0 8f shl r2,r1 17 2,1 01 0111 010 001 | 5d1 90 sra r0,r1 18 0,1 01 1000 000 001 | 601 91 sra r0,r2 18 0,2 01 1000 000 010 | 602 92 sra r1,r0 18 1,0 01 1000 001 000 | 608 93 sra r1,r2 18 1,2 01 1000 001 010 | 60a 94 sra r2,r0 18 2,0 01 1000 010 000 | 610 95 sra r2,r1 18 2,1 01 1000 010 001 | 611 96 srl r0,r1 19 0,1 01 1001 000 001 | 641 97 srl r0,r2 19 0,2 01 1001 000 010 | 642 98 srl r1,r0 19 1,0 01 1001 001 000 | 648 99 srl r1,r2 19 1,2 01 1001 001 010 | 64a 9a srl r2,r0 19 2,0 01 1001 010 000 | 650 9b srl r2,r1 19 2,1 01 1001 010 001 | 651 9c sub r0,r1 1a 0,1 01 1010 000 001 | 681 9d sub r0,r2 1a 0,2 01 1010 000 010 | 682 9e sub r1,r0 1a 1,0 01 1010 001 000 | 688 9f sub r1,r2 1a 1,2 01 1010 001 010 | 68a a0 sub r2,r0 1a 2,0 01 1010 010 000 | 690 a1 sub r2,r1 1a 2,1 01 1010 010 001 | 691 a2 sub sp,dddddd 1b 4,7 01 1011 100 111 | 6e7 a3 sw r0,dd(r0) 1c 0,0 01 1100 000 000 | 700 a4 sw r0,dd(r1) 1c 0,1 01 1100 000 001 | 701 a5 sw r0,dd(r2) 1c 0,2 01 1100 000 010 | 702 a6 sw r0,dd(fp) 1c 0,3 01 1100 000 011 | 703 a7 sw r1,dd(r0) 1c 1,0 01 1100 001 000 | 708 a8 sw r1,dd(r1) 1c 1,1 01 1100 001 001 | 709 a9 sw r1,dd(r2) 1c 1,2 01 1100 001 010 | 70a aa sw r1,dd(fp) 1c 1,3 01 1100 001 011 | 70b ab sw r2,dd(r0) 1c 2,0 01 1100 010 000 | 710 ac sw r2,dd(r1) 1c 2,1 01 1100 010 001 | 711 ad sw r2,dd(r2) 1c 2,2 01 1100 010 010 | 712 ae sw r2,dd(fp) 1c 2,3 01 1100 010 011 | 713 af sxt r0,r0 1d 0,0 01 1101 000 000 | 740 b0 sxt r0,r1 1d 0,1 01 1101 000 001 | 741 b1 sxt r0,r2 1d 0,2 01 1101 000 010 | 742 b2 sxt r1,r0 1d 1,0 01 1101 001 000 | 748 b3 sxt r1,r1 1d 1,1 01 1101 001 001 | 749 b4 sxt r1,r2 1d 1,2 01 1101 001 010 | 74a b5 sxt r2,r0 1d 2,0 01 1101 010 000 | 750 b6 sxt r2,r1 1d 2,1 01 1101 010 001 | 751 b7 sxt r2,r2 1d 2,1 01 1101 010 010 | 752 b8 xor r0,r1 1e 0,1 01 1110 000 001 | 781 b9 xor r0,r2 1e 0,2 01 1110 000 010 | 782 ba xor r1,r0 1e 1,0 01 1110 001 000 | 788 bb xor r1,r2 1e 1,2 01 1110 001 010 | 78a bc xor r2,r0 1e 2,0 01 1110 010 000 | 790 bd xor r2,r1 1e 2,1 01 1110 010 001 | 791 be zxt r0,r0 1f 0,0 01 1111 000 000 | 7c0 bf zxt r0,r1 1f 0,1 01 1111 000 001 | 7c1 c0 zxt r0,r2 1f 0,2 01 1111 000 010 | 7c2 c1 zxt r1,r0 1f 1,0 01 1111 001 000 | 7c8 c2 zxt r1,r1 1f 1,1 01 1111 001 001 | 7c9 c3 zxt r1,r2 1f 1,2 01 1111 001 010 | 7ca c4 zxt r2,r0 1f 2,0 01 1111 010 000 | 7d0 c5 zxt r2,r1 1f 2,1 01 1111 010 001 | 7d1 c6 zxt r2,r2 1f 2,2 01 1111 010 010 | 7d2 === Late additions === c7 jmp dddddd 0b 7,7 00 1011 111 111 | 2ff From heinz at osta.com Wed Dec 14 15:07:47 2022 From: heinz at osta.com (Heinz Lycklama) Date: Tue, 13 Dec 2022 21:07:47 -0800 Subject: [TUHS] Clever code [ really PB 250 ] In-Reply-To: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> References: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> Message-ID: Jon, I found the documentation for SNAP and FSNAP which both ran on the DDP-516 multiprogramming operating system. Both documents were written in the summer/fall of 1970, and the FSNAP language is based on SNAP programming language, but I'm not sure if this SNAP language was the same as the one you used on the PDP-8. I'll send you the two documents in a separate email so you can tell if the two SNAP's are one and the same. We are talking 52 years ago now. Let's see if you can remember. Heinz P.S. Coincidentally I learned much of my system level     programming on a PDP-8 computer during my     student graduate days in the late 1960's. On 12/13/2022 9:14 AM, Jon Steinhart wrote: > Wow, this brings back memories. When I was a kid I remember visiting > a guy who had a barn full of computers in or around Princeton, N.J. > There was a Burroughs 500, a PB 250, and a PDP-8. The 500 was a vacuum > tube and nixie display machine. That sucker used a lot of neon, and I > seem to remember that it used about $100 worth of electricity in 1960s > dollars just to warm it up. I think that the PB 250 was one of the > first machines built using transistors. I assume that all of you know > what a PDP-8 is. I remember using the PDP-8 using SNAP (simple numeric > arithmetic processor) to crank out my math homework. Note that the PB > 250 also had SNAP, but in that case it was their assembler. > > Some of the first serious programming that I did was later at BTL on > 516-TSS using FSNAP (floating-point SNAP) written by Heinz. Maybe he > can fill us in on whether it was derived from SNAP. > > Anyway, I could only visit the place occasionally because it was far > from home. Does anyone else out there know anything about it? It's a > vague memory brought back by the mention of the 250. > > Jon From robpike at gmail.com Wed Dec 14 16:13:28 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 14 Dec 2022 17:13:28 +1100 Subject: [TUHS] Clever code [ really PB 250 ] In-Reply-To: References: <202212131714.2BDHE22g1863684@darkstar.fourwinds.com> Message-ID: Well, if you're sharing educational bootstrapping stories, Heinz, if I remember right you were the first person I saw in person from Bell Labs, when you gave a talk at the University of Toronto about Bell's work on ARPANET around 1977. -rob On Wed, Dec 14, 2022 at 4:08 PM Heinz Lycklama wrote: > Jon, I found the documentation for SNAP and FSNAP > which both ran on the DDP-516 multiprogramming > operating system. Both documents were written in > the summer/fall of 1970, and the FSNAP language > is based on SNAP programming language, but I'm not > sure if this SNAP language was the same as the one > you used on the PDP-8. I'll send you the two documents > in a separate email so you can tell if the two SNAP's > are one and the same. We are talking 52 years ago now. > Let's see if you can remember. > > Heinz > > P.S. Coincidentally I learned much of my system level > programming on a PDP-8 computer during my > student graduate days in the late 1960's. > > > > On 12/13/2022 9:14 AM, Jon Steinhart wrote: > > Wow, this brings back memories. When I was a kid I remember visiting > > a guy who had a barn full of computers in or around Princeton, N.J. > > There was a Burroughs 500, a PB 250, and a PDP-8. The 500 was a vacuum > > tube and nixie display machine. That sucker used a lot of neon, and I > > seem to remember that it used about $100 worth of electricity in 1960s > > dollars just to warm it up. I think that the PB 250 was one of the > > first machines built using transistors. I assume that all of you know > > what a PDP-8 is. I remember using the PDP-8 using SNAP (simple numeric > > arithmetic processor) to crank out my math homework. Note that the PB > > 250 also had SNAP, but in that case it was their assembler. > > > > Some of the first serious programming that I did was later at BTL on > > 516-TSS using FSNAP (floating-point SNAP) written by Heinz. Maybe he > > can fill us in on whether it was derived from SNAP. > > > > Anyway, I could only visit the place occasionally because it was far > > from home. Does anyone else out there know anything about it? It's a > > vague memory brought back by the mention of the 250. > > > > Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Wed Dec 14 16:32:23 2022 From: rdm at cfcl.com (Rich Morin) Date: Tue, 13 Dec 2022 22:32:23 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> Message-ID: > On Dec 13, 2022, at 17:40, segaloco via TUHS wrote: > > ... I wish Apple would actually engage with their "open source" nature more. I'd love to plink around in the Darwin kernel but even with Google-fu have never managed to actually get a kernel build all the way through. Their lack of documentation is a painful matter. I'd love to bootstrap it on RISC-V if I could get there... You might want to take a look at http://www.puredarwin.org/ ... -r From arnold at skeeve.com Wed Dec 14 17:31:47 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 14 Dec 2022 00:31:47 -0700 Subject: [TUHS] Clever code In-Reply-To: References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: <202212140731.2BE7VlmG009174@freefriends.org> Thank you for the explanation. The skill of the programmers who had to write code for such machines amazes me. I might could have held all that kind of info in my head when I was younger, but certainly not today... Thanks, Arnold Douglas McIlroy wrote: > A delay line is logically like a drum, with circulating data that is > accessible only at one point on the circle. A delay line was > effectively a linear channel along which a train of data pulses was > sent. Pulses received at the far end were reshaped electronically. and > reinjected at the sending end. One kind of delay line was a mercury > column that carried acoustic pulses.. The PB 250 delay line was > magnetostrictive (a technology I know nothing about). > > If instruction timing is known, then the next instruction to appear is > predictable. The only caveat is that instruction times should not be > data-dependent. You can lay out sequential code along the circle as > long as no instruction steps on one already placed. When that happens > you must switch modes to jump to an open spot, or perhaps insert nops > to jiggle the layout. > > Doug > > On Tue, Dec 13, 2022 at 9:31 AM wrote: > > > > Douglas McIlroy wrote: > > > > > Apropos of accessing rotating storage, John Kelly used to describe the > > > Packard-Bell 250, which had a delay-line memory, as a machine where > > > addresses refer to time rather than space. > > > > > > The PB 250 had two instruction-sequencing modes. In one mode, each > > > instruction included the address of its successor. In the other mode, > > > whatever popped out the delay line when the current instruction > > > completed would be executed next. > > > > > > Doug > > > > For us (relative) youngsters, can you explain some more how delay > > line memory worked? The second mode you describe sounds like it > > would be impossible to use if you wanted repeatable, reproducible > > runs of your program. > > > > Thanks, > > > > Arnold From arnold at skeeve.com Wed Dec 14 17:49:32 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 14 Dec 2022 00:49:32 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> Message-ID: <202212140749.2BE7nWE2012686@freefriends.org> Andrew Warkentin wrote: > Yes, I agree 100% that Mach is a complete and utter failure as a > microkernel, and seems to have almost single-handedly destroyed the > reputation of microkernels. I don't get why everyone was so focused on > Mach-like kernels when there was a better alternative that had been > around in some form for almost a decade before Mach (QNX wasn't the > first of its kind; it seems to have had pretty significant influence > from Thoth). I suspect because Mach was available if you had the right Unix licenses and because it was hot in the research world in the mid 80s. Researchy types tend to look at what other researchers are doing / using, it seems to me often without knowledge of or caring about what people are using in industry. (My two cents, from having worked at universities.) Arnold From rdm at cfcl.com Wed Dec 14 19:38:03 2022 From: rdm at cfcl.com (Rich Morin) Date: Wed, 14 Dec 2022 01:38:03 -0800 Subject: [TUHS] OT - Remington Rand ad from 1956 Message-ID: <92148C11-0757-46B9-BD08-94AA1E874CBE@cfcl.com> This is rather off-topic, but some folks here might find it amusing... A Univac Commercial from Remington Randt - 1956 https://www.youtube.com/watch?v=-Ge0N080qw8& -r From skogtun at gmail.com Wed Dec 14 19:46:01 2022 From: skogtun at gmail.com (Harald Arnesen) Date: Wed, 14 Dec 2022 10:46:01 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221214010531.GK20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> Message-ID: <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> Larry McVoy [14/12/2022 02.05]: > To me, it's not that surprising that the rest of the world didn't copy > QNX because the rest of the world was either a mono-kernel or it was > Mach. Don't get me started on Mach, it has defenders but I absolutely > hate it. Mach is more of a distributed research OS that advertised > itself as a microkernel. There is_nothing_ micro about Mach. It's > a big bloated mess. There was a rumour back in the early 90s that a new version of AmigaOS would be based on QNX. This was just before Commodore went bust, so nothing came out of it. A shame, I rather liked the Amiga and its so-called Workbench. -- Hilsen Harald From brad at anduin.eldar.org Wed Dec 14 21:54:04 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Wed, 14 Dec 2022 06:54:04 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <202212140749.2BE7nWE2012686@freefriends.org> (arnold@skeeve.com) Message-ID: arnold at skeeve.com writes: > Andrew Warkentin wrote: > >> Yes, I agree 100% that Mach is a complete and utter failure as a >> microkernel, and seems to have almost single-handedly destroyed the >> reputation of microkernels. I don't get why everyone was so focused on >> Mach-like kernels when there was a better alternative that had been >> around in some form for almost a decade before Mach (QNX wasn't the >> first of its kind; it seems to have had pretty significant influence >> from Thoth). > > I suspect because Mach was available if you had the right Unix licenses > and because it was hot in the research world in the mid 80s. Researchy > types tend to look at what other researchers are doing / using, it seems > to me often without knowledge of or caring about what people are using > in industry. (My two cents, from having worked at universities.) > > Arnold In that time frame there was a number of microkernel designs. One that has not been mentioned was OS-9 for the 6809/68000 processor. I used it pretty extensively. OS-9 was very unix like from the userland POV, when you consider something like V5 unix, however it didn't share any of the same command names, just many of the same concepts. It was close enough that if you had the C compiler, a very basic K&R compiler, you could get some of the unix command to compile without too much trouble. I ported sed from the DEC user's group source and the termcap library from BSD and created a varargs library for it. OS-9 was very microkernel and nothing like Mach or even Minix. It was also very much positioned to real time OS needs of the time and was not really marketed generally and unless you happened to have a Color Computer from Radio Shack or was a part of the nitch they served you would probably have never come across it and it would have seemed to be expensive to acquire. It was very clean, but you needed to know 6809 or 68000 assembly to create anything new for the OS itself, although at least one person had figured out how to use the C compiler, sort of, to produce assembly that could be assembled into device managers and device drivers. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From e5655f30a07f at ewoof.net Wed Dec 14 22:08:21 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 14 Dec 2022 12:08:21 +0000 Subject: [TUHS] (TUHS -> COFF?) Re: Clever code In-Reply-To: References: <202212140749.2BE7nWE2012686@freefriends.org> Message-ID: On 14 Dec 2022 06:54 -0500, from brad at anduin.eldar.org (Brad Spencer): > [...] but you needed to know 6809 or 68000 assembly to create anything > new for the OS itself, Wasn't that the norm at the time, though? As I recall one of the things that really set UNIX apart from other operating systems up until about the early 1990s was precisely how machine-independent it was by virtue of (with the exception of the early versions) having been written in something other than assembler. -- ✍  Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From gilles at gravier.org Wed Dec 14 22:35:08 2022 From: gilles at gravier.org (Gilles Gravier) Date: Wed, 14 Dec 2022 13:35:08 +0100 Subject: [TUHS] OT - Remington Rand ad from 1956 In-Reply-To: <92148C11-0757-46B9-BD08-94AA1E874CBE@cfcl.com> References: <92148C11-0757-46B9-BD08-94AA1E874CBE@cfcl.com> Message-ID: <45c901d1-046e-2306-53bf-2e4a03162d04@gravier.org> 2000 flops! That's amazing perf! On 14/12/2022 10:38, Rich Morin wrote: > This is rather off-topic, but some folks here might find it amusing... > > A Univac Commercial from Remington Randt - 1956 > https://www.youtube.com/watch?v=-Ge0N080qw8& > > -r > -- Signature Home Pro Gilles Gravier- Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key: 0xA610DB098DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Thu Dec 15 01:14:44 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 14 Dec 2022 09:14:44 -0600 Subject: [TUHS] Microware's OS-9 (was: Clever code) In-Reply-To: References: <202212140749.2BE7nWE2012686@freefriends.org> Message-ID: <20221214151444.niv5xtnxlmoifbrm@illithid> At 2022-12-14T06:54:04-0500, Brad Spencer wrote: > arnold at skeeve.com writes: > > I suspect because Mach was available if you had the right Unix > > licenses and because it was hot in the research world in the mid > > 80s. Researchy types tend to look at what other researchers are > > doing / using, it seems to me often without knowledge of or caring > > about what people are using in industry. (My two cents, from having > > worked at universities.) The UNSW CSE department seemed to be a bit more outward facing than that, at least in my brief exposure to it, long after the 1980s. > In that time frame there was a number of microkernel designs. One > that has not been mentioned was OS-9 for the 6809/68000 processor. I > used it pretty extensively. OS-9 was very unix like from the userland > POV, when you consider something like V5 unix, however it didn't share > any of the same command names, just many of the same concepts. This is emphatically true. I used this system as a kid on a 64KiB machine, and I don't remember even a mention of Unix in the doorstop of a manual by Dale Puckett and Peter Dibble (who gave you something like 6 chapters of architectural background before introducing the shell prompt). Maybe they did mention Unix , but since it had no meaning to me at the time, it didn't sink in. I think it is also possible they avoided any names that they thought might draw legal ire from AT&T. > It was close enough that if you had the C compiler, a very basic K&R > compiler, you could get some of the unix command to compile without > too much trouble. Years later I went to college, landed on Sun IPC workstations, and quickly recognized OS-9's "T/S Edit" as a vi clone, and its "T/S Word" as a version of nroff. There was also a "T/S Spell" product but I don't recall it clearly enough to venture whether it was a clone of ispell. > OS-9 was very microkernel In that deployment environment, it had to be. > and nothing like Mach or even Minix. With the source of all three available, a technical paper analyzing and contrasting them would be a worthwhile thing to have. (It's unclear to me if even a historical version of QNX is available for study.) > It was also very much positioned to real time OS needs of the time and > was not really marketed generally and unless you happened to have a > Color Computer from Radio Shack Lucky me! How I yearned for a 128KiB Color Computer 3 so I could upgrade to OS-9 Level 2 and the windowing system. (512KiB was preferred, but there had been a spike in RAM prices right about the time the machine was released. Not that greater market success would have kept Tandy from under-promoting and eventually killing the machine.[1]) > It was very clean, but you needed to know 6809 or 68000 assembly to > create anything new for the OS itself, The 6809 was my first exposure to a (relatively) clean ISA design, having come from the Z80. It probably helped that I was born with a big-endian head and thus had an instinctive revulsion to Intel byte order at an extremely young age. In the late 1990s, Apple decided they wanted to rebrand their operating system (still "MacOS [Classic]" at the time), looked at Microware's name for its system, and said, "right, we'll be having that". Microware, having apparently so carefully followed the letter of trademark law with respect to AT&T Unix, sued Apple for peddling "OS/9" in the operating system market, and promptly got their asses handed to them by the federal district court, which dutifully honored the foremost principle of law: big people get to stomp smaller people as often, and as hard, as they would like.[2] (Later, apparently, Apple pointed out this precedent to Cisco with a shark-toothed grin when Apple decided they wanted the name "iOS" for yet another revitalizing rebrand of familiar technology. Cisco rolled over and took some undisclosed amount of money, which they promptly spent on acquisitions--they then were suddenly startled by the proportion of op ex going to salaries, and initiated layoffs.) Apple's never changed its stripes, but OS-9 lives on, as Free Software, under the name NitrOS-9.[4] Regards, Branden [1] Here's a story you may have to sit down for from Frank Durda IV (now deceased) about how the same company knifed their m68k-based line--which ran XENIX--in the gut repeatedly. It's hard to find this story via Web search so I've made a Facebook post temporarily(?) public. I'd simply include it, but it's pretty long. https://www.facebook.com/g.branden.robinson/posts/pfbid0F8MrvauQ6KPQ1tytme9uDiWGvprXft5dsxUzABYtdTKA9viZhB6Q2nadvtP1aDNQl [2] https://www.cnn.com/2000/TECH/computing/03/21/os9.suit.idg/index.html [3] https://appleinsider.com/articles/10/06/08/cisco_licenses_ios_name_to_apple_screenshot_shows_iwork_on_iphone [4] https://sourceforge.net/projects/nitros9/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cowan at ccil.org Thu Dec 15 08:41:11 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 14 Dec 2022 17:41:11 -0500 Subject: [TUHS] Microware's OS-9 (was: Clever code) In-Reply-To: <20221214151444.niv5xtnxlmoifbrm@illithid> References: <202212140749.2BE7nWE2012686@freefriends.org> <20221214151444.niv5xtnxlmoifbrm@illithid> Message-ID: On Wed, Dec 14, 2022 at 10:15 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: Microware, having apparently so carefully followed the letter of > trademark law with respect to AT&T Unix, sued Apple for peddling "OS/9" > in the operating system market, and promptly got their asses handed to > them by the federal district court, which dutifully honored the foremost > principle of law: big people get to stomp smaller people as often, and > as hard, as they would like.[2] > To be fair, the judge decided that there wasn't a whole lot of risk of consumer confusion between a consumer OS that ran only on Apple Macintoshes and an OEM OS that did not. The only actual victims were Mac people who stumbled into comp.os.os9 and got seriously confused. In any case, Microsoft v. Lindows pretty much established that sometimes the little guy wins, even in trademark cases. Microsoft claimed that Lindows was infringing their trademark for Windows (it was a Linux distro that came with Wine and some glue) and lost the case on prior-use grounds (both Xerox and Apple). So rather than risking all on a retrial and maybe losing the Windows trademark altogether, they settled for US$20M and Lindows changed its corporate and distro names to Linspire. That said, "Windows" is a descriptive trademark, and those are always shaky legally. > Cisco rolled over > and took some undisclosed amount of money, > Money undoubtedly flowed from Apple Computers to Apple Records when the first company started selling music, too. This sort of thing is routine. While I was working at Chase Bank, they paid a small fortune to Chase Research for the rights to "chase.com". -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 15 10:29:45 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 14 Dec 2022 16:29:45 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> Message-ID: <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: > > It's not necessarily true that microkernels are significantly slower. uKernels are usually quite fast as they do so little. What can be slow is emulating a Unix like OS on top due to context switches. For instance, a user process doing read() will have the following context switches: userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc or worse (I didn't account for a few things). Because of this even some uKernels run a few critical services + drivers in the supervisor mode. But overall slowdown of such a unix emulation will very much depend on the workload and also what kind of performance improvements you are willing to try in a complex kernel vs same services running in user mode. At present the linux kernel has about 31+ Million lines (accounting for all architectures, filesystems, device drivers etc.). The FreeBSD 13.x kernel is about 8.7M LoC (of which 44-45% are in device drivers). I only counted .c and .h files. In contract FreeBSD 2.2.2 kernel has ~554K LoC. This LoC growth is entirely understandable but I wonder how things may have turned out in an alternate universe of uKernel based designs.... From lm at mcvoy.com Thu Dec 15 12:54:53 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 14 Dec 2022 18:54:53 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> Message-ID: <20221215025453.GY20511@mcvoy.com> Wasn't there some statement that QNX dropped some of these? Copy plus context switch? On Wed, Dec 14, 2022 at 04:29:45PM -0800, Bakul Shah wrote: > On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: > > > > It's not necessarily true that microkernels are significantly slower. > > uKernels are usually quite fast as they do so little. What can be slow > is emulating a Unix like OS on top due to context switches. For instance, > a user process doing read() will have the following context switches: > > userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc > > or worse (I didn't account for a few things). Because of this even some > uKernels run a few critical services + drivers in the supervisor mode. > But overall slowdown of such a unix emulation will very much depend on the > workload and also what kind of performance improvements you are willing to > try in a complex kernel vs same services running in user mode. > > At present the linux kernel has about 31+ Million lines (accounting for > all architectures, filesystems, device drivers etc.). The FreeBSD 13.x > kernel is about 8.7M LoC (of which 44-45% are in device drivers). I only > counted .c and .h files. In contract FreeBSD 2.2.2 kernel has ~554K LoC. > This LoC growth is entirely understandable but I wonder how things may > have turned out in an alternate universe of uKernel based designs.... -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From bakul at iitbombay.org Thu Dec 15 15:36:12 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 14 Dec 2022 21:36:12 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221215025453.GY20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> Message-ID: Don't see how unless they put multiple related services in the same address space, which reduces context switching but tends toward a monokernel (& increased coupling). Unless I am misunderstanding you. > On Dec 14, 2022, at 6:54 PM, Larry McVoy wrote: > > Wasn't there some statement that QNX dropped some of these? Copy plus > context switch? > > On Wed, Dec 14, 2022 at 04:29:45PM -0800, Bakul Shah wrote: >> On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: >>> >>> It's not necessarily true that microkernels are significantly slower. >> >> uKernels are usually quite fast as they do so little. What can be slow >> is emulating a Unix like OS on top due to context switches. For instance, >> a user process doing read() will have the following context switches: >> >> userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc >> >> or worse (I didn't account for a few things). Because of this even some >> uKernels run a few critical services + drivers in the supervisor mode. >> But overall slowdown of such a unix emulation will very much depend on the >> workload and also what kind of performance improvements you are willing to >> try in a complex kernel vs same services running in user mode. >> >> At present the linux kernel has about 31+ Million lines (accounting for >> all architectures, filesystems, device drivers etc.). The FreeBSD 13.x >> kernel is about 8.7M LoC (of which 44-45% are in device drivers). I only >> counted .c and .h files. In contract FreeBSD 2.2.2 kernel has ~554K LoC. >> This LoC growth is entirely understandable but I wonder how things may >> have turned out in an alternate universe of uKernel based designs.... > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From grog at lemis.com Thu Dec 15 16:30:47 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 15 Dec 2022 17:30:47 +1100 Subject: [TUHS] Delay line memory (was: Clever code) In-Reply-To: <202212131431.2BDEVCls018959@freefriends.org> References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: <20221215063047.GB84239@eureka.lemis.com> On Tuesday, 13 December 2022 at 7:31:12 -0700, arnold at skeeve.com wrote: > For us (relative) youngsters, can you explain some more how delay > line memory worked? At a slight tangent, if you're ever in Melbourne (Australia, of course), you should take a look at CSIRAC, allegedly the oldest intact computer still in existence. It had delay line memory. I took some photos of it years ago: http://www.lemis.com/grog/photos/Photos.php?dirdate=20040904 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: 163 bytes Desc: not available URL: From grog at lemis.com Thu Dec 15 16:39:03 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 15 Dec 2022 17:39:03 +1100 Subject: [TUHS] Sector interleaving (was: Clever code) In-Reply-To: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> References: <29888CC6-CA23-4361-BC9C-1B8A775C8DA9@iitbombay.org> Message-ID: <20221215063902.GC84239@eureka.lemis.com> On Tuesday, 13 December 2022 at 7:52:49 -0800, Bakul Shah wrote: > On Dec 12, 2022, at 7:30 PM, Rudi Blom wrote: >> >> I vaguely remember having read here about 'clever code' which took >> into account the time a magnetic drum needed to rotate in order to >> optimise access. > > Similar consideration applied in the early days of unix workstations. > Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec > (17 sectors/track of early ST412/ST506 disks) fast enough. As Warner > said, one dealt with it by formatting the disk so that the logical > blocks N & N+1 (from the OS PoV) were physically more than 1 sector > apart. No clever coding needed! CP/M did something similar with floppy disks. It imposed a 6 fold software interleave between sectors (logical sectors 1, 2, 3.. were "physical" sectors 1, 7, 13...) On soft-sectored floppies, the "physical" sectors were really just the numbers in the sector header. By the time I got involved, computers were far fast enough that they spent a lot of time just waiting for the next sector. I wrote a format program that positioned the "physical" sectors so that there was only one sector between "physical" 1, 7, 13 and so. It made an amazing difference to the disk speed. 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: 163 bytes Desc: not available URL: From andreww591 at gmail.com Thu Dec 15 18:01:56 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Thu, 15 Dec 2022 01:01:56 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221215025453.GY20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> Message-ID: On 12/14/22, Larry McVoy wrote: > Wasn't there some statement that QNX dropped some of these? Copy plus > context switch? > Yeah, QNX/L4-type IPC is usually just copying followed by a context switch. Some such kernels (like seL4) don't even have full message queues per endpoint (the scheduler queue sort of functions as an IPC queue). Mach IPC is slow because of stuff like permission checking, which I would assume involves iteration over a list of permitted threads. QNX/L4-type kernels usually either use constant-time permission checks (like the old "clans and chiefs" model used by L3 and early L4, or the more modern capability-oriented model used by seL4 and some others), or lack kernel permission checking entirely leaving it up to servers. Another issue is that Mach-type kernels don't have what is known as "direct process switching" AFAIK. When a synchronous message is sent on a QNX/L4-type kernel, the kernel immediately switches to the receiving process, bypassing the scheduler queue entirely, with the remainder of the sender's timeslice being given to the receiver (depending on the kernel, priorities may factor into this so it isn't always quite that simple though). Mach-like kernels often require the sender to wait for the kernel to decide to schedule the receiver based on the queue, and then once the reply is sent there's another wait for the kernel to again decide to schedule the sender again, which makes for rather poor performance. On 12/14/22, Bakul Shah wrote: > On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: >> >> It's not necessarily true that microkernels are significantly slower. > > uKernels are usually quite fast as they do so little. What can be slow > is emulating a Unix like OS on top due to context switches. For instance, > a user process doing read() will have the following context switches: > > userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc > > or worse (I didn't account for a few things). Because of this even some > uKernels run a few critical services + drivers in the supervisor mode. > But overall slowdown of such a unix emulation will very much depend on the > workload and also what kind of performance improvements you are willing to > try in a complex kernel vs same services running in user mode. Yeah, excessive vertical layering can be bad for performance. QNX normally follows a process-per-subsystem-instance architecture, so the chain is just: client -> (kernel) -> diskServer -> (kernel) -> client where the disk server includes the disk driver, partition table driver (if applicable), and disk filesystem. The VFS layer isn't even involved at all on reads, writes, and the like (it's pretty much only there to deal with operations that involve paths and not those that only involve FDs), whereas some other Unix-like microkernel OSes have it act as an intermediary on all FS operations. A lot of the time, protection domains correspond more to subsystem instances rather than layer instances, so there really isn't much harm in merging all layers of a subsystem into a single process for the sake of performance. When there is a benefit to separation of layers into different processes, it is possible to use tap-type drivers to allow running subsystem instances that only contain some of the layers (QNX doesn't do this AFAIK, but my OS will). From lm at mcvoy.com Fri Dec 16 00:02:25 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Dec 2022 06:02:25 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> Message-ID: <20221215140225.GB21275@mcvoy.com> I wasn't clear. There was someone who said that the copy to another address space included a context switch to the receiving process (I think that was it) that resulted in better performance. Perhaps the person who said that can elaborate. On Wed, Dec 14, 2022 at 09:36:12PM -0800, Bakul Shah wrote: > Don't see how unless they put multiple related services in the same > address space, which reduces context switching but tends toward a > monokernel (& increased coupling). Unless I am misunderstanding you. > > > On Dec 14, 2022, at 6:54 PM, Larry McVoy wrote: > > > > Wasn't there some statement that QNX dropped some of these? Copy plus > > context switch? > > > > On Wed, Dec 14, 2022 at 04:29:45PM -0800, Bakul Shah wrote: > >> On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: > >>> > >>> It's not necessarily true that microkernels are significantly slower. > >> > >> uKernels are usually quite fast as they do so little. What can be slow > >> is emulating a Unix like OS on top due to context switches. For instance, > >> a user process doing read() will have the following context switches: > >> > >> userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc > >> > >> or worse (I didn't account for a few things). Because of this even some > >> uKernels run a few critical services + drivers in the supervisor mode. > >> But overall slowdown of such a unix emulation will very much depend on the > >> workload and also what kind of performance improvements you are willing to > >> try in a complex kernel vs same services running in user mode. > >> > >> At present the linux kernel has about 31+ Million lines (accounting for > >> all architectures, filesystems, device drivers etc.). The FreeBSD 13.x > >> kernel is about 8.7M LoC (of which 44-45% are in device drivers). I only > >> counted .c and .h files. In contract FreeBSD 2.2.2 kernel has ~554K LoC. > >> This LoC growth is entirely understandable but I wonder how things may > >> have turned out in an alternate universe of uKernel based designs.... > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Fri Dec 16 00:02:08 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Dec 2022 09:02:08 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> Message-ID: On Thu, Dec 15, 2022 at 12:38 AM Bakul Shah wrote: > Don't see how unless they put multiple related services in the same > address space, which reduces context switching but tends toward a > monokernel (& increased coupling). Unless I am misunderstanding you. I don't see why two services in a microkernel couldn't arrange to share a region of memory and implement bidirectional queues between themselves. With an appropriate signalling mechanism, you'd still be context switching but avoiding a lot of copying. - Dan C. > > On Dec 14, 2022, at 6:54 PM, Larry McVoy wrote: > > > > Wasn't there some statement that QNX dropped some of these? Copy plus > > context switch? > > > > On Wed, Dec 14, 2022 at 04:29:45PM -0800, Bakul Shah wrote: > >> On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: > >>> > >>> It's not necessarily true that microkernels are significantly slower. > >> > >> uKernels are usually quite fast as they do so little. What can be slow > >> is emulating a Unix like OS on top due to context switches. For instance, > >> a user process doing read() will have the following context switches: > >> > >> userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc > >> > >> or worse (I didn't account for a few things). Because of this even some > >> uKernels run a few critical services + drivers in the supervisor mode. > >> But overall slowdown of such a unix emulation will very much depend on the > >> workload and also what kind of performance improvements you are willing to > >> try in a complex kernel vs same services running in user mode. > >> > >> At present the linux kernel has about 31+ Million lines (accounting for > >> all architectures, filesystems, device drivers etc.). The FreeBSD 13.x > >> kernel is about 8.7M LoC (of which 44-45% are in device drivers). I only > >> counted .c and .h files. In contract FreeBSD 2.2.2 kernel has ~554K LoC. > >> This LoC growth is entirely understandable but I wonder how things may > >> have turned out in an alternate universe of uKernel based designs.... > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat > From lm at mcvoy.com Fri Dec 16 00:06:59 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Dec 2022 06:06:59 -0800 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> Message-ID: <20221215140659.GE21275@mcvoy.com> On Thu, Dec 15, 2022 at 09:02:08AM -0500, Dan Cross wrote: > On Thu, Dec 15, 2022 at 12:38 AM Bakul Shah wrote: > > Don't see how unless they put multiple related services in the same > > address space, which reduces context switching but tends toward a > > monokernel (& increased coupling). Unless I am misunderstanding you. > > I don't see why two services in a microkernel couldn't arrange to > share a region of memory and implement bidirectional queues > between themselves. With an appropriate signalling mechanism, > you'd still be context switching but avoiding a lot of copying. My mind went to similar thoughts. How did QNX manage the page cache? Did they have mmap? From crossd at gmail.com Fri Dec 16 00:18:42 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Dec 2022 09:18:42 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <20221215140659.GE21275@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> <20221215140659.GE21275@mcvoy.com> Message-ID: On Thu, Dec 15, 2022 at 9:07 AM Larry McVoy wrote: > On Thu, Dec 15, 2022 at 09:02:08AM -0500, Dan Cross wrote: > > On Thu, Dec 15, 2022 at 12:38 AM Bakul Shah wrote: > > > Don't see how unless they put multiple related services in the same > > > address space, which reduces context switching but tends toward a > > > monokernel (& increased coupling). Unless I am misunderstanding you. > > > > I don't see why two services in a microkernel couldn't arrange to > > share a region of memory and implement bidirectional queues > > between themselves. With an appropriate signalling mechanism, > > you'd still be context switching but avoiding a lot of copying. > > My mind went to similar thoughts. How did QNX manage the page cache? > Did they have mmap? I don't know if they did historically, but I kind of doubt it; QNX predates 4.2BSD, and I imagine there wasn't much influence from TENEX/PMAP). But they seem to now: https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.getting_started/topic/s1_resmgr_io_mmap.html No idea how they handle page caching. That's an interesting question, given how they adopted POSIX and try to at least give the outward appearance of being Unix-y. Given the emphasis on the message-based architecture, where messages can be sent between nodes, I doubt there's that much support for shared memory as a basis for IPC; I think they favored explicit messaging copying facilitated by the ukernel. Whether you could build something bespoke using the provided primitives is another matter. - Dan C. From marc.donner at gmail.com Fri Dec 16 04:06:36 2022 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 15 Dec 2022 13:06:36 -0500 Subject: [TUHS] Clever code In-Reply-To: References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: Further on delay line storage: Physically one of the most common ones was a cylinder of liquid mercury. There was a device at one end for introducing pressure waves into the mercury (think loudspeaker) and a device at the other end for measuring the pressure waves arriving (think microphone). The pulses that came off the microphone end were then fed back to the loudspeaker end, after being cleaned up. ===== nygeek.net mindthegapdialogs.com/home On Tue, Dec 13, 2022 at 10:12 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > A delay line is logically like a drum, with circulating data that is > accessible only at one point on the circle. A delay line was > effectively a linear channel along which a train of data pulses was > sent. Pulses received at the far end were reshaped electronically. and > reinjected at the sending end. One kind of delay line was a mercury > column that carried acoustic pulses.. The PB 250 delay line was > magnetostrictive (a technology I know nothing about). > > If instruction timing is known, then the next instruction to appear is > predictable. The only caveat is that instruction times should not be > data-dependent. You can lay out sequential code along the circle as > long as no instruction steps on one already placed. When that happens > you must switch modes to jump to an open spot, or perhaps insert nops > to jiggle the layout. > > Doug > > On Tue, Dec 13, 2022 at 9:31 AM wrote: > > > > Douglas McIlroy wrote: > > > > > Apropos of accessing rotating storage, John Kelly used to describe the > > > Packard-Bell 250, which had a delay-line memory, as a machine where > > > addresses refer to time rather than space. > > > > > > The PB 250 had two instruction-sequencing modes. In one mode, each > > > instruction included the address of its successor. In the other mode, > > > whatever popped out the delay line when the current instruction > > > completed would be executed next. > > > > > > Doug > > > > For us (relative) youngsters, can you explain some more how delay > > line memory worked? The second mode you describe sounds like it > > would be impossible to use if you wanted repeatable, reproducible > > runs of your program. > > > > Thanks, > > > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Fri Dec 16 04:08:10 2022 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 15 Dec 2022 13:08:10 -0500 Subject: [TUHS] Clever code In-Reply-To: References: <202212131431.2BDEVCls018959@freefriends.org> Message-ID: Here is a page from the Computer History Museum on the topic: https://www.computerhistory.org/revolution/memory-storage/8/309 about halfway down the page is a nice schematic. ===== nygeek.net mindthegapdialogs.com/home On Thu, Dec 15, 2022 at 1:06 PM Marc Donner wrote: > Further on delay line storage: > > Physically one of the most common ones was a cylinder of liquid mercury. > There was a device at one end for introducing pressure waves into the > mercury (think loudspeaker) and a device at the other end for measuring the > pressure waves arriving (think microphone). The pulses that came off the > microphone end were then fed back to the loudspeaker end, after being > cleaned up. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Tue, Dec 13, 2022 at 10:12 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> A delay line is logically like a drum, with circulating data that is >> accessible only at one point on the circle. A delay line was >> effectively a linear channel along which a train of data pulses was >> sent. Pulses received at the far end were reshaped electronically. and >> reinjected at the sending end. One kind of delay line was a mercury >> column that carried acoustic pulses.. The PB 250 delay line was >> magnetostrictive (a technology I know nothing about). >> >> If instruction timing is known, then the next instruction to appear is >> predictable. The only caveat is that instruction times should not be >> data-dependent. You can lay out sequential code along the circle as >> long as no instruction steps on one already placed. When that happens >> you must switch modes to jump to an open spot, or perhaps insert nops >> to jiggle the layout. >> >> Doug >> >> On Tue, Dec 13, 2022 at 9:31 AM wrote: >> > >> > Douglas McIlroy wrote: >> > >> > > Apropos of accessing rotating storage, John Kelly used to describe the >> > > Packard-Bell 250, which had a delay-line memory, as a machine where >> > > addresses refer to time rather than space. >> > > >> > > The PB 250 had two instruction-sequencing modes. In one mode, each >> > > instruction included the address of its successor. In the other mode, >> > > whatever popped out the delay line when the current instruction >> > > completed would be executed next. >> > > >> > > Doug >> > >> > For us (relative) youngsters, can you explain some more how delay >> > line memory worked? The second mode you describe sounds like it >> > would be impossible to use if you wanted repeatable, reproducible >> > runs of your program. >> > >> > Thanks, >> > >> > Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lproven at gmail.com Fri Dec 16 04:33:57 2022 From: lproven at gmail.com (Liam Proven) Date: Thu, 15 Dec 2022 19:33:57 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> Message-ID: On Wed, 14 Dec 2022 at 10:47, Harald Arnesen wrote: > > There was a rumour back in the early 90s that a new version of AmigaOS > would be based on QNX. Oh, it wasn't a rumour. The deal got quite advanced. My now-employers covered it at the time: https://www.theregister.com/1998/11/14/amiga_2_to_use_qnx/ > This was just before Commodore went bust, so > nothing came out of it. It was after. By this point it was Gateway Inc paying for it. There's an account of what happened here: https://www.trollaxor.com/2005/06/how-qnx-failed-amiga.html The next-gen Amiga project was pretty much why QNX gained its GUI, Neutrino: https://guidebookgallery.org/screenshots/qnx621 This is also the basis of the famous QNX Demo Disk, build by the late great Dan Hildebrandt: http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm > A shame, I rather liked the Amiga and its > so-called Workbench. It was a good OS in its time and its admirers often call it a microkernel, but IMVHO if all the code is in the same memory space, that's not really a true microkernel. Amiga Inc then went on to nearly do a deal with Tao Group for the much more advanced Taos, in its later v2 incarnation as Intent/Elate. https://wiki.c2.com/?TaoIntentOs https://www.osnews.com/story/157/tao-group-on-elateos-amigade-and-more/ Ars has some info on this nearly-forgotten OS: https://arstechnica.com/gadgets/2018/03/a-history-of-the-amiga-part-12-red-vs-blue/ -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From frew at ucsb.edu Fri Dec 16 08:13:30 2022 From: frew at ucsb.edu (James Frew) Date: Thu, 15 Dec 2022 14:13:30 -0800 Subject: [TUHS] UNIXabilia Message-ID: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> Having recently emeritated, I'm clearing out my university office and giving away hundreds of books. It occurs to me that some of them may be of interest to some of the folks on this list. (Before you ask, no, you can't have my original printed-on-Kleenex versions of the Lions notes...) Most of the books are listed here: https://www.librarything.com/catalog/james.frew . They're (alas) utterly uncategorized, but include a fair amount of UNIX, C, and general CS stuff. I also have some manuals and USENIX conference proceedings even LibraryThing couldn't locate; they're listed in the attached Markdown file. None of these proceedings are online at usenix.org, so I'd be stoked if someone volunteered to scan them. If you want any of them, let me know, and we'll figure out some way to reimburse me for shipping them. (No charge for the "content".) Or if you're close enough to Santa Barbara, come and get 'em. Cheers, /Frew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- USENIX & related conferences proceedings | when | what | where | | ------- | ------------------------------ | ----------------- | | 1982-07 | USENIX, /usr/group, STUG | Boston, MA | | 1983-01 | USENIX, /usr/group, STUG | San Diego, CA | | 1985-01 | USENIX | Dallas, TX | | 1985-06 | USENIX | Portland, OR | | 1985-12 | 2nd Computer Graphics Workshop | Monterey, CA | | 1986-01 | USENIX | Denver, CO | | 1986-06 | USENIX | Atlanta, GA | | 1986-11 | 3rd Computer Graphics Workshop | Monterey, CA | | 1987-01 | USENIX | Washington, DC | | 1987-10 | 4th Computer Graphics Workshop | Cambridge, MA | | 1987-11 | C++ Workshop | Santa Fe, NM | | 1988-06 | USENIX | San Francisco, CA | | 1988-10 | C++ | Denver, CO | | 1989-01 | USENIX | San Diego, CA | | 1990-06 | USENIX | Anaheim, CA | UNIX System V Documenter's Workbench Release 2.0 manuals (comb-bound) | ATT # | title | | ------- | ----------------------------------------- | | 310-004 | User's Guide | | 310-005 | Technical Discussion and Reference Manual | | 310-006 | Product Overview | | 310-007 | Release Notes | | 310-008 | Handbook | | 310-009 | Handbook for New Users | 4.3 BSD documentation set (comb-bound) | TLA | title | | ---- | ------------------------------------------ | | URM | User Reference Manual (man [167]) | | USD | User Supplementary Documents | | PRM | Programmer Reference Manual (man [2-5]) | | PS1 | Programmer Supplementary Documents, part 1 | | PS2 | Programmer Supplementary Documents, part 2 | | SMM | System Manager's Manual (includes man 8) | | | Master Index | From tuhs at tuhs.org Fri Dec 16 08:41:48 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 15 Dec 2022 22:41:48 +0000 Subject: [TUHS] UNIXabilia In-Reply-To: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> References: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> Message-ID: Wow, there's a lot of good stuff here James! I would definitely have an interest in doing some preservation, although I'm holding off on taking on new work at least until March, I'm going to be in the midst of a move here soon and don't want something priceless getting lost in the mail. Just to speak to my interest, absolutely anything AT&T of course, so the DWB 2.0 comb bound documents and the AT&T SVR3 (grey manuals with UNIX earth and trace lines) set. That represents one of the holes in my System V documentation archival efforts actually, I've got just about the full blue SVR4 set as well as the full SVR1 set, but have avoided SVR2 and 3 since there's just such a diversity of documentation in that timeframe and I need to work through some of my other scan jobs before searching around for those. However, if you've already got them and are offering them precisely for preservation reasons, then our interests here line up pretty well. Also, looking through your list, you've also got Organick's Multics book. I'd love a copy of that for selfish reasons, so if you still have that by March. Could probably find it on eBay but I'd love supporting another TUHS member. I'd say if it all lines up that you still have the USENIX stuff, any AT&T/Bell literature, and the Multics book by the first couple weeks of March, let's circle back around and talk. Otherwise, if someone jumps on this for preservation purposes before, I'll gladly contribute to the funds if it means this stuff gets scanned and archived (and I don't have to be the one to do it :P) - Matt G. ------- Original Message ------- On Thursday, December 15th, 2022 at 2:13 PM, James Frew wrote: > Having recently emeritated, I'm clearing out my university office and giving away hundreds of books. It occurs to me that some of them may be of interest to some of the folks on this list. (Before you ask, no, you can't have my original printed-on-Kleenex versions of the Lions notes...) > > Most of the books are listed here: https://www.librarything.com/catalog/james.frew . They're (alas) utterly uncategorized, but include a fair amount of UNIX, C, and general CS stuff. > > I also have some manuals and USENIX conference proceedings even LibraryThing couldn't locate; they're listed in the attached Markdown file. None of these proceedings are online at usenix.org, so I'd be stoked if someone volunteered to scan them. > > If you want any of them, let me know, and we'll figure out some way to reimburse me for shipping them. (No charge for the "content".) Or if you're close enough to Santa Barbara, come and get 'em. > > Cheers, > /[Frew](https://purl.org/frew) -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4udv8 at comcast.net Fri Dec 16 09:02:48 2022 From: b4udv8 at comcast.net (b4udv8 at comcast.net) Date: Thu, 15 Dec 2022 15:02:48 -0800 Subject: [TUHS] UNIXabilia In-Reply-To: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> References: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> Message-ID: <03d301d910d9$5e463f70$1ad2be50$@comcast.net> I will PROUDLY take The C Programming Language book off your hands! PayPal ok? Cheers! Don Harrison From: James Frew Sent: Thursday, December 15, 2022 2:14 PM To: tuhs at tuhs.org Subject: [TUHS] UNIXabilia Having recently emeritated, I'm clearing out my university office and giving away hundreds of books. It occurs to me that some of them may be of interest to some of the folks on this list. (Before you ask, no, you can't have my original printed-on-Kleenex versions of the Lions notes...) Most of the books are listed here: https://www.librarything.com/catalog/james.frew . They're (alas) utterly uncategorized, but include a fair amount of UNIX, C, and general CS stuff. I also have some manuals and USENIX conference proceedings even LibraryThing couldn't locate; they're listed in the attached Markdown file. None of these proceedings are online at usenix.org, so I'd be stoked if someone volunteered to scan them. If you want any of them, let me know, and we'll figure out some way to reimburse me for shipping them. (No charge for the "content".) Or if you're close enough to Santa Barbara, come and get 'em. Cheers, /Frew -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Fri Dec 16 09:37:11 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 15 Dec 2022 17:37:11 -0600 Subject: [TUHS] UNIXabilia In-Reply-To: References: <7786c188-8acf-ecc5-f128-7ee2afface16@ucsb.edu> Message-ID: <20221215233711.lq4fuvagr7pvlhdu@illithid> At 2022-12-15T22:41:48+0000, segaloco via TUHS wrote: > Also, looking through your list, you've also got Organick's Multics > book. I'd love a copy of that for selfish reasons, so if you still > have that by March. Could probably find it on eBay but I'd love > supporting another TUHS member. I guess I may have a collector's item--while mine lacks the dust cover, it's inscribed by Samuel J. Leffler. Picked the thing up in a used bookstore years and years ago. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From will.senn at gmail.com Fri Dec 16 10:27:25 2022 From: will.senn at gmail.com (Will Senn) Date: Thu, 15 Dec 2022 18:27:25 -0600 Subject: [TUHS] Continued celebration of Warren's Flame Message-ID: All, I recently migrated my blog - it's new and improved, of course:) over to https://decuser.github.io. When I saw Warren was awarded Usenix's "The Flame" last week, I thought it appropriate that one of my first new blog posts celebrate Warren and his well deserved award. Here's the post: https://decuser.github.io/unix/2022/12/15/usenix-flame-award-2022.html Thanks again to Warren, both for the initiative, and for the maintenance of one of my all time favorite archives. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronscohen at gmail.com Fri Dec 16 11:36:50 2022 From: aaronscohen at gmail.com (Aaron) Date: Thu, 15 Dec 2022 20:36:50 -0500 Subject: [TUHS] Please reinstate Message-ID: <1456FBA5-D423-41B0-AE85-8D0245AB45BC@gmail.com> I accidentally unsubscribed Sent from my iPhone From douglas.mcilroy at dartmouth.edu Fri Dec 16 13:02:18 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 15 Dec 2022 22:02:18 -0500 Subject: [TUHS] origin of null-terminated strings Message-ID: I think this cited quote from https://www.joelonsoftware.com/2001/12/11/ is urban legend. Why do C strings [have a terminating NUl]? It’s because the PDP-7 microprocessor, on which UNIX and the C programming language were invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) at the end.” This assertion seems unlikely since neither C nor the library string functions existed on the PDP-7. In fact the "terminating character" of a string in the PDP-7 language B was the pair '*e'. A string was a sequence of words, packed two characters per word. For odd-length strings half of the final one-character word was effectively NUL-padded as described below. One might trace null termination to the original (1965) proposal for ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only role specifically suggested for NUL is to "serve to accomplish time fill or media fill." With character-addressable hardware (not the PDP-7), it is only a small step from using NUL as terminal padding to the convention of null termination in all cases. Ken would probably know for sure whether there's any truth in the attribution to ASCIZ. Doug From kenbob at gmail.com Fri Dec 16 13:14:50 2022 From: kenbob at gmail.com (Ken Thompson) Date: Thu, 15 Dec 2022 19:14:50 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: asciz -- this is the first time i heard of it. doug -- yes. On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I think this cited quote from > https://www.joelonsoftware.com/2001/12/11/ is urban legend. > > Why do C strings [have a terminating NUl]? It’s because the PDP-7 > microprocessor, on which UNIX and the C programming language were > invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) > at the end.” > > This assertion seems unlikely since neither C nor the library string > functions existed on the PDP-7. In fact the "terminating character" of > a string in the PDP-7 language B was the pair '*e'. A string was a > sequence of words, packed two characters per word. For odd-length > strings half of the final one-character word was effectively > NUL-padded as described below. > > One might trace null termination to the original (1965) proposal for > ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only > role specifically suggested for NUL is to "serve to accomplish time > fill or media fill." With character-addressable hardware (not the > PDP-7), it is only a small step from using NUL as terminal padding to > the convention of null termination in all cases. > > Ken would probably know for sure whether there's any truth in the > attribution to ASCIZ. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Dec 16 13:17:51 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 15 Dec 2022 22:17:51 -0500 (EST) Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022, Douglas McIlroy wrote: > I think this cited quote from > https://www.joelonsoftware.com/2001/12/11/ is urban legend. > > Why do C strings [have a terminating NUl]? It’s because the PDP-7 > microprocessor, on which UNIX and the C programming language were > invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) > at the end.” > > This assertion seems unlikely since neither C nor the library string > functions existed on the PDP-7. In fact the "terminating character" of > a string in the PDP-7 language B was the pair '*e'. A string was a > sequence of words, packed two characters per word. For odd-length > strings half of the final one-character word was effectively > NUL-padded as described below. > > One might trace null termination to the original (1965) proposal for > ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only > role specifically suggested for NUL is to "serve to accomplish time > fill or media fill." With character-addressable hardware (not the > PDP-7), it is only a small step from using NUL as terminal padding to > the convention of null termination in all cases. > > Ken would probably know for sure whether there's any truth in the > attribution to ASCIZ. > > Doug > For what it's worth, when I code for the Apple //e (using 65C02 assembler), I use C strings. I can just do something like prstr: ldy #$00 @1: lda msg, y beq @2 ; string terminator ora #$80 ; firmware wants high bit on jsr $FDED ; write char iny bne @1 @2: rts msg: .byte "Hello, cruel world.", 13, 0 and using a NUL terminator just makes sense here because of how simple it is to check for (BEQ and BNE check the 6502's zero flag, which LDA automatically sets). -uso. From tuhs at tuhs.org Fri Dec 16 16:09:43 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 Dec 2022 06:09:43 +0000 Subject: [TUHS] 3B20S UNIX User's Manual Release 4.1 Scans Thread Message-ID: Good evening folks. I'm starting a new thread to pass along info as I scan materials from the 3B20S manual that I picked up. I figured it'd be easier to trickle out the bits folks ask me for first and then continue to scan the rest, that way anyone looking to sink their teeth into something specific can be sated first. With that, the first scan (and frankly one of my favorite things about this manual) is the cover itself: https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png Someone had mentioned the idea of making this into a poster and I gotta say, I'd gladly put one up. The image definitely would need some cleanup for that, I just scanned it like it came, haven't tried to clean up any of the wear of time yet. Sadly, the back cover isn't emblazoned with a big Bell logo like the 3.0 and 5.0 (Bell variant) manuals, so scanning that would be a boring white piece of cardstock. Anywho, the next round which may come later this evening or sometime this weekend is going to be various *ROFF-related documents, so documents like troff(1), mm(5), etc. - Matt G. From iain at csp-partnership.co.uk Fri Dec 16 19:13:35 2022 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Fri, 16 Dec 2022 09:13:35 +0000 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> ASCIZ Lost in the mists of time in my mind. I remember running into a .asciz directive n the 70s “somewhere”. It was an assembler directive in one of the RT11 systems??? or perhaps the unix bootstrap and/or “.s” files - when I get some time I will go read some old code/manuals. I Yes, it put a null byte at the end of a string. > On 16 Dec 2022, at 03:14, Ken Thompson wrote: > > asciz -- this is the first time i heard of it. > doug -- yes. > > > On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy > wrote: > I think this cited quote from > https://www.joelonsoftware.com/2001/12/11/ is urban legend. > > Why do C strings [have a terminating NUl]? It’s because the PDP-7 > microprocessor, on which UNIX and the C programming language were > invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) > at the end.” > > This assertion seems unlikely since neither C nor the library string > functions existed on the PDP-7. In fact the "terminating character" of > a string in the PDP-7 language B was the pair '*e'. A string was a > sequence of words, packed two characters per word. For odd-length > strings half of the final one-character word was effectively > NUL-padded as described below. > > One might trace null termination to the original (1965) proposal for > ASCII, https://dl.acm.org/doi/10.1145/363831.363839 . There the only > role specifically suggested for NUL is to "serve to accomplish time > fill or media fill." With character-addressable hardware (not the > PDP-7), it is only a small step from using NUL as terminal padding to > the convention of null termination in all cases. > > Ken would probably know for sure whether there's any truth in the > attribution to ASCIZ. > > Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From skogtun at gmail.com Fri Dec 16 20:42:43 2022 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 16 Dec 2022 11:42:43 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> Message-ID: <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Liam Proven [15/12/2022 19.33]: > On Wed, 14 Dec 2022 at 10:47, Harald Arnesen wrote: >> There was a rumour back in the early 90s that a new version of AmigaOS >> would be based on QNX. > Oh, it wasn't a rumour. The deal got quite advanced. > > My now-employers covered it at the time: > https://www.theregister.com/1998/11/14/amiga_2_to_use_qnx/ Thanks! Very interesting, I didn't know much of this. -- Hilsen Harald From halbert at halwitz.org Fri Dec 16 23:42:12 2022 From: halbert at halwitz.org (Dan Halbert) Date: Fri, 16 Dec 2022 08:42:12 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> ASCIZ was an assembler directive used for a number of different DEC computers, and also the name for null-terminated strings. I learned it for the PDP-10, but I'm sure it existed on other machines. It is in some PDP-10 documentation I am looking at right now. Anyone who used DEC and did assembly programming would have known about it. Various system calls took ASCIZ strings. On 12/16/22 04:13, Dr Iain Maoileoin wrote: > ASCIZ > Lost in the mists of time in my mind. > > I remember running into a .asciz directive n the 70s “somewhere”. > It was an assembler directive in one of the RT11 systems??? or perhaps > the unix bootstrap and/or “.s” files - when I get some time I will go > read some old code/manuals. > > I > > Yes, it put a null byte at the end of a string. > >> On 16 Dec 2022, at 03:14, Ken Thompson wrote: >> >> asciz -- this is the first time i heard of it. >> doug -- yes. >> >> >> On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy >> wrote: >> >> I think this cited quote from >> https://www.joelonsoftware.com/2001/12/11/ is urban legend. >> >>     Why do C strings [have a terminating NUl]? It’s because the PDP-7 >> microprocessor, on which UNIX and the C programming language were >> invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z >> (zero) >> at the end.” >> >> This assertion seems unlikely since neither C nor the library string >> functions existed on the PDP-7. In fact the "terminating >> character" of >> a string in the PDP-7 language B was the pair '*e'. A string was a >> sequence of words, packed two characters per word. For odd-length >> strings half of the final one-character word was effectively >> NUL-padded as described below. >> >> One might trace null termination to the original (1965) proposal for >> ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only >> role specifically suggested for NUL is to "serve to accomplish time >> fill or media fill." With character-addressable hardware (not the >> PDP-7), it is only a small step from using NUL as terminal padding to >> the convention of null termination in all cases. >> >> Ken would probably know for sure whether there's any truth in the >> attribution to ASCIZ. >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Dec 17 02:10:31 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 16 Dec 2022 11:10:31 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> Message-ID: On Fri, Dec 16, 2022 at 8:42 AM Dan Halbert wrote: > ASCIZ was an assembler directive used for a number of different DEC computers, and also the name for null-terminated strings. I learned it for the PDP-10, but I'm sure it existed on other machines. It is in some PDP-10 documentation I am looking at right now. Anyone who used DEC and did assembly programming would have known about it. Various system calls took ASCIZ strings. This raises something I've always been curious about. To what extent were the Unix folks at Bell Labs already familiar with DEC systems before the PDP-7? It strikes me that much of the published work was centered around IBM and GE systems (e.g., Ken's wonderful paper on regular expressions, and of course the Multics work). Were there other Digital machines floating around? I know a proposal was written to get a PDP-10 for operating systems research, but it wasn't approved. Relatedly, was any thought given to trying to get a 360 system? On 12/16/22 04:13, Dr Iain Maoileoin wrote: > ASCIZ > Lost in the mists of time in my mind. Origin, perhaps, but it exists in contemporary assemblers. Like most sane people I try to avoid being in assembler for too long, when you're first turning on a machine it is useful to be able to squirt a message out of the UART if something goes dramatically wrong, and the directive is handy for that. It seems to have made its way into Research assembler via BSD; it's in locore.s in 8th Edition, for instance, but doesn't appear before that. The "UNIX Assembler Manual" describes "String Statements" for the 7th Edition assembler; strings are sequences of ASCII characters between '<' and '>'. But it doesn't say that they're NUL terminated, and they are not: adding the terminator was manual via the familiar, `\0` escape sequence. - Dan C. > I remember running into a .asciz directive n the 70s “somewhere”. > It was an assembler directive in one of the RT11 systems??? or perhaps the unix bootstrap and/or “.s” files - when I get some time I will go read some old code/manuals. > > I > > Yes, it put a null byte at the end of a string. > > On 16 Dec 2022, at 03:14, Ken Thompson wrote: > > asciz -- this is the first time i heard of it. > doug -- yes. > > > On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy wrote: >> >> I think this cited quote from >> https://www.joelonsoftware.com/2001/12/11/ is urban legend. >> >> Why do C strings [have a terminating NUl]? It’s because the PDP-7 >> microprocessor, on which UNIX and the C programming language were >> invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) >> at the end.” >> >> This assertion seems unlikely since neither C nor the library string >> functions existed on the PDP-7. In fact the "terminating character" of >> a string in the PDP-7 language B was the pair '*e'. A string was a >> sequence of words, packed two characters per word. For odd-length >> strings half of the final one-character word was effectively >> NUL-padded as described below. >> >> One might trace null termination to the original (1965) proposal for >> ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only >> role specifically suggested for NUL is to "serve to accomplish time >> fill or media fill." With character-addressable hardware (not the >> PDP-7), it is only a small step from using NUL as terminal padding to >> the convention of null termination in all cases. >> >> Ken would probably know for sure whether there's any truth in the >> attribution to ASCIZ. >> >> Doug > > > From pugs78 at gmail.com Sat Dec 17 02:22:22 2022 From: pugs78 at gmail.com (Tom Lyon) Date: Fri, 16 Dec 2022 08:22:22 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> Message-ID: Re: getting a 360 - IBM and AT&T really hated each other, so 360s were avoided for strategic reasons. That said, they could not be practically avoided; Holmdel had a large installation: https://www.youtube.com/watch?v=HMYiktO0D64&ab_channel=AT%26TTechChannel When Amdahl and UTS/UNIX came along, the Bell System was by far the biggest customer. On Fri, Dec 16, 2022 at 8:12 AM Dan Cross wrote: > On Fri, Dec 16, 2022 at 8:42 AM Dan Halbert wrote: > > ASCIZ was an assembler directive used for a number of different DEC > computers, and also the name for null-terminated strings. I learned it for > the PDP-10, but I'm sure it existed on other machines. It is in some PDP-10 > documentation I am looking at right now. Anyone who used DEC and did > assembly programming would have known about it. Various system calls took > ASCIZ strings. > > This raises something I've always been curious about. To what extent were > the Unix folks at Bell Labs already familiar with DEC systems before the > PDP-7? > > It strikes me that much of the published work was centered around IBM and > GE > systems (e.g., Ken's wonderful paper on regular expressions, and of course > the > Multics work). Were there other Digital machines floating around? I know a > proposal was written to get a PDP-10 for operating systems research, but it > wasn't approved. > > Relatedly, was any thought given to trying to get a 360 system? > > On 12/16/22 04:13, Dr Iain Maoileoin wrote: > > ASCIZ > > Lost in the mists of time in my mind. > > Origin, perhaps, but it exists in contemporary assemblers. Like most > sane people I try to avoid being in assembler for too long, when you're > first turning on a machine it is useful to be able to squirt a message > out of the UART if something goes dramatically wrong, and the directive > is handy for that. > > It seems to have made its way into Research assembler via BSD; it's in > locore.s in 8th Edition, for instance, but doesn't appear before that. The > "UNIX Assembler Manual" describes "String Statements" for the 7th > Edition assembler; strings are sequences of ASCII characters between > '<' and '>'. But it doesn't say that they're NUL terminated, and they are > not: adding the terminator was manual via the familiar, `\0` escape > sequence. > > - Dan C. > > > > I remember running into a .asciz directive n the 70s “somewhere”. > > It was an assembler directive in one of the RT11 systems??? or perhaps > the unix bootstrap and/or “.s” files - when I get some time I will go read > some old code/manuals. > > > > I > > > > Yes, it put a null byte at the end of a string. > > > > On 16 Dec 2022, at 03:14, Ken Thompson wrote: > > > > asciz -- this is the first time i heard of it. > > doug -- yes. > > > > > > On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > >> I think this cited quote from > >> https://www.joelonsoftware.com/2001/12/11/ is urban legend. > >> > >> Why do C strings [have a terminating NUl]? It’s because the PDP-7 > >> microprocessor, on which UNIX and the C programming language were > >> invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) > >> at the end.” > >> > >> This assertion seems unlikely since neither C nor the library string > >> functions existed on the PDP-7. In fact the "terminating character" of > >> a string in the PDP-7 language B was the pair '*e'. A string was a > >> sequence of words, packed two characters per word. For odd-length > >> strings half of the final one-character word was effectively > >> NUL-padded as described below. > >> > >> One might trace null termination to the original (1965) proposal for > >> ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only > >> role specifically suggested for NUL is to "serve to accomplish time > >> fill or media fill." With character-addressable hardware (not the > >> PDP-7), it is only a small step from using NUL as terminal padding to > >> the convention of null termination in all cases. > >> > >> Ken would probably know for sure whether there's any truth in the > >> attribution to ASCIZ. > >> > >> Doug > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Dec 17 02:29:20 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 16 Dec 2022 08:29:20 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> Message-ID: <202212161629.2BGGTKSU2417723@darkstar.fourwinds.com> Dan Cross writes: > > This raises something I've always been curious about. To what extent were > the Unix folks at Bell Labs already familiar with DEC systems before the PDP-7? Well, I recall that there was a PDP-8 in the keypunch room on the 5th floor of building 2. I believe that it was hooked to a card reader and printer so that one could get a listing of a deck of cards without having to use the computer center. But that's probably not what you're asking about. Jon From jpl.jpl at gmail.com Sat Dec 17 03:24:11 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 16 Dec 2022 12:24:11 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: Suppose you have two strings of 8-bit bytes, and you'd like to compare them lexicographically (left to right, byte by byte). An oracle tells you the length of the strings, so maybe you have 3 ram 4 ramp You can just do an strncmp on the two strings, using the minimum of the two lengths (3 in the example). If they differ (they didn't), you are done. If the strings are of the same length (they aren't), they are equal. Otherwise, the shorter (a prefix of the longer) compares low. Ho-hum. Suppose each comparand is a sequence of such strings, and you want to break ties on initial components of such sequences using subsequent components (if any). But you have to combine them as a single string and the oracle only tells you the total length. You can't just concatenate them together, or (3 ram, 4 part) => 7 rampart (4 ramp, 3 art) => 7 rampart (7 rampart) => 7 rampart and they all look equal, but they're not supposed to be. The problem is that some components are proper prefixes of the corresponding component. We can sneak past the end of one component and compare bytes from different components, something that cannot be allowed. A collection of components is said to have "the prefix property" if no component is a proper prefix of any other component. If there is some byte that cannot occur in some component, we can tack that byte onto the component, and the components will then have the prefix property. Newline terminated lines have the prefix property, but we cannot just concatenate such components and do an strncmp, because newlines compare low to most bytes, but high to some legitimate bytes, like tabs, so they don't break ties correctly. Null terminators to the rescue! These induce the prefix property, and compare low to everything else. Using blanks to stand in for hard-to-parse null bytes, we get (4 ram , 5 part ) => 9 ram part (5 ramp , 4 art ) => 9 ramp art (8 rampart ) => 8 rampart The strncmp on the results establishes the desired order. The null terminator on the final component is optional. The oracular length determines how much of the component is significant. But you have to be consistent. The final component must always, or never, have the "optional" terminator. Null-terminated strings (which cannot, themselves, contain a null) are not the only components having the prefix property. Fixed length strings cannot, by definition, include proper prefixes, and they are free to contain any byte. UTF-8 code-points have the prefix property (I suspect this was no accident), so the null-terminated concatenation of non-null UTF-8 code-points have the prefix property and break ties appropriately (assuming that the code-points themselves establish the correct order for what is being compared). I doubt that this explains the use of null terminated strings, but for those of use who spend too much time thinking about sorting, they sure work well. On Thu, Dec 15, 2022 at 10:04 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I think this cited quote from > https://www.joelonsoftware.com/2001/12/11/ is urban legend. > > Why do C strings [have a terminating NUl]? It’s because the PDP-7 > microprocessor, on which UNIX and the C programming language were > invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) > at the end.” > > This assertion seems unlikely since neither C nor the library string > functions existed on the PDP-7. In fact the "terminating character" of > a string in the PDP-7 language B was the pair '*e'. A string was a > sequence of words, packed two characters per word. For odd-length > strings half of the final one-character word was effectively > NUL-padded as described below. > > One might trace null termination to the original (1965) proposal for > ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only > role specifically suggested for NUL is to "serve to accomplish time > fill or media fill." With character-addressable hardware (not the > PDP-7), it is only a small step from using NUL as terminal padding to > the convention of null termination in all cases. > > Ken would probably know for sure whether there's any truth in the > attribution to ASCIZ. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Dec 17 06:12:13 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Dec 2022 07:12:13 +1100 (EST) Subject: [TUHS] origin of null-terminated strings In-Reply-To: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: On Fri, 16 Dec 2022, Dr Iain Maoileoin wrote: > I remember running into a .asciz directive n the 70s “somewhere”. It was > an assembler directive in one of the RT11 systems??? or perhaps the unix > bootstrap and/or “.s” files - when I get some time I will go read some > old code/manuals. MACRO-11 on RSX-11D seems to ring a bell... -- Dave From imp at bsdimp.com Sat Dec 17 07:02:26 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 16 Dec 2022 14:02:26 -0700 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: On Fri, Dec 16, 2022, 1:12 PM Dave Horsfall wrote: > On Fri, 16 Dec 2022, Dr Iain Maoileoin wrote: > > > I remember running into a .asciz directive n the 70s “somewhere”. It was > > an assembler directive in one of the RT11 systems??? or perhaps the unix > > bootstrap and/or “.s” files - when I get some time I will go read some > > old code/manuals. > > MACRO-11 on RSX-11D seems to ring a bell... > I first encountered it on RSTS/E 6C in the MACRO-11 it had... But the v6 macro assembler from DEC via Harvard that eventually wound up in 2BSD is older and dates to 1977 or so. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Dec 17 07:13:05 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Dec 2022 16:13:05 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: So I went to the oracle on much of DEC history ... -- this explains why Ken never heard it. ---------- Forwarded message --------- From: Timothe Litt Date: Fri, Dec 16, 2022 at 3:40 PM Subject: Re: Origin of ASCIZ / null terminated char arrays. To: Clem Cole On 16-Dec-22 15:04, Clem Cole wrote: Do either of you know when it showed up in DEC assemblers? I remember it in Macro11 and Macro10, but I have to believe it was in the earlier machines? So far I have not found a reference to it in any of my PDP-8 stuff (which is small) and I never had the docs for 6, 7 or 9 -- I assume Al K. has them on bitsavers - so I'm going to go poking around - but I thought I'd ask you two if you knew. Ken Thompson says he had never heard of it before, but he never used the DEC assemblers -- (he wrote their own on the Honeywell originally I believe). FWIW: B did not use null-terminated char arrays originally, but by the time dmr morphed B into newB then C, they had become standard. Like many, I had always thought Dennis picked them from the DEC assembler, but as Ken says - they never really used it. I was trying to figure out when they (null terminate char arrays) started to become more standard and specifically the pdeudo OP ASCIZ to create them. Tx Clem It depends on if you require ASCII, or just character strings terminated by a stop code... The -11 has .asciz (as does VMS Macro,...); the -10 has ASCIZ. SIXBIT 0 is a space, so you needed to know the length, oftentimes in words, so strip trailing 00s. The basic 8 assembler (PAL) didn't even have ASCII data. http://www.bitsavers.org/pdf/dec/pdp8/software/DEC-08-ASAC-D_PAL-III_Symbolic_Assembler_Programming_Manual.pdf Macro-8 does; the TEXT pseudo-op uses 00 as a stop code. (It also uses a 6-bit ASCII code). " is a single character ASCII constant, but not used for strings. https://www.grc.com/pdp-8/docs/macro-8_programming_manual.pdf The -15 has .ASCII and .SIXBIT, but no .ASCIZ. http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp15/DEC-15-AMZA-D_MACRO15.pdf Probably of most interest to the Unix history, the PDP-7 assembler's TEXT pseudo-op 'in order to separate the string from other data following it, a termination code determined by the character mode is inserted automatically after the last character code of the string"/... http://www.bitsavers.org/pdf/dec/pdp7/PDP-7_AsmMan.pdf I don't remember and/or didn't use the earlier assemblers, but many of the manuals are on bitsavers. Both NUL and RUBOUT (a.k.a. DELETE) were used as fill characters to cover the time teletypes take to execute and . you couldn't represent the NUL version with ASCIZ, and RUBOUT was picked for the ability to overpunch paper tape typos. Neither function, nor the use of NUL as an end of string marker is in the ASCII standard, IIRC. ᐧ > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Sat Dec 17 07:18:10 2022 From: luther at makerlisp.com (Luther Johnson) Date: Fri, 16 Dec 2022 14:18:10 -0700 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: I used RT-11 versions 4 and 5, and I seem to remember the MACRO-11 there had .ASCIZ. On 12/16/2022 02:02 PM, Warner Losh wrote: > > > On Fri, Dec 16, 2022, 1:12 PM Dave Horsfall > wrote: > > On Fri, 16 Dec 2022, Dr Iain Maoileoin wrote: > > > I remember running into a .asciz directive n the 70s > “somewhere”. It was > > an assembler directive in one of the RT11 systems??? or perhaps > the unix > > bootstrap and/or “.s” files - when I get some time I will go > read some > > old code/manuals. > > MACRO-11 on RSX-11D seems to ring a bell... > > > I first encountered it on RSTS/E 6C in the MACRO-11 it had... But the > v6 macro assembler from DEC via Harvard that eventually wound up in > 2BSD is older and dates to 1977 or so. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Sat Dec 17 07:20:59 2022 From: halbert at halwitz.org (Dan Halbert) Date: Fri, 16 Dec 2022 16:20:59 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: On 12/16/22 16:02, Warner Losh wrote: > On Fri, Dec 16, 2022, 1:12 PM Dave Horsfall wrote: > > On Fri, 16 Dec 2022, Dr Iain Maoileoin wrote: > > > I remember running into a .asciz directive n the 70s > “somewhere”. It was > > an assembler directive in one of the RT11 systems??? or perhaps > the unix > > bootstrap and/or “.s” files - when I get some time I will go > read some > > old code/manuals. > > MACRO-11 on RSX-11D seems to ring a bell... > > > I first encountered it on RSTS/E 6C in the MACRO-11 it had... But the > v6 macro assembler from DEC via Harvard that eventually wound up in > 2BSD is older and dates to 1977 or so. > > Warner The PDP-10 manual I spoke of is from 1971, and there were older editions. For the PDP-7, this manual from 1965, http://www.bitsavers.org/pdf/dec/pdp7/PDP-7_AsmMan.pdf, printed pages 38-40, does not mention "ASCIZ" specifically, but talks about assembler directives "TELETYPE" and "ANALEX" that add a "termination code" of 00 octal, for characters. DEC also used SIXBIT, a truncated ASCII code that had printing characters but no control characters, so no newline, etc. In that scheme, 00 octal was SPACE. Table here: https://en.wikipedia.org/wiki/Six-bit_character_code#Examples_of_six-bit_ASCII_variants. Dan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Dec 17 07:49:54 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Dec 2022 16:49:54 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: More info WRT to historical DEC usage ... ---------- Forwarded message --------- From: Bob Supnik Date: Fri, Dec 16, 2022 at 4:39 PM Subject: Re: Origin of ASCIZ / null terminated char arrays. To: Clem Cole It wasn't in the PDP8. The PDP8 mostly used sixbit, the ASCII subset between 40 and 137. The character was simply masked by 077, so that 100 (@) became 0 and could be used as the delimiter. PAL8 (in OS8) does not have a text generation pseudo-op. The PDP7 had a TEXT pseudo-op that fill an extra word with 0s if the string was a multiple of 3 characters. It supported FIODEC, BAUDOT, and ANALEX encodings, but not ASCII. The PDP9 has both .SXBIT and .ASCII. The latter used two 18-bit words to hold five 7bit ASCII characters. In both cases, words were zero-filled, but an extra (word) of 0s was not added if the string was a multiple of 2/multiple of 5 characters. The PDP11 had .ASCIZ, starting with Macro11 in 1972. Tim can comment on the PDP10. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Dec 17 08:26:19 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 16 Dec 2022 17:26:19 -0500 Subject: [TUHS] origin of null-terminated strings Message-ID: > To what extent were the Unix folks at Bell Labs already familiar with DEC systems before the PDP-7? Some awareness, but no hands-on experience, > was any thought given to trying to get a 360 system? Very serious thought. However, virtual memory was a non-negotiable desideratum, to which Gene Amdahl was implacably opposed because demand paging would devastate hardware performance. Soon after GE got the nod, IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, but by then the die had been cast. Michigan bought one and built a nice time-sharing system that was running well before Multics. Doug From alx.manpages at gmail.com Sat Dec 17 08:30:34 2022 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Fri, 16 Dec 2022 23:30:34 +0100 Subject: [TUHS] Terms for string, and similar character constructs (was: origin of null-terminated strings) In-Reply-To: <6009124d-750d-365e-a424-ec7bb25922b9@gmail.com> References: <6009124d-750d-365e-a424-ec7bb25922b9@gmail.com> Message-ID: <1ef751f4-16d0-69a1-367b-d201f815e88c@gmail.com> [Resend from my subscribed address, as the list is subscribers-only, it seems] In C, most syscalls and libc functions use strings, that is, zero or more non-NUL characters followed by a NUL. However, there are a few cases where other incompatible character constructs are used. A few examples: - utmpx(5): Some of its fields use fixed-width char arrays which contain a sequence of non-NUL characters, and padding of NULs to fill the rest (although some systems only require a NUL to delimit the padding, which can then contain garbage). - Some programs use just a pointer and a length to determine sequences of characters. No NULs involved. - abstract sockets: On Linux, abstract Unix socket names are stored in a fixed-width array, and all bytes are meaningful (up to the specified size), even if they are NULs. Only special that that the first byte is NUL. Since those are only rare cases, those constructs don't seem to have a name; some programmers call them strings (quite confusingly). Has there been any de-facto standard (or informal naming) to call those things, and differentiate them? Thanks, Alex -- From dave at horsfall.org Sat Dec 17 08:51:29 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Dec 2022 09:51:29 +1100 (EST) Subject: [TUHS] Terms for string, and similar character constructs (was: origin of null-terminated strings) In-Reply-To: <1ef751f4-16d0-69a1-367b-d201f815e88c@gmail.com> References: <6009124d-750d-365e-a424-ec7bb25922b9@gmail.com> <1ef751f4-16d0-69a1-367b-d201f815e88c@gmail.com> Message-ID: On Fri, 16 Dec 2022, Alejandro Colomar wrote: > [Resend from my subscribed address, as the list is subscribers-only, it seems] Of course; open lists are spam magnets... Regretful, but true. -- Dave From jnc at mercury.lcs.mit.edu Sat Dec 17 09:11:44 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 16 Dec 2022 18:11:44 -0500 (EST) Subject: [TUHS] origin of null-terminated strings Message-ID: <20221216231144.62E0518C087@mercury.lcs.mit.edu> > From: Bob Supnik > The PDP11 had .ASCIZ, starting with Macro11 in 1972. I was just about to report on my results, after a tiny bit of digging, which included this. The important datum is that PAL-11 (in DEC-11-GGPB-D, "paper tape software", April 1970, revised March 1971), which _preceded_ Macro-11, _does not_ include .ASCIZ (although it has .ASCII). My oldest Macro-11 book (DEC-11-OMACA-B-D, "BATCH-11/DOS-11 Assembler (MACRO-11)", April 1972, revised March 1973) does have .ASCIZ. So in the DEC PDP-11 universe, it dates from sometime between 1970 and 1972. I'm not sure if Bell had any of the DEC paper tape software: "In early 1970 we proposed acquisition of a PDP-11, which had just been introduced by Digital. ... an order for a PDP-11 was placed in May. The processor arrived at the end of the summer, but the PDP-11 was so new a product that no disk was available until December. In the meantime, a rudimentary, core-only version of Unix was written using a cross-assembler on the PDP-7." So the .ASCIZ in Macro-11 wasn't until a couple of years later. Noel From phil at ultimate.com Sat Dec 17 10:26:50 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 16 Dec 2022 19:26:50 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> Message-ID: <202212170026.2BH0QoH7060198@ultimate.com> > From: Bob Supnik > Tim can comment on the PDP10. MACRO10 (the DEC PDP-10 assembler) had the ASCIZ directive, I don't see it in the May 1964 MACRO6 (PDP-6 assembler) document at: http://bitsavers.trailing-edge.com/pdf/dec/pdp6/F-64MAS_MACRO6_Assembly_Program_May64.pdf Nor the February 1965 version: http://bitsavers.trailing-edge.com/pdf/dec/pdp6/DEC-6-0-TP-MAC-LM-FP-ACT01_MACRO-6_Assembly_Language_Feb65.pdf But it does appear in the May 1965 MACRO-6 manual: http://bitsavers.trailing-edge.com/pdf/dec/pdp6/DEC-6-0-TP-MAC-LM-FP_ACT02_MACRO-6_Assembly_Language_May65.pdf Which has the fullly trifuricated character packings: ASCII/ASCIZ: 7 bit bytes, with the low order bit left over (set at the start of lines in files to indicate a Line Sequence Number metadata for line number based editors) SIXBIT "6-bit ASCII" -- ASCII characters 040 thru 0137 stored as 00 thru 077 in six six bit bytes RADIX50 6 characters from a 40 (050) character character set (plus four flag bits) used to store symbol tables https://en.wikipedia.org/wiki/DEC_RADIX_50#36-bit_systems And ASCIZ is used in listings of the PDP-6 "T.S. Executive" version 1.4 dated 8-18-65: http://bitsavers.trailing-edge.com/pdf/dec/pdp6/tsExec1.4/COMCON.pdf COMCON is "COMmand CONtrol" -- the top level command interpreter built into the monitor (the file name was retained into the later days of TOPS-10), and messages output to the user use ASCIZ directives. And to tie the thread back (closer) to the list subject, the "sub title" headers in the above assembler listing file are "T. HASTINGS 8-2-65" (who I believe is Tom Hastings), which also appears in many other files, including the job scheduler: http://bitsavers.trailing-edge.com/pdf/dec/pdp6/tsExec1.4/CLKCSS.pdf *AND* T. Hastings also appears as an author of the CTSS scheduler: https://softwarehistory.csse.rose-hulman.edu/index.php/ctss-scheduler/ (in the "Full Code" section): :R******TIME SHARING SCHEDULING ALGORITHM*********** :R T. Hastings and R. Daley :R Minor Modifications by G. Schroeder when NEW :R I/O Package Installed....Summer, 1965 From frew at ucsb.edu Sat Dec 17 12:03:15 2022 From: frew at ucsb.edu (James Frew) Date: Fri, 16 Dec 2022 18:03:15 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: <2875e06b-c744-2467-2c9e-b16b53bcde5a@ucsb.edu> Yes, MTS (Michigan Terminal System)! One of my first jobs as a geography grad student was helping Waldo Tobler port a bunch of his MTS Fortran* programs to UCSB's 370/168 running OS/MVT. Definitely a step backwards, as Waldo never ceased to remind me. He calmed down once he got a Tektronix storage tube display connected to our PDP-11/45 running v6; seemed like UNIX was almost as nice as MTS... /Frew *commented in German... On 2022-12-16 14:26, Douglas McIlroy wrote: >> was any thought given to trying to get a 360 system? > Very serious thought. However, virtual memory was a non-negotiable > desideratum, to which Gene Amdahl was implacably opposed because > demand paging would devastate hardware performance. Soon after GE got > the nod, IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, > but by then the die had been cast. Michigan bought one and built a > nice time-sharing system that was running well before Multics. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sat Dec 17 13:42:59 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sat, 17 Dec 2022 14:42:59 +1100 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: > On 17 Dec 2022, at 09:26, Douglas McIlroy wrote: > >> >> was any thought given to trying to get a 360 system? > > Very serious thought. However, virtual memory was a non-negotiable > desideratum, to which Gene Amdahl was implacably opposed because > demand paging would devastate hardware performance. Soon after GE got > the nod, IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, > but by then the die had been cast. Michigan bought one and built a > nice time-sharing system that was running well before Multics. > > Doug Doug, Thanks for the insight. I've seen “MTS” mentioned, but never properly understood its significance. Never looked into it, either :( Brief search results below, w/o Wikipedia etc. A process step of building new ’things’, skipped on all computing / I.T. projects I worked on, is a “Post Mortem” a.k.a “Post Implementation Review”. If MIT / Bell Labs / GE ever did a project review on Multics, I’d love to know if it’s been published, and what insights they came away with, and any changes made to their development & project management processes. The MIT lead, Corbató / Corby, had demonstrated a high-level of competence & ability. He'd built CTSS in 1961 and won the ACM Turing Award in 1990. Never given to "second best”. It wasn’t a lack of talent, need, desire (for a product/service to sell) or funding that made Multics take years & years. With the capability & experience of the people involved, it'd be simplistic and superficial to attribute the project delays to “Second System Effect”. Is it more akin to what we’re seeing now in the differences in approach to building Space Launch Systems & Vehicles? I don’t have words/ concepts for the different approaches, but they seem to parallel how Multics & Unix were developed. - NASA & Boeing et al have only just flown the Space Shuttle replacement, Artemis, the SLS pluse Orion capsule. In 2005, a program to replace the Shuttle (retired in 2011) was begun. This was replaced with the SLS / Artemis program in 2010 - reusing many of the Shuttle components, eg RS-25 engines. Next flight, Artemis 2, due in 2024. - Space-X is developing it’s second launch system, plus a Crew / Cargo vehicle (StarShip). Falcon 9 has become the cheapest per kg/LEO, most reliable and most flown rocket in history. They’ve already beaten 1 launch/week this year, lofting 150+ tons per quarter into LEO. Which is more than two-times all other programs, public or private, put together. steve j ======== David L. Mills, photo gallery & some comments Michigan Terminal System (MTS) During much of the 1960s I was a staff member at the U Michigan Computing Center. I worked with a bunch of other guys on various hardward and software projects, one of which is described on this page. ======== Organization and features of the Michigan terminal system Michael T. Alexander 16 November 1971 ABSTRACT This paper will explore some aspects of the Michigan Terminal System (MTS) developed at the University of Michigan. MTS is the operating system used on the IBM 360/67 at the University of Michigan Computing Center, as well as at several other installations. It supports a large variety of uses ranging from very small student-type jobs to large jobs requiring several million bytes of storage and hours of processor time. Currently at the University of Michigan there are about 13,000 users running as many as 86,000 jobs per month. ======== Time-sharing in the IBM system/360: model 67 Charles T. Gibson IBM Fine detail of 360/67, differences to /50. TSS mentioned ======== -- 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 clemc at ccc.com Sun Dec 18 03:11:41 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 17 Dec 2022 12:11:41 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and TSS hackers that were also later to be UNIX hackers after their original introduction to system programming as undergrads. I will keep this reply in TUHS, although it could be argued that it belongs in COFF. Note good sources for even more of the background of the history politics at both IBM & GE can be found in Haigh and Ceruzzi's book: "A New History of Modern Computing " - which I have previously mentioned as it is a beautiful read. On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, > but by then the die had been cast. Michigan bought one and built a > nice time-sharing system that was running well before Multics. > All true, but a few details are glossed over, and thus, this could be misinterpreted - so I'm going to add those as one of the people. TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note that the /67 could run as a model /65, which as I understand it, most of the ones IBM sold did. At the time, IBM offered the /67 to Universities at a substantial discount (I believe even less than the /65). Thus, several schools bought them with Michigan, CMU, Cornell, and Princeton that I am aware of; but I suspect there were others. TSS was late, and the first releases could have been more stable. Cornell and Princeton chose to run their systems as /65 using the original IBM OS. CMU and Michigan both received copies of TSS with their systems. Michigan would do a substantial rewrite, which was different enough that became the new system MTS. CMU did a great deal of bug fixing, which went back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by data and TSS at night until they felt they could trust it to not crash]. Nominally, TSS and MTS should share programs, and with some work, both could import source programs from OS/360 [My first paid programming job was helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers and many tools for all three were common. MTS and TSS used the same file system structure, or it was close enough that tools were shared. I don't know if OS/360 could read TSS disk packs - I would have suspected, although the common media of the day was 1/2" mag tape. This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know as a different name in the first version - was modeled after the disk scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty primitive if you had used to see the other as a system programmer first. Also, a big reason why all the errors were originally in uppercase was the IBM program had done it. In many ways, neither Ted nor I knew any better at the time. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sun Dec 18 04:15:11 2022 From: pugs78 at gmail.com (Tom Lyon) Date: Sat, 17 Dec 2022 10:15:11 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of CMS. >From Melinda Varian's amazing history of VM, I gleaned these factoids: CP-67 - 8 sites by May '68 Feb of 68 - IBM decommits from TSS Apr 69 - IBM rescinds decommit of TSS CP-67 - 44 sites by 1970, ~10 internal to IBM May 71 - TSS finally decommitted So TSS was a rocky road, while CP&VM were simple and just worked. On Sat, Dec 17, 2022 at 9:13 AM Clem Cole wrote: > Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and > TSS hackers that were also later to be UNIX hackers after their original > introduction to system programming as undergrads. I will keep this reply > in TUHS, although it could be argued that it belongs in COFF. > > Note good sources for even more of the background of the history politics > at both IBM & GE can be found in Haigh and Ceruzzi's book: "A New History > of Modern Computing > " - > which I have previously mentioned as it is a beautiful read. > > On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, >> but by then the die had been cast. Michigan bought one and built a >> nice time-sharing system that was running well before Multics. >> > All true, but a few details are glossed over, and thus, this could be > misinterpreted - so I'm going to add those as one of the people. > > TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note that the > /67 could run as a model /65, which as I understand it, most of the ones > IBM sold did. > > At the time, IBM offered the /67 to Universities at a substantial discount > (I believe even less than the /65). Thus, several schools bought them with > Michigan, CMU, Cornell, and Princeton that I am aware of; but I suspect > there were others. > > TSS was late, and the first releases could have been more stable. > Cornell and Princeton chose to run their systems as /65 using the original > IBM OS. CMU and Michigan both received copies of TSS with their systems. > Michigan would do a substantial rewrite, which was different enough that > became the new system MTS. CMU did a great deal of bug fixing, which went > back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by > data and TSS at night until they felt they could trust it to not crash]. > Nominally, TSS and MTS should share programs, and with some work, both > could import source programs from OS/360 [My first paid programming job was > helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers > and many tools for all three were common. > > MTS and TSS used the same file system structure, or it was close enough > that tools were shared. I don't know if OS/360 could read TSS disk packs - > I would have suspected, although the common media of the day was 1/2" mag > tape. > > This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know > as a different name in the first version - was modeled after the disk > scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty > primitive if you had used to see the other as a system programmer first. > Also, a big reason why all the errors were originally in uppercase was the > IBM program had done it. In many ways, neither Ted nor I knew any better > at the time. > > Clem > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Dec 18 04:43:52 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 17 Dec 2022 13:43:52 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: Tom Lyon -- TSS was around and supported into the 80's. That said, I've seen that May '71, but it might be a typo -- '81 sounds much more plausible as it real death. IIRC Tom Haight has better dates in his book. FWIW: I was at CMU in the mid 70s [programming TSS including installing fixes from the IBM support team]. Plus, my old boss, Dean Hiller, left CMU in the late 70s to work for IBM as a TSS system person [he retired from IBM years later and had moved to the AIX team at one point]. And I also have a copy of one of the TSS documents that has a printing date of 1980. It's also possible IBM stopped *selling new sites* in the early 70s, but TSS was definitely a supported product throughout the 1980s. IBM had some large and important customers running TSS, in particular, NASA and I believe a couple of automotive ones -- maybe GM and Rolls Royce but I don't know. IIRC: One of the original mechanical CAD programs had been developed on it and users needed either MTS or TSS to run it properly. I also remember that in 77-78, when CMU started to move off the /67 to the DEC-20s, IBM had counter-proposed an S370/168 with VM on it - which CMU had rejected. But Amdahl had proposed CMU could keep running TSS on their then-newest system which was at least the V7 (maybe the V8 as I have forgotten when the latter was released). Around that same time, Michigan had stayed with MTS but had switched to Amdhal as the vendor. ᐧ On Sat, Dec 17, 2022 at 1:15 PM Tom Lyon wrote: > Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of > CMS. > From Melinda Varian's amazing history of VM, I gleaned these factoids: > CP-67 - 8 sites by May '68 > Feb of 68 - IBM decommits from TSS > Apr 69 - IBM rescinds decommit of TSS > CP-67 - 44 sites by 1970, ~10 internal to IBM > May 71 - TSS finally decommitted > > So TSS was a rocky road, while CP&VM were simple and just worked. > > > > On Sat, Dec 17, 2022 at 9:13 AM Clem Cole wrote: > >> Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and >> TSS hackers that were also later to be UNIX hackers after their original >> introduction to system programming as undergrads. I will keep this reply >> in TUHS, although it could be argued that it belongs in COFF. >> >> Note good sources for even more of the background of the history politics >> at both IBM & GE can be found in Haigh and Ceruzzi's book: "A New >> History of Modern Computing >> " - >> which I have previously mentioned as it is a beautiful read. >> >> On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < >> douglas.mcilroy at dartmouth.edu> wrote: >> >>> IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, >>> but by then the die had been cast. Michigan bought one and built a >>> nice time-sharing system that was running well before Multics. >>> >> All true, but a few details are glossed over, and thus, this could be >> misinterpreted - so I'm going to add those as one of the people. >> >> TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note that >> the /67 could run as a model /65, which as I understand it, most of the >> ones IBM sold did. >> >> At the time, IBM offered the /67 to Universities at a >> substantial discount (I believe even less than the /65). Thus, several >> schools bought them with Michigan, CMU, Cornell, and Princeton that I am >> aware of; but I suspect there were others. >> >> TSS was late, and the first releases could have been more stable. >> Cornell and Princeton chose to run their systems as /65 using the original >> IBM OS. CMU and Michigan both received copies of TSS with their systems. >> Michigan would do a substantial rewrite, which was different enough that >> became the new system MTS. CMU did a great deal of bug fixing, which went >> back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by >> data and TSS at night until they felt they could trust it to not crash]. >> Nominally, TSS and MTS should share programs, and with some work, both >> could import source programs from OS/360 [My first paid programming job was >> helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers >> and many tools for all three were common. >> >> MTS and TSS used the same file system structure, or it was close enough >> that tools were shared. I don't know if OS/360 could read TSS disk packs - >> I would have suspected, although the common media of the day was 1/2" mag >> tape. >> >> This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know >> as a different name in the first version - was modeled after the disk >> scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty >> primitive if you had used to see the other as a system programmer first. >> Also, a big reason why all the errors were originally in uppercase was the >> IBM program had done it. In many ways, neither Ted nor I knew any better >> at the time. >> >> Clem >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Dec 18 04:46:16 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 17 Dec 2022 13:46:16 -0500 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: typo... sigh... TSS was definitely a supported product throughout *the 1970s and into* the 1980s ᐧ On Sat, Dec 17, 2022 at 1:43 PM Clem Cole wrote: > Tom Lyon -- TSS was around and supported into the 80's. That said, I've > seen that May '71, but it might be a typo -- '81 sounds much more plausible > as it real death. IIRC Tom Haight has better dates in his book. > > FWIW: I was at CMU in the mid 70s [programming TSS including installing > fixes from the IBM support team]. Plus, my old boss, Dean Hiller, left CMU > in the late 70s to work for IBM as a TSS system person [he retired from IBM > years later and had moved to the AIX team at one point]. And I also have > a copy of one of the TSS documents that has a printing date of 1980. > > It's also possible IBM stopped *selling new sites* in the early 70s, but > TSS was definitely a supported product throughout the 1980s. IBM had some > large and important customers running TSS, in particular, NASA and I > believe a couple of automotive ones -- maybe GM and Rolls Royce but I don't > know. IIRC: One of the original mechanical CAD programs had been > developed on it and users needed either MTS or TSS to run it properly. > > I also remember that in 77-78, when CMU started to move off the /67 to the > DEC-20s, IBM had counter-proposed an S370/168 with VM on it - which CMU had > rejected. But Amdahl had proposed CMU could keep running TSS on their > then-newest system which was at least the V7 (maybe the V8 as I have > forgotten when the latter was released). > > Around that same time, Michigan had stayed with MTS but had switched to > Amdhal as the vendor. > ᐧ > > On Sat, Dec 17, 2022 at 1:15 PM Tom Lyon wrote: > >> Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of >> CMS. >> From Melinda Varian's amazing history of VM, I gleaned these factoids: >> CP-67 - 8 sites by May '68 >> Feb of 68 - IBM decommits from TSS >> Apr 69 - IBM rescinds decommit of TSS >> CP-67 - 44 sites by 1970, ~10 internal to IBM >> May 71 - TSS finally decommitted >> >> So TSS was a rocky road, while CP&VM were simple and just worked. >> >> >> >> On Sat, Dec 17, 2022 at 9:13 AM Clem Cole wrote: >> >>> Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and >>> TSS hackers that were also later to be UNIX hackers after their original >>> introduction to system programming as undergrads. I will keep this reply >>> in TUHS, although it could be argued that it belongs in COFF. >>> >>> Note good sources for even more of the background of the history >>> politics at both IBM & GE can be found in Haigh and Ceruzzi's book: "A >>> New History of Modern Computing >>> " - >>> which I have previously mentioned as it is a beautiful read. >>> >>> On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < >>> douglas.mcilroy at dartmouth.edu> wrote: >>> >>>> IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, >>>> but by then the die had been cast. Michigan bought one and built a >>>> nice time-sharing system that was running well before Multics. >>>> >>> All true, but a few details are glossed over, and thus, this could be >>> misinterpreted - so I'm going to add those as one of the people. >>> >>> TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note >>> that the /67 could run as a model /65, which as I understand it, most >>> of the ones IBM sold did. >>> >>> At the time, IBM offered the /67 to Universities at a >>> substantial discount (I believe even less than the /65). Thus, several >>> schools bought them with Michigan, CMU, Cornell, and Princeton that I am >>> aware of; but I suspect there were others. >>> >>> TSS was late, and the first releases could have been more stable. >>> Cornell and Princeton chose to run their systems as /65 using the original >>> IBM OS. CMU and Michigan both received copies of TSS with their systems. >>> Michigan would do a substantial rewrite, which was different enough that >>> became the new system MTS. CMU did a great deal of bug fixing, which went >>> back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by >>> data and TSS at night until they felt they could trust it to not crash]. >>> Nominally, TSS and MTS should share programs, and with some work, both >>> could import source programs from OS/360 [My first paid programming job was >>> helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers >>> and many tools for all three were common. >>> >>> MTS and TSS used the same file system structure, or it was close enough >>> that tools were shared. I don't know if OS/360 could read TSS disk packs - >>> I would have suspected, although the common media of the day was 1/2" mag >>> tape. >>> >>> This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know >>> as a different name in the first version - was modeled after the disk >>> scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty >>> primitive if you had used to see the other as a system programmer first. >>> Also, a big reason why all the errors were originally in uppercase was the >>> IBM program had done it. In many ways, neither Ted nor I knew any better >>> at the time. >>> >>> Clem >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.perrine+tuhs at gmail.com Sun Dec 18 05:26:14 2022 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Sat, 17 Dec 2022 11:26:14 -0800 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: I can offer at least one perspective on Multics, although from a limited viewpoint. I was an Explorer Scout at post 414, sponsored by Honeywell, in Phoenix, from about 1972 onwards. This was a "high tech" special interest Post, and our interest was computers - no surprise. Weekly meetings included time using Teletypes (and later nicer terminals) to connect to a GCOS system in Phoenix. Programming in Basic, FORTRAN, COBOL and other arcane languages ensued. As did "an incident". Pretty minor, but yeah, some high school kids "popped" (for some value of "popped") the local GCOS system and got access to some files they shouldn't have. I'm not sure if this was dumpster diving, or a real bug, or just exploiting some employee carelessly setting file permissions to "read and write for the entire system". I strongly suspect the latter. As a result, all our GCOS accounts were cancelled and we were moved to System M, one of the primary development systems for Multics. As was new and not all common at the time, the entire source code for the entire system was available online - and not just because this was a dev system, this was the norm for all Multics owners. In this way, Multics followed the UNIX model, or maybe they came from a common theme. The Post took to PL/1 in a big way and delivered some interesting changes to (mostly) the games on the system - vbg (Video BackGammon), chess, yet another space wars clone, and a huge expanded ADVENTURE. There was also some interesting new programming, including finding a way to exploit IPC channels, and another way to crash the front end processor, that led to some emergency bugfixes being rolled out (I later learned) overnight to the Pentagon and "the Fort" customers. Speaking of which, there was a bit of a kerfluffle when someone who shall remain nameless, innocently asked "I identified all the Multics systems in the site documents, except System N. Where is System N?" in a public forum on System M. I was warned Never To Speak of System "N" Ever Again Or Else. Over the next 10 years, a lot of my technical life was around Multic. As a Boy Scout, and eventually as a student intern at Honeywell. Throughout college all my engineering programming was done on Multics, mostly in pl1, instead of fortran. As an intern I worked on projects across the GCOS (GCOS-8), Multics and even a little CP-6 spaces. I got to see and hear how different parts of the company saw the GCOS vs Multics conflict, admittedly filtered through the eyes of a still naive intern. Here are some recollections and talking points. 1. Multics hardware is too expensive! 1. GCOS 8 HW, which would have run Multics, GCOS classic and the someday GCOS 8 was even more expensive) 2. Multics HW was expensive because they built and burned-in an entire GCOS system, and then partially took it apart, re-wired the CPU boards and other parts, and then put it back together!A Multics CPU had some boards in common with a GCOS CPU, some were modified boards, and some were completely separate, if I recall correctly. Wirewrap CPU boards in addition to the wirewrapped backplane, which was also (I think) a built-and-then-rewired GCOS backplane. 2. Our customers want more batch and less timesharing! - Multics doesn't have a real batch mode! 1. which could have easily been addressed with a "dusty deck translator" from GCOS JCL to Multics "absentee" scripts. 3. Timesharing is a fad and too expensive - look at how few people our GCOS customers put on TSS! 1. yeah, because GCOS TSS was an afterthought - a big pasted-on batch job that remained primitive compared to Multics and other competitors - looking at you TOPS-20, which was also up and coming 4. Our profit margins on GCOS SW and HW are better - so we should sell more GCOS! 5. Spending money on Multics will take away resources from our bread and butter GCOS, which is where we make money! 6. No one cares about PL/1 - all our customers want COBOL and FORTRAN 1. which Multics had, and a better COBOL compiler than GCOS - I learned COBOL68 and COBOL74 on both - and along the way found a bug that would crash THE ENTIRE GCOS OPERATING SYSTEM (not just the compiler!) if you mis-spelled "ENVIRONMENT DIVISION" in a COBOL74 program. 7. GCOS (formerly GECOS, thankyouverymuch) is the real legacy of GE, not that research project from MIT!!! - Multics is a toy we were paid to make, that will never make a dime! 8. There was some rivalry between Phoenix and Billerica(?) that was mostly kept away from "the kids", so we didn't see that in detail but it was there. 9. This rivalry seemed to be (in retrospect) two orgs fighting over ever-scarcer resources as the mini/super-mini revolution came on strong. A Multics CPU was pretty much a synchronous 1 MIP machine (per CPU). Of course you could have up to 8(?) CPUs and the I/O bandwidth was light years ahead of the super-minis, but DEC said that the VaX-11/780 was a "1 MIP machine" and it was cheaper than a mainframe, so there!! Anything else would probably be off topic for TUHS, but with the inter-twined DNA of Multics and UNIX, perhaps this is actually on-topic? I would point out that I don't think Multics was a victim of UNIX adoption, as that (from my dim recollection) took place years after Multics dev had been mostly capped. After Multics, my first UNIX system was PWB on a PDP-11. It was quite the change, but led to the rest of my career - BSD, KSOS, SysV, IRIX, Ultrix, SunOS, Solaris, UNICOS, others and eventually Linux. You never forget your first :-) Regards, --tep On Sat, Dec 17, 2022 at 10:17 AM Tom Lyon wrote: > Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of > CMS. > From Melinda Varian's amazing history of VM, I gleaned these factoids: > CP-67 - 8 sites by May '68 > Feb of 68 - IBM decommits from TSS > Apr 69 - IBM rescinds decommit of TSS > CP-67 - 44 sites by 1970, ~10 internal to IBM > May 71 - TSS finally decommitted > > So TSS was a rocky road, while CP&VM were simple and just worked. > > > > On Sat, Dec 17, 2022 at 9:13 AM Clem Cole wrote: > >> Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and >> TSS hackers that were also later to be UNIX hackers after their original >> introduction to system programming as undergrads. I will keep this reply >> in TUHS, although it could be argued that it belongs in COFF. >> >> Note good sources for even more of the background of the history politics >> at both IBM & GE can be found in Haigh and Ceruzzi's book: "A New >> History of Modern Computing >> " - >> which I have previously mentioned as it is a beautiful read. >> >> On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < >> douglas.mcilroy at dartmouth.edu> wrote: >> >>> IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, >>> but by then the die had been cast. Michigan bought one and built a >>> nice time-sharing system that was running well before Multics. >>> >> All true, but a few details are glossed over, and thus, this could be >> misinterpreted - so I'm going to add those as one of the people. >> >> TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note that >> the /67 could run as a model /65, which as I understand it, most of the >> ones IBM sold did. >> >> At the time, IBM offered the /67 to Universities at a >> substantial discount (I believe even less than the /65). Thus, several >> schools bought them with Michigan, CMU, Cornell, and Princeton that I am >> aware of; but I suspect there were others. >> >> TSS was late, and the first releases could have been more stable. >> Cornell and Princeton chose to run their systems as /65 using the original >> IBM OS. CMU and Michigan both received copies of TSS with their systems. >> Michigan would do a substantial rewrite, which was different enough that >> became the new system MTS. CMU did a great deal of bug fixing, which went >> back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by >> data and TSS at night until they felt they could trust it to not crash]. >> Nominally, TSS and MTS should share programs, and with some work, both >> could import source programs from OS/360 [My first paid programming job was >> helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers >> and many tools for all three were common. >> >> MTS and TSS used the same file system structure, or it was close enough >> that tools were shared. I don't know if OS/360 could read TSS disk packs - >> I would have suspected, although the common media of the day was 1/2" mag >> tape. >> >> This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know >> as a different name in the first version - was modeled after the disk >> scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty >> primitive if you had used to see the other as a system programmer first. >> Also, a big reason why all the errors were originally in uppercase was the >> IBM program had done it. In many ways, neither Ted nor I knew any better >> at the time. >> >> Clem >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lproven at gmail.com Mon Dec 19 00:05:57 2022 From: lproven at gmail.com (Liam Proven) Date: Sun, 18 Dec 2022 15:05:57 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Message-ID: On Fri, 16 Dec 2022 at 11:43, Harald Arnesen wrote: > > Thanks! Very interesting, I didn't know much of this. My pleasure. I am a daily Unix user but my main interests tend to lie elsewhere. I don't have any citations for this, but it looked to me, watching in the magazines at the time, that _before_ the Amiga deal, QNX did run on PCs for testing purposes, but I am not totally sure if it had a GUI at all, and little to no multimedia support. My impression is that QNX implemented that for Amiga Inc and then were left with it when Amiga turned its gaze on Tao and Elate. (Some of the best remaining info about Intent and Elate is in HN comments, e.g. https://news.ycombinator.com/item?id=16053726 https://news.ycombinator.com/item?id=9807269 Which leads to: http://www.uruk.org/emu/Taos.html ) I am curious to know if the TAOS virtual-processor, all-binaries-are-CPU-independent, model influenced or inspired Inferno. I think that Inferno postdates TAOS. But returning to QNX: my impression is, they implemented a GUI and multimedia frameworks for Amiga, Amiga changed its mind, and QNX offered it as a PC dev kit for a while. E.g. https://archive.org/details/qnx-neutrino-rtos-x86-runtime-kit-6.3.0-sp3 But the only mass-market end-user-facing graphical multimedia-capable QNX devices I know of were the Blackberry X smartphones. (And cancelled tablet and netbook.) I owned a Blackberry Passport. A lovely device with a lovely OS... but too late and it flopped. So, oddly, and accidentally and unintentionally, Amiga Inc was directly responsible for the Blackberry smartphone OS. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From stuff at riddermarkfarm.ca Mon Dec 19 01:08:09 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 18 Dec 2022 10:08:09 -0500 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Message-ID: On 2022-12-18 09:05, Liam Proven wrote (in part): [...] > But returning to QNX: my impression is, they implemented a GUI and > multimedia frameworks for Amiga, Amiga changed its mind, and QNX > offered it as a PC dev kit for a while. > > E.g. > https://archive.org/details/qnx-neutrino-rtos-x86-runtime-kit-6.3.0-sp3 QNX initially ran only on x86 kit. I do not recall a GUI at that time. > But the only mass-market end-user-facing graphical multimedia-capable > QNX devices I know of were the Blackberry X smartphones. (And > cancelled tablet and netbook.) The BB10 i/f was designed by TAT (https://www.engadget.com/2010-12-02-rim-buys-tat-blackberry-ui-in-danger-of-becoming-awesome.html). > I owned a Blackberry Passport. A lovely device with a lovely OS... but > too late and it flopped. Quite so. N. From athornton at gmail.com Mon Dec 19 14:26:52 2022 From: athornton at gmail.com (Adam Thornton) Date: Sun, 18 Dec 2022 21:26:52 -0700 Subject: [TUHS] origin of null-terminated strings In-Reply-To: References: Message-ID: > On Dec 17, 2022, at 11:15 AM, Tom Lyon wrote: > > Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of CMS. > From Melinda Varian's amazing history of VM, I gleaned these factoids: > CP-67 - 8 sites by May '68 > Feb of 68 - IBM decommits from TSS > Apr 69 - IBM rescinds decommit of TSS > CP-67 - 44 sites by 1970, ~10 internal to IBM > May 71 - TSS finally decommitted > > So TSS was a rocky road, while CP&VM were simple and just worked. > Ask the Varians! Lee was a TSS heavy-hitter, and Melinda was...well, Melinda; "What Mother Never Told You" is still the best document about system maintenance ever written. At least as of last year they were both still alive and well. Adam From lproven at gmail.com Mon Dec 19 21:47:44 2022 From: lproven at gmail.com (Liam Proven) Date: Mon, 19 Dec 2022 12:47:44 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Message-ID: On Sun, 18 Dec 2022 at 16:08, Stuff Received wrote: > > The BB10 i/f was designed by TAT > (https://www.engadget.com/2010-12-02-rim-buys-tat-blackberry-ui-in-danger-of-becoming-awesome.html). Oh, fascinating. I did not know that -- thank you! > > I owned a Blackberry Passport. A lovely device with a lovely OS... but > > too late and it flopped. > > Quite so. One of the slightly stranger things in the smartphone OS space recently, for me, has been watching Huawei's response to the licensing fight with Google. Huawei now promotes its devices as running "Harmony OS" with a lot of hot air about microkernels, convergence, cross-platform, blah blah. It's nothing of the kind. It's AOSP, the open-source core of Android, with their own skin on top. I don't think Huawei has the tech skills to build a new OS as it's claimed it has... But it could make some of those claims come true if it licensed BB10 and spent a bit on updating it. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From phil at ultimate.com Tue Dec 20 03:38:21 2022 From: phil at ultimate.com (Phil Budne) Date: Mon, 19 Dec 2022 12:38:21 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 Message-ID: <202212191738.2BJHcLBF024793@ultimate.com> The October 1984 BSTJ article by Felton, Miller and Milner https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf Describes an AT&T port of UNIX to System/370 using TSS/370 underpinnings as the "Resident System Supervisor" and used as the 5ESS switching system development environment. I also found mention at http://www.columbia.edu/~rh120/ch106.x09 chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: Ian Johnstone, who had been the tutor at University of New South Wales working with Professor John Lions, was one of the researchers invited to Bell Labs. He managed the completion at AT&T Bell Labs of the port of Unix to the IBM 370 computer. See "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX Review, October, 1984, p. 26. Johnstone also led the group that did the port to the AT&T 2B20A multiprocessor system. I found https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers rationale. Also: "IBM's own involvement in Unix can be dated to 1979, when it assisted Bell Labs in doing its own Unix port to the 370 (to be used as a build host for the 5ESS switch's software). In the process, IBM made modifications to the TSS/370 hypervisor to better support Unix.[12]" at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 Is there any other surviving documentation about the system? Any recall of what branch of AT&T UNIX it was based on? Thanks! Phil From tuhs at tuhs.org Tue Dec 20 04:53:48 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 19 Dec 2022 18:53:48 +0000 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212191738.2BJHcLBF024793@ultimate.com> References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: All I can comment is there are a number of #ifdef u370 sections added to System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is my understanding of Bell-adjacent platform work: PDP-7 - Research, 1969 PDP-11 - Research, 1970 Interdata 8/32 - Research, 1977 VAX - Research, 1979 (or did USG do 32V, it's sitting in my USG folder...) 3B20 - UNIX/TS 4.x, 1981 System/370 - UNIX/TS?, 198x 3B5 - Release 5.0, 1982 M68000 - System V, 1983 Z8000 - System V, 1983 And sources are obvious for PDP-7, PDP-11, Interdata, and VAX. 3B20 I based on the 4.1 manual, unsure if it was integrated any earlier. M68000 and Z8000 are based on entries in the AT&T documentation catalogue from 1984, among other things, they mention System V documentation for M680000 and Z8000. The machid man page in System V lists pdp11, u3b, u3b5, and vax. The 370 references I'm aware of are all in code. I can try and pinpoint that if anyone wants me to look, a grep for u370 should suffice though. In any case, machid in my 5.0 manual does not list M68000, Z8000, nor System/370. Also ran upstairs and checked some of my other manuals, I find no reference of machid in the SVR2 era manual I have, but it isn't a formal release-version manual, it's "The UNIX System User's Manual" with the red AT&T cover that was the motif at the time. It seems to be a much more general manual, meant to encompass multiple versions and just the basics. It's actually pretty interesting in typography and layout, I'll see if that thing has been scanned yet, and if not, will add it to my list. Checking the actual System V branded manual, it removes the 3b5 reference, perhaps 3b5 was still pretty internal at the time. The 3b5 reference *is* in the Bell Labs Release 5.0 manual variant, so appears to have just been scrubbed from commercial release material. Fast forwarding to SVR4, that adds u3b2, u3b15, and u370, so System/370 UNIX was formalized and promoted somewhere between SVR1 and SVR4, pointing more strongly to it being the work of USG and the UNIX/TS line. That's my initial analysis, I feel like I saw mention of 370 in some sort of papers from around this timeframe, so will respond if I find anything else. Unfortunately I have a gaping SVR2/SVR3 hole in my library that I don't intend to fill until I work my scan backlog down. - Matt G. ------- Original Message ------- On Monday, December 19th, 2022 at 9:38 AM, Phil Budne wrote: > The October 1984 BSTJ article by Felton, Miller and Milner > https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf > > Describes an AT&T port of UNIX to System/370 using TSS/370 > underpinnings as the "Resident System Supervisor" and used as the 5ESS > switching system development environment. > > I also found mention at http://www.columbia.edu/~rh120/ch106.x09 > chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: > > Ian Johnstone, who had been the tutor at University of New > South Wales working with Professor John Lions, was one of the > researchers invited to Bell Labs. He managed the completion at > AT&T Bell Labs of the port of Unix to the IBM 370 computer. See > "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX > Review, October, 1984, p. 26. Johnstone also led the group that did > the port to the AT&T 2B20A multiprocessor system. > > I found > https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf > "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers rationale. > > Also: > > "IBM's own involvement in Unix can be dated to 1979, when it > assisted Bell Labs in doing its own Unix port to the 370 (to > be used as a build host for the 5ESS switch's software). In > the process, IBM made modifications to the TSS/370 hypervisor > to better support Unix.[12]" > at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 > > Is there any other surviving documentation about the system? > Any recall of what branch of AT&T UNIX it was based on? > > Thanks! > Phil From clemc at ccc.com Tue Dec 20 07:01:54 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 19 Dec 2022 16:01:54 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS wrote: > All I can comment is there are a number of #ifdef u370 sections added to > System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is > my understanding of Bell-adjacent platform work: > > PDP-7 - Research, 1969 > PDP-11 - Research, 1970 > Interdata 8/32 - Research, 1977 > VAX - Research, 1979 (or did USG do 32V, it's sitting in my USG > folder...) > 3B20 - UNIX/TS 4.x, 1981 > System/370 - UNIX/TS?, 198x > 3B5 - Release 5.0, 1982 > M68000 - System V, 1983 > Z8000 - System V, 1983 > > Sadly, do I wish it was this linear as you present ;-) Simply - it was not. Just like the folks outside of the Bell System, inside, there were several forks, many of which have been discussed here. Research was its own bloodline. Ken/Dennis et al.. This, of course, was what seeded much of the external work at the Universities with the BSD bloodline as a direct result. There was a good bit of porting work done there, such as the work on the Interdata, IBM S/360, and Honeywell, but most of that work tended to leave the labs in an indirect form. PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al... as a fork of Research Sixth Edition. After many twists and turns, that bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve Johnson - a.k.a. yaccman - was a manager in Summit and has offered some enlightenment on this list over the years). As we have often discussed here, the TS line is hugely impure. There is a great question of what was TS and what was not. What was the name and what was actual technology? It's clear it started based on AT&T politics of the mid-late 70s, but as things changed at AT&T and their own internal Unix wars - names and technologies shave been blurred and some of the details were lost to time. We know that the PWB thread (and >>name<< ) would >>eventually<< become the many flavors of Sys V and it was the 'official' line that AT&T started to market -- at first to the Operating Companies and later more widespread commercially. What was PWB and what was TS is not completely clear? (I think Werner may have done so of the best sleuthing here and has reported his learnings in the past). Part of the issues we have as historians was because threads and those twists and turns started before the breakup and were controlled by rules of the 1956 consent decree (TS and PWB itself are examples) and other things happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at being in the computer business. Pre breakup, the AT&T >>commercial<< work was targeted for the Operating Companys. Each group often did different things to deal with specific projects that were being targeted to solve problems that the OCs had. As was pointed out before, the switching folks in Indian Hill not only needed to build things like SW for the ESS#5 (the 370/TSS-based stuff mentioned yesterday helped to support that project) but they were also working on a very slick single system image Unix system [Tom Bishop at friends] that ran on the 3B duplex and some other HW - the /400 IIRC] (FWIW: Tom used to be findable - I've tried to get him on this list a few times). But you will see some #ifdefs in various codes that ended back up in Summit that really are from that work. That said, if I understand things that have been suggested here, officially the Duplex system used an OS that Indian Hill created but was >>seeded<< from Summit, but not the Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc might have]. Holmdel ( Reisner et al.) had several projects. The best we3 can tell, is that bloodline seems to have died off due to some internal AT&T politics and reorgs, although a number of things from it seem to have shown up in other bloodlines and different people brought some of the ideas. For instance, while it's not directly there, SVR3's memory system >>seems<< to have had some Reisner's influence. Again we don't have direct evidence other than different people's recollections and some comments people here and elsewhere have found in different sources. Columbus ( Dale's team ) did a great deal of work in several areas. Some of it has been recovered, but not all. Mary Ann, is a one-time member of that team and often comments and fills in some of the history here. FWIW: The PWB 3.0, a.k.a. System III release, got a bunch of the technology from CBUNIX (again discussed at length here over the years) - shared mem, semaphore, ipc, etc. These are just a few and I apologize to anyone that was not mentioned. I offered some highlights to make my point. If you are newer to the list, I respectfully suggest that instead of restarting some of this discussion, please go back into the old Mail archives and you will see a great deal of detail. The most important point I will leave you with is that the different UNIX flavors influenced each other - inside and outside the Bell System. As Larry points out, politics often had a more substantial influence on what 'won' than the 'goodness' of the technology itself in many cases. But the path from the root to any of the leaves includes a great deal of cross-fertilization. It seems to me to be a bit disingenuous to offer a linear statement from one of the bloodlines and infer that was how it all worked, just because some #ifdefs have been found in a few places in some of the different pieces of code, be kernel portions or user space. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Dec 20 07:19:50 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 20 Dec 2022 08:19:50 +1100 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.) Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down. Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there. I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true. Columbus's major contribution, as we saw it from Research, was the world's second most complex init. All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic. Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics. Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast. And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice. -rob On Tue, Dec 20, 2022 at 8:03 AM Clem Cole wrote: > > > On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS wrote: > >> All I can comment is there are a number of #ifdef u370 sections added to >> System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is >> my understanding of Bell-adjacent platform work: >> >> PDP-7 - Research, 1969 >> PDP-11 - Research, 1970 >> Interdata 8/32 - Research, 1977 >> VAX - Research, 1979 (or did USG do 32V, it's sitting in my >> USG folder...) >> 3B20 - UNIX/TS 4.x, 1981 >> System/370 - UNIX/TS?, 198x >> 3B5 - Release 5.0, 1982 >> M68000 - System V, 1983 >> Z8000 - System V, 1983 >> >> > Sadly, do I wish it was this linear as you present ;-) Simply - it was > not. > > Just like the folks outside of the Bell System, inside, there were several > forks, many of which have been discussed here. > > Research was its own bloodline. Ken/Dennis et al.. This, of course, was > what seeded much of the external work at the Universities with the BSD > bloodline as a direct result. There was a good bit of porting work done > there, such as the work on the Interdata, IBM S/360, and Honeywell, but > most of that work tended to leave the labs in an indirect form. > > PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al... as a > fork of Research Sixth Edition. After many twists and turns, that > bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve > Johnson - a.k.a. yaccman - was a manager in Summit and has offered some > enlightenment on this list over the years). As we have often discussed > here, the TS line is hugely impure. There is a great question of what was > TS and what was not. What was the name and what was actual technology? > It's clear it started based on AT&T politics of the mid-late 70s, but as > things changed at AT&T and their own internal Unix wars - names and > technologies shave been blurred and some of the details were lost to time. > We know that the PWB thread (and >>name<< ) would >>eventually<< become > the many flavors of Sys V and it was the 'official' line that AT&T started > to market -- at first to the Operating Companies and later more widespread > commercially. What was PWB and what was TS is not completely clear? (I > think Werner may have done so of the best sleuthing here and has reported > his learnings in the past). > > Part of the issues we have as historians was because threads and those > twists and turns started before the breakup and were controlled by rules of > the 1956 consent decree (TS and PWB itself are examples) and other things > happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at > being in the computer business. Pre breakup, the AT&T >>commercial<< work > was targeted for the Operating Companys. Each group often did different > things to deal with specific projects that were being targeted to solve > problems that the OCs had. > > As was pointed out before, the switching folks in Indian Hill not only > needed to build things like SW for the ESS#5 (the 370/TSS-based stuff > mentioned yesterday helped to support that project) but they were also > working on a very slick single system image Unix system [Tom Bishop at > friends] that ran on the 3B duplex and some other HW - the /400 IIRC] > (FWIW: Tom used to be findable - I've tried to get him on this list a few > times). But you will see some #ifdefs in various codes that ended back up > in Summit that really are from that work. That said, if I understand > things that have been suggested here, officially the Duplex system used an > OS that Indian Hill created but was >>seeded<< from Summit, but not the > Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc > might have]. > > Holmdel ( Reisner et al.) had several projects. The best we3 can tell, > is that bloodline seems to have died off due to some internal AT&T politics > and reorgs, although a number of things from it seem to have shown up in > other bloodlines and different people brought some of the ideas. For > instance, while it's not directly there, SVR3's memory system >>seems<< to > have had some Reisner's influence. Again we don't have direct evidence > other than different people's recollections and some comments people here > and elsewhere have found in different sources. > > Columbus ( Dale's team ) did a great deal of work in several areas. Some > of it has been recovered, but not all. Mary Ann, is a one-time member of > that team and often comments and fills in some of the history here. FWIW: > The PWB 3.0, a.k.a. System III release, got a bunch of the technology from > CBUNIX (again discussed at length here over the years) - shared mem, > semaphore, ipc, etc. > > These are just a few and I apologize to anyone that was not mentioned. I > offered some highlights to make my point. > > If you are newer to the list, I respectfully suggest that instead of > restarting some of this discussion, please go back into the old Mail > archives and you will see a great deal of detail. > > The most important point I will leave you with is that the different UNIX > flavors influenced each other - inside and outside the Bell System. As > Larry points out, politics often had a more substantial influence on what > 'won' than the 'goodness' of the technology itself in many cases. But the > path from the root to any of the leaves includes a great deal of > cross-fertilization. It seems to me to be a bit disingenuous to offer a > linear statement from one of the bloodlines and infer that was how it all > worked, just because some #ifdefs have been found in a few places in some > of the different pieces of code, be kernel portions or user space. > ᐧ > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Tue Dec 20 07:36:13 2022 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 19 Dec 2022 16:36:13 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212191738.2BJHcLBF024793@ultimate.com> References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: There was a track of USENIX 1986 called "UNIX on Big Iron." Peter Capek of IBM was the chair and Gene Miya and Jim Lipkis rounded out the program committee. The proceedings are available. Program included: - User Requirements for Future-nix - Gene Miya - Experience with Large Applications on UNIX - Bob Bilyeu - UNIX Scheduling for Large Systems - Jeffrey Straathof, Ashok Thareja, Ashok Agrawal - A Straightforward Implementation of a 4.2BSD on a High Performance Multiprocessor - Dave Probert - Porting UNIX to the System/370 Extended Architecture - Joseph R Eykholt - Full Duplex Support for Mainframes - Don Sterk - Concentrix -- A UNIX for the Alliant Multiprocessor - Jack Test - A User-Tunable Multiprocessor Schedule - Herb Jacobs - Considerations for Massively Parallel UNIX Systems on the NYU Ultracomputer and the IBM RP3 - Jan Edler, Alan Jottlieb, Jim Lipkis - UNIX of CTSS for the Cray-1, Cray X-MP, and Cray-2 Supercomputers - Karl Auerbach, Robin O'Neill - Experience Porting System V to the Cray 2 - Tim Hoel ===== nygeek.net mindthegapdialogs.com/home On Mon, Dec 19, 2022 at 12:38 PM Phil Budne wrote: > The October 1984 BSTJ article by Felton, Miller and Milner > https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf > > Describes an AT&T port of UNIX to System/370 using TSS/370 > underpinnings as the "Resident System Supervisor" and used as the 5ESS > switching system development environment. > > I also found mention at http://www.columbia.edu/~rh120/ch106.x09 > chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: > > Ian Johnstone, who had been the tutor at University of New > South Wales working with Professor John Lions, was one of the > researchers invited to Bell Labs. He managed the completion at > AT&T Bell Labs of the port of Unix to the IBM 370 computer. See > "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX > Review, October, 1984, p. 26. Johnstone also led the group that did > the port to the AT&T 2B20A multiprocessor system. > > I found > > https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf > "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers > rationale. > > Also: > > "IBM's own involvement in Unix can be dated to 1979, when it > assisted Bell Labs in doing its own Unix port to the 370 (to > be used as a build host for the 5ESS switch's software). In > the process, IBM made modifications to the TSS/370 hypervisor > to better support Unix.[12]" > at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 > > Is there any other surviving documentation about the system? > Any recall of what branch of AT&T UNIX it was based on? > > Thanks! > Phil > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Dec 20 08:15:29 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 19 Dec 2022 22:15:29 +0000 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: If it helps any, the init discrepancies are one of the hints at part of the System III/3.0 lineage. System III has an init much closer in flavor to CB init than the research init (inittab, runlevels). There are notable differences too, the inittab is in a slightly different format and the runlevels are simply 1-9, no s/S alias for single user mode afaik. 4.1 appears to be the first release to have split a_man and u_man, and I only managed to track down a user manual, so can't compare the init and getty pages, but the inittab entry matches System III, meaning that CB init as we know it didn't make it in until 5.0. In any case, a diff on the III and V versions is pretty stark, leading me to believe if CB init was inspired by this, it was in design only, but possibly a fresh codebase? So hard to tell. Where this leaves a quandary is where did this init in System III come from? Not a System/370 matter but if anyone knows I'd love to hear you out. Another matter I've been keeping tabs on in my recent study is the presence of SCCS tags on things. Most System V code has SCCS tags, but only select bits of System III seem to have them. Where they do exist, often times they're either carried through to the System V file verbatim or​ there's some monkeying with the numbers I can't quite explain but I have some hunches. In any case, many of the files unmodified between III and V are listed as SCCS version 1.1 in V. I'm not sure there what the significance of the version numbers was, and in analyzing several versions, i haven't been able to identify a singular pattern. One pattern I did notice sporadically was when comparing SVR1 Release 1 (PDP-11) and SVR1 Release 2 (M68K), all of these SCCS identifiers I checked roll from whatever 1.x they were in the former to 2.1 in the latter, presumably the major number being the System V release and minor being revisions since that was tagged? All speculation though. In any case, Clem is totally right that nothing is that linear, I was just pulling some references from some documents I have on hand to fill in some of the available context. At the root of it all though there is u370 in the PDP-11 codebase for SVR0/1 (never know which to apply...). So at least by 1982 there was definitely System/370 stuff floating around far enough up the chain to be integrated. Where those actual lines of code came from, can't entirely say, although I have a document I'm scanning tonight that miiiight shed some more light. Appendix I of the System Release Description document for System V is a 62 page list of all the modification requests presumably between 3.0 and 5.0. It's a table with header "NR AREA SUMMARY MR" where NR is just an increasing number, AREA is a rough idea of where it's at (some have program names, some have text like "3.0 manual", SUMMARY is basically a commit message, and then MR is two letters (location/team?), two numbers (year?), a dash, then 5 numbers (issue number?). There are plenty of u370 references throughout, for instance 775 graphics union adrbits in file xytekl.c must be inverted for unix 370 bl81-21610 786 grep an #ifdef should be around u370 code bl81-28302 There are others, just did a quick visual scan for some examples. I've got the entire rest of the document scanned already, just need to get Appendix I and upload it. I think this'll be very informative of what was going on in that timeframe. Unfortunately the order is not chronological as far as I can tell, so it'll take OCR'ing this and then sorting on the MR column to get something like that out of it. I also don't know if the MR number is representative of when something was fixed or reported. Given MR is Modification Request, my assumption is any chronological data is predicated on the report date, not fix date. Anywho I'll hopefully have that and the other PDFs from that volume somewhere folks can get to them by this evening. Decided to ramp up getting this thing scanned since it'll also contribute to what is pretty much turning into a UNIX 4.x restoration for me. Anywho, hopefully this thing turns up some timelines. More to come! - Matt G. ------- Original Message ------- On Monday, December 19th, 2022 at 1:19 PM, Rob Pike wrote: > Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.) Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down. > > Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there. I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true. Columbus's major contribution, as we saw it from Research, was the world's second most complex init. All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic. > > Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics. Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast. And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice. > > -rob > > On Tue, Dec 20, 2022 at 8:03 AM Clem Cole wrote: > >> On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS wrote: >> >>> All I can comment is there are a number of #ifdef u370 sections added to System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is my understanding of Bell-adjacent platform work: >>> >>> PDP-7 - Research, 1969 >>> PDP-11 - Research, 1970 >>> Interdata 8/32 - Research, 1977 >>> VAX - Research, 1979 (or did USG do 32V, it's sitting in my USG folder...) >>> 3B20 - UNIX/TS 4.x, 1981 >>> System/370 - UNIX/TS?, 198x >>> 3B5 - Release 5.0, 1982 >>> M68000 - System V, 1983 >>> Z8000 - System V, 1983 >> >> Sadly, do I wish it was this linear as you present ;-) Simply - it was not. >> >> Just like the folks outside of the Bell System, inside, there were several forks, many of which have been discussed here. >> >> Research was its own bloodline. Ken/Dennis et al.. This, of course, was what seeded much of the external work at the Universities with the BSD bloodline as a direct result. There was a good bit of porting work done there, such as the work on the Interdata, IBM S/360, and Honeywell, but most of that work tended to leave the labs in an indirect form. >> >> PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al... as a fork of Research Sixth Edition. After many twists and turns, that bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve Johnson - a.k.a. yaccman - was a manager in Summit and has offered some enlightenment on this list over the years). As we have often discussed here, the TS line is hugely impure. There is a great question of what was TS and what was not. What was the name and what was actual technology? It's clear it started based on AT&T politics of the mid-late 70s, but as things changed at AT&T and their own internal Unix wars - names and technologies shave been blurred and some of the details were lost to time. We know that the PWB thread (and >>name<< ) would >>eventually<< become the many flavors of Sys V and it was the 'official' line that AT&T started to market -- at first to the Operating Companies and later more widespread commercially. What was PWB and what was TS is not completely clear? (I think Werner may have done so of the best sleuthing here and has reported his learnings in the past). >> >> Part of the issues we have as historians was because threads and those twists and turns started before the breakup and were controlled by rules of the 1956 consent decree (TS and PWB itself are examples) and other things happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at being in the computer business. Pre breakup, the AT&T >>commercial<< work was targeted for the Operating Companys. Each group often did different things to deal with specific projects that were being targeted to solve problems that the OCs had. >> >> As was pointed out before, the switching folks in Indian Hill not only needed to build things like SW for the ESS#5 (the 370/TSS-based stuff mentioned yesterday helped to support that project) but they were also working on a very slick single system image Unix system [Tom Bishop at friends] that ran on the 3B duplex and some other HW - the /400 IIRC] (FWIW: Tom used to be findable - I've tried to get him on this list a few times). But you will see some #ifdefs in various codes that ended back up in Summit that really are from that work. That said, if I understand things that have been suggested here, officially the Duplex system used an OS that Indian Hill created but was >>seeded<< from Summit, but not the Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc might have]. >> >> Holmdel ( Reisner et al.) had several projects. The best we3 can tell, is that bloodline seems to have died off due to some internal AT&T politics and reorgs, although a number of things from it seem to have shown up in other bloodlines and different people brought some of the ideas. For instance, while it's not directly there, SVR3's memory system >>seems<< to have had some Reisner's influence. Again we don't have direct evidence other than different people's recollections and some comments people here and elsewhere have found in different sources. >> >> Columbus ( Dale's team ) did a great deal of work in several areas. Some of it has been recovered, but not all. Mary Ann, is a one-time member of that team and often comments and fills in some of the history here. FWIW: The PWB 3.0, a.k.a. System III release, got a bunch of the technology from CBUNIX (again discussed at length here over the years) - shared mem, semaphore, ipc, etc. >> >> These are just a few and I apologize to anyone that was not mentioned. I offered some highlights to make my point. >> >> If you are newer to the list, I respectfully suggest that instead of restarting some of this discussion, please go back into the old Mail archives and you will see a great deal of detail. >> >> The most important point I will leave you with is that the different UNIX flavors influenced each other - inside and outside the Bell System. As Larry points out, politics often had a more substantial influence on what 'won' than the 'goodness' of the technology itself in many cases. But the path from the root to any of the leaves includes a great deal of cross-fertilization. It seems to me to be a bit disingenuous to offer a linear statement from one of the bloodlines and infer that was how it all worked, just because some #ifdefs have been found in a few places in some of the different pieces of code, be kernel portions or user space. >> ᐧ >> ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Tue Dec 20 08:52:12 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Mon, 19 Dec 2022 16:52:12 -0600 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: <68215a42-e823-1f1b-6af3-e203381fc75b@technologists.com> Locus Computing Corporation had a substantial Unix on 370 effort in the 1980s. My impression/understanding was that the LCC kernel was derived from 4.1BSD and close to the metal when running on the 370. The LCC work became AIX/370 & AIX PS/2 with the Locus distributed system technology named TCF (transparent computing facility). As far as I know, the LCC work that became AIX/370 was the only version of Unix for the 370 officially supported by IBM. On 12/19/2022 3:36 PM, Marc Donner wrote: > There was a track of USENIX 1986 called "UNIX on Big Iron."  Peter Capek > of IBM was the chair and Gene Miya and Jim Lipkis rounded out the > program committee.  The proceedings are available. > > Program included: > > * User Requirements for Future-nix - Gene Miya > * Experience with Large Applications on UNIX - Bob Bilyeu > * UNIX Scheduling for Large Systems - Jeffrey Straathof, Ashok > Thareja, Ashok Agrawal > * A Straightforward Implementation of a 4.2BSD on a High Performance > Multiprocessor - Dave Probert > * Porting UNIX to the System/370 Extended Architecture - Joseph R Eykholt > * Full Duplex Support for Mainframes - Don Sterk > * Concentrix -- A UNIX for the Alliant Multiprocessor - Jack Test > * A User-Tunable Multiprocessor Schedule - Herb Jacobs > * Considerations for Massively Parallel UNIX Systems on the NYU > Ultracomputer and the IBM RP3 - Jan Edler, Alan Jottlieb, Jim Lipkis > * UNIX of CTSS for the Cray-1, Cray X-MP, and Cray-2 Supercomputers - > Karl Auerbach, Robin O'Neill > * Experience Porting System V to the Cray 2 - Tim Hoel > > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Mon, Dec 19, 2022 at 12:38 PM Phil Budne > wrote: > > The October 1984 BSTJ article by Felton, Miller and Milner > https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf > > > Describes an AT&T port of UNIX to System/370 using TSS/370 > underpinnings as the "Resident System Supervisor" and used as the 5ESS > switching system development environment. > > I also found mention at http://www.columbia.edu/~rh120/ch106.x09 > > chapter 9 of http://www.columbia.edu/~rh120/ > with footnote 96: > >       Ian Johnstone, who had been the tutor at University of New >       South Wales working with Professor John Lions, was one of the >       researchers invited to Bell Labs. He managed the completion at >       AT&T Bell Labs of the port of Unix to the IBM 370 computer. See >       "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX >       Review, October, 1984, p. 26. Johnstone also led the group > that did >       the port to the AT&T 2B20A multiprocessor system. > > I found > https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf > "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers > rationale. > > Also: > >         "IBM's own involvement in Unix can be dated to 1979, when it >         assisted Bell Labs in doing its own Unix port to the 370 (to >         be used as a build host for the 5ESS switch's software). In >         the process, IBM made modifications to the TSS/370 hypervisor >         to better support Unix.[12]" > at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 > > > Is there any other surviving documentation about the system? > Any recall of what branch of AT&T UNIX it was based on? > > Thanks! > Phil > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From clemc at ccc.com Tue Dec 20 09:02:20 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 19 Dec 2022 18:02:20 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: On Mon, Dec 19, 2022 at 4:20 PM Rob Pike wrote: > Quite a bit of this feels not exactly wrong, but not quite right. (And his > name is John Reiser, not Reisner.) > Thank you. Never assume I will get spelling right ;-) > Steve Johnson didn't go to work in development until the mid 1980s, for > example, long after these bloodlines as you call them were laid down. > Yes, I know. I did not mean to imply this -- only that we have discussed much of this and Steve has offered comments as a manager. > > Do we know that PWB became USG? That doesn't feel right to me, although it > might well be true, I wasn't there. > I was not either, although very close friends with a few that were. My old lab partner in hacking, the late Ted Kowalski and Armando Stettner were officemates in Summit in USG in the late 1970s - who are the primary sources of data I have from that time. Mashey is the other (and I think we have an old email from John in the archives). The problem you are getting too is exactly what I was referring BTW. It was not a straight line. Some facts ... PWB 1.0 was created and release before USG would be created. Again look at the old messages here. What I don't know is who packaged PWB 2.0 -- I was under the impression that was still Mashey et al (as you said Whippany a few other NJ labs - although the USG folks must have just been created). IIRC the kernel in PWB 2.0 and V7 are close, but not the same and definitely the userspaces are different. TS starts to could thing, and the best I personally can tell (again from old message from Ted Armando et al), at some point TS was being created - maybe around 1978ish. How much of V7 went into TS and vice versa - is not clear. So far, I do not believe we have found a definitive TS 'distribution' - but a number of things seem to be a part. Werner I think can add the most color here, as he researched it., a bit more than I did. Again, the best, I can tell is that something approximating TS 1.0 was created (in Summit >>I believe<<) and it had a common kernel with V7. Who got it and how it was distributed it not completely understood -- again AT&T politics, the consent decree et al, all mix this up. Tick, tick, tick ... Judge Green does his thing ... PWB 3.0 was released to the OCs at some point. During a discussions AT&T NC (Al Arms et al) had with customers (like me), we had memos created by USG that are marked PWB 3.0 that discussed what was going to be in the release. AT&T North Carolina (the lawyers and marketing folks) gave them to us. I personally was part of the negotiation associated with that license had a few of those memos at one point. They were clearly marked PWB 3.0 and were originally created the OCs distribution. AT&T was now in the computer market and the marketing/sales types and did not like the name Programmmer Workbench - when going against IBM [who was clearly the target]. It was also made clear to us (commercial UNIX licensees) that whatever was produced, would not be the named PWBct when the AT&T Marketing folks released it publically -- it seems to me that they were working trademarking in parallel with the pricing/licensing negotiation that I was a part. I >>believe<< that is why the manuals were printed saying 3.0 - but Summit did not yet know what the name would be - although they did release PWB 3.0 inside of the Bell System. Eventually, the name 'System III' was picked by AT&T NC and the marketing blitz started -- "Consider it standard," etc.. FWIW: John Mashey is the source of the comment about PWB bloodline begets Summits work. > I think of it as mostly staying in Whippany, not going to Summit. Also > your prose would imply USG never got to V7 level, which is certainly not > true. > Not at all. I was not trying to imply that in any way. > Columbus's major contribution, as we saw it from Research, was the world's > second most complex init. > systemd was yet to be created ;-) > All these variants lobbied to have Research adopt things, as such approval > was seen as a badge of honor. Honestly, though, it was all pretty toxic. > That is the impression I had. > > Reiser and London's Unix, which I greatly admired, died on the vine for a > variety of political reasons, as well as because it had slightly different > semantics in some important cases, and because of a broad antipathy to > virtual memory across the company due to various people having used VM on > inadequate hardware, and of course then there was Multics. > Again - that syncs with my comments and my memory of the time. > Sandy Fraser was very nervous about Research adopting the BSD kernel > because of his experience with Atlas. But let it be said: Reiser's VM > system was seriously impressive, cleanly integrated, structurally central, > and wonderfully fast. > I never ran it, but that does seem to be the report. Question for you Rob ... SVR3 was a rewrite the memory system from earlier things called 'System V'. Do you know if any of Reiser's stuff make it into that or was SVR3 a new stream altogether and who did it? Tom Bishop lead me to believe that some of Reiser's stuff was imported into the SSI system they did in IH. But again what went where and who did what has never been clearly understood. And that was my point -- there was never a linear progression. > And Sandy relented but the general warmth of 1127 towards Berkeley led to > Research adopting Berkeley Unix as its VAX VM platform, despite some, > including myself, feeling that was the inferior choice. > Indeed and not the first time we have heard that said here. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Tue Dec 20 10:02:24 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 19 Dec 2022 19:02:24 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: (message from segaloco via TUHS on Mon, 19 Dec 2022 22:15:29 +0000) Message-ID: segaloco via TUHS writes: [snip] > Another matter I've been keeping tabs on in my recent study is the presence of SCCS tags on things. Most System V code has SCCS tags, but only select bits of System III seem to have them. Where they do exist, often times they're either carried through to the System V file verbatim or​ there's some monkeying with the numbers I can't quite explain but I have some hunches. In any case, many of the files unmodified between III and V are listed as SCCS version 1.1 in V. I'm not sure there what the significance of the version numbers was, and in analyzing several versions, i haven't been able to identify a singular pattern. One pattern I did notice sporadically was when comparing SVR1 Release 1 (PDP-11) and SVR1 Release 2 (M68K), all of these SCCS identifiers I checked roll from whatever 1.x they were in the former to 2.1 in the latter, presumably the major number being the System V release and minor being revisions since that was tagged? All speculation though. [snip] Someone else will have to indicate if raw SCCS was used during the time frame for the code you are looking at or if there was some management system built on SCCS that was actually used. What I mean by this is that there was a source code control management system used at AT&T and later Lucent called Sublime (it was more or less mandated at CB at least for the software groups I know of and I am pretty sure I remember it in other locations too). Sublime was used in the '90s onward and likely quite a bit before that time. This system was a layer on top of SCCS, which wasn't allowed to be used directly for source code control. It was true that SCCS tags ended up in your code (usually), but you could not directly use the tag information in any meaningful manor. Sublime used the tag information in it own way that was opaque to the software developers. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From athornton at gmail.com Tue Dec 20 11:04:09 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 19 Dec 2022 18:04:09 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: Message-ID: If anyone wants to play with UTS--the version I'm running has sources that indicate it's pretty much a v7--you can connect to it at https://mvsevm.fsf.net, resize your window so the terminal is 80x25, pick option 11 (VM/370), hit enter, and then after the logo goes away type "DIAL UTS". The passwords are findable via a web search for something like "uts vm/370 password" in that I have not changed them from the defaults. If you manage to break out of UTS into VM, and from there into Hercules, and from that to the physical host, and then from there compromise my network, I'd like to know how you did it. If on the other hand you're going to mine bitcoin with my UTS VM guest, you can cost me literally dozens of cents a month in electricity, probably. I have not played with the 3270 libraries, but they exist. The two full-screen 3270 utilities I am aware of are ned and man. Ned's really rather a lovely little editor. Other than that it feels a lot like a stock v7, but of course the terminal is linemode. The command to log out is "logoff". Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Tue Dec 20 11:20:07 2022 From: stewart at serissa.com (Larry Stewart) Date: Mon, 19 Dec 2022 20:20:07 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: Message-ID: I forget if I've mentioned this here before, so apologies in advance. I never met Reiser, but I ran across his PhD thesis (for Knuth!). It was 35 pages (!) on random number generators. I implemented one for my own work. It was pretty clear he was one of those people who is smarter than the rest of us. -Larry > On Dec 19, 2022, at 6:03 PM, Clem Cole wrote: > >  > > >> On Mon, Dec 19, 2022 at 4:20 PM Rob Pike wrote: >> Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.) > Thank you. Never assume I will get spelling right ;-) > > >> Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down. > Yes, I know. I did not mean to imply this -- only that we have discussed much of this and Steve has offered comments as a manager. > > >> >> Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there. > I was not either, although very close friends with a few that were. My old lab partner in hacking, the late Ted Kowalski and Armando Stettner were officemates in Summit in USG in the late 1970s - who are the primary sources of data I have from that time. Mashey is the other (and I think we have an old email from John in the archives). > > The problem you are getting too is exactly what I was referring BTW. It was not a straight line. > > Some facts ... PWB 1.0 was created and release before USG would be created. Again look at the old messages here. What I don't know is who packaged PWB 2.0 -- I was under the impression that was still Mashey et al (as you said Whippany a few other NJ labs - although the USG folks must have just been created). > > IIRC the kernel in PWB 2.0 and V7 are close, but not the same and definitely the userspaces are different. > > TS starts to could thing, and the best I personally can tell (again from old message from Ted Armando et al), at some point TS was being created - maybe around 1978ish. How much of V7 went into TS and vice versa - is not clear. So far, I do not believe we have found a definitive TS 'distribution' - but a number of things seem to be a part. Werner I think can add the most color here, as he researched it., a bit more than I did. Again, the best, I can tell is that something approximating TS 1.0 was created (in Summit >>I believe<<) and it had a common kernel with V7. Who got it and how it was distributed it not completely understood -- again AT&T politics, the consent decree et al, all mix this up. > > Tick, tick, tick ... Judge Green does his thing ... > > PWB 3.0 was released to the OCs at some point. During a discussions AT&T NC (Al Arms et al) had with customers (like me), we had memos created by USG that are marked PWB 3.0 that discussed what was going to be in the release. AT&T North Carolina (the lawyers and marketing folks) gave them to us. I personally was part of the negotiation associated with that license had a few of those memos at one point. They were clearly marked PWB 3.0 and were originally created the OCs distribution. > > AT&T was now in the computer market and the marketing/sales types and did not like the name Programmmer Workbench - when going against IBM [who was clearly the target]. It was also made clear to us (commercial UNIX licensees) that whatever was produced, would not be the named PWBct when the AT&T Marketing folks released it publically -- it seems to me that they were working trademarking in parallel with the pricing/licensing negotiation that I was a part. > > I >>believe<< that is why the manuals were printed saying 3.0 - but Summit did not yet know what the name would be - although they did release PWB 3.0 inside of the Bell System. Eventually, the name 'System III' was picked by AT&T NC and the marketing blitz started -- "Consider it standard," etc.. > > FWIW: John Mashey is the source of the comment about PWB bloodline begets Summits work. > > > > >> I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true. > Not at all. I was not trying to imply that in any way. > > > >> Columbus's major contribution, as we saw it from Research, was the world's second most complex init. > systemd was yet to be created ;-) > > > >> All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic. > That is the impression I had. > > >> >> Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics. > Again - that syncs with my comments and my memory of the time. > > >> Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast. > I never ran it, but that does seem to be the report. > > Question for you Rob ... SVR3 was a rewrite the memory system from earlier things called 'System V'. Do you know if any of Reiser's stuff make it into that or was SVR3 a new stream altogether and who did it? Tom Bishop lead me to believe that some of Reiser's stuff was imported into the SSI system they did in IH. But again what went where and who did what has never been clearly understood. > > And that was my point -- there was never a linear progression. > > >> And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice. > Indeed and not the first time we have heard that said here. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Dec 20 11:33:23 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 19 Dec 2022 17:33:23 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: Message-ID: <20221220013323.GL4401@mcvoy.com> On Mon, Dec 19, 2022 at 08:20:07PM -0500, Larry Stewart wrote: > I forget if I've mentioned this here before, so apologies in advance. > > I never met Reiser, but I ran across his PhD thesis (for Knuth!). It was 35 pages (!) on random number generators. I implemented one for my own work. It was pretty clear he was one of those people who is smarter than the rest of us. Rob's (and maybe other's?) description of the VM system he did makes me really want to read that code. Rob talked about it the way I talk about the SunOS 4.x VM system, very clean and easy to understand. I'm still waiting to hear someone talk about an SMP VM system that way. That stuff gets complicated. From marc.donner at gmail.com Tue Dec 20 11:49:37 2022 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 19 Dec 2022 20:49:37 -0500 Subject: [TUHS] pre-1991 USENIX proceedings In-Reply-To: <01428a75-3507-7b8a-fd35-cef74c8c0bd2@ucsb.edu> References: <202212191738.2BJHcLBF024793@ultimate.com> <01428a75-3507-7b8a-fd35-cef74c8c0bd2@ucsb.edu> Message-ID: https://bitsavers.org/pdf/usenix/USENIX_1986_Winter_Technical_Conference_Proceedings_198601.pdf Here is the URL (All I did was search for ‘“Unix on big iron” usenix proceedings’) On Mon, Dec 19, 2022 at 4:59 PM James Frew wrote: > Hello Marc, > > Where did you find the 1986 USENIX proceedings? > > Reason I'm asking is, I have a pile of pre-1991 USENIX proceedings that I > haven't found online, and I'm planning to get them scanned. It would be > great if I didn't have to go the trouble :-) > > Thanks, > /James Frew > On 2022-12-19 13:36, Marc Donner wrote: > > > There was a track of USENIX 1986 called "UNIX on Big Iron." Peter Capek > of IBM was the chair and Gene Miya and Jim Lipkis rounded out the program > committee. The proceedings are available. > > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Tue Dec 20 11:57:49 2022 From: ggm at algebras.org (George Michaelson) Date: Tue, 20 Dec 2022 11:57:49 +1000 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221220013323.GL4401@mcvoy.com> References: <20221220013323.GL4401@mcvoy.com> Message-ID: Any comment now about taking ideas from Berkeley is informed by the twisted history which followed. At the time I can totally understand a preference for code from the tertiary education sector over IBM absent some explicit decision higher up about IPR: dealing with IBM must have been a very complicated story for Bell over time, and it wasn't that long since the whole CP/M MS-DOS thing had blown up with sillyness on both sides. It is entirely possible a decision with this much weight was made on a hunch/feel at some desk who had suffered at the hands of big blue lawyers at the time. Just because at a transatlantic distance I found the regents a nightmare to deal with (4.1 to 4.2 upgrade, re-licencing with bodies moving so signatures differing, then much later the same dance over some VLSI design s/w at UQ in Australia) doesn't mean Bell would have. To the contrary, they might have had the lowest bar legal and contractual barriers to work with. There was also the whole thing about DoD funding. Sockets are crap. I think they only became a de-facto standard because of familiarity. But again, put that back into historical context and have a platform coming out of the Californian state education system funded by the DoD with a network interface. DoD funding..yea lets hitch on that: maybe there will be some more of that sweet DARPA money flowing and if we're familiar with it, then we can get into the future contracts: Not that anyone cutting code thinks that way but desk jockeys would maybe? York Unix was how I met things on a Vax with VM. I remain a fan of how Charles Forsyth codes things. Small and elegant. I don't know that it fed back into anything. From crossd at gmail.com Tue Dec 20 12:06:04 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 19 Dec 2022 21:06:04 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221220013323.GL4401@mcvoy.com> Message-ID: On Mon, Dec 19, 2022, 8:59 PM George Michaelson wrote: > [snip] > > York Unix was how I met things on a Vax with VM. I remain a fan of how > Charles Forsyth codes things. Small and elegant. I don't know that it > fed back into anything. > Forsyth wrote a really nice paper on the follow-on work he did on Sun's; he implemented the EMAS paging algorithms, which was quite the coup. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Dec 20 12:12:06 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 19 Dec 2022 19:12:06 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221220013323.GL4401@mcvoy.com> Message-ID: <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. Having said that...maybe what I really want is 64-bit 4.3 BSD? I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. From tuhs at tuhs.org Tue Dec 20 12:35:02 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 20 Dec 2022 02:35:02 +0000 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: Message-ID: <-g8-VWi01ppo8Di6mjAYl_BPsMjFahCJ3KVFkQoWLC7X4PJUu607MQbO4IGVZA-sGoTJvEjY3j1lAzsaOxlxteSPmw5PZY-jSNcktkyk0SI=@protonmail.com> Oh wow, this is cool. So I hopped on and am looking around, after digging around for a while, it looks like that version of UNIX is this: https://en.wikipedia.org/wiki/Amdahl_UTS A very, very early version at that. Wikipedia says they stuck around and carried this through all the way to being an SVR4 derivative, but what we're seeing here, at least based on perusing around for 5-10 minutes, does indeed look very V7ish. The manual is interesting, looks like they tried to create their own manual ordering, there are man0-man3 folders but then vol1 vol2 and vol3 containing copies of many things, as well as several scripts and files with a lot of information on their process for adding new pages and documents. My reasoning on this not being past V7 is that there are no utsname or uname syscalls to speak of, nor pwbname. The history on that command/syscall is a little fuzzy, I know I've seen the name "utsname" somewhere but I can't recall where. The command is uname by the time of 3.0. This version does have a "sysname" command that suggests it does something similar, but I couldn't find a corresponding syscall, not that I looked very hard. - Matt G. ------- Original Message ------- On Monday, December 19th, 2022 at 5:04 PM, Adam Thornton wrote: > If anyone wants to play with UTS--the version I'm running has sources that indicate it's pretty much a v7--you can connect to it at https://mvsevm.fsf.net, resize your window so the terminal is 80x25, pick option 11 (VM/370), hit enter, and then after the logo goes away type "DIAL UTS". > > The passwords are findable via a web search for something like "uts vm/370 password" in that I have not changed them from the defaults. If you manage to break out of UTS into VM, and from there into Hercules, and from that to the physical host, and then from there compromise my network, I'd like to know how you did it. If on the other hand you're going to mine bitcoin with my UTS VM guest, you can cost me literally dozens of cents a month in electricity, probably. > > I have not played with the 3270 libraries, but they exist. The two full-screen 3270 utilities I am aware of are ned and man. Ned's really rather a lovely little editor. Other than that it feels a lot like a stock v7, but of course the terminal is linemode. The command to log out is "logoff". > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Dec 20 12:52:47 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 19 Dec 2022 18:52:47 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> On Dec 19, 2022, at 1:19 PM, Rob Pike wrote: > > Reiser and London's Unix, which I greatly admired, died on the vine > for a variety of political reasons, as well as because it had > slightly different semantics in some important cases, and because > of a broad antipathy to virtual memory across the company due to > various people having used VM on inadequate hardware, and of course > then there was Multics. Sandy Fraser was very nervous about > Research adopting the BSD kernel because of his experience with > Atlas. But let it be said: Reiser's VM system was seriously > impressive, cleanly integrated, structurally central, and > wonderfully fast. And Sandy relented but the general warmth of 1127 > towards Berkeley led to Research adopting Berkeley Unix as its VAX > VM platform, despite some, including myself, feeling that was > inferior choice. Is there a publicly available description of Reiser's VM system? I found "A Unix operating system for the DEC VAX 11/780 Computer" by London & Reiser which includes a long paragraph on VM (included below) but that is about it. And it would be interesting to hear why and what you found in Reiser's VM system that was better than Berkeley's VM system. Thanks! From the London&Reiser paper: The virtual address space of a process running on the VAX-11/780 consists of 2**32 8-bit bytes. The two high-order bits of a 32-bit address determine one of four segments. Two of these segments are system segments common to the address space of all processes. One of the system segments is reserved for future use. The other two segments are separately defined for each process and are automatically managed by the context switching instructions. One of the per-process segments is designed for a stack which grows towards lower-numbered memory addresses. Segments are divided into pages of 512 bytes. Memory mapping hardware translates virtual addresses into physical addresses using page tables. A page table contains one four-byte entry for each page mapped; the entry contains a valid bit, a four-bit field which encodes access privileges, a modify bit, and the physical page-frame number where the page is mapped. (There is no reference bit which is maintained by hardware!) A base register and a limit register describe the page table of each segment. The base register of a per-process segment contains a virtual address within the system segment; the base register for the system segment contains a physical memory address. The VAX11/780 central processor contains a virtual address translation buffer holding 128 virtual address-page frame number pairs which eliminates the need for extra memory references during address translation for (typically) 9896 of all memory references. The memory is implemented using MOS semiconductor RAMs with an error correcting code which corrects all single-bit errors and detects all double-bit errors and 70% of all greater-than-double bit errors. A memory controller can handle 8 memory boards; using 4K chips each board can hold 128K bytes. There can be two memory controllers, thus the maximum amount of physical memory is currently 2 megabytes. When 16K chips are used (forecasted for late 1978), each board will hold 512K, and physical memory can be 8 megabytes. There is a battery backup option for maintaining data in the event of a power failure. Each optional battery will maintain l megabyte for 10 minutes. From lm at mcvoy.com Tue Dec 20 13:09:43 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 19 Dec 2022 19:09:43 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> References: <202212191738.2BJHcLBF024793@ultimate.com> <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> Message-ID: <20221220030942.GR4401@mcvoy.com> On Mon, Dec 19, 2022 at 06:52:47PM -0800, Bakul Shah wrote: > On Dec 19, 2022, at 1:19 PM, Rob Pike wrote: > > > > Reiser and London's Unix, which I greatly admired, died on the vine > > for a variety of political reasons, as well as because it had > > slightly different semantics in some important cases, and because > > of a broad antipathy to virtual memory across the company due to > > various people having used VM on inadequate hardware, and of course > > then there was Multics. Sandy Fraser was very nervous about > > Research adopting the BSD kernel because of his experience with > > Atlas. But let it be said: Reiser's VM system was seriously > > impressive, cleanly integrated, structurally central, and > > wonderfully fast. And Sandy relented but the general warmth of 1127 > > towards Berkeley led to Research adopting Berkeley Unix as its VAX > > VM platform, despite some, including myself, feeling that was > > inferior choice. > > Is there a publicly available description of Reiser's VM system? > I found "A Unix operating system for the DEC VAX 11/780 Computer" > by London & Reiser which includes a long paragraph on VM (included > below) but that is about it. > > And it would be interesting to hear why and what you found in > Reiser's VM system that was better than Berkeley's VM system. Berkeley didn't really have a good VM system, other than Bill Joy imagining it and then went on to go to Sun and inspired Joe Moran to implement it. FreeBSD took Mach's VM system and while I have respect for what Mach was trying to do, holy moly, what a mess. I can't speak to Reiser's code because I haven't seen it, but I can speak to Joe Moran's code, it was just so clear to see what he was trying to do. And he did it. And you could understand it, I did as a year out of grad school. From imp at bsdimp.com Tue Dec 20 13:11:46 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 19 Dec 2022 20:11:46 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212191738.2BJHcLBF024793@ultimate.com> References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: On Mon, Dec 19, 2022, 10:39 AM Phil Budne wrote: > The October 1984 BSTJ article by Felton, Miller and Milner > https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf > > Describes an AT&T port of UNIX to System/370 using TSS/370 > underpinnings as the "Resident System Supervisor" and used as the 5ESS > switching system development environment. > > I also found mention at http://www.columbia.edu/~rh120/ch106.x09 > chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: > > Ian Johnstone, who had been the tutor at University of New > South Wales working with Professor John Lions, was one of the > researchers invited to Bell Labs. He managed the completion at > AT&T Bell Labs of the port of Unix to the IBM 370 computer. See > "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX > Review, October, 1984, p. 26. Johnstone also led the group that did > the port to the AT&T 2B20A multiprocessor system. > > I found > > https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf > "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers > rationale. > > Also: > > "IBM's own involvement in Unix can be dated to 1979, when it > assisted Bell Labs in doing its own Unix port to the 370 (to > be used as a build host for the 5ESS switch's software). In > the process, IBM made modifications to the TSS/370 hypervisor > to better support Unix.[12]" > at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 > > Is there any other surviving documentation about the system? > Any recall of what branch of AT&T UNIX it was based on? > [ since this original question hasn't been answered ] > V6. There were 3 v6 ports: two interdata ports (Wollongong and Labs) and one VM/370 port (at Harvard or Princeton). They are got to first boot the sane year, within a few months of each other Uts grew out of this early port. There's several blog posts about this and the TUHS archive has the initial port that was recovered from DECtapes recently. https://akapugs.blog/2018/05/12/370unixpart3/ is the last in the series. AT&T also did a V7 port, which I think is what is written up in the bell labs journal. I'm not sure I have a proper source for this other than comparing the two accounts. I don't know if research did this or another group. AT&T did the VAX port of V7 called V32, but v32 was little more than a swapping kernel that didn't do demand paging. This is where the Berkeley folks started to do paging with 3BSD. It is also where AT&T did their Vax port that other mailing list threads chronicled. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Dec 20 13:27:21 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 19 Dec 2022 19:27:21 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221220030942.GR4401@mcvoy.com> References: <202212191738.2BJHcLBF024793@ultimate.com> <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> <20221220030942.GR4401@mcvoy.com> Message-ID: On Dec 19, 2022, at 7:09 PM, Larry McVoy wrote: > > Berkeley didn't really have a good VM system, other than Bill Joy > imagining it and then went on to go to Sun and inspired Joe Moran > to implement it. The context I was interested in is the VAX and early 80s. The following paper by Özalp Baboğlu & Bill Joy describes the BSD design in some detail. http://roguelife.org/~fujita/COOKIES/HISTORY/3BSD/design.pdf > FreeBSD took Mach's VM system and while I have respect for what > Mach was trying to do, holy moly, what a mess. FreeBSD came much later. 1994 or so. From imp at bsdimp.com Tue Dec 20 13:48:14 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 19 Dec 2022 20:48:14 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221220030942.GR4401@mcvoy.com> References: <202212191738.2BJHcLBF024793@ultimate.com> <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> <20221220030942.GR4401@mcvoy.com> Message-ID: On Mon, Dec 19, 2022, 8:10 PM Larry McVoy wrote: > On Mon, Dec 19, 2022 at 06:52:47PM -0800, Bakul Shah wrote: > > On Dec 19, 2022, at 1:19 PM, Rob Pike wrote: > > > > > > Reiser and London's Unix, which I greatly admired, died on the vine > > > for a variety of political reasons, as well as because it had > > > slightly different semantics in some important cases, and because > > > of a broad antipathy to virtual memory across the company due to > > > various people having used VM on inadequate hardware, and of course > > > then there was Multics. Sandy Fraser was very nervous about > > > Research adopting the BSD kernel because of his experience with > > > Atlas. But let it be said: Reiser's VM system was seriously > > > impressive, cleanly integrated, structurally central, and > > > wonderfully fast. And Sandy relented but the general warmth of 1127 > > > towards Berkeley led to Research adopting Berkeley Unix as its VAX > > > VM platform, despite some, including myself, feeling that was > > > inferior choice. > > > > Is there a publicly available description of Reiser's VM system? > > I found "A Unix operating system for the DEC VAX 11/780 Computer" > > by London & Reiser which includes a long paragraph on VM (included > > below) but that is about it. > > > > And it would be interesting to hear why and what you found in > > Reiser's VM system that was better than Berkeley's VM system. > > Berkeley didn't really have a good VM system, other than Bill Joy > imagining it and then went on to go to Sun and inspired Joe Moran > to implement it. > The 4.2 and 4.3 VM were too vax specific. FreeBSD took Mach's VM system and while I have respect for what > Mach was trying to do, holy moly, what a mess. > To be fair, 4.4BSD had the mach vm because while Sun wanted to donate their VM, the lawyers killed the deal due to its value to the company... I'd sure rather have had the SunOS vm in 4.4BSD, but they went with what was available. The Mach VM works, but it's fit to the 4.4 kernel is imperfect. FreeBSD made it work via the early heroics of Dyson and Dillon, and the late SMP tuning of Juniper. It works, but has undergone at least 5 or 6 reorgs over the years. It also scales as all the bottlenecks have been fixed... but it could sure stand a rewrite (though that will have to wait for the next paradigm shift). NetBSD and OpenBSD adopted uvm instead maybe 5 or 10 years after 4.4 was released. This VM was initially more easily scaleable than Mach, but I'm not sure the vastly increased core counts of late work well with it. Warner I can't speak to Reiser's code because I haven't seen it, but I > can speak to Joe Moran's code, it was just so clear to see what > he was trying to do. And he did it. And you could understand it, > I did as a year out of grad school. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Tue Dec 20 14:21:32 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 20 Dec 2022 15:21:32 +1100 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221220030942.GR4401@mcvoy.com> References: <202212191738.2BJHcLBF024793@ultimate.com> <94155806-907F-40EE-AB00-F3B345509442@iitbombay.org> <20221220030942.GR4401@mcvoy.com> Message-ID: On Mon, Dec 19, 2022 at 07:09:43PM -0800, Larry McVoy wrote: > > Berkeley didn't really have a good VM system, other than Bill Joy > imagining it and then went on to go to Sun and inspired Joe Moran > to implement it. > > FreeBSD took Mach's VM system and while I have respect for what > Mach was trying to do, holy moly, what a mess. Mike Hibler did that for HPBSD and CSRG releases. https://www.flux.utah.edu/~mike/hpbsd/hpbsd.html "In April 1989, with encouragement from CSRG, I started the ``new VM project,'' integrating the Mach 2.0 VM system[1] into BSD. This was done in the context of our then current HPBSD. A reasonable prototype was done by November 1989 when I talked about it at the ``Berkeley workshop'' in Boulder[2]. Development on the new VM code in HPBSD continued off and on til May of 1990 when the VM code was merged into CSRG's source tree (what was to become net2 and later 4.4bsd)." From andreww591 at gmail.com Tue Dec 20 18:30:23 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Tue, 20 Dec 2022 01:30:23 -0700 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Message-ID: On 12/18/22, Liam Proven wrote: > > I don't have any citations for this, but it looked to me, watching in > the magazines at the time, that _before_ the Amiga deal, QNX did run > on PCs for testing purposes, but I am not totally sure if it had a GUI > at all, and little to no multimedia support. > > My impression is that QNX implemented that for Amiga Inc and then were > left with it when Amiga turned its gaze on Tao and Elate. > QNX Classic and 4.x only ran on x86 machines, most of which were either standard PCs or at least sort of PC-like (although AFAIK the ability to run without a BIOS was present very early on). It was quite common to run QNX on desktops as a development host for embedded systems AFAIK. GUIs for QNX predate the Amiga deal, and have existed since the late 80s. The original was QNX Windows, which was either a reimplementation or port (not quite sure which) of Open Look on a custom non-X11 window server, running on later versions of 2.x and all versions of 4.x. Later versions of 4.x added Photon 1, which looks like a cross between Motif and Windows 9x, again based on a custom window server (this time with a rather unconventional multi-process architecture). The 90s-era demo disk was based on 4.25 and Photon 1 (there was also a 2.x demo disk back in the 80s but this didn't have a GUI). 6.0 came with Photon 2, which is still Win9x-ish in terms of organization and is a fairly straightforward evolution of Photon 1, although the widgets look very vaguely Amiga-like in 6.0-6.2. 6.0 came out slightly after the Amiga deal, so that might be the reason for the Amiga-like theming. Neutrino was not the name of a GUI, but rather of the entire OS that succeeded QNX 4 (the first versions of Neutrino used Photon 1 but were incapable of self-hosting and were developed alongside 4.x; 6.0 was the first mainline QNX version to be Neutrino-based). > > But the only mass-market end-user-facing graphical multimedia-capable > QNX devices I know of were the Blackberry X smartphones. (And > cancelled tablet and netbook.) > There were also the i-Opener (running 4.25) and Audrey (running 6.0) internet appliances of the late 90s. From arnold at skeeve.com Tue Dec 20 18:56:10 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 20 Dec 2022 01:56:10 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212191738.2BJHcLBF024793@ultimate.com> References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: <202212200856.2BK8uA1d004518@freefriends.org> Phil Budne wrote: > Is there any other surviving documentation about the system? > Any recall of what branch of AT&T UNIX it was based on? IIRC, in the USG 4.0 doc that I sent to Matt, it says something like "UNIX is an operating system for the DEC PDP-11, the DEC VAX 11/780, and the IBM System 370". Matt --- can you confirm? I can't get to my copy so easily. That document dates from 1981, and as it came from USG, it would mean that the AT&T UNIX on 370 was from that world and is what is described in the 1984 BSTJ. If anyone has the System III source handy, one could check if there is a u370 shell script and/or a u370 directory in the kernel source. (There used to be shell scripts named pdp11, vax, u3b, and u370 for use in shell 'if' statements, analogous to the C preprocessor defines.) If so, then UNIX 370 would date back even further. HTH, Arnold From tuhs at tuhs.org Tue Dec 20 19:31:57 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 20 Dec 2022 09:31:57 +0000 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212200856.2BK8uA1d004518@freefriends.org> References: <202212191738.2BJHcLBF024793@ultimate.com> <202212200856.2BK8uA1d004518@freefriends.org> Message-ID: <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1. Yep, must've been 4.0, because that's in the first document, A.1.1: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf "Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750; and IBM System/370 and equivalent." But wait, there's more! https://archive.org/details/unix-system-release-description-system-v This is the Release Description released with System V. It contains a couple of introductory documents explaining the new features and general environmental adjustments involved, as well as a number of appendices that make up the bulk of the document. Of particular note in this case is Appendix I, the document I mentioned earlier containing a list of modification requests resolved between System III and System V. Then there's the Documentation Guide: https://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf This is where mention is made of many different architectures. There are documents for 3B20(A|S), 3B5, 3B15, 3B2, WE32100, VME/WE321SB, DEC (PDP/VAX), NS32000, M68000, iAPX 286, and Z8000. This document also mentions docs for UNIX Real-Time-Reliable on the 3B20D. No doubt a MERT and UNIX/RT descendant. 3B5 section mentions a "Release 5.3" so before the System V moniker. Farthest I've seen the minor version. I've skimmed over this listing a couple of times looking for other information but a few things stood out this time. The WE321SB seems to be a single board computer running a version called System V/VME. I wonder if any of those still exist, a single board running SVR2 out of the box! No mention of System/370 though, but of course this is just a listing of available documentation at the time, it doesn't reflect what is actually out there. Of the listed architectures, I don't think I've seen anything floating around for VME/WE321SB, Z8000, or iAPX 286, but I can't say I've looked very hard. Needless to say the system really grew legs in the 80s even inside the Bell. - Matt G. ------- Original Message ------- On Tuesday, December 20th, 2022 at 12:56 AM, arnold at skeeve.com wrote: > Phil Budne phil at ultimate.com wrote: > > > Is there any other surviving documentation about the system? > > Any recall of what branch of AT&T UNIX it was based on? > > > IIRC, in the USG 4.0 doc that I sent to Matt, it says something like > "UNIX is an operating system for the DEC PDP-11, the DEC VAX 11/780, > and the IBM System 370". Matt --- can you confirm? I can't get to my > copy so easily. > > That document dates from 1981, and as it came from USG, it would mean > that the AT&T UNIX on 370 was from that world and is what is described > in the 1984 BSTJ. > > If anyone has the System III source handy, one could check if there > is a u370 shell script and/or a u370 directory in the kernel source. > (There used to be shell scripts named pdp11, vax, u3b, and u370 for use > in shell 'if' statements, analogous to the C preprocessor defines.) > If so, then UNIX 370 would date back even further. > > HTH, > > Arnold From arnold at skeeve.com Tue Dec 20 19:39:52 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 20 Dec 2022 02:39:52 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> References: <202212191738.2BJHcLBF024793@ultimate.com> <202212200856.2BK8uA1d004518@freefriends.org> <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> Message-ID: <202212200939.2BK9dqpo011090@freefriends.org> segaloco wrote: > Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1. > > Yep, must've been 4.0, because that's in the first document, A.1.1: > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf > > "Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment > Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750; > and IBM System/370 and equivalent." So there we have it, Unix/370 inside the Bell System was at 4.0. I don't think they ever released that outside the Bell System. Not surprising, as it needed a modified TSS underneath. Arnold From jsg at jsg.id.au Tue Dec 20 19:55:15 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 20 Dec 2022 20:55:15 +1100 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212200939.2BK9dqpo011090@freefriends.org> References: <202212191738.2BJHcLBF024793@ultimate.com> <202212200856.2BK8uA1d004518@freefriends.org> <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> <202212200939.2BK9dqpo011090@freefriends.org> Message-ID: On Tue, Dec 20, 2022 at 02:39:52AM -0700, arnold at skeeve.com wrote: > segaloco wrote: > > > Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1. > > > > Yep, must've been 4.0, because that's in the first document, A.1.1: > > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf > > > > "Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment > > Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750; > > and IBM System/370 and equivalent." > > So there we have it, Unix/370 inside the Bell System was at 4.0. I don't think they ever released that > outside the Bell System. Not surprising, as it needed a modified TSS underneath. > > Arnold "A Bell Laboratories -wide reorganisation in January 1981 resulted in the UNIX Lab being renumbered. Release 4.0 was launched from this organization in March. It introduced new IPC mechanisms as well as new drivers and changes to the text processing software and the C libraries etc. Also in March, the first UNIX release for an IBM machine was launched as UNIX/370 Release 3.0" Pirzada, A Statistical Examination of The Evolution of the UNIX System https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf From lproven at gmail.com Tue Dec 20 21:57:47 2022 From: lproven at gmail.com (Liam Proven) Date: Tue, 20 Dec 2022 12:57:47 +0100 Subject: [TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? In-Reply-To: References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> <20221213133726.GA20511@mcvoy.com> <20221214010531.GK20511@mcvoy.com> <018ac308-b67f-4e5a-4ae5-03f492900847@gmail.com> <37f4dd4e-c8b9-cd91-b4a5-aaa6cf3839ec@gmail.com> Message-ID: On Tue, 20 Dec 2022 at 09:31, Andrew Warkentin wrote: > QNX Classic and 4.x only ran on x86 machines, most of which were > either standard PCs or at least sort of PC-like (although AFAIK the > ability to run without a BIOS was present very early on). It was quite > common to run QNX on desktops as a development host for embedded > systems AFAIK. > > GUIs for QNX predate the Amiga deal, and have existed since the late > 80s. The original was QNX Windows, which was either a reimplementation > or port (not quite sure which) of Open Look on a custom non-X11 window > server, running on later versions of 2.x and all versions of 4.x. > > Later versions of 4.x added Photon 1, which looks like a cross between > Motif and Windows 9x, again based on a custom window server (this time > with a rather unconventional multi-process architecture). The 90s-era > demo disk was based on 4.25 and Photon 1 (there was also a 2.x demo > disk back in the 80s but this didn't have a GUI). Fascinating. Thanks for setting the record straight, and I apologise for my inaccurate speculation. > > 6.0 came with Photon 2, which is still Win9x-ish in terms of > organization and is a fairly straightforward evolution of Photon 1, > although the widgets look very vaguely Amiga-like in 6.0-6.2. 6.0 came > out slightly after the Amiga deal, so that might be the reason for the > Amiga-like theming. > > Neutrino was not the name of a GUI, but rather of the entire OS that > succeeded QNX 4 (the first versions of Neutrino used Photon 1 but were > incapable of self-hosting and were developed alongside 4.x; 6.0 was > the first mainline QNX version to be Neutrino-based). Aha! > There were also the i-Opener (running 4.25) and Audrey (running 6.0) > internet appliances of the late 90s. I did not realise they were QNX devices. I vaguely thought the 3Com Audrey was based on BeIA, in fact, but I must be confusing it with something else -- perhaps the Sony eVilla. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From andrew at humeweb.com Wed Dec 21 00:25:49 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 20 Dec 2022 06:25:49 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: Message-ID: <17054461-C155-4302-9D13-569ED73C1F8C@humeweb.com> when i worked on system iii and system v, we were certainly using SCCS (and not sublime). we had some machinery built on top of SCCS but by and large, it was just SCCS. > On Dec 19, 2022, at 4:02 PM, Brad Spencer wrote: > [snip] > > Someone else will have to indicate if raw SCCS was used during the time > frame for the code you are looking at or if there was some management > system built on SCCS that was actually used. > -- > Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From clemc at ccc.com Wed Dec 21 00:27:07 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 20 Dec 2022 09:27:07 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> References: <202212191738.2BJHcLBF024793@ultimate.com> <202212200856.2BK8uA1d004518@freefriends.org> <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> Message-ID: On Tue, Dec 20, 2022 at 4:32 AM segaloco via TUHS wrote: > This document also mentions docs for UNIX Real-Time-Reliable on the > 3B20D. No doubt a MERT and UNIX/RT descendant. I'm not so sure it was that direct, actually. This is the work from IH that I have mentioned from Tom Bishop et al. - a very cool system IMO. As I understand from Tom, the team had the earlier docs and code but started over for different reasons (primarily the need for SSI support). I'm not sure how many/if any, of the earlier MERT-specific system functions (see the docs that Heinz got to us on TUHS) were supported. As I understand it, few. The primary target for this system was to control ESS#5, and I don't think Tom and the team were considering codes that at already been released and running in the OC on PDP-11-based MERTs. > 3B5 section mentions a "Release 5.3" so before the System V moniker. > Farthest I've seen the minor version. > Again -- my point about internal AT&T politics. The 'System x' stuff was the marketing / legal team in North Carolina. System development was in Summit (USG). You can see two heads of AT&T in this observation of the code base. On the one hand, the traditional TelCo market, in which the 'UNIXness' was important, but on the other hand was Charlie Brown's new directive and being allowed to be in the 'computer business.' The whole thing about the System x stuff was created and pushed from NC as part of the latter. The folks concentrating on the former, the traditional teams in IH, Columbus, etc., already understood their customers (the former OCs, now baby Bells). > Needless to say the system really grew legs in the 80s even inside the > Bell. > Exactly - which is why all of this is so confusing years later, particularly to folks that did not live the times. Today (i.e, years after the fact), we can see many technical results as time points, such as releases from different teams. We know the technologies and the people that created/implemented them. But very much lost to time is the content - which is the politics and economics of why things went in specific directions. As I have said so often, as technologists, we have to try to remember: that simple economics beats sophisticated engineering Yes, this is sometimes grating for us, as we like to look at things from the technical side. As Larry likes to point out, the new SunVM was excellent but was tossed in favor of the inferior SVR4, or as Rob says, Research went with BSD on the Vax, although they too had what seems in hindsight to have been superior options. But I will that an experienced >>guess<< both of those were driven, in the end, by reasons other than pure technology (Larry has discussed the Sun situation, for instance). Only someone like Rob or Ken can say why in the end, BSD was picked -- but having lived these types of choices in other places, I'd >>bet just using BSD was because 'pure joy' was 'good enough' to support the Vaxen (which were tools for them) and they had other things to worry about - and/or their research efforts were no longer directed at the VM system, but rather other features such like distributed FS, remote execution and such. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Dec 21 01:04:27 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 20 Dec 2022 10:04:27 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221220013323.GL4401@mcvoy.com> Message-ID: <4abca725-252a-666e-9122-3df2afe648b7@case.edu> On 12/19/22 9:06 PM, Dan Cross wrote: > York Unix was how I met things on a Vax with VM. I remain a fan of how > Charles Forsyth codes things. Small and elegant. I don't know that it > fed back into anything. > > > Forsyth wrote a really nice paper on the follow-on work he did on Sun's; he > implemented the EMAS paging algorithms, which was quite the coup. http://www.collyer.net/who/geoff/taste.pdf -- ``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 akosela at andykosela.com Wed Dec 21 01:29:21 2022 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 20 Dec 2022 16:29:21 +0100 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> References: <20221220013323.GL4401@mcvoy.com> <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> Message-ID: On Tuesday, December 20, 2022, Adam Thornton wrote: > I mean, just a Unix, without all the cruft of a modern Linux, but which > can actually take advantage of the resources of a modern machine. I don't > care about a desktop, or even a graphical environment, I don't care about > all the strange syscalls that are there to support particular databases, I > don't care much about being a virtualization host. But then...what would the purpose of such a system? A mini-Unix just to run vi(1) or text based game? If you want to run retro games there are much better retro platforms for that, e.g. I do not need a Unix machine if I want to run MS-DOS era games. I prefer period correct hardware and software. If you want a modern Unix for production systems, then most of the real world modern workloads are run in Kubernetes which is a very Linux orientated technology anyway. It appears to me there is really no need for such a modern mini-Unix system outside of hard core O/S theorists community. There are already a myriad of similar projects like Alan Cox's Fuzix OS which can run e.g. on Amiga, but it will not play Centurion or Another World anytime soon anyway. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Dec 21 01:35:28 2022 From: athornton at gmail.com (Adam Thornton) Date: Tue, 20 Dec 2022 08:35:28 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221220013323.GL4401@mcvoy.com> <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> Message-ID: On Tue, Dec 20, 2022 at 8:29 AM Andy Kosela wrote: > On Tuesday, December 20, 2022, Adam Thornton wrote: > >> I mean, just a Unix, without all the cruft of a modern Linux, but which >> can actually take advantage of the resources of a modern machine. I don't >> care about a desktop, or even a graphical environment, I don't care about >> all the strange syscalls that are there to support particular databases, I >> don't care much about being a virtualization host. > > > But then...what would the purpose of such a system? ... > It appears to me there is really no need for such a modern mini-Unix > system outside of hard core O/S theorists community. > > I'm not asking for a _practical_ Christmas gift, and certainly not one that will help me at work. As you say: at work I've got Kubernetes. I think it would be aesthetically pleasing and fun to use. Need has nothing to do with it. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 21 08:25:31 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 20 Dec 2022 17:25:31 -0500 (EST) Subject: [TUHS] UNIX on (not quite bare) System/370 Message-ID: <20221220222531.3DC0818C079@mercury.lcs.mit.edu> > From: Bakul Shah > Is there a publicly available description of Reiser's VM system? I > found "A Unix operating system for the DEC VAX 11/780 Computer" by > London & Reiser which includes a long paragraph on VM (included below) That para is basically all about the VAX paging hardware; it doesn't say anything about how that (any :-) Unix actually uses it. Noel From davida at pobox.com Wed Dec 21 09:18:12 2022 From: davida at pobox.com (David Arnold) Date: Wed, 21 Dec 2022 10:18:12 +1100 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> References: <20221220013323.GL4401@mcvoy.com> <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> Message-ID: > On 20 Dec 2022, at 13:12, Adam Thornton wrote: > > I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. > > The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. > > Having said that...maybe what I really want is 64-bit 4.3 BSD? > > I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. I think xv6 does SMP? (param.h says NCPU = 8, at least). You’d need to add a network stack and a userland, but there are options for those … d From bakul at iitbombay.org Wed Dec 21 09:18:18 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 20 Dec 2022 15:18:18 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221220222531.3DC0818C079@mercury.lcs.mit.edu> References: <20221220222531.3DC0818C079@mercury.lcs.mit.edu> Message-ID: > On Dec 20, 2022, at 2:25 PM, Noel Chiappa wrote: > >> From: Bakul Shah > >> Is there a publicly available description of Reiser's VM system? I >> found "A Unix operating system for the DEC VAX 11/780 Computer" by >> London & Reiser which includes a long paragraph on VM (included below) > > That para is basically all about the VAX paging hardware; it doesn't say > anything about how that (any :-) Unix actually uses it. You are right! Mea culpa. There is a further para: Like the UNIX system for the PDP-11, the current implementation for the VAX-11/780 maintains each process in contiguous physical memory and swaps processes to disk when there is not enough physical memory to contain them all. Reducing external memory fragmentation to zero by utilizing the VAX- 11/780 memory mapping hardware for scatter loading is high on the list of things to do in the second imple- mentation pass. To simplify kernel memory allocation, the size of the user-segment memory map is an assembly parameter which currently allows three pages of page table or 192K bytes total for text, data, and stack. This also deserves to be rewritten, both to allow varying process size, and to allow processes larger than physical memory through demand paging. Dynamic page table size would mean dynamic u area size if the page table remained part of the u area. This seems like a minimal "bring up" port of V7. Later they must have implemented demand paging? From luther at makerlisp.com Wed Dec 21 12:43:48 2022 From: luther at makerlisp.com (Luther Johnson) Date: Tue, 20 Dec 2022 19:43:48 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221220013323.GL4401@mcvoy.com> <4942C729-FCE2-4075-9B1B-08CB7FC33813@gmail.com> Message-ID: I'm in the process of building a system like that for myself, but perhaps a little smaller - mine will be based on an embedded microprocessor I've developed (so much work still yet to do ! at least a year out). But are you familiar with the V7 port that Robert Nordier has done ? It's been mentioned here before: https://minnie.tuhs.org/pipermail/tuhs/2007-October/004782.html Here is his web site: https://edu.anarcho-copy.org/UNIX/unix-version-7/x86-port/www.nordier.com/v7x86/ On 12/20/2022 08:35 AM, Adam Thornton wrote: > > > On Tue, Dec 20, 2022 at 8:29 AM Andy Kosela > wrote: > > On Tuesday, December 20, 2022, Adam Thornton > wrote: > > I mean, just a Unix, without all the cruft of a modern Linux, > but which can actually take advantage of the resources of a > modern machine. I don't care about a desktop, or even a > graphical environment, I don't care about all the strange > syscalls that are there to support particular databases, I > don't care much about being a virtualization host. > > > But then...what would the purpose of such a system? ... > It appears to me there is really no need for such a modern > mini-Unix system outside of hard core O/S theorists community. > > > I'm not asking for a _practical_ Christmas gift, and certainly not one > that will help me at work. As you say: at work I've got Kubernetes. > I think it would be aesthetically pleasing and fun to use. Need has > nothing to do with it. > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Dec 22 08:17:58 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 21 Dec 2022 22:17:58 +0000 Subject: [TUHS] General Document Scans Thread (Was 3B20 Manual Scans) In-Reply-To: References: Message-ID: <45Q0t9PVvJprIt3r2zFzf4OhEjADf6cZOhz68jq9eUXLD9mO2dBDgKjaFqIIJYQj542XOdHi7dqucUyKctn_dM7EVCh1xReC2OjQdqSlHyo=@protonmail.com> Good day folks, reassigning this thread once again as I've refocused efforts to the System V docs I have since I'm working on a *ROFF restoration of that 4.1 manual, that seems quicker to market for research purposes than scanning and OCR'ing it all, as I can just compare 3.0 and 5.0 sources with diff and then touch up one or the other to produce a faithful typesetter source. Not to say I won't eventually be scanning the physical pages, but that seems like a quicker way to get stuff available for study. Given that, I'm scanning the System V stuff because there's a much less clear path to producing typesetter sources there, and truth be told there's a lot more interesting information in these docs. So without further ado, here's a second document from that set, the "Transition Aids" containing five papers: System III to System V transitional changes, 512 byte to 1K block filesystem transitions, changes to the UNIX ar format, an expository paper on COFF (Common Object File Format), and finally changes to the C language in this update. The COFF document is the longest, offers a full exposition, but the rest are just notes on what has changed between versions: https://archive.org/details/unix-system-transition-aids-system-v Additionally, as I kinda just dropped it buried in another thread, I also scanned this one the past few days, the System Release Description: https://archive.org/details/unix-system-release-description-system-v/ Where the Transition Aids concerns the most essential information for a System III user to assess a System V migration, the System Release Description is much more holistic and contains one very exciting document (for me at least), Appendix I, a list of modification requests completed in the upgrade, in other words, a development log of every commit between System III and System V (allegedly). Finally, looks like archive.org opted to OCR this for me, and the bits I've snipped and checked actually look accurate, so hopefully as I continue to do this, I continue to get quality OCR from archive.org for free. - Matt G. ------- Original Message ------- On Thursday, December 15th, 2022 at 10:09 PM, segaloco via TUHS wrote: > Good evening folks. I'm starting a new thread to pass along info as I scan materials from the 3B20S manual that I picked up. I figured it'd be easier to trickle out the bits folks ask me for first and then continue to scan the rest, that way anyone looking to sink their teeth into something specific can be sated first. > > With that, the first scan (and frankly one of my favorite things about this manual) is the cover itself: https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png > > Someone had mentioned the idea of making this into a poster and I gotta say, I'd gladly put one up. The image definitely would need some cleanup for that, I just scanned it like it came, haven't tried to clean up any of the wear of time yet. Sadly, the back cover isn't emblazoned with a big Bell logo like the 3.0 and 5.0 (Bell variant) manuals, so scanning that would be a boring white piece of cardstock. > > Anywho, the next round which may come later this evening or sometime this weekend is going to be various *ROFF-related documents, so documents like troff(1), mm(5), etc. > > - Matt G. From tuhs at tuhs.org Thu Dec 22 10:01:30 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 22 Dec 2022 00:01:30 +0000 Subject: [TUHS] General Document Scans Thread (Was 3B20 Manual Scans) In-Reply-To: <45Q0t9PVvJprIt3r2zFzf4OhEjADf6cZOhz68jq9eUXLD9mO2dBDgKjaFqIIJYQj542XOdHi7dqucUyKctn_dM7EVCh1xReC2OjQdqSlHyo=@protonmail.com> References: <45Q0t9PVvJprIt3r2zFzf4OhEjADf6cZOhz68jq9eUXLD9mO2dBDgKjaFqIIJYQj542XOdHi7dqucUyKctn_dM7EVCh1xReC2OjQdqSlHyo=@protonmail.com> Message-ID: And another today because I figured why not, the next batch should be a group, I didn't think I'd do another today or it would've been included, not trying to contribute to email alert fatigue for anyone. https://archive.org/details/unix-system-operators-guide-release-5-0 This is the Operator's Guide as published for Release 5.0 and System V. It contains information regarding console commands/configuration necessary to booting a UNIX system, some hardware and installation notes, and covers the 3B20S, 3B20A, PDP-11/70, and VAX-11/750+780. The PDP-11/70 gets the least attention, presumably because it was on the way out as a supported platform by this point. The next slug when I swing back around to it will be the Users and Administrators Guides, similar to this one but for a slightly different audience. After that, the remaining manuals will be a bit more challenging as they are conventional binding rather than binders, brads, or comb bound, trying to figure out if I can get adequate scans in a non-destructive way but may be unavoidable, in which case those will wait until after I move so I can work out a plan to have them rebound once all is said and done. Also, worth mentioning, when I'm done with all of these documents, I have no real attachment to the physical articles, so when the time comes, I'm going to be interested in offloading the physical materials with priority given to anything like a computing museum, then UNIX heads around here, then if nothing else will just donate them to the local community college library if they're interested. If anyone is aware of a perfect destination for these, I'm happy to coordinate shipping them to their forever home once I'm done scanning. Whoever gets them can pay me if they want, but that won't be prerequisite beyond probably asking for shipping costs to be covered. I'm much more of the interest of insuring they go somewhere they'll be cherished/taken care of than making any sort of money off the transaction, I'm already doing this stuff at a loss because I'm more interested in the preservation aspect. Plus, I ain't trying to give the impression I'm financially gaining from all this material I didn't write. Thanks for being a willing audience to all my study and research lately, hopefully the materials are making putting up with my verbosity and frequency worth it :) - Matt G. ------- Original Message ------- On Wednesday, December 21st, 2022 at 2:17 PM, segaloco via TUHS wrote: > Good day folks, reassigning this thread once again as I've refocused efforts to the System V docs I have since I'm working on a *ROFF restoration of that 4.1 manual, that seems quicker to market for research purposes than scanning and OCR'ing it all, as I can just compare 3.0 and 5.0 sources with diff and then touch up one or the other to produce a faithful typesetter source. Not to say I won't eventually be scanning the physical pages, but that seems like a quicker way to get stuff available for study. > > Given that, I'm scanning the System V stuff because there's a much less clear path to producing typesetter sources there, and truth be told there's a lot more interesting information in these docs. > > So without further ado, here's a second document from that set, the "Transition Aids" containing five papers: System III to System V transitional changes, 512 byte to 1K block filesystem transitions, changes to the UNIX ar format, an expository paper on COFF (Common Object File Format), and finally changes to the C language in this update. The COFF document is the longest, offers a full exposition, but the rest are just notes on what has changed between versions: https://archive.org/details/unix-system-transition-aids-system-v > > Additionally, as I kinda just dropped it buried in another thread, I also scanned this one the past few days, the System Release Description: https://archive.org/details/unix-system-release-description-system-v/ > > Where the Transition Aids concerns the most essential information for a System III user to assess a System V migration, the System Release Description is much more holistic and contains one very exciting document (for me at least), Appendix I, a list of modification requests completed in the upgrade, in other words, a development log of every commit between System III and System V (allegedly). Finally, looks like archive.org opted to OCR this for me, and the bits I've snipped and checked actually look accurate, so hopefully as I continue to do this, I continue to get quality OCR from archive.org for free. > > - Matt G. > > ------- Original Message ------- > On Thursday, December 15th, 2022 at 10:09 PM, segaloco via TUHS tuhs at tuhs.org wrote: > > > > > Good evening folks. I'm starting a new thread to pass along info as I scan materials from the 3B20S manual that I picked up. I figured it'd be easier to trickle out the bits folks ask me for first and then continue to scan the rest, that way anyone looking to sink their teeth into something specific can be sated first. > > > > With that, the first scan (and frankly one of my favorite things about this manual) is the cover itself: https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png > > > > Someone had mentioned the idea of making this into a poster and I gotta say, I'd gladly put one up. The image definitely would need some cleanup for that, I just scanned it like it came, haven't tried to clean up any of the wear of time yet. Sadly, the back cover isn't emblazoned with a big Bell logo like the 3.0 and 5.0 (Bell variant) manuals, so scanning that would be a boring white piece of cardstock. > > > > Anywho, the next round which may come later this evening or sometime this weekend is going to be various *ROFF-related documents, so documents like troff(1), mm(5), etc. > > > > - Matt G. From pnr at planet.nl Thu Dec 22 20:55:04 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 22 Dec 2022 11:55:04 +0100 Subject: [TUHS] Early Unix on (64-bit) Risc-V Message-ID: Adam Thorton wrote: > I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. > > The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. > > Having said that...maybe what I really want is 64-bit 4.3 BSD? > > I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. Luther Johnson wrote: > I'm in the process of building a system like that for myself, but > perhaps a little smaller - mine will be based on an embedded > microprocessor I've developed (so much work still yet to do ! at least a > year out). Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal. It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats). The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true. The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents. My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list. === David Arnold wrote: > I think xv6 does SMP? (param.h says NCPU = 8, at least). > > You’d need to add a network stack and a userland, but there are options for those … For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.). As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained. In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start. From jnc at mercury.lcs.mit.edu Fri Dec 23 03:26:54 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 22 Dec 2022 12:26:54 -0500 (EST) Subject: [TUHS] UNIX on (not quite bare) System/370 Message-ID: <20221222172654.965D618C079@mercury.lcs.mit.edu> > From: Bakul Shah > There is a further para: > Reducing external memory fragmentation to zero by utilizing the VAX- > 11/780 memory mapping hardware for scatter loading is high on the list > of things to do in the second implementation pass. I'm curious as to exactly what is meant by "external memory"? They must mean memory on the Synchronous Backplane Interconnect: http://gunkies.org/wiki/Synchronous_Backplane_Interconnect I.e. what most of us would call 'main memory'. If this code didn't even allocate main memory by pages, instead of in process-size blocks, it sounds like it's much like 32V (or is it 32V that's being discussed; I thought this thread had moved on to the Reiser demand paging version - my apologies it I've gotten lost). Also, this note: http://gunkies.org/wiki/Talk:CB-UNIX from Dale DeJager (which he kindly gave me permission to post) gives a fair amount of detail on the relationship between the Research and CB/UNIX versions, with a brief mention of USG - precisely the era, and relationships, that are so poorly documented. Interestingly, he indicates that the early versions of what later became CB/UNIX used something in the V1/V3 range (V4 was the first one in C), so it dates back earlier than most people apparently assume. If anyone else has any first-hand notes (i.e.from people who were there at the time), about the relationship between all the early systems, for which the author has given permiosssion to post it, please send it to me and I will add it to the appropriate article on the CHWiki. Probably the most needed is more about the roots of USG; Dale has filled in CB/UNIX, and the roots of PWB are covered fairly well in the BSTJ article on it: https://archive.org/details/bstj57-6-2177 at least, for PWB1. Anything that covers the later PWBs would likewise be gratefully receied. I suppose I should also write up the relationships of the later UNIXen - 32V and its descendants too - any material sent to me about them will be most gratefully received. (If anyone want a CHWiki account, to write it up themselves, please let me know). Noel From crossd at gmail.com Fri Dec 23 03:33:12 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 22 Dec 2022 12:33:12 -0500 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221222172654.965D618C079@mercury.lcs.mit.edu> References: <20221222172654.965D618C079@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 22, 2022 at 12:27 PM Noel Chiappa wrote: > > > From: Bakul Shah > > > There is a further para: > > > Reducing external memory fragmentation to zero by utilizing the VAX- > > 11/780 memory mapping hardware for scatter loading is high on the list > > of things to do in the second implementation pass. > > I'm curious as to exactly what is meant by "external memory"? They must mean > memory on the Synchronous Backplane Interconnect: > > http://gunkies.org/wiki/Synchronous_Backplane_Interconnect > > I.e. what most of us would call 'main memory'. > [snip] I think you left off a critical word: "fragmentation." I interpreted this to be about external memory fragmentation a la memory allocators. As in, https://en.wikipedia.org/wiki/Fragmentation_(computing)#External_fragmentation Presumably, this would be less of an issue if they were actually making use of the virtual memory hardware to compose contiguous virtual address spaces from discontiguous physical memory pages. - Dan C. From phil at ultimate.com Fri Dec 23 04:52:22 2022 From: phil at ultimate.com (Phil Budne) Date: Thu, 22 Dec 2022 13:52:22 -0500 Subject: [TUHS] Early supported UNIX manual Message-ID: <202212221852.2BMIqMRk003859@ultimate.com> Rather than increase subject drift on a thread I started "UNIX on (not quite bare) System/370", here's a new thread. Since the TUHS archive seems to now include documentation, I decided to take a look and see if the earliest UNIX manual I have is in the archive: It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980) who had graduated, and worked for AT&T. It's hole punched for a four ring binder (I found an unused Bell System Project Telstar binder to put it in). The cover page has: Upper left corner: Bell Telephone Laboratories Incorperated PROGRAM APPLICATION INSTRUCTION Upper right corner: PA-1C300-01 Section 1 Issue 1, January 1976 AT&TCo SPCS Center: UNIX PROGRAMMER'S MANUAL Program Generic PG-1C300 Issue 2 Published by the UNIX Support Group January, 1976 The preface starts with: This document is published as part of the UNIX Operating System Program Generic, PG-1C300 Issue 2. The development of the Program Generic is the result of the efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift, G. C. Vogel and I. A. Winheim. and ends with For corrections and comments please contact C. D. Perez, MH 2C-423, Extension 6041. Not knowing who else I could ask, I brought it to a Boston Usenix (in the 90's or oughts), and asked DMR if he could identify it. He said it was an early supported UNIX, and he signed the preface page for me. The manual has sections I through VIII; all manual pages start with page -1- I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf with cover page: UNIX PROGRAM DESCRIPTION Program Generic PG-1C300 Issue 2 Published by the UNIX Support Group January 1976 contents: NUMBER ISSUE TITLE PD-1C301-01 1 Operating System PD-1C302-01 1 Device Drivers Section 1 PD-1C303-01 1 Device Drivers Section 2 And consists of descriptions of kernel functions. So it seems likely that my manual is a companion to that. I have a Brother printer/scanner, but the paper is fragile, so unless it's of immediate and burning value to someone, it's unlikely to rise to the top of my ever-static list of documents to scan.... But if someone has specific questions I can look up, let me know.... From andrew at humeweb.com Fri Dec 23 05:00:00 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 22 Dec 2022 11:00:00 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <202212191738.2BJHcLBF024793@ultimate.com> References: <202212191738.2BJHcLBF024793@ultimate.com> Message-ID: <17C275C8-C08C-4FC7-B78D-00094495FD73@humeweb.com> i used to work for ianj (his login), and in fact, he persuaded bell labs to hire me from australia. he had been my boss at the australian graduate school of management. i think jon lions induced bell labs to interview ian for a job. ian has retired and lives in rural victoria (australia), i think. i occasionally have an alumni zoom conference with him. ian caused a kerfuffle with bell labs. he was so good at his job that bell labs wanted to promote him to supervisor but at the time, he was still on a visitor (j-1) visa. > On Dec 19, 2022, at 9:38 AM, Phil Budne wrote: > > I also found mention at http://www.columbia.edu/~rh120/ch106.x09 > chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: > > Ian Johnstone, who had been the tutor at University of New > South Wales working with Professor John Lions, was one of the > researchers invited to Bell Labs. He managed the completion at > AT&T Bell Labs of the port of Unix to the IBM 370 computer. See > "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX > Review, October, 1984, p. 26. Johnstone also led the group that did > the port to the AT&T 2B20A multiprocessor system. > > Thanks! > Phil > From tuhs at tuhs.org Fri Dec 23 05:51:03 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 22 Dec 2022 19:51:03 +0000 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212221852.2BMIqMRk003859@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> Message-ID: <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> That is exciting news and I wish you all the best with scanning efforts! One area of immediate curiosity for me is the init system, whether the pages suggest it is more in line with research (rc and ttys files) or TS (inittab, runlevels). - Matt G. ------- Original Message ------- On Thursday, December 22nd, 2022 at 10:52 AM, Phil Budne wrote: > Rather than increase subject drift on a thread I started > "UNIX on (not quite bare) System/370", here's a new thread. > > Since the TUHS archive seems to now include documentation, > I decided to take a look and see if the earliest UNIX manual I have > is in the archive: > > It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980) > who had graduated, and worked for AT&T. > > It's hole punched for a four ring binder > (I found an unused Bell System Project Telstar binder to put it in). > > The cover page has: > > Upper left corner: > Bell Telephone Laboratories Incorperated > PROGRAM APPLICATION INSTRUCTION > > Upper right corner: > PA-1C300-01 > Section 1 > Issue 1, January 1976 > AT&TCo SPCS > > Center: > UNIX PROGRAMMER'S MANUAL > Program Generic PG-1C300 Issue 2 > Published by the UNIX Support Group > January, 1976 > > The preface starts with: > > This document is published as part of the UNIX Operating System Program Generic, > PG-1C300 Issue 2. The development of the Program Generic is the result of the > efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano > and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift, > G. C. Vogel and I. A. Winheim. > > and ends with > > For corrections and comments please contact C. D. Perez, MH 2C-423, Extension > 6041. > > Not knowing who else I could ask, I brought it to a Boston Usenix (in > the 90's or oughts), and asked DMR if he could identify it. He said > it was an early supported UNIX, and he signed the preface page for me. > > The manual has sections I through VIII; all manual pages start with page -1- > > I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > with cover page: > UNIX PROGRAM DESCRIPTION > Program Generic PG-1C300 Issue 2 > Published by the UNIX Support Group > January 1976 > > contents: > NUMBER ISSUE TITLE > PD-1C301-01 1 Operating System > PD-1C302-01 1 Device Drivers Section 1 > PD-1C303-01 1 Device Drivers Section 2 > > And consists of descriptions of kernel functions. > > So it seems likely that my manual is a companion to that. > > I have a Brother printer/scanner, but the paper is fragile, so unless > it's of immediate and burning value to someone, it's unlikely to rise > to the top of my ever-static list of documents to scan.... > > But if someone has specific questions I can look up, let me know.... From imp at bsdimp.com Fri Dec 23 06:25:11 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 22 Dec 2022 13:25:11 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: <20221222172654.965D618C079@mercury.lcs.mit.edu> References: <20221222172654.965D618C079@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 22, 2022, 10:27 AM Noel Chiappa wrote: > > From: Bakul Shah > > > There is a further para: > > > Reducing external memory fragmentation to zero by utilizing the VAX- > > 11/780 memory mapping hardware for scatter loading is high on the > list > > of things to do in the second implementation pass. > > I'm curious as to exactly what is meant by "external memory"? They must > mean > memory on the Synchronous Backplane Interconnect: > > http://gunkies.org/wiki/Synchronous_Backplane_Interconnect > > I.e. what most of us would call 'main memory'. > > If this code didn't even allocate main memory by pages, instead of in > process-size blocks, it sounds like it's much like 32V (or is it 32V that's > being discussed; I thought this thread had moved on to the Reiser demand > paging version - my apologies it I've gotten lost). > > > Also, this note: > > http://gunkies.org/wiki/Talk:CB-UNIX > > from Dale DeJager (which he kindly gave me permission to post) It's quite similar to a note he posted to I think unix-wizards mailing list back in the late 80s. I found it for my early unix talk and it's why I call cbunix the first fork. gives a fair > amount of detail on the relationship between the Research and CB/UNIX > versions, with a brief mention of USG - precisely the era, and > relationships, > that are so poorly documented. Interestingly, he indicates that the early > versions of what later became CB/UNIX used something in the V1/V3 range (V4 > was the first one in C), so it dates back earlier than most people > apparently > assume. > For my early unix talk, I think I pegged that at V2. Running on the 11/20 coupled with V3 manual strongly suggesting running on 11/20 would be better with v1 or v2. If anyone else has any first-hand notes (i.e.from people who were there at > the > time), about the relationship between all the early systems, for which the > author has given permiosssion to post it, please send it to me and I will > add it to the appropriate article on the CHWiki > The source I had said it was NJ Bell that did the productization of v2 in 1972 or 1973 for the SCCS project. I have a memory of reading somewhere that Columbus took over maintenance once they deployed and out of that grew cbunix. I'll see if I can find that again. It matches other things I've read that Columbus provided support for the operating companies deploying unix. Warner Probably the most needed is more about the roots of USG; Dale has filled in > CB/UNIX, and the roots of PWB are covered fairly well in the BSTJ article > on it: > > https://archive.org/details/bstj57-6-2177 > > at least, for PWB1. Anything that covers the later PWBs would likewise be > gratefully receied. > > > I suppose I should also write up the relationships of the later UNIXen - > 32V > and its descendants too - any material sent to me about them will be most > gratefully received. (If anyone want a CHWiki account, to write it up > themselves, please let me know). > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Fri Dec 23 07:44:32 2022 From: phil at ultimate.com (Phil Budne) Date: Thu, 22 Dec 2022 16:44:32 -0500 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> References: <202212221852.2BMIqMRk003859@ultimate.com> <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> Message-ID: <202212222144.2BMLiWHk007731@ultimate.com> Matt G wrote: > One area of immediate curiosity for me is the init system, whether the pages suggest it is more in line with research (rc and ttys files) or TS (inittab, runlevels). The init (VII) page mentions /etc/rc and refers to ttys (V) which says the file consists of lines with three characters (enable, tty name, getty arg) getty (VII) describes behaviors for 0, -, 1, 2 The one interesting bit in section (II) is lock (system call 62.) that implements semaphores with subfunctions lock/unlock/tlock, all of which take a non-negative semaphore ID called a flag. From tuhs at tuhs.org Fri Dec 23 07:55:06 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 22 Dec 2022 21:55:06 +0000 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212222144.2BMLiWHk007731@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> <202212222144.2BMLiWHk007731@ultimate.com> Message-ID: Drat, the origin of SysIII init remains obscure...it's not in PWB 1, now not in USG Issue 2...so either PWB2, USG Issue 3 (or later) or UNIX/TS.....or maybe it's an older CB variant...anywho thank you for the quick response! - Matt G. ------- Original Message ------- On Thursday, December 22nd, 2022 at 1:44 PM, Phil Budne wrote: > Matt G wrote: > > > One area of immediate curiosity for me is the init system, whether the pages suggest it is more in line with research (rc and ttys files) or TS (inittab, runlevels). > > > The init (VII) page mentions /etc/rc and refers to ttys (V) which says the file > consists of lines with three characters (enable, tty name, getty arg) > > getty (VII) describes behaviors for 0, -, 1, 2 > > The one interesting bit in section (II) is lock (system call 62.) that > implements semaphores with subfunctions lock/unlock/tlock, all of > which take a non-negative semaphore ID called a flag. From imp at bsdimp.com Fri Dec 23 09:06:27 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 22 Dec 2022 16:06:27 -0700 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <20221222172654.965D618C079@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 22, 2022 at 1:25 PM Warner Losh wrote: > > > On Thu, Dec 22, 2022, 10:27 AM Noel Chiappa > wrote: > >> > From: Bakul Shah >> >> > There is a further para: >> >> > Reducing external memory fragmentation to zero by utilizing the >> VAX- >> > 11/780 memory mapping hardware for scatter loading is high on the >> list >> > of things to do in the second implementation pass. >> >> I'm curious as to exactly what is meant by "external memory"? They must >> mean >> memory on the Synchronous Backplane Interconnect: >> >> http://gunkies.org/wiki/Synchronous_Backplane_Interconnect >> >> I.e. what most of us would call 'main memory'. >> >> If this code didn't even allocate main memory by pages, instead of in >> process-size blocks, it sounds like it's much like 32V (or is it 32V >> that's >> being discussed; I thought this thread had moved on to the Reiser demand >> paging version - my apologies it I've gotten lost). >> >> >> Also, this note: >> >> http://gunkies.org/wiki/Talk:CB-UNIX >> >> from Dale DeJager (which he kindly gave me permission to post) > > > It's quite similar to a note he posted to I think unix-wizards mailing > list back in the late 80s. I found it for my early unix talk and it's why I > call cbunix the first fork. > Looks to be comp.unix on Jan 17, 1984 in our archive as Usenet/comp.unix/1984-January/007696.html and while it is somewhat similar to the gunkie's talk page, it differs in a number of ways. So I think Dale wrote these notes independently and didn't repost his earlier effort more recently. The gunkies note says it was retired in favor of Unix 4.0, but the earlier post says it was 5.0. this is also my source for the New Jersey Bell reference, though the above link also says that (I didn't see this before my last message). Of note for this thread, that article says: >>Note that CB-UNIX was not a derivative of UNIX/RT, but >>of Version 6 and Version 7. PWB UNIX was also a derivative of Version 7. >>USG UNIX was originally a derivative of Version 6 and 7 with some CB-UNIX >>facilities added. Eventaully a decision was made to consoldate to two >>versions of UNIX: UNIX/TS and UNIX/RT. RT was a derivative of MERT, and >>TS a derivative of PWB UNIX. RT was to be used by Operations Systems, but >>was never too widely accepted. Eventually, UNIX/TS was augmented to have >>many of the features present in CB-UNIX (this was done by Roger Faulkner >>at Indian Hill, BTL. This, in turn, became the base for UNIX 4.0, which >>was never released externally. While this augmentation was going on, UNIX/TS >>was being changed into UNIX 3.0 which was release externally as SYSTEM III. which gives a few more details, but it still leaves us wanting more. PWB 1.0 was Version 6 based (since V7 hadn't come out yet when it was released), so maybe it's talking about a later PWB that was V7 based? But last time this came up, people disputed that CB-Unix never ran on anything newer than the 11/70... > gives a fair >> amount of detail on the relationship between the Research and CB/UNIX >> versions, with a brief mention of USG - precisely the era, and >> relationships, >> that are so poorly documented. Interestingly, he indicates that the early >> versions of what later became CB/UNIX used something in the V1/V3 range >> (V4 >> was the first one in C), so it dates back earlier than most people >> apparently >> assume. >> > > For my early unix talk, I think I pegged that at V2. Running on the 11/20 > coupled with V3 manual strongly suggesting running on 11/20 would be better > with v1 or v2. > > If anyone else has any first-hand notes (i.e.from people who were there at >> the >> time), about the relationship between all the early systems, for which the >> author has given permiosssion to post it, please send it to me and I will >> add it to the appropriate article on the CHWiki >> > > The source I had said it was NJ Bell that did the productization of v2 in > 1972 or 1973 for the SCCS project. I have a memory of reading somewhere > that Columbus took over maintenance once they deployed and out of that grew > cbunix. I'll see if I can find that again. It matches other things I've > read that Columbus provided support for the operating companies deploying > unix. > I do wish I had pointers to more posts or notes from 'back in the day' from the early 80s with memories still relatively fresh. Warner > Warner > > Probably the most needed is more about the roots of USG; Dale has filled in >> CB/UNIX, and the roots of PWB are covered fairly well in the BSTJ article >> on it: >> >> https://archive.org/details/bstj57-6-2177 >> >> at least, for PWB1. Anything that covers the later PWBs would likewise be >> gratefully receied. >> >> >> I suppose I should also write up the relationships of the later UNIXen - >> 32V >> and its descendants too - any material sent to me about them will be most >> gratefully received. (If anyone want a CHWiki account, to write it up >> themselves, please let me know). >> >> Noel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gingell at computer.org Fri Dec 23 11:53:50 2022 From: gingell at computer.org (Rob Gingell) Date: Thu, 22 Dec 2022 17:53:50 -0800 Subject: [TUHS] UNIX on (not quite bare) System/370 In-Reply-To: References: <202212191738.2BJHcLBF024793@ultimate.com> <202212200856.2BK8uA1d004518@freefriends.org> <4eZtTVIQfet1mQn895IP8V1ZHaPd_E6PAseycGIryzxcUSh-2vdyfPcB2a-KB3zyAUBYT1SPXXt200n2dBB7tt3ghyto1ZcWhQOLlqx01Mc=@protonmail.com> Message-ID: Some additional contextual notes largely in support of Clem's observations: On 12/20/22 6:27 AM, Clem Cole wrote: > Charlie Brown's new directive and > being allowed to be in the 'computer business.'  The whole thing about > the System x stuff was created and pushed from NC as part of the > latter. ... > As I have said so often, as technologists, we have to try to remember: > that simple economics beats sophisticated engineering > Yes, this is sometimes grating for us, as we like to look at things from > the technical side. As Larry likes to point out, the new SunVM was > excellent but was tossed in favor of the inferior SVR4, I said "largely in support" because have to contradict something first. The Sun VM system wasn't thrown out in SVR4, it was incorporated into SVR4, as were all of Sun's significant systems technologies through SunOS 4.0. (Which isn't to dismiss Larry's grievances over SVR4 as well as later changes corrupting to the VM system to support ZFS, simply to put them in the timeline correctly.) That the AT&T/Sun SVR4 project happened at all had as its backdrop AT&T's desire to enter the computer business in a big way. AT&T had hired Vittorio Cassoni to run its computer division and he supplied significant energy towards the relationship with Sun (the word "pursuit" seemed applicable at the time). The impression I had was that this was part of trying to move quickly, one of probably several initiatives to gain a foothold in the industry. An alliance with a then red-hot company like Sun was perceived to serve that. People who were at Summit or within AT&T likely have a better and more complete cause-and-effect history. The alliance was over more than UNIX as it anticipated AT&T employing SPARC processors and gaining a "platform presence". To Clem's point though, the alliance meant both organizations had to make concessions. In this particular case Sun didn't have to concede its existing systems work such as the VM system as that was all adopted in SVR4, but did have to concede what our plans would have been without the alliance. I can't speak to USG/Summit's concession but I'm very aware that our imposition on them was ... disruptive. The press release jointly issued by both companies announcing the alliance, when read in the context of "AT&T is getting into the computer business" may add perspective. The release is appended below, though reading it 35 years later and knowing the outcome is also an interesting perspective and an illustration that "optimism" is also a party to most new relationships, ==== FOR RELEASE MONDAY, OCTOBER 19, 1987 NEW YORK, NY -- AT&T and Sun Microsystems, Inc., today unveiled plans for a computer platform that will be unsurpassed in its ability to protect customers' software investments, while allowing them to take full advantage of technological innovation. "This is the wave of the future," said Vittorio Cassoni, president of AT&T's Data Systems Group. "We expect this platform to become a major computing environment for the 1990's and beyond." The new platform will use a unified version of AT&T's UNIX System V, as well as Sun's recently announced Scalable Processor Architecture (SPARC*), a flexible microprocessor design for chips that use reduced instruction-set computing (RISC) technology. It will include a standard interface, known as an application binary interface, or ABI, which will run UNIX system software programs as interchangeably as personal computers run PC software today. "Customers are demanding freedom of choice and easy access to new technology--needs that only the UNIX system can meet," said Cassoni. "That is why AT&T is making a concerted effort to consolidate the UNIX system market." UNIX System V for the new platform will incorporate popular features of the Berkeley 4.2 system, a derivative of the UNIX system used widely in scientific and engineering markets, as well as features of SunOS*, a variant of the Berkeley 4.2 systems marketed by Sun. These features include networking and graphics features, such as the Network File System (NFS*) and X.11/NeWS*, a graphic user interface. Earlier this year, AT&T and Microsoft Corporation agreed to incorporate the features of Microsoft's XENIX** into UNIX System V. "Our agreement with Microsoft solidified the UNIX system market for computers that use the Intel 80386 microprocessor, just as today's agreement defines the UNIX system market for RISC computers," said Cassoni. "It's clear that the next generation of computers will be based on RISC technology," said Scott McNealy, president and chief executive officer of Sun Microsystems. "The safest investments today are computers based on the UNIX system. The UNIX system is the only environment that can ride the technology curve to RISC. "The SPARC architecture is capturing widespread interest in the industry," said McNealy. "With UNIX System V and the ABI, SPARC systems will give customers a powerful, open alternative to the proprietary computing environments that, in effect, discourage innovation and growth." The SPARC architecture is gaining acceptance among RISC chip manufacturers, since it can be transferred, or scaled, easily to new, more powerful semiconductor technologies. SPARC technology already has been licensed to Fujitsu Microelectronics Inc., Cypress Semiconductor Corp., and Bipolar Integrated Technology, Inc., for manufacture. Sun markets the Sun-4* supercomputing workstation, which is based on a SPARC implementation from Fujitsu. "AT&T will add SPARC-based computers to its product line," Cassoni said. "And since our 3B computers and 6386 WorkGroup Systems are based on UNIX System V, our customers who require high-performance computers will be able to migrate easily to SPARC-RISC technology while protecting their current and future investments in 3B and 6386 software and system training." The new platform will be created in phases. By mid-1988, Sun will make available a version of SunOS that will conform to AT&T's System V Interface Definition. In 1989, AT&T will offer UNIX System V incorporating key Berkeley 4.2 system and SunOS features. AT&T, with Sun and others in the industry, then will continue to develop the technology to be incorporated into the UNIX system to meet the market needs of the 1990's. AT&T and Sun will offer the new platform in their product lines. In addition, AT&T will license the software technology and Sun will license the SPARC architecture to other manufacturers. ### From jnc at mercury.lcs.mit.edu Fri Dec 23 12:26:52 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 22 Dec 2022 21:26:52 -0500 (EST) Subject: [TUHS] Early supported UNIX manual Message-ID: <20221223022652.AD41018C079@mercury.lcs.mit.edu> > From: Phil Budne > The cover page has: > ... > Upper right corner: > PA-1C300-01 > Section 1 > Issue 1, January 1976 > AT&TCo SPCS I have a very similar manual; I got it a long time ago, and no longer recall how I came by it. Minor difference: mine is for PD-1C301-01, and at the bottom of the page, it says "ISSUE 1 1/30/76", followed by a prominent trade secret notice. TUHS has a copy of this version, here: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf The README file in that directory: https://www.tuhs.org/Archive/Distributions/USDL/README speculates that "this is PWB/1.0" but admits "this has not yet been confirmed". It's not PWB1, it's stock V6. If you look at the writeup of sys1$exec(), on pg. 39 of the PDF, you'll see it describing how arguments are copied into a disk buffer; that right there is the tip-off. In PWB1 (whose source we do have): https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys1.c you'll see that PWB1 accumulates the arguments in a chunk of swap space. V6 _does_ use a disk buffer for this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c So this is for V6. Noel From phil at ultimate.com Fri Dec 23 14:32:50 2022 From: phil at ultimate.com (Phil Budne) Date: Thu, 22 Dec 2022 23:32:50 -0500 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <20221223022652.AD41018C079@mercury.lcs.mit.edu> References: <20221223022652.AD41018C079@mercury.lcs.mit.edu> Message-ID: <202212230432.2BN4WorG015346@ultimate.com> Noel wrote: > > From: Phil Budne > > > The cover page has: > > ... > > Upper right corner: > > PA-1C300-01 > > Section 1 > > Issue 1, January 1976 > > AT&TCo SPCS > > I have a very similar manual; I got it a long time ago, and no longer recall > how I came by it. Minor difference: mine is for PD-1C301-01, and at the > bottom of the page, it says "ISSUE 1 1/30/76", followed by a prominent trade > secret notice. > > TUHS has a copy of this version, here: > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > The README file in that directory: > > https://www.tuhs.org/Archive/Distributions/USDL/README > > speculates that "this is PWB/1.0" but admits "this has not yet been > confirmed". It's not PWB1, it's stock V6. If you look at the writeup of > sys1$exec(), on pg. 39 of the PDF, you'll see it describing how arguments are > copied into a disk buffer; that right there is the tip-off. In PWB1 (whose > source we do have): > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys1.c > > you'll see that PWB1 accumulates the arguments in a chunk of swap space. > V6 _does_ use a disk buffer for this: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c > > So this is for V6. 1. My document is the programmers manual, with sections 1-8 (I through VIII). I can't say whether the document you have, and is on line is a PLM (program logic manual) for the same system or not (tho the dates and document numbers are very close). 2. My EXEC (II) manual page has BUGS: "Only 512 characters of arguments are allowed" So my manual, like yours is not for PWB. BUT, my manual describes system call 62, "lock", and the v6 sysent.c has "nosys" there, so it's at least in theory, an offshoot. I haven't spotted anything in the unix_program_description_jan_1976.pdf document regarding lock Searching for the names in the preface of my manual I found: J. F. Maranzano: Co-author with G W R Leuderer and B A Tague of "The UNIX Operating System as a Base for Aplications" BSTJ Vol. 57 No. 6 July-Aug 1978 https://www.bell-labs.com/institute/publications/bstj57-6-2201/ https://archive.org/details/bstj57-6-2201 Co-author with S.R. Bourne of "A Tutorial Introduction to ADB" https://wolfram.schneider.org/bsd/7thEdManVol2/adb/adb.pdf May 1977 https://minnie.tuhs.org/pipermail/tuhs/2018-May/015468.html Mention in list of UNIX Tech Memoranda: A Description of the UNIX File System September 16, 1975 Author J. F. Maranzano R. B. Brandt Richard B. Brandt appears in distribution list (cover sheet only) in https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-75-1352-2_Emulation_of_UNIX_on_Peripheral_Processors_19750109.pdf J. Feder Author "The UNIX system: The evolution of UNIX system performance" Oct 1984 AT&T Bell Laboratories Technical Journal ( Volume: 63, Issue: 8, October 1984) https://www.bell-labs.com/institute/publications/arnumber-6771919/ C. D. Perez: in "A Guide to the C Library for UNIX Users": https://bitsavers.org/pdf/att/unix/Release_4.0_1981/UNIX_Release_4.0_Volume_1_198101.pdf (pdf p. 395) And https://bitsavers.org/pdf/att/unix/Release_4.0_1981/UNIX_Release_4.0_Volume_2_198101.pdf pdf p 371 acknowledges Cathy Perez Cathy Perez is also thanked in https://www.tuhs.org/Archive/Documentation/Papers/lions_PCCpass2_jun1979.pdf T. M. Raleigh https://minnie.tuhs.org/pipermail/tuhs/2018-May/015468.html Mention in list of UNIX Tech Memoranda: Introduction to Scheduling and Switching under UNIX October 20, 1975 TM: 75-8234-7 Author: T. M. Raleigh R. E. Swift nothing found at first glance G. C. Vogel http://bitsavers.informatik.uni-stuttgart.de/pdf/att/unix/System_III/UNIX_Users_Manual_Release_3_Jun80.pdf pdf p. 4 "P. E. Cannata and G. C. Vogel rewrote Section 2 for this edition." I. A. Winheim nothing found at first glance From arnold at skeeve.com Fri Dec 23 17:52:23 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 23 Dec 2022 00:52:23 -0700 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212230432.2BN4WorG015346@ultimate.com> References: <20221223022652.AD41018C079@mercury.lcs.mit.edu> <202212230432.2BN4WorG015346@ultimate.com> Message-ID: <202212230752.2BN7qNqg014188@freefriends.org> Hi. Phil Budne wrote: > > you'll see that PWB1 accumulates the arguments in a chunk of swap space. > > V6 _does_ use a disk buffer for this: > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c > > > > So this is for V6. > > 1. My document is the programmers manual, with sections 1-8 (I through > VIII). This fact alone indicates that the code predates V7; through V6 the manual sections used Roman numerals. From V7 on they used Arabic numerals. FWIW, Arnold From ralph at inputplus.co.uk Fri Dec 23 18:47:23 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 23 Dec 2022 08:47:23 +0000 Subject: [TUHS] Book Scanning. (Was: Early supported UNIX manual) In-Reply-To: <202212221852.2BMIqMRk003859@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> Message-ID: <20221223084723.03954220C6@orac.inputplus.co.uk> Hi Phil, > I have a Brother printer/scanner, but the paper is fragile There are book scanners which take photographs of the pages at a distance, typically with the manual turning of pages. Or cradles which hold the book and the mobile phone that does the snapping. Or just mobile-phone apps leaving the lighting and physical positioning up to you. Removing page curvature is done in software. https://diybookscanner.org may be useful, especially its forum. Or perhaps there's experience with ‘photo scanning’ on this list. -- Cheers, Ralph. From jsg at jsg.id.au Fri Dec 23 19:09:56 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 23 Dec 2022 20:09:56 +1100 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212230432.2BN4WorG015346@ultimate.com> References: <20221223022652.AD41018C079@mercury.lcs.mit.edu> <202212230432.2BN4WorG015346@ultimate.com> Message-ID: On Thu, Dec 22, 2022 at 11:32:50PM -0500, Phil Budne wrote: > Noel wrote: > > > From: Phil Budne > > > > > The cover page has: > > > ... > > > Upper right corner: > > > PA-1C300-01 > > > Section 1 > > > Issue 1, January 1976 > > > AT&TCo SPCS > > > > I have a very similar manual; I got it a long time ago, and no longer recall > > how I came by it. Minor difference: mine is for PD-1C301-01, and at the > > bottom of the page, it says "ISSUE 1 1/30/76", followed by a prominent trade > > secret notice. > > > > TUHS has a copy of this version, here: > > > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > > > The README file in that directory: > > > > https://www.tuhs.org/Archive/Distributions/USDL/README > > > > speculates that "this is PWB/1.0" but admits "this has not yet been > > confirmed". It's not PWB1, it's stock V6. If you look at the writeup of > > sys1$exec(), on pg. 39 of the PDF, you'll see it describing how arguments are > > copied into a disk buffer; that right there is the tip-off. In PWB1 (whose > > source we do have): > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys1.c > > > > you'll see that PWB1 accumulates the arguments in a chunk of swap space. > > V6 _does_ use a disk buffer for this: > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c > > > > So this is for V6. > > 1. My document is the programmers manual, with sections 1-8 (I through > VIII). I can't say whether the document you have, and is on line is a > PLM (program logic manual) for the same system or not (tho the dates > and document numbers are very close). > > 2. My EXEC (II) manual page has BUGS: > "Only 512 characters of arguments are allowed" > > So my manual, like yours is not for PWB. Is there an access() system call? https://minnie.tuhs.org/pipermail/tuhs/2021-November/024657.html or alarm() and pause() system calls added in the v6 "50 changes" tuhs/Applications/Spencer_Tapes/unsw3.tar.gz usr/sys/v6unix/unix_changes described in usr/sys/v6unix/changenotes or changes to C such as libS/stdio, unsigned and typedef which would later show up in the compiler on the phototypesetter version 7 tape. https://www.darwinsys.com/history/hist.html usr/source/c_compiler/ on the unsw3 tape may be close to that compiler, it isn't the same as the pwb compiler. "New archiver ... uses long (double-word) integers, which can only be compiled by the new C compiler which we can't distribute yet." UNIX News, May-June 1976, 6-3 tuhs/Documentation/Usenix/Early_Newsletters/197605-unix-news-n6.pdf "a new tape is in the process of preparation, and should be available as soon as it clears the lawyers, for the usual free license and handling fee. It contains the new nroff, the new C, the new I/O library (faster & smaller than anything to date), and a bunch of other such things. It will be available from Bell, not the Center. Ken is going to send a formal notice to the News." UNIX News, November 1976, pg 1 tuhs/Documentation/Usenix/Early_Newsletters/197611-unix-news-n11.pdf From phil at ultimate.com Sat Dec 24 04:04:54 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 23 Dec 2022 13:04:54 -0500 Subject: [TUHS] Early supported UNIX manual In-Reply-To: References: <20221223022652.AD41018C079@mercury.lcs.mit.edu> <202212230432.2BN4WorG015346@ultimate.com> Message-ID: <202212231804.2BNI4s3U031968@ultimate.com> Jonathan Gray asked: > Is there an access() system call? > https://minnie.tuhs.org/pipermail/tuhs/2021-November/024657.html no. > or alarm() and pause() system calls added in the v6 "50 changes" yes to both > or changes to C such as libS/stdio, unsigned and typedef which would > later show up in the compiler on the phototypesetter version 7 tape. > https://www.darwinsys.com/history/hist.html > usr/source/c_compiler/ on the unsw3 tape may be close to that compiler, > it isn't the same as the pwb compiler. The getc and putc man page synopsis look identical to the ones at https://man.cat-v.org/unix-6th/3/ Section VI differs from https://man.cat-v.org/unix-6th/6/ Mine has (in addition to those in v6) agen -- generates associative memory drivers hyphen -- find hyphenated words lex -- generate programs for simple lexical analysis ptx -- permuted index tmac -- -ms macros which is ms(vii) in v6 And from v6 is missing: azel col graph m6 plot quiz sky speak spline tbl tmg Compared to the v7 lex, the one command line argument is "-code", equivalent to a first input line of "%-code" which changes the output prefix from "yy" to "code". Compared to v6, Section I is missing: eqn, lpr, man, neqn, newgrp, opr, rc, rev, roff, spell, tee, troff. But has: lc (LIL compiler) mtm (magnetic tape manipulation), onintr (specify interrupt handling for a command file) read/open/onend (sequential file read) req (rewind tape) sum (sum file) The one man page I compared is yacc(I) which is missing the '-r' (ratfor) option present in v6 The manual is typeset, and the inside of the cover page days "This manual was set by a Grahpic Systems phototypesetter driven by the troff formatting program under the UNIX system. The text of the manual was prepared using the ed text editor" No sign of new archive format. I have only the manual pages, so I can't speak to the state of C. From jsg at jsg.id.au Sat Dec 24 13:30:09 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 24 Dec 2022 14:30:09 +1100 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212222144.2BMLiWHk007731@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> <202212222144.2BMLiWHk007731@ultimate.com> Message-ID: On Thu, Dec 22, 2022 at 04:44:32PM -0500, Phil Budne wrote: > > Matt G wrote: > > One area of immediate curiosity for me is the init system, whether the pages suggest it is more in line with research (rc and ttys files) or TS (inittab, runlevels). > > The init (VII) page mentions /etc/rc and refers to ttys (V) which says the file > consists of lines with three characters (enable, tty name, getty arg) > > getty (VII) describes behaviors for 0, -, 1, 2 > > The one interesting bit in section (II) is lock (system call 62.) that > implements semaphores with subfunctions lock/unlock/tlock, all of > which take a non-negative semaphore ID called a flag. used by MERT: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Calls%20-%20man2/lock.2.pdf "The semaphores provided in the MERT/UNIX supervisor are identical to those provided by the USG-UNIX Generic 3 system [8]. [8] Brandt, R. B., Implementation of Semaphores and Messages in UNIX, MF-76-8234-076." https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-78-3114-4_The_MERT-UNIX_Supervisor_19780420.pdf "Make (a program for maintaining other programs) was launched at the CSRC towards the end of the year and was immediately adopted by USG for the next generic release (PG-1C300 issue 2). This was a snapshot of the USG system at mod level 3.33 (January 1976) indicating at least three distinct levels of evolution: the generic releases, major and minor USG mod levels." "Generic 3.0 was released in spring 1977 (delayed from January)." Pirzada, A Statistical Examination of The Evolution of the UNIX System "I do remember a conversation with Dennis about semaphores, though. He mentioned that no less than five groups inside of Bell Labs had hacked semaphores into the kernel. Each group did it differently." Steve Johnson https://minnie.tuhs.org/pipermail/tuhs/2017-February/009748.html In CB-UNIX there was sema(2): https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man2_04.pdf In System V Release 1, semctl(2), semget(2), semop(2) http://www.bitsavers.org/pdf/att/unix/System_V_Release_1/301-905_UNIX_System_V_Release_1_Users_Manual_Jan83.pdf xenix creatsem(2), opensem(2), sigsem(2), waitsem(2) http://www.bitsavers.org/pdf/intel/system3xx/xenix-286/174385-001_Overview_of_the_XENIX_286_Operating_System_Nov84.pdf From tuhs at tuhs.org Sat Dec 24 18:58:06 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 24 Dec 2022 08:58:06 +0000 Subject: [TUHS] Early supported UNIX manual In-Reply-To: References: <202212221852.2BMIqMRk003859@ultimate.com> <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> <202212222144.2BMLiWHk007731@ultimate.com> Message-ID: <08n94qOTX7MtEldV_R4HpFjZ1ar4em7foXpHnK659iYVp7cv-ewgjx6nywuiRNladfhaeB2vg0U2nyN1DY3KLggUZDQqvuEpTaWQpvHiEOk=@protonmail.com> Your reference to sema(2) in CB-UNIX prompted me to go check the source and curiously, that isn't in sysent.c: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/SourceCode/cbunix6.pdf (p. 50). However, there is a sys5.c with some semaphore stuff in it. Not how the code gets from the sigcall entry to that file, maybe there's a CB-specific syscall aggregator like the sys3b systemcall for 3B20-specific stuff. It had never actually occurred to me that the semaphores in SVR1 weren't the ones from CB-UNIX, I thought they just forklifted all the IPC into 4.0 from CB. That then means the semaphores that carried through in System V originated at least in UNIX/TS 4.0, but not by way of CB. Minor trivia, but that's news to me. Maybe the sysV modification request logs can shed some light, I remember seeing several IPC mentions in there. - Matt G. ------- Original Message ------- On Friday, December 23rd, 2022 at 7:30 PM, Jonathan Gray wrote: > On Thu, Dec 22, 2022 at 04:44:32PM -0500, Phil Budne wrote: > > > Matt G wrote: > > > > > One area of immediate curiosity for me is the init system, whether the pages suggest it is more in line with research (rc and ttys files) or TS (inittab, runlevels). > > > > The init (VII) page mentions /etc/rc and refers to ttys (V) which says the file > > consists of lines with three characters (enable, tty name, getty arg) > > > > getty (VII) describes behaviors for 0, -, 1, 2 > > > > The one interesting bit in section (II) is lock (system call 62.) that > > implements semaphores with subfunctions lock/unlock/tlock, all of > > which take a non-negative semaphore ID called a flag. > > > used by MERT: > > https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix Programmer Manual - UPM - White Tabs/System Calls - man2/lock.2.pdf > > "The semaphores provided in the MERT/UNIX supervisor are identical to > those provided by the USG-UNIX Generic 3 system [8]. > [8] Brandt, R. B., Implementation of Semaphores and Messages in UNIX, MF-76-8234-076." > https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-78-3114-4_The_MERT-UNIX_Supervisor_19780420.pdf > > "Make (a program for maintaining other programs) was launched at the > CSRC towards the end of the year and was immediately adopted by USG for > the next generic release (PG-1C300 issue 2). This was a snapshot of the > USG system at mod level 3.33 (January 1976) indicating at least three > distinct levels of evolution: the generic releases, major and minor USG > mod levels." > > "Generic 3.0 was released in spring 1977 (delayed from January)." > > Pirzada, A Statistical Examination of The Evolution of the UNIX System > > "I do remember a conversation with Dennis about semaphores, though. > He mentioned that no less than five groups inside of Bell Labs had > hacked semaphores into the kernel. Each group did it differently." > Steve Johnson > https://minnie.tuhs.org/pipermail/tuhs/2017-February/009748.html > > In CB-UNIX there was sema(2): > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man2_04.pdf > > In System V Release 1, semctl(2), semget(2), semop(2) > http://www.bitsavers.org/pdf/att/unix/System_V_Release_1/301-905_UNIX_System_V_Release_1_Users_Manual_Jan83.pdf > > xenix creatsem(2), opensem(2), sigsem(2), waitsem(2) > http://www.bitsavers.org/pdf/intel/system3xx/xenix-286/174385-001_Overview_of_the_XENIX_286_Operating_System_Nov84.pdf From jsg at jsg.id.au Sat Dec 24 20:30:17 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 24 Dec 2022 21:30:17 +1100 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <08n94qOTX7MtEldV_R4HpFjZ1ar4em7foXpHnK659iYVp7cv-ewgjx6nywuiRNladfhaeB2vg0U2nyN1DY3KLggUZDQqvuEpTaWQpvHiEOk=@protonmail.com> References: <202212221852.2BMIqMRk003859@ultimate.com> <2PV-DjW5M0eYObQ5MSA_2OzpT0t9A6VXbljYr-F4VfM375f26IygWqKx5bTLQXGM-RaNsNCnaL-Ato2u4dyavj7fgOakY-e5y_2S1uUPJMA=@protonmail.com> <202212222144.2BMLiWHk007731@ultimate.com> <08n94qOTX7MtEldV_R4HpFjZ1ar4em7foXpHnK659iYVp7cv-ewgjx6nywuiRNladfhaeB2vg0U2nyN1DY3KLggUZDQqvuEpTaWQpvHiEOk=@protonmail.com> Message-ID: On Sat, Dec 24, 2022 at 08:58:06AM +0000, segaloco via TUHS wrote: > Your reference to sema(2) in CB-UNIX prompted me to go check the source and curiously, that isn't in sysent.c: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/SourceCode/cbunix6.pdf (p. 50). However, there is a sys5.c with some semaphore stuff in it. Not how the code gets from the sigcall entry to that file, maybe there's a CB-specific syscall aggregator like the sys3b systemcall for 3B20-specific stuff. It had never actually occurred to me that the semaphores in SVR1 weren't the ones from CB-UNIX, I thought they just forklifted all the IPC into 4.0 from CB. That then means the semaphores that carried through in System V originated at least in UNIX/TS 4.0, but not by way of CB. Minor trivia, but that's news to me. Maybe the sysV modification request logs can shed some light, I remember seeing several IPC mentions in there. > > - Matt G. https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man2L_01.pdf describes 'EVENT:O(2L), event - semaphore operations', event() is system call 63 in cbunix6.pdf sysent USG UNIX 4.0 and 4.1 IPC were not the same: https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/4mcL76lKbmMJ From michel at ngelo.eu Mon Dec 26 04:15:19 2022 From: michel at ngelo.eu (Michelangelo De Simone) Date: Sun, 25 Dec 2022 10:15:19 -0800 Subject: [TUHS] X11 Conservancy Project Message-ID: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> From [1]: The X11 Conservancy Project (X11CP) pulls together the disparate set of programs which were being written between the very late 80s, and early 90s -- usually for Unix and Linux. …snip… As the Internet expanded and Linux distributions became established, certain FTP sites were largely used to host some of the more established programs, as well as those found in the LSM. …snip… But the early dawn of free software, especially around applications written for X11, using Motif and XT and other widget libraries has now mostly been consigned to obscurity. With X11 itself now under threat of no longer being developed in favour of Wayland, these applications are going to be harder to run and be discovered. Hence, the X11CP is designed to be a central place for hosting the sources of these applications, and to showcase their unique history and properties. In keeping this software active, it will help keep an important historical point alive. [1] https://x11cp.org/ — Michelangelo From tuhs at tuhs.org Mon Dec 26 05:16:45 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 25 Dec 2022 19:16:45 +0000 Subject: [TUHS] X11 Conservancy Project In-Reply-To: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> Message-ID: Does the project accept patches to old X11 applications to get them working again? I've recently been tinkering with xfm, would love to contribute my retooling to such an effort. - Matt G. ------- Original Message ------- On Sunday, December 25th, 2022 at 10:15 AM, Michelangelo De Simone wrote: > From [1]: > > The X11 Conservancy Project (X11CP) pulls together the disparate set of programs which were being written between the very late 80s, and early 90s -- usually for Unix and Linux. > > …snip… > > As the Internet expanded and Linux distributions became established, certain FTP sites were largely used to host some of the more established programs, as well as those found in the LSM. > > …snip… > > But the early dawn of free software, especially around applications written for X11, using Motif and XT and other widget libraries has now mostly been consigned to obscurity. > With X11 itself now under threat of no longer being developed in favour of Wayland, these applications are going to be harder to run and be discovered. > > Hence, the X11CP is designed to be a central place for hosting the sources of these applications, and to showcase their unique history and properties. In keeping this software active, it will help keep an important historical point alive. > > [1] https://x11cp.org/ > > — Michelangelo > From e5655f30a07f at ewoof.net Mon Dec 26 05:57:36 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 25 Dec 2022 19:57:36 +0000 Subject: [TUHS] X11 Conservancy Project In-Reply-To: References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> Message-ID: On 25 Dec 2022 19:16 +0000, from tuhs at tuhs.org (segaloco via TUHS): > Does the project accept patches to old X11 applications to get them > working again? The "X11CP repository" link on the web site goes to https://codeberg.org/x11cp/x11cp which has a README that, under "Contributing", among other things lists "Source-code modification". There is also a recent patch committed that explicitly says "add compilation fixes" and "This makes gcc happier". See . By deduction, I would expect patches that allows old software to compile and execute on modern systems, while remainining true to the experience of running those applications in their original environment, to qualify for inclusion. There is also multiple points of contact listed, by way of which you could almost certainly get an authoritative answer. -- Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From g.branden.robinson at gmail.com Mon Dec 26 06:51:51 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 25 Dec 2022 14:51:51 -0600 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> Message-ID: <20221225205151.x3kflt7qrjc3b7i4@illithid> At 2022-12-25T10:15:19-0800, Michelangelo De Simone wrote: > The X11 Conservancy Project (X11CP) pulls together the disparate set > of programs which were being written between the very late 80s, and > early 90s -- usually for Unix and Linux. It looks like this must have just gotten started. All that is present is xtartan. Which I do at least remember. :) Library support is going to be an issue for a lot of X11 legacy apps. I remember that the XForms widget library used to be proprietary, and I recall that it had been freed, but not that this had been done 20 years ago now[1][2]...albeit still too late to have made itself the center of the Linux desktop environment, as it could have been if only the copyright holders had not clung so tightly to The Precious. Motif and XView similarly got freed (the latter quite early in fact, as I recall...but night had already fallen for the SunView UI). But two tooklit variants I've heard of, I've never found out if they ever made their sources freely available: OLIT and MoOLIT. As I understand it, OLIT was XView, but written on top of the X Toolkit Intrinsics library (Xt) as opposed to bypassing it and going straight to libX11. And MoOLIT was, apparently, some kind of shim--whether it supplemented OLIT or replaced it, I am not sure--that, like XForms and Java's AWT, allowed you to to write a "look-and-feel-neutral" application. As I recall, such efforts often failed because they abstracted only the intersection of available features rather than the union of them, so except for very simple UIs, programs didn't look or behave "idiomatically" anyway. I'd be curious to hear people's recollections of these and especially to learn of any pointers to source. Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which I never saw in the flesh. Regards, Branden [1] https://web.archive.org/web/20110718230734/http://xforms-toolkit.org/ Nowadays its web site does not even mention its proprietary past. [2] Before that relicensing, I was part of a team at Progeny Linux Systems that was contracted by HP to port xforms (and a lot of other stuff) to IA-64. xforms was given to me because I was "the X guy" on staff. I don't remember it being difficult--just the usual long/int punning issues. I don't recollect now whether xforms had already been ported to Alpha or SPARC V9; it seems to me that it should have been by 2001, or would have been, had it been FLOSS. Great merriment was had in those days dogging on IA-64, but the more I learned about that ISA the more I liked it compared it to x86, though that may be damning it with faint praise. But apparently IA-64 made novel demands with respect to instruction sequencing that caused compiler writers--or perhaps more accurately the people who would have to pay compiler writers--squeal like pigs in hot oil. Intel had a similar "fiasco" with the iAPX 432 fifteen years before; that was the ISA for which, infamously, "Ada [was the] intended primary language for application programming." Ada was also reviled, ostenisbly because it was too damn hard to write a compiler for it, but probably also because its keyword inventory more closely resembled Pascal than C, which was already starting to eat the world in the mid-1980s. Strangely enough, as I understand it, the compiler innovations demanded by Ada and IA-64, respectively, came to be standard and expected, and their benefits enjoyed unthinkingly by x86 and C advocates. Thus do we reward innovation in this industry. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From brad at anduin.eldar.org Mon Dec 26 07:03:11 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Sun, 25 Dec 2022 16:03:11 -0500 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: <20221225205151.x3kflt7qrjc3b7i4@illithid> (g.branden.robinson@gmail.com) Message-ID: "G. Branden Robinson" writes: [snip] > And MoOLIT was, apparently, some kind of shim--whether it supplemented > OLIT or replaced it, I am not sure--that, like XForms and Java's AWT, > allowed you to to write a "look-and-feel-neutral" application. [snip] Motif on OLIT, if I remember that correctly. Sort of a Motif look and feel but without the need to purchase a license for Motif which you had to do at the time (that is, in order to even RUN a motif linked application, you needed the shared libraries which you could pretty much only get by purchasing a license.. there was probably other ways, and it has been a LONG time ago). Our group at AT&T used it to keep from having to have the customer buy anything additional for a release but who also wanted "Motif". I don't honestly remember if you coded in OLIT or Motif, but probably OLIT, but the end result was something that sort of looked like Motif in the end. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From joshnatis0 at gmail.com Mon Dec 26 07:38:32 2022 From: joshnatis0 at gmail.com (josh) Date: Sun, 25 Dec 2022 16:38:32 -0500 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: <20221225205151.x3kflt7qrjc3b7i4@illithid> References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> Message-ID: > > Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which > I never saw in the flesh. > Branden, You may find this fellow’s archaeological dig on NeWS and PostScript interesting: https://twitter.com/rsnous/status/788053163857379328 He also attempted to make a NeWS clone: http://dev.rsnous.com/dewdrop/executive/ (source available). Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Dec 26 07:47:20 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 25 Dec 2022 21:47:20 +0000 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> Message-ID: Much as I was a fan of NeWS back in the day (and later used a NeWS-ish complete with the Owen Densmore object oriented extensions) postscript interpreter as the basis for our product, I’m having some issues with that “history.” First off, you couldn’t arbitrarily cat a PostScript file to the screen and expect it to work. There were enough differences between Adobe and the NeWS version to cause problems. The idea of putting small programs (written in PostScript) to handle the interaction was an interesting one. The problem is that writing stuff in PostScript (even with the NeWS extensions) is so godawful that I have my doubts about having implemented an entire X Server in one (having written several X Servers subsequent to that). Of course, Gosling came up with a more palatable development language for the next attempt: Java. ------ Original Message ------ >From "josh" To "G. Branden Robinson" Cc "tuhs at tuhs.org" Date 12/25/2022 4:38:32 PM Subject [TUHS] Re: OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) >>Ranging a bit farther afield, I wonder similarly about Sun's NeWS, >>which >>I never saw in the flesh. > >Branden, > >You may find this fellow’s archaeological dig on NeWS and PostScript >interesting: https://twitter.com/rsnous/status/788053163857379328 > >He also attempted to make a NeWS clone: >http://dev.rsnous.com/dewdrop/executive/ (source available). > >Josh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Dec 26 14:18:01 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 25 Dec 2022 21:18:01 -0700 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: <20221225205151.x3kflt7qrjc3b7i4@illithid> References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> Message-ID: On Sun, Dec 25, 2022 at 1:52 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2022-12-25T10:15:19-0800, Michelangelo De Simone wrote: > > The X11 Conservancy Project (X11CP) pulls together the disparate set > > of programs which were being written between the very late 80s, and > > early 90s -- usually for Unix and Linux. > > It looks like this must have just gotten started. All that is present > is xtartan. Which I do at least remember. :) > If you go read their Mastodon feed, you'll see that there's a bunch of others... > Library support is going to be an issue for a lot of X11 legacy apps. > Indeed... There was quite the diversity back in the day... > I remember that the XForms widget library used to be proprietary, and I > recall that it had been freed, but not that this had been done 20 years > ago now[1][2]...albeit still too late to have made itself the center of > the Linux desktop environment, as it could have been if only the > copyright holders had not clung so tightly to The Precious. > Yea, it was one of many early contenders. > Motif and XView similarly got freed (the latter quite early in fact, as > I recall...but night had already fallen for the SunView UI). > Yea, XView was actually free from the start (or almost the start), but the SunView UII and programming model was a bit of a rough fit with X11 and never caught on, even though XView was widely ported. Motif was freed a few years later, in time for it to be used by a few projects before people moved on to things like Gnome and Qt. > But two tooklit variants I've heard of, I've never found out if they > ever made their sources freely available: OLIT and MoOLIT. > Now those are two toolkits I've not heard of in a long time... > As I understand it, OLIT was XView, but written on top of the X Toolkit > Intrinsics library (Xt) as opposed to bypassing it and going straight to > libX11. > Yes. OLIT implemented the OpenLook look and feel in the intrinsics programming model. It shared no code with XView, though. Sun was big on pushing OpenLook back in the day. > And MoOLIT was, apparently, some kind of shim--whether it supplemented > OLIT or replaced it, I am not sure--that, like XForms and Java's AWT, > allowed you to to write a "look-and-feel-neutral" application. > IIRC, and we're reaching back across 30 years at this point, MoOLIT was an attempt to implement both interaction models in one toolkit. > As I recall, such efforts often failed because they abstracted only the > intersection of available features rather than the union of them, so > except for very simple UIs, programs didn't look or behave > "idiomatically" anyway. > Yes. It was a poor implementation of all of them, and only kinda sorta looked right. It was OK for some things, but serious programs had big issues scaling. > I'd be curious to hear people's recollections of these and especially to > learn of any pointers to source. > I never was able to get my hands on binaries, despite trying to order them, let alone sources. They wouldn't ship them to Solbourne for some reason (well, the reason is below). > Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which > I never saw in the flesh. > NeWS was about 3 years before OpenLook, etc. So I spent the 4 years just out of college in my second job at Solboune and later ParkPlace and Openware. I did the OI toolkit and UIB interface builder. It was a C++ toolkit that implemented both Open Looks (both 2d and 3d variants) and Motif. It did it in a neutral manner that allowed better layout than most other toolkits of the time (many other multi-model toolkits had issues where they'd render incorrectly if the fonts changed, or the model added 3d noo-dads that were different sizes for OpenLook and Motif). The interface builder I worked on would allow people to create real programs since it would create the right subclasses for you, allow you to expand the base toolkit either through composition of base objects, or via your own custom widgets. I even engineered the OI giveaway for Linux in the 0.99 days.... But the C++ ABI issues meant it never went anywhere... Sadly, there's little online about this toolkit these days. I found the following, which just gives the business news and no taste of the cool technology: https://techmonitor.ai/technology/att_takes_solbournes_c_object_library_for_designing_user_interfaces https://techmonitor.ai/technology/parcplace_systems_buys_solbournes_c_tool_division and an early paper on the technology before the automatic layout code was added: https://www.semanticscholar.org/paper/Encapsulating-a-C%2B%2B-Library-Linton/2421abe44375dca4620b5dcb1e717f43e2c538a5 It was a cool ride... I can dig up more info if people are interested... Warner > Regards, > Branden > > [1] https://web.archive.org/web/20110718230734/http://xforms-toolkit.org/ > Nowadays its web site does not even mention its proprietary past. > > [2] Before that relicensing, I was part of a team at Progeny Linux > Systems that was contracted by HP to port xforms (and a lot of other > stuff) to IA-64. xforms was given to me because I was "the X guy" > on staff. I don't remember it being difficult--just the usual > long/int punning issues. I don't recollect now whether xforms had > already been ported to Alpha or SPARC V9; it seems to me that it > should have been by 2001, or would have been, had it been FLOSS. > > Great merriment was had in those days dogging on IA-64, but the more > I learned about that ISA the more I liked it compared it to x86, > though that may be damning it with faint praise. But apparently > IA-64 made novel demands with respect to instruction sequencing that > caused compiler writers--or perhaps more accurately the people who > would have to pay compiler writers--squeal like pigs in hot oil. > Intel had a similar "fiasco" with the iAPX 432 fifteen years before; > that was the ISA for which, infamously, "Ada [was the] intended > primary language for application programming." Ada was also > reviled, ostenisbly because it was too damn hard to write a compiler > for it, but probably also because its keyword inventory more closely > resembled Pascal than C, which was already starting to eat the world > in the mid-1980s. Strangely enough, as I understand it, the > compiler innovations demanded by Ada and IA-64, respectively, came > to be standard and expected, and their benefits enjoyed unthinkingly > by x86 and C advocates. Thus do we reward innovation in this > industry. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Dec 26 16:26:24 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 25 Dec 2022 23:26:24 -0700 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> Message-ID: <202212260626.2BQ6QOm6024195@freefriends.org> josh wrote: > > Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which > > I never saw in the flesh. > > Branden, > > You may find this fellow’s archaeological dig on NeWS and PostScript > interesting: https://twitter.com/rsnous/status/788053163857379328 The link there gets to https://github.com/IanDarwin/OpenLookCDROM which has NeWS and a bunch of other stuff. Possibly worth copying into the TUHS archive. Arnold From lars at nocrew.org Mon Dec 26 19:59:28 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 26 Dec 2022 09:59:28 +0000 Subject: [TUHS] X11 Conservancy Project In-Reply-To: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> (Michelangelo De Simone's message of "Sun, 25 Dec 2022 10:15:19 -0800") References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> Message-ID: <7wbknqiiyn.fsf@junk.nocrew.org> Is this limited to X11? The oldest X version I have seen around is X10R3, but rumor has it earlier versions exist on tapes which have not yet been read. We're also missing W. From jon at fourwinds.com Tue Dec 27 05:37:12 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 26 Dec 2022 11:37:12 -0800 Subject: [TUHS] OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) In-Reply-To: <202212260626.2BQ6QOm6024195@freefriends.org> References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> <202212260626.2BQ6QOm6024195@freefriends.org> Message-ID: <202212261937.2BQJbD53508609@darkstar.fourwinds.com> arnold at skeeve.com writes: > josh wrote: > > > > Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which > > > I never saw in the flesh. > > > > Branden, > > > > You may find this fellow’s archaeological dig on NeWS and PostScript > > interesting: https://twitter.com/rsnous/status/788053163857379328 > > The link there gets to https://github.com/IanDarwin/OpenLookCDROM > which has NeWS and a bunch of other stuff. Possibly worth copying > into the TUHS archive. > > Arnold Ah, 'tis the season for old past follies. Somewhere I have an old Christmas card that Dave Lavalle helped me make for James Gosling using NeWS and taking advantage of the color printer that had somehow been justified. I'll scan it when I find it. The text of it was "Merry X-Mess and a Happy NeWS Year". Related to all this, the original PostScript source has recently been made available. My major beef with NeWS was that it perpetuated the awful X input model where everything had to be rectangles. NeWS greatly improved graphics but not input. Being an ancient graphics person, I thought that it should have followed the "pick identifier" model from the traditional (light pen) vector graphics days where identifiers could be associated with objects that were reported when they were selected. NeWS could have done amazing things by adding a pick identifier to the graphics context, and in the PostScript way having that be polymorphic. Would have greatly simplified a lot of user interaction programming to be able to associate a function with an object, and to not have to have a bazillion separate input rectangle for each part of a window border and so on. Jon From pugs78 at gmail.com Tue Dec 27 12:10:17 2022 From: pugs78 at gmail.com (Tom Lyon) Date: Mon, 26 Dec 2022 18:10:17 -0800 Subject: [TUHS] Center 127 directory from 6/17/77 Message-ID: More grist from the scanner. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Center127.pdf Type: application/pdf Size: 95443 bytes Desc: not available URL: From lm at mcvoy.com Tue Dec 27 12:36:52 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Dec 2022 18:36:52 -0800 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: Message-ID: <20221227023651.GZ5825@mcvoy.com> That's a who's who of Unix. I didn't know you were part of that Pugs, I am jealous. I feel fortunate that I got to be part of what I think of as the good Sun, the 4.x days, to me, that felt as close to Bell Labs as you could get in that time. You've lived through a lot. I did twist arms to be lm at sun.com and got to be lm at cs.stanford.edu, I miss lm at sun.com a lot, so short, Unix people like short, it's "ls" not "list". It really was the best part of my career but it is nothing like what I imagine being at the end of an uucp email address ending up at Bell Labs. On Mon, Dec 26, 2022 at 06:10:17PM -0800, Tom Lyon wrote: > More grist from the scanner. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From robpike at gmail.com Tue Dec 27 13:36:32 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 27 Dec 2022 14:36:32 +1100 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: <20221227023651.GZ5825@mcvoy.com> References: <20221227023651.GZ5825@mcvoy.com> Message-ID: Sweet, thanks for that. That was before research!rob arrived, but most of those names were still there when he did. -rob On Tue, Dec 27, 2022 at 1:37 PM Larry McVoy wrote: > That's a who's who of Unix. I didn't know you were part of that Pugs, > I am jealous. I feel fortunate that I got to be part of what I think > of as the good Sun, the 4.x days, to me, that felt as close to Bell Labs > as you could get in that time. > > You've lived through a lot. > > I did twist arms to be lm at sun.com and got to be lm at cs.stanford.edu, I miss > lm at sun.com a lot, so short, Unix people like short, it's "ls" not "list". > It really was the best part of my career but it is nothing like what I > imagine being at the end of an uucp email address ending up at Bell Labs. > > > On Mon, Dec 26, 2022 at 06:10:17PM -0800, Tom Lyon wrote: > > More grist from the scanner. > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From audioskeptic at gmail.com Tue Dec 27 14:51:30 2022 From: audioskeptic at gmail.com (James Johnston) Date: Mon, 26 Dec 2022 20:51:30 -0800 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: <20221227023651.GZ5825@mcvoy.com> Message-ID: Yeah, but Rob, where was Fred? I was there in Acoustics Research (not 127!) then, using R70 for UCDS. I'm pretty sure I distinctly recall Fred Grampp being around then. On Mon, Dec 26, 2022 at 7:38 PM Rob Pike wrote: > Sweet, thanks for that. > > That was before research!rob arrived, but most of those names were still > there when he did. > > -rob > > > On Tue, Dec 27, 2022 at 1:37 PM Larry McVoy wrote: > >> That's a who's who of Unix. I didn't know you were part of that Pugs, >> I am jealous. I feel fortunate that I got to be part of what I think >> of as the good Sun, the 4.x days, to me, that felt as close to Bell Labs >> as you could get in that time. >> >> You've lived through a lot. >> >> I did twist arms to be lm at sun.com and got to be lm at cs.stanford.edu, I >> miss >> lm at sun.com a lot, so short, Unix people like short, it's "ls" not "list". >> It really was the best part of my career but it is nothing like what I >> imagine being at the end of an uucp email address ending up at Bell Labs. >> >> >> On Mon, Dec 26, 2022 at 06:10:17PM -0800, Tom Lyon wrote: >> > More grist from the scanner. >> >> >> >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -- James D. (jj) Johnston Chief Scientist, Immersion Networks -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Dec 27 15:10:49 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 27 Dec 2022 16:10:49 +1100 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: <20221227023651.GZ5825@mcvoy.com> Message-ID: Not in (1)127 yet. He was transferred in some time after I arrived. Not sure quite when. Mid-80s maybe. -rob On Tue, Dec 27, 2022 at 3:53 PM James Johnston wrote: > Yeah, but Rob, where was Fred? I was there in Acoustics Research (not > 127!) then, using R70 for UCDS. > > I'm pretty sure I distinctly recall Fred Grampp being around then. > > On Mon, Dec 26, 2022 at 7:38 PM Rob Pike wrote: > >> Sweet, thanks for that. >> >> That was before research!rob arrived, but most of those names were still >> there when he did. >> >> -rob >> >> >> On Tue, Dec 27, 2022 at 1:37 PM Larry McVoy wrote: >> >>> That's a who's who of Unix. I didn't know you were part of that Pugs, >>> I am jealous. I feel fortunate that I got to be part of what I think >>> of as the good Sun, the 4.x days, to me, that felt as close to Bell Labs >>> as you could get in that time. >>> >>> You've lived through a lot. >>> >>> I did twist arms to be lm at sun.com and got to be lm at cs.stanford.edu, I >>> miss >>> lm at sun.com a lot, so short, Unix people like short, it's "ls" not >>> "list". >>> It really was the best part of my career but it is nothing like what I >>> imagine being at the end of an uucp email address ending up at Bell Labs. >>> >>> >>> On Mon, Dec 26, 2022 at 06:10:17PM -0800, Tom Lyon wrote: >>> > More grist from the scanner. >>> >>> >>> >>> -- >>> --- >>> Larry McVoy Retired to fishing >>> http://www.mcvoy.com/lm/boat >>> >> > > -- > James D. (jj) Johnston > > Chief Scientist, Immersion Networks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Tue Dec 27 23:30:44 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 27 Dec 2022 13:30:44 +0000 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: Message-ID: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> Hi, Tom Lyon, 2C-557, wrote: > More grist from the scanner. Here's the second page ordered by room then name. - I thought quite a few shared, two to an office, but not in this June 1977 list. - John Vollaro office is the Network Lab. - 2C-525 isn't listed; between Bob Morris and Doug McIlroy. - Joe Condon, Belle's co-creator, had two offices. - The secretaries shared, along with ‘UNIX Documentation Specialist’ Miss C. Scrocca. - ‘Patent Consultant’ S. J. Phillips is only on page 1 so perhaps the two pages were maintained manually. 12 4232 - Tucker, Frank E. 1A-324 - 4233 - - Verrico, Mrs. B. 1A-326 1274 6429 - Kaufman, Linda 2C-457 1274 6429 ** Ryan, Ms. D. R. 2C-457 1274 6558 - Blue, James L. 2C-459 1274 2833 - Wamer, Daniel D. 2C-461 1274 2912 - Schryer, Norman L. 2C-462 - 6087 - Network Machine Room 2C-501 - 3445 & 3744 - UNIX Room 2C-502 1273 6321 - Vollaro, John R. 2C-505 - 6087 - Network Lab 2C-505 1270 6694 - Condon, Joseph H. 2C-507 1273 5956 ** Stark, Eugene W. 2C-507 - 3445 & 3744 - Console Room 2C-508 1273 2879 - Elliott, Ruby Jane 2C-511 1273 7419 - Bourne, Stephen R. 2C-512 1271 5970 ** Wing, Ms. Jeannette M. 2C-513 1271 6503 - Baker, Ms. Brenda S. 2C-514 1271 5963 ** Myers, Eugene W. 2C-515 1271 6067 - Cherry, Ms. Lorinda L. 2C-516 1273 3770 - Ritchie, Dennis M. 2C-517 1273 6021 - Kernighan, Brian W. 2C-518 1271 4006 - Sethi, Ravi 2C-519 1273 3685 - Fraser, Alexander G. 2C-520 1271 3520 - Ossanna, Joseph F., Jr. 2C-521 1271 4862 - Aho, Alfred V. 2C-522 1271 2394 - Thompson, Kenneth 2C-523 1271 3878 - W. Morris, Robert 2C-524 1271 6050 - Mcllroy, M. Douglas 2C-526 - 6011 - Library 2C-553 1270 3302 - McMahon, Lee E. 2C-555 1270 6694 - Condon, Joseph H. 2C-556 1273 2761 ** Lyon, T. L. 2C-557 1273 2761 * Mitze, Robert W. 2C-557 1273 7775 - Chesson, Greg L. 2C-558 1273 3968 - Johnson, Stephen C. 2C-559 127 6490 - Morgan, Samuel P. 2C-560 1273 2582 - Pinson, Elliot N. 2C-561 - 6695 - - Marky, Miss Geraldine A. 2C-562 - 6051 - - Marky, Miss Geraldine A. 2C-562 - 6491 - - Chittenden, Ms. Sonia A. 2C-562 - 2583 - - Chittenden, Ms. Sonia A. 2C-562 - 5401 - - Logan, Mrs. Vera G. 2C-562 12 5400 - Prim, Robert C. 2C-563 1274 2059 - Feldman, Stuart I. 2C-570 1274 6377 - Lesk, Michael E. 2C-572 1274 4822 - Brown, W. Stanley 2C-574 - 4823 - - Jones, Mrs. Cleeva Y. 2C-579 - 3303 - - Jones, Mrs. Cleeva Y. 2C-579 7133 7685 - Scrocca, Carmela 2C-579 - 4508 - - Bittrich, Mrs. Mary E. 2C-579 12 4507 - Tukey, John W. 2C-580 - 2574 - - Luciani, Mrs. Dorothy 7E-413 1276 2573 - Terry, Milton E. 7F-502 * Intern from Dept. 5432 ** Summer I recall a rough map of the corridor popping up on this list. -- Cheers, Ralph. From norman at oclsc.org Wed Dec 28 01:10:17 2022 From: norman at oclsc.org (Norman Wilson) Date: Tue, 27 Dec 2022 10:10:17 -0500 (EST) Subject: [TUHS] Center 127 directory from 6/17/77 Message-ID: James Johnston: > Yeah, but Rob, where was Fred? I was there in Acoustics Research (not > 127!) then, using R70 for UCDS. Rob Pike: Not in (1)127 yet. He was transferred in some time after I arrived. Not sure quite when. Mid-80s maybe. ===== Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. Norman Wilson Toronto ON From lm at mcvoy.com Wed Dec 28 01:18:08 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Dec 2022 07:18:08 -0800 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> References: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> Message-ID: <20221227151808.GA5825@mcvoy.com> Well this lines up with my records: slovax$ call ritchie Dennis Ritchie 908-582-3770 (W/bell labs) Same as the extension listed below. Dennis was one of the well known people who taught me that if you had done your homework, he was more than willing to talk to you. I had some question about inodes (I think, it was something in the kernel) and we traded emails for a while and then he sent me his phone number saying "this will be faster". Kind of blew my mind at the time. On Tue, Dec 27, 2022 at 01:30:44PM +0000, Ralph Corderoy wrote: > Hi, > > Tom Lyon, 2C-557, wrote: > > More grist from the scanner. > > Here's the second page ordered by room then name. > > - I thought quite a few shared, two to an office, but not in this > June??1977 list. > - John Vollaro office is the Network Lab. > - 2C-525 isn't listed; between Bob Morris and Doug McIlroy. > - Joe Condon, Belle's co-creator, had two offices. > - The secretaries shared, along with ???UNIX Documentation Specialist??? > Miss C. Scrocca. > - ???Patent Consultant??? S. J. Phillips is only on page 1 so perhaps the > two pages were maintained manually. > > 12 4232 - Tucker, Frank E. 1A-324 > - 4233 - - Verrico, Mrs. B. 1A-326 > 1274 6429 - Kaufman, Linda 2C-457 > 1274 6429 ** Ryan, Ms. D. R. 2C-457 > 1274 6558 - Blue, James L. 2C-459 > 1274 2833 - Wamer, Daniel D. 2C-461 > 1274 2912 - Schryer, Norman L. 2C-462 > - 6087 - Network Machine Room 2C-501 > - 3445 & 3744 - UNIX Room 2C-502 > 1273 6321 - Vollaro, John R. 2C-505 > - 6087 - Network Lab 2C-505 > 1270 6694 - Condon, Joseph H. 2C-507 > 1273 5956 ** Stark, Eugene W. 2C-507 > - 3445 & 3744 - Console Room 2C-508 > 1273 2879 - Elliott, Ruby Jane 2C-511 > 1273 7419 - Bourne, Stephen R. 2C-512 > 1271 5970 ** Wing, Ms. Jeannette M. 2C-513 > 1271 6503 - Baker, Ms. Brenda S. 2C-514 > 1271 5963 ** Myers, Eugene W. 2C-515 > 1271 6067 - Cherry, Ms. Lorinda L. 2C-516 > 1273 3770 - Ritchie, Dennis M. 2C-517 > 1273 6021 - Kernighan, Brian W. 2C-518 > 1271 4006 - Sethi, Ravi 2C-519 > 1273 3685 - Fraser, Alexander G. 2C-520 > 1271 3520 - Ossanna, Joseph F., Jr. 2C-521 > 1271 4862 - Aho, Alfred V. 2C-522 > 1271 2394 - Thompson, Kenneth 2C-523 > 1271 3878 - W. Morris, Robert 2C-524 > 1271 6050 - Mcllroy, M. Douglas 2C-526 > - 6011 - Library 2C-553 > 1270 3302 - McMahon, Lee E. 2C-555 > 1270 6694 - Condon, Joseph H. 2C-556 > 1273 2761 ** Lyon, T. L. 2C-557 > 1273 2761 * Mitze, Robert W. 2C-557 > 1273 7775 - Chesson, Greg L. 2C-558 > 1273 3968 - Johnson, Stephen C. 2C-559 > 127 6490 - Morgan, Samuel P. 2C-560 > 1273 2582 - Pinson, Elliot N. 2C-561 > - 6695 - - Marky, Miss Geraldine A. 2C-562 > - 6051 - - Marky, Miss Geraldine A. 2C-562 > - 6491 - - Chittenden, Ms. Sonia A. 2C-562 > - 2583 - - Chittenden, Ms. Sonia A. 2C-562 > - 5401 - - Logan, Mrs. Vera G. 2C-562 > 12 5400 - Prim, Robert C. 2C-563 > 1274 2059 - Feldman, Stuart I. 2C-570 > 1274 6377 - Lesk, Michael E. 2C-572 > 1274 4822 - Brown, W. Stanley 2C-574 > - 4823 - - Jones, Mrs. Cleeva Y. 2C-579 > - 3303 - - Jones, Mrs. Cleeva Y. 2C-579 > 7133 7685 - Scrocca, Carmela 2C-579 > - 4508 - - Bittrich, Mrs. Mary E. 2C-579 > 12 4507 - Tukey, John W. 2C-580 > - 2574 - - Luciani, Mrs. Dorothy 7E-413 > 1276 2573 - Terry, Milton E. 7F-502 > > * Intern from Dept. 5432 > ** Summer > > > I recall a rough map of the corridor popping up on this list. > > -- > Cheers, Ralph. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From douglas.mcilroy at dartmouth.edu Thu Dec 29 10:36:37 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 28 Dec 2022 19:36:37 -0500 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: <20221227151808.GA5825@mcvoy.com> References: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> <20221227151808.GA5825@mcvoy.com> Message-ID: Trivia: Morris (eventually Pike) was next door to McIlroy. 2C-525 was across the hall; it soon became home to Condon and the cube of uranium he kept in his desk to show people that it's not normally dangerous. Doug On Tue, Dec 27, 2022 at 10:18 AM Larry McVoy wrote: > > Well this lines up with my records: > > slovax$ call ritchie > Dennis Ritchie 908-582-3770 (W/bell labs) > > Same as the extension listed below. > > Dennis was one of the well known people who taught me that if you had > done your homework, he was more than willing to talk to you. I had some > question about inodes (I think, it was something in the kernel) and we > traded emails for a while and then he sent me his phone number saying > "this will be faster". Kind of blew my mind at the time. > > On Tue, Dec 27, 2022 at 01:30:44PM +0000, Ralph Corderoy wrote: > > Hi, > > > > Tom Lyon, 2C-557, wrote: > > > More grist from the scanner. > > > > Here's the second page ordered by room then name. > > > > - I thought quite a few shared, two to an office, but not in this > > June??1977 list. > > - John Vollaro office is the Network Lab. > > - 2C-525 isn't listed; between Bob Morris and Doug McIlroy. > > - Joe Condon, Belle's co-creator, had two offices. > > - The secretaries shared, along with ???UNIX Documentation Specialist??? > > Miss C. Scrocca. > > - ???Patent Consultant??? S. J. Phillips is only on page 1 so perhaps the > > two pages were maintained manually. > > > > 12 4232 - Tucker, Frank E. 1A-324 > > - 4233 - - Verrico, Mrs. B. 1A-326 > > 1274 6429 - Kaufman, Linda 2C-457 > > 1274 6429 ** Ryan, Ms. D. R. 2C-457 > > 1274 6558 - Blue, James L. 2C-459 > > 1274 2833 - Wamer, Daniel D. 2C-461 > > 1274 2912 - Schryer, Norman L. 2C-462 > > - 6087 - Network Machine Room 2C-501 > > - 3445 & 3744 - UNIX Room 2C-502 > > 1273 6321 - Vollaro, John R. 2C-505 > > - 6087 - Network Lab 2C-505 > > 1270 6694 - Condon, Joseph H. 2C-507 > > 1273 5956 ** Stark, Eugene W. 2C-507 > > - 3445 & 3744 - Console Room 2C-508 > > 1273 2879 - Elliott, Ruby Jane 2C-511 > > 1273 7419 - Bourne, Stephen R. 2C-512 > > 1271 5970 ** Wing, Ms. Jeannette M. 2C-513 > > 1271 6503 - Baker, Ms. Brenda S. 2C-514 > > 1271 5963 ** Myers, Eugene W. 2C-515 > > 1271 6067 - Cherry, Ms. Lorinda L. 2C-516 > > 1273 3770 - Ritchie, Dennis M. 2C-517 > > 1273 6021 - Kernighan, Brian W. 2C-518 > > 1271 4006 - Sethi, Ravi 2C-519 > > 1273 3685 - Fraser, Alexander G. 2C-520 > > 1271 3520 - Ossanna, Joseph F., Jr. 2C-521 > > 1271 4862 - Aho, Alfred V. 2C-522 > > 1271 2394 - Thompson, Kenneth 2C-523 > > 1271 3878 - W. Morris, Robert 2C-524 > > 1271 6050 - Mcllroy, M. Douglas 2C-526 > > - 6011 - Library 2C-553 > > 1270 3302 - McMahon, Lee E. 2C-555 > > 1270 6694 - Condon, Joseph H. 2C-556 > > 1273 2761 ** Lyon, T. L. 2C-557 > > 1273 2761 * Mitze, Robert W. 2C-557 > > 1273 7775 - Chesson, Greg L. 2C-558 > > 1273 3968 - Johnson, Stephen C. 2C-559 > > 127 6490 - Morgan, Samuel P. 2C-560 > > 1273 2582 - Pinson, Elliot N. 2C-561 > > - 6695 - - Marky, Miss Geraldine A. 2C-562 > > - 6051 - - Marky, Miss Geraldine A. 2C-562 > > - 6491 - - Chittenden, Ms. Sonia A. 2C-562 > > - 2583 - - Chittenden, Ms. Sonia A. 2C-562 > > - 5401 - - Logan, Mrs. Vera G. 2C-562 > > 12 5400 - Prim, Robert C. 2C-563 > > 1274 2059 - Feldman, Stuart I. 2C-570 > > 1274 6377 - Lesk, Michael E. 2C-572 > > 1274 4822 - Brown, W. Stanley 2C-574 > > - 4823 - - Jones, Mrs. Cleeva Y. 2C-579 > > - 3303 - - Jones, Mrs. Cleeva Y. 2C-579 > > 7133 7685 - Scrocca, Carmela 2C-579 > > - 4508 - - Bittrich, Mrs. Mary E. 2C-579 > > 12 4507 - Tukey, John W. 2C-580 > > - 2574 - - Luciani, Mrs. Dorothy 7E-413 > > 1276 2573 - Terry, Milton E. 7F-502 > > > > * Intern from Dept. 5432 > > ** Summer > > > > > > I recall a rough map of the corridor popping up on this list. > > > > -- > > Cheers, Ralph. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Dec 29 11:12:01 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 29 Dec 2022 01:12:01 +0000 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> <20221227151808.GA5825@mcvoy.com> Message-ID: That reminds me of a story from my lab days. Many years ago worked in a routine environmental lab in receiving at the time and one day we received an errant cooler filled with NORM (low-hazard possibly radioactive soil), complete with yellow and black rad hazard stickers. Being that we weren't a radiological facility, it had some folks quite perturbed. After all, they were bench chemists, not rad experts. Luckily our safety guy had been around the block and then some. He disappears back to the back warehouse for a little while and comes back with a Geiger counter nobody knew we even had. He had a quick lesson with folks, waved the wand over the material showing no detectable counts, and everyone went about their day. The best part of it all was our Geiger counter being "found", we had quite a bit of fun with it later on when a coworker went in for some thyroid work and returned with a throat full of Iodine-131. Several years later I was on an assignment in Richland, WA and had the privilege of some residency at one of our rad facilities at the time. Tying it back to TUHS, they were the only lab in our network that still had an old UNIX box lying around from our pre-Windows days (Sun I think). The technical manager Ken was also quite enthused to show me a bunch of old DEC documentation in a closet. They've since closed. I wish I had been around for that, someone made off with all the "for disposal" tech stuff before I caught wind of it :( - Matt G. P.S. If you're ever flying over the tri-cities area (central WA), try and scope out Hanford from a distance. It's a bit haunting to be honest. The facilities are in a general state of demolition/remediation, then down the way you have the current Columbia River nuclear plant, and a field of who knows what between. Definitely a sight to see for any radiological enthusiasts, I'll make it on one of those tours someday! ------- Original Message ------- On Wednesday, December 28th, 2022 at 4:36 PM, Douglas McIlroy wrote: > Trivia: Morris (eventually Pike) was next door to McIlroy. 2C-525 was > across the hall; it soon became home to Condon and the cube of uranium > he kept in his desk to show people that it's not normally dangerous. > > Doug > > On Tue, Dec 27, 2022 at 10:18 AM Larry McVoy lm at mcvoy.com wrote: > > > Well this lines up with my records: > > > > slovax$ call ritchie > > Dennis Ritchie 908-582-3770 (W/bell labs) > > > > Same as the extension listed below. > > > > Dennis was one of the well known people who taught me that if you had > > done your homework, he was more than willing to talk to you. I had some > > question about inodes (I think, it was something in the kernel) and we > > traded emails for a while and then he sent me his phone number saying > > "this will be faster". Kind of blew my mind at the time. > > > > On Tue, Dec 27, 2022 at 01:30:44PM +0000, Ralph Corderoy wrote: > > > > > Hi, > > > > > > Tom Lyon, 2C-557, wrote: > > > > > > > More grist from the scanner. > > > > > > Here's the second page ordered by room then name. > > > > > > - I thought quite a few shared, two to an office, but not in this > > > June??1977 list. > > > - John Vollaro office is the Network Lab. > > > - 2C-525 isn't listed; between Bob Morris and Doug McIlroy. > > > - Joe Condon, Belle's co-creator, had two offices. > > > - The secretaries shared, along with ???UNIX Documentation Specialist??? > > > Miss C. Scrocca. > > > - ???Patent Consultant??? S. J. Phillips is only on page 1 so perhaps the > > > two pages were maintained manually. > > > > > > 12 4232 - Tucker, Frank E. 1A-324 > > > - 4233 - - Verrico, Mrs. B. 1A-326 > > > 1274 6429 - Kaufman, Linda 2C-457 > > > 1274 6429 ** Ryan, Ms. D. R. 2C-457 > > > 1274 6558 - Blue, James L. 2C-459 > > > 1274 2833 - Wamer, Daniel D. 2C-461 > > > 1274 2912 - Schryer, Norman L. 2C-462 > > > - 6087 - Network Machine Room 2C-501 > > > - 3445 & 3744 - UNIX Room 2C-502 > > > 1273 6321 - Vollaro, John R. 2C-505 > > > - 6087 - Network Lab 2C-505 > > > 1270 6694 - Condon, Joseph H. 2C-507 > > > 1273 5956 ** Stark, Eugene W. 2C-507 > > > - 3445 & 3744 - Console Room 2C-508 > > > 1273 2879 - Elliott, Ruby Jane 2C-511 > > > 1273 7419 - Bourne, Stephen R. 2C-512 > > > 1271 5970 ** Wing, Ms. Jeannette M. 2C-513 > > > 1271 6503 - Baker, Ms. Brenda S. 2C-514 > > > 1271 5963 ** Myers, Eugene W. 2C-515 > > > 1271 6067 - Cherry, Ms. Lorinda L. 2C-516 > > > 1273 3770 - Ritchie, Dennis M. 2C-517 > > > 1273 6021 - Kernighan, Brian W. 2C-518 > > > 1271 4006 - Sethi, Ravi 2C-519 > > > 1273 3685 - Fraser, Alexander G. 2C-520 > > > 1271 3520 - Ossanna, Joseph F., Jr. 2C-521 > > > 1271 4862 - Aho, Alfred V. 2C-522 > > > 1271 2394 - Thompson, Kenneth 2C-523 > > > 1271 3878 - W. Morris, Robert 2C-524 > > > 1271 6050 - Mcllroy, M. Douglas 2C-526 > > > - 6011 - Library 2C-553 > > > 1270 3302 - McMahon, Lee E. 2C-555 > > > 1270 6694 - Condon, Joseph H. 2C-556 > > > 1273 2761 ** Lyon, T. L. 2C-557 > > > 1273 2761 * Mitze, Robert W. 2C-557 > > > 1273 7775 - Chesson, Greg L. 2C-558 > > > 1273 3968 - Johnson, Stephen C. 2C-559 > > > 127 6490 - Morgan, Samuel P. 2C-560 > > > 1273 2582 - Pinson, Elliot N. 2C-561 > > > - 6695 - - Marky, Miss Geraldine A. 2C-562 > > > - 6051 - - Marky, Miss Geraldine A. 2C-562 > > > - 6491 - - Chittenden, Ms. Sonia A. 2C-562 > > > - 2583 - - Chittenden, Ms. Sonia A. 2C-562 > > > - 5401 - - Logan, Mrs. Vera G. 2C-562 > > > 12 5400 - Prim, Robert C. 2C-563 > > > 1274 2059 - Feldman, Stuart I. 2C-570 > > > 1274 6377 - Lesk, Michael E. 2C-572 > > > 1274 4822 - Brown, W. Stanley 2C-574 > > > - 4823 - - Jones, Mrs. Cleeva Y. 2C-579 > > > - 3303 - - Jones, Mrs. Cleeva Y. 2C-579 > > > 7133 7685 - Scrocca, Carmela 2C-579 > > > - 4508 - - Bittrich, Mrs. Mary E. 2C-579 > > > 12 4507 - Tukey, John W. 2C-580 > > > - 2574 - - Luciani, Mrs. Dorothy 7E-413 > > > 1276 2573 - Terry, Milton E. 7F-502 > > > > > > * Intern from Dept. 5432 > > > ** Summer > > > > > > I recall a rough map of the corridor popping up on this list. > > > > > > -- > > > Cheers, Ralph. > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From mah at mhorton.net Fri Dec 30 14:00:04 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 29 Dec 2022 20:00:04 -0800 Subject: [TUHS] Center 127 directory from 6/17/77 In-Reply-To: References: <20221227133044.B12D41F9AA@orac.inputplus.co.uk> <20221227151808.GA5825@mcvoy.com> Message-ID: I was born in Richland, company town for Hanford. It had the same nuclear technology as Chernobyl. Some would say that explains a lot. :) Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! On 12/28/22 17:12, segaloco via TUHS wrote: > P.S. If you're ever flying over the tri-cities area (central WA), try and scope out Hanford from a distance. It's a bit haunting to be honest. The facilities are in a general state of demolition/remediation, then down the way you have the current Columbia River nuclear plant, and a field of who knows what between. Definitely a sight to see for any radiological enthusiasts, I'll make it on one of those tours someday! -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Dec 31 00:43:55 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 30 Dec 2022 09:43:55 -0500 Subject: [TUHS] Center 127 directory from 6/17/77 Message-ID: > James Johnston: >> Yeah, but Rob, where was Fred? I was there in Acoustics Research (not >> 127!) then, using R70 for UCDS. > Rob Pike: > Not in (1)127 yet. He was transferred in some time after I arrived. Not > sure quite when. Mid-80s maybe. > ===== > Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. > Norman Wilson In 1980 Fred was a stalwart of the computer center. There he exhibited great creativity, including the invention of "quest" for sniffing out security lapses throughout the BTL computer network. His findings underpinned the headline claim of the Labs' first computer-security task force (1982), "It is easy and not very risky to pilfer data from Bell Labs computers". Doug From pnr at planet.nl Sat Dec 31 04:24:16 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:24:16 +0100 Subject: [TUHS] Fwd: Early Unix on (64-bit) Risc-V References: Message-ID: During the past year I’ve worked on and off on porting Sys III. My approach to studying ancient Unix is to port it to a new system, as that forces one to consider many of the design trade-offs in a code base. For 16 bit Unix I used the TI990 as a target, for the 1980-1985 period I was thinking about a 68030 based board. However, in the end using a Riscv based target seemed more interesting and that is what I used (more specifically the 64-bit Allwinner D1 chip, for which several cheap boards are available, along with Fabrice Ballard’s TinyEMU for simulation). In general, my approach was to first select a toolchain and I settled on the Plan9 compiler suite, with the Riscv backend as done by Richard Miller, used together with a library that enabled using this tool chain on modern Unix. This I then used to port the educational XV6 system to the D1 chip, building on work done by Michael Engel. From there I ported the SysIII kernel (reusing some bits of XV6 memory code), initially using the XV6 user land. From there I went on to port the original SysIII user land. Much to my surprise, the original SysIII code can support the Plan 9 tool chain, just a dozen standard libc routines needed to be added to give this SysIII port a native compiler. There is a lot to report, and I will split it over several posts covering different aspects. I hope that this will not be perceived as spamming this list. The topics are: 1. Riscv, Plan-9 and a toolchain 2. Porting the SysIII kernel: first steps & memory management 3. Porting the SysIII kernel: boot, config & device drivers 4. A few comments on porting the Bourne shell 5. Xv6, Linux and SysIII on a RV32 FPGA system For those who just want to see the results, the tool chain is here: https://gitlab.com/pnru/riscv-kencc And the SysIII port is here: https://gitlab.com/pnru/SysIII_rv64 > Begin forwarded message: > > From: Paul Ruizendaal > Subject: Early Unix on (64-bit) Risc-V > Date: December 22, 2022 at 11:55:04 AM GMT+1 > To: The Eunuchs Hysterical Society > Cc: athornton at gmail.com, davida at pobox.com, luther at makerlisp.com > > > Adam Thorton wrote: > >> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. >> >> The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. >> >> Having said that...maybe what I really want is 64-bit 4.3 BSD? >> >> I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. > > Luther Johnson wrote: > >> I'm in the process of building a system like that for myself, but >> perhaps a little smaller - mine will be based on an embedded >> microprocessor I've developed (so much work still yet to do ! at least a >> year out). > > Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal. > > It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats). > > The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true. > > The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents. > > My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list. > > === > > David Arnold wrote: > >> I think xv6 does SMP? (param.h says NCPU = 8, at least). >> >> You’d need to add a network stack and a userland, but there are options for those … > > For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.). > > As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained. > > In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Dec 31 04:25:01 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:25:01 +0100 Subject: [TUHS] Riscv, Plan-9 and a toolchain Message-ID: After initially gearing up to use the Motorola 68020 or 68030 as a porting target for a study of Unix in the 1980-1985 era, I reconsidered and used Risc-V as a target instead. As the original RISC and MIPS projects were contemporaneous with early 32-bit Unix (32V, BSD, SysIII and SVr1,r2) it seems appropriate and there is currently considerable interest (hype?) around Risc-V. From a programming perspective, the Risk-V ISA does not feel (at least to me) all that different from what was current in the early 80’s — the number of WTFs/min is low. The modularity is a pleasant surprise, as is the observation that the 32-bit and 64-bit instruction sets are almost identical and that compressed instructions mingle nicely with full size ones. The MMU design appears straightforward. Maybe this is because the ISA is still relatively new and has not acquired much historical baggage at this point in its lifespan, but it also seems to be a good synthesis of insights gained over the last 4 decades and applied with a sense of minimalism. At first I was thinking to create a toolchain based on pcc or pcc2 for the SysIII porting effort, based on some preparation I had done when I was still thinking about 68030 as a target (the surviving Blit code includes a pcc-based 68000 compiler and the SysV/68 source archive contains a pcc2-based compiler). Before I got underway with that, I came across a presentation Richard Miller had done about his Risc-V compiler: https://riscv.org/news/2020/10/a-plan-9-c-compiler-for-rv32gc-and-rv64gc/ Richard was kind enough to share the source code for his Risc-V back-end. The first complication was that the source code assumes that it will be running inside a Plan-9 environment, whereas I was looking for a Unix/Posix environment. Luckily somebody already had assembled the libraries needed for this: https://github.com/aryx/fork-kencc I’m not sure where it came from, but I would assume it has some roots in the "Plan-9 from user space" effort. From this work I extracted the minimum needed to get the C compiler working and to build from scratch. The libraries mostly just worked. The compiler was a bit harder: the source code assumes a LLP64 model in a few places and compiling this with clang (which uses a LP64 model) introduces issues in a handful of places. Other than this initial hurdle, the compiler and tools have worked flawlessly, both for 64-bit code and for 32-bit code, and have been a joy to use. One particular nicety is that Plan 9 style "abstract assembler" source for 64-bit code is even more identical to its 32-bit variant than with the mainstream Risc-V assembler syntax. My repo for the tool chain is here: https://gitlab.com/pnru/riscv-kencc Initially, my expectation was that I could only use these compilers as cross-compilers and that I would need to do a pcc2 version for native compilation at some point. However, when I saw how small and fast the tools were, I experimented with using them on SysIII. Much to my surprise the effort required was absolutely minimal, all that was needed was adding a dozen simple standard functions in libc (see here: https://gitlab.com/pnru/SysIII_rv64/-/tree/master/libc/compat) and adding the ‘dup2' sys call. I had not expected that SysIII was so close to the Unix systems of the 1990’s in this regard. This result inspires ideas for future projects: as I plan to add an 8th edition style file system switch anyway, maybe it will not be all that hard to make the Plan-9 debugger work on this “SysIII+” as well. Another observation has been that the code size of binaries compiled for Risc-V by this tool chain is almost the same as those compiled for the VAX by pcc (the Risc-V ones are maybe 10-20% larger). This is using the compressed instructions where possible. This is I think another indication that both the Risc-V ISA and the tool chain are quite well done. The one less positive surprise has been the memory use of the compiler. Even on a relatively simple program file it will quickly use 1 megabyte or more of ram. I understood from Richard that this is because the compiler only malloc()’s and never free()’s by design. This has been a mixed blessing. Such large memory images don’t work all that well with the "scatter paging + partial swapping" memory management of SysIII when memory is constrained to say 4MB of core to mimic the systems of the era. On the other hand, parallel compiling the kernel on SysIII itself heavily exercises the partial swapping code and has been a great test case for debugging. Many thanks to Ken, Rob, Richard and all the others who created this fine tool chain! From pnr at planet.nl Sat Dec 31 04:25:18 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:25:18 +0100 Subject: [TUHS] Porting the SysIII kernel: first steps & memory management Message-ID: <4A7EBAFB-CF48-45CF-9609-A9DF924AF299@planet.nl> Porting the SysIII kernel to a D1 board (https://www.aliexpress.us/item/3256803408560538.html) began with a port of XV6, in order to test the tool chain and to get comfortable with this target. Michael Engel had already ported XV6 to the D1 chip a few months before (https://www.uni-bamberg.de/fileadmin/sysnap/slides/xv6-riscv.pdf), giving a ready base to work with. The main new effort was to add code to initialise the DRAM controller and the SD Card interface, and to have a simple boot loader. Such code is available from the manufacturer board support package (BSP), although in this case the DRAM controller code was only available as assembler compiler output and had to be reverse engineered back into C. In general I was surprised to see how big and unwieldy the BSP code is; maybe the code just looks sloppy because it has to deal with all kinds of edge cases - but I can also imagine that it accumulates cruft as it is ported from SoC to SoC by the manufacturer. The resulting XV6 source tree is here: https://gitlab.com/pnru/xv6-d1 This version automatically boots from the SD Card on the board. With that out of the way, the ancient Unix port was relatively easy. It would seem to me that the SysIII code base has a lot of clean-up work in it that still pays off today. The code compiles to a 64-bit target with minimal updates, which I think is a compliment to the engineers that worked on it. Probably using a LLP64 compiler also helped. In order to bring something up quickly, I modified the kernel to load ELF binaries, so that I could use proven material from the XV6 port (such as a minimalistic init and shell). Initially, I just replaced VAX memory management with page table code taken from XV6 (i.e. no VM or swapping). Working with Risc-V page tables gives much simpler code, but I have a deeper appreciation of the VAX paging design now: for the type of code that was run in 1980, the VAX design enables very small page tables with just a few dozen entries. In contrast, for the 3-level page tables of 64-bit Risc-V I end up with 7 pages of page table of 4KB each, or 28KB -- that is larger than the memory image of many SysIII programs. If I move the ‘trampoline' to just above the stack in virtual memory it could be 5 pages instead of 7, but the overall picture remains the same. The 68020 or ‘030 MMU could be configured to have various page sizes -- this looked byzantine to me when I first saw it, but it makes more sense now. Next I replaced the VAX scatter paging / partial swapping code, keeping the same methodology. I noticed that there is still confusion over memory management in 32V and SysIII (and implicitly SVR1,R2). The original 32V as described in the London/Reiser paper used V7 style swapping. This code can be found as ‘slowsys’ in the surviving source (https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/slowsys). It was quickly (Mar vs. Jan 1979) replaced by the scatter loading / partial swapping design already hinted at in the paper (source is in 32V/usr/src/sys). Unfortunately, the “32V uses V7 swapping” meme lives on. In scatter paging, the pages are no longer allocated continuous in physical memory but new pages are taken from a free list and expansion swaps are not usually needed. Also, when a process is swapped out, it is not fully swapped out, but just enough pages to make room for the new process. When it is readied to run again, only the partial set needs to be reloaded. In the VAX context, scatter paging and partial swapping are quite effective and I think competitive with demand paging for the 25-100KB processes that were in use at the time. As I mentioned in the post on the toolchain, the Plan 9 C compiler can easily use 1MB of memory and in a 4MB of core context, this trashes the algorithm; it starts to behave much like traditional swapping. The reason for this is that the entire process must be in memory in order to be able to run and the algorithm cannot recognise that a much smaller working set is needed. The implicit assumption of small processes can also be seen in the choice to limit partial swaps to 4KB per iteration (8 VAX pages). For handling processes with a large memory footprint but a small working set a true demand paged VM approach is needed. The simplest such approach appears to be Richard Miller’s work for SVR1 (see June 1984 Usenix conference proceedings, "A Demand Paging Virtual Memory Manager for System V"). This is a very light touch implementation of demand paging and it seems that enough bits and pieces survive to recreate it. The journey through the memory code made it clear again that in SysIII and before, the memory code is scattered over several locations and not so easy to fathom at first glance. It would seem that in SysV/68 an attempt was made to organise the code into separate files and with a more defined API. It does not seem to have carried through. Maybe this was because the MMU’s of the 1980-1985 era were all too different to be efficiently abstracted into a single framework. Beyond SysV/68, were there any other attempts in the early 80’s to organise and abstract the kernel memory management code (outside BSD)? From pnr at planet.nl Sat Dec 31 04:25:43 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:25:43 +0100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers Message-ID: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> As mentioned in the first post on SysIII porting, I was surprised to see how much code was needed to initialise modern hardware and to load an OS. Of course, modern devices are much more capable than the ones of 40 years ago, so maybe my surprise is misplaced. It did raise an interest in the history of Unix system configuration though. It would seem that 5th Edition already contained a configuration program that generated a few system tables and the ‘low.s’ file with interrupt vectors and alike. Although it steadily grew in sophistication, the approach appears still the same in SysIII. I suppose this is all in line with common practice of the era, with OS’s typically having a ’system generation kit' to combine the pre-linked OS kernel with device drivers and system tables. SysIII also introduces the "var struct" and the “v” kernel variable that summarises some of the system configuration. I’m not sure whether it has roots in earlier Unix systems, it does not seem to originate from Research. I’m not sure what the point of this ‘v’ kernel variable was. Does anybody remember? One could argue that one of the drivers of the success of CP/M in the 1970’s was due to its clear separation between the boot rom, BIOS and BDOS components. As far as I am aware, Unix prior to 1985 did never attempt to separate the device drivers from the other kernel code. I am not very familiar with early Xenix, it could be that Microsoft had both the skill and the interest to separate Xenix in a standard binary (i.e. BDOS part) and a device driver binary (i.e. BIOS part). Maybe the differences in MMU for the machines of the early 80’s were such that a standard binary could not be done anyway and separating out the device drivers would serve no purpose. Once the PC became dominant, maybe the point became moot for MS. It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition? Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot? From pnr at planet.nl Sat Dec 31 04:25:55 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:25:55 +0100 Subject: [TUHS] A few comments on porting the Bourne shell Message-ID: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. There were three aspects that I found noteworthy: 1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value: /* the following nonsense is required * because casts turn an Lvalue * into an Rvalue so two cheats * are necessary, one for each context. */ union { int _cheat;}; #define Lcheat(a) ((a)._cheat) #define Rcheat(a) ((int)(a)) However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C. 2. On the history of dup2 The shell code includes the following: rename(f1,f2) REG INT f1, f2; { #ifdef RES /* research has different sys calls from TS */ IF f1!=f2 THEN dup(f1|DUPFLG, f2); close(f1); IF f2==0 THEN ioset|=1 FI FI #else INT fs; IF f1!=f2 THEN fs = fcntl(f2,1,0); close(f2); fcntl(f1,0,f2); close(f1); IF fs==1 THEN fcntl(f2,2,1) FI IF f2==0 THEN ioset|=1 FI FI #endif } I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices. 3. Halfway to demand paging I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically: VOID fault(sig) REG INT sig; { signal(sig, fault); IF sig==MEMF THEN IF setbrk(brkincr) == -1 THEN error(nospace); FI ELIF ... This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling. From pnr at planet.nl Sat Dec 31 04:26:28 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 30 Dec 2022 19:26:28 +0100 Subject: [TUHS] Xv6, Linux and SysIII on a RV32 FPGA system Message-ID: <7C246577-E12E-4C15-B912-7EB9AABAC700@planet.nl> Having done the SysIII 64-bit port to a recent Risc-V chip, I realised that whilst it is an interesting exercise bij itself -- and maybe even useful to students and educators around the world -- it is not ideal as a research tool for analysing Unix from the early 80’s. The address size difference adds some superfluous porting, and the 100x speed difference can hide critical algorithm constraints. Also the complex IO devices are out of character. For a Risc-V 32 bit target I’ve settled on an FPGA implementation from the University of Tokyo. I’ve somewhat modified the system to work with the open source Yosys/NextPNR tool chain. It now implements a Linux-capable SoC with a full MMU, a 4-way cache and SD card driver in less than 4,000 lines of plain Verilog (compiling to about 14K LUTs). In a way, the code has a 6th edition feel to it: it covers a real and usable system and the code can be understood in a couple of days -- or a semester for a student who is new to the concepts involved. https://gitlab.com/r1809/rvsoc/-/tree/main/doc So far I have Linux and XV6 (https://gitlab.com/r1809/xv6-rv32) running, but have not started on SysIII yet. Usefully for my use case this system is not very fast, completing an instruction in on average 10 clocks. Still, when running at 40MHz it is about 2 or 3 times as fast as a VAX11/780, which is similar to the systems of the mid-80’s. Even at this speed, a single user console Linux is surprisingly usable. By the way, funny to realise that ‘Unix/Linux capable’ has been a marketing slogan for system capability for 40 years now. There is a short video clip with a demonstration (but running at 100MHz) here: https://youtu.be/Kt_iXVAjXcQ Due to its simple design, the main CPU only uses some 30% of the cache memory bandwidth and it should not be all that hard to add a second CPU to the system (the CPU already supports the Risc-V atomic operations), and this could be a nice target for studying the early Unix multi-processor designs (e.g. VAX/BSD & 3B2/SVR3). I find it an intriguing thought that the chip technology of the early 80’s (let’s say the technology used for the Bellmac-32 or M68K) would probably have sufficed to build a CPU similar to the one used in this FPGA design. As the topic of this post is on a tangent from the focus of this list, I would recommend that any follow-ups not related to the history of Unix are sent off list. From usotsuki at buric.co Sat Dec 31 04:56:35 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 30 Dec 2022 13:56:35 -0500 (EST) Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Fri, 30 Dec 2022, Paul Ruizendaal wrote: > One could argue that one of the drivers of the success of CP/M in the > 1970’s was due to its clear separation between the boot rom, BIOS and > BDOS components. As far as I am aware, Unix prior to 1985 did never > attempt to separate the device drivers from the other kernel code. I am > not very familiar with early Xenix, it could be that Microsoft had both > the skill and the interest to separate Xenix in a standard binary (i.e. > BDOS part) and a device driver binary (i.e. BIOS part). Maybe the > differences in MMU for the machines of the early 80’s were such that a > standard binary could not be done anyway and separating out the device > drivers would serve no purpose. Once the PC became dominant, maybe the > point became moot for MS. Certainly Microsoft *did* have an operating system, as early as 1981, that had the concept of separated BIOS and BDOS, but they didn't write it, they bought it 🤪 That said, given that it existed in MS-DOS, I can't imagine it wouldn't have been impossible to also implement in Xenix... -uso. From tuhs at tuhs.org Sat Dec 31 05:50:35 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 30 Dec 2022 19:50:35 +0000 Subject: [TUHS] Fwd: Early Unix on (64-bit) Risc-V In-Reply-To: References: Message-ID: Wow you beat me to the punch on this...I've been speccing out either a SysIII or SysV port to RISC-V, I've got a VisionFive 1 with a JH7100 core I've been tinkering with some systems design stuff on and have been porting little bits and pieces of UNIX kernel code to. I'll look this all over and see how far I can get this on my VisionFive. If all goes swimmingly, maybe I don't need to work on my 4.x restoration in SimH, I could just layer it on top of this and develop/test using real hardware. I'm sure I'll have some feedback once I digest your various missives, this is awesome stuff, thanks for sharing Paul! - Matt G. ------- Original Message ------- On Friday, December 30th, 2022 at 10:24 AM, Paul Ruizendaal wrote: > During the past year I’ve worked on and off on porting Sys III. My approach to studying ancient Unix is to port it to a new system, as that forces one to consider many of the design trade-offs in a code base. For 16 bit Unix I used the TI990 as a target, for the 1980-1985 period I was thinking about a 68030 based board. However, in the end using a Riscv based target seemed more interesting and that is what I used (more specifically the 64-bit Allwinner D1 chip, for which several cheap boards are available, along with Fabrice Ballard’s TinyEMU for simulation). > > In general, my approach was to first select a toolchain and I settled on the Plan9 compiler suite, with the Riscv backend as done by Richard Miller, used together with a library that enabled using this tool chain on modern Unix. This I then used to port the educational XV6 system to the D1 chip, building on work done by Michael Engel. From there I ported the SysIII kernel (reusing some bits of XV6 memory code), initially using the XV6 user land. From there I went on to port the original SysIII user land. Much to my surprise, the original SysIII code can support the Plan 9 tool chain, just a dozen standard libc routines needed to be added to give this SysIII port a native compiler. > > There is a lot to report, and I will split it over several posts covering different aspects. I hope that this will not be perceived as spamming this list. The topics are: > > 1. Riscv, Plan-9 and a toolchain > > 2. Porting the SysIII kernel: first steps & memory management > > 3. Porting the SysIII kernel: boot, config & device drivers > > 4. A few comments on porting the Bourne shell > > 5. Xv6, Linux and SysIII on a RV32 FPGA system > > For those who just want to see the results, the tool chain is here: > > https://gitlab.com/pnru/riscv-kencc > > And the SysIII port is here: > > https://gitlab.com/pnru/SysIII_rv64 > >> Begin forwarded message: >> >> From: Paul Ruizendaal >> Subject: Early Unix on (64-bit) Risc-V >> >> Date: December 22, 2022 at 11:55:04 AM GMT+1 >> To: The Eunuchs Hysterical Society >> Cc: athornton at gmail.com, davida at pobox.com, luther at makerlisp.com >> >> Adam Thorton wrote: >> >>> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. >>> >>> The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. >>> >>> Having said that...maybe what I really want is 64-bit 4.3 BSD? >>> >>> I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. >> >> Luther Johnson wrote: >> >>> I'm in the process of building a system like that for myself, but >>> perhaps a little smaller - mine will be based on an embedded >>> microprocessor I've developed (so much work still yet to do ! at least a >>> year out). >> >> Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal. >> >> It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats). >> >> The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true. >> >> The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents. >> >> My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list. >> >> === >> >> David Arnold wrote: >> >>> I think xv6 does SMP? (param.h says NCPU = 8, at least). >>> >>> You’d need to add a network stack and a userland, but there are options for those … >> >> For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.). >> >> As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained. >> >> In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sat Dec 31 05:51:26 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 30 Dec 2022 14:51:26 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> Message-ID: <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> On 12/30/22 1:25 PM, Paul Ruizendaal wrote: > > London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. Have you read http://www.collyer.net/who/geoff/sh.tour.pdf and looked at http://www.collyer.net/who/geoff/v7sh.tar ? In the limited literature on Bourne Shell porting, this is authoritative. Arnold Robbins built on that work and ported the v8-v10 shells to modern Linux versions. (I am sorry, I do not have a link right now.) -- ``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 Sat Dec 31 05:57:27 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 30 Dec 2022 19:57:27 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> Message-ID: I'll have to double check later but I'm fairly certain the remaining L/R cheats are gone by SysV. From what I can tell much of that portability work may have been done prior to the V7 release code base we're familiar with, as I did some comparison and found only one significant change between V7 and 32V code as I know it at least. Either the claims of portability issues came between 32V and System III (meaning the shell was accepted as "broken"? in 32V) or the code we actually see in V7 has already been tidied up significantly and doesn't represent the "non-portable" version lamented in the famous quote. Does this observation hold with reality? Is there an earlier, more PDP-11 bound version of the Bourne Shell out there? I seem to recall reading something about some bits of it even being in assembly at one point, but can't remember the quote source. - Matt G. ------- Original Message ------- On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal wrote: > London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. > > There were three aspects that I found noteworthy: > > 1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value: > > > > /* the following nonsense is required > * because casts turn an Lvalue > * into an Rvalue so two cheats > * are necessary, one for each context. > */ > union { int _cheat;}; > #define Lcheat(a) ((a)._cheat) > #define Rcheat(a) ((int)(a)) > > > > However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C. > > 2. On the history of dup2 > > The shell code includes the following: > > > > rename(f1,f2) > REG INT f1, f2; > { > #ifdef RES /* research has different sys calls from TS */ > IF f1!=f2 > THEN dup(f1|DUPFLG, f2); > close(f1); > IF f2==0 THEN ioset|=1 FI > FI > #else > INT fs; > IF f1!=f2 > THEN fs = fcntl(f2,1,0); > close(f2); > fcntl(f1,0,f2); > close(f1); > IF fs==1 THEN fcntl(f2,2,1) FI > IF f2==0 THEN ioset|=1 FI > FI > #endif > } > > > > I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices. > > 3. Halfway to demand paging > > I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically: > > > > VOID fault(sig) > REG INT sig; > { > signal(sig, fault); > IF sig==MEMF > THEN IF setbrk(brkincr) == -1 > THEN error(nospace); > FI > ELIF ... > > > > This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling. > From lm at mcvoy.com Sat Dec 31 06:02:46 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 30 Dec 2022 12:02:46 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: <20221230200246.GW5825@mcvoy.com> On Fri, Dec 30, 2022 at 02:51:26PM -0500, Chet Ramey wrote: > On 12/30/22 1:25 PM, Paul Ruizendaal wrote: > > > >London and Reiser report about porting the shell that ???it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.??? By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. > > Have you read > > http://www.collyer.net/who/geoff/sh.tour.pdf > > and looked at http://www.collyer.net/who/geoff/v7sh.tar ? > > In the limited literature on Bourne Shell porting, this is authoritative. Is there are reason to hang on to the Bourne shell? Maybe shell scripts? Does it perform better than ksh or bash? Don't get me wrong, I much prefer the sh syntax over csh syntax, but I'd never go back to the Bourne shell as my login shell. Way too much useful stuff in ksh/bash. From mascheck at in-ulm.de Sat Dec 31 06:20:28 2022 From: mascheck at in-ulm.de (Sven Mascheck) Date: Fri, 30 Dec 2022 21:20:28 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: Chet Ramey on 30.12.2022 20:51: > Arnold Robbins built on that work and ported the v8-v10 shells to modern > Linux versions. (I am sorry, I do not have a link right now.) And btw, 8th ed (http://man.cat-v.org/unix_8th/1/sh) even added a simple history mechanism with the "=(1)" command (https://www.in-ulm.de/~mascheck/bourne/v8/=.html). Sven From luther at makerlisp.com Sat Dec 31 06:31:46 2022 From: luther at makerlisp.com (Luther Johnson) Date: Fri, 30 Dec 2022 13:31:46 -0700 Subject: [TUHS] Fwd: Early Unix on (64-bit) Risc-V In-Reply-To: References: Message-ID: Awesome ! I'll particularly be reading your thoughts on the Plan 9 tool chain with interest. Thanks for all of this ! On 12/30/2022 11:24 AM, Paul Ruizendaal wrote: > During the past year I’ve worked on and off on porting Sys III. My > approach to studying ancient Unix is to port it to a new system, as > that forces one to consider many of the design trade-offs in a code > base. For 16 bit Unix I used the TI990 as a target, for the 1980-1985 > period I was thinking about a 68030 based board. However, in the end > using a Riscv based target seemed more interesting and that is what I > used (more specifically the 64-bit Allwinner D1 chip, for which > several cheap boards are available, along with Fabrice Ballard’s > TinyEMU for simulation). > > In general, my approach was to first select a toolchain and I settled > on the Plan9 compiler suite, with the Riscv backend as done by Richard > Miller, used together with a library that enabled using this tool > chain on modern Unix. This I then used to port the educational XV6 > system to the D1 chip, building on work done by Michael Engel. From > there I ported the SysIII kernel (reusing some bits of XV6 memory > code), initially using the XV6 user land. From there I went on to port > the original SysIII user land. Much to my surprise, the original > SysIII code can support the Plan 9 tool chain, just a dozen standard > libc routines needed to be added to give this SysIII port a native > compiler. > > There is a lot to report, and I will split it over several posts > covering different aspects. I hope that this will not be perceived as > spamming this list. The topics are: > > 1. Riscv, Plan-9 and a toolchain > > 2. Porting the SysIII kernel: first steps & memory management > > 3. Porting the SysIII kernel: boot, config & device drivers > > 4. A few comments on porting the Bourne shell > > 5. Xv6, Linux and SysIII on a RV32 FPGA system > > For those who just want to see the results, the tool chain is here: > > https://gitlab.com/pnru/riscv-kencc > > And the SysIII port is here: > > https://gitlab.com/pnru/SysIII_rv64 > > >> Begin forwarded message: >> >> *From: *Paul Ruizendaal > >> *Subject: **Early Unix on (64-bit) Risc-V* >> *Date: *December 22, 2022 at 11:55:04 AM GMT+1 >> *To: *The Eunuchs Hysterical Society > > >> *Cc: *athornton at gmail.com , >> davida at pobox.com , luther at makerlisp.com >> >> >> >> Adam Thorton wrote: >> >>> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP >>> support, a screen editor, and SMP support. >>> >>> The third one is a solved problem. The second one would not be that >>> hard to adapt, say, uIP 0.9, to v7. That first one would require >>> some work with C type sizes, but getting larger is easier than the >>> reverse. It's that last one. >>> >>> Having said that...maybe what I really want is 64-bit 4.3 BSD? >>> >>> I mean, just a Unix, without all the cruft of a modern Linux, but >>> which can actually take advantage of the resources of a modern >>> machine. I don't care about a desktop, or even a graphical >>> environment, I don't care about all the strange syscalls that are >>> there to support particular databases, I don't care much about being >>> a virtualization host. >> >> Luther Johnson wrote: >> >>> I'm in the process of building a system like that for myself, but >>> perhaps a little smaller - mine will be based on an embedded >>> microprocessor I've developed (so much work still yet to do ! at >>> least a >>> year out). >> >> Earlier this year I ported VAX System III to Risc-V, to a simple >> Allwinner D1 based SBC. This is RV64GC. Just ported to the console >> terminal. >> >> It turned out that porting Sys III to 64 bit was surprisingly easy, >> most of the kernel and user land appears to be 64 bit clean. It helps >> that I am using a LLP64 compiler, though. Apart from networking Sys >> III also feels surprisingly modern (for an ancient Unix) - its should >> get more attention than it does. The hardest work was in porting the >> VAX memory code to Risc-V page tables (and to a lesser extent, >> updating libc for the different FP formats). >> >> The code is currently in an ugly state (with debug stuff in >> commented-out blocks, a mix of ansi and K&R styles, an incoherent >> kludgy build system, etc.) and the shame stopped me from putting it >> out on gitlab until I found enough time to clean this up. As there >> seems to be some interest now, I’ll put it up anyway in the next week >> or so. There you go Adam, half your wish comes true. >> >> The kernel is about 60KB and most binaries are quite close in size to >> the VAX equivalents. >> >> My next goals for it are to re-implement the Reiser demand paging (I >> think I have a good enough view of how that worked, but the proof of >> the pudding will be in the eating), and to add TCP/IP networking, >> probably the BBN stack. Making it work on RV32 and exploring early >> SMP work is also on my interest list. >> >> === >> >> David Arnold wrote: >> >>> I think xv6 does SMP? (param.h says NCPU = 8, at least). >>> >>> You’d need to add a network stack and a userland, but there are >>> options for those … >> >> For the above, making xv6 work on the D1 board was my first stepping >> stone, to proof the tool chain and to get the basics right (hardware >> init, low-level I/O, etc.). >> >> As an educational tool, I am sure that xv6 hits all the right spots, >> and it certainly does SMP (the D1 is single hart, so I have not tried >> that myself). I like it a lot in that context. However, as a simple >> Unix it is useless: from a user-land view it is less capable than >> LSX. At minimum it needs fixes to make the file system less constrained. >> >> In my view, for SMP Keith Kelleman’s work for Sys-V is probably a >> better place to start. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Dec 31 06:31:24 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 30 Dec 2022 13:31:24 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221230200246.GW5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> Message-ID: <983B3B28-F6C2-4CDF-A9FC-B15F67E14619@gmail.com> > On Dec 30, 2022, at 1:02 PM, Larry McVoy wrote: >> > > Is there are reason to hang on to the Bourne shell? Maybe shell scripts? > Does it perform better than ksh or bash? POSIX sh seems like a good lowest-common-denominator shell to write for (sorry, SunOS and xpg4). > > Don't get me wrong, I much prefer the sh syntax over csh syntax, but > I'd never go back to the Bourne shell as my login shell. Way too much > useful stuff in ksh/bash. I mean I would assume the reason is that bash takes a whole lot more memory and CPU to do its very convenient magic. That's an issue if you're trying to run on a PDP-11 and only have 16 bits of address space, but in 64-bit-world, where you almost certainly have at least half a gigabyte of core storage available, and your processor clock is almost certainly in at least the high hundreds of MHz...yeah. Although (because my daily driver is a Mac) I've finally taken the zsh plunge. I feel a little dirty, but oh-my-zsh certainly has its attractions. Adam From mascheck at in-ulm.de Sat Dec 31 06:42:42 2022 From: mascheck at in-ulm.de (Sven Mascheck) Date: Fri, 30 Dec 2022 21:42:42 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221230200246.GW5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> Message-ID: <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Larry McVoy on 30.12.2022 21:02: > > [SysIII port] > Is there are reason to hang on to the Bourne shell? Maybe shell scripts? > Does it perform better than ksh or bash? > > Don't get me wrong, I much prefer the sh syntax over csh syntax, but > I'd never go back to the Bourne shell as my login shell. Way too much > useful stuff in ksh/bash. I'd like the idea of   "preserving a heirloom in its natural environment" (and even more effort went in https://heirloom.sourceforge.net/sh.html) let alone this does not prevent from adding modern shells... I guess in interactive use most users would only miss one thing: the history & line editing capability? Side notes to that: * By intention, the almquist shell (a port due to the Berkeley/ATT mess) initially had no history. From the package file DIFFERENCES [1], "History.   It seems to me that the csh history mechanism is mostly a response to the deficiencies of UNIX terminal I/O. Those of you running 4.2 BSD should try out atty (which I am posting to the net at the same time as ash) and see if you still want history." * and in "ksh - An Extensible High Level Language" David Korn writes: "Originally the idea of adding command line editing to ksh was rejected in the hope that line editing would move into the terminal driver." [2] I have always wondered, what such a central terminal driver driven history/line-editing would have felt like. [1] https://www.in-ulm.de/~mascheck/various/ash/DIFFERENCES [2] https://www.in-ulm.de/~mascheck/bourne/korn.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sat Dec 31 06:47:02 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 30 Dec 2022 15:47:02 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221230200246.GW5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> Message-ID: <50f82d6d-0070-8166-3968-bc868125b6be@case.edu> On 12/30/22 3:02 PM, Larry McVoy wrote: > On Fri, Dec 30, 2022 at 02:51:26PM -0500, Chet Ramey wrote: >> On 12/30/22 1:25 PM, Paul Ruizendaal wrote: >>> >>> London and Reiser report about porting the shell that ???it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.??? By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. >> >> Have you read >> >> http://www.collyer.net/who/geoff/sh.tour.pdf >> >> and looked at http://www.collyer.net/who/geoff/v7sh.tar ? >> >> In the limited literature on Bourne Shell porting, this is authoritative. > > Is there are reason to hang on to the Bourne shell? Maybe shell scripts? > Does it perform better than ksh or bash? Historical interest? Software archaeology? Reference behavior? I don't think anyone is suggesting that we use it as a login shell, in the same way that no one is suggesting we go back to using v7 as an everyday computing environment. The world's come too far. -- ``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 jon at fourwinds.com Sat Dec 31 06:48:10 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 30 Dec 2022 12:48:10 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> Sven Mascheck writes: > I guess in interactive use most users would only miss one thing: the > history & line editing capability? Job control? From chet.ramey at case.edu Sat Dec 31 06:49:31 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 30 Dec 2022 15:49:31 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <983B3B28-F6C2-4CDF-A9FC-B15F67E14619@gmail.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <983B3B28-F6C2-4CDF-A9FC-B15F67E14619@gmail.com> Message-ID: On 12/30/22 3:31 PM, Adam Thornton wrote: > Although (because my daily driver is a Mac) I've finally taken the zsh plunge. You don't have to, you know. ;-) -- ``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 ron at ronnatalie.com Sat Dec 31 06:49:36 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 30 Dec 2022 20:49:36 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: I was just happy when VR2 came out and found someone had undone all those macros that were in the original code. I hacked Berkeley Job Control as well as command line editing into it (KSH hadn’t seen the light of day outside the labs at that point). I subsequently had a nice talk with Korn at a USENIX. I also sat down with a couple of the guys trying to implement their own shell independent of the ATT code and explained to them how Berkeley job control works. It’s for that reason my name shows up in a lot of the early Linux docs. Amusingly, I’d forgotten all about this stuff until one day I was sitting at a MIPS workstation (MIPS branded, not the DEC spim). Without thinking about it, I typed “fg” at the shell prompt. “Job control not Enabled,” it said. Hey! That sounds like one of my messages. “set -J” I type. “Job control enabled.” Hey! This is a “Ron shell” as it was known at BRL. Turns out it went out on the Mach distros so I’ve found it on all kinds of things like the NeXT etc… ------ Original Message ------ >From "Sven Mascheck" To tuhs at tuhs.org Date 12/30/2022 3:20:28 PM Subject [TUHS] Re: A few comments on porting the Bourne shell >Chet Ramey on 30.12.2022 20:51: >>Arnold Robbins built on that work and ported the v8-v10 shells to modern >>Linux versions. (I am sorry, I do not have a link right now.) > >And btw, 8th ed (http://man.cat-v.org/unix_8th/1/sh) even added a simple history mechanism with the "=(1)" command (https://www.in-ulm.de/~mascheck/bourne/v8/=.html). > >Sven > From mascheck at in-ulm.de Sat Dec 31 06:51:13 2022 From: mascheck at in-ulm.de (Sven Mascheck) Date: Fri, 30 Dec 2022 21:51:13 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> Message-ID: Jon Steinhart 30.12.2022 21:48: >> I guess in interactive use most users would only miss one thing: the >> history & line editing capability? > Job control? well spotted, not available in vanilla sh until SVR4... From robpike at gmail.com Sat Dec 31 06:52:28 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 31 Dec 2022 07:52:28 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: That "someone" was Steve Bourne. At least, the version he handed me when I built up the v8 shell was from him and clean of ELIFs. -rob On Sat, Dec 31, 2022 at 7:50 AM Ron Natalie wrote: > I was just happy when VR2 came out and found someone had undone all > those macros that were in the original code. > I hacked Berkeley Job Control as well as command line editing into it > (KSH hadn’t seen the light of day outside the labs at that point). > I subsequently had a nice talk with Korn at a USENIX. I also sat down > with a couple of the guys trying to implement their own shell > independent of the ATT code and explained to them how Berkeley job > control works. It’s for that reason my name shows up in a lot of the > early Linux docs. > > Amusingly, I’d forgotten all about this stuff until one day I was > sitting at a MIPS workstation (MIPS branded, not the DEC spim). > Without thinking about it, I typed “fg” at the shell prompt. > > “Job control not Enabled,” it said. Hey! That sounds like one of my > messages. “set -J” I type. “Job control enabled.” > Hey! This is a “Ron shell” as it was known at BRL. Turns out it went > out on the Mach distros so I’ve found it on all kinds of things like the > NeXT etc… > > > ------ Original Message ------ > From "Sven Mascheck" > To tuhs at tuhs.org > Date 12/30/2022 3:20:28 PM > Subject [TUHS] Re: A few comments on porting the Bourne shell > > >Chet Ramey on 30.12.2022 20:51: > >>Arnold Robbins built on that work and ported the v8-v10 shells to modern > >>Linux versions. (I am sorry, I do not have a link right now.) > > > >And btw, 8th ed (http://man.cat-v.org/unix_8th/1/sh) even added a simple > history mechanism with the "=(1)" command ( > https://www.in-ulm.de/~mascheck/bourne/v8/=.html). > > > >Sven > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Dec 31 06:53:41 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 30 Dec 2022 12:53:41 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: <202212302053.2BUKrf19253823@darkstar.fourwinds.com> Ron Natalie writes: > I was just happy when VR2 came out and found someone had undone all > those macros that were in the original code. On an amusing note, a while ago I had polled folks on a different mailing list on items to include in a starter tool set for my daughter. Steve: Hi Jon, highly recommend DeWalt 20V drill, here is my checklist for my boat tools. Might be something there to add. Some clearly not but didn't scrub. Jon: Thanks. I was thinking that I should also get her one of those adapters that connects a { to a BEGIN :-) Steve: Looks like this :-} From steve at quintile.net Sat Dec 31 07:24:29 2022 From: steve at quintile.net (Steve Simon) Date: Fri, 30 Dec 2022 21:24:29 +0000 Subject: [TUHS] plan9 compiler memory use In-Reply-To: <167243231558.2485736.5509457353063331582@minnie.tuhs.org> References: <167243231558.2485736.5509457353063331582@minnie.tuhs.org> Message-ID: at the risk of making a fool of myself - there are several people far better qualified here, however… my memory is that the plan9 linker could be easily rebuilt to use malloc and free in the traditional style, reducing its memory footprint - though making it much slower. -Steve From luther at makerlisp.com Sat Dec 31 10:08:42 2022 From: luther at makerlisp.com (Luther Johnson) Date: Fri, 30 Dec 2022 17:08:42 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221230200246.GW5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> Message-ID: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> The Almquist shell (ash) and Debian's version of it, "dash", are compatible re-implementations of the Bourne shell, and use much less resources, and therefore wind up being faster as processes come and go. I use csh (tcsh) and bash at the command line, but straight Bourne shell language is preferred and recommended by many for shell programming, I used to use csh for that and got bitten by all the things that I later discovered, those in the know had been warning about for years. Also, "bash-isms", syntactic sugary things in bash had led me to use them as a crutch, my scripts got simpler and more to the point when I re-wrote them for Bourne shell language only. That was my experience. I think we'll always have some kind of Bourne shell as the script workhorse, at last in Linux/Unix start-up and other blood and guts stuff. In John Gilmore's paper on porting BSD through gcc to get to 4.4, he also remarked on how the original Bourne shell code was difficult to port. On 12/30/2022 01:02 PM, Larry McVoy wrote: > On Fri, Dec 30, 2022 at 02:51:26PM -0500, Chet Ramey wrote: >> On 12/30/22 1:25 PM, Paul Ruizendaal wrote: >>> London and Reiser report about porting the shell that ???it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.??? By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. >> Have you read >> >> http://www.collyer.net/who/geoff/sh.tour.pdf >> >> and looked at http://www.collyer.net/who/geoff/v7sh.tar ? >> >> In the limited literature on Bourne Shell porting, this is authoritative. > Is there are reason to hang on to the Bourne shell? Maybe shell scripts? > Does it perform better than ksh or bash? > > Don't get me wrong, I much prefer the sh syntax over csh syntax, but > I'd never go back to the Bourne shell as my login shell. Way too much > useful stuff in ksh/bash. > From lm at mcvoy.com Sat Dec 31 13:59:31 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 30 Dec 2022 19:59:31 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> Message-ID: <20221231035931.GG5825@mcvoy.com> On Fri, Dec 30, 2022 at 05:08:42PM -0700, Luther Johnson wrote: > I use csh (tcsh) and bash at the command line, but straight Bourne shell > language is preferred and recommended by many for shell programming, I used > to use csh for that and got bitten by all the things that I later > discovered, those in the know had been warning about for years. Also, > "bash-isms", syntactic sugary things in bash had led me to use them as a > crutch, my scripts got simpler and more to the point when I re-wrote them > for Bourne shell language only. That was my experience. I think we'll always > have some kind of Bourne shell as the script workhorse, at last in > Linux/Unix start-up and other blood and guts stuff. When I was running my engineering team I was strict about Bourne syntax and features only. I got pushed on like crazy because "bash has this $GOODNESS whhhhhhhy can't we use it". Because we were supporting our product on pretty much every unix and if it wasn't HP-UX that had an ancient /bin/sh, it was AIX or whoever. Over and over, I won the "straight bourne shell only" battle. So I agree, if you want /bin/sh to work, Bourne shell for the win. For a login shell, bash is my shell of choice. It's bloated but I'm typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and 4 cores and it's fine. It was fine a 133mhz Pentium. From usotsuki at buric.co Sat Dec 31 14:12:11 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 30 Dec 2022 23:12:11 -0500 (EST) Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231035931.GG5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: On Fri, 30 Dec 2022, Larry McVoy wrote: > When I was running my engineering team I was strict about Bourne syntax > and features only. I got pushed on like crazy because "bash has this > $GOODNESS whhhhhhhy can't we use it". Because we were supporting our > product on pretty much every unix and if it wasn't HP-UX that had an > ancient /bin/sh, it was AIX or whoever. > > Over and over, I won the "straight bourne shell only" battle. So I agree, > if you want /bin/sh to work, Bourne shell for the win. > > For a login shell, bash is my shell of choice. It's bloated but I'm > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and > 4 cores and it's fine. It was fine a 133mhz Pentium. There's some variants of the Almquist shell that have bash-style command-line editing, and I can deal with that if that's /bin/sh. Usually I use bash and it's plenty fine. I generally code shell scripts for Posix sh as my baseline and start my scripts with #!/bin/sh - but sometimes I'll use #!/bin/ksh if I don't expect them to be used on another machine. ksh93 is lighter and faster than bash and the only things I miss are quirks of the command line editor. -uso. From bakul at iitbombay.org Sat Dec 31 14:18:06 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 30 Dec 2022 20:18:06 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231035931.GG5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: On Dec 30, 2022, at 7:59 PM, Larry McVoy wrote: > > For a login shell, bash is my shell of choice. It's bloated but I'm > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and > 4 cores and it's fine. It was fine a 133mhz Pentium. I switched to zsh in 1993-94 when I found out it had sh compatible syntax but also had some useful features from csh (bang commands, a{b,c} expansion, aliases etc.). Back then my machine had 16MB of memory (IIRC a 50Mhz i486). zsh is the Cadillac of shells. But I also use rc, the VWbug of shells on plan9! From marc.donner at gmail.com Sat Dec 31 14:19:21 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 30 Dec 2022 23:19:21 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231035931.GG5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: Fascinating. When I left IBM Research to become a grad student at CMU (1981) the Unix CS was running did not have history in the shell. It had just been introduced in VM/CMS and I loved it. I nagged the sysadmins in the CS department about it, and voila, it appeared shortly thereafter. I presume it was one of the things discussed here ported to the CMU environment. I remember that I implemented history for the shell in the PERQ, doing some nasty stuff to fit a reasonable history length in the weird Pascal they had, since Pascal didn’t have dynamic strings or real pointers. Marc ===== On Fri, Dec 30, 2022 at 10:59 PM Larry McVoy wrote: > On Fri, Dec 30, 2022 at 05:08:42PM -0700, Luther Johnson wrote: > > I use csh (tcsh) and bash at the command line, but straight Bourne shell > > language is preferred and recommended by many for shell programming, I > used > > to use csh for that and got bitten by all the things that I later > > discovered, those in the know had been warning about for years. Also, > > "bash-isms", syntactic sugary things in bash had led me to use them as a > > crutch, my scripts got simpler and more to the point when I re-wrote them > > for Bourne shell language only. That was my experience. I think we'll > always > > have some kind of Bourne shell as the script workhorse, at last in > > Linux/Unix start-up and other blood and guts stuff. > > When I was running my engineering team I was strict about Bourne syntax > and features only. I got pushed on like crazy because "bash has this > $GOODNESS whhhhhhhy can't we use it". Because we were supporting our > product on pretty much every unix and if it wasn't HP-UX that had an > ancient /bin/sh, it was AIX or whoever. > > Over and over, I won the "straight bourne shell only" battle. So I agree, > if you want /bin/sh to work, Bourne shell for the win. > > For a login shell, bash is my shell of choice. It's bloated but I'm > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and > 4 cores and it's fine. It was fine a 133mhz Pentium. > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Dec 31 14:23:03 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 31 Dec 2022 15:23:03 +1100 (EST) Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231035931.GG5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: On Fri, 30 Dec 2022, Larry McVoy wrote: > When I was running my engineering team I was strict about Bourne syntax > and features only. I got pushed on like crazy because "bash has this > $GOODNESS whhhhhhhy can't we use it". Because we were supporting our > product on pretty much every unix and if it wasn't HP-UX that had an > ancient /bin/sh, it was AIX or whoever. I've never bothered to learn those Bash thingies, because "expr" does everything that I need and is available on just about all boxes. > Over and over, I won the "straight bourne shell only" battle. So I > agree, if you want /bin/sh to work, Bourne shell for the win. Yep; whoever wrote CSH must've been high on something, as the syntax makes no sense whatsoever. > For a login shell, bash is my shell of choice. It's bloated but I'm > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and 4 > cores and it's fine. It was fine a 133mhz Pentium. I do admit to being a bit of a ZSH user... I've never bothered to learn all its features, but the subset I use gets me through. -- Dave From clemc at ccc.com Sat Dec 31 14:37:07 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 30 Dec 2022 23:37:07 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: Bourne to program, type with Joy. On Fri, Dec 30, 2022 at 11:23 PM Dave Horsfall wrote: > On Fri, 30 Dec 2022, Larry McVoy wrote: > > > When I was running my engineering team I was strict about Bourne syntax > > and features only. I got pushed on like crazy because "bash has this > > $GOODNESS whhhhhhhy can't we use it". Because we were supporting our > > product on pretty much every unix and if it wasn't HP-UX that had an > > ancient /bin/sh, it was AIX or whoever. > > I've never bothered to learn those Bash thingies, because "expr" does > everything that I need and is available on just about all boxes. > > > Over and over, I won the "straight bourne shell only" battle. So I > > agree, if you want /bin/sh to work, Bourne shell for the win. > > Yep; whoever wrote CSH must've been high on something, as the syntax makes > no sense whatsoever. > > > For a login shell, bash is my shell of choice. It's bloated but I'm > > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and 4 > > cores and it's fine. It was fine a 133mhz Pentium. > > I do admit to being a bit of a ZSH user... I've never bothered to learn > all its features, but the subset I use gets me through. > > -- Dave > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Dec 31 14:40:49 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 30 Dec 2022 20:40:49 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: <20221231044049.GI5825@mcvoy.com> On Fri, Dec 30, 2022 at 08:18:06PM -0800, Bakul Shah wrote: > On Dec 30, 2022, at 7:59 PM, Larry McVoy wrote: > > > > For a login shell, bash is my shell of choice. It's bloated but I'm > > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and > > 4 cores and it's fine. It was fine a 133mhz Pentium. > > I switched to zsh in 1993-94 when I found out it had sh compatible > syntax but also had some useful features from csh (bang commands, > a{b,c} expansion, aliases etc.). This should probably move to COFF (which unlike many other lists I've been on, has critical mass in the "go over there" list). You are the 2nd to say zsh is your login shell. I tried it for a while, my progression was ${I dunno} to csh, actually used Bourne shell as a login shell for a while around 1985 or so, all of my login scripts, other shell scripts, were Bourne shell, I think zsh was next, then sighed in relief with the original ksh release that went out, and when bash came around with portability to everywhere, it has been bash. ksh93 was interesting but bash was good enough and clearly open source so... For script portability, pure Bourne shell has been the win for at least 40 years. I suspect my kids and their kids will be writing Steve's syntax, that's a legacy. For general purpose scripting, I've moved on. I loved Perl4. It's a kitchen sink language but it so clearly had roots in the Bourne shell, in awk, in sed. It was trying to be all of those things in one language and it mostly succeeded. In the 40mhz SPARC days I actually advocated for rewriting a ton of /usr/bin on SunOS in perl4 because it was so easy and far more maintainable than the C versions. These days perl is weird, the kids seem to like Python, I hate Python because there is no printf in the base language. How is that a thing? But people like it. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From grog at lemis.com Sat Dec 31 14:41:54 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 31 Dec 2022 15:41:54 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231035931.GG5825@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: <20221231044154.GA54376@eureka.lemis.com> On Friday, 30 December 2022 at 19:59:31 -0800, Larry McVoy wrote: > Over and over, I won the "straight bourne shell only" battle. So I agree, > if you want /bin/sh to work, Bourne shell for the win. Agreed. > For a login shell, bash is my shell of choice. It's bloated but I'm > typing this on a 5 year old Lenova X1 Carbon with 16GB of memory and > 4 cores and it's fine. It was fine a 133mhz Pentium. I've been using bash since 16 MHz i386s. People told me that it was bloated, but somehow I didn't notice. Somehow this reminds me of the expansion of EMACS: Eight Megabytes And Continually Swapping. 8 MB? Nowadays? It shows how old these prejudices are. Now my emacs processes have round 30 MB of resident memory and are dwarfed by 2 GB web browsers. bash comes in at a little over 2 MB, just not worth talking about. 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: 163 bytes Desc: not available URL: From ralph at inputplus.co.uk Sat Dec 31 21:40:37 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 31 Dec 2022 11:40:37 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> Message-ID: <20221231114037.7D30921FB4@orac.inputplus.co.uk> Hi Jon, > > I guess in interactive use most users would only miss one thing: > > the history & line editing capability? > > Job control? Just as history and line editing were a possible enhancement to the TTY driver, didn't Pike comment that job control was cooked up in foreign climes because they couldn't drag out a new TTY window in pixels? Was something like screen(1)'s ‘Ctrl-A c’ considered in the TTY driver to spin up another pseudo-TTY rather than suspend the long job with Ctrl-Z and ‘bg’ it? -- Cheers, Ralph. From pnr at planet.nl Sat Dec 31 22:55:20 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 31 Dec 2022 13:55:20 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> Message-ID: <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> The "assembly code in the Bourne shell" comment is in the same London/Reiser paper. The full quote is: "The (Bourne) shell is the standard user command interpreter. It required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable. Critical portions are coded in assembly language and had to be painstakingly rewritten. The shell uses its own sbrk which is functionally different from the standard routine in libc. The shell wants the routine which fields a signal to be passed a parameter giving the number of the signal being caught; signal was also a private rou- tine. This was handled by having the operating system provide the parameter in the first place, doing away with the private code for signal. The code in fixargs (for constructing the argument list to an exec system call) had to be diddled." The files in the V7 tree on the Tuhs website are dated January 1979, so it would seem that the fixes for 32V were immediately taken back to Research. As you point out, this means that the comments above do not refer to the well known source code, but to a predecessor of that (which I don’t think survived). Despite all the criticism voiced above, I think it is well understood that the original Bourne shell is an amazing piece of work that managed to fit an enormous amount of functionality into a cramped address space. Its longevity attests to that. That its internals became difficult to understand is par for the course -- the 1980’s in essence needed a Lions commentary on sh. > On 30 Dec 2022, at 20:57, segaloco wrote: > > I'll have to double check later but I'm fairly certain the remaining L/R cheats are gone by SysV. From what I can tell much of that portability work may have been done prior to the V7 release code base we're familiar with, as I did some comparison and found only one significant change between V7 and 32V code as I know it at least. Either the claims of portability issues came between 32V and System III (meaning the shell was accepted as "broken"? in 32V) or the code we actually see in V7 has already been tidied up significantly and doesn't represent the "non-portable" version lamented in the famous quote. Does this observation hold with reality? Is there an earlier, more PDP-11 bound version of the Bourne Shell out there? I seem to recall reading something about some bits of it even being in assembly at one point, but can't remember the quote source. > > - Matt G. > > ------- Original Message ------- > On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal wrote: > > >> London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. >> >> There were three aspects that I found noteworthy: >> >> 1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value: >> >> >> >> /* the following nonsense is required >> * because casts turn an Lvalue >> * into an Rvalue so two cheats >> * are necessary, one for each context. >> */ >> union { int _cheat;}; >> #define Lcheat(a) ((a)._cheat) >> #define Rcheat(a) ((int)(a)) >> >> >> >> However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C. >> >> 2. On the history of dup2 >> >> The shell code includes the following: >> >> >> >> rename(f1,f2) >> REG INT f1, f2; >> { >> #ifdef RES /* research has different sys calls from TS */ >> IF f1!=f2 >> THEN dup(f1|DUPFLG, f2); >> close(f1); >> IF f2==0 THEN ioset|=1 FI >> FI >> #else >> INT fs; >> IF f1!=f2 >> THEN fs = fcntl(f2,1,0); >> close(f2); >> fcntl(f1,0,f2); >> close(f1); >> IF fs==1 THEN fcntl(f2,2,1) FI >> IF f2==0 THEN ioset|=1 FI >> FI >> #endif >> } >> >> >> >> I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices. >> >> 3. Halfway to demand paging >> >> I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically: >> >> >> >> VOID fault(sig) >> REG INT sig; >> { >> signal(sig, fault); >> IF sig==MEMF >> THEN IF setbrk(brkincr) == -1 >> THEN error(nospace); >> FI >> ELIF ... >> >> >> >> This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling. >> From douglas.mcilroy at dartmouth.edu Sat Dec 31 23:26:56 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 31 Dec 2022 08:26:56 -0500 Subject: [TUHS] A few comments on porting the Bourne shell Message-ID: > "Originally the idea of adding command line editing to ksh was > rejected in the hope that line editing would move into the terminal > driver." [2] > I have always wondered, what such a central terminal driver driven > history/line-editing would have felt like. You can get a feel for it in Rob's "sam" editor, which works that way. Doug