From ron at ronnatalie.com Wed Dec 1 01:19:00 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 30 Nov 2021 15:19:00 +0000 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> Message-ID: Indeed, the early PDPs (10/15/20) had no microprogramming at all. Even the early microprogrammed ones used "random logic" to implement that. It would take ten years before large scale integration took over. The PDP-11/44 in 1979 was the last of the discrete logic CPUs. ------ Original Message ------ From: pbirkel at gmail.com To: "'TUHS main list'" Cc: "'Eugene Miya'" Sent: 11/30/2021 3:07:15 AM Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores >I believe that the PDP-11 ISA was defined at a time when DEC was still using >random logic rather than a control stor From arnold at skeeve.com Wed Dec 1 01:30:02 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 30 Nov 2021 08:30:02 -0700 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> Message-ID: <202111301530.1AUFU2eC015214@freefriends.org> Can someone please explain why it's called "random" logic? Discrete logic I understand (more or less), but I've not heard the term "random" used in this context before now. Thanks, Arnold "Ron Natalie" wrote: > Indeed, the early PDPs (10/15/20) had no microprogramming at all. Even > the early microprogrammed ones used "random logic" to implement that. > It would take ten years before large scale integration took over. The > PDP-11/44 in 1979 was the last of the discrete logic CPUs. > > > ------ Original Message ------ > From: pbirkel at gmail.com > To: "'TUHS main list'" > Cc: "'Eugene Miya'" > Sent: 11/30/2021 3:07:15 AM > Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores > > >I believe that the PDP-11 ISA was defined at a time when DEC was still using > >random logic rather than a control stor > From ralph at inputplus.co.uk Wed Dec 1 01:39:54 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 30 Nov 2021 15:39:54 +0000 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <202111301530.1AUFU2eC015214@freefriends.org> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> Message-ID: <20211130153954.2AABB210F4@orac.inputplus.co.uk> Hi Arnold, > Can someone please explain why it's called "random" logic? Discrete > logic I understand (more or less), but I've not heard the term > "random" used in this context before now. I'm more used to ‘hard-wired’ logic versus ‘micro-programmed’ for microcode but random logic in a known term in this context: https://en.wikipedia.org/wiki/Random_logic Random logic is a semiconductor circuit design technique that translates high-level logic descriptions directly into hardware features such as AND and OR gates. The name derives from the fact that few easily discernible patterns are evident in the arrangement of features on the chip and in the interconnects between them. -- Cheers, Ralph. From jon at fourwinds.com Wed Dec 1 04:50:57 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 30 Nov 2021 10:50:57 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <202111301530.1AUFU2eC015214@freefriends.org> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> Message-ID: <202111301850.1AUIovEG006894@darkstar.fourwinds.com> arnold at skeeve.com writes: > Can someone please explain why it's called "random" logic? Discrete > logic I understand (more or less), but I've not heard the term "random" > used in this context before now. Well, as a recovered random logic designer, I think that the name comes from there being no particular structure to the logic. Many parts of logic design are very regular, think memory. But that regularity doesn't exist when, for example, decoding irregular instructions. From ralph at inputplus.co.uk Wed Dec 1 05:27:18 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 30 Nov 2021 19:27:18 +0000 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> <20211129011244.GJ18441@mcvoy.com> <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org> Message-ID: <20211130192718.C0401210F4@orac.inputplus.co.uk> Hi Bakul, > As far as processor design is concerned, I believe one of the problems > is that there are fewer and fewer people who can do both h/w and s/w > design competently. The ARM chip came about because the UK's Acorn Computers couldn't find a decent cost:performance 16-bit CPU to replace the 6502 in new models. Furber and Wilson realised from a visit to Bill Mensch's WDC that chip design could be done by a small outfit. The recent UCB reports on RISC suggested a simple design could still have high performance so they set about skipping 16-bit CPUs and rolling their own 32-bit RISC CPU, the Acorn RISC Machine. The point of that bit of history is they were not chip designers, but knew electronics and programming. Wilson designed the ARM's instruction set and it was a delight to code: very orthogonal, and every instruction had four-bits of condition-flag test, e.g. Carry Set, and a bit to indicate if this instruction should set the condition flags. Thus several instructions in a row could test the condition flags set by an instruction a few earlier and unaltered since; this cut the need for quite a few branches. I think Wilson did such a good job because she had coded extensively in assembler on several different architectures. Not just the odd device driver or context-switch but 16 KiB of 6502 instructions which were BBC BASIC, a structured BASIC with WHILE, PROC, integers, floats, etc. (The BASIC ROM remains a good test of any 6502 emulator today because of all the corner cases the hand-written assembly exercised.) This was just for the BASIC interpreter; the OS, file system, etc., were all in other 16 KiB ROMs of hand-written assembly. The ability to add a co-processor to the BBC Microcomputer meant Z80 and other implementations followed. So with all that experience it's not surprising that the instruction set, though RISC, gave just what the assembly writer wanted, nothing more, whilst being easy to learn and remember. I don't think a hardware-chip designer could have done such a good job. The later pressure to drop 32-bit instructions for a mixture of 16-bit and 32-bit due to mobile's small flash capacity beget Thumb, still used today as Thumb-2, which dropped much of the nice features which made hand-written assembly such a pleasure, but then by then compilers were better quality and more common. > This is why I think more programmers should roll up their sleeves and > design a processor and understand the issues involved, especially now > that programming FPGAs is becoming common. May be start with an > existing RISC-V core in some HDL, and push and pull it into (what you > think is) an ideal minimalist design. I agree with the sentiment, but it sounds quite a big leap for most programmers. I knew assembly and logic but not how to fill the gap to create a CPU. The popular book from a few years ago which plugged the hole for me was ‘The Elements of Computing Systems’, which I see has now had a second edition: ISBN 0-262-53980-2, https://amzn.to/3xE0IZo It's a book of two halves: the first builds a simple CPU for a primitive computer from nothing but NAND gates; the second half writes an assembler, then a compiler for a language targeting a VM and then implements the VM on the CPU built in part one. It's the reader who has to do all this. Initially in the book's HDL run against the provided simulators and test cases. Then in the programming language of his choice as just text I/O is required. So to start the other binary-operator logic gates have to be build with NANDs, then multiplexers, etc. There's a target of how many gates to use so an efficient design has to be produced. By chapter two we're implementing the ALU. After the sequential logic of chapter three the instruction set is introduced in chapter four. It proceeds at pace, just giving the barest tuition needed to understand each conceptual part. Any discussion of subtleties or alternative approaches is eschewed for weightier textbooks. I think it's a better introduction to CPU design and from that one can read up on Verilog, etc., and start experimenting with little CPU designs on FPGAs. -- Cheers, Ralph. From hummsmith42 at gmail.com Wed Dec 1 07:45:50 2021 From: hummsmith42 at gmail.com (Humm) Date: Tue, 30 Nov 2021 21:45:50 +0000 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <202111301850.1AUIovEG006894@darkstar.fourwinds.com> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> Message-ID: Quoth Jon Steinhart: >arnold at skeeve.com writes: >> Can someone please explain why it's called "random" logic? Discrete >> logic I understand (more or less), but I've not heard the term "random" >> used in this context before now. > >Well, as a recovered random logic designer, I think that the name comes >from there being no particular structure to the logic. Many parts of >logic design are very regular, think memory. But that regularity doesn't >exist when, for example, decoding irregular instructions. Now that’s a “random” definition. -- Humm From jon at fourwinds.com Wed Dec 1 09:07:29 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 30 Nov 2021 15:07:29 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> Message-ID: <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> Humm writes: > Quoth Jon Steinhart: > >arnold at skeeve.com writes: > >> Can someone please explain why it's called "random" logic? Discrete > >> logic I understand (more or less), but I've not heard the term "random" > >> used in this context before now. > > > >Well, as a recovered random logic designer, I think that the name comes > >from there being no particular structure to the logic. Many parts of > >logic design are very regular, think memory. But that regularity doesn't > >exist when, for example, decoding irregular instructions. > > Now that’s a “random” definition. > > -- > Humm OK, I'll try again. For anybody familiar with Portland, Oregon, it's the difference between driving in Northwest where there's a rectangular grid numbered in one direction and alphabetical in the other, and approaching the Ross Island Bridge from the west side which appears to be designed by someone following a goat while tripping their brains out. One can address Northwest Portland quite easily unlike getting onto the Ross Island Bridge. From henry.r.bent at gmail.com Wed Dec 1 09:18:43 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 30 Nov 2021 18:18:43 -0500 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> Message-ID: On Tue, 30 Nov 2021 at 18:10, Jon Steinhart wrote: > Humm writes: > > Quoth Jon Steinhart: > > >arnold at skeeve.com writes: > > >> Can someone please explain why it's called "random" logic? Discrete > > >> logic I understand (more or less), but I've not heard the term > "random" > > >> used in this context before now. > > > > > >Well, as a recovered random logic designer, I think that the name comes > > >from there being no particular structure to the logic. Many parts of > > >logic design are very regular, think memory. But that regularity > doesn't > > >exist when, for example, decoding irregular instructions. > > > > Now that’s a “random” definition. > > > > -- > > Humm > > OK, I'll try again. For anybody familiar with Portland, Oregon, it's the > difference between driving in Northwest where there's a rectangular grid > numbered in one direction and alphabetical in the other, and approaching > the Ross Island Bridge from the west side which appears to be designed by > someone following a goat while tripping their brains out. One can address > Northwest Portland quite easily unlike getting onto the Ross Island Bridge. > So - and as I say this as someone who has no direct experience with this level of logic - everything is directly addressable but the difference is in how you get there? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Dec 1 15:00:36 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 30 Nov 2021 21:00:36 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> Message-ID: <202112010500.1B150a48077541@darkstar.fourwinds.com> Henry Bent writes: > On Tue, 30 Nov 2021 at 18:10, Jon Steinhart wrote: > > > Humm writes: > > > Quoth Jon Steinhart: > > > >arnold at skeeve.com writes: > > > >> Can someone please explain why it's called "random" logic? Discrete > > > >> logic I understand (more or less), but I've not heard the term > > "random" > > > >> used in this context before now. > > > > > > > >Well, as a recovered random logic designer, I think that the name comes > > > >from there being no particular structure to the logic. Many parts of > > > >logic design are very regular, think memory. But that regularity doesn't > > > >exist when, for example, decoding irregular instructions. > > > > > > Now that's a "random" definition. > > > > > > -- > > > Humm > > > > OK, I'll try again. For anybody familiar with Portland, Oregon, it's the > > difference between driving in Northwest where there's a rectangular grid > > numbered in one direction and alphabetical in the other, and approaching > > the Ross Island Bridge from the west side which appears to be designed by > > someone following a goat while tripping their brains out. One can address > > Northwest Portland quite easily unlike getting onto the Ross Island Bridge. > > > > So - and as I say this as someone who has no direct experience with this > level of logic - everything is directly addressable but the difference is > in how you get there? Sorry my analogy didn't work. Look at a photomicrograph of a chip; at least to me it's pretty obvious where the random logic is located. Here's another try. In a microcoded machine, the same hardware is used for every microinstruction. In random logic, custom designed circuitry is used for each special case. From pbirkel at gmail.com Wed Dec 1 16:27:35 2021 From: pbirkel at gmail.com (pbirkel at gmail.com) Date: Wed, 1 Dec 2021 01:27:35 -0500 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <202112010500.1B150a48077541@darkstar.fourwinds.com> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> <202112010500.1B150a48077541@darkstar.fourwinds.com> Message-ID: <028601d7e67c$87e1bbd0$97a53370$@gmail.com> Said Jon: " In a microcoded machine, the same hardware is used for every microinstruction. In random logic, custom designed circuitry is used for each special case." Best way to get a handle on the distinction is to read up on the originator of the concept, Maurice Wilkes: https://en.wikipedia.org/wiki/Maurice_Wilkes https://amturing.acm.org/info/wilkes_1001395.cfm The original paper: http://www.cs.princeton.edu/courses/archive/fall09/cos375/BestWay.pdf "The Best Way to Design an Automatic Calculating Machine" (1951) ----- From rdm at cfcl.com Wed Dec 1 18:46:41 2021 From: rdm at cfcl.com (Rich Morin) Date: Wed, 1 Dec 2021 00:46:41 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <20211130192718.C0401210F4@orac.inputplus.co.uk> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> <20211129011244.GJ18441@mcvoy.com> <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org> <20211130192718.C0401210F4@orac.inputplus.co.uk> Message-ID: > On Nov 30, 2021, at 11:27, Ralph Corderoy wrote: > > ... The point of that bit of history is they were not chip designers, but > knew electronics and programming. Wilson designed the ARM's instruction > set and it was a delight to code: very orthogonal, and every instruction > had four-bits of condition-flag test, e.g. Carry Set, and a bit to > indicate if this instruction should set the condition flags. Thus > several instructions in a row could test the condition flags set by an > instruction a few earlier and unaltered since; this cut the need for > quite a few branches. ... I wrote a fair amount of PDP-11 assembler, back in the early 70's (about 10K LOC). I was particularly happy with a routine that moved a cell between a pair of doubly-linked, circular linked lists (a "free" list and a "busy" list). The routine only had to modify six pointers, which isn't a hard problem. The cute part was that it was able to do so using (IIRC) only eight or nine instructions. The PDP-11's auto-increment mode obviated the need for separate index modification code. I had previously written a fair amount of code for a Varian 620i, which had an AQX architecture. The 620i wasn't _hard_ to program, but it _was_ a bit tedious. The PDP-11, by comparison, was a programmer's delight. Which brings me to a historical notion: The DG Nova (https://en.wikipedia.org/wiki/Data_General_Nova) came out in 1969, just a bit before the PDP-11 (https://en.wikipedia.org/wiki/PDP-11). My impression, when I (later on) looked at the Nova ISA, was that they had moved in the right direction from the AQX approach, but not quite far enough. DEC, IMNSHO, got it right. (ducking). -r From aek at bitsavers.org Wed Dec 1 22:28:42 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 1 Dec 2021 04:28:42 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> <20211129011244.GJ18441@mcvoy.com> <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org> <20211130192718.C0401210F4@orac.inputplus.co.uk> Message-ID: <06fb60f8-a3a3-c959-f750-2d5862e83727@bitsavers.org> On 12/1/21 12:46 AM, Rich Morin wrote: > The DG Nova (https://en.wikipedia.org/wiki/Data_General_Nova) came out in 1969, just a bit before the PDP-11 (https://en.wikipedia.org/wiki/PDP-11). My impression, when I (later on) looked at the Nova ISA, was that they had moved in the right direction from the AQX approach, but not quite far enough. DEC, IMNSHO, got it right. (ducking). https://history-computer.com/dec-pdp-11-computer/ is a concise summary of where the pdp-11 architecture came from (Harold McFarland at CMU) and the origins of the nova from the and the connection to the dec pdp-x original source documents can be found at bitsavers From pnr at planet.nl Wed Dec 1 23:59:45 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 1 Dec 2021 14:59:45 +0100 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores Message-ID: <219A3DE7-3DA1-4618-82B2-9354D63F93DF@planet.nl> For DEC memo’s on designing the PDP-11 see bitsavers: http://www.bitsavers.org/pdf/dec/pdp11/memos/ (thank you Bitsavers! I love that archive) Ad van de Goor (author of a few of the memo’s) was my MSc thesis professor. I recall him saying in the early 80’s that in his view the PDP-11 should have been an 18-bit machine; he reasoned that even in the late 60’s it was obvious that 16-bits of address space was not enough for the lifespan of the design. --- For those who want to experiment with FPGA’s and ancient ISA’s, here is my plain Verilog code for the TI 9995 chip, which has an instruction set that is highly reminiscent of the PDP-11: https://gitlab.com/pnru/cortex/-/tree/master The actual CPU code (TMS99095.v) is less than 1000 lines of code. Paul From douglas.mcilroy at dartmouth.edu Thu Dec 2 00:55:23 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Dec 2021 09:55:23 -0500 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores Message-ID: My take on defining random logic random logic : hardware :: spaghetti code : software Doug From rminnich at gmail.com Thu Dec 2 02:42:16 2021 From: rminnich at gmail.com (ron minnich) Date: Wed, 1 Dec 2021 08:42:16 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <028601d7e67c$87e1bbd0$97a53370$@gmail.com> References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> <202112010500.1B150a48077541@darkstar.fourwinds.com> <028601d7e67c$87e1bbd0$97a53370$@gmail.com> Message-ID: I used to design hardware in those days, and had a soldering iron and a PDP 11/45 board on the same bench, unsuccessfully, so here goes. It's interesting to consider the PDP-8 and -11, and the progression of hardware. The -11 was way different than the -8: I still have some -8 boards, on which you can see the transistors and such needed to implement state and gates. The -11s had TTL. At the time, a package with four logic elements was a big deal. so the -8 had "a gate per 2x3 inch card" or so. The -11 had about 8x11 boards with, by my count on the 11/20, around 100+ gates (I've got some cards still ...). Again, multiple logic elements in a 14-dip were an amazing step forward. If you look at those boards, you see lots of 14-DIP with quad NAND, AND, NOR, 2 flops per package, and that's about it. In this world, where a gate costs about $1, you think about everything. Look carefully, and you can see the traces were laid out by hand; some of us remember the rooms full of light panels and the red tape you used to lay out the board. Not that I designed CPUs, but having used this gear, lived in the culture, I'd argue that bit layouts of instructions did in fact matter. The TTL MUX parts were yet to appear. The board layout, package design, cost of a wire, instruction format: all to some extent intertwined. You could look at the hardware design and draw a connection right back to instruction coding. It was all of a piece. The luxury of a ROM or MUX that picked instructions apart for you? Not at that time. As for random logic ... the things we did back then. The discipline of design for test, which we take for granted today as JTAG, was some time in the future. And some of you no doubt remember the unibus ... and the practice of "margining the bus." I.e., slow it the hell down so maybe it would not get data errors. Or maybe, even, "let's put a cap here to add some delay constant" -- people really did that stuff. It's amazing anything worked. But when a gate costs a buck, you do what you do. On Tue, Nov 30, 2021 at 10:30 PM wrote: > > Said Jon: > > " In a microcoded machine, the same hardware is used for every > microinstruction. In random logic, custom designed circuitry is used for > each special case." > > Best way to get a handle on the distinction is to read up on the originator > of the concept, Maurice Wilkes: > > https://en.wikipedia.org/wiki/Maurice_Wilkes > https://amturing.acm.org/info/wilkes_1001395.cfm > > The original paper: > > http://www.cs.princeton.edu/courses/archive/fall09/cos375/BestWay.pdf > > "The Best Way to Design an Automatic Calculating Machine" (1951) > > ----- > From ron at ronnatalie.com Thu Dec 2 03:08:58 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 01 Dec 2021 17:08:58 +0000 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> <202112010500.1B150a48077541@darkstar.fourwinds.com> <028601d7e67c$87e1bbd0$97a53370$@gmail.com> Message-ID: There seems to be confusion here about microcoding vs. discrete logic/LSI. All but the initial 11/20 (and its variants) are microcoded. That is there is a programmed sequence of operations in the execution of the individual instructions. The less popular 11/60 even featrued a writable control store. All of the early PDP-11s were built out of discrete logic. Relatively simplistic combinations of various logic chips, gates, flip flops, etc.. A lot of these were encapsulated into the DEC "Flip Chips" small circuit boards to do common sets of operations. While this is by modern standards, crude, it doesn't preclude microcoding and other advanced tasks. I worked on a supercomputer built that way (Denelcor HEP built largely out of Motorola 10800-series ECL chips). As I previously stated, the 11/44 was the last of the discrete logic PDP's in 1979. The later systems were all large scale integrated circuit based. First starting with the LSI-11/03 on the Q bus, quickly followed by the 11/23 and the Unibus 11/24. From jon at fourwinds.com Thu Dec 2 06:27:51 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 01 Dec 2021 12:27:51 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: Message-ID: <202112012027.1B1KRp0G120957@darkstar.fourwinds.com> Douglas McIlroy writes: > My take on defining random logic > > random logic : hardware :: spaghetti code : software I hate to take issue with Doug's explanation since he's a lot smarter than me. In my opinion, spaghetti code is a choice while random logic is not. In both cases, I have an underlying assumption that the hardware designer or coder is implementing someone else's design and doesn't have the ability to say "I could do a cleaner implementation if we could make a design change." While one could almost always do a "regular" implementation instead of a "random" one in hardware the regular one would likely be more expensive in terms of resources like speed, space, cost, and power than the random one. Of course, that's not always true. In the blast from the past department, I had to implement something around 1980 where there was no chance of meeting the timing requirements using random gates. At the time, and my memory is fuzzy here, AMD had a very fast 1Kx8 PROM. Instead of using random logic I used a couple of these, and wrote a compiler that converted logic equations into bit patterns for burning the PROMs. It was actually that project that got me back into doing software. Plus, of course, the fact that our department finally gave up on DEC operating systems and starting running UNIX. Random logic design is way different than it used to be. Back when I was in college, we had a Digital Logic Design course that focused on Karnaugh maps and all that sort of logic minimization stuff. I made a deal with my professor. I'd teach the class instead of taking it and annoying the crap out of him. In addition to the regular class material, I added TI's "The TTL Book". The new idea that I brought to the class was that gates came in packages, and one had to balance logic minimization with package minimization. So for example, if you needed an inverter and none was available but you had an extra NAND gate in a 7400 you could use it as an inverter instead of adding another package of which 5/6 of the gates would be unused. Today, all of this gets handled by CAD packages. The only time that one might have to get down into the dirt is in something like a very tight FPGA design where certain elements are in short supply and can clever misuse of other elements can get what's needed. Anyway, for yet another try, random logic is what you get when implementing an "unclean" specification while minimizing cost and other factors. Sort of like implementing a parser for FORTRAN :-) Speaking of FORTRAN and back to Doug's comment, I'm reminded of yet another story. Some decades ago I was the author of the C language binding for GKS, an absolutely stupid standard graphics package. The original GKS only had a FORTRAN binding, and many people on the ANSI committee were working on bindings for languages that their customers actually wanted. The FORTRAN binding was pretty much what you'd expect. When I did the C binding, among other things I defined a "point" data structure to hold x,y coordinates. At one of the meetings my friend Randy from Sandia complained about it. When pressed, he said that he had a program that started by labeling a map, and it was tedious for him to have code like p.x = 10; p.y = 20; gtext(p, "label"); when in FORTRAN he could just do gtext(10, 20, "label"); Once I understood his issue, I of course had to say "Well, if I was doing a map to monitor the nuclear test ban..." (because it was always fun to have people like him and the NSA person who pretended that we didn't know what they did), I taught him how to put the coordinates and labels into a static data structure making the rest a two-line program. He went back to Sandia and started teaching his peers how to write C in C instead of doing FORTRAN in C. I think that this is somewhat analogous to Doug's comment in that there was a choice on how to write the code, and Sandia's original choice wasn't very good. But, it was a choice, not something required by the specification. Different than, for example, logic that says that "an interrupt is generated when this or that or another goes high and this enable bit is high and this mask bit is low and the global interrupt enable is high." No sensible way to implement this except as a random hunk of logic because it's a one-off. Especially if there are other interrupts such as an NMI that has completely different rules. Hope that this all helps. Jon From arnold at skeeve.com Thu Dec 2 06:23:38 2021 From: arnold at skeeve.com (Arnold Robbins) Date: Wed, 01 Dec 2021 22:23:38 +0200 Subject: [TUHS] Ratfor revived! Message-ID: Hi All. Mainly for fun (sic), I decided to revive the Ratfor (Rational Fortran) preprocessor. Please see: https://github.com/arnoldrobbins/ratfor I started with the V6 code, then added the V7, V8 and V10 versions on top of it. Each one has its own branch so that you can look at the original code, if you wish. The man page and the paper from the V7 manual are also included. Starting with the Tenth Edition version, I set about to modernize the code and get it to compile and run on a modern-day system. (ANSI style declarations and function headers, modern include files, use of getopt, and most importantly, correct use of Yacc yyval and yylval variables.) You will need Berkely Yacc installed as byacc in order to build it. I have only touch-tested it, but so far it seems OK. 'make' runs in like 2 seconds, really quick. On my Ubuntu Linux systems, it compiles with no warnings. I hope to eventually add a test suite also, if I can steal some time. Before anyone asks, no, I don't think anybody today has any real use for it. This was simply "for fun", and because Ratfor has a soft spot in my heart. "Software Tools" was, for me, the most influential programming book that I ever read. I don't think there's a better book to convey the "zen" of Unix. Thanks, Arnold From cowan at ccil.org Thu Dec 2 06:57:40 2021 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Dec 2021 15:57:40 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: Message-ID: On Wed, Dec 1, 2021 at 3:40 PM Arnold Robbins wrote: > "Software Tools" was, for me, the most influential > programming book that I ever read. I don't think there's a better > book to convey the "zen" of Unix. > +1. Jez Higgins is in the process of rewriting _Software Tools in Pascal_ into C++ in a project called "stinc++". His blog index is at < https://www.jezuk.co.uk/tags/software-tools-in-c++.html> and the repo is at . He's up through uniq in Chapter 4 so far. He writes: "I first found Software Tools in Pascal a bit over 20 years ago, hidden in amongst old VAX manuals in the library of the company where I worked at the time. Unusually for a technical book, Software Tools in Pascal has a terrific narrative. It starts with a tiny task – copy everything from the console input to the console output – and presents the correspondingly tiny program. Step by step, program by program, you arrive at the end of the book with an ex-like line editor, a roff-style print formatter, and a macro processor. En route, you take in filtering, file archiving, sorting, and regular expressions. Each incremental step seems so logical and the code presented is so clear, that you just want to keep reading. Chunks of code in a book can be rather tedious, but Kernighan and Plauger’s is a joy. The lessons imparted on simplicity, clarity, efficiency, on tools and the Unix philosophy, in common sense, how each decision affects the finished program – well, they are at the core of what we do, and how we should think about programming. Your mind can only be blown once, but I re-read bits of this book often to remind myself of the feeling it gave me." -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 2 06:59:00 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Dec 2021 15:59:00 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: Message-ID: Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of things I want to play with at some point. I too had a wonderful childhood experience with the SW tools. Somebody had a number of them running on a VMS box when all we had was the VMS Fortran compiler, no C yet. I am curious why did you decide to use byacc? I would have thought in a desire to modernize and make it more available on a modern system -- was there something in byacc that could not be done easily in bison? To be honest, I had thought Robert Corbett did them both and bison was the successor to byacc, but I'm not a compiler guy - so I'm suspecting that there must be a difference/reason. As I said, this is purely curiosity -- an educational opportunity. Thanks again, Clem ᐧ On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: > Hi All. > > Mainly for fun (sic), I decided to revive the Ratfor (Rational > Fortran) preprocessor. Please see: > > https://github.com/arnoldrobbins/ratfor > > I started with the V6 code, then added the V7, V8 and V10 versions > on top of it. Each one has its own branch so that you can look > at the original code, if you wish. The man page and the paper from > the V7 manual are also included. > > Starting with the Tenth Edition version, I set about to modernize > the code and get it to compile and run on a modern-day system. > (ANSI style declarations and function headers, modern include files, > use of getopt, and most importantly, correct use of Yacc yyval and > yylval variables.) > > You will need Berkely Yacc installed as byacc in order to build it. > > I have only touch-tested it, but so far it seems OK. 'make' runs in like 2 > seconds, really quick. On my Ubuntu Linux systems, it compiles with > no warnings. > > I hope to eventually add a test suite also, if I can steal some time. > > Before anyone asks, no, I don't think anybody today has any real use > for it. This was simply "for fun", and because Ratfor has a soft > spot in my heart. "Software Tools" was, for me, the most influential > programming book that I ever read. I don't think there's a better > book to convey the "zen" of Unix. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu Dec 2 07:14:02 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 1 Dec 2021 16:14:02 -0500 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: References: Message-ID: <4FA7E5AA-C673-491F-9874-26E2165F51A7@serissa.com> > On 2021, Dec 1, at 9:55 AM, Douglas McIlroy wrote: > > My take on defining random logic > > random logic : hardware :: spaghetti code : software > > Doug I don’t think this is right. The irregular parts of die photographs didn’t get that way because the hardware engineers were writing bad (spaghetti) code. They got that way due to several levels of optimizing tools working over quite sensible RTL or System C code or whatever. You might as well ding the output of -O3 for being incomprehensible. You might get the same logic by writing a clean state machine and letting the tools minimize the control rom into gates (good) or by writing the gates yourself (bad). You can’t tell without looking at the sources. Software coding: You write the conrol flow and the compiler generates the datapath Hardware coding: You write the datapath and the compiler does the control logic. From thomas.paulsen at firemail.de Thu Dec 2 07:24:29 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 01 Dec 2021 22:24:29 +0100 Subject: [TUHS] Ratfor revived! In-Reply-To: References: Message-ID: <9698e5747f5cd4c7bb30862082cb987c@firemail.de> An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Dec 2 07:56:55 2021 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 2 Dec 2021 07:56:55 +1000 Subject: [TUHS] Encoding an ISA In-Reply-To: References: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> <202111301530.1AUFU2eC015214@freefriends.org> <202111301850.1AUIovEG006894@darkstar.fourwinds.com> <202111302307.1AUN7TBv066715@darkstar.fourwinds.com> <202112010500.1B150a48077541@darkstar.fourwinds.com> <028601d7e67c$87e1bbd0$97a53370$@gmail.com> Message-ID: <20211201215655.GA24090@minnie.tuhs.org> All, I think it's time to move the ISA and random logic threads over to COFF :-) Thanks! Warren From jon at fourwinds.com Thu Dec 2 08:09:28 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 01 Dec 2021 14:09:28 -0800 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores In-Reply-To: <4FA7E5AA-C673-491F-9874-26E2165F51A7@serissa.com> References: <4FA7E5AA-C673-491F-9874-26E2165F51A7@serissa.com> Message-ID: <202112012209.1B1M9SbS123400@darkstar.fourwinds.com> Lawrence Stewart writes: > I don’t think this is right. The irregular parts of die photographs didn’t > get that way because the hardware engineers were writing bad (spaghetti) > code. They got that way due to several levels of optimizing tools working > over quite sensible RTL or System C code or whatever. You might as well ding > the output of -O3 for being incomprehensible. Yes and no. The irregular parts of die photographs are from the instantiation of random logic. The point that I obviously failed to make earlier is that it looks way different than the instantiation of more regular logic. But there's also a historical element here and I was living in the past. Sure, what you say is true of modern designs which I haven't been involved with; my current history is limited to FPGA designs. But, going back a while, look up Rubylith (no relation to Ruby) which is how ICs were laid out pre-CAD days. The regular and random parts look remarkably similar to the way that they do today. No compilers needed to make things look that way. Just for some more BTL history, I started doing work on CAD software around 1985. I'm thinking that it was maybe 1988 or 1989 when a bunch of area 10 folks (Carl, Greg, Hal, ...) left BTL to found what I think was called Silicon Design Labs which eventually merged with Silicon Compilers (or the other way around). I think that they were later bought out by one of the current big CAD system survivors. Jon From dscherrer at solar.stanford.edu Thu Dec 2 07:14:06 2021 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 1 Dec 2021 13:14:06 -0800 Subject: [TUHS] Ratfor revived! In-Reply-To: References: Message-ID: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> All you folks revisiting the Software Tools should remember that there was an entire movement around the first book, based at Lawrence Berkeley Lab.  The Software Tools group, an offshoot of Usenix, had about 2000 members.  We created an almost-entire Unix environment based on a virtual operating system that we designed, inspired of course by Kernighan's ideas.  The collection was ported to over 50 operating systems, including some without file systems.   This is all still freely available, and stored with the Unix archives. Deborah On 12/1/21 12:59 PM, Clem Cole wrote: > Arnold -- sounds fun.  Thank you!!!  I'll add it to my growing pile of > things I want to play with at some point.   I too had a wonderful > childhood experience with the SW tools.  Somebody had a number of them > running on a VMS box when all we had was the VMS Fortran compiler, no > C yet. > > I am curious why did you decide to use byacc?   I would have thought > in a desire to modernize and make it more available on a modern system > -- was there something in byacc that could not be done easily in > bison?   To be honest, I had thought Robert Corbett did them both and > bison was the successor to byacc, but I'm not a compiler guy - so I'm > suspecting that there must be a difference/reason.   As I said, this > is purely curiosity -- an educational opportunity. > > Thanks again, > Clem > ᐧ > > On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: > > Hi All. > > Mainly for fun (sic), I decided to revive the Ratfor (Rational > Fortran) preprocessor.  Please see: > > https://github.com/arnoldrobbins/ratfor > > I started with the V6 code, then added the V7, V8 and V10 versions > on top of it. Each one has its own branch so that you can look > at the original code, if you wish. The man page and the paper from > the V7 manual are also included. > > Starting with the Tenth Edition version, I set about to modernize > the code and get it to compile and run on a modern-day system. > (ANSI style declarations and function headers, modern include files, > use of getopt, and most importantly, correct use of Yacc yyval and > yylval variables.) > > You will need Berkely Yacc installed as byacc in order to build it. > > I have only touch-tested it, but so far it seems OK.  'make' runs > in like 2 > seconds, really quick. On my Ubuntu Linux systems, it compiles with > no warnings. > > I hope to eventually add a test suite also, if I can steal some time. > > Before anyone asks, no, I don't think anybody today has any real use > for it.  This was simply "for fun", and because Ratfor has a soft > spot in my heart.  "Software Tools" was, for me, the most influential > programming book that I ever read.  I don't think there's a better > book to convey the "zen" of Unix. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Dec 2 08:23:12 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 1 Dec 2021 17:23:12 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: On Wed, 1 Dec 2021 at 17:17, Deborah Scherrer wrote: > All you folks revisiting the Software Tools should remember that there was > an entire movement around the first book, based at Lawrence Berkeley Lab. > The Software Tools group, an offshoot of Usenix, had about 2000 members. > We created an almost-entire Unix environment based on a virtual operating > system that we designed, inspired of course by Kernighan's ideas. The > collection was ported to over 50 operating systems, including some without > file systems. This is all still freely available, and stored with the > Unix archives. > Could you provide a link to said environment, and suggest what sort of machines it might have run on? I probably have something here that will do it, and I am very interested. -Henry > On 12/1/21 12:59 PM, Clem Cole wrote: > > Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of > things I want to play with at some point. I too had a wonderful childhood > experience with the SW tools. Somebody had a number of them running on a > VMS box when all we had was the VMS Fortran compiler, no C yet. > > I am curious why did you decide to use byacc? I would have thought in a > desire to modernize and make it more available on a modern system -- was > there something in byacc that could not be done easily in bison? To be > honest, I had thought Robert Corbett did them both and bison was the > successor to byacc, but I'm not a compiler guy - so I'm suspecting that > there must be a difference/reason. As I said, this is purely curiosity -- > an educational opportunity. > > Thanks again, > Clem > ᐧ > > On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: > >> Hi All. >> >> Mainly for fun (sic), I decided to revive the Ratfor (Rational >> Fortran) preprocessor. Please see: >> >> https://github.com/arnoldrobbins/ratfor >> >> I started with the V6 code, then added the V7, V8 and V10 versions >> on top of it. Each one has its own branch so that you can look >> at the original code, if you wish. The man page and the paper from >> the V7 manual are also included. >> >> Starting with the Tenth Edition version, I set about to modernize >> the code and get it to compile and run on a modern-day system. >> (ANSI style declarations and function headers, modern include files, >> use of getopt, and most importantly, correct use of Yacc yyval and >> yylval variables.) >> >> You will need Berkely Yacc installed as byacc in order to build it. >> >> I have only touch-tested it, but so far it seems OK. 'make' runs in like >> 2 >> seconds, really quick. On my Ubuntu Linux systems, it compiles with >> no warnings. >> >> I hope to eventually add a test suite also, if I can steal some time. >> >> Before anyone asks, no, I don't think anybody today has any real use >> for it. This was simply "for fun", and because Ratfor has a soft >> spot in my heart. "Software Tools" was, for me, the most influential >> programming book that I ever read. I don't think there's a better >> book to convey the "zen" of Unix. >> >> Thanks, >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Thu Dec 2 08:43:39 2021 From: brantley at coraid.com (Brantley Coile) Date: Wed, 1 Dec 2021 22:43:39 +0000 Subject: [TUHS] Ratfor revived! In-Reply-To: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: <1432F1B1-DC2F-4A7B-AE97-F7B574C9B8BC@coraid.com> I installed the STUG tape on our CDC Cyber 18/30 minicomputer and went from clunky to cool. A mentor Bob Stearns loaned me a copy of the book and it changed my life. After Bob passed away, his widow gave me the book. I was very touched. The Software Tools Groups work certainly made a big difference before Unix was widely available. Brantley Coile > On Dec 1, 2021, at 4:14 PM, Deborah Scherrer wrote: > > All you folks revisiting the Software Tools should remember that there was an entire movement around the first book, based at Lawrence Berkeley Lab. The Software Tools group, an offshoot of Usenix, had about 2000 members. We created an almost-entire Unix environment based on a virtual operating system that we designed, inspired of course by Kernighan's ideas. The collection was ported to over 50 operating systems, including some without file systems. This is all still freely available, and stored with the Unix archives. > > Deborah > On 12/1/21 12:59 PM, Clem Cole wrote: >> Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of things I want to play with at some point. I too had a wonderful childhood experience with the SW tools. Somebody had a number of them running on a VMS box when all we had was the VMS Fortran compiler, no C yet. >> >> I am curious why did you decide to use byacc? I would have thought in a desire to modernize and make it more available on a modern system -- was there something in byacc that could not be done easily in bison? To be honest, I had thought Robert Corbett did them both and bison was the successor to byacc, but I'm not a compiler guy - so I'm suspecting that there must be a difference/reason. As I said, this is purely curiosity -- an educational opportunity. >> >> Thanks again, >> Clem >> ᐧ >> >> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: >> Hi All. >> >> Mainly for fun (sic), I decided to revive the Ratfor (Rational >> Fortran) preprocessor. Please see: >> >> https://github.com/arnoldrobbins/ratfor >> >> I started with the V6 code, then added the V7, V8 and V10 versions >> on top of it. Each one has its own branch so that you can look >> at the original code, if you wish. The man page and the paper from >> the V7 manual are also included. >> >> Starting with the Tenth Edition version, I set about to modernize >> the code and get it to compile and run on a modern-day system. >> (ANSI style declarations and function headers, modern include files, >> use of getopt, and most importantly, correct use of Yacc yyval and >> yylval variables.) >> >> You will need Berkely Yacc installed as byacc in order to build it. >> >> I have only touch-tested it, but so far it seems OK. 'make' runs in like 2 >> seconds, really quick. On my Ubuntu Linux systems, it compiles with >> no warnings. >> >> I hope to eventually add a test suite also, if I can steal some time. >> >> Before anyone asks, no, I don't think anybody today has any real use >> for it. This was simply "for fun", and because Ratfor has a soft >> spot in my heart. "Software Tools" was, for me, the most influential >> programming book that I ever read. I don't think there's a better >> book to convey the "zen" of Unix. >> >> Thanks, >> >> Arnold From clemc at ccc.com Thu Dec 2 10:34:15 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Dec 2021 19:34:15 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: https://www.tuhs.org/Archive/Applications/Software_Tools/ ᐧ On Wed, Dec 1, 2021 at 5:25 PM Henry Bent wrote: > On Wed, 1 Dec 2021 at 17:17, Deborah Scherrer < > dscherrer at solar.stanford.edu> wrote: > >> All you folks revisiting the Software Tools should remember that there >> was an entire movement around the first book, based at Lawrence Berkeley >> Lab. The Software Tools group, an offshoot of Usenix, had about 2000 >> members. We created an almost-entire Unix environment based on a virtual >> operating system that we designed, inspired of course by Kernighan's >> ideas. The collection was ported to over 50 operating systems, including >> some without file systems. This is all still freely available, and stored >> with the Unix archives. >> > Could you provide a link to said environment, and suggest what sort of > machines it might have run on? I probably have something here that will do > it, and I am very interested. > > -Henry > > >> On 12/1/21 12:59 PM, Clem Cole wrote: >> >> Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of >> things I want to play with at some point. I too had a wonderful childhood >> experience with the SW tools. Somebody had a number of them running on a >> VMS box when all we had was the VMS Fortran compiler, no C yet. >> >> I am curious why did you decide to use byacc? I would have thought in a >> desire to modernize and make it more available on a modern system -- was >> there something in byacc that could not be done easily in bison? To be >> honest, I had thought Robert Corbett did them both and bison was the >> successor to byacc, but I'm not a compiler guy - so I'm suspecting that >> there must be a difference/reason. As I said, this is purely curiosity -- >> an educational opportunity. >> >> Thanks again, >> Clem >> ᐧ >> >> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: >> >>> Hi All. >>> >>> Mainly for fun (sic), I decided to revive the Ratfor (Rational >>> Fortran) preprocessor. Please see: >>> >>> https://github.com/arnoldrobbins/ratfor >>> >>> I started with the V6 code, then added the V7, V8 and V10 versions >>> on top of it. Each one has its own branch so that you can look >>> at the original code, if you wish. The man page and the paper from >>> the V7 manual are also included. >>> >>> Starting with the Tenth Edition version, I set about to modernize >>> the code and get it to compile and run on a modern-day system. >>> (ANSI style declarations and function headers, modern include files, >>> use of getopt, and most importantly, correct use of Yacc yyval and >>> yylval variables.) >>> >>> You will need Berkely Yacc installed as byacc in order to build it. >>> >>> I have only touch-tested it, but so far it seems OK. 'make' runs in >>> like 2 >>> seconds, really quick. On my Ubuntu Linux systems, it compiles with >>> no warnings. >>> >>> I hope to eventually add a test suite also, if I can steal some time. >>> >>> Before anyone asks, no, I don't think anybody today has any real use >>> for it. This was simply "for fun", and because Ratfor has a soft >>> spot in my heart. "Software Tools" was, for me, the most influential >>> programming book that I ever read. I don't think there's a better >>> book to convey the "zen" of Unix. >>> >>> Thanks, >>> >>> Arnold >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Dec 2 15:44:33 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 2 Dec 2021 00:44:33 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: Thank you, Clem. I am working on getting the tools running in DOSBox, which seemed most straightforward. The Byte article (the scan of which I am very grateful for; not having to go trawling through the stacks at the Oberlin College library is always a plus) claims that the tools have been implemented on: ACOS Amdahl Apollo AN/UYK Burroughs CDC Cray Data General DEC FACOM GEC HP HITAC Honeywell IBM Intel Interdata Modcomp Multics NCR Perkin-Elmer Prime Rolm SEL Tandem Univac Wang Xerox CP/M Machines MS/DOS Machines UNIX Machines Which is quite the list; I've never even heard of a few of those! Based on the files in the UNIX Archive, am I to assume that most of those ports took advantage of a native Pascal compiler? That's how I'm planning to bring the tools up on my local RT-11 machine. -Henry On Wed, 1 Dec 2021 at 19:34, Clem Cole wrote: > https://www.tuhs.org/Archive/Applications/Software_Tools/ > ᐧ > > On Wed, Dec 1, 2021 at 5:25 PM Henry Bent wrote: > >> On Wed, 1 Dec 2021 at 17:17, Deborah Scherrer < >> dscherrer at solar.stanford.edu> wrote: >> >>> All you folks revisiting the Software Tools should remember that there >>> was an entire movement around the first book, based at Lawrence Berkeley >>> Lab. The Software Tools group, an offshoot of Usenix, had about 2000 >>> members. We created an almost-entire Unix environment based on a virtual >>> operating system that we designed, inspired of course by Kernighan's >>> ideas. The collection was ported to over 50 operating systems, including >>> some without file systems. This is all still freely available, and stored >>> with the Unix archives. >>> >> Could you provide a link to said environment, and suggest what sort of >> machines it might have run on? I probably have something here that will do >> it, and I am very interested. >> >> -Henry >> >> >>> On 12/1/21 12:59 PM, Clem Cole wrote: >>> >>> Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of >>> things I want to play with at some point. I too had a wonderful childhood >>> experience with the SW tools. Somebody had a number of them running on a >>> VMS box when all we had was the VMS Fortran compiler, no C yet. >>> >>> I am curious why did you decide to use byacc? I would have thought in >>> a desire to modernize and make it more available on a modern system -- was >>> there something in byacc that could not be done easily in bison? To be >>> honest, I had thought Robert Corbett did them both and bison was the >>> successor to byacc, but I'm not a compiler guy - so I'm suspecting that >>> there must be a difference/reason. As I said, this is purely curiosity -- >>> an educational opportunity. >>> >>> Thanks again, >>> Clem >>> ᐧ >>> >>> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: >>> >>>> Hi All. >>>> >>>> Mainly for fun (sic), I decided to revive the Ratfor (Rational >>>> Fortran) preprocessor. Please see: >>>> >>>> https://github.com/arnoldrobbins/ratfor >>>> >>>> I started with the V6 code, then added the V7, V8 and V10 versions >>>> on top of it. Each one has its own branch so that you can look >>>> at the original code, if you wish. The man page and the paper from >>>> the V7 manual are also included. >>>> >>>> Starting with the Tenth Edition version, I set about to modernize >>>> the code and get it to compile and run on a modern-day system. >>>> (ANSI style declarations and function headers, modern include files, >>>> use of getopt, and most importantly, correct use of Yacc yyval and >>>> yylval variables.) >>>> >>>> You will need Berkely Yacc installed as byacc in order to build it. >>>> >>>> I have only touch-tested it, but so far it seems OK. 'make' runs in >>>> like 2 >>>> seconds, really quick. On my Ubuntu Linux systems, it compiles with >>>> no warnings. >>>> >>>> I hope to eventually add a test suite also, if I can steal some time. >>>> >>>> Before anyone asks, no, I don't think anybody today has any real use >>>> for it. This was simply "for fun", and because Ratfor has a soft >>>> spot in my heart. "Software Tools" was, for me, the most influential >>>> programming book that I ever read. I don't think there's a better >>>> book to convey the "zen" of Unix. >>>> >>>> Thanks, >>>> >>>> Arnold >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Dec 2 17:41:15 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Dec 2021 00:41:15 -0700 Subject: [TUHS] Ratfor revived! In-Reply-To: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: <202112020741.1B27fFUc030032@freefriends.org> Indeed. I never worked with this directly, though. I went to grad school at Georgia Tech, where some of the students had started with the tools from the book and built a beautiful Unix-like subsystem on top of Primos on Pr1me minicomputers. (This code was recoverd in 2019, after thinking it'd been lost for 30+ years!) I never asked, but I suspect that the Georgia Tech guys simply didn't know about the LBL work, or else they developed in parallel. Arnold Deborah Scherrer wrote: > All you folks revisiting the Software Tools should remember that there > was an entire movement around the first book, based at Lawrence Berkeley > Lab.  The Software Tools group, an offshoot of Usenix, had about 2000 > members.  We created an almost-entire Unix environment based on a > virtual operating system that we designed, inspired of course by > Kernighan's ideas.  The collection was ported to over 50 operating > systems, including some without file systems.   This is all still freely > available, and stored with the Unix archives. > > Deborah > > On 12/1/21 12:59 PM, Clem Cole wrote: > > Arnold -- sounds fun.  Thank you!!!  I'll add it to my growing pile of > > things I want to play with at some point.   I too had a wonderful > > childhood experience with the SW tools.  Somebody had a number of them > > running on a VMS box when all we had was the VMS Fortran compiler, no > > C yet. > > > > I am curious why did you decide to use byacc?   I would have thought > > in a desire to modernize and make it more available on a modern system > > -- was there something in byacc that could not be done easily in > > bison?   To be honest, I had thought Robert Corbett did them both and > > bison was the successor to byacc, but I'm not a compiler guy - so I'm > > suspecting that there must be a difference/reason.   As I said, this > > is purely curiosity -- an educational opportunity. > > > > Thanks again, > > Clem > > ᐧ > > > > On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: > > > > Hi All. > > > > Mainly for fun (sic), I decided to revive the Ratfor (Rational > > Fortran) preprocessor.  Please see: > > > > https://github.com/arnoldrobbins/ratfor > > > > I started with the V6 code, then added the V7, V8 and V10 versions > > on top of it. Each one has its own branch so that you can look > > at the original code, if you wish. The man page and the paper from > > the V7 manual are also included. > > > > Starting with the Tenth Edition version, I set about to modernize > > the code and get it to compile and run on a modern-day system. > > (ANSI style declarations and function headers, modern include files, > > use of getopt, and most importantly, correct use of Yacc yyval and > > yylval variables.) > > > > You will need Berkely Yacc installed as byacc in order to build it. > > > > I have only touch-tested it, but so far it seems OK.  'make' runs > > in like 2 > > seconds, really quick. On my Ubuntu Linux systems, it compiles with > > no warnings. > > > > I hope to eventually add a test suite also, if I can steal some time. > > > > Before anyone asks, no, I don't think anybody today has any real use > > for it.  This was simply "for fun", and because Ratfor has a soft > > spot in my heart.  "Software Tools" was, for me, the most influential > > programming book that I ever read.  I don't think there's a better > > book to convey the "zen" of Unix. > > > > Thanks, > > > > Arnold > > From arnold at skeeve.com Thu Dec 2 17:34:05 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Dec 2021 00:34:05 -0700 Subject: [TUHS] Ratfor revived! In-Reply-To: References: Message-ID: <202112020734.1B27Y5rJ028898@freefriends.org> Hi Clem. Clem Cole wrote: > I am curious why did you decide to use byacc? I did try Bison first. But, for reasons I have not yet fathomed, the code makes use of yyval (not yylval!), which is $$ in yacc productions. Bison does not make that available as a global variable. > To be honest, I had thought Robert Corbett did them both I am not sure of the exact provenance. My understanding is that RMS started with Corbett's yacc and built bison out of it. But I could be totally wrong. Arnold From clemc at ccc.com Fri Dec 3 00:15:43 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 2 Dec 2021 09:15:43 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: Henry -- most people that I am aware used the original Fortran-IV version since that was the Lingua-Franca. The Pascal version was a few years later, and frankly other than to read the book, I personally never ran the results from them. But I can say I did use the original Fortran version under VMS back in the day. As bwk says in the Pascal edition, it was actually a difficult thing to do because Pascal lacked many features that really made it uniform across implementations, portable between systems themselves, and as a reasonable systems programming language. See: Why Pascal is Not My Favorite Programming Language Clem ᐧ On Thu, Dec 2, 2021 at 12:44 AM Henry Bent wrote: > Thank you, Clem. I am working on getting the tools running in DOSBox, > which seemed most straightforward. > > The Byte article (the scan of which I am very grateful for; not having to > go trawling through the stacks at the Oberlin College library is always a > plus) claims that the tools have been implemented on: > > ACOS > Amdahl > Apollo > AN/UYK > Burroughs > CDC > Cray > Data General > DEC > FACOM > GEC > HP > HITAC > Honeywell > IBM > Intel > Interdata > Modcomp > Multics > NCR > Perkin-Elmer > Prime > Rolm > SEL > Tandem > Univac > Wang > Xerox > CP/M Machines > MS/DOS Machines > UNIX Machines > > Which is quite the list; I've never even heard of a few of those! Based > on the files in the UNIX Archive, am I to assume that most of those ports > took advantage of a native Pascal compiler? That's how I'm planning to > bring the tools up on my local RT-11 machine. > > -Henry > > On Wed, 1 Dec 2021 at 19:34, Clem Cole wrote: > >> https://www.tuhs.org/Archive/Applications/Software_Tools/ >> ᐧ >> >> On Wed, Dec 1, 2021 at 5:25 PM Henry Bent wrote: >> >>> On Wed, 1 Dec 2021 at 17:17, Deborah Scherrer < >>> dscherrer at solar.stanford.edu> wrote: >>> >>>> All you folks revisiting the Software Tools should remember that there >>>> was an entire movement around the first book, based at Lawrence Berkeley >>>> Lab. The Software Tools group, an offshoot of Usenix, had about 2000 >>>> members. We created an almost-entire Unix environment based on a virtual >>>> operating system that we designed, inspired of course by Kernighan's >>>> ideas. The collection was ported to over 50 operating systems, including >>>> some without file systems. This is all still freely available, and stored >>>> with the Unix archives. >>>> >>> Could you provide a link to said environment, and suggest what sort of >>> machines it might have run on? I probably have something here that will do >>> it, and I am very interested. >>> >>> -Henry >>> >>> >>>> On 12/1/21 12:59 PM, Clem Cole wrote: >>>> >>>> Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of >>>> things I want to play with at some point. I too had a wonderful childhood >>>> experience with the SW tools. Somebody had a number of them running on a >>>> VMS box when all we had was the VMS Fortran compiler, no C yet. >>>> >>>> I am curious why did you decide to use byacc? I would have thought in >>>> a desire to modernize and make it more available on a modern system -- was >>>> there something in byacc that could not be done easily in bison? To be >>>> honest, I had thought Robert Corbett did them both and bison was the >>>> successor to byacc, but I'm not a compiler guy - so I'm suspecting that >>>> there must be a difference/reason. As I said, this is purely curiosity -- >>>> an educational opportunity. >>>> >>>> Thanks again, >>>> Clem >>>> ᐧ >>>> >>>> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins >>>> wrote: >>>> >>>>> Hi All. >>>>> >>>>> Mainly for fun (sic), I decided to revive the Ratfor (Rational >>>>> Fortran) preprocessor. Please see: >>>>> >>>>> https://github.com/arnoldrobbins/ratfor >>>>> >>>>> I started with the V6 code, then added the V7, V8 and V10 versions >>>>> on top of it. Each one has its own branch so that you can look >>>>> at the original code, if you wish. The man page and the paper from >>>>> the V7 manual are also included. >>>>> >>>>> Starting with the Tenth Edition version, I set about to modernize >>>>> the code and get it to compile and run on a modern-day system. >>>>> (ANSI style declarations and function headers, modern include files, >>>>> use of getopt, and most importantly, correct use of Yacc yyval and >>>>> yylval variables.) >>>>> >>>>> You will need Berkely Yacc installed as byacc in order to build it. >>>>> >>>>> I have only touch-tested it, but so far it seems OK. 'make' runs in >>>>> like 2 >>>>> seconds, really quick. On my Ubuntu Linux systems, it compiles with >>>>> no warnings. >>>>> >>>>> I hope to eventually add a test suite also, if I can steal some time. >>>>> >>>>> Before anyone asks, no, I don't think anybody today has any real use >>>>> for it. This was simply "for fun", and because Ratfor has a soft >>>>> spot in my heart. "Software Tools" was, for me, the most influential >>>>> programming book that I ever read. I don't think there's a better >>>>> book to convey the "zen" of Unix. >>>>> >>>>> Thanks, >>>>> >>>>> Arnold >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Fri Dec 3 00:35:40 2021 From: brantley at coraid.com (Brantley Coile) Date: Thu, 2 Dec 2021 14:35:40 +0000 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: I lead a dual technological life. I usually don't talk about one side on email lists about the other. Sometimes creates heat. But I'm completely convinced of the value of both sides. Let's call one 1127, after the department number at Bell Labs, and the other Wirthian. Thomsonian and Wirthian would also be appropriate. I loved the WPNMFPL paper! Later, Wirth fixed all the language issues mentioned in that paper with his last language, Oberon. Some issues in the paper are issues of taste, and Oberon is, well, strongly Wirthian, so one might object to it if their taste corresponds with BWK's. DMR said at HOPL that Pascal and C have a lot in common. He said one might even expect there was information cross flow, which he stated there wasn't. That was what DMR said, not me. I program in C on Plan 9 because it's the best tool for what I'm doing. I could easily see me living in Oberon. I might even like it better. Some days. But then... See how great it is to live a duplicitous life. Best of both. Brantley > On Dec 2, 2021, at 9:15 AM, Clem Cole wrote: > > Henry -- most people that I am aware used the original Fortran-IV version since that was the Lingua-Franca. The Pascal version was a few years later, and frankly other than to read the book, I personally never ran the results from them. But I can say I did use the original Fortran version under VMS back in the day. As bwk says in the Pascal edition, it was actually a difficult thing to do because Pascal lacked many features that really made it uniform across implementations, portable between systems themselves, and as a reasonable systems programming language. See: Why Pascal is Not My Favorite Programming Language > > Clem > ᐧ > > On Thu, Dec 2, 2021 at 12:44 AM Henry Bent wrote: > Thank you, Clem. I am working on getting the tools running in DOSBox, which seemed most straightforward. > > The Byte article (the scan of which I am very grateful for; not having to go trawling through the stacks at the Oberlin College library is always a plus) claims that the tools have been implemented on: > > ACOS > Amdahl > Apollo > AN/UYK > Burroughs > CDC > Cray > Data General > DEC > FACOM > GEC > HP > HITAC > Honeywell > IBM > Intel > Interdata > Modcomp > Multics > NCR > Perkin-Elmer > Prime > Rolm > SEL > Tandem > Univac > Wang > Xerox > CP/M Machines > MS/DOS Machines > UNIX Machines > > Which is quite the list; I've never even heard of a few of those! Based on the files in the UNIX Archive, am I to assume that most of those ports took advantage of a native Pascal compiler? That's how I'm planning to bring the tools up on my local RT-11 machine. > > -Henry > > On Wed, 1 Dec 2021 at 19:34, Clem Cole wrote: > https://www.tuhs.org/Archive/Applications/Software_Tools/ > ᐧ > > On Wed, Dec 1, 2021 at 5:25 PM Henry Bent wrote: > On Wed, 1 Dec 2021 at 17:17, Deborah Scherrer wrote: > All you folks revisiting the Software Tools should remember that there was an entire movement around the first book, based at Lawrence Berkeley Lab. The Software Tools group, an offshoot of Usenix, had about 2000 members. We created an almost-entire Unix environment based on a virtual operating system that we designed, inspired of course by Kernighan's ideas. The collection was ported to over 50 operating systems, including some without file systems. This is all still freely available, and stored with the Unix archives. > > Could you provide a link to said environment, and suggest what sort of machines it might have run on? I probably have something here that will do it, and I am very interested. > > -Henry > > On 12/1/21 12:59 PM, Clem Cole wrote: >> Arnold -- sounds fun. Thank you!!! I'll add it to my growing pile of things I want to play with at some point. I too had a wonderful childhood experience with the SW tools. Somebody had a number of them running on a VMS box when all we had was the VMS Fortran compiler, no C yet. >> >> I am curious why did you decide to use byacc? I would have thought in a desire to modernize and make it more available on a modern system -- was there something in byacc that could not be done easily in bison? To be honest, I had thought Robert Corbett did them both and bison was the successor to byacc, but I'm not a compiler guy - so I'm suspecting that there must be a difference/reason. As I said, this is purely curiosity -- an educational opportunity. >> >> Thanks again, >> Clem >> ᐧ >> >> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: >> Hi All. >> >> Mainly for fun (sic), I decided to revive the Ratfor (Rational >> Fortran) preprocessor. Please see: >> >> https://github.com/arnoldrobbins/ratfor >> >> I started with the V6 code, then added the V7, V8 and V10 versions >> on top of it. Each one has its own branch so that you can look >> at the original code, if you wish. The man page and the paper from >> the V7 manual are also included. >> >> Starting with the Tenth Edition version, I set about to modernize >> the code and get it to compile and run on a modern-day system. >> (ANSI style declarations and function headers, modern include files, >> use of getopt, and most importantly, correct use of Yacc yyval and >> yylval variables.) >> >> You will need Berkely Yacc installed as byacc in order to build it. >> >> I have only touch-tested it, but so far it seems OK. 'make' runs in like 2 >> seconds, really quick. On my Ubuntu Linux systems, it compiles with >> no warnings. >> >> I hope to eventually add a test suite also, if I can steal some time. >> >> Before anyone asks, no, I don't think anybody today has any real use >> for it. This was simply "for fun", and because Ratfor has a soft >> spot in my heart. "Software Tools" was, for me, the most influential >> programming book that I ever read. I don't think there's a better >> book to convey the "zen" of Unix. >> >> Thanks, >> >> Arnold From arnold at skeeve.com Fri Dec 3 00:49:30 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Dec 2021 07:49:30 -0700 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: <202112021449.1B2EnUk2022868@freefriends.org> Clem Cole wrote: > See: Why Pascal is Not My Favorite Programming Language > Even better: https://github.com/arnoldrobbins/cstr100 This is the troff for that memo; I got it from BWK. :-) Arnold From cowan at ccil.org Fri Dec 3 02:30:35 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 2 Dec 2021 11:30:35 -0500 Subject: [TUHS] Ratfor revived! In-Reply-To: References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> Message-ID: On Thu, Dec 2, 2021 at 12:45 AM Henry Bent wrote: > The Byte article (the scan of which I am very grateful for; not having to > go trawling through the stacks at the Oberlin College library is always a > plus) claims that the tools have been implemented on: > > Tandem > That would be me; at least I registered it with Addison-Wesley, although someone else may have implemented it independently. I also wrote a shell that took advantage of Guardian-style IPC, using a per-user pipe server that connected up all the monodirectional pipes through itself. Its prompt was ::, which the documentation referred to as the quadpoint prompt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Fri Dec 3 04:34:45 2021 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Thu, 2 Dec 2021 10:34:45 -0800 Subject: [TUHS] Ratfor revived! In-Reply-To: <202112020741.1B27fFUc030032@freefriends.org> References: <4186ba55-8c1d-9a7b-f7f7-f45a86d3fe0c@solar.stanford.edu> <202112020741.1B27fFUc030032@freefriends.org> Message-ID: <2d362739-41da-4e39-8d19-c0302207151a@solar.stanford.edu> Oh no, the Georgia Tech guys were heavily involved with the Software Tools stuff at Lawrence Berkeley Lab.  Were in frequent contact.  Did a superb job of setting up the Tools there and extending them.  Good guys! Debbie On 12/1/21 11:41 PM, arnold at skeeve.com wrote: > Indeed. > > I never worked with this directly, though. I went to grad school > at Georgia Tech, where some of the students had started with the tools > from the book and built a beautiful Unix-like subsystem on top of > Primos on Pr1me minicomputers. (This code was recoverd in 2019, > after thinking it'd been lost for 30+ years!) > > I never asked, but I suspect that the Georgia Tech guys simply didn't > know about the LBL work, or else they developed in parallel. > > Arnold > > Deborah Scherrer wrote: > >> All you folks revisiting the Software Tools should remember that there >> was an entire movement around the first book, based at Lawrence Berkeley >> Lab.  The Software Tools group, an offshoot of Usenix, had about 2000 >> members.  We created an almost-entire Unix environment based on a >> virtual operating system that we designed, inspired of course by >> Kernighan's ideas.  The collection was ported to over 50 operating >> systems, including some without file systems.   This is all still freely >> available, and stored with the Unix archives. >> >> Deborah >> >> On 12/1/21 12:59 PM, Clem Cole wrote: >>> Arnold -- sounds fun.  Thank you!!!  I'll add it to my growing pile of >>> things I want to play with at some point.   I too had a wonderful >>> childhood experience with the SW tools.  Somebody had a number of them >>> running on a VMS box when all we had was the VMS Fortran compiler, no >>> C yet. >>> >>> I am curious why did you decide to use byacc?   I would have thought >>> in a desire to modernize and make it more available on a modern system >>> -- was there something in byacc that could not be done easily in >>> bison?   To be honest, I had thought Robert Corbett did them both and >>> bison was the successor to byacc, but I'm not a compiler guy - so I'm >>> suspecting that there must be a difference/reason.   As I said, this >>> is purely curiosity -- an educational opportunity. >>> >>> Thanks again, >>> Clem >>> ᐧ >>> >>> On Wed, Dec 1, 2021 at 3:41 PM Arnold Robbins wrote: >>> >>> Hi All. >>> >>> Mainly for fun (sic), I decided to revive the Ratfor (Rational >>> Fortran) preprocessor.  Please see: >>> >>> https://github.com/arnoldrobbins/ratfor >>> >>> I started with the V6 code, then added the V7, V8 and V10 versions >>> on top of it. Each one has its own branch so that you can look >>> at the original code, if you wish. The man page and the paper from >>> the V7 manual are also included. >>> >>> Starting with the Tenth Edition version, I set about to modernize >>> the code and get it to compile and run on a modern-day system. >>> (ANSI style declarations and function headers, modern include files, >>> use of getopt, and most importantly, correct use of Yacc yyval and >>> yylval variables.) >>> >>> You will need Berkely Yacc installed as byacc in order to build it. >>> >>> I have only touch-tested it, but so far it seems OK.  'make' runs >>> in like 2 >>> seconds, really quick. On my Ubuntu Linux systems, it compiles with >>> no warnings. >>> >>> I hope to eventually add a test suite also, if I can steal some time. >>> >>> Before anyone asks, no, I don't think anybody today has any real use >>> for it.  This was simply "for fun", and because Ratfor has a soft >>> spot in my heart.  "Software Tools" was, for me, the most influential >>> programming book that I ever read.  I don't think there's a better >>> book to convey the "zen" of Unix. >>> >>> Thanks, >>> >>> Arnold >>> From duncanmak at gmail.com Fri Dec 3 07:35:32 2021 From: duncanmak at gmail.com (Duncan Mak) Date: Thu, 2 Dec 2021 16:35:32 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > APL is a fascinating invention, but can be so compact as to be > inscrutable. (I confess not to have practiced APL enough to become > fluent.) In the same vein, Haskell's powerful higher-level functions > make middling fragments of code very clear, but can compress large > code to opacity. Jeremy Gibbons, a high priest of functional > programming, even wrote a paper about deconstructing such wonders for > improved readability. > I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html but didn't find anything resembling it. What's the name of the paper? -- Duncan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 3 08:32:40 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 2 Dec 2021 14:32:40 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <6F605F15-60D4-4780-B067-A750D76603A3@iitbombay.org> > On Dec 2, 2021, at 1:35 PM, Duncan Mak wrote: > > On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy wrote: > > APL is a fascinating invention, but can be so compact as to be > inscrutable. (I confess not to have practiced APL enough to become > fluent.) In the same vein, Haskell's powerful higher-level functions > make middling fragments of code very clear, but can compress large > code to opacity. Jeremy Gibbons, a high priest of functional > programming, even wrote a paper about deconstructing such wonders for > improved readability. > > I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html but didn't find anything resembling it. > > What's the name of the paper? The following paper seems APLicable here. Jeremy Gibbons also gave a delightful talk on this. https://www.47deg.com/media/2017/11/07/jeremy-gibbons-lambda-world-2017/ "APLicative Programming with Naperian Functors" https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf We show here that such a custom language design is unnecessary: the requisite compatibility checks can already be captured in modern expressive type systems, as found for example in Haskell; moreover, generative type-driven program- ming can exploit that static type information constructively to automat- ically induce the appropriate liftings. We show also that the structure of multi-dimensional data is inherently a matter of Naperian applicative functors -- lax monoidal functors, with strength, commutative up to isomorphism under composition -- that also support traversal. From robpike at gmail.com Fri Dec 3 08:34:49 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 3 Dec 2021 09:34:49 +1100 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: https://www.youtube.com/watch?v=ek1yjc9sSag On Fri, Dec 3, 2021 at 8:39 AM Duncan Mak wrote: > > On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy wrote: >> >> >> APL is a fascinating invention, but can be so compact as to be >> inscrutable. (I confess not to have practiced APL enough to become >> fluent.) In the same vein, Haskell's powerful higher-level functions >> make middling fragments of code very clear, but can compress large >> code to opacity. Jeremy Gibbons, a high priest of functional >> programming, even wrote a paper about deconstructing such wonders for >> improved readability. > > > I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html but didn't find anything resembling it. > > What's the name of the paper? > > -- > Duncan. From douglas.mcilroy at dartmouth.edu Fri Dec 3 12:50:20 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Dec 2021 21:50:20 -0500 Subject: [TUHS] Book Recommendation Message-ID: http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fission.pdf Duncan Mak wrote > Haskell's powerful higher-level functions > make middling fragments of code very clear, but can compress large > code to opacity. Jeremy Gibbons, a high priest of functional > programming, even wrote a paper about deconstructing such wonders for > improved readability. > I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html but didn't find anything resembling it. What's the name of the paper? From wkt at tuhs.org Sun Dec 5 07:36:50 2021 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 5 Dec 2021 08:36:50 +1100 Subject: [TUHS] UNIX/AT&T patent licensing In-Reply-To: References: Message-ID: <3ecf4c2b-0a58-fce1-4bfe-ec64901c78c4@tuhs.org> All, I got this e-mail forwarded on from John Fox via Eric S. Raymond. Cheers, Warren Hi Eric, I think you might find this interesting. I have a 2001 copy of your book. I dog-eared page 9 twenty years ago because of this section: It spread very rapidly with AT&T, in spite of the lack of any formal support program for it. By 1980 it had spread to a large number of university and research computing sites, and thousands of hackers considered it home. Regarding the "spread", I believe one of the contributing factors was AT&T's decision to give the source code away to universities. And in doing so, unwittingly provided the fertile soil for open source development. I happen to know the man who made that decision. He was my father-in-law. He died Tuesday. He had no idea what UNIX was, and had no idea what his decision helped to create. Funny when things we do have such a major impact without us even knowing. That was certainly true in this case. Anyway, I thought you'd be interested to know. His name is John (Jack) H. Bolt. He was 95. PS, before making the decision, he called Ken Olson at DEC to see if he'd be interested in buying it, lock, stock, and barrel. Jack's opening offer was $250k. Olson wasn't interested. And on that, Jack's decision was made. John Fox -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Mon Dec 6 14:25:11 2021 From: athornton at gmail.com (Adam Thornton) Date: Sun, 5 Dec 2021 21:25:11 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: Probably time to move this to COFF, but along the line of Fission for Program Comprehension.... I wonder how many of you don't know about Don Lancaster. Pioneer in home computing back when that meant something, inventor of a very low cost 1970s video terminal (the TV Typewriter), tremendously skilled hacker, brilliant guy. Also still alive, lives a couple hours away from me in Safford, AZ, and has been doing fantastic research on Native American hanging canals for the last couple decades. Anyway: he wrote a magnificent piece on how to understand a (6502) program from its disassembly, which reminded me of Gibbons's work: https://www.tinaja.com/ebooks/tearing_rework.pdf I don't think Don ever had a lot of crossover with the more academic world of Unix people, but he's one of my heroes and I have learned a hell of a lot from his works. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Mon Dec 6 14:42:07 2021 From: halbert at halwitz.org (Dan Halbert) Date: Sun, 5 Dec 2021 23:42:07 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <261e2007-a199-b436-f881-8a5f821f86ba@halwitz.org> On 12/5/21 11:25 PM, Adam Thornton wrote: > I wonder how many of you don't know about Don Lancaster. > > Pioneer in home computing back when that meant something, inventor of > a very low cost 1970s video terminal (the TV Typewriter), tremendously > skilled hacker, brilliant guy. > In 1970, in eighth grade, I learned digital logic from his "RTL Cookbook" and the SWTPC Digital Logic Microlab, from Popular Electronics: https://www.tinaja.com/glib/microlab.pdf, both of which I still have. From sauer at technologists.com Mon Dec 6 15:18:49 2021 From: sauer at technologists.com (Charles H. Sauer) Date: Sun, 5 Dec 2021 23:18:49 -0600 Subject: [TUHS] Book Recommendation In-Reply-To: <261e2007-a199-b436-f881-8a5f821f86ba@halwitz.org> References: <261e2007-a199-b436-f881-8a5f821f86ba@halwitz.org> Message-ID: <07160F1F-2B40-4E7C-9159-7A5297DE697F@technologists.com> > On Dec 5, 2021, at 10:42 PM, Dan Halbert wrote: > > On 12/5/21 11:25 PM, Adam Thornton wrote: >> I wonder how many of you don't know about Don Lancaster. >> >> Pioneer in home computing back when that meant something, inventor of a very low cost 1970s video terminal (the TV Typewriter), tremendously skilled hacker, brilliant guy. >> > > In 1970, in eighth grade, I learned digital logic from his "RTL Cookbook" and the SWTPC Digital Logic Microlab, from Popular Electronics: https://www.tinaja.com/glib/microlab.pdf, both of which I still have. In 1972, while i was still ambivalent about my music ambitions, in the second year of my transition to computer ambitions, pondering the combination of those ambitions, I built one of Lancaster’s function generator projects, depicted on the cover at https://worldradiohistory.com/Archive-Radio-Electronics/70s/1972/Radio-Electronics-1972-09.pdf . I think i still have it in the garage, but am not sure if I could still get it to work. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 7 00:11:46 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Dec 2021 09:11:46 -0500 Subject: [TUHS] [COFF] Book Recommendation In-Reply-To: References: Message-ID: Adam - first thank you. Pleased to know he's still kicking around. On Sun, Dec 5, 2021 at 11:26 PM Adam Thornton wrote: > I don't think Don ever had a lot of crossover with the more academic world > of Unix people, but he's one of my heroes and I have learned a hell of a > lot from his works. > Not true at all. If you grew up as EE, in the late 1960s/early 1970s it was hard to not know about him since he was so prolific. FWIW, before I went to CMU, he was already a hero and I had a number of books from the late 1960's. When I was freshman in the early 1970s, his TTL Cookbook was an optional text for the intro to EE course [I already had it but a number of my mates had never seen it before]. His CMOS Cookbox was not published yet, but when it was, I bought it. Side story, I want to say about 1969/70, after reading one of his articles in Radio-Electronics I sent him a (US snail mail) letter asking him for help in designing an RF interface to a TV. He replied to me but told me such a design would be illegal to make as it would run afoul of FCC rules. I wish I had kept that letter, but he reversed himself a few years later with his TV Typewriter and Son of Video books. My guess is he had been researching the idea for one of the magazines when I contacted him, and must have gotten a ruling from legal counsel about publishing the same. I always wondered what made him change his mind a few years later. Since he seems to publish an email, I think I'll have to write him and ask that way to see if he responds. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Dec 7 00:22:05 2021 From: crossd at gmail.com (Dan Cross) Date: Mon, 6 Dec 2021 09:22:05 -0500 Subject: [TUHS] [COFF] Book Recommendation In-Reply-To: References: Message-ID: [TUHS to Bcc] On Mon, Dec 6, 2021 at 9:15 AM Clem Cole wrote: > Adam - first thank you. Pleased to know he's still kicking around. > > On Sun, Dec 5, 2021 at 11:26 PM Adam Thornton wrote: > >> I don't think Don ever had a lot of crossover with the more academic >> world of Unix people, but he's one of my heroes and I have learned a hell >> of a lot from his works. >> > Not true at all. If you grew up as EE, in the late 1960s/early 1970s it > was hard to not know about him since he was so prolific. FWIW, before I > went to CMU, he was already a hero and I had a number of books from the > late 1960's. When I was freshman in the early 1970s, his TTL Cookbook was > an optional text for the intro to EE course [I already had it but a number > of my mates had never seen it before]. His CMOS Cookbox was not published > yet, but when it was, I bought it. > Indeed, still well-known: I have both his TTL and CMOS cookbooks within easy reach. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Dec 7 00:29:24 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Dec 2021 09:29:24 -0500 (EST) Subject: [TUHS] [COFF] Book Recommendation Message-ID: <20211206142924.A8A7118C079@mercury.lcs.mit.edu> OK, this is my last _civil_ request to stop email-bombing both lists with trafic. In the future, I will say publicly _exactly_ what I think - and if screens still had phosphor, it would probably peel it off. I can see that there are cases when one might validly want to post to both lists - e.g. when starting a new discusson. However, one of the two should _always_ be BCC'd, so that simple use of reply won't generate a copy to both. I would suggest that one might say something like 'this discussion is probably best continued on the list' - which could be seeded by BCCing the _other_. Thank you. Noel From bryan at bryanstamour.com Tue Dec 7 03:27:09 2021 From: bryan at bryanstamour.com (Bryan St. Amour) Date: Mon, 6 Dec 2021 12:27:09 -0500 Subject: [TUHS] New Member Message-ID: <064d2267-f9f5-7bde-a316-a14198c7ec00@bryanstamour.com> Hello! I have just joined this mailing list recently, and figured I would give an introduction to myself. My first encounter with Unix took place in 2006 when I started my undergraduate studies in Computer Science. The main servers all ran Solaris, and we accessed them via thin clients. Eventually I wanted a similar feeling operating system for my personal computer, so that I could do my assignments without having to always log into the school servers, and so I came across Linux. I hopped around for a while, but eventually settled with Slackware for my personal computers. Nowadays I run a mixture of Linux and BSD operating systems for various purposes. Unfortunately my day job has me writing desktop software for Windows (no fun there :(), so I'm thankful to have found a group of people with similar computing interests as myself, and I look forward to chatting with you all! Regards, Bryan St. Amour From jjacocks at mac.com Wed Dec 8 03:28:40 2021 From: jjacocks at mac.com (Alexander Jacocks) Date: Tue, 7 Dec 2021 12:28:40 -0500 Subject: [TUHS] Belated Introduction Message-ID: <1A9B771F-48C2-4AEE-B170-A1749E067773@mac.com> Spurred on by Bryan, I thought I should properly introduce myself: I am a fairly young Unix devotee, having gotten my start with System V on a Wang word processing system (believe it or not, they made one!), at my mother’s office, in the late 1980s. My first personal system, which ran SLS Linux, came about in 1992. I am a member of the Vintage Computing Federation, and have given talks and made exhibits on Unix history at VCF’s museum, in Wall, New Jersey. I have also had the pleasure to show Brian Kernighan and Ken Thompson, who are two of my computing heroes, my exhibit on the origins of BSD Unix on the Intel 386. I learned C from Brian’s book, as probably did many others here. I have spent my entire professional career supporting Unix, in some form or another. I started with SunOS at the National Institutes of Health, in Bethesda, Maryland, and moved on to Solaris, HP-UX, SCO, and finally Linux. I worked for AT&T, in Virginia, in the early 2000s, but there were few vestiges of Unix present, other than some 3b1 and 3b2 monitors and keyboards. I current work for Red Hat, in Tyson’s Corner, Virginia, as a principal sales engineer, where I spend most of my time teaching and presenting at conferences, both in person and virtual. Thank you to everyone here who created the tools that have enabled my career and love of computing! - Alexander Jacocks From arnold at skeeve.com Wed Dec 15 18:44:44 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 15 Dec 2021 01:44:44 -0700 Subject: [TUHS] efl(1) anyone? Message-ID: <202112150844.1BF8iibJ012519@freefriends.org> Hi TUHS folks! After having reincarnated ratfor, I am wondering about Stuart Feldman's efl (extended fortran language). It was a real compiler that let you define structs, and generated more or less readable Fortran code. I have the impression that it was pretty cool, but that it just didn't catch on. So: - Did anyone here ever use it personally? - Is my impression that it didn't catch on correct? Or am I ignorant? Thoughts etc. welcome. :-) Thanks, Arnold From cowan at ccil.org Thu Dec 16 02:25:42 2021 From: cowan at ccil.org (John Cowan) Date: Wed, 15 Dec 2021 11:25:42 -0500 Subject: [TUHS] efl(1) anyone? In-Reply-To: <202112150844.1BF8iibJ012519@freefriends.org> References: <202112150844.1BF8iibJ012519@freefriends.org> Message-ID: On Wed, Dec 15, 2021 at 3:48 AM wrote: > - Is my impression that it didn't catch on correct? Or am I ignorant? > My sense after the fact (I wasn't there and could only see the published stuff) is that EFL couldn't compete with the f77 (later f2c) compiler, which came out at about the same time. Because the EFL compiler parses the whole language, unlike Ratfor, it can't cope with extensions to Fortran 66+, so it is stuck in the deep past. Ratfor "does not know [much] Fortran", so if you want to use some new-style declarations or '77-or-later `format' specifiers in Ratfor code, you're cool. (Although by now Fortran probably does everything Ratfor does, although in a much less C-ish way.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.manos at gmail.com Fri Dec 17 03:56:49 2021 From: tom.manos at gmail.com (Tom Manos) Date: Thu, 16 Dec 2021 12:56:49 -0500 Subject: [TUHS] efl(1) anyone? In-Reply-To: <202112150844.1BF8iibJ012519@freefriends.org> References: <202112150844.1BF8iibJ012519@freefriends.org> Message-ID: I'm late to the party here. Although I'm a gray hair, I didn't start using UNIX until the early '80s, and though I've seen, and been curious about efl, I've never used it. Fortran 4 was my first high-level language in college in the '70s. That said, I do remember efl being on an early PC based UNIX - Microport SVR2. On later Microport UNIXen it was gone, but I can't remember whether it disappeared on SVR3 or 4. I currently play with 4.3BSD Quasijarus system on simh, which has efl. What a fun system to play with! Maybe I'll give efl a try if I can find enough docs to grok it. Tom ---- Tom Manos KO4ENQ On Wed, Dec 15, 2021 at 3:49 AM wrote: > Hi TUHS folks! > > After having reincarnated ratfor, I am wondering about Stuart Feldman's > efl (extended fortran language). It was a real compiler that let you > define structs, and generated more or less readable Fortran code. > > I have the impression that it was pretty cool, but that it just didn't > catch on. So: > > - Did anyone here ever use it personally? > > - Is my impression that it didn't catch on correct? Or am I ignorant? > > Thoughts etc. welcome. :-) > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Dec 17 08:38:02 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 16 Dec 2021 17:38:02 -0500 Subject: [TUHS] efl(1) anyone? In-Reply-To: References: <202112150844.1BF8iibJ012519@freefriends.org> Message-ID: Not, trying to discourage anyone from messing with simh and one of the old UNIX systems - looking at the past. But to be honest at this stage of the game there is nothing in EFL that I know of that modern Fortran can not do. And if you want to see how the world has progressed since F4, and you have a Mac, Linux or Windows box -- the entire Intel compiler suite, including their Fortran 2018 compatible system can be downloaded for free -- Intel OneAPI HPC Toolkit Download This is the compiler many (most) supercomputer codes use - why is a good COFF discussion ;-) For the youngsters that never saw it, is a piece of F4 code [the Intel compiler can still gork it BTW], which we call the 'Eklund Test' as Dave Eklund was Mr. Fixed format for both DEC and Intel starting in the early 1970s until he retired 5 years ago [note Dave did not write this - came from Europe but is now part of the Intel compiler test suite]. C This FORTRAN program may be compiled and run on a Norsk Data C computer running SINTRAN and the FTN compiler. It uses only C FORTRAN reserved words, and contains just one numerical C constant, in a character string (a format specifier). When C you run it, it prints a well known mathematical construct... C C Even FORTRAN is a block structured programming language: C PROGRAM ;PROGRAM;INTEGERIF,INTEGER,GOTO,IMPLICIT;REALREAL,DIMENSION,EXTERNA AL,FORMAT,END;INTEGERLOGICAL;REALCOMPLEX,DATA,CALL,ASSIGN,CHARACTER R;DOFORIF=INTEGER,INTEGER;ENDDO;INTEGER=IF+IF;GOTO=INTEGER*INTEGER* *INTEGER*INTEGER-INTEGER-IF;CALLFUNCTION(IMPLICIT,REAL,DIMENSION,EX XTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA,CALL,ASSIGN,CHARACTER);CALL LSUBROUTINE(IMPLICIT,LOGICAL,GOTO,IF,INTEGER);END;SUBROUTINEFUNCTIO ON(IMPLICIT,REAL,DIMENSION,EXTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA A,CALL,ASSIGN,CHARACTER);RETURN;END;SUBROUTINESUBROUTINE(IMPLICIT,L LOGICAL,GOTO,IF,INTEGER);INTEGERGOTO,IMPLICIT(GOTO),LOGICAL(GOTO),I IF,INTEGER,EXTERNAL,RETURN;DOFOREXTERNAL=IF,GOTO;DOFORRETURN=INTEGE ER,EXTERNAL-IF;IMPLICIT(RETURN)=LOGICAL(RETURN)+LOGICAL(RETURN-IF); ;ENDDO;IMPLICIT(IF)=IF;IMPLICIT(EXTERNAL)=IF;DOFORRETURN=IF,GOTO-EX XTERNAL;WRITE(IF,'(''$ '')');ENDDO;DOFORRETURN=IF,EXTERNAL;WRITE(I IF,'(''$''I4)')IMPLICIT(RETURN);ENDDO;WRITE(IF,'( /)');DOFORRETURN= =IF,GOTO;LOGICAL(RETURN)=IMPLICIT(RETURN);ENDDO;ENDDO;END On Thu, Dec 16, 2021 at 12:57 PM Tom Manos wrote: > I'm late to the party here. Although I'm a gray hair, I didn't start using > UNIX until the early '80s, and though I've seen, and been curious about > efl, I've never used it. Fortran 4 was my first high-level language in > college in the '70s. > > That said, I do remember efl being on an early PC based UNIX - Microport > SVR2. On later Microport UNIXen it was gone, but I can't remember whether > it disappeared on SVR3 or 4. > > I currently play with 4.3BSD Quasijarus system on simh, which has efl. > What a fun system to play with! Maybe I'll give efl a try if I can find > enough docs to grok it. > > Tom > ---- > Tom Manos > KO4ENQ > > > On Wed, Dec 15, 2021 at 3:49 AM wrote: > >> Hi TUHS folks! >> >> After having reincarnated ratfor, I am wondering about Stuart Feldman's >> efl (extended fortran language). It was a real compiler that let you >> define structs, and generated more or less readable Fortran code. >> >> I have the impression that it was pretty cool, but that it just didn't >> catch on. So: >> >> - Did anyone here ever use it personally? >> >> - Is my impression that it didn't catch on correct? Or am I ignorant? >> >> Thoughts etc. welcome. :-) >> >> Thanks, >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.manos at gmail.com Fri Dec 17 09:41:00 2021 From: tom.manos at gmail.com (Tom Manos) Date: Thu, 16 Dec 2021 18:41:00 -0500 Subject: [TUHS] efl(1) anyone? In-Reply-To: References: <202112150844.1BF8iibJ012519@freefriends.org> Message-ID: Clem, I agree with everything you said. I think the operative word here is "playing". I'm not aware of anyone who would use either 4.3BSD or efl for real work. It's just fun to mess around with some things from the somewhat distant past that we missed along the way. For me, right now, that's BSD, which I used at Naval Postgraduate School in the mid-80s, but never after. After I left grad school, all I was exposed to was SVR2-4 and then OSF/1 and then Solaris from the mid 90's on. BSD is fun. Tom ---- Tom Manos Vivat Jesus KO4ENQ On Thu, Dec 16, 2021 at 12:56 PM Tom Manos wrote: > I'm late to the party here. Although I'm a gray hair, I didn't start using > UNIX until the early '80s, and though I've seen, and been curious about > efl, I've never used it. Fortran 4 was my first high-level language in > college in the '70s. > > That said, I do remember efl being on an early PC based UNIX - Microport > SVR2. On later Microport UNIXen it was gone, but I can't remember whether > it disappeared on SVR3 or 4. > > I currently play with 4.3BSD Quasijarus system on simh, which has efl. > What a fun system to play with! Maybe I'll give efl a try if I can find > enough docs to grok it. > > Tom > ---- > Tom Manos > KO4ENQ > > > On Wed, Dec 15, 2021 at 3:49 AM wrote: > >> Hi TUHS folks! >> >> After having reincarnated ratfor, I am wondering about Stuart Feldman's >> efl (extended fortran language). It was a real compiler that let you >> define structs, and generated more or less readable Fortran code. >> >> I have the impression that it was pretty cool, but that it just didn't >> catch on. So: >> >> - Did anyone here ever use it personally? >> >> - Is my impression that it didn't catch on correct? Or am I ignorant? >> >> Thoughts etc. welcome. :-) >> >> Thanks, >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Sat Dec 18 18:11:14 2021 From: steve at quintile.net (Steve Simon) Date: Sat, 18 Dec 2021 08:11:14 +0000 Subject: [TUHS] efl Message-ID: <2788C381-789B-4B66-8749-AB330D3D08C1@quintile.net> hi, having supported Pafec and then in a different job flow3d, i was most interested in anything that could make large fortran packages more manageable. there was a commercial package called Spag i which claimed to un-spagatti-ify your code which i always wanted but, could never afford. the best i managed was sed and awk scripts to split huge fortran files into one file per function and build a makefile. this at least made rebuilds quicker. i do not miss maintaining fortran code hacked by dozens of people over many decades. -Steve From dave at plonka.us Sun Dec 19 11:00:04 2021 From: dave at plonka.us (Dave Plonka) Date: Sat, 18 Dec 2021 19:00:04 -0600 Subject: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest! Message-ID: Hi folks! While doing some end of year retrocomputing revisiting, I thought some of you might enjoy this - there is hope for the next generation(s)! ;) https://www.youtube.com/watch?v=_Zyng5Ob-e8 In this video I share my personal pick for "best" demo at VCF Midwest: Gavin's PDP 11/23 running UNIX Version 6! We write and run a simple BASIC program in Ken Thompson's bas(1), finding some quirks with this (currently) entirely floppy-based system, possible having to do with a glitch in disk I/O. (We discovered bas(1) uses a temporary file as backing store.) Filmed at the Vintage Computer Festival Midwest: VCF Midwest 16, September 11, 2021 http://vcfmw.org/ Here's the source code to the simple program we wrote; you can also run it on modern machines if you install a Research UNIX version using SimH (pdp-11 simulator). 5 goto 30 10 for col = 1 arg(1) 12 prompt " " 14 next 20 print "Welcome to VCF Midwest!" 25 return 30 for x = 0 55 40 10(x) 50 next 60 for x = _56 _1 70 10(_x) 80 next -- dave at plonka.us http://www.cs.wisc.edu/~plonka/ From arnold at skeeve.com Sun Dec 19 17:54:10 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 19 Dec 2021 00:54:10 -0700 Subject: [TUHS] efl In-Reply-To: <2788C381-789B-4B66-8749-AB330D3D08C1@quintile.net> References: <2788C381-789B-4B66-8749-AB330D3D08C1@quintile.net> Message-ID: <202112190754.1BJ7sAMt028858@freefriends.org> Steve, Were you not aware of struct(1)? It was in V7 and BSD. It would read regular Fortran and turn it into ratfor. I never used it, but I thought it was the coolest kind of thing. Arnold Steve Simon wrote: > hi, > > having supported Pafec and then in a different job flow3d, i was most > interested in anything that could make large fortran packages more > manageable. > > there was a commercial package called Spag i which claimed to > un-spagatti-ify your code which i always wanted but, could never afford. > > the best i managed was sed and awk scripts to split huge fortran files > into one file per function and build a makefile. this at least made > rebuilds quicker. > > i do not miss maintaining fortran code hacked by dozens of people over > many decades. > > -Steve > From bakul at iitbombay.org Sun Dec 19 18:08:11 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 19 Dec 2021 00:08:11 -0800 Subject: [TUHS] efl In-Reply-To: <202112190754.1BJ7sAMt028858@freefriends.org> References: <2788C381-789B-4B66-8749-AB330D3D08C1@quintile.net> <202112190754.1BJ7sAMt028858@freefriends.org> Message-ID: On Dec 18, 2021, at 11:54 PM, arnold at skeeve.com wrote: > > Steve, > > Were you not aware of struct(1)? It was in V7 and BSD. It would read > regular Fortran and turn it into ratfor. > > I never used it, but I thought it was the coolest kind of thing. So did I! I used it to convert an early PAL assembler (palasm?) from FORTRAN IV to ratfor and then I hand translated it to C. I don't recall if there was a need for this or I just felt like it! This was possibly before AMD introduced PAL22V10. IIRC we used PAL16V8s on the Fortune box. From douglas.mcilroy at dartmouth.edu Mon Dec 20 00:37:12 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 19 Dec 2021 09:37:12 -0500 Subject: [TUHS] {TUHS} efl Message-ID: > there was a commercial package called Spag i which claimed to un-spagatti-ify your code which i always wanted but, could never afford. You needed struct(1) in v7. It did precisely that, converting Fortran to Ratfor. Amazingly (to me, anyway) it embodied a theorem: a Fortran program has a canonical form. People found the converted code to be easier to understand--even when they had written the original code themselves. Doug From pnr at planet.nl Mon Dec 20 03:25:34 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 19 Dec 2021 18:25:34 +0100 Subject: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest! Message-ID: <55817161-038A-4358-8D4D-2D938578583A@planet.nl> > While doing some end of year retrocomputing revisiting, I thought some > of you might enjoy this - there is hope for the next generation(s)! ;) > https://www.youtube.com/watch?v=_Zyng5Ob-e8 Thanks for that video link! I noticed the bit at the end about V6 and the occasional dropped character and that this was not a serial line issue. I have the same issue in my V6 port to the TI-990 and always assumed that it was a bug I introduced myself when hacking the tty driver. Does anyone remember, was this a real life bug back in 6th edition back in the 1970’s? Maybe only showing at higher baud rates? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Mon Dec 20 11:19:08 2021 From: torek at elf.torek.net (Chris Torek) Date: Sun, 19 Dec 2021 17:19:08 -0800 (PST) Subject: [TUHS] {TUHS} efl In-Reply-To: Message-ID: <202112200119.1BK1J7QS039714@elf.torek.net> >You needed struct(1) in v7. You mentioned this before (https://minnie.tuhs.org/pipermail/tuhs/2020-March/020670.html). Personally, I don't know why Brenda Baker isn't famous. >People found the converted code to be easier to understand--even >when they had written the original code themselves. I ran it on a number of Fortran programs in the EE department at the U of MD. When it *didn't* resolve loops into Ratfor style WHILE constructs and the like, it usually meant there was a bug. I found at least two or three bugs this way. Chris From dave at plonka.us Tue Dec 21 01:43:56 2021 From: dave at plonka.us (Dave Plonka) Date: Mon, 20 Dec 2021 09:43:56 -0600 Subject: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest! In-Reply-To: <55817161-038A-4358-8D4D-2D938578583A@planet.nl> References: <55817161-038A-4358-8D4D-2D938578583A@planet.nl> Message-ID: Hi Paul We talked about this a bit more in the comments on the video, with Gavin doing some experiment afterwards. While at the show, one experiment we did was to redirection the bas(1)ic program's output to a file and what we found was that (a) characters would still sometimes be lost (which is how we determined it's not due to a serial communications, directly and (b) the dropped characters would coalesce together into a small run. Gavin's speculation at the time was that the floppy driver interfered/interrupted the bas' output somehow, since we noticed there was also disk activity coinciding roughly in time with a bout of dropped characters. What is unusual about Gavin's machine (at the time of this video) is that everything was on floppies - including root, tmp, etc. because he did not have a functioning fixed disk yet. It may be a configuration that was rarely used, e.g., scratch space for bas on floppy. (We found bas seems to read the source code from the file system even at runtime.) Any insights welcome - esp. if you can put them in the comments there. Peace, Dave On Sun, Dec 19, 2021 at 11:25 AM Paul Ruizendaal wrote: > > While doing some end of year retrocomputing revisiting, I thought some > of you might enjoy this - there is hope for the next generation(s)! ;) > https://www.youtube.com/watch?v=_Zyng5Ob-e8 > > > > Thanks for that video link! > > I noticed the bit at the end about V6 and the occasional dropped character and that this was not a serial line issue. I have the same issue in my V6 port to the TI-990 and always assumed that it was a bug I introduced myself when hacking the tty driver. > > Does anyone remember, was this a real life bug back in 6th edition back in the 1970’s? Maybe only showing at higher baud rates? > > Paul > -- dave at plonka.us http://www.cs.wisc.edu/~plonka/ From clemc at ccc.com Tue Dec 21 02:30:12 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Dec 2021 11:30:12 -0500 Subject: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest! In-Reply-To: References: <55817161-038A-4358-8D4D-2D938578583A@planet.nl> Message-ID: Dave/Paul First Sixth Edition does not have support for either the 11/23 or a floppy. So your issues might be found in either place. Where did you get the modifications? Maybe: https://www.hamartun.priv.no/v6unix.html Your guess WRT to floppy being the source, would be where I started to poke. Frankly, early UNIX when ported to a system with a floppy has a lot of issues [we did this at Tektronix in the early late 1970s for the magnolia and some of its siblings). Take a look at the physical floppy - you will notice a lack of magnetic material near the center of the diskette. This is the i-list and v6 (and v7) hits it pretty hard. Caching of the inodes was added later, but was thought to do on the 11s due to lack of address space [you need to BSD 2.X later versions and generally need support for separate I/D 11 and a lot more physical memory]. I thought I remember that the 11/23 is a 11/40 class processor, not a 45 class so it lacks the '17th' bit as it were, although I think it can support more the 256K bytes of memory, but again it takes hacking V6 to enable and use it. One thing you could do is put the kernel image on simh [ https://github.com/simh/simh] or Ersatz11 [http://www.dbit.com/] and try it with an 11/40 and an RK05 emulator instead of the 11/23 and floppy since 11/40 with an RK05 and RP03/04 were the native distribution. Then try to change processors, and finally disks on the emulation. BTW: it if works fine with an emulated floppy [I would not be surprised if it does] I would look at the driver. I would think that it is possible for the floppy driver is causing the 11/23 to have missed interrupts with how the spl()/splx() calls are working [which can get tricky and easy to be 'almost right']. One other thought, I'm pretty sure that Noel's V6+ system from MIT can support a 23 but I don't know about floppies, you might try his image. Check out gunkies - https://gunkies.org/wiki/UNIX_Sixth_Edition, but Noel might reply here directly with more info. Have fun. Clem ᐧ On Mon, Dec 20, 2021 at 10:45 AM Dave Plonka wrote: > Hi Paul > > We talked about this a bit more in the comments on the video, with > Gavin doing some experiment afterwards. > > While at the show, one experiment we did was to redirection the > bas(1)ic program's output to a file and what we found was that (a) > characters would still sometimes be lost (which is how we determined > it's not due to a serial communications, directly and (b) the dropped > characters would coalesce together into a small run. > > Gavin's speculation at the time was that the floppy driver > interfered/interrupted the bas' output somehow, since we noticed there > was also disk activity coinciding roughly in time with a bout of > dropped characters. > > What is unusual about Gavin's machine (at the time of this video) is > that everything was on floppies - including root, tmp, etc. because he > did not have a functioning fixed disk yet. It may be a configuration > that was rarely used, e.g., scratch space for bas on floppy. (We found > bas seems to read the source code from the file system even at > runtime.) > > Any insights welcome - esp. if you can put them in the comments there. > > Peace, > Dave > > On Sun, Dec 19, 2021 at 11:25 AM Paul Ruizendaal wrote: > > > > While doing some end of year retrocomputing revisiting, I thought some > > of you might enjoy this - there is hope for the next generation(s)! ;) > > https://www.youtube.com/watch?v=_Zyng5Ob-e8 > > > > > > > > Thanks for that video link! > > > > I noticed the bit at the end about V6 and the occasional dropped > character and that this was not a serial line issue. I have the same issue > in my V6 port to the TI-990 and always assumed that it was a bug I > introduced myself when hacking the tty driver. > > > > Does anyone remember, was this a real life bug back in 6th edition back > in the 1970’s? Maybe only showing at higher baud rates? > > > > Paul > > > > > -- > > dave at plonka.us http://www.cs.wisc.edu/~plonka/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyrille.lefevre-lists at laposte.net Tue Dec 21 23:55:55 2021 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Tue, 21 Dec 2021 14:55:55 +0100 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> Message-ID: <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> Hi, Here are some ksh versions... http://cyrillelefevre.free.fr/ksh/ ksh86a-toolchest.tar.bz2 314427 ksh88c-hpux-9.10.tar.bz2 169413 ksh88d-svr4.tar.bz2 132718 ksh88f-i18n-irix-6.5.5.tar.bz2 160563 ksh88f-irix-6.5.7.tar.bz2 215090 ksh88g-sco-unixware7.tar.bz2 195282 ksh88h-sco-unixware7.tar.bz2 147194 ksh88i-solaris-2.5.tar.bz2 149477 ksh88i-solaris-2.6.tar.bz2 159219 ksh88i-solaris-2.7.tar.bz2 163976 ksh88i-solaris-2.8.tar.bz2 164771 ksh93e-sco-unixware7.tar.bz2 542380 Le 23/12/2020 à 08:19, Efton Collins a écrit : > here is a link to a ksh version that seems to predate ksh88, msg.c > says "Version 06/03/86a": > https://github.com/weiss/original-bsd/tree/master/local/toolchest/ksh > > I found the link at the bottom of this interesting page: > https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html > > and this link contains a surprising amount of information on many > shell versions released over the years - > https://www.in-ulm.de/~mascheck/various/shells > > On 12/22/20, Scot Jenkins via TUHS wrote: >> Warren Toomey wrote: >> >>> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >>> search for it on-line doesn't reveal it. Does anybody have a copy? >> https://archive.org/details/ATTUNIXSystemVRelease4Version2 >> has source for several releases. >> >> click "show all" on the right under "download options", >> the file sysvr4.tar.bz2 has source for ksh88: >> >> from cmd/ksh/sh/msg.c: >> msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; >> >> I think this was for x86 PCs. I haven't tried to build it. >> The date on the files is Jan 25 1993. >> >> scot >> > -- mailto:Cyrille.Lefevre-lists at laposte.net From lm at mcvoy.com Wed Dec 22 02:21:39 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Dec 2021 08:21:39 -0800 Subject: [TUHS] ksh88 source code? In-Reply-To: <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> Message-ID: <20211221162139.GP24180@mcvoy.com> I get the historical interest, but in today's world, is there any advantage to ksh over bash? I get that lots of scripts are run with /bin/sh and it is nice when that is fast, but aren't the cpus fast enough these days that it sort of doesn't matter? On Tue, Dec 21, 2021 at 02:55:55PM +0100, Cyrille Lefevre via TUHS wrote: > Hi, Here are some ksh versions... > > http://cyrillelefevre.free.fr/ksh/ > > ksh86a-toolchest.tar.bz2 314427 > ksh88c-hpux-9.10.tar.bz2 169413 > ksh88d-svr4.tar.bz2 132718 > ksh88f-i18n-irix-6.5.5.tar.bz2 160563 > ksh88f-irix-6.5.7.tar.bz2 215090 > ksh88g-sco-unixware7.tar.bz2 195282 > ksh88h-sco-unixware7.tar.bz2 147194 > ksh88i-solaris-2.5.tar.bz2 149477 > ksh88i-solaris-2.6.tar.bz2 159219 > ksh88i-solaris-2.7.tar.bz2 163976 > ksh88i-solaris-2.8.tar.bz2 164771 > ksh93e-sco-unixware7.tar.bz2 542380 > > Le 23/12/2020 ? 08:19, Efton Collins a ?crit?: > >here is a link to a ksh version that seems to predate ksh88, msg.c > >says "Version 06/03/86a": > >https://github.com/weiss/original-bsd/tree/master/local/toolchest/ksh > > > >I found the link at the bottom of this interesting page: > >https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html > > > >and this link contains a surprising amount of information on many > >shell versions released over the years - > >https://www.in-ulm.de/~mascheck/various/shells > > > >On 12/22/20, Scot Jenkins via TUHS wrote: > >>Warren Toomey wrote: > >> > >>>Hi all, I received an e-mail looking for the ksh-88 source code. A quick > >>>search for it on-line doesn't reveal it. Does anybody have a copy? > >>https://archive.org/details/ATTUNIXSystemVRelease4Version2 > >>has source for several releases. > >> > >>click "show all" on the right under "download options", > >>the file sysvr4.tar.bz2 has source for ksh88: > >> > >>from cmd/ksh/sh/msg.c: > >>msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > >> > >>I think this was for x86 PCs. I haven't tried to build it. > >>The date on the files is Jan 25 1993. > >> > >>scot > >> > > > -- > mailto:Cyrille.Lefevre-lists at laposte.net > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From imp at bsdimp.com Wed Dec 22 02:27:58 2021 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Dec 2021 10:27:58 -0600 Subject: [TUHS] ksh88 source code? In-Reply-To: <20211221162139.GP24180@mcvoy.com> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: On Tue, Dec 21, 2021, 10:22 AM Larry McVoy wrote: > I get the historical interest, but in today's world, is there any > advantage to ksh over bash? I get that lots of scripts are run > with /bin/sh and it is nice when that is fast, but aren't the cpus > fast enough these days that it sort of doesn't matter? > Bash is GPLd. Ksh isn't. :) Warner On Tue, Dec 21, 2021 at 02:55:55PM +0100, Cyrille Lefevre via TUHS wrote: > > Hi, Here are some ksh versions... > > > > http://cyrillelefevre.free.fr/ksh/ > > > > ksh86a-toolchest.tar.bz2 314427 > > ksh88c-hpux-9.10.tar.bz2 169413 > > ksh88d-svr4.tar.bz2 132718 > > ksh88f-i18n-irix-6.5.5.tar.bz2 160563 > > ksh88f-irix-6.5.7.tar.bz2 215090 > > ksh88g-sco-unixware7.tar.bz2 195282 > > ksh88h-sco-unixware7.tar.bz2 147194 > > ksh88i-solaris-2.5.tar.bz2 149477 > > ksh88i-solaris-2.6.tar.bz2 159219 > > ksh88i-solaris-2.7.tar.bz2 163976 > > ksh88i-solaris-2.8.tar.bz2 164771 > > ksh93e-sco-unixware7.tar.bz2 542380 > > > > Le 23/12/2020 ? 08:19, Efton Collins a ?crit?: > > >here is a link to a ksh version that seems to predate ksh88, msg.c > > >says "Version 06/03/86a": > > >https://github.com/weiss/original-bsd/tree/master/local/toolchest/ksh > > > > > >I found the link at the bottom of this interesting page: > > >https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html > > > > > >and this link contains a surprising amount of information on many > > >shell versions released over the years - > > >https://www.in-ulm.de/~mascheck/various/shells > > > > > >On 12/22/20, Scot Jenkins via TUHS wrote: > > >>Warren Toomey wrote: > > >> > > >>>Hi all, I received an e-mail looking for the ksh-88 source code. A > quick > > >>>search for it on-line doesn't reveal it. Does anybody have a copy? > > >>https://archive.org/details/ATTUNIXSystemVRelease4Version2 > > >>has source for several releases. > > >> > > >>click "show all" on the right under "download options", > > >>the file sysvr4.tar.bz2 has source for ksh88: > > >> > > >>from cmd/ksh/sh/msg.c: > > >>msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > > >> > > >>I think this was for x86 PCs. I haven't tried to build it. > > >>The date on the files is Jan 25 1993. > > >> > > >>scot > > >> > > > > > -- > > mailto:Cyrille.Lefevre-lists at laposte.net > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Dec 22 02:42:48 2021 From: cowan at ccil.org (John Cowan) Date: Tue, 21 Dec 2021 11:42:48 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: <20211221162139.GP24180@mcvoy.com> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy wrote: I get the historical interest, but in today's world, is there any > advantage to ksh over bash? I get that lots of scripts are run > with /bin/sh and it is nice when that is fast, but aren't the cpus > fast enough these days that it sort of doesn't matter? > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 (from which it spread to BSD) precisely because it was much faster than bash. It's also smaller: bash is a memory hog. When I wrote a whole (batch) application in about 120 Perl and shell scripts in 1999-2001, I often needed multiple shell scripts running simultaneously, sometimes for concurrency and sometimes just from scripts calling other scripts. So I made sure everything ran under Solaris sh, which was a modified Bourne shell at that time and so was much lighter than bash, which I used for development. Nowadays I'd use dash in the same circumstances. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Dec 22 02:47:13 2021 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 21 Dec 2021 11:47:13 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: On 12/21/21 11:42 AM, John Cowan wrote: > > > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy > wrote: > > I get the historical interest, but in today's world, is there any > advantage to ksh over bash?  I get that lots of scripts are run > with /bin/sh and it is nice when that is fast, but aren't the cpus > fast enough these days that it sort of doesn't matter? > > > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 > (from which it spread to BSD) precisely because it was much faster than > bash.  It's also smaller: bash is a memory hog.  You're talking about dash, I think. -- ``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 cowan at ccil.org Wed Dec 22 03:09:47 2021 From: cowan at ccil.org (John Cowan) Date: Tue, 21 Dec 2021 12:09:47 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: Yes, sorry: I edited the posting heavily and I missed that some pronouns now had the wrong antecedent. On Tue, Dec 21, 2021 at 11:47 AM Chet Ramey wrote: > On 12/21/21 11:42 AM, John Cowan wrote: > > > > > > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy > > wrote: > > > > I get the historical interest, but in today's world, is there any > > advantage to ksh over bash? I get that lots of scripts are run > > with /bin/sh and it is nice when that is fast, but aren't the cpus > > fast enough these days that it sort of doesn't matter? > > > > > > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 > > (from which it spread to BSD) precisely because it was much faster than > > bash. It's also smaller: bash is a memory hog. > > You're talking about dash, I think. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Wed Dec 22 03:15:56 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Dec 2021 10:15:56 -0700 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> On 12/21/21 9:27 AM, Warner Losh wrote: > Bash is GPLd. Ksh isn't. :) At the risk of showing my ignorance.... What is the effective difference between GPLed software; Bash, vs non-GPLed software; Ksh? Why, as a lay user, would I care? I mostly care that I am allowed to use it by some license so that I'm not pirating software. -- 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 gerberb at zenez.com Wed Dec 22 03:31:25 2021 From: gerberb at zenez.com (Boyd Lynn Gerber) Date: Tue, 21 Dec 2021 10:31:25 -0700 Subject: [TUHS] ksh88 source code? In-Reply-To: <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: I have moved to mksh http://www.mirbsd.org/mksh.htm mksh(1) R59c This is the website of the MirBSD™ Korn Shell, an actively developed free implementation of the Korn Shell programming language and a successor to the Public Domain Korn Shell (pdksh). Regards, -- Boyd Gerber 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 From pnr at planet.nl Wed Dec 22 03:41:42 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 21 Dec 2021 18:41:42 +0100 Subject: [TUHS] 32V with virtual memory Message-ID: I am making some slow progress on the topic of Tom Reiser’s 32V with virtual memory. Two more names popped up of folks who worked with his virtual memory code base at Bell Labs / USG in the early 80’s: Robert (Bob) Baron and Jim McCormick. Bob Barron was later working on Mach at CMU. If anybody on this list has contact suggestions for these two folks, please send a private message. Paul From rich.salz at gmail.com Wed Dec 22 05:09:49 2021 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 21 Dec 2021 14:09:49 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: > I have moved to mksh > http://www.mirbsd.org/mksh.htm > I use http://nadvsh.sourceforge.net/ when I don't use the rc port. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 22 07:42:20 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Dec 2021 16:42:20 -0500 (EST) Subject: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest! Message-ID: <20211221214220.4A13118C07A@mercury.lcs.mit.edu> > From: Paul Ruizendaal > Does anyone remember, was this a real life bug back in 6th edition The 'V6' at MIT (actually, PWB1) never had an issue, but then again, its TTY driver (here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/dmr/tty.c if anyone wants to see it) was heavily re-written. But from the below, it's almost certainlynothing to do with the TTY code... > From: Dave Plonka > one experiment we did was to redirection the bas(1)ic program's output > to a file and what we found was that (a) characters would still > sometimes be lost Good test. If you all want to chase this down (I can lend V6 expertise, if needed), I'd say the first step is to work out whether it's the application, or the system, losing the characters. To do that, I'd put a little bit of code in write() to store a copy of data sent through that in a circular buffer, along with tagging it with the writing process, etc. Once you figure out where it's getting lost, then you can move on to how/why. > From: Clem Cole > First Sixth Edition does not have support for either the 11/23 Yeah, but it's super-trivial to add /23 support to V6: http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23 The only places where change is needed (no LKS register, no switch register, and support for more than 256KB of main memory - and that one one can get by without), it's hard to see how they could cause this problem. > One other thought, I'm pretty sure that Noel's V6+ system from MIT can > support a 23 No, we never ran than on a /23 BITD (no need, no mass storage); and I have yet to bring the V6+ system up (although I have all the bits, and intend to, at some point, to get its TCP/IP running). I've been using stock (well, hacked a bit, in a number of ways - e.g. 8-bit serial line output) V6. Noel From thomas.paulsen at firemail.de Wed Dec 22 08:15:34 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 21 Dec 2021 23:15:34 +0100 Subject: [TUHS] ksh88 source code? In-Reply-To: <20211221162139.GP24180@mcvoy.com> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: <1219e66ad292df0b821c428dc003e6ea@firemail.de> First of all, there is a big difference between ksh88 and ksh94. The latter is closer to bash, but it's ancient software. bash is clearly more advanced. ksh is retro computing. --------------------------------------------------------------------------- I get the historical interest, but in today's world, is there any advantage to ksh over bash? I get that lots of scripts are run with /bin/sh and it is nice when that is fast, but aren't the cpus fast enough these days that it sort of doesn't matter? From jason-tuhs at shalott.net Wed Dec 22 16:23:17 2021 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Tue, 21 Dec 2021 22:23:17 -0800 (PST) Subject: [TUHS] ksh88 source code? In-Reply-To: <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: >> Bash is GPLd. Ksh isn't. :) > What is the effective difference between GPLed software; Bash, vs > non-GPLed software; Ksh? > > Why, as a lay user, would I care? As an end user, you would not care. As a vendor or distributor, you would care. Anyone doing an OS or other software distribution (think the BSDs, of course; but also think Apple or Microsoft) needs to care. Anyone selling a hardware device with embedded software (think switches/routers; think IOT devices; think consumer devices like DVRs; etc) needs to care. GPL (or similar "virally" licensed) software carries legal implications for anyone selling or distributing products that contain such software; and this can be a motivation to use software with less-restrictive license terms. > I get the historical interest, but in today's world, is there any > advantage to ksh over bash? I'm aware of a few random features that are in ksh93 but not other shells (random, trivial, example that I saw just today*: "printf %(FORMAT)T"). That said, my first impulse would have been to say no, there aren't any meaningful (technical) advantages to ksh over bash -- except that it seems there's still some amount of active development going on in ksh: https://github.com/att/ast/issues/1466 So I guess, for some people at least, there are indeed reasons to prefer it, including (according to users in those github issues) performance. On the licensing front, the GPL is an issue for bash; but zsh is available as a more modern, fully-featured shell that avoids any GPL issues. This is why Apple switched the default shell in OSX from bash to zsh: they wanted to avoid the GPLv3. Previously, they had been shipping the last GPLv2 version of bash, which was from 2006. According to this blog, they've been avoiding any GPLv3 code and actively working to remove even GPLv2 code in OSX for quite a while: http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/ -Jason * bash seems to recognize %(FORMAT)T, but only takes epoch seconds as an argument. ksh93 takes anything vaguely date-like. zsh and pdksh don't recognize it at all. for S in ksh93 pdksh bash zsh ; do echo "===> ${S} <===" ; eval "${S} -c 'printf \"%(%F)T\n\" \"last thursday\"'" ; echo "" ; done ===> ksh93 <=== 2021-12-16 ===> pdksh <=== printf: illegal format character ( ===> bash <=== bash: line 1: printf: last thursday: invalid number 1969-12-31 ===> zsh <=== zsh:printf:1: %(: invalid directive From arnold at skeeve.com Wed Dec 22 17:44:12 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Dec 2021 00:44:12 -0700 Subject: [TUHS] ksh88 source code? In-Reply-To: <1219e66ad292df0b821c428dc003e6ea@firemail.de> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <1219e66ad292df0b821c428dc003e6ea@firemail.de> Message-ID: <202112220744.1BM7iCwT006614@freefriends.org> "Thomas Paulsen" wrote: > ksh is retro computing. Ksh is still being worked on,just not by David Korn. See https://github.com/ksh93/ksh Arnold From cyrille.lefevre-lists at laposte.net Wed Dec 22 21:11:40 2021 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Wed, 22 Dec 2021 12:11:40 +0100 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> Message-ID: <8d19eacf-dc1d-efe2-1635-7feaa6d66d20@laposte.net> Le 21/12/2021 à 17:42, John Cowan a écrit : > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy > wrote: > > I get the historical interest, but in today's world, is there any > advantage to ksh over bash?  I get that lots of scripts are run > with /bin/sh and it is nice when that is fast, but aren't the cpus > fast enough these days that it sort of doesn't matter? > > Ubuntu chose it as the default shell for sysvinit startup scripts in > 2006 (from which it spread to BSD) precisely because it was much faster > than bash.  It's also smaller: bash is a memory hog. it seems bash4 have solved the performance penalty : https://github.com/ksh-community/shbench/blob/master/bench/gsub.ksh /me -- mailto:Cyrille.Lefevre-lists at laposte.net From cyrille.lefevre-lists at laposte.net Thu Dec 23 00:35:00 2021 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Wed, 22 Dec 2021 15:35:00 +0100 Subject: [TUHS] ksh88 source code? In-Reply-To: <1219e66ad292df0b821c428dc003e6ea@firemail.de> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <1219e66ad292df0b821c428dc003e6ea@firemail.de> Message-ID: <8a102f85-be74-819f-322b-989f743029d7@laposte.net> Le 21/12/2021 à 23:15, Thomas Paulsen a écrit : > First of all, there is a big difference between ksh88 and ksh94. The latter is closer to bash, but it's ancient software. bash is clearly more advanced. ksh is retro computing. s/94/93/ ksh93 was more advanced than bash for years... regarding https://tldp.org/LDP/abs/html/bashver4.html, ksh93 is just missing mapfile and some features like ${x^}, ${x,}, '\uXXX', others things were implemented for years... in fact, bash4 implements man ksh93 :-) /me -- mailto:Cyrille.Lefevre-lists at laposte.net From norman at oclsc.org Thu Dec 23 00:40:56 2021 From: norman at oclsc.org (Norman Wilson) Date: Wed, 22 Dec 2021 09:40:56 -0500 (EST) Subject: [TUHS] ksh88 source code? Message-ID: <5D8BA976A496FD8E3AEFB6C9153250F0.for-standards-violators@oclsc.org> Thomas Paulsen: bash is clearly more advanced. ksh is retro computing. ==== Shell wars are, in the end, no more interesting than editor wars. I use bash on Linux systems because it's the least-poorly supported of the Bourne-family shells, besides which bash is there by default. Ksh isn't. I use ksh on OpenBSD systems because it's the least-poorly supported of the Bourne-family shells, besides which kh is there by default. Bash isn't. I don't actually care for most of the extra crap in either of those shells. I don't want my shell to do line editing or auto-completion, and I find the csh-derived history mechanisms more annoying than useful so I turn them off too. To my mind, the Research 10/e sh had it about right, including the simple way functions were exported and the whatis built-in that told you whether something was a variable or a shell function or an external executable, and printed the first two in forms easily edited on the screen and re-used. Terminal programs that don't let you easily edit input or output from the screen and re-send it, and programs that abet them by spouting gratuitous ANSI control sequences: now THAT's what I call retro-computing. Probably further discussion of any of this belongs in COFF. Norman Wilson Toronto ON From chet.ramey at case.edu Thu Dec 23 00:36:33 2021 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 22 Dec 2021 09:36:33 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: <8a102f85-be74-819f-322b-989f743029d7@laposte.net> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <1219e66ad292df0b821c428dc003e6ea@firemail.de> <8a102f85-be74-819f-322b-989f743029d7@laposte.net> Message-ID: <19a2c8fd-b94c-55ce-9f19-3795486c1a9a@case.edu> On 12/22/21 9:35 AM, Cyrille Lefevre via TUHS wrote: > in fact, bash4 implements man ksh93 :-) Well, that's not true. -- ``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 jjacocks at mac.com Thu Dec 23 01:11:26 2021 From: jjacocks at mac.com (Alexander Jacocks) Date: Wed, 22 Dec 2021 10:11:26 -0500 Subject: [TUHS] Photos of University Computer Labs Message-ID: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Hello, I’m looking for photographs of university computer labs from 1985 until 1995, particularly labs full of unix workstations, of course. Does anyone here have photos like that in their collection? I’m also thinking of reaching out to university archivists, but I don’t have any direct connections to any. Thanks much! - Alex From joshnatis0 at gmail.com Thu Dec 23 06:31:08 2021 From: joshnatis0 at gmail.com (josh) Date: Wed, 22 Dec 2021 15:31:08 -0500 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: Hi Alex, On Wednesday, December 22, 2021, Alexander Jacocks via TUHS < tuhs at minnie.tuhs.org> wrote: > > I’m looking for photographs of university computer labs from 1985 until > 1995, particularly labs full of unix workstations, of course. This is from a few years earlier than you requested, but in Rob Pike's "Unix History, An illustrated memoir" talk ( https://m.youtube.com/watch?v=_2NI6t2r_Hs ), at around ~11:18, Rob shows a photo of the University of Toronto's computer graphics lab (with Unix machines :P). He doesn't say the exact date, but based on context it should be from around 1979ish. Hope this helps, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Dec 23 06:35:44 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Dec 2021 15:35:44 -0500 Subject: [TUHS] Faces of Open Source (and NFTs) Message-ID: So a number of Unix luminaries were photographed as part of the "Faces of Open Source" project. I have to admit, the photos themselves are quite good: https://www.facesofopensource.com/collect/ It seems that the photographer is now selling NFTs based on those photos, which is...a thing. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Dec 23 07:15:02 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 23 Dec 2021 08:15:02 +1100 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: I responded with a couple of modest jpgs but the 100kB limit on this list is once again blocking photographic history. I'll send them to Josh directly. -rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From treese at acm.org Thu Dec 23 07:14:35 2021 From: treese at acm.org (Win Treese) Date: Wed, 22 Dec 2021 16:14:35 -0500 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: > On Dec 22, 2021, at 10:11 AM, Alexander Jacocks via TUHS wrote: > > Hello, > > I’m looking for photographs of university computer labs from 1985 until 1995, particularly labs full of unix workstations, of course. Does anyone here have photos like that in their collection? > > I’m also thinking of reaching out to university archivists, but I don’t have any direct connections to any. There may be some photos of MIT’s Project Athena rooms in the collections of the MIT Museum (http://mitmuseum.mit.edu/contact) or the Institute Archives at the MIT Libraries (https://libraries.mit.edu/distinctive-collections/collections/institute-archives/). In a quick search online, I only found photos of the original terminal rooms, with terminals connected to VAXen running UNIX. The workstations were deployed in 1986 +/-, I think. - Win From athornton at gmail.com Thu Dec 23 10:48:23 2021 From: athornton at gmail.com (Adam Thornton) Date: Wed, 22 Dec 2021 17:48:23 -0700 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: I can well remember how the Ab Lab (in the Abercrombie mechanical engineering building) looked and smelled at Rice University from 1990-1994, as its Sun 3s and RT-6000s were replaced by SparcStations...but I don't have any pictures of it. On Wed, Dec 22, 2021 at 2:21 PM Win Treese wrote: > > > On Dec 22, 2021, at 10:11 AM, Alexander Jacocks via TUHS < > tuhs at minnie.tuhs.org> wrote: > > > > Hello, > > > > I’m looking for photographs of university computer labs from 1985 until > 1995, particularly labs full of unix workstations, of course. Does anyone > here have photos like that in their collection? > > > > I’m also thinking of reaching out to university archivists, but I don’t > have any direct connections to any. > > There may be some photos of MIT’s Project Athena rooms in the collections > of the MIT Museum (http://mitmuseum.mit.edu/contact) or the Institute > Archives at the MIT Libraries ( > https://libraries.mit.edu/distinctive-collections/collections/institute-archives/). > In a quick search online, I only found photos of the original terminal > rooms, with terminals connected to VAXen running UNIX. The workstations > were deployed in 1986 +/-, I think. > > - Win > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ats at offog.org Thu Dec 23 11:30:38 2021 From: ats at offog.org (Adam Sampson) Date: Thu, 23 Dec 2021 01:30:38 +0000 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> (Alexander Jacocks via TUHS's message of "Wed, 22 Dec 2021 10:11:26 -0500") References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: Alexander Jacocks via TUHS writes: > I’m looking for photographs of university computer labs from 1985 > until 1995, particularly labs full of unix workstations, of > course. Does anyone here have photos like that in their collection? Here's a computer lab at Dundee Institute of Technology (now Abertay University), Dundee, Scotland around 1985: http://stuff.offog.org/dct/torch-lab-c1985.jpg It's unlikely that there was any Unix involved in that picture -- the Torch machines pictured are modified BBC Micros with a Z80 coprocessor so they can run a CP/M clone, and DIT's computer centre had a TOPS-20 system and several VMS machines at that point. -- Adam Sampson From lm at mcvoy.com Thu Dec 23 12:18:05 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Dec 2021 18:18:05 -0800 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: <20211223021805.GK24180@mcvoy.com> On Thu, Dec 23, 2021 at 01:30:38AM +0000, Adam Sampson wrote: > Alexander Jacocks via TUHS writes: > > > I???m looking for photographs of university computer labs from 1985 > > until 1995, particularly labs full of unix workstations, of > > course. Does anyone here have photos like that in their collection? > > Here's a computer lab at Dundee Institute of Technology (now Abertay > University), Dundee, Scotland around 1985: > > http://stuff.offog.org/dct/torch-lab-c1985.jpg > > It's unlikely that there was any Unix involved in that picture -- the > Torch machines pictured are modified BBC Micros with a Z80 coprocessor > so they can run a CP/M clone, and DIT's computer centre had a TOPS-20 > system and several VMS machines at that point. The terminal rooms bring back memories. I learned *so* much looking over someone else's shoulder and going "how did you make vi do that?". The CP/M machines bring back different memories, using that and BDS C because an 11/780 with 4MB of ram and 40 users meant each user was getting 1KB so it swapped and swapped and swapped. 128K less the space for video on a CP/M machine was slower when you had the VAX to yourself (as in never) and much faster in general. Wrote a boatload of funky C code on my CP/M machine. More lonely but more productive code wise. --lm From wkt at tuhs.org Thu Dec 23 14:28:43 2021 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 23 Dec 2021 15:28:43 +1100 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: I've just bumped the limit up to a massive 1M :-) I could be persuaded to go even higher! Cheers, Warren On 23/12/21 8:15 am, Rob Pike wrote: > I responded with a couple of modest jpgs but the 100kB limit on this > list is once again blocking photographic history. > > I'll send them to Josh directly. > > -rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjacocks at mac.com Thu Dec 23 14:31:38 2021 From: jjacocks at mac.com (Alexander Jacocks) Date: Wed, 22 Dec 2021 23:31:38 -0500 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: Rob, I was the original requestor. Thanks for the images! Thanks for upping the limit, Warren. - Alex > On Dec 22, 2021, at 11:28 PM, Warren Toomey wrote: > > I've just bumped the limit up to a massive 1M :-) I could be persuaded to go even higher! > > Cheers, Warren > > On 23/12/21 8:15 am, Rob Pike wrote: >> I responded with a couple of modest jpgs but the 100kB limit on this list is once again blocking photographic history. >> >> I'll send them to Josh directly. >> >> -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Dec 23 14:45:48 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 23 Dec 2021 15:45:48 +1100 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: Thank you! -rob On Thu, Dec 23, 2021 at 3:29 PM Warren Toomey wrote: > I've just bumped the limit up to a massive 1M :-) I could be persuaded to > go even higher! > > Cheers, Warren > On 23/12/21 8:15 am, Rob Pike wrote: > > I responded with a couple of modest jpgs but the 100kB limit on this list > is once again blocking photographic history. > > I'll send them to Josh directly. > > -rob > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Dec 23 07:07:33 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 23 Dec 2021 08:07:33 +1100 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: And here they are. The images are lousy scans of prints. [image: 20181026-unix 4.jpg] [image: 20181026-unix 5.jpg] -rob On Thu, Dec 23, 2021 at 7:32 AM josh wrote: > Hi Alex, > > On Wednesday, December 22, 2021, Alexander Jacocks via TUHS < > tuhs at minnie.tuhs.org> wrote: >> >> I’m looking for photographs of university computer labs from 1985 until >> 1995, particularly labs full of unix workstations, of course. > > > This is from a few years earlier than you requested, but in Rob Pike's > "Unix History, An illustrated memoir" talk ( > https://m.youtube.com/watch?v=_2NI6t2r_Hs > ), at around ~11:18, > Rob shows a photo of the University of Toronto's computer graphics lab > (with Unix machines :P). He doesn't say the exact date, but based on > context it should be from around 1979ish. > > Hope this helps, > Josh > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20181026-unix 4.jpg Type: image/jpeg Size: 451338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20181026-unix 5.jpg Type: image/jpeg Size: 414207 bytes Desc: not available URL: From michael at kjorling.se Thu Dec 23 23:05:55 2021 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 23 Dec 2021 13:05:55 +0000 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: <20211223021805.GK24180@mcvoy.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> Message-ID: On 22 Dec 2021 18:18 -0800, from lm at mcvoy.com (Larry McVoy): > The CP/M machines bring back different memories, using that and BDS > C because an 11/780 with 4MB of ram and 40 users meant each user was > getting 1KB so it swapped and swapped and swapped. 4 MB RAM and 40 users works out to 100 KB of RAM per user for me. Even accounting for a large at the time OS it should be several tens of kilobytes per user on average for actual useful data. So, because there's probably some detail here that means you're right and I'm wrong, how do you arrive at the figure 1 KB of RAM per user in that scenario? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From cyrille.lefevre-lists at laposte.net Thu Dec 23 23:39:44 2021 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Thu, 23 Dec 2021 14:39:44 +0100 Subject: [TUHS] Bourne shell source code (was Re: ksh88 source code?) In-Reply-To: <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> Message-ID: Le 21/12/2021 à 14:55, Cyrille Lefevre a écrit : > Hi, Here are some ksh versions... > > http://cyrillelefevre.free.fr/ksh/ > > ksh86a-toolchest.tar.bz2 314427 > ksh88c-hpux-9.10.tar.bz2 169413 > ksh88d-svr4.tar.bz2 132718 > ksh88f-irix-6.5.5f.tar.bz2 160563 > ksh88f-irix-6.5.5m.tar.bz2 160563 > ksh88f-irix-6.5.7m.tar.bz2 215090 > ksh88g-sco-unixware7.tar.bz2 195282 > ksh88h-sco-unixware7.tar.bz2 147194 > ksh88i-solaris-2.5.tar.bz2 149477 > ksh88i-solaris-2.6.tar.bz2 159219 > ksh88i-solaris-2.7.tar.bz2 163976 > ksh88i-solaris-2.8.tar.bz2 164771 > ksh93e-sco-unixware7.tar.bz2 542380 added : dclemans_ksh-0.3.tar.Z 162394 ksh93u-apple.tar.bz2 4545249 and some bourne shell versions... http://cyrillelefevre.free.fr/sh/ sh5-ultrix-4.3-bsd.tar.bz2 41341 sh-aix-4.1.3.tar.bz2 61194 sh-bsd-4.4-lite2+1hour.tar.bz2 50660 sh-dec-osf1-1.0.tar.bz2 58670 sh-dec-osf1-2.0.tar.bz2 58691 sh-hpux-9.10.tar.bz2 52270 sh-irix-3.7.tar.bz2 61028 sh-irix-6.5.5f.tar.bz2 60260 sh-irix-6.5.5m.tar.bz2 60295 sh-irix-6.5.7m.tar.bz2 60220 sh-opensolaris-b147.tar.bz2 53857 sh-sco-unixware7.tar.bz2 55594 sh-sco-unixware7-osr.tar.bz2 50062 sh-solaris-2.6.tar.bz2 51006 sh-solaris-2.8.tar.bz2 53597 sh-sunos-4.1.4.tar.bz2 39230 sh-svr4.tar.bz2 47766 sh-ultrix-4.3-bsd.tar.bz2 28799 sh-ultrix-osf1-1.0.tar.bz2 56072 sh-usl-4.2.tar.bz2 54212 Regards, /me -- mailto:Cyrille.Lefevre-lists at laposte.net From lm at mcvoy.com Fri Dec 24 00:19:58 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Dec 2021 06:19:58 -0800 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> Message-ID: <20211223141958.GR24180@mcvoy.com> On Thu, Dec 23, 2021 at 01:05:55PM +0000, Michael Kj??rling wrote: > On 22 Dec 2021 18:18 -0800, from lm at mcvoy.com (Larry McVoy): > > The CP/M machines bring back different memories, using that and BDS > > C because an 11/780 with 4MB of ram and 40 users meant each user was > > getting 1KB so it swapped and swapped and swapped. > > 4 MB RAM and 40 users works out to 100 KB of RAM per user for me. Even > accounting for a large at the time OS it should be several tens of > kilobytes per user on average for actual useful data. So, because > there's probably some detail here that means you're right and I'm > wrong, how do you arrive at the figure 1 KB of RAM per user in that > scenario? Probably boomer doing math wrong. You are right, I'm wrong. Though I will say that 100K/student was _painful_. Not enough to run make/cc in any reasonable time. About the only thing that worked was ^t (I think that was it) that showed you some basic info about performance. From iain at csp-partnership.co.uk Fri Dec 24 01:29:18 2021 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 23 Dec 2021 15:29:18 +0000 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <20211223141958.GR24180@mcvoy.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> Message-ID: On 12/23/21 2:19 PM, Larry McVoy wrote: > On Thu, Dec 23, 2021 at 01:05:55PM +0000, Michael Kj??rling wrote: >> On 22 Dec 2021 18:18 -0800, from lm at mcvoy.com (Larry McVoy): >>> The CP/M machines bring back different memories, using that and BDS >>> C because an 11/780 with 4MB of ram and 40 users meant each user was >>> getting 1KB so it swapped and swapped and swapped. >> 4 MB RAM and 40 users works out to 100 KB of RAM per user for me. Even >> accounting for a large at the time OS it should be several tens of >> kilobytes per user on average for actual useful data. So, because >> there's probably some detail here that means you're right and I'm >> wrong, how do you arrive at the figure 1 KB of RAM per user in that >> scenario? > Probably boomer doing math wrong. I might get flamed for this comment, but is a number divided by a number not arithmetic.  I cant see any maths in there. In my support I point out that the "dc" manual page says  dc  is a reverse-polish desk calculator which supports unlimited precision arithmetic. In Scotland - at least years ago - arithmetic was an examinable subject at the lower grades (you also get a mathematics exam at the same grade). Arithmetic could not be taken past the basic level, mathematics could. Nowadays they have lumped arithmetic into maths (pronounced "maffs"). Do other countries have this change in language? Sorry for the intrusion. It is Christmas with me (or is it "happy holiday" to be politically correct). > You are right, I'm wrong. Though I > will say that 100K/student was _painful_. Not enough to run make/cc in > any reasonable time. About the only thing that worked was ^t (I think > that was it) that showed you some basic info about performance. I had forgotten about control-t - does anything modern still do that ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 24 02:00:11 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Dec 2021 08:00:11 -0800 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> Message-ID: <20211223160011.GS24180@mcvoy.com> On Thu, Dec 23, 2021 at 03:29:18PM +0000, Dr Iain Maoileoin wrote: > >Probably boomer doing math wrong. > > I might get flamed for this comment, but is a number divided by a number not > arithmetic.?? I cant see any maths in there. That's just a language thing, lots of people in the US call arithmetic math. I'm 100% positive that that is not just me. From imp at bsdimp.com Fri Dec 24 02:02:40 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 23 Dec 2021 10:02:40 -0600 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> Message-ID: On Thu, Dec 23, 2021, 8:54 AM Dr Iain Maoileoin wrote: > On 12/23/21 2:19 PM, Larry McVoy wrote: > > On Thu, Dec 23, 2021 at 01:05:55PM +0000, Michael Kj??rling wrote: > > On 22 Dec 2021 18:18 -0800, from lm at mcvoy.com (Larry McVoy): > > The CP/M machines bring back different memories, using that and BDS > C because an 11/780 with 4MB of ram and 40 users meant each user was > getting 1KB so it swapped and swapped and swapped. > > 4 MB RAM and 40 users works out to 100 KB of RAM per user for me. Even > accounting for a large at the time OS it should be several tens of > kilobytes per user on average for actual useful data. So, because > there's probably some detail here that means you're right and I'm > wrong, how do you arrive at the figure 1 KB of RAM per user in that > scenario? > > Probably boomer doing math wrong. > > I might get flamed for this comment, but is a number divided by a number > not arithmetic. I cant see any maths in there. > > In my support I point out that the "dc" manual page says > > dc is a reverse-polish desk calculator which supports unlimited precision arithmetic. > > > In Scotland - at least years ago - arithmetic was an examinable subject at > the lower grades (you also get a mathematics exam at the same grade). > > Arithmetic could not be taken past the basic level, mathematics could. > > Nowadays they have lumped arithmetic into maths (pronounced "maffs"). > > Do other countries have this change in language? > > Sorry for the intrusion. It is Christmas with me (or is it "happy holiday" > to be politically correct). > > You are right, I'm wrong. Though I > will say that 100K/student was _painful_. Not enough to run make/cc in > any reasonable time. About the only thing that worked was ^t (I think > that was it) that showed you some basic info about performance. > > I had forgotten about control-t - does anything modern still do that > FreeBSD does. It's my biggest annoyance with Linux that it doesn't. 100k for a process that likely needed 500k to 1MB would indeed be swapping its brains out. So while tha vax could do I/O 10 times faster than a Z80 of the era and run maybe 5 times faster, all that was lost when you started thrashing because you can't keep your working set in memory. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 24 02:19:23 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Dec 2021 08:19:23 -0800 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> Message-ID: <20211223161923.GT24180@mcvoy.com> On Thu, Dec 23, 2021 at 10:02:40AM -0600, Warner Losh wrote: > > I had forgotten about control-t - does anything modern still do that > > FreeBSD does. It's my biggest annoyance with Linux that it doesn't. Seems like a patch might be nice. > 100k for a process that likely needed 500k to 1MB would indeed be swapping > its brains out. So while tha vax could do I/O 10 times faster than a Z80 of > the era and run maybe 5 times faster, all that was lost when you started > thrashing because you can't keep your working set in memory. Yeah, exactly. A z80 with floppies seems slower, and was much slower than a VAX to yourself, but I very rarely experienced that. 40 students at 4am and the load average was through the roof? No thanks, I'll take the predictable speed of my CP/M machine over the VAX any day. It wasn't that slow, I got a lot of work done on it. --lm From iain at csp-partnership.co.uk Fri Dec 24 02:28:26 2021 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 23 Dec 2021 16:28:26 +0000 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <20211223160011.GS24180@mcvoy.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223160011.GS24180@mcvoy.com> Message-ID: <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> On 12/23/21 4:00 PM, Larry McVoy wrote: > On Thu, Dec 23, 2021 at 03:29:18PM +0000, Dr Iain Maoileoin wrote: >>> Probably boomer doing math wrong. >> I might get flamed for this comment, but is a number divided by a number not >> arithmetic.?? I cant see any maths in there. > That's just a language thing, lots of people in the US call arithmetic > math. I'm 100% positive that that is not just me. Interesting - have you always done that?  Or is it a more recent use of the word? 50 years ago our (Scottish) schooling used only Arithmetic for the basic number manipulation.  About 10-15 years ago maffs became the name.  I dont know how the transition occured with us. Schools?  or Media??  Perhaps we have just imported the name from the good old US of A ;-) From lm at mcvoy.com Fri Dec 24 02:35:32 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Dec 2021 08:35:32 -0800 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223160011.GS24180@mcvoy.com> <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> Message-ID: <20211223163532.GW24180@mcvoy.com> On Thu, Dec 23, 2021 at 04:28:26PM +0000, Dr Iain Maoileoin wrote: > On 12/23/21 4:00 PM, Larry McVoy wrote: > >On Thu, Dec 23, 2021 at 03:29:18PM +0000, Dr Iain Maoileoin wrote: > >>>Probably boomer doing math wrong. > >>I might get flamed for this comment, but is a number divided by a number not > >>arithmetic.?? I cant see any maths in there. > >That's just a language thing, lots of people in the US call arithmetic > >math. I'm 100% positive that that is not just me. > > Interesting - have you always done that??? Or is it a more recent use of the > word? It's always been that way, arithmetic is a mouthful so people use math to mean arithmetic. You are correct, arithmetic is a distinct subset of math. But it's pedantic to call that out, math is a superset of arithmetic so it is perfectly reasonable to call doing some arithmetic "math". If we started nit picking about those types of differences, we'd never get anything meaningful done. From iain at csp-partnership.co.uk Fri Dec 24 02:47:19 2021 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 23 Dec 2021 16:47:19 +0000 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <20211223163532.GW24180@mcvoy.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223160011.GS24180@mcvoy.com> <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> <20211223163532.GW24180@mcvoy.com> Message-ID: <0531de6e-6c93-bdde-9ee4-cd4ab1f54e0b@csp-partnership.co.uk> On 12/23/21 4:35 PM, Larry McVoy wrote: > On Thu, Dec 23, 2021 at 04:28:26PM +0000, Dr Iain Maoileoin wrote: >> On 12/23/21 4:00 PM, Larry McVoy wrote: >>> On Thu, Dec 23, 2021 at 03:29:18PM +0000, Dr Iain Maoileoin wrote: >>>>> Probably boomer doing math wrong. >>>> I might get flamed for this comment, but is a number divided by a number not >>>> arithmetic.?? I cant see any maths in there. >>> That's just a language thing, lots of people in the US call arithmetic >>> math. I'm 100% positive that that is not just me. >> Interesting - have you always done that??? Or is it a more recent use of the >> word? > It's always been that way, arithmetic is a mouthful so people use math > to mean arithmetic. You are correct, arithmetic is a distinct subset > of math. But it's pedantic to call that out, math is a superset of > arithmetic so it is perfectly reasonable to call doing some arithmetic > "math". If we started nit picking about those types of differences, > we'd never get anything meaningful done. I totally agree.  My question is about language use (or drift) - nothing else.  In Scotland - amongst the young -  "Arithmetic" is now referred to as "Maths".   I am aware of the transition but cant understand what caused it to happen!  I dont know if other countries had/have the same slide from a specific to a general - hence the questions - nothing deeper. In lower secondary school we would go to both Arithmetic AND also to Maths classes.  I suspect that no longer happens in the schools.  I guess I will need to go speak to some teachers. I am not nit-picking, this is just the first time I have picked up the use of maths in the context amongst eh how do I phrase it "the older generation" oops.... From cowan at ccil.org Fri Dec 24 03:23:35 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 23 Dec 2021 12:23:35 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: <5D8BA976A496FD8E3AEFB6C9153250F0.for-standards-violators@oclsc.org> References: <5D8BA976A496FD8E3AEFB6C9153250F0.for-standards-violators@oclsc.org> Message-ID: On Wed, Dec 22, 2021 at 9:41 AM Norman Wilson wrote: > Shell wars are, in the end, no more interesting than editor wars. > +1. One person's "fully-featured software" is another person's "ten pounds of crap in a five-pound bag". > Bourne-family shells All of which, considered as programming languages, are badly designed, in the usual way of sofa beds and other allegedly dual-purpose pieces of furniture. Scsh is a shell that's a high-quality programming language (namely Scheme), and I have just discovered xonsh, which is like scsh for Python. I have some ideas for a shell based on rc and Lua. > To my mind, the Research 10/e sh had it about right, > Unfortunately, approximately nobody except you has access to its man page. Can you post or email it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Dec 24 05:10:21 2021 From: norman at oclsc.org (Norman Wilson) Date: Thu, 23 Dec 2021 14:10:21 -0500 (EST) Subject: [TUHS] ksh88 source code? Message-ID: John Cowan: Unfortunately, approximately nobody except you has access to [the 10/e sh] man page. Can you post or email it? === I am happy to remind you that you're a few years out of date: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/sh.1 Norman Wilson Toronto ON From silas8642 at hotmail.co.uk Fri Dec 24 06:08:08 2021 From: silas8642 at hotmail.co.uk (silas poulson) Date: Thu, 23 Dec 2021 20:08:08 +0000 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <5D8BA976A496FD8E3AEFB6C9153250F0.for-standards-violators@oclsc.org> Message-ID: <8008FC53-A9B3-47E5-A933-44BC2142E5F7@hotmail.co.uk> > On 23 Dec 2021, at 17:23, John Cowan wrote: > Unfortunately, approximately nobody except you has access to its man > page. Can you post or email it? If you’re having trouble using the source, also available at Silas From usotsuki at buric.co Fri Dec 24 08:13:39 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 23 Dec 2021 17:13:39 -0500 (EST) Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <20211223161923.GT24180@mcvoy.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223161923.GT24180@mcvoy.com> Message-ID: On Thu, 23 Dec 2021, Larry McVoy wrote: > On Thu, Dec 23, 2021 at 10:02:40AM -0600, Warner Losh wrote: >>> I had forgotten about control-t - does anything modern still do that >> >> FreeBSD does. It's my biggest annoyance with Linux that it doesn't. > > Seems like a patch might be nice. Yeah, I miss SIGINFO when I'm on Linux. -uso. From usotsuki at buric.co Fri Dec 24 08:15:02 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 23 Dec 2021 17:15:02 -0500 (EST) Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223160011.GS24180@mcvoy.com> <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> Message-ID: On Thu, 23 Dec 2021, Dr Iain Maoileoin wrote: > Interesting - have you always done that?  Or is it a more recent use of the > word? > > 50 years ago our (Scottish) schooling used only Arithmetic for the basic > number manipulation.  About 10-15 years ago maffs became the name.  I dont > know how the transition occured with us. Schools?  or Media??  Perhaps we > have just imported the name from the good old US of A ;-) It was the norm in the US at least around 1985ish. Can't speak for earlier. -uso. From tytso at mit.edu Fri Dec 24 13:48:30 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 23 Dec 2021 22:48:30 -0500 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223161923.GT24180@mcvoy.com> Message-ID: On Thu, Dec 23, 2021 at 05:13:39PM -0500, Steve Nickolas wrote: > On Thu, 23 Dec 2021, Larry McVoy wrote: > > > On Thu, Dec 23, 2021 at 10:02:40AM -0600, Warner Losh wrote: > > > > I had forgotten about control-t - does anything modern still do that > > > > > > FreeBSD does. It's my biggest annoyance with Linux that it doesn't. > > > > Seems like a patch might be nice. > > Yeah, I miss SIGINFO when I'm on Linux. There have been patches proposed, but it turns out the sticky wicket is that we're out of signal numbers on most architectures. There are code points that potentially could be repurposed, since they aren't actually signaled from the kernel: SIGLOST - Term File lock lost (unused) SIGSTKFLT - Term Stack fault on coprocessor (unused) Howveer, the current behavior if no signal handler is installed is to terminate the process --- and it's unclear whether there might be some user space libraries that might be using these signals for their own nefarious purposes. So someone would have to deprecate one of these signals, and then try to do a code search across the internet to see if there's any evidence that SIGLOST or SIGSTKFLT is being used (at least in open source software). It's not impossible to deal with this, but no one has cared enough to really try to push this through as a new feature. Cheers, - Ted From will.senn at gmail.com Fri Dec 24 14:38:38 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 23 Dec 2021 22:38:38 -0600 Subject: [TUHS] Are there images of any SVR2's available online? Message-ID: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> All, Are there any bootable media available for any SVR 2 systems available online? Or are they all under IP lock and key? If so, what's the closest system that is available to get a feel for that variety of OS? Happy holidays, folks. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Dec 24 17:09:24 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 24 Dec 2021 00:09:24 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On Thu, Dec 23, 2021 at 9:39 PM Will Senn wrote: > All, > > Are there any bootable media available for any SVR 2 systems available > online? Or are they all under IP lock and key? If so, what's the closest > system that is available to get a feel for that variety of OS? > You can find pointers to System Vr4.2 on i386 here https://www.in-ulm.de/~mascheck/various/ancient/ as well as System III, but nothing in between. http://squoze.net/UNIX/sysV_pdp11/Installation has system Vr1 on a pdp-11 installation instructions. This is, as far as I know, the only version of System V that ran on the pdp-11. The porting target was changed to the VAX in system Vr2 (though there were VAX versions of both System Vr1 and System III, the latter on squoze.net). https://archive.org/details/ATTUNIXSystemVRelease4Version2 has the sources to the different System V releases and claims to have a cpio of the System Vr2 sources that could create a bootable system. On vetusware.com, you can search for SYSVr2 and find 2 entries. I've not looked at them. One claims to be the source, and the other claims to be a dump of /usr with sources and binaries (but no "/" nor bootable tapes it would appear). The entries for these indicate there's animport of BSD code, but no TCP/IP. Finally, there's this page on installing System Vr3 on a 3b2 from scratch. https://loomcom.com/3b2/installing_unix.html looks good to my eye. It's an installation from floppies. But no bootable tapes that my googling could find. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Fri Dec 24 21:20:33 2021 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 24 Dec 2021 12:20:33 +0100 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On 23/12/21, Will Senn wrote: > All, > > Are there any bootable media available for any SVR 2 systems available > online? Or are they all under IP lock and key? If so, what's the closest > system that is available to get a feel for that variety of OS? Many years ago I got an image from betaarchive.com I believe. I no longer can find the thread about and the link is probably dead anyway, but I found the original file and put it here: http://squoze.net/_misc/Unix%20SYSVr2%20for%20the%20VAX%2011-780.7z SysVR1 for VAX is still something i'd like to see some day... > Happy holidays, folks. And to you! aap From clemc at ccc.com Fri Dec 24 23:56:56 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Dec 2021 08:56:56 -0500 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On Thu, Dec 23, 2021 at 11:39 PM Will Senn wrote: > All, > > Are there any bootable media available for any SVR 2 systems available > online? > I'm interested in learning what it is specifically about the SVR2 system that you are curious? As Warner pointed out, the reference system ISA for the folks in Summit, NJ started changing from the PDP-11 to VAX at that point. By SVR3 it became a WE32000 and by SVR4.2 it was the Intel 386. Besides the ISA changes for the core kernel and the collection of supported user space programs, SYS V took a number twists and turns [for different reasons, some in hindsight, proved questionable] - but nonetheless. Other than the native support for the Vax, IIRC there really was not a lot special in SVR2 - while SVR1 and SVR3 [and later SVR4.2] were actually substantially different from their predecessors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Dec 25 02:20:36 2021 From: will.senn at gmail.com (Will Senn) Date: Fri, 24 Dec 2021 10:20:36 -0600 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: <42e304ee-7007-22b8-139a-aa2a835fbe12@gmail.com> On 12/24/21 1:09 AM, Warner Losh wrote: > > > On Thu, Dec 23, 2021 at 9:39 PM Will Senn wrote: > > All, > > Are there any bootable media available for any SVR 2 systems > available online? Or are they all under IP lock and key? If so, > what's the closest system that is available to get a feel for that > variety of OS? > > > You can find pointers to System Vr4.2 on i386 here > https://www.in-ulm.de/~mascheck/various/ancient/ as well as System > III, but nothing in between. > > http://squoze.net/UNIX/sysV_pdp11/Installation has system Vr1 on a > pdp-11 installation instructions. This is, as far as I know, the only > version of System V that ran on the pdp-11. The porting target was > changed to the VAX in system Vr2 (though there were VAX versions of > both System Vr1 and System III, the latter on squoze.net > ). > > https://archive.org/details/ATTUNIXSystemVRelease4Version2 has the > sources to the different System V releases and claims to have a cpio > of the System Vr2 sources that could create a bootable system. > > On vetusware.com , you can search for SYSVr2 and > find 2 entries. I've not looked at them. One claims to be the source, > and the other claims to be a dump of /usr with sources and binaries > (but no "/" nor bootable tapes it would appear). The entries for these > indicate there's animport of BSD code, but no TCP/IP. > > Finally, there's this page on installing System Vr3 on a 3b2 from > scratch. https://loomcom.com/3b2/installing_unix.html looks good to my > eye. It's an installation from floppies. > > But no bootable tapes that my googling could find. > > Warner Thanks Warner. I remembered 3b2 coming available, but had lost track of where. Thanks for the summary and links. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Dec 25 02:27:00 2021 From: will.senn at gmail.com (Will Senn) Date: Fri, 24 Dec 2021 10:27:00 -0600 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> On 12/24/21 7:56 AM, Clem Cole wrote: > > > On Thu, Dec 23, 2021 at 11:39 PM Will Senn wrote: > > All, > > Are there any bootable media available for any SVR 2 systems > available online? > > I'm interested in learning what it is specifically about the SVR2 > system that you are curious?  As Warner pointed out, the reference > system ISA for the folks in Summit, NJ started changing from the > PDP-11 to VAX at that point.  By SVR3 it became a WE32000 and by > SVR4.2 it was the Intel 386. Clem, Ha! I'm curious by nature. I recently was sent a book that references SVR2 and that is enough impetus for me to want to try it out 'for real' :). Shiny object, for sure. > > Besides the ISA changes for the core kernel and the collection of > supported user space programs, SYS V took a number twists and turns > [for different reasons, some in hindsight, proved questionable] - but > nonetheless. > > Other than the native support for the Vax, IIRC there really was not a > lot special in SVR2 - while SVR1 and SVR3 [and later SVR4.2] were > actually substantially different from their predecessors. Which is why I went looking for SVR2 - substantive (although to me completely opaque) differences from SVR1 and SVR3. The book mentions SVR2, not SVR1 or SVR3, though, I'm sure it applies equally well to those as well, I'm just a sucker for the closest experience I can get without driving myself off the rails trying to get things working. Turns out it isn't horrible, this time. Angelo's Vax 780 version works about like v6/v7 in SIMH - stupid # and @ stuff, but I'm guessing I can change it without mucking about in the source this time. - stty'll prolly do it. Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sat Dec 25 02:57:29 2021 From: web at loomcom.com (Seth Morabito) Date: Fri, 24 Dec 2021 08:57:29 -0800 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On Thu, Dec 23, 2021, at 8:38 PM, Will Senn wrote: > All, > > Are there any bootable media available for any SVR 2 systems available online? Or are they all under IP lock and key? If so, what's the closest system that is available to get a feel for that variety of OS? > > Happy holidays, folks. > > Will I have preserved the installation diskettes for AT&T System V Release 2.0.5 for 3B2 here: https://archives.loomcom.com/3b2/software/System_V_Release_2.0.5/ It should work on the SIMH 3B2/400 emulator, but it occurs to me I've never actually tried a full installation from these before (I've always used SVR 3) -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From clayhickman.io at gmail.com Sat Dec 25 03:58:23 2021 From: clayhickman.io at gmail.com (Clay Hickman) Date: Fri, 24 Dec 2021 11:58:23 -0600 Subject: [TUHS] COFF subscription Message-ID: Hey Warren, First and foremost; Thank you so much for maintaining this mailing list, and for including me within the subscribers list. I find myself intrigued by some of the topics that transfer over to the “COFF” mailing list. Could you include me on that mailing list as well? Peace. From arno.griffioen at ieee.org Sat Dec 25 04:02:17 2021 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Fri, 24 Dec 2021 19:02:17 +0100 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On Thu, Dec 23, 2021 at 10:38:38PM -0600, Will Senn wrote: > Are there any bootable media available for any SVR 2 systems available online? > Or are they all under IP lock and key? If so, what's the closest system that is > available to get a feel for that variety of OS? A/UX for one.. It's available in images and it may be bootable on an m68k Mac emulator. Finding a more 'vanilla' AT&T SVR2 image may indeed be tricky though.. I have run into quite a lot of SVR2 UNIX installs in the past (on all sorts of CPU's), but in many cases these were fairly dedicated or almost 'embedded' systems and not so much generic-use UNIX boxes apart from a few like A/UX. I suspect the relatively small footprint of SVR2 kept it alive for quite some time, although not in the mainstream. Kept bumping into these well into the SVR4 days. Many such dedicated or small footprint SVR2 installs are totally random as to how much and which userland there is though... Some were stripped to the bone with very simple userland commands and others would have backported SVR3 or even SVR4 userland tools. Of course this was also in the days when IP was just 'one of the protocols' so many of these had all sorts of weird and wonderful network stacks hacked onto them. Bye, Arno. From gtaylor at tnetconsulting.net Sat Dec 25 04:32:33 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 24 Dec 2021 11:32:33 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> Message-ID: <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> On 12/24/21 9:27 AM, Will Senn wrote: > Ha! I'm curious by nature. I recently was sent a book that references > SVR2 and that is enough impetus for me to want to try it out 'for real' > :). Shiny object, for sure. /Chuckle/ I'm following suit for 4.4BSD as I've got The Design and Implementation of the 4.4BSD Operating System book (ISBN: 0-201-54979-4) on my desk. Sadly it seems as if 4.4BSD-Encumbered would be required to run it on a VAX emulator and 4.4BSD-Lite is apparently non-starter. I'm also wondering if 386BSD on a PC would be close enough. Though I think that it, and it's ilk, is based on 4.3BSD Net/2. I don't know what the effective differences will be. :-/ In some ways I sort of which I had picked up the 4.3BSD counterpart to the book. > Which is why I went looking for SVR2 s/SVR2/4.4BSD/ > I'm just a sucker for the closest experience I can get without driving > myself off the rails trying to get things working. #truth -- 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 will.senn at gmail.com Sat Dec 25 04:45:06 2021 From: will.senn at gmail.com (Will Senn) Date: Fri, 24 Dec 2021 12:45:06 -0600 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: <4bbfa199-4f68-77c1-d501-c1ff4d6a7de3@gmail.com> On 12/24/21 10:57 AM, Seth Morabito wrote: > On Thu, Dec 23, 2021, at 8:38 PM, Will Senn wrote: >> All, >> >> Are there any bootable media available for any SVR 2 systems available online? Or are they all under IP lock and key? If so, what's the closest system that is available to get a feel for that variety of OS? >> >> Happy holidays, folks. >> >> Will > I have preserved the installation diskettes for AT&T System V Release 2.0.5 for 3B2 here: > > https://archives.loomcom.com/3b2/software/System_V_Release_2.0.5/ > > It should work on the SIMH 3B2/400 emulator, but it occurs to me I've never actually tried a full installation from these before (I've always used SVR 3) > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com Wow, Seth. Your site is very well organized! I'm now busy with my new Christmas holidays project of setting up UNIX System V Release 2.0.5 on the SIMH 3B2/400. Thanks for the steer in that direction. I have the working VAX version to compare with and fall back on if I can't get it working. I'll follow your howto: https://loomcom.com/3b2/installing_unix.html and note any differences along the way. Thanks and later, Will From henry.r.bent at gmail.com Sat Dec 25 05:26:04 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 24 Dec 2021 14:26:04 -0500 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: On Fri, 24 Dec 2021 at 13:33, Grant Taylor via TUHS wrote: > > I'm following suit for 4.4BSD as I've got The Design and Implementation > of the 4.4BSD Operating System book (ISBN: 0-201-54979-4) on my desk. > > Sadly it seems as if 4.4BSD-Encumbered would be required to run it on a > VAX emulator and 4.4BSD-Lite is apparently non-starter. > > 4.4's /usr/src/sys/vax/README: The VAX architecture does not compile in 4.4BSD, as it has not been converted to the new VM. It is here for porting information purposes only. The best you can do as-is on a VAX is 4.3-Reno. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Dec 25 05:31:04 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 24 Dec 2021 12:31:04 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: On Fri, Dec 24, 2021, 12:26 PM Henry Bent wrote: > On Fri, 24 Dec 2021 at 13:33, Grant Taylor via TUHS > wrote: > >> >> I'm following suit for 4.4BSD as I've got The Design and Implementation >> of the 4.4BSD Operating System book (ISBN: 0-201-54979-4) on my desk. >> >> Sadly it seems as if 4.4BSD-Encumbered would be required to run it on a >> VAX emulator and 4.4BSD-Lite is apparently non-starter. >> >> > 4.4's /usr/src/sys/vax/README: > The VAX architecture does not compile in 4.4BSD, as it has > not been converted to the new VM. It is here for porting > information purposes only. > > The best you can do as-is on a VAX is 4.3-Reno. > Vax was running early on with NetBSD. That will be super close to D&I... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair at netbsd.org Sat Dec 25 05:35:00 2021 From: fair at netbsd.org (Erik E. Fair) Date: Fri, 24 Dec 2021 11:35:00 -0800 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: <196.1640374500@cesium.clock.org> Actually, you can do better than 4.3 BSD on a VAX - NetBSD 9.2 runs on VAXen. See http://wiki.netbsd.org/ports/vax/ Erik From dfawcus+lists-tuhs at employees.org Sat Dec 25 06:57:58 2021 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Fri, 24 Dec 2021 20:57:58 +0000 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223160011.GS24180@mcvoy.com> <3915e4db-6740-9777-03f4-4c6b4c09045c@csp-partnership.co.uk> Message-ID: On Thu, Dec 23, 2021 at 04:28:26PM +0000, Dr Iain Maoileoin wrote: > > 50 years ago our (Scottish) schooling used only Arithmetic for the basic > number manipulation.  About 10-15 years ago maffs became the name.  I > dont know how the transition occured with us. Schools?  or Media??  > Perhaps we have just imported the name from the good old US of A ;-) Or more likely from England? I can recall my parents and grandparents referring to the "Three R's", so at some point we would have called it Arithmetic. I don't recall what we called it in Primary School, when simply doing addition, subtraction, multiplication, division and handing of fractions (i.e. rationals) including 'vulgar fractions'. However once at Middle School, the lessons were definitly called maths, and covered other fields (e.g. logariths). The O-level and A-level papers in High School were all in maths. At O-level Mathematics, at A-level Pure Mathematics & Applied Mathematics (the latter at the time with distinct Statistics and/or Mechanics lessons / papers). So that is at least the mid 70s. (For folks outwith the UK, the Scottish and English school systems are distict, and always have been) DF From gtaylor at tnetconsulting.net Sat Dec 25 07:23:12 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 24 Dec 2021 14:23:12 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: On 12/24/21 12:26 PM, Henry Bent wrote: > 4.4's /usr/src/sys/vax/README: > The VAX architecture does not compile in 4.4BSD, as it has > not been converted to the new VM.  It is here for porting > information purposes only. Okay. :-/ > The best you can do as-is on a VAX is 4.3-Reno. At the risk of showing my BSD ignorance, what architectures does 4.4BSD run on? I had assumed it was VAX, but it seems that assumption was wrong. -- 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 gtaylor at tnetconsulting.net Sat Dec 25 07:27:00 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 24 Dec 2021 14:27:00 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> <5d9a246d-c6ab-fc69-30a1-0995d2d0e4f4@gmail.com> <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: <8b982531-f800-6012-dc89-0940f79f7e94@spamtrap.tnetconsulting.net> On 12/24/21 12:31 PM, Warner Losh wrote: > Vax was running early on with NetBSD. That will be super close to D&I... Noted about NetBSD. Thank you Warner. Will there be any substantive differences between NetBSD on VAX and NetBSD on 386 PC? The latter can easily be run in mostly normal virtualization. Or so I assume. The former can be run on emulated hardware. Much like Will, I'm trying to get "...the closest experience I can get without driving myself off the rails trying to get things working." I suppose I could, perhaps should, simply start reading the book to see if I actually feel the need to look at a running system. -- 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 gtaylor at tnetconsulting.net Sat Dec 25 08:51:29 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 24 Dec 2021 15:51:29 -0700 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: On 12/21/21 11:23 PM, jason-tuhs at shalott.net wrote: > As an end user, you would not care. That tends to explain why I've not personally cared. > As a vendor or distributor, you would care.  Anyone doing an OS or other > software distribution (think the BSDs, of course; but also think Apple > or Microsoft) needs to care.  Anyone selling a hardware device with > embedded software (think switches/routers; think IOT devices; think > consumer devices like DVRs; etc) needs to care.  GPL (or similar > "virally" licensed) software carries legal implications for anyone > selling or distributing products that contain such software; and this > can be a motivation to use software with less-restrictive license terms. Okay. My limited understanding is that the GPLed parts of the product must be made available. But I'm not aware that using GPLed parts means that /everything/ /else/ must also be made available. Also, I believe /made/ /available/ means that it must be accessible or provided when asked. Thus it does not mean that the GPLed code needs to be shipped with the product. > I'm aware of a few random features that are in ksh93 but not other > shells (random, trivial, example that I saw just today*: "printf > %(FORMAT)T"). That said, my first impulse would have been to say no, > there aren't any meaningful (technical) advantages to ksh over bash -- > except that it seems there's still some amount of active development > going on in ksh: The biggest motivation I had in a previous job was to make sure that my account's shell was set to a shell that lived on the root file system. I could easily have that shell test to see if my preferred shell was available and start or exec it. That way I could still log in if the file system with my preferred shell was not mounted. As if I needed to address the underlying issue that was preventing the desired shell from being accessible. E.g. /usr/bin/bash wasn't available b/c /usr wasn't automatically mounted at boot. > So I guess, for some people at least, there are indeed reasons to prefer > it, including (according to users in those github issues) performance. At my last job I helped administer some systems that didn't have any shells other than was was in the base OS installation. (We won't talk about why.) > On the licensing front, the GPL is an issue for bash; but zsh is > available as a more modern, fully-featured shell that avoids any GPL > issues.  This is why Apple switched the default shell in OSX from bash > to zsh: they wanted to avoid the GPLv3.  Previously, they had been > shipping the last GPLv2 version of bash, which was from 2006.  According > to this blog, they've been avoiding any GPLv3 code and actively working > to remove even GPLv2 code in OSX for quite a while: That makes sense. > * bash seems to recognize %(FORMAT)T, but only takes epoch seconds as an > argument.  ksh93 takes anything vaguely date-like.  zsh and pdksh don't > recognize it at all. Interesting. Thank you for the informative reply Jason. -- 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 rich.salz at gmail.com Sat Dec 25 09:15:39 2021 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 24 Dec 2021 18:15:39 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: > My limited understanding is that the GPLed parts of the product must be > made available. But I'm not aware that using GPLed parts means that > /everything/ /else/ must also be made available. > Your limited understanding is limited and/or incorrect, particularly for operating system vendors. This list is not the place to discuss the GPL, but please stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mphuff at gmail.com Sat Dec 25 09:34:57 2021 From: mphuff at gmail.com (Michael Huff) Date: Fri, 24 Dec 2021 14:34:57 -0900 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> <1653639b-8e41-7437-8c0e-32564dfdd788@laposte.net> <20211221162139.GP24180@mcvoy.com> <9e3b9669-6ffc-2701-bdcb-e287495419c0@spamtrap.tnetconsulting.net> Message-ID: > My limited understanding is that the GPLed parts of the product must be made available. But I'm not aware that using GPLed parts means that /everything/ /else/ must also be made available. >From what I read, you are correct -it doesn't. At least that's what the FSF appears to say themselves: https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndNonfreeOnSameMachine There's been some attempts over the years (eg Microsoft's "get the facts" campaign) to muddy the waters on that issue and paint the GNU license as acting "cancerous"; but I'm not aware of any legal precedents backing that up. Another part of the same page that you might find interesting (regarding distributing sources): https://www.gnu.org/licenses/gpl-faq.en.html#DistributeWithSourceOnInternet Of course if someone is acting as an owner or employee of a company they'll want to consult their legal staff in addition to reading what the GNU have to say as well. /disclaimer; I do not work in IT, but have used Unix and Linux for 25 years now -make of that what you will On Fri, Dec 24, 2021 at 1:52 PM Grant Taylor via TUHS wrote: > On 12/21/21 11:23 PM, jason-tuhs at shalott.net wrote: > > As an end user, you would not care. > > That tends to explain why I've not personally cared. > > > As a vendor or distributor, you would care. Anyone doing an OS or other > > software distribution (think the BSDs, of course; but also think Apple > > or Microsoft) needs to care. Anyone selling a hardware device with > > embedded software (think switches/routers; think IOT devices; think > > consumer devices like DVRs; etc) needs to care. GPL (or similar > > "virally" licensed) software carries legal implications for anyone > > selling or distributing products that contain such software; and this > > can be a motivation to use software with less-restrictive license terms. > > Okay. > > My limited understanding is that the GPLed parts of the product must be > made available. But I'm not aware that using GPLed parts means that > /everything/ /else/ must also be made available. > > Also, I believe /made/ /available/ means that it must be accessible or > provided when asked. Thus it does not mean that the GPLed code needs to > be shipped with the product. > > > I'm aware of a few random features that are in ksh93 but not other > > shells (random, trivial, example that I saw just today*: "printf > > %(FORMAT)T"). That said, my first impulse would have been to say no, > > there aren't any meaningful (technical) advantages to ksh over bash -- > > except that it seems there's still some amount of active development > > going on in ksh: > > The biggest motivation I had in a previous job was to make sure that my > account's shell was set to a shell that lived on the root file system. > > I could easily have that shell test to see if my preferred shell was > available and start or exec it. That way I could still log in if the > file system with my preferred shell was not mounted. As if I needed to > address the underlying issue that was preventing the desired shell from > being accessible. E.g. /usr/bin/bash wasn't available b/c /usr wasn't > automatically mounted at boot. > > > So I guess, for some people at least, there are indeed reasons to prefer > > it, including (according to users in those github issues) performance. > > At my last job I helped administer some systems that didn't have any > shells other than was was in the base OS installation. (We won't talk > about why.) > > > On the licensing front, the GPL is an issue for bash; but zsh is > > available as a more modern, fully-featured shell that avoids any GPL > > issues. This is why Apple switched the default shell in OSX from bash > > to zsh: they wanted to avoid the GPLv3. Previously, they had been > > shipping the last GPLv2 version of bash, which was from 2006. According > > to this blog, they've been avoiding any GPLv3 code and actively working > > to remove even GPLv2 code in OSX for quite a while: > > That makes sense. > > > * bash seems to recognize %(FORMAT)T, but only takes epoch seconds as an > > argument. ksh93 takes anything vaguely date-like. zsh and pdksh don't > > recognize it at all. > > Interesting. > > Thank you for the informative reply Jason. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Sat Dec 25 10:00:00 2021 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 24 Dec 2021 19:00:00 -0500 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: On Wed, Dec 22, 2021 at 10:12 AM Alexander Jacocks via TUHS < tuhs at minnie.tuhs.org> wrote: > ...I’m looking for photographs of university computer labs from 1985 until > 1995, particularly labs full of unix workstations, of course. Does anyone > here have photos like that in their collection?... > These are from University of Delaware, a little earlier than you hope for and no workstations, mid to late 1970s: https://udel.edu/~mm/udComputers/ Maybe not helpful to you but sharing just in case! Mike Markowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From mochid at netside.co.jp Sun Dec 26 22:37:57 2021 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Sun, 26 Dec 2021 21:37:57 +0900 (JST) Subject: [TUHS] 4.4BSD run on (Re: Are there images of any SVR2's available online?) In-Reply-To: References: <87abf999-1a19-9075-0087-2ba6d4f19261@spamtrap.tnetconsulting.net> Message-ID: <20211226.213757.532670001976002294.mochid@netside.co.jp> From: Grant Taylor via TUHS > what architectures does 4.4BSD run on? http://docs.freebsd.org/44doc/smm/01.setup/paper-2.html Primary target arch was HP9000/300. It seems that there were Sun SPARC (sun4c only), and R2000,R3000 based DECstation binaries. If you want to run on emulator, you might use DECstation (pmax) binary that I compiled below with GXemul. http://www.netside.co.jp/~mochid/comp/bsd44-build/ -mochid From will.senn at gmail.com Mon Dec 27 01:11:28 2021 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Dec 2021 09:11:28 -0600 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: On 12/24/21 10:57 AM, Seth Morabito wrote: > On Thu, Dec 23, 2021, at 8:38 PM, Will Senn wrote: >> All, >> >> Are there any bootable media available for any SVR 2 systems available online? Or are they all under IP lock and key? If so, what's the closest system that is available to get a feel for that variety of OS? >> >> Happy holidays, folks. >> >> Will > I have preserved the installation diskettes for AT&T System V Release 2.0.5 for 3B2 here: > > https://archives.loomcom.com/3b2/software/System_V_Release_2.0.5/ > > It should work on the SIMH 3B2/400 emulator, but it occurs to me I've never actually tried a full installation from these before (I've always used SVR 3) > > -Seth Just to close the loop on this... the 3b2 Core System V Release 2.0.5 floppies, C-Kermit, and the Editor Utilities borrowed from the Core System V Release 3.2 files (gotta have vi) work great under SIMH's 3b2/400. The same goes for Basic, C, Fortran, Pascal, Document Workbench, and Writers Workbench... (well at least they install, I haven't tested them all yet). Later, Will From arnold at skeeve.com Mon Dec 27 01:17:00 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Dec 2021 08:17:00 -0700 Subject: [TUHS] Are there images of any SVR2's available online? In-Reply-To: References: <936cfcbc-b3b1-99f8-6f68-ebab7e180770@gmail.com> Message-ID: <202112261517.1BQFH0dw003777@freefriends.org> Another S5R2 system is available here: https://github.com/philpem/freebee This is an emulator for the AT&T 3B1, a 68010 system with a mostly S5R2 user land and a primitive windowing system. The github page has links to pre-built disk images as well as instructions with links on installing from floppy images. Arnold From will.senn at gmail.com Mon Dec 27 10:31:38 2021 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Dec 2021 18:31:38 -0600 Subject: [TUHS] svr2 delete behavior Message-ID: <509bcd30-d0cb-2d39-3101-5c32ea3a058f@gmail.com> Did svr2 have anything similar to modern behavior when handling the delete/backspace key where the character is deleted from the input and rubbed out? The default, like in v6/v7 for erase and kill is # and @. I can live with this, if I can't get it to do the rubout, because at least you can see the # in the input, but if I can figure out how to get it to rubout the last character, I'd map erase to DEL, which I believe to be ^U (but since it's invisible, it's confusing when it doesn't rubout). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Mon Dec 27 11:24:59 2021 From: web at loomcom.com (Seth Morabito) Date: Sun, 26 Dec 2021 17:24:59 -0800 Subject: [TUHS] svr2 delete behavior In-Reply-To: <509bcd30-d0cb-2d39-3101-5c32ea3a058f@gmail.com> References: <509bcd30-d0cb-2d39-3101-5c32ea3a058f@gmail.com> Message-ID: <74999131-cf0a-41d1-9625-bc306febc7a8@www.fastmail.com> On Sun, Dec 26, 2021, at 4:31 PM, Will Senn wrote: > Did svr2 have anything similar to modern behavior when handling the delete/backspace key where the character is deleted from the input and rubbed out? The default, like in v6/v7 for erase and kill is # and @. I can live with this, if I can't get it to do the rubout, because at least you can see the # in the input, but if I can figure out how to get it to rubout the last character, I'd map erase to DEL, which I believe to be ^U (but since it's invisible, it's confusing when it doesn't rubout). > > Will You should be able to do `stty erase \^H` and `stty echoe` to get the rubout behavior you want with ^H (and of course you can combine them into one stty line) -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Mon Dec 27 21:47:58 2021 From: dot at dotat.at (Tony Finch) Date: Mon, 27 Dec 2021 11:47:58 +0000 Subject: [TUHS] Bolsky's C Programmer's Handbook Message-ID: <4bcc40d8-1ce3-97ed-744c-2e95838032c9@dotat.at> I have a copy of a spiral-bound booklet with yellow covers called "The C Programmer's Reference" by Morris I. Bolsky of the Systems Training Center, AT&T Bell Laboratories, (C) 1985. A curious little snapshot of 1980s pre-ANSI C. I posted a picture of the front cover (with table of contents) at https://twitter.com/fanf/status/1475407500946157570 I think I rescued it from the office clear-out in 2013 when Cambridge University Computing Service moved out of the old city-centre offices. I probably picked it up from a stack of old books that were to be chucked; wherever I found it, I can't remember who it belonged to. And now I no longer work for the University, it has come home with me. Tony. -- f.anthony.n.finch https://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Southerly or southeasterly, backing easterly or northeasterly later, 4 to 6, becoming variable 3 for a time in Cromarty and Forth. Moderate, occasionally rough at first in southwest Forties, Cromarty and Dogger. Rain or showers, fog patches developing. Moderate or good, occasionally very poor. From arnold at skeeve.com Mon Dec 27 22:08:30 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 27 Dec 2021 05:08:30 -0700 Subject: [TUHS] Bolsky's C Programmer's Handbook In-Reply-To: <4bcc40d8-1ce3-97ed-744c-2e95838032c9@dotat.at> References: <4bcc40d8-1ce3-97ed-744c-2e95838032c9@dotat.at> Message-ID: <202112271208.1BRC8UuV026638@freefriends.org> Bolsky was David Korn's co-author for the two editions of the book on ksh. The C book is probably worth hanging on to for historical value. Arnold Tony Finch wrote: > I have a copy of a spiral-bound booklet with yellow covers called "The C > Programmer's Reference" by Morris I. Bolsky of the Systems Training > Center, AT&T Bell Laboratories, (C) 1985. A curious little snapshot of > 1980s pre-ANSI C. > > I posted a picture of the front cover (with table of contents) at > https://twitter.com/fanf/status/1475407500946157570 > > I think I rescued it from the office clear-out in 2013 when Cambridge > University Computing Service moved out of the old city-centre offices. I > probably picked it up from a stack of old books that were to be chucked; > wherever I found it, I can't remember who it belonged to. And now I no > longer work for the University, it has come home with me. > > Tony. > -- > f.anthony.n.finch https://dotat.at/ > Southwest Forties, Cromarty, Forth, Tyne, Dogger: Southerly or > southeasterly, backing easterly or northeasterly later, 4 to 6, > becoming variable 3 for a time in Cromarty and Forth. Moderate, > occasionally rough at first in southwest Forties, Cromarty and Dogger. > Rain or showers, fog patches developing. Moderate or good, > occasionally very poor. From dot at dotat.at Mon Dec 27 22:20:34 2021 From: dot at dotat.at (Tony Finch) Date: Mon, 27 Dec 2021 12:20:34 +0000 Subject: [TUHS] Bolsky's C Programmer's Handbook In-Reply-To: <202112271208.1BRC8UuV026638@freefriends.org> References: <4bcc40d8-1ce3-97ed-744c-2e95838032c9@dotat.at> <202112271208.1BRC8UuV026638@freefriends.org> Message-ID: arnold at skeeve.com wrote: > The C book is probably worth hanging on to for historical value. That's my plan, yes :-) There is a apparently another copy in our local computer museum so I guess it isn't super rare. http://www.computinghistory.org.uk/det/18788/The-C-Programmers-Handbook/ Tony. -- f.anthony.n.finch https://dotat.at/ Fisher, German Bight: East or southeast 5 or 6, occasionally 7 in Fisher. Moderate or rough, becoming slight or moderate in German Bight. Rain or sleet. Good, occasionally poor. From jnc at mercury.lcs.mit.edu Tue Dec 28 00:37:43 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Dec 2021 09:37:43 -0500 (EST) Subject: [TUHS] svr2 delete behavior Message-ID: <20211227143743.B798F18C073@mercury.lcs.mit.edu> > From: Will Senn > anything similar to modern behavior when handling the delete/backspace > key where the character is deleted from the input and rubbed out? The > default, like in v6/v7 for erase and kill is # and @. I can live with > this, if I can't get it to do the rubout, because at least you can see > the # in the input I use ASCII 'backspace' (^H) on my V6, and it 'sort of' works; it doesn't erase the deleted character on the screen, but if one then types corrected characters, they overlay the deleted ones, leaving the corrected input. That should work on everything later than V6. The MIT PWB1 tty handler (link in a prior message) not only supported a 'kill line' (we generally used '^U') which actually visibly deleted the old line contents (on screen terminals, of course; on printing terminals you're stuck), it also had suppport for '^R' (re-type line) and some other stuff. Noel From will.senn at gmail.com Tue Dec 28 00:39:44 2021 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Dec 2021 08:39:44 -0600 Subject: [TUHS] svr2 delete behavior In-Reply-To: <74999131-cf0a-41d1-9625-bc306febc7a8@www.fastmail.com> References: <509bcd30-d0cb-2d39-3101-5c32ea3a058f@gmail.com> <74999131-cf0a-41d1-9625-bc306febc7a8@www.fastmail.com> Message-ID: <350ed660-6f96-b30c-7f01-438029a7d703@gmail.com> On 12/26/21 7:24 PM, Seth Morabito wrote: > On Sun, Dec 26, 2021, at 4:31 PM, Will Senn wrote: >> Did svr2 have anything similar to modern behavior when handling the >> delete/backspace key where the character is deleted from the input >> and rubbed out? The default, like in v6/v7 for erase and kill is # >> and @. I can live with this, if I can't get it to do the rubout, >> because at least you can see the # in the input, but if I can figure >> out how to get it to rubout the last character, I'd map erase to DEL, >> which I believe to be ^U (but since it's invisible, it's confusing >> when it doesn't rubout). >> >> Will > > You should be able to do `stty erase \^H` and `stty echoe` to get the > rubout behavior you want with ^H (and of course you can combine them > into one stty line) > > -Seth > -- >   Seth Morabito >   Poulsbo, WA > web at loomcom.com > > Got it working: echo 'stty intr \^c erase \^? kill \^u echoe' >> .profile relogin, and it works. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Dec 28 00:56:12 2021 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Dec 2021 08:56:12 -0600 Subject: [TUHS] svr2 delete behavior In-Reply-To: <20211227143743.B798F18C073@mercury.lcs.mit.edu> References: <20211227143743.B798F18C073@mercury.lcs.mit.edu> Message-ID: On 12/27/21 8:37 AM, Noel Chiappa wrote: > > From: Will Senn > > > anything similar to modern behavior when handling the delete/backspace > > key where the character is deleted from the input and rubbed out? The > > default, like in v6/v7 for erase and kill is # and @. I can live with > > this, if I can't get it to do the rubout, because at least you can see > > the # in the input > > I use ASCII 'backspace' (^H) on my V6, and it 'sort of' works; it doesn't > erase the deleted character on the screen, but if one then types corrected > characters, they overlay the deleted ones, leaving the corrected input. That > should work on everything later than V6. > > The MIT PWB1 tty handler (link in a prior message) not only supported a 'kill > line' (we generally used '^U') which actually visibly deleted the old line > contents (on screen terminals, of course; on printing terminals you're > stuck), it also had suppport for '^R' (re-type line) and some other stuff. > > Noel Hi Noel, that's interesting. I hadn't tried it in v6 in a while. I'd pretty much resigned myself to # and @. But I see the effect in v6, even without changing stty and it 'works', but in svr2, if I type lsa and then hit ^H it backs up a place, but then when I press enter the shell says something along the lines of - lsa^H: not found. But by adding stty erase ^H, it then 'works' the same as in v6. Seth's steer regarding setting erase and echoe 'fixed' things, once I figured out that having DEL doubling as intr wasn't ideal. Oh, the mysteries of terminal interaction. Add the fact that I'm using Mac OS's Terminal, and no telling what could happen. I generally turn on Option as Meta magic but I don't remap ^H as DEL :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Dec 28 02:05:27 2021 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Dec 2021 10:05:27 -0600 Subject: [TUHS] manpages in svr2 Message-ID: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> The core system of svr2 distributed by ATT for the 3b2-400 doesn't come with manpages installed. Does anybody know of a set of manpages for SVR2 that can be installed into the system? It's not the end of the world, if not... the user guide is available as a pdf, but it'd be handy to have man on the system. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 28 02:16:27 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Dec 2021 11:16:27 -0500 Subject: [TUHS] manpages in svr2 In-Reply-To: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> References: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> Message-ID: If you have to the installation distribution from them it would have been in a cpio file that is optionally installed On Mon, Dec 27, 2021 at 11:06 AM Will Senn wrote: > The core system of svr2 distributed by ATT for the 3b2-400 doesn't come > with manpages installed. Does anybody know of a set of manpages for SVR2 > that can be installed into the system? It's not the end of the world, if > not... the user guide is available as a pdf, but it'd be handy to have man > on the system. > > > Will > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Tue Dec 28 03:11:20 2021 From: web at loomcom.com (Seth Morabito) Date: Mon, 27 Dec 2021 09:11:20 -0800 Subject: [TUHS] manpages in svr2 In-Reply-To: References: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> Message-ID: On Mon, Dec 27, 2021, at 8:16 AM, Clem Cole wrote: > If you have to the installation distribution from them it would have been in a cpio file that is optionally installed > > On Mon, Dec 27, 2021 at 11:06 AM Will Senn wrote: >> The core system of svr2 distributed by ATT for the 3b2-400 doesn't come with manpages installed. Does anybody know of a set of manpages for SVR2 that can be installed into the system? It's not the end of the world, if not... the user guide is available as a pdf, but it'd be handy to have man on the system. >> >> >> Will > -- > Sent from a handheld expect more typos than usual I don't believe AT&T ever distributed manpages for the 3B2, but if I'm wrong and someone has a link to a set, I would be very happy to archive them! It's quite possible that at some point someone compiled a set of manpages as a third-party package, but unfortunately so many of the old 3B2 archives disappeared in the late 2000s before I (or anyone else I know) had a chance to archive them completely. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Dec 28 09:52:17 2021 From: cowan at ccil.org (John Cowan) Date: Mon, 27 Dec 2021 18:52:17 -0500 Subject: [TUHS] svr2 delete behavior In-Reply-To: References: <20211227143743.B798F18C073@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 27, 2021 at 9:56 AM Will Senn wrote: > I hadn't tried it in v6 in a while. I'd pretty much resigned myself to # > and @. But I see the effect in v6, even without changing stty and it > 'works', but in svr2, if I type lsa and then hit ^H it backs up a place, > but then when I press enter the shell says something along the lines of - > lsa^H: not found. > That's exactly what you expect when ^H is not magic: it is echoed back to /dev/tty like any other normal character, and your emulator does what ^H means per X3.4: it backs up the cursor by 1 column. But by adding stty erase ^H, it then 'works' the same as in v6. Seth's > steer regarding setting erase and echoe 'fixed' things, once I figured out > that having DEL doubling as intr wasn't ideal. > A nice hack in stty (though I am not sure how far back it goes): you can enter ^H either with an actual backspace character or with the two-character sequence ^ followed by h or H. The second form has the advantage that it can be typed correctly no matter how badly you have screwed up your control characters. Oh, the mysteries of terminal interaction. > Not _that_ mysterious. Grab ECMA standard 48 (technically equivalent to ANSI X3.64) at < https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf> and you'll know all about how terminal emulators behave. It isn't hard to read, once you have learned to read "00/13" as hex 0D, which everyone knows right off is CR. (If not, is your friend.) The reason for this bizarre row/column notation is so that escape sequences are always binary no matter the encoding: the sequence that introduces multi-character control sequences is usually spoken of as "ESC [", but technically it has to be sent to a conforming terminal as "\x1B\x45" even if the encoding is EBCDIC, where "ESC [" would be "\x27\xBA" (at least in the US/Canada flavor of EBCDIC). Bugs are another matter, of course. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Dec 29 07:15:41 2021 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Dec 2021 15:15:41 -0600 Subject: [TUHS] echo in v6/v7/sysvr2 Message-ID: <84e6263e-f990-cf9d-b988-55d15217771f@gmail.com> Is it possible to use echo to send a vt-100 escape sequence in v6/v7/sysvr2? I can write a c program to clear the screen and go home in sysvr2: #define ASCII_ESC 27 main() {     printf( "%c[2J", ASCII_ESC );     printf( "%c[H", ASCII_ESC ); } and it works fine. I can type the escape sequences in as well, but I'd just as soon write a shell script with an echo '[[2J;[[H' or something similar without having to compile a clear command. Is it possible and what do I need to know :)?. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Wed Dec 29 07:21:25 2021 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 28 Dec 2021 13:21:25 -0800 Subject: [TUHS] manpages in svr2 In-Reply-To: References: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> Message-ID: At Mon, 27 Dec 2021 09:11:20 -0800, "Seth Morabito" wrote: Subject: Re: [TUHS] manpages in svr2 > > I don't believe AT&T ever distributed manpages for the 3B2, but if I'm > wrong and someone has a link to a set, I would be very happy to > archive them! It's quite possible that at some point someone compiled > a set of manpages as a third-party package, but unfortunately so many > of the old 3B2 archives disappeared in the late 2000s before I (or > anyone else I know) had a chance to archive them completely. I definitely had man pages on my 3B2/400 with SysVr3 (and r3.2). They were pre-formatted (catman), not troff source though, IIRC. This was true for all of UNIX System V, at least from 2.0 on. There was a separate "source" distribution for the documentation, called the "Machine Readable Documentation", aka MRD. It contains source for all of the system documentation, not just the manual pages. The separation was necessary due to the separate licensing of the Documenter's Workbench. You couldn't format roff documents without it, not even with nroff, so source for the documentation would be useless to anyone who didn't also license DWB. (IIRC some Unix licensees kept their versions of V7 nroff working on their later SysV releases so that they could ship man page sources that would be usable, but using that ancient troff with modern printers was painful even with Chris Lewis' psroff.) The archive.org copy of SysVr2.0-NS32k contains source for DWB, MRD, as well as the system and commands: https://archive.org/download/ATTUNIXSystemVRelease4Version2/SysVr2.0_32000.tgz I don't know if it is legal or not, but it's been there for ages. IIRC somewhere there on archive.org there's also a SysVr2 for VAX too, complete with binaries and sources, and it has catman pages included. I do happen to have a copy of the MRD for SysVr3.2 for 3B2, but I don't think it is legal. I also had a legal binary license for DWB-2.0 for 3B2, but I don't think I have a copy of the media any more. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Wed Dec 29 07:45:14 2021 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 28 Dec 2021 13:45:14 -0800 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223161923.GT24180@mcvoy.com> Message-ID: At Thu, 23 Dec 2021 22:48:30 -0500, "Theodore Ts'o" wrote: Subject: Re: [TUHS] Photos of University Computer Labs - now off topic > > There have been patches proposed, but it turns out the sticky wicket > is that we're out of signal numbers on most architectures. Huh. What an interesting "excuse"! (Not that I know anything useful about the implementation in Linux....) > There are > code points that potentially could be repurposed, since they aren't > actually signaled from the kernel: > > SIGLOST - Term File lock lost (unused) > SIGSTKFLT - Term Stack fault on coprocessor (unused) If SIGLOST were used/needed it would seem like a very bad system design. > It's not impossible to deal with this, but no one has cared enough to > really try to push this through as a new feature. I personally can't stand using Linux, even casually for a very short sys-admin task, because of this missing feature. I think I would find it nearly impossible to go back to SysVr4 without SIGINFO too. It's just too damn convenient and useful, especially with ever more tools and utilities gaining interesting support for it. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From will.senn at gmail.com Wed Dec 29 07:48:05 2021 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Dec 2021 15:48:05 -0600 Subject: [TUHS] echo in v6/v7/sysvr2 In-Reply-To: <84e6263e-f990-cf9d-b988-55d15217771f@gmail.com> References: <84e6263e-f990-cf9d-b988-55d15217771f@gmail.com> Message-ID: Duh! RTFM - man echo (pdf, cuz I haven't quite figured out how got system pages yet): echo '\033[2J\033[H' works fine. The advantage of the c program is it doesn't put a newline after the escape sequences... On 12/28/21 3:15 PM, Will Senn wrote: > Is it possible to use echo to send a vt-100 escape sequence in > v6/v7/sysvr2? > > I can write a c program to clear the screen and go home in sysvr2: > > #define ASCII_ESC 27 > main() > { >     printf( "%c[2J", ASCII_ESC ); >     printf( "%c[H", ASCII_ESC ); > } > > and it works fine. I can type the escape sequences in as well, but I'd > just as soon write a shell script with an echo '[[2J;[[H' or something > similar without having to compile a clear command. Is it possible and > what do I need to know :)?. > > Thanks, > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Dec 29 07:49:19 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 28 Dec 2021 22:49:19 +0100 Subject: [TUHS] echo in v6/v7/sysvr2 In-Reply-To: <84e6263e-f990-cf9d-b988-55d15217771f@gmail.com> References: <84e6263e-f990-cf9d-b988-55d15217771f@gmail.com> Message-ID: <20211228214919.5eom3%steffen@sdaoden.eu> Will Senn wrote in <84e6263e-f990-cf9d-b988-55d15217771f at gmail.com>: |Is it possible to use echo to send a vt-100 escape sequence in v6/v7/sys\ |vr2? | |I can write a c program to clear the screen and go home in sysvr2: | |#define ASCII_ESC 27 |main() |{ |     printf( "%c[2J", ASCII_ESC ); |     printf( "%c[H", ASCII_ESC ); |} | |and it works fine. I can type the escape sequences in as well, but I'd |just as soon write a shell script with an echo '[[2J;[[H' or something |similar without having to compile a clear command. Is it possible and |what do I need to know :)?. cat is considered harmful. Is it??? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From will.senn at gmail.com Wed Dec 29 08:19:02 2021 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Dec 2021 16:19:02 -0600 Subject: [TUHS] manpages in svr2 In-Reply-To: References: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> Message-ID: Greg, I got manpages! Thanks. I took the tarball, extracted the files, cpio'd 'em onto a tape cartridge image, pulled 'em off the cartridge onto /usr2/manpages, installed the Documenter's Workbench and: nroff -man echo.1      ECHO(1)                   UNIX System V ECHO(1)      NAME           echo - echo arguments      SYNOPSIS           echo [ arg ] ... Yeeha. Now to type in Stephen's version of man in shell script form :). Thanks, Will On 12/28/21 3:21 PM, Greg A. Woods wrote: > At Mon, 27 Dec 2021 09:11:20 -0800, "Seth Morabito" wrote: > Subject: Re: [TUHS] manpages in svr2 >> I don't believe AT&T ever distributed manpages for the 3B2, but if I'm >> wrong and someone has a link to a set, I would be very happy to >> archive them! It's quite possible that at some point someone compiled >> a set of manpages as a third-party package, but unfortunately so many >> of the old 3B2 archives disappeared in the late 2000s before I (or >> anyone else I know) had a chance to archive them completely. > I definitely had man pages on my 3B2/400 with SysVr3 (and r3.2). > > They were pre-formatted (catman), not troff source though, IIRC. > > This was true for all of UNIX System V, at least from 2.0 on. > > There was a separate "source" distribution for the documentation, called > the "Machine Readable Documentation", aka MRD. It contains source for > all of the system documentation, not just the manual pages. > > The separation was necessary due to the separate licensing of the > Documenter's Workbench. You couldn't format roff documents without it, > not even with nroff, so source for the documentation would be useless to > anyone who didn't also license DWB. (IIRC some Unix licensees kept > their versions of V7 nroff working on their later SysV releases so that > they could ship man page sources that would be usable, but using that > ancient troff with modern printers was painful even with Chris Lewis' > psroff.) > > The archive.org copy of SysVr2.0-NS32k contains source for DWB, MRD, as > well as the system and commands: > > https://archive.org/download/ATTUNIXSystemVRelease4Version2/SysVr2.0_32000.tgz > > I don't know if it is legal or not, but it's been there for ages. > > IIRC somewhere there on archive.org there's also a SysVr2 for VAX too, > complete with binaries and sources, and it has catman pages included. > > I do happen to have a copy of the MRD for SysVr3.2 for 3B2, but I don't > think it is legal. I also had a legal binary license for DWB-2.0 for > 3B2, but I don't think I have a copy of the media any more. > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Wed Dec 29 09:43:23 2021 From: web at loomcom.com (Seth Morabito) Date: Tue, 28 Dec 2021 15:43:23 -0800 Subject: [TUHS] manpages in svr2 In-Reply-To: References: <8f494b35-59fe-c006-447a-e72cae1f3a0d@gmail.com> Message-ID: <00a5bf57-ea04-4791-b816-598e9e8c770f@www.fastmail.com> On Tue, Dec 28, 2021, at 1:21 PM, Greg A. Woods wrote: > At Mon, 27 Dec 2021 09:11:20 -0800, "Seth Morabito" wrote: > I do happen to have a copy of the MRD for SysVr3.2 for 3B2, but I don't > think it is legal. I also had a legal binary license for DWB-2.0 for > 3B2, but I don't think I have a copy of the media any more. Hello Greg, Would you be willing to share a copy of the MRD? I'd like to at least archive it, even if I don't make it public. If you're interested in seeing the current state of my 3B2 archive, it's available on the web at http://archive.loomcom.com/3b2/, and also on rsync at rsync://archives.loomcom.com/3b2/ I've given up trying to track down the current copyright holder of the software. AT&T certainly no longer has it, they gave it up ages ago. My trail grew cold after following the copyrights from AT&T to SCO to Novell to MicroFocus. It's not clear who owns what, and I'm afraid that even asking any more questions at this point. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From jjacocks at mac.com Wed Dec 29 12:44:52 2021 From: jjacocks at mac.com (Alexander Jacocks) Date: Tue, 28 Dec 2021 21:44:52 -0500 Subject: [TUHS] Photos of University Computer Labs In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> Message-ID: > On Dec 24, 2021, at 7:00 PM, Mike Markowski wrote: > > On Wed, Dec 22, 2021 at 10:12 AM Alexander Jacocks via TUHS > wrote: > ...I’m looking for photographs of university computer labs from 1985 until 1995, particularly labs full of unix workstations, of course. Does anyone here have photos like that in their collection?... > > These are from University of Delaware, a little earlier than you hope for and no workstations, mid to late 1970s: > > https://udel.edu/~mm/udComputers/ > > Maybe not helpful to you but sharing just in case! These are definitely helpful! Thanks so much to you, and to the others who have sent photos. I’m still interested in more, if anyone else has them to share. - Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Dec 30 00:33:17 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 29 Dec 2021 08:33:17 -0600 Subject: [TUHS] moving directories in svr2 Message-ID: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> I'm a little flummoxed in trying to move some directories around in svr2. Shouldn't the following work?     mkdir a     mkdir b     mv a b I get the following error: mv: b exists I tried many of the possible variants including: mv a b/ mv: b/ exists mv a b/a mv: directory rename only cd b mv ../a . mv: . exists mv ../a ./ mv: ./ exists mv ../a ./a mv: directory rename only If moving directories into existing directories wasn't allowed in those days, 1) how were directories managed? and 2) when did moving directories into directories become a thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Dec 30 01:02:09 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 29 Dec 2021 08:02:09 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> Message-ID: <202112291502.1BTF2926024814@freefriends.org> System V of that era didn't allow moving directories. You can copy them recursively with find and cpio with the option that makes hard links and then remove the old directory, or use a standard tar pipeline to copy the directory tree. BSD has always allowed moving directories; I *think* that descends from Research Unix but I don't remember for sure. HTH, Arnold Will Senn wrote: > I'm a little flummoxed in trying to move some directories around in > svr2. Shouldn't the following work? > >     mkdir a >     mkdir b >     mv a b > > I get the following error: > mv: b exists > > I tried many of the possible variants including: > > mv a b/ > mv: b/ exists > mv a b/a > mv: directory rename only > cd b > mv ../a . > mv: . exists > mv ../a ./ > mv: ./ exists > mv ../a ./a > mv: directory rename only > > > If moving directories into existing directories wasn't allowed in those > days, 1) how were directories managed? and 2) when did moving > directories into directories become a thing? > From clemc at ccc.com Thu Dec 30 01:17:57 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 10:17:57 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> Message-ID: Not until the BSD rename system call,. Try it on V6 or V7 and you will get 'directory exists' as an error. Think about the UNIX FS and the link system call. How is mv implemented? You link the file to the new directory and the unlink it from the old one. But a directory file can not be in two directories at the same time as the .. link would fail. When Joy created the rename system call it became possible. Until System V picked it up (IIRC was SVR3), only system that supported the BSD world. What I have forgotten is if the BSD mv command for 4.1 supported it. If it did then it was not atomic -- it would have had to create the new directory, move the contents independently and then remove the old one. FWIW: when we did the first SMP UNIX at Masscomp we had supported the BSD FS and the 4.1c/4.2 system calls. Joy's implementation of rename was a real mess. Making it atomic, supporting an SMP and deal with all the recovery paths on an error took some work. It's funny, the rename system call is a simple idea, but on a failure when partially thru it, makes unwinding the partial completion an interesting problem. Clem On Wed, Dec 29, 2021 at 9:34 AM Will Senn wrote: > I'm a little flummoxed in trying to move some directories around in svr2. > Shouldn't the following work? > > mkdir a > mkdir b > mv a b > > I get the following error: > mv: b exists > > I tried many of the possible variants including: > > mv a b/ > mv: b/ exists > mv a b/a > mv: directory rename only > cd b > mv ../a . > mv: . exists > mv ../a ./ > mv: ./ exists > mv ../a ./a > mv: directory rename only > > > If moving directories into existing directories wasn't allowed in those > days, 1) how were directories managed? and 2) when did moving directories > into directories become a thing? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Dec 30 01:38:05 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 29 Dec 2021 09:38:05 -0600 Subject: [TUHS] moving directories in svr2 In-Reply-To: <202112291502.1BTF2926024814@freefriends.org> References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> Message-ID: <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> That's fascinating. I always wondered how oldtimers were so facile with cpio and its ilk. If they had to use if for stuff like this, it's no wonder they built some muscle memory on it. Thanks, Will On 12/29/21 9:02 AM, arnold at skeeve.com wrote: > System V of that era didn't allow moving directories. You can copy them > recursively with find and cpio with the option that makes hard links > and then remove the old directory, or use a standard tar pipeline to > copy the directory tree. > > BSD has always allowed moving directories; I *think* that descends > from Research Unix but I don't remember for sure. > > HTH, > > Arnold > > Will Senn wrote: > >> I'm a little flummoxed in trying to move some directories around in >> svr2. Shouldn't the following work? >> >>     mkdir a >>     mkdir b >>     mv a b >> >> I get the following error: >> mv: b exists >> >> I tried many of the possible variants including: >> >> mv a b/ >> mv: b/ exists >> mv a b/a >> mv: directory rename only >> cd b >> mv ../a . >> mv: . exists >> mv ../a ./ >> mv: ./ exists >> mv ../a ./a >> mv: directory rename only >> >> >> If moving directories into existing directories wasn't allowed in those >> days, 1) how were directories managed? and 2) when did moving >> directories into directories become a thing? >> From will.senn at gmail.com Thu Dec 30 01:44:32 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 29 Dec 2021 09:44:32 -0600 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> Message-ID: On 12/29/21 9:17 AM, Clem Cole wrote: > Not until the BSD rename system call,. > > Try it on V6 or V7 and you will get 'directory exists' as an error. > Sure enough. I never really noticed. I guess cuz I was careful about creating directories in the first place. > Think about the UNIX FS and the link system call. How is mv > implemented?   You link the file to the new directory and the unlink > it from the old one.   But a directory file can not be in two > directories at the same time as the .. link would fail.      When Joy > created the rename system call it became possible.  Until System V > picked it up (IIRC was SVR3), only system that supported the BSD world. > Nice summary. I will add it to my systems programming investigations list. > What I have forgotten is if the BSD mv command for 4.1 supported it.  > If it did then it was not atomic -- it would have had to create the > new directory, move the contents independently and then remove the old > one. > > FWIW: when we did the first SMP UNIX at Masscomp we had supported the > BSD FS and the 4.1c/4.2 system calls.   Joy's implementation of rename > was a real mess.   Making it atomic, supporting an SMP and deal with > all the recovery paths on an error took some work.  It's funny, the > rename system call is a simple idea, but on a failure when > partially thru it, makes unwinding the partial completion an > interesting problem. It's impressive what early work was done and how few today really understand the challenges that were met and overcome to give us our cushy oses. > > Clem > > On Wed, Dec 29, 2021 at 9:34 AM Will Senn wrote: > > I'm a little flummoxed in trying to move some directories around > in svr2. Shouldn't the following work? > >     mkdir a >     mkdir b >     mv a b > > I get the following error: > mv: b exists > > I tried many of the possible variants including: > > mv a b/ > mv: b/ exists > mv a b/a > mv: directory rename only > cd b > mv ../a . > mv: . exists > mv ../a ./ > mv: ./ exists > mv ../a ./a > mv: directory rename only > > > If moving directories into existing directories wasn't allowed in > those days, 1) how were directories managed? and 2) when did > moving directories into directories become a thing? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Dec 30 01:44:24 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 29 Dec 2021 10:44:24 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: Wasn't some of that handled by the mvdir command? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 30 02:01:31 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 29 Dec 2021 08:01:31 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: On Dec 29, 2021, at 7:18 AM, Clem Cole wrote: > > Think about the UNIX FS and the link system call. How is mv implemented? You link the file to the new directory and the unlink it from the old one. But a directory file can not be in two directories at the same time as the .. link would fail. Don’t see why linking a dir in two places is a problem. From clemc at ccc.com Thu Dec 30 02:10:24 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 11:10:24 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> Message-ID: Just get the 4.1 man pages and it says: "Directories may only be moved within the same parent directory." On Wed, Dec 29, 2021 at 10:44 AM Will Senn wrote: > On 12/29/21 9:17 AM, Clem Cole wrote: > > Not until the BSD rename system call,. > > Try it on V6 or V7 and you will get 'directory exists' as an error. > > Sure enough. I never really noticed. I guess cuz I was careful about > creating directories in the first place. > > Think about the UNIX FS and the link system call. How is mv implemented? > You link the file to the new directory and the unlink it from the old one. > But a directory file can not be in two directories at the same time as > the .. link would fail. When Joy created the rename system call it > became possible. Until System V picked it up (IIRC was SVR3), only system > that supported the BSD world. > > Nice summary. I will add it to my systems programming investigations list. > > What I have forgotten is if the BSD mv command for 4.1 supported it. If > it did then it was not atomic -- it would have had to create the new > directory, move the contents independently and then remove the old one. > > FWIW: when we did the first SMP UNIX at Masscomp we had supported the BSD > FS and the 4.1c/4.2 system calls. Joy's implementation of rename was a > real mess. Making it atomic, supporting an SMP and deal with all the > recovery paths on an error took some work. It's funny, the rename system > call is a simple idea, but on a failure when partially thru it, makes > unwinding the partial completion an interesting problem. > > It's impressive what early work was done and how few today really > understand the challenges that were met and overcome to give us our cushy > oses. > > > Clem > > On Wed, Dec 29, 2021 at 9:34 AM Will Senn wrote: > >> I'm a little flummoxed in trying to move some directories around in svr2. >> Shouldn't the following work? >> >> mkdir a >> mkdir b >> mv a b >> >> I get the following error: >> mv: b exists >> >> I tried many of the possible variants including: >> >> mv a b/ >> mv: b/ exists >> mv a b/a >> mv: directory rename only >> cd b >> mv ../a . >> mv: . exists >> mv ../a ./ >> mv: ./ exists >> mv ../a ./a >> mv: directory rename only >> >> >> If moving directories into existing directories wasn't allowed in those >> days, 1) how were directories managed? and 2) when did moving directories >> into directories become a thing? >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 30 02:17:22 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 11:17:22 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: Where and when did mvdir(1) appear? It's not in Research or BSD. FWIW: in the old days, I just used tar cf - . | (cd some_place_else; tar xvpf - ) preserving permissions. The hardlink scheme of cpio was the one thing it could do that the original tar did not. Clem On Wed, Dec 29, 2021 at 10:46 AM Richard Salz wrote: > Wasn't some of that handled by the mvdir command? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Dec 30 02:33:24 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 29 Dec 2021 09:33:24 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> Message-ID: Kirk has said it took decades to get rename(2) right... it was by far the hardest system call to get right, especially in the face of concurrency. Warner Warner On Wed, Dec 29, 2021, 9:11 AM Clem Cole wrote: > Just get the 4.1 man pages and it says: "Directories may only be moved > within the same parent directory." > > On Wed, Dec 29, 2021 at 10:44 AM Will Senn wrote: > >> On 12/29/21 9:17 AM, Clem Cole wrote: >> >> Not until the BSD rename system call,. >> >> Try it on V6 or V7 and you will get 'directory exists' as an error. >> >> Sure enough. I never really noticed. I guess cuz I was careful about >> creating directories in the first place. >> >> Think about the UNIX FS and the link system call. How is mv implemented? >> You link the file to the new directory and the unlink it from the old >> one. But a directory file can not be in two directories at the same time >> as the .. link would fail. When Joy created the rename system call it >> became possible. Until System V picked it up (IIRC was SVR3), only system >> that supported the BSD world. >> >> Nice summary. I will add it to my systems programming investigations >> list. >> >> What I have forgotten is if the BSD mv command for 4.1 supported it. If >> it did then it was not atomic -- it would have had to create the new >> directory, move the contents independently and then remove the old one. >> >> FWIW: when we did the first SMP UNIX at Masscomp we had supported the BSD >> FS and the 4.1c/4.2 system calls. Joy's implementation of rename was a >> real mess. Making it atomic, supporting an SMP and deal with all the >> recovery paths on an error took some work. It's funny, the rename system >> call is a simple idea, but on a failure when partially thru it, makes >> unwinding the partial completion an interesting problem. >> >> It's impressive what early work was done and how few today really >> understand the challenges that were met and overcome to give us our cushy >> oses. >> >> >> Clem >> >> On Wed, Dec 29, 2021 at 9:34 AM Will Senn wrote: >> >>> I'm a little flummoxed in trying to move some directories around in >>> svr2. Shouldn't the following work? >>> >>> mkdir a >>> mkdir b >>> mv a b >>> >>> I get the following error: >>> mv: b exists >>> >>> I tried many of the possible variants including: >>> >>> mv a b/ >>> mv: b/ exists >>> mv a b/a >>> mv: directory rename only >>> cd b >>> mv ../a . >>> mv: . exists >>> mv ../a ./ >>> mv: ./ exists >>> mv ../a ./a >>> mv: directory rename only >>> >>> >>> If moving directories into existing directories wasn't allowed in those >>> days, 1) how were directories managed? and 2) when did moving directories >>> into directories become a thing? >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Dec 30 02:58:05 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 29 Dec 2021 11:58:05 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: Where and when did mvdir(1) appear? It's not in Research or BSD. > IIRC /etc/mvdir in early SysV? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 30 02:59:04 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 29 Dec 2021 08:59:04 -0800 Subject: [TUHS] moving directories in svr2 Message-ID:  On Dec 29, 2021, at 8:01 AM, Bakul Shah wrote: > On Dec 29, 2021, at 7:18 AM, Clem Cole wrote: >> >> Think about the UNIX FS and the link system call. How is mv implemented? You link the file to the new directory and the unlink it from the old one. But a directory file can not be in two directories at the same time as the .. link would fail. > > Don’t see why linking a dir in two places is a problem. To expand on this a bit, the “cd ..” case can be handled by not storing a .. link in a dir. in the first place! Store the $PWD path in the u struct. Then cd .. would simply lop off the last component, if one exists. Thus .. takes you back only on the path you used! This also takes care of the issue with symlinks (& does what csh did in user code). From clemc at ccc.com Thu Dec 30 03:04:00 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 12:04:00 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: On Wed, Dec 29, 2021 at 11:59 AM Bakul Shah wrote: > To expand on this a bit, the “cd ..” case can be handled by not storing a > .. > link in a dir. in the first place! Store the $PWD path in the u struct. > Then > cd .. would simply lop off the last component, if one exists. Thus .. takes > you back only on the path you used! This also takes care of the issue with > symlinks (& does what csh did in user code). Which is exactly the problem ... Your solution works as a runtime fix, sometimes. It's hardly sufficient and why I hate symlinks thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Dec 30 02:58:27 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 29 Dec 2021 11:58:27 -0500 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223161923.GT24180@mcvoy.com> Message-ID: (Moving to COFF, tuhs on bcc.) On Tue, Dec 28, 2021 at 01:45:14PM -0800, Greg A. Woods wrote: > > There have been patches proposed, but it turns out the sticky wicket > > is that we're out of signal numbers on most architectures. > > Huh. What an interesting "excuse"! (Not that I know anything useful > about the implementation in Linux....) If recall correctly, the last time someone tried to submit patches, they overloaded some signal that was in use, and it was NACK'ed on that basis. I personally didn't care, because on my systems, I'll use GUI program like xload, or if I need something more detailed, GKrellM. (And GKreelM can be used to remotely monitor servers as well.) > > SIGLOST - Term File lock lost (unused) > > SIGSTKFLT - Term Stack fault on coprocessor (unused) > > If SIGLOST were used/needed it would seem like a very bad system design. It's used in Solaris to report that the client NFSv4 code could not recover a file lock on recovery. So that means one of the first places to look would be to see if Ganesha (an open-source NFSv4 user-space client) isn't using SIGLOST (or might have plans to use SIGLOST in the feature). For a remote / distributed file system, Brewer's Theorem applies --- Consistency, Availability, Partition tolerance --- chose any two, but you're not always going to be able to get all three. Cheers, - Ted From douglas.mcilroy at dartmouth.edu Thu Dec 30 03:12:06 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 29 Dec 2021 12:12:06 -0500 Subject: [TUHS] moving directories in svr2 Message-ID: The first specific mention of moving directories in Research is in v10, but I'm sure that was implemented considerably earlier. The only things special about moving a directory were that it needed root privilege and checked against moving a directory into itself. As with ordinary files, copying (with loss of hard links) happened only when moving between different file systems. As far as I know, no atomicity precautions were taken. From arnold at skeeve.com Thu Dec 30 03:14:44 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 29 Dec 2021 10:14:44 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: <202112291714.1BTHEiXo008223@freefriends.org> Bakul Shah wrote: >  > On Dec 29, 2021, at 8:01 AM, Bakul Shah wrote: > > On Dec 29, 2021, at 7:18 AM, Clem Cole wrote: > >> > >> Think about the UNIX FS and the link system call. How is mv implemented? You link the file to the new directory and the unlink it from the old one. But a directory file can not be in two directories at the same time as the .. link would fail. > > > > Don’t see why linking a dir in two places is a problem. > > To expand on this a bit, the “cd ..” case can be handled by not storing a .. > link in a dir. in the first place! Store the $PWD path in the u struct. Then > cd .. would simply lop off the last component, if one exists. Thus .. takes > you back only on the path you used! This also takes care of the issue with > symlinks (& does what csh did in user code). Plan 9 eventually did something like this. I don't remember the details. Arnold From clemc at ccc.com Thu Dec 30 03:38:45 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 12:38:45 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <202112291714.1BTHEiXo008223@freefriends.org> References: <202112291714.1BTHEiXo008223@freefriends.org> Message-ID: At the risk of kicking a dead horse too much ... On Wed, Dec 29, 2021 at 12:14 PM wrote: > Plan 9 eventually did something like this. I don't remember the details. > Arnold - point taken but ... unfortunately, I think that the comparison is a little difficult because Plan9's concepts of namespaces is a tad different than UNIX's. But I'll let Rob or Ken comment as they lived and developed both systems. FWIW: An object store is something that retains information after the processes that operates on it complete -* i.e. *its a *static entity*. Links were (are) also a static concept. Late binding to names (like symlinks) are a dynamic (runtime idea). Bakul points out that by using the per process u area, the dynamic context can be retained. The observation is that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm not sure how you keep consistency in the static FS if you don't store the link in the inode. As someone that did, I suggest - try writing fsck if you are using dynamic content. How do you know? I'd still claim it is the same issue. Anyway, I suppose that like context sensitive symlinks (which I sorely miss), you could do this and keep a list of the N inodes for the N parents and then like CDSL's keep the one you used to get there in the u area so that .. picks the proper one on the way out and you can still have the static notion which something like fsck can check off line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Thu Dec 30 03:49:41 2021 From: brantley at coraid.com (Brantley Coile) Date: Wed, 29 Dec 2021 17:49:41 +0000 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <202112291714.1BTHEiXo008223@freefriends.org> Message-ID: Plan 9 can't move directories with mv. I will only change the name of them. (If this is the question. I was only half paying attention to the thread. Sorry) --bwc cessna% mkdir dira cessna% mkdir dirb cessna% touch dira/a cessna% touch dirb/b cessna% mv dira dirb mv: can't remove ./dirb: remove -- directory not empty To move contents of directories we use dircp. cessna% man dircp TAR(1) TAR(1) NAME tar, dircp - archiver SYNOPSIS tar key [ file ... ] dircp fromdir todir DESCRIPTION Tar saves and restores file trees. It is most often used to transport a tree of files from one system to another. The ... and .tz. If no extension matches, gzip is used. The z flag is unnecessary (but allowed) when using the t and x verbs on archives with recognized extensions. EXAMPLES Tar can be used to copy hierarchies thus: @{cd fromdir && tar c .} | @{cd todir && tar xT} Dircp does this. SOURCE /sys/src/cmd/tar.c /rc/bin/dircp SEE ALSO ar(1), bundle(1), tapefs(4), mkfs(8) cessna% > On Dec 29, 2021, at 12:38 PM, Clem Cole wrote: > > At the risk of kicking a dead horse too much ... > > On Wed, Dec 29, 2021 at 12:14 PM wrote: > Plan 9 eventually did something like this. I don't remember the details. > Arnold - point taken but ... unfortunately, I think that the comparison is a little difficult because Plan9's concepts of namespaces is a tad different than UNIX's. But I'll let Rob or Ken comment as they lived and developed both systems. > > FWIW: An object store is something that retains information after the processes that operates on it complete - i.e. its a static entity. Links were (are) also a static concept. Late binding to names (like symlinks) are a dynamic (runtime idea). Bakul points out that by using the per process u area, the dynamic context can be retained. The observation is that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm not sure how you keep consistency in the static FS if you don't store the link in the inode. As someone that did, I suggest - try writing fsck if you are using dynamic content. How do you know? I'd still claim it is the same issue. > > Anyway, I suppose that like context sensitive symlinks (which I sorely miss), you could do this and keep a list of the N inodes for the N parents and then like CDSL's keep the one you used to get there in the u area so that .. picks the proper one on the way out and you can still have the static notion which something like fsck can check off line. From rminnich at gmail.com Thu Dec 30 04:27:12 2021 From: rminnich at gmail.com (ron minnich) Date: Wed, 29 Dec 2021 10:27:12 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <202112291714.1BTHEiXo008223@freefriends.org> Message-ID: since .. came up, nobody mentioned it yet, https://plan9.io/sys/doc/lexnames.pdf but the subject line is "moving directories" and, as pointed out, on old school file systems with hard links, it's not a move, just an ln, more or less. And in the easy case, it's easy; and in the not so easy case, it can be impossible ... On newer systems, which don't have such notions as hard links, it's a different game, and on many, it may not be possible; dircp to the rescue, with all the pain that implies (doesn't go well when you are in CA and the server is in NJ, trust me :-) But this brings up a question I forgot: what was the last Unix version that let users make arbitrary links, such that the file system was no longer a DAG? I recall in v6 days hearing that earlier Unix allowed this, and that cleanup (via icheck and friends) got to be near impossible. On Wed, Dec 29, 2021 at 9:50 AM Brantley Coile wrote: > > Plan 9 can't move directories with mv. I will only change the name of them. > (If this is the question. I was only half paying attention to the thread. Sorry) > > --bwc > > cessna% mkdir dira > cessna% mkdir dirb > cessna% touch dira/a > cessna% touch dirb/b > cessna% mv dira dirb > mv: can't remove ./dirb: remove -- directory not empty > > To move contents of directories we use dircp. > > cessna% man dircp > > TAR(1) TAR(1) > > NAME > tar, dircp - archiver > > SYNOPSIS > tar key [ file ... ] > > dircp fromdir todir > > DESCRIPTION > Tar saves and restores file trees. It is most often used to > transport a tree of files from one system to another. The > > ... > and .tz. If no extension matches, gzip is used. The z > flag is unnecessary (but allowed) when using the t and > x verbs on archives with recognized extensions. > > EXAMPLES > Tar can be used to copy hierarchies thus: > > @{cd fromdir && tar c .} | @{cd todir && tar xT} > > Dircp does this. > > SOURCE > /sys/src/cmd/tar.c > /rc/bin/dircp > > SEE ALSO > ar(1), bundle(1), tapefs(4), mkfs(8) > > > > cessna% > > On Dec 29, 2021, at 12:38 PM, Clem Cole wrote: > > > > At the risk of kicking a dead horse too much ... > > > > On Wed, Dec 29, 2021 at 12:14 PM wrote: > > Plan 9 eventually did something like this. I don't remember the details. > > Arnold - point taken but ... unfortunately, I think that the comparison is a little difficult because Plan9's concepts of namespaces is a tad different than UNIX's. But I'll let Rob or Ken comment as they lived and developed both systems. > > > > FWIW: An object store is something that retains information after the processes that operates on it complete - i.e. its a static entity. Links were (are) also a static concept. Late binding to names (like symlinks) are a dynamic (runtime idea). Bakul points out that by using the per process u area, the dynamic context can be retained. The observation is that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm not sure how you keep consistency in the static FS if you don't store the link in the inode. As someone that did, I suggest - try writing fsck if you are using dynamic content. How do you know? I'd still claim it is the same issue. > > > > Anyway, I suppose that like context sensitive symlinks (which I sorely miss), you could do this and keep a list of the N inodes for the N parents and then like CDSL's keep the one you used to get there in the u area so that .. picks the proper one on the way out and you can still have the static notion which something like fsck can check off line. > From douglas.mcilroy at dartmouth.edu Thu Dec 30 05:13:25 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 29 Dec 2021 14:13:25 -0500 Subject: [TUHS] moving directories in svr2 Message-ID: > what was the last Unix version > that let users make arbitrary links, such that the file system was no > longer a DAG? I recall in v6 days hearing that earlier Unix allowed > this, and that cleanup (via icheck and friends) got to be near > impossible. >From v1 on (I'm not sure about PDP-7 Unix) only the superuser could do that, so what you heard strikes me as urban legend. Perhaps some installations abused root privilege to scramble the file system, but I certainly didn't see that happen in Research systems. Doug From jnc at mercury.lcs.mit.edu Thu Dec 30 05:33:48 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Dec 2021 14:33:48 -0500 (EST) Subject: [TUHS] moving directories in svr2 Message-ID: <20211229193348.A4ED018C08E@mercury.lcs.mit.edu> > From: Clem Cole > Try it on V6 or V7 and you will get 'directory exists' as an error. The V6 'mv' is prepared to move a directory _within_ a directory (i.e. 'rename' functionality). I'm not sure why it's not prepared to move within a partition; probably whoever wrote it wasn't prepared to deal with all the extra work for that (unlink from the old '..', then link to the '..' in the new directory, etc, etc). (The MIT PWB1 had a 'mvdir' written by Jeff Schiller, so PWB1 didn't have 'move directory' functionality before that. MIT must have been using the PWB1 system for 6.031, which I didn't recall; the comments in 'mvdir' refer to it being used there.) The V6 'mv' is fairly complicated (as I found out when I tried to modify it to use 'smdate()', so that moving a file didn't change its 'last write' date). Oddly enough, it is prepared to do cross-partition 'moves' (it forks a 'cp' to do the move). Although on V6, 'cp' only does one file; 'cp *.c {dest}' was not supported, there was 'cpall' for that. (Why no 'mvall', I wonder? It would have been trivial to clone 'cpall'.) Run fact; the V6 'mv' is the place that has the famous (?) "values of B will give rise to dom!" error message (in the directory-moing section). > if the BSD mv command for 4.1 supported it. If it did then it was not > atomic -- it would have had to create the new directory, move the > contents independently and then remove the old one. Speaking of atomic operation, in V6 'mkdir' (not being a system call) was not atomic, so if interrupted at 'just the right time', it could leave the FS in an inconsistent state. That's the best reason I've come across to make 'mkdir' a system call - it can be made atomic that way. Noel From crossd at gmail.com Thu Dec 30 05:37:37 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Dec 2021 14:37:37 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: On Wed, Dec 29, 2021 at 2:14 PM Douglas McIlroy wrote: > > what was the last Unix version > > that let users make arbitrary links, such that the file system was no > > longer a DAG? I recall in v6 days hearing that earlier Unix allowed > > this, and that cleanup (via icheck and friends) got to be near > > impossible. > > From v1 on (I'm not sure about PDP-7 Unix) only the superuser could do > that, so what you heard strikes me as urban legend. Perhaps some > installations abused root privilege to scramble the file system, but I > certainly didn't see that happen in Research systems. I recall doing this on some system via a lesser-known flag to `ln`. But I believe that a) you had to be root, and b) fsck sure was unhappy after the fact. I gather it was one of those, "wizard sysadmin invokes the deep magic from single user mode to fix the filesystem" and like other such arcana was mostly for dealing with seriously perverse failure modes, possibly in concert with the `unlink` command. https://www.freebsd.org/cgi/man.cgi?query=ln&apropos=0&sektion=0&manpath=SunOS+4.1.3&arch=default&format=html says that the `-f` flag to `ln` would force a hard link to a directory on (at least) SunOS 4.1.3. The 4.3BSD man page has this gem: "Hard links may not refer to directories (unless the proper incantations are supplied) and may not span file systems." And indeed, a quick look at /usr/src/bin/ln.c on a VAX running 4.3 shows that it has an undocumented `-f` flag: presumably the "proper incantation" mentioned in the man page. - Dan C. From crossd at gmail.com Thu Dec 30 06:15:48 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Dec 2021 15:15:48 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: On Wed, Dec 29, 2021 at 2:37 PM Dan Cross wrote: > The 4.3BSD man page has this gem: "Hard links may not refer to > directories (unless the proper incantations are supplied) and may not > span file systems." And indeed, a quick look at /usr/src/bin/ln.c on a > VAX running 4.3 shows that it has an undocumented `-f` flag: > presumably the "proper incantation" mentioned in the man page. On a lark, I decided to check for this on 7th Edition as well. The man page says, quite clearly: "It is forbidden to link to a directory or to link across file systems." However, /usr/src/cmd/ln.c has the undocumented `-f` flag, and if given, will elide checking for whether the "name1" argument is a directory or not. Looking at the kernel, as Doug mentioned, one must be the superuser to link a directory. - Dan C. From rich.salz at gmail.com Thu Dec 30 06:42:01 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 29 Dec 2021 15:42:01 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with: Each directory always has at least two entries. The name "." in each directory refers to the directory itself. Thus a program may read the current directory under the name “.” without knowing its complete path name. The name “..” by convention refers to the parent of the directory in which it appears, that is, to the directory in which it was created. The directory structure is constrained to have the form of a rooted tree. Except for the special entries “.” and “..”, each directory must appear as an entry in exactly one other, which is its parent. The reason for this is to simplify the writing of programs which visit subtrees of the directory structure, and more important, to avoid the separation of portions of the hierarchy. If arbitrary links to directories were permitted, it would be quite difficult to detect when the last connection from the root to a directory was severed -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Dec 30 06:58:10 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Dec 2021 15:58:10 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: Partitioning the tree sure seems like it would lead to a bad day, doesn't it? I expect the undocumented arcana related to linking directories was always an escape hatch for a skilled administrator to rescue a sick system. One can imagine any number of ways in which directory files could be corrupted; sufficient inspection of disk contents might give someone with the requisite low-level knowledge sufficient information that they could, say, reattach a pruned subtree with clever uses of `ln -f` and `unlink`. Did `icheck` and friends have something analogous to the `lost+found` directory created by `fsck`? I could imagine (somewhat painfully) executing those commands while in single-user mode on the console. - Dan C. On Wed, Dec 29, 2021 at 3:42 PM Richard Salz wrote: > > https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with: > > Each directory always has at least two entries. The > name "." in each directory refers to the directory itself. Thus a > program may read the current directory under the name “.” > without knowing its complete path name. The name “..” by > convention refers to the parent of the directory in which it > appears, that is, to the directory in which it was created. > The directory structure is constrained to have the form > of a rooted tree. Except for the special entries “.” and “..”, > each directory must appear as an entry in exactly one other, > which is its parent. The reason for this is to simplify the > writing of programs which visit subtrees of the directory > structure, and more important, to avoid the separation of > portions of the hierarchy. If arbitrary links to directories > were permitted, it would be quite difficult to detect when > the last connection from the root to a directory was severed From robpike at gmail.com Thu Dec 30 06:59:56 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 30 Dec 2021 07:59:56 +1100 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <202112291714.1BTHEiXo008223@freefriends.org> Message-ID: Not an answer, but relevant: Apple's Time Machine works by hard-linking directories to make the forest of old roots. -rob On Thu, Dec 30, 2021 at 5:28 AM ron minnich wrote: > since .. came up, nobody mentioned it yet, > https://plan9.io/sys/doc/lexnames.pdf > > but the subject line is "moving directories" and, as pointed out, on > old school file systems with hard links, it's not a move, just an ln, > more or less. And in the easy case, it's easy; and in the not so easy > case, it can be impossible ... > > On newer systems, which don't have such notions as hard links, it's a > different game, and on many, it may not be possible; dircp to the > rescue, with all the pain that implies (doesn't go well when you are > in CA and the server is in NJ, trust me :-) > > But this brings up a question I forgot: what was the last Unix version > that let users make arbitrary links, such that the file system was no > longer a DAG? I recall in v6 days hearing that earlier Unix allowed > this, and that cleanup (via icheck and friends) got to be near > impossible. > > On Wed, Dec 29, 2021 at 9:50 AM Brantley Coile > wrote: > > > > Plan 9 can't move directories with mv. I will only change the name of > them. > > (If this is the question. I was only half paying attention to the > thread. Sorry) > > > > --bwc > > > > cessna% mkdir dira > > cessna% mkdir dirb > > cessna% touch dira/a > > cessna% touch dirb/b > > cessna% mv dira dirb > > mv: can't remove ./dirb: remove -- directory not empty > > > > To move contents of directories we use dircp. > > > > cessna% man dircp > > > > TAR(1) TAR(1) > > > > NAME > > tar, dircp - archiver > > > > SYNOPSIS > > tar key [ file ... ] > > > > dircp fromdir todir > > > > DESCRIPTION > > Tar saves and restores file trees. It is most often used to > > transport a tree of files from one system to another. The > > > > ... > > and .tz. If no extension matches, gzip is used. The z > > flag is unnecessary (but allowed) when using the t and > > x verbs on archives with recognized extensions. > > > > EXAMPLES > > Tar can be used to copy hierarchies thus: > > > > @{cd fromdir && tar c .} | @{cd todir && tar xT} > > > > Dircp does this. > > > > SOURCE > > /sys/src/cmd/tar.c > > /rc/bin/dircp > > > > SEE ALSO > > ar(1), bundle(1), tapefs(4), mkfs(8) > > > > > > > > cessna% > > > On Dec 29, 2021, at 12:38 PM, Clem Cole wrote: > > > > > > At the risk of kicking a dead horse too much ... > > > > > > On Wed, Dec 29, 2021 at 12:14 PM wrote: > > > Plan 9 eventually did something like this. I don't remember the > details. > > > Arnold - point taken but ... unfortunately, I think that the > comparison is a little difficult because Plan9's concepts of namespaces is > a tad different than UNIX's. But I'll let Rob or Ken comment as they lived > and developed both systems. > > > > > > FWIW: An object store is something that retains information after the > processes that operates on it complete - i.e. its a static entity. Links > were (are) also a static concept. Late binding to names (like symlinks) > are a dynamic (runtime idea). Bakul points out that by using the per > process u area, the dynamic context can be retained. The observation is > that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm > not sure how you keep consistency in the static FS if you don't store the > link in the inode. As someone that did, I suggest - try writing fsck if > you are using dynamic content. How do you know? I'd still claim it is > the same issue. > > > > > > Anyway, I suppose that like context sensitive symlinks (which I sorely > miss), you could do this and keep a list of the N inodes for the N parents > and then like CDSL's keep the one you used to get there in the u area so > that .. picks the proper one on the way out and you can still have the > static notion which something like fsck can check off line. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 30 07:20:19 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Dec 2021 16:20:19 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: On Wed, Dec 29, 2021 at 3:59 PM Dan Cross wrote: > Did `icheck` and friends have something analogous to the `lost+found` > directory created by `fsck`? > The lost+found directory was a tjk-ism although I can get a very small level of credit/inspiration. It was born of need. Ted was explaining to me one night that one of the issues when you had identified a file that no directory was claiming was what to do with it. Originally, Ted linked lost files into root because there was usually only a couple of files, but ... we startiong seeing a situation where often the root directory did not have free directory slots. Some of the folks (I want to say it was either bio-med or architecture dept) had a recurring crash that occurred after a bunch of intermediate files had been created on a long running program. If the program stopped we had a way of restarting it part way using them. The problem was that people did not clean up the /tmp directory so the program unlinked them after creating them. But if it crashed, the files were still there but just connected to anything. Ted could find them with f*ck [it had a different name then]. I remember that we talked more about the issue and he came up with the idea of creating the directory lost+found and then preallocating a bunch of slots with a shell script instead of hoping the root directory was going to being available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 30 13:15:39 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 29 Dec 2021 19:15:39 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: Message-ID: <5467120F-A6D0-4882-A577-CB612321402E@iitbombay.org> > On Dec 29, 2021, at 12:42 PM, Richard Salz wrote: > > https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with: > > Each directory always has at least two entries. The > name "." in each directory refers to the directory itself. Thus a > program may read the current directory under the name “.” > without knowing its complete path name. The name “..” by > convention refers to the parent of the directory in which it > appears, that is, to the directory in which it was created. > The directory structure is constrained to have the form > of a rooted tree. Except for the special entries “.” and “..”, Note that "." or ".." entries are not needed if you store the entire path of the current working dir. in a process'es kernel state. My guess is *not* storing a path instead of a ptr to the inode was done to save on memory. > each directory must appear as an entry in exactly one other, > which is its parent. The reason for this is to simplify the > writing of programs which visit subtrees of the directory > structure, and more important, to avoid the separation of > portions of the hierarchy. If arbitrary links to directories > were permitted, it would be quite difficult to detect when > the last connection from the root to a directory was severed Every inode has a linkcount so detecting when the last conn. is severed not a problem. The separation *can* occur in any case if the system crashes at the wrong time and you can find #inode-number named directories in /lost+found. plan9 folks finessed the problem by not storing the linkcount. This is why moving a tree is a copy and then rm -rf of the old location. You win some, you lose some. Clem wrote: > Late binding to names (like symlinks) are a dynamic (runtime idea). Bakul points out that by using the per process u area, the dynamic context can be retained. The observation is that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm not sure how you keep consistency in the static FS if you don't store the link in the inode. Symlinks are not a runtime idea but $PWD is strictly a runtime thing. With symlinks perhaps 4.xBSD took the easy way out by decreeing that only 8(?) symlink may be traversed at runtime in interpreting a path for open etc, perhaps to save space but detecting loops can be done by storing per component and checking that. The same algorithm would help if multiple dir. hard links were allowed. Sure it has O(n) behavior but the user pays for it, or you can put a liberal limit on this array. I don't have much experience with crash recovery on plan9 so don't know if not having linkcounts is a problem. I haven't thought through about whether there are crash or concurrency related issues with allowin arbitray graphs by dir linking. But probably fixable by writing an intent log ala DBMS. > At the risk of kicking a dead horse too much I think it helps to once in a while wonder about why/how some system decisions were made and learn something from that; or gain a deeper understanding. At least that is my excuse! Thanks for all the responses. My take away is that while it is possible to allow arbitrary dir links, it would increase implementation complexity while the added benefit of it are few if any. From jnc at mercury.lcs.mit.edu Thu Dec 30 13:45:12 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Dec 2021 22:45:12 -0500 (EST) Subject: [TUHS] moving directories in svr2 Message-ID: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> > From: Bakul Shah > My guess is *not* storing a path instead of a ptr to the inode was done > to save on memory. More probably speed; those old disks were not fast, and on a PDP-11, disk caches were so small that converting the path to the current directory to its in memory inode could take a bunch of disk reads. > Every inode has a linkcount so detecting when the last conn. is severed > not a problem. Depends; if a directory _has_ to be empty before it can be deleted, maybe; but if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree underneath it has to be walked and the components deleted. That could take a while...) In the general case (e.g. without the restriction to a tree), it's basically the same problem as garbage collection in LISP. Noel From jay-tuhs9915 at toaster.com Thu Dec 30 13:40:57 2021 From: jay-tuhs9915 at toaster.com (Jay Logue) Date: Wed, 29 Dec 2021 19:40:57 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20211229193348.A4ED018C08E@mercury.lcs.mit.edu> References: <20211229193348.A4ED018C08E@mercury.lcs.mit.edu> Message-ID: <20211230034805.6CC299CD62@minnie.tuhs.org> v6 mv is indeed limited to renaming directories.  However, mv on v7 is able to move directories. Considering the similarity between the code bases, I think it would be fairly straightforward to support directory move on v6 in the same manner as was done in v7.  (On a related tangent, I found it fairly straightforward to implement modern rename(2) semantics on top of both code bases in my retro-fuse filesystem [e.g. v6fs.c:559 ].  Of course I had the benefit of a single-threaded execution environment.) Given the way mkdir and directory renaming worked in v6/v7, I'm not sure the lack of atomicity in directory move would have made things any worse for operators. It's interesting though that dcheck does not look for malformed directory links. --Jay On 12/29/2021 11:33 AM, Noel Chiappa wrote: > > From: Clem Cole > > > Try it on V6 or V7 and you will get 'directory exists' as an error. > > The V6 'mv' is prepared to move a directory _within_ a directory (i.e. > 'rename' functionality). I'm not sure why it's not prepared to move within > a partition; probably whoever wrote it wasn't prepared to deal with all the > extra work for that (unlink from the old '..', then link to the '..' in the > new directory, etc, etc). > > (The MIT PWB1 had a 'mvdir' written by Jeff Schiller, so PWB1 didn't have > 'move directory' functionality before that. MIT must have been using the PWB1 > system for 6.031, which I didn't recall; the comments in 'mvdir' refer to it > being used there.) > > The V6 'mv' is fairly complicated (as I found out when I tried to modify it > to use 'smdate()', so that moving a file didn't change its 'last write' > date). Oddly enough, it is prepared to do cross-partition 'moves' (it forks a > 'cp' to do the move). Although on V6, 'cp' only does one file; 'cp *.c > {dest}' was not supported, there was 'cpall' for that. (Why no 'mvall', I > wonder? It would have been trivial to clone 'cpall'.) > > Run fact; the V6 'mv' is the place that has the famous (?) "values of B will > give rise to dom!" error message (in the directory-moing section). > > > if the BSD mv command for 4.1 supported it. If it did then it was not > > atomic -- it would have had to create the new directory, move the > > contents independently and then remove the old one. > > Speaking of atomic operation, in V6 'mkdir' (not being a system call) was > not atomic, so if interrupted at 'just the right time', it could leave > the FS in an inconsistent state. That's the best reason I've come across > to make 'mkdir' a system call - it can be made atomic that way. > > Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 30 14:02:38 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 29 Dec 2021 20:02:38 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: <2FC8F8C7-DC17-4AC1-B8D4-E204A1CB378D@iitbombay.org> On Dec 29, 2021, at 7:45 PM, Noel Chiappa wrote: > >> From: Bakul Shah > >> My guess is *not* storing a path instead of a ptr to the inode was done >> to save on memory. > > More probably speed; those old disks were not fast, and on a PDP-11, disk > caches were so small that converting the path to the current directory to its > in memory inode could take a bunch of disk reads. Good point! >> Every inode has a linkcount so detecting when the last conn. is severed >> not a problem. > > Depends; if a directory _has_ to be empty before it can be deleted, maybe; but > if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree > underneath it has to be walked and the components deleted. That could take a > while...) In the general case (e.g. without the restriction to a tree), it's > basically the same problem as garbage collection in LISP. Indeed. You can detect circularly linked nodes when you try to delete sub directories. Then you have to ask the user whether to still delete it! In Lisp you can simply NIL a node and let the GC take care of it.... May be you can do the same with "rm -rf" but it may have a surprising/unintended outcome! An important point I missed. Thanks. > > Noel From drsalists at gmail.com Thu Dec 30 15:14:29 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 29 Dec 2021 21:14:29 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: On Wed, Dec 29, 2021 at 8:18 AM Clem Cole wrote: > Where and when did mvdir(1) appear? It's not in Research or BSD. > > FWIW: in the old days, I just used tar cf - . | (cd some_place_else; tar > xvpf - ) preserving permissions. The hardlink scheme of cpio was the > one thing it could do that the original tar did not. > I'm partial to: (cd /source/dir && tar cf - .) | (cd /dest/dir && tar xfp -) The &&'s make it so a typo is less likely to do something odd or even damaging. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Dec 31 02:22:38 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Dec 2021 11:22:38 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: sure - but old habits die hard (and Ken's man page for tar shows the form I use. I programmed my fingers to his example in 1978 I suspect). On Thu, Dec 30, 2021 at 12:14 AM Dan Stromberg wrote: > > On Wed, Dec 29, 2021 at 8:18 AM Clem Cole wrote: > >> Where and when did mvdir(1) appear? It's not in Research or BSD. >> >> FWIW: in the old days, I just used tar cf - . | (cd some_place_else; >> tar xvpf - ) preserving permissions. The hardlink scheme of cpio was >> the one thing it could do that the original tar did not. >> > > I'm partial to: > (cd /source/dir && tar cf - .) | (cd /dest/dir && tar xfp -) > > The &&'s make it so a typo is less likely to do something odd or even > damaging. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Dec 31 02:40:31 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 30 Dec 2021 11:40:31 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote: > > From: Bakul Shah > > > My guess is *not* storing a path instead of a ptr to the inode was done > > to save on memory. > > More probably speed; those old disks were not fast, and on a PDP-11, disk > caches were so small that converting the path to the current directory to its > in memory inode could take a bunch of disk reads. The other problem with storing the path as a string is that if higher-level directories get renamed, the path would become invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would become invalidated. Sure, you could scan the pwd of all the processes running on the system and do edit all of the strings, but once you go SMP, the potential locking pitfalls would be numerous. - Ted From cowan at ccil.org Fri Dec 31 04:02:27 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 30 Dec 2021 13:02:27 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: On Thu, Dec 30, 2021 at 12:15 AM Dan Stromberg wrote: FWIW: in the old days, I just used tar cf - . | (cd some_place_else; tar >> xvpf - ) preserving permissions. >> > In the new days, rsync -a dir1/ dir2 is the ticket (derived from "is etiquette", if you can believe it). You need the terminating slash to prevent dir1 from becoming a subdirectory of dir2; dir1/* would of course not copy dotfiles. (I grew weary of typing "cp -r dir1/.[a-zA-Z]* dir2" to copy dotfiles and dotdirectories left behind.) The -a flag ensures permissions, symlinks, etc. are preserved. If you rsync more than once, only the files in dir1 that have changed are copied. You can also use user at host:path as either argument to make it work over ssh, which is the common use case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Dec 31 05:10:02 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 30 Dec 2021 13:10:02 -0600 Subject: [TUHS] BSD 2.11 documentation Message-ID: <4407AB71-8024-4F83-ACA8-59898315E14B@gmail.com> Are there any extant 2.11 manuals other than the online manual and various install and configure PDFs, available for download? Also, am I understanding correctly that 2.11 is 2.10 plus some 4.3 backports and a ton of patches? If there aren’t any 2.11 specific docs, what would be the closest of what is available? Will Sent from my iPhone From imp at bsdimp.com Fri Dec 31 06:10:27 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Dec 2021 13:10:27 -0700 Subject: [TUHS] BSD 2.11 documentation In-Reply-To: <4407AB71-8024-4F83-ACA8-59898315E14B@gmail.com> References: <4407AB71-8024-4F83-ACA8-59898315E14B@gmail.com> Message-ID: On Thu, Dec 30, 2021 at 12:10 PM Will Senn wrote: > Are there any extant 2.11 manuals other than the online manual and various > install and configure PDFs, available for download? > > Also, am I understanding correctly that 2.11 is 2.10 plus some 4.3 > backports and a ton of patches? If there aren’t any 2.11 specific docs, > what would be the closest of what is available? > BSD2.11 as released was BSD2.10 with even more 4.3 backports (though that process started before 2.10 was released). BSD2.11-pl473 has a lot that's not been summarized. Release notes / installation guides have been updated as things like disk labels were added. But I've not seen any comprehensive summary of the patches. I should spend some time putting something together that summarizes things (rather than the tick-tock of each patch, some of which fix very niche bugs, others which add an ANSI-C compiler). There's also a few bugs that were fixed that didn't get proper patches that you can detect with careful diffing, at least in the early days... https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/ has the latest, nearly canonical version of 2.11BSD. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Dec 31 08:10:55 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 30 Dec 2021 16:10:55 -0600 Subject: [TUHS] v7 software Message-ID: I'm tooling around doing my annual dive into operating systems ancient and not-so-ancient and I've gotten back around to v7 because it has a working f77 in baseline. The 3b2 has f77 as an installable package but it crashes and burns with read statements like: read *,var - in both sysvr2 and sysvr3. After consulting with the fortran expert, I'm gonna chalk it up to "man there's a lot of backstory to these seemingly simple issues" and just work with v7... in full disclosure f77 also seems to work fine on 211bsd, but that's too new for today's dive :). Anyhow, I ran through my install notes from back in 2017 and did a few updates on them to update urls (would everyone just go ahead and move to https already?), fix some clunky examples, fix some typos, and update to a more recent host environment (although some would argue that Mojave is out of date - just give me a drop in replacement for Adobe Acrobat Pro X (a 32 bit app) that doesn't phone home every 5 minutes and I'll move to Monterey). Version 1.7 of the doc is posted on the blog: https://decuser.blogspot.com/ Anyway, now I'm ready to add stuff to my shiny new v7 instance and document the additions. So, on to the question of the hour... I did some looking around and couldn't easily locate any v7 software archives for additional software that will run on v7 (not the distros, which are adequately hosted in the Unix Archive). Stuff like pascal, fortran iv, fortran 90, basic, lisp and the ilk. Do y'all know of any good caches? Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Dec 31 08:31:09 2021 From: crossd at gmail.com (Dan Cross) Date: Thu, 30 Dec 2021 17:31:09 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: > On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote: > > > From: Bakul Shah > > > > > My guess is *not* storing a path instead of a ptr to the inode was done > > > to save on memory. > > > > More probably speed; those old disks were not fast, and on a PDP-11, disk > > caches were so small that converting the path to the current directory to its > > in memory inode could take a bunch of disk reads. > > The other problem with storing the path as a string is that if > higher-level directories get renamed, the path would become > invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone > renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would > become invalidated. Why? Presumably as you traversed the filesystem, you'd cache, (path component, inode) pairs and keep a ref on the inode. For any given file, including $CWD, you'd know it's pathname from the root as you accessed it, but if it got renamed, it wouldn't matter because you'd have cached a reference to the inode. > Sure, you could scan the pwd of all the processes running on the > system and do edit all of the strings, but once you go SMP, the > potential locking pitfalls would be numerous. I don't see the need for that. What am I missing? - Dan C. From rich.salz at gmail.com Fri Dec 31 09:04:11 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 30 Dec 2021 18:04:11 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <529fceae-2493-e9b1-c949-928e95e430e1@gmail.com> <202112291502.1BTF2926024814@freefriends.org> <3606ba6d-7d00-01f2-2a52-06cfb440dfbb@gmail.com> Message-ID: > In the new days, rsync -a dir1/ dir2 is the ticket ... > If you rsync more than once, only the files in dir1 that have changed are > copied. > More then that. It uses a clever algorithm to send over only changes. It was the basis of Tridgedell's PhD thesis. https://www.samba.org/~tridge/phd_thesis.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Dec 31 09:50:03 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 30 Dec 2021 17:50:03 -0600 Subject: [TUHS] v7 bas - "Ken Thompson's BASIC" Message-ID: So, I was bemoaning the fact that I couldn't really make sense of the bas command in v7. In sysv2, it works and is similar enough to modern dialects that I was able to get a simple example working, but with v7, the best I was able to do was use it interactively, as a calculator. Then I went looking for v7 videos on youtube and came across this Dr. Dave's Diversions video: https://www.youtube.com/watch?v=LZUMNZTUJos In it Dr. Dave demos a few simple versions of 99 bottles of beer in v7. Wow! I wondered how he'd glommed the inner workings of bas - did he read a book, just know it naturally, phone a friend, or what? Well, as it turned out, he... wait for it... read the bas(1) man page! Wha?! Ridiculous. So, I pulled out my v7 phone book and read the bas(1) man page and sure enough, it was all there... how '_' is used for negation, how those arcane for loops work, arrays?!, function calls?!, etc and so on, all in 3 short pages. So, two observations: 1. Those man pages from back in the day - wow. So terse, yet so well written. With a little help from a friend (thanks, Dr Dave), they're really all you need, sometimes. 2. Those early apps - wow. So obscure these days, but so ahead of their time, too (thanks, Ken for making Dec 2021 interesting by doing what you did back in the early 70's). And a question (you knew it was coming): Besides the bas(1) page, is there anything else written on Ken's basic out there in the wild? Oh, and a bonus question, draw and erase from v5 appear to still be around in v7, but not documented in the man page. Did it work and has anyone written a Tektronix 611 emulator that works with v7? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 31 10:43:37 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 30 Dec 2021 16:43:37 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> On Dec 30, 2021, at 2:31 PM, Dan Cross wrote: > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: >> >> The other problem with storing the path as a string is that if >> higher-level directories get renamed, the path would become >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would >> become invalidated. > > Why? Presumably as you traversed the filesystem, you'd cache, (path > component, inode) pairs and keep a ref on the inode. For any given > file, including $CWD, you'd know it's pathname from the root as you > accessed it, but if it got renamed, it wouldn't matter because you'd > have cached a reference to the inode. Without the ".." entry you can't map a dir inode back to a path. Note that something similar can happen even today: $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. cd: no such file or directory: .. $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b ls: ../b: No such file or directory You can't protect the user from every such case. Storing a path instead of the cwd inode simply changes the symptoms. From nw at retrocomputingtasmania.com Fri Dec 31 10:53:14 2021 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Fri, 31 Dec 2021 11:53:14 +1100 Subject: [TUHS] v7 bas - "Ken Thompson's BASIC" In-Reply-To: References: Message-ID: Regarding this BASIC or something contemporaneous does anyone recall the (perhaps) apocryphal story that an early version was written in PDP-11 assembler in a single afternoon? A few times I've gone looking for the original comment, I assume it was in a UNIX newsletter or in one of the USENET groups, but I've never found it. From robpike at gmail.com Fri Dec 31 11:00:29 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 31 Dec 2021 12:00:29 +1100 Subject: [TUHS] moving directories in svr2 In-Reply-To: <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> Message-ID: Grumpy hat on. Sometimes the Unix community suffers from the twin attitudes of a) believing if it can't be done perfectly, any improvement shouldn't be attempted at all and b) it's already done as well as is possible anyway. I disagree with both of these positions, obviously, but have given up pushing against them. We're in the 6th decade of Unix and we still suffer from unintended, fixable consequences of decisions made long long ago. Grumpy hat off. -rob On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah wrote: > On Dec 30, 2021, at 2:31 PM, Dan Cross wrote: > > > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: > >> > >> The other problem with storing the path as a string is that if > >> higher-level directories get renamed, the path would become > >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone > >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would > >> become invalidated. > > > > Why? Presumably as you traversed the filesystem, you'd cache, (path > > component, inode) pairs and keep a ref on the inode. For any given > > file, including $CWD, you'd know it's pathname from the root as you > > accessed it, but if it got renamed, it wouldn't matter because you'd > > have cached a reference to the inode. > > Without the ".." entry you can't map a dir inode back to a path. > Note that something similar can happen even today: > > $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. > cd: no such file or directory: .. > > $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b > ls: ../b: No such file or directory > > You can't protect the user from every such case. Storing a path > instead of the cwd inode simply changes the symptoms. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Dec 31 11:21:30 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Dec 2021 20:21:30 -0500 Subject: [TUHS] v7 software In-Reply-To: References: Message-ID: Joy’s original 2BSD tape will give you UCB Pascal. For anything else you'll probably want to find some of the old USENIX tapes. Warren has some of them, although I'm not sure he has the complete set. BTW: The Cooper Union folks got the DEC Fortran to run at one point. But it was quite a task, as it involved running a partial PDP-10/TOPS-10 user space emulator so they could run the DEC BLISS-10 compiler [this was long before simh]. I also think that ultrix11 binaries will on V7 so there are other language processors there including ftn. You’ll need to bring the dec linker over from Ultrix to use them as they output objs that are not the same although the final output is an a.out. On Thu, Dec 30, 2021 at 5:11 PM Will Senn wrote: > I'm tooling around doing my annual dive into operating systems ancient and > not-so-ancient and I've gotten back around to v7 because it has a working > f77 in baseline. The 3b2 has f77 as an installable package but it crashes > and burns with read statements like: read *,var - in both sysvr2 and > sysvr3. After consulting with the fortran expert, I'm gonna chalk it up to > "man there's a lot of backstory to these seemingly simple issues" and just > work with v7... in full disclosure f77 also seems to work fine on 211bsd, > but that's too new for today's dive :). > > Anyhow, I ran through my install notes from back in 2017 and did a few > updates on them to update urls (would everyone just go ahead and move to > https already?), fix some clunky examples, fix some typos, and update to a > more recent host environment (although some would argue that Mojave is out > of date - just give me a drop in replacement for Adobe Acrobat Pro X (a 32 > bit app) that doesn't phone home every 5 minutes and I'll move to > Monterey). Version 1.7 of the doc is posted on the blog: > https://decuser.blogspot.com/ > > Anyway, now I'm ready to add stuff to my shiny new v7 instance and > document the additions. So, on to the question of the hour... I did some > looking around and couldn't easily locate any v7 software archives for > additional software that will run on v7 (not the distros, which are > adequately hosted in the Unix Archive). Stuff like pascal, fortran iv, > fortran 90, basic, lisp and the ilk. Do y'all know of any good caches? > > Later, > > Will > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 31 11:45:43 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 30 Dec 2021 17:45:43 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> Message-ID: ? I was just explaining Ts'o's point, not agreeing with it. The first example I gave works just fine on plan9 (unlike on unix). And since it doesn't allow renames, the scenario T'so outlines can't happen there! But we were discussing Unix here. As for symlinks, if we have to have them, storing a path actually makes their use less surprising. > We're in the 6th decade of Unix and we still suffer from unintended, fixable consequences of decisions made long long ago. No argument here. Perhaps you can suggest a path for fixing? > On Dec 30, 2021, at 5:00 PM, Rob Pike wrote: > > Grumpy hat on. > > Sometimes the Unix community suffers from the twin attitudes of a) believing if it can't be done perfectly, any improvement shouldn't be attempted at all and b) it's already done as well as is possible anyway. > > I disagree with both of these positions, obviously, but have given up pushing against them. > > We're in the 6th decade of Unix and we still suffer from unintended, fixable consequences of decisions made long long ago. > > Grumpy hat off. > > -rob > > > On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah > wrote: > On Dec 30, 2021, at 2:31 PM, Dan Cross > wrote: > > > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o > wrote: > >> > >> The other problem with storing the path as a string is that if > >> higher-level directories get renamed, the path would become > >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone > >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would > >> become invalidated. > > > > Why? Presumably as you traversed the filesystem, you'd cache, (path > > component, inode) pairs and keep a ref on the inode. For any given > > file, including $CWD, you'd know it's pathname from the root as you > > accessed it, but if it got renamed, it wouldn't matter because you'd > > have cached a reference to the inode. > > Without the ".." entry you can't map a dir inode back to a path. > Note that something similar can happen even today: > > $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. > cd: no such file or directory: .. > > $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b > ls: ../b: No such file or directory > > You can't protect the user from every such case. Storing a path > instead of the cwd inode simply changes the symptoms. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Dec 31 12:23:36 2021 From: athornton at gmail.com (Adam Thornton) Date: Thu, 30 Dec 2021 19:23:36 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> Message-ID: Moving to COFF, perhaps prematurely, but... It feels weird to be a Unix native (which I consider myself: got my first taste of Irix and SVR3 in 1989, went to college where it was a Sun-mostly environment, started running Linux on my own machines in 1992 and never stopped). (For purposes of this discussion, of course Linux is Unix.) It feels weird the same way it was weird when I was working for Express Scripts, and then ESRX bought Medco, and all of a sudden we were the 500-lb Gorilla. That's why I left: we (particularly my little group) had been doing some fairly cool and innovative stuff, and after that deal closed, we switched over entirely to playing defense, and it got really boring really fast. My biggest win after that was showing that Pega ran perfectly fine on Tomcat, which caused IBM to say something like "oh did we say $5 million a year to license Websphere App Server? Uh...we meant $50K." So I saved them a lot of money but it sucked to watch several months' work flushed down the toilet, even though the savings to the company was many times my salary for those months. But the weird part is similar: Unix won. Windows *lost*. Sure, corporate desktops still mostly run Windows, and those people who use it mostly hate it. But people who like using computers...use Macs (or, sure, Linux, and then there are those weirdos like me who enjoy running all sorts of ancient-or-niche-systems, many of which are Unix). And all the people who don't care do computing tasks on their phones, which are running either Android--a Unix--or iOS--also a Unix. It's ubiquitous. It's the air you breathe. It's no longer strange to be a Unix user, it means you use a 21st-century electronic device. And, sure, it's got its warts, but it's still basically the least-worst thing out there. And it continues to flabbergast me that a typesetting system designed to run on single-processor 16-bit machines has, basically, conquered the world. Adam P.S. It's also about time, he said with a sigh of relief, having been an OS/2 partisan, and a BeOS partisan, back in the day. Nice to back a winning horse for once. On Thu, Dec 30, 2021 at 6:46 PM Bakul Shah wrote: > ? > > I was just explaining Ts'o's point, not agreeing with it. The first > example I > gave works just fine on plan9 (unlike on unix). And since it doesn't allow > renames, the scenario T'so outlines can't happen there! But we were > discussing Unix here. > > As for symlinks, if we have to have them, storing a path actually makes > their > use less surprising. > > We're in the 6th decade of Unix and we still suffer from unintended, > fixable consequences of decisions made long long ago. > > > No argument here. Perhaps you can suggest a path for fixing? > > On Dec 30, 2021, at 5:00 PM, Rob Pike wrote: > > Grumpy hat on. > > Sometimes the Unix community suffers from the twin attitudes of a) > believing if it can't be done perfectly, any improvement shouldn't be > attempted at all and b) it's already done as well as is possible anyway. > > I disagree with both of these positions, obviously, but have given up > pushing against them. > > We're in the 6th decade of Unix and we still suffer from unintended, > fixable consequences of decisions made long long ago. > > Grumpy hat off. > > -rob > > > On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah wrote: > >> On Dec 30, 2021, at 2:31 PM, Dan Cross wrote: >> > >> > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: >> >> >> >> The other problem with storing the path as a string is that if >> >> higher-level directories get renamed, the path would become >> >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone >> >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would >> >> become invalidated. >> > >> > Why? Presumably as you traversed the filesystem, you'd cache, (path >> > component, inode) pairs and keep a ref on the inode. For any given >> > file, including $CWD, you'd know it's pathname from the root as you >> > accessed it, but if it got renamed, it wouldn't matter because you'd >> > have cached a reference to the inode. >> >> Without the ".." entry you can't map a dir inode back to a path. >> Note that something similar can happen even today: >> >> $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. >> cd: no such file or directory: .. >> >> $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b >> ls: ../b: No such file or directory >> >> You can't protect the user from every such case. Storing a path >> instead of the cwd inode simply changes the symptoms. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Fri Dec 31 13:05:08 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 30 Dec 2021 22:05:08 -0500 Subject: [TUHS] v7 software Message-ID: > Joy’s original 2BSD tape will give you UCB Pascal. While I agree with Kernighan that Pascal is not my favorite programming language, UCB Pascal is my favorite compiler because of its spectacularly good syntax diagnostics. The diagnostics are automatically generated, so they have a completely consistent style and never go down rabbit holes trying to explain an error. The UCB trick is to report the exact spot where LR parsing chokes and suggest a canonical alternate token that allows progress. This simple strategy is startlingly effective; the compiler taught me Pascal in an evening. It occurred to me that Pascal would be a suitable language in which to express a certain algorithm. Having skimmed the Pascal report a year or more earlier, I knew it was a pretty typical language, so I grabbed a sample program from somewhere and plowed ahead. I made mistake after mistake, but every diagnostic was instantly suggestive. By the end of the session I had a polished working program. In due time it was accepted for publication. Doug From tytso at mit.edu Fri Dec 31 13:08:29 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 30 Dec 2021 22:08:29 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote: > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: > > On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote: > > > > From: Bakul Shah > > > > > > > My guess is *not* storing a path instead of a ptr to the inode was done > > > > to save on memory. > > > > > > More probably speed; those old disks were not fast, and on a PDP-11, disk > > > caches were so small that converting the path to the current directory to its > > > in memory inode could take a bunch of disk reads. > > > > The other problem with storing the path as a string is that if > > higher-level directories get renamed, the path would become > > invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone > > renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would > > become invalidated. > > Why? Presumably as you traversed the filesystem, you'd cache, (path > component, inode) pairs and keep a ref on the inode. For any given > file, including $CWD, you'd know it's pathname from the root as you > accessed it, but if it got renamed, it wouldn't matter because you'd > have cached a reference to the inode. I was responding to Bakul's suggestion that the original Unix could/should have stored the cwd as a string, instead of a pointer to a directory inode. If you stored the cwd as a string, then you could interpret .. by chopping off the last file name component of the string, and so now you could have hard links to directories and the file system tree could then be a file system DAG. I don't think Bakul's proposal would have worked --- although I suppose if you disallowed directory renames, I guess it could. Noel's objection above was a performance one, in that if you had to parse the path every single time, you'd be much more dependent on the namei cache --- and that PDP-11 didn't have the memory to support a sufficiently large cache. - Ted From robpike at gmail.com Fri Dec 31 13:23:15 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 31 Dec 2021 14:23:15 +1100 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: In broad strokes, that's exactly what we did in Plan 9, with great results, as was said here a while back. The paper ended with a plea to do the same to Unix, which I think is quite doable. https://9p.io/sys/doc/lexnames.html -rob On Fri, Dec 31, 2021 at 2:09 PM Theodore Ts'o wrote: > On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote: > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: > > > On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote: > > > > > From: Bakul Shah > > > > > > > > > My guess is *not* storing a path instead of a ptr to the inode > was done > > > > > to save on memory. > > > > > > > > More probably speed; those old disks were not fast, and on a PDP-11, > disk > > > > caches were so small that converting the path to the current > directory to its > > > > in memory inode could take a bunch of disk reads. > > > > > > The other problem with storing the path as a string is that if > > > higher-level directories get renamed, the path would become > > > invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone > > > renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would > > > become invalidated. > > > > Why? Presumably as you traversed the filesystem, you'd cache, (path > > component, inode) pairs and keep a ref on the inode. For any given > > file, including $CWD, you'd know it's pathname from the root as you > > accessed it, but if it got renamed, it wouldn't matter because you'd > > have cached a reference to the inode. > > I was responding to Bakul's suggestion that the original Unix > could/should have stored the cwd as a string, instead of a pointer to > a directory inode. If you stored the cwd as a string, then you could > interpret .. by chopping off the last file name component of the > string, and so now you could have hard links to directories and the > file system tree could then be a file system DAG. > > I don't think Bakul's proposal would have worked --- although I > suppose if you disallowed directory renames, I guess it could. Noel's > objection above was a performance one, in that if you had to parse the > path every single time, you'd be much more dependent on the namei > cache --- and that PDP-11 didn't have the memory to support a > sufficiently large cache. > > - Ted > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 31 15:12:26 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 30 Dec 2021 21:12:26 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: <6B72AED1-90F2-4F18-BE6E-BA0CAC4380D0@iitbombay.org> > On Dec 30, 2021, at 7:08 PM, Theodore Ts'o wrote: > > On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote: >> On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o wrote: >>> On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote: >>>>> From: Bakul Shah >>>> >>>>> My guess is *not* storing a path instead of a ptr to the inode was done >>>>> to save on memory. >>>> >>>> More probably speed; those old disks were not fast, and on a PDP-11, disk >>>> caches were so small that converting the path to the current directory to its >>>> in memory inode could take a bunch of disk reads. >>> >>> The other problem with storing the path as a string is that if >>> higher-level directories get renamed, the path would become >>> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone >>> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would >>> become invalidated. >> >> Why? Presumably as you traversed the filesystem, you'd cache, (path >> component, inode) pairs and keep a ref on the inode. For any given >> file, including $CWD, you'd know it's pathname from the root as you >> accessed it, but if it got renamed, it wouldn't matter because you'd >> have cached a reference to the inode. > > I was responding to Bakul's suggestion that the original Unix > could/should have stored the cwd as a string, instead of a pointer to > a directory inode. If you stored the cwd as a string, then you could > interpret .. by chopping off the last file name component of the > string, and so now you could have hard links to directories and the > file system tree could then be a file system DAG. > > I don't think Bakul's proposal would have worked --- although I > suppose if you disallowed directory renames, I guess it could. Note that this is already broken! $ mkdir -p ~/a/b; cd ~/a/b; mv ~/a /tmp # /tmp is on a diff filesystem $ cd .. cd: no such file or directory: .. At least with the change[1] I was talking about, cd .. would not be an error! At least with this change the behavior is more consistent! Now if you want bug for bug compatibility then yes, you can't make any changes but usually it is more a cost/benefit tradeoff as far as any breaking changes are concerned. NFS broke a few things for example and most of us put up with that. [1] cwd as string, not allowing multiple links to a dir. I speculated about the latter but any benefit is not worth the cost. not worth it. From tytso at mit.edu Fri Dec 31 15:16:05 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 31 Dec 2021 00:16:05 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike wrote: > In broad strokes, that's exactly what we did in Plan 9, with great results, > as was said here a while back. The paper ended with a plea to do the same > to Unix, which I think is quite doable. > > https://9p.io/sys/doc/lexnames.html I'm sure it *could* be done. In fact, Linux has a number of the pieces of the implementations already, which could be reused for a Plan-9-style lexical namespace. Linux has bind mounts, and a dentry is essentially a cached directory lookup (it contains a pointer to its parent dentry, the filename used to do the lookup and a pointer to the resulting inode). And a struct file contains a struct dentry, which means in Linux it is possible to determine the path used to open a particular file. There are some differences of course; so it's not exact, but I agree with you that it is quite "doable". (In particular, how Linux dentries and symlinks interact appears to be different from how Plan 9 and Channels did things, if I understand the paper correctly.) The question though, is whether Linux *should* do it. Or rather, *could* we do it without breaking backwards compatibility with users and application which expect that dot-dot works the way it does in classical Unix implementations for the past 4 decades or so. Granted that the combination of symlinks, and hard links, and in Linux, bind mounts (not to mention bind namespaces, chroots, and pivot_root operations), can be confusing. But there is a whole ecosystem of shell scripts, programs, user's finger macros, etc., that would break if we "made things better" or "made things simpler". One of the benefits of research OS's is that you can experiment with things without having to worry about the howls of angry users when you break backwards compatibility, or eliminate some particular awkward API or feature. - Ted P.S. For example, how I wish I could eliminate telldir/seekdir, or at least change things so that telldir/seekdir used a substantially larger "cookie" to memoize a position in a directory's readdir stream which has to be valid effectively forever. Today, you can pass a 32-bit telldir cookie to seekdir, and readdir MUST not return a directory entry that it had already returned, and MUST not skip a directory entry that was present at the time of the telldir(). Thus spake POSIX, and there are applications which depend on telldir/seekdir/readdir having this precise set of semantics If your directory is stored internally as a linear stream, that's not too bad; but if you're using a more complex data structure, life gets interesting. I know of one file system (JFS) which added an extra, separate, on-disk b-tree structure to each directory just to be able to provide stable telldir/seekdir cookies. (And of course, there's a performance impact to needing to update an extra b-tree each time a directory entry is added or removed.) With a research OS, it's at least possible to say, "Well, *that* was a mistake; let's pretend it never happened and let's see how much better life would be." :-) From crossd at gmail.com Fri Dec 31 15:21:45 2021 From: crossd at gmail.com (Dan Cross) Date: Fri, 31 Dec 2021 00:21:45 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: On Fri, Dec 31, 2021, 12:16 AM Theodore Ts'o wrote: > [snip] > One of the benefits of research OS's is that you can experiment with > things without having to worry about the howls of angry users when you > break backwards compatibility, or eliminate some particular awkward > API or feature. > Ah, I see you mercifully avoiding spending a lot of time on the 9fans list ... - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Dec 31 15:55:34 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 31 Dec 2021 16:55:34 +1100 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: Thanks for your thoughtful response (and for reading the paper). This for me is the catch: *But there is a whole ecosystem of shell scripts, programs, user's finger macros, etc., that would break if we "made things better" or made things simpler.* And of course you're right, but we've known how to roll out breaking changes in software for a very long time now. And we do so often. Few Unix programs from the past would compile and run today without being updated to "modern" interfaces and compilers. I believe it could be done, and I believe it should be done. Rolled out carefully and explained well it would please far more than it offends, and is arguably far closer to correct than the current situation. Of course, I am not volunteering, sorry. Easy for me to snipe, I admit, but then I paid my OS dues long ago. -rob On Fri, Dec 31, 2021 at 4:16 PM Theodore Ts'o wrote: > On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike wrote: > > In broad strokes, that's exactly what we did in Plan 9, with great > results, > > as was said here a while back. The paper ended with a plea to do the same > > to Unix, which I think is quite doable. > > > > https://9p.io/sys/doc/lexnames.html > > I'm sure it *could* be done. In fact, Linux has a number of the > pieces of the implementations already, which could be reused for a > Plan-9-style lexical namespace. Linux has bind mounts, and a dentry is > essentially a cached directory lookup (it contains a pointer to its > parent dentry, the filename used to do the lookup and a pointer to the > resulting inode). And a struct file contains a struct dentry, which > means in Linux it is possible to determine the path used to open a > particular file. There are some differences of course; so it's not > exact, but I agree with you that it is quite "doable". (In > particular, how Linux dentries and symlinks interact appears to be > different from how Plan 9 and Channels did things, if I understand the > paper correctly.) > > The question though, is whether Linux *should* do it. Or rather, > *could* we do it without breaking backwards compatibility with users > and application which expect that dot-dot works the way it does in > classical Unix implementations for the past 4 decades or so. > > Granted that the combination of symlinks, and hard links, and in > Linux, bind mounts (not to mention bind namespaces, chroots, and > pivot_root operations), can be confusing. But there is a whole > ecosystem of shell scripts, programs, user's finger macros, etc., that > would break if we "made things better" or "made things simpler". > > One of the benefits of research OS's is that you can experiment with > things without having to worry about the howls of angry users when you > break backwards compatibility, or eliminate some particular awkward > API or feature. > > - Ted > > P.S. For example, how I wish I could eliminate telldir/seekdir, or at > least change things so that telldir/seekdir used a substantially > larger "cookie" to memoize a position in a directory's readdir stream > which has to be valid effectively forever. Today, you can pass a > 32-bit telldir cookie to seekdir, and readdir MUST not return a > directory entry that it had already returned, and MUST not skip a > directory entry that was present at the time of the telldir(). Thus > spake POSIX, and there are applications which depend on > telldir/seekdir/readdir having this precise set of semantics > > If your directory is stored internally as a linear stream, that's not > too bad; but if you're using a more complex data structure, life gets > interesting. I know of one file system (JFS) which added an extra, > separate, on-disk b-tree structure to each directory just to be able > to provide stable telldir/seekdir cookies. (And of course, there's a > performance impact to needing to update an extra b-tree each time a > directory entry is added or removed.) > > With a research OS, it's at least possible to say, "Well, *that* was a > mistake; let's pretend it never happened and let's see how much better > life would be." :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Fri Dec 31 23:32:57 2021 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 31 Dec 2021 13:32:57 +0000 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> Message-ID: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> On 31 Dec 2021 16:55 +1100, from robpike at gmail.com (Rob Pike): > And of course you're right, but we've known how to roll out breaking > changes in software for a very long time now. And we do so often. Few Unix > programs from the past would compile and run today without being updated to > "modern" interfaces and compilers. > > I believe it could be done, and I believe it should be done. Rolled out > carefully and explained well it would please far more than it offends, and > is arguably far closer to correct than the current situation. Seems to me that we have a decent, relatively current case study of this with Python 2 vs Python 3. Which is probably a good bit easier actually, because maintaining the ability to run Python 2 applications while introducing the ability to run Python 3 applications is likely easier than introducing changes to how something as relatively fundamental as how ".." behaves in paths while at the same time maintaining backwards compatibility with the old behavior, where different users and different applications on the same system might very well expect different behavior... -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”