From fjarlq at gmail.com Wed Jul 1 07:27:48 2020 From: fjarlq at gmail.com (Matt Day) Date: Tue, 30 Jun 2020 15:27:48 -0600 Subject: [TUHS] Bill Shannon RIP Message-ID: David Rosenthal has written a wonderful memorial of Bill Shannon: https://blog.dshr.org/2020/06/bill-shannon-rip.html From lm at mcvoy.com Wed Jul 1 13:20:55 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 30 Jun 2020 20:20:55 -0700 Subject: [TUHS] Bill Shannon RIP In-Reply-To: References: Message-ID: <20200701032055.GQ19858@mcvoy.com> That was a great post from David. It rang true on everything where I overlapped. The cars in the ponds were before my time. I had mixed feelings about Bill when I was at Sun, we fought. We both wanted the right thing, we fought like crazy about what was right. There were so many times I wanted to quit and I thought "I can't leave Bill to fight them alone". So yeah, I'm another Bill Shannon fan. And a Karen fan, I liked how she did things. Both really great people. Matt, thanks for this, I had not seen it. On Tue, Jun 30, 2020 at 03:27:48PM -0600, Matt Day wrote: > David Rosenthal has written a wonderful memorial of Bill Shannon: > > https://blog.dshr.org/2020/06/bill-shannon-rip.html -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From athornton at gmail.com Sat Jul 4 06:52:42 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 3 Jul 2020 13:52:42 -0700 Subject: [TUHS] v7 uucp debugging help requested Message-ID: (if this is better suited for COFF, that'd be fine too) I've been trying to set up UUCP on my V7 system and its raspberry Pi host. This plus the "s" editor (already working) are really all that's needed to make this something pretty close to a daily driver, if all I wanted to do was write text files (which in some sense is all my job _is_, but to be fair I get a much more immediate feedback loop in my current environment). I was following https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf more or less--I had already rebuilt v7 with the DZ terminal driver and was using it for interactive sessions (albeit, before I started trying to get UUCP running, with 7-bit line discipline--but I've since changed that). I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, because I can use them for terminal sessions. I've built UUCP, set a node name, and set it up on the pi. I can execute uucico to send files, and it, frustratingly, almost works. >From the Pi side, I see (with uulog): uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol 'g' sending packet/window 64/3 receiving 64/7) uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending /home/adam/git/simh/sim_scsi.h (6780 bytes) uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for packet uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86, resent 6, received 1 uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, order 0, remote rejects 0 uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440 bytes 19 bps) So it's clearly logging in, and if I telnet in directly, the v7 end is starting uucico as expected: login: pi-uucp Password: Shere uulog -x on the v7 side has no output, and nothing ever appears in the spool directory, which I suspect is a direct result of the timeout waiting for packet. So my question is, what else do I do to debug this? Clearly the pi (Taylor UUCP) side is expecting something else--maybe an acknowledgement?--from the v7 side to let it know the transmission was successful. Any help would be appreciated. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 4 07:26:48 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 3 Jul 2020 17:26:48 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: > (if this is better suited for COFF, that'd be fine too) > > I've been trying to set up UUCP on my V7 system and its raspberry Pi > host. This plus the "s" editor (already working) are really all that's > needed to make this something pretty close to a daily driver, if all I > wanted to do was write text files (which in some sense is all my job _is_, > but to be fair I get a much more immediate feedback loop in my current > environment). > > I was following > https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf > more or less--I had already rebuilt v7 with the DZ terminal driver and was > using it for interactive sessions (albeit, before I started trying to get > UUCP running, with 7-bit line discipline--but I've since changed that). > > I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, > because I can use them for terminal sessions. > As a long time UUCP person on PDP-11's, "Danger Will Robinson." Just for grins and giggles on the V7/PDP-11 side, try it over a DH (VH driver in simh) emulation (or even a KL/DL - although the simulated interrupts will be a mother). That said, the VH driver is a not exactly a DH as I understand it, its the later QBUS version which was similar but different. It's been on my list of things I want to chase down at some point to make work to get it closer to the original. FYI: Running UUCP over real DZ's was always troublesome. There were a ton of updates/patches done post the original V7 release in the DZ drivers to make them play better. Most of us that ran large UUCP set up in the old days, installed ABLE DMAX (DH/DM) that were a single board DH replacement - they are DMA, and buffered (and supported proper modem control which the DZ's don't - although later UCB work on the driver sort of faked it enough to make to it work for basic dial-up use reasonably reliably). -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Jul 4 08:38:31 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 3 Jul 2020 16:38:31 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> On 7/3/20 2:52 PM, Adam Thornton wrote: > I've built UUCP, set a node name, and set it up on the pi. > > I can execute uucico to send files, and it, frustratingly, almost works. Which system are you referring to here? The Pi or V7? > From the Pi side, I see (with uulog): > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > (protocol 'g' sending packet/window 64/3 receiving 64/7) > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > /home/adam/git/simh/sim_scsi.h (6780 bytes) > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > for packet > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > 86, resent 6, received 1 I'm a little surprised that you're trying to use the 'g' protocol to talk to v7. I thought the 'g' protocol came out later for TCP over Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' protocol. I think that Clem knows a LOT more about this than I do. I'm ignorantly asking questions. > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > order 0, remote rejects 0 > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > 5440 bytes 19 bps) > > So it's clearly logging in, and if I telnet in directly, the v7 end is > starting uucico as expected: > > login: pi-uucp > Password: > Shere Shouldn't that be something more like the following? Shere=v7 What does 'uuname -l' (or '--local') show? (I'm much more familiar with Taylor UUCP than I am the UUCP in v7. > uulog -x on the v7 side has no output, and nothing ever appears in the > spool directory, which I suspect is a direct result of the timeout > waiting for packet. > > So my question is, what else do I do to debug this?  Clearly the pi > (Taylor UUCP) side is expecting something else--maybe an > acknowledgement?--from the v7 side to let it know the transmission was > successful. > > Any help would be appreciated. I've not messed with this particular problem in probably 2 years and I've forgotten more than comments above. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From cowan at ccil.org Sat Jul 4 08:50:24 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 3 Jul 2020 18:50:24 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: > I've been trying to set up UUCP on my V7 system and its raspberry Pi > host. This plus the "s" editor (already working) > What is this "s" editor? The v7 man pages say nothing about it, and of course Dr. Google is equally unhelpful. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org We call nothing profound that is not wittily expressed. --Northrop Frye (improved) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 4 10:28:49 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 3 Jul 2020 20:28:49 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: Grant - The g (greg’s protocol) is correct. IIRC that’s the only line protocol Dan distributed in the V7 original code base. On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS wrote: > On 7/3/20 2:52 PM, Adam Thornton wrote: > > I've built UUCP, set a node name, and set it up on the pi. > > > > I can execute uucico to send files, and it, frustratingly, almost works. > > Which system are you referring to here? The Pi or V7? > > > From the Pi side, I see (with uulog): > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > for packet > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > 86, resent 6, received 1 > > I'm a little surprised that you're trying to use the 'g' protocol to > talk to v7. I thought the 'g' protocol came out later for TCP over > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > protocol. > > I think that Clem knows a LOT more about this than I do. > > I'm ignorantly asking questions. > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > > order 0, remote rejects 0 > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > 5440 bytes 19 bps) > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > starting uucico as expected: > > > > login: pi-uucp > > Password: > > Shere > > Shouldn't that be something more like the following? > > Shere=v7 > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > Taylor UUCP than I am the UUCP in v7. > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > spool directory, which I suspect is a direct result of the timeout > > waiting for packet. > > > > So my question is, what else do I do to debug this? Clearly the pi > > (Taylor UUCP) side is expecting something else--maybe an > > acknowledgement?--from the v7 side to let it know the transmission was > > successful. > > > > Any help would be appreciated. > > I've not messed with this particular problem in probably 2 years and > I've forgotten more than comments above. > > > > -- > Grant. . . . > unix || die > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 4 10:31:05 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 3 Jul 2020 20:31:05 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: Grant. I wrote e for Ethernet based ( ip/ tcp ) connections at Masscomp so we didn’t have hack the mailer at time. On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS wrote: > On 7/3/20 2:52 PM, Adam Thornton wrote: > > I've built UUCP, set a node name, and set it up on the pi. > > > > I can execute uucico to send files, and it, frustratingly, almost works. > > Which system are you referring to here? The Pi or V7? > > > From the Pi side, I see (with uulog): > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > for packet > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > 86, resent 6, received 1 > > I'm a little surprised that you're trying to use the 'g' protocol to > talk to v7. I thought the 'g' protocol came out later for TCP over > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > protocol. > > I think that Clem knows a LOT more about this than I do. > > I'm ignorantly asking questions. > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > > order 0, remote rejects 0 > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > 5440 bytes 19 bps) > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > starting uucico as expected: > > > > login: pi-uucp > > Password: > > Shere > > Shouldn't that be something more like the following? > > Shere=v7 > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > Taylor UUCP than I am the UUCP in v7. > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > spool directory, which I suspect is a direct result of the timeout > > waiting for packet. > > > > So my question is, what else do I do to debug this? Clearly the pi > > (Taylor UUCP) side is expecting something else--maybe an > > acknowledgement?--from the v7 side to let it know the transmission was > > successful. > > > > Any help would be appreciated. > > I've not messed with this particular problem in probably 2 years and > I've forgotten more than comments above. > > > > -- > Grant. . . . > unix || die > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Sat Jul 4 10:35:52 2020 From: norman at oclsc.org (Norman Wilson) Date: Fri, 3 Jul 2020 20:35:52 -0400 (EDT) Subject: [TUHS] v7 uucp debugging help requested Message-ID: <20200704003552.EB5914422E@lignose.oclsc.org> Grant Taylor: I'm a little surprised that you're trying to use the 'g' protocol to talk to v7. I thought the 'g' protocol came out later for TCP over Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' protocol. ===== You're mis-remembering. g was the original protocol, intended for use over possibly-noisy serial lines (e.g. modems on POTS). It does error checking of various sorts with retransmission. I believe it is named g after the protocol's original designer, Greg Chesson. Later protocols meant to work over reliable, error- checked links like a TCP/IP circuit were t and e. Norman Wilson Toronto ON From paul.allan.palmer at gmail.com Sat Jul 4 16:10:01 2020 From: paul.allan.palmer at gmail.com (Paul Palmer) Date: Sat, 4 Jul 2020 01:10:01 -0500 Subject: [TUHS] s editor Message-ID: Could someone point me to some information about s editor? Googling didn't help On Fri, Jul 3, 2020, 9:00 PM Send TUHS mailing list submissions to > tuhs at minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request at minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner at minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. v7 uucp debugging help requested (Adam Thornton) > 2. Re: v7 uucp debugging help requested (Clem Cole) > 3. Re: v7 uucp debugging help requested (Grant Taylor) > 4. Re: v7 uucp debugging help requested (John Cowan) > 5. Re: v7 uucp debugging help requested (Clem Cole) > 6. Re: v7 uucp debugging help requested (Clem Cole) > 7. Re: v7 uucp debugging help requested (Norman Wilson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 3 Jul 2020 13:52:42 -0700 > From: Adam Thornton > To: The Eunuchs Hysterical Society > Subject: [TUHS] v7 uucp debugging help requested > Message-ID: > g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > (if this is better suited for COFF, that'd be fine too) > > I've been trying to set up UUCP on my V7 system and its raspberry Pi host. > This plus the "s" editor (already working) are really all that's needed to > make this something pretty close to a daily driver, if all I wanted to do > was write text files (which in some sense is all my job _is_, but to be > fair I get a much more immediate feedback loop in my current environment). > > I was following > > https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf > more or less--I had already rebuilt v7 with the DZ terminal driver and was > using it for interactive sessions (albeit, before I started trying to get > UUCP running, with 7-bit line discipline--but I've since changed that). > > I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, > because I can use them for terminal sessions. > > I've built UUCP, set a node name, and set it up on the pi. > > I can execute uucico to send files, and it, frustratingly, almost works. > > >From the Pi side, I see (with uulog): > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol > 'g' sending packet/window 64/3 receiving 64/7) > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > /home/adam/git/simh/sim_scsi.h (6780 bytes) > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for > packet > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86, > resent 6, received 1 > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > order 0, remote rejects 0 > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440 > bytes 19 bps) > > So it's clearly logging in, and if I telnet in directly, the v7 end is > starting uucico as expected: > > login: pi-uucp > Password: > Shere > > uulog -x on the v7 side has no output, and nothing ever appears in the > spool directory, which I suspect is a direct result of the timeout waiting > for packet. > > So my question is, what else do I do to debug this? Clearly the pi (Taylor > UUCP) side is expecting something else--maybe an acknowledgement?--from the > v7 side to let it know the transmission was successful. > > Any help would be appreciated. > > Adam > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/fbc5f57a/attachment-0001.htm > > > > ------------------------------ > > Message: 2 > Date: Fri, 3 Jul 2020 17:26:48 -0400 > From: Clem Cole > To: Adam Thornton > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: > < > CAC20D2Mxug+DdwUcS-FDvWzt4ysmZkZDtVgQ8_HYAz2kpPVS8g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: > > > (if this is better suited for COFF, that'd be fine too) > > > > I've been trying to set up UUCP on my V7 system and its raspberry Pi > > host. This plus the "s" editor (already working) are really all that's > > needed to make this something pretty close to a daily driver, if all I > > wanted to do was write text files (which in some sense is all my job > _is_, > > but to be fair I get a much more immediate feedback loop in my current > > environment). > > > > I was following > > > https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf > > more or less--I had already rebuilt v7 with the DZ terminal driver and > was > > using it for interactive sessions (albeit, before I started trying to get > > UUCP running, with 7-bit line discipline--but I've since changed that). > > > > I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, > > because I can use them for terminal sessions. > > > As a long time UUCP person on PDP-11's, "Danger Will Robinson." > > Just for grins and giggles on the V7/PDP-11 side, try it over a DH (VH > driver in simh) emulation (or even a KL/DL - although the > simulated interrupts will be a mother). That said, the VH driver is a not > exactly a DH as I understand it, its the later QBUS version which was > similar but different. It's been on my list of things I want to chase > down at some point to make work to get it closer to the original. > > FYI: Running UUCP over real DZ's was always troublesome. There were a ton > of updates/patches done post the original V7 release in the DZ drivers to > make them play better. Most of us that ran large UUCP set up in the old > days, installed ABLE DMAX (DH/DM) that were a single board DH replacement - > they are DMA, and buffered (and supported proper modem control which the > DZ's don't - although later UCB work on the driver sort of faked it enough > to make to it work for basic dial-up use reasonably reliably). > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/093ff539/attachment-0001.htm > > > > ------------------------------ > > Message: 3 > Date: Fri, 3 Jul 2020 16:38:31 -0600 > From: Grant Taylor > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: <01f8f896-9921-6c55-8dc2-6b9859f2f230 at tnetconsulting.net> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 7/3/20 2:52 PM, Adam Thornton wrote: > > I've built UUCP, set a node name, and set it up on the pi. > > > > I can execute uucico to send files, and it, frustratingly, almost works. > > Which system are you referring to here? The Pi or V7? > > > From the Pi side, I see (with uulog): > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > for packet > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > 86, resent 6, received 1 > > I'm a little surprised that you're trying to use the 'g' protocol to > talk to v7. I thought the 'g' protocol came out later for TCP over > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > protocol. > > I think that Clem knows a LOT more about this than I do. > > I'm ignorantly asking questions. > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > > order 0, remote rejects 0 > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > 5440 bytes 19 bps) > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > starting uucico as expected: > > > > login: pi-uucp > > Password: > > Shere > > Shouldn't that be something more like the following? > > Shere=v7 > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > Taylor UUCP than I am the UUCP in v7. > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > spool directory, which I suspect is a direct result of the timeout > > waiting for packet. > > > > So my question is, what else do I do to debug this? Clearly the pi > > (Taylor UUCP) side is expecting something else--maybe an > > acknowledgement?--from the v7 side to let it know the transmission was > > successful. > > > > Any help would be appreciated. > > I've not messed with this particular problem in probably 2 years and > I've forgotten more than comments above. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4013 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/b827f997/attachment-0001.bin > > > > ------------------------------ > > Message: 4 > Date: Fri, 3 Jul 2020 18:50:24 -0400 > From: John Cowan > To: Adam Thornton > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: > DzyQnUZg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: > > > > I've been trying to set up UUCP on my V7 system and its raspberry Pi > > host. This plus the "s" editor (already working) > > > > What is this "s" editor? The v7 man pages say nothing about it, and of > course Dr. Google is equally unhelpful. > > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > We call nothing profound that is not wittily expressed. > --Northrop Frye (improved) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/83879cf0/attachment-0001.htm > > > > ------------------------------ > > Message: 5 > Date: Fri, 3 Jul 2020 20:28:49 -0400 > From: Clem Cole > To: Grant Taylor > Cc: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: > ze2pdY5wRJnYbiYFxb-GcXK1P7SbZJFoPg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Grant - The g (greg’s protocol) is correct. IIRC that’s the only line > protocol Dan distributed in the V7 original code base. > > On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS > > wrote: > > > On 7/3/20 2:52 PM, Adam Thornton wrote: > > > I've built UUCP, set a node name, and set it up on the pi. > > > > > > I can execute uucico to send files, and it, frustratingly, almost > works. > > > > Which system are you referring to here? The Pi or V7? > > > > > From the Pi side, I see (with uulog): > > > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > > for packet > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > > 86, resent 6, received 1 > > > > I'm a little surprised that you're trying to use the 'g' protocol to > > talk to v7. I thought the 'g' protocol came out later for TCP over > > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > > protocol. > > > > I think that Clem knows a LOT more about this than I do. > > > > I'm ignorantly asking questions. > > > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum > 0, > > > order 0, remote rejects 0 > > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > > 5440 bytes 19 bps) > > > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > > starting uucico as expected: > > > > > > login: pi-uucp > > > Password: > > > Shere > > > > Shouldn't that be something more like the following? > > > > Shere=v7 > > > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > > Taylor UUCP than I am the UUCP in v7. > > > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > > spool directory, which I suspect is a direct result of the timeout > > > waiting for packet. > > > > > > So my question is, what else do I do to debug this? Clearly the pi > > > (Taylor UUCP) side is expecting something else--maybe an > > > acknowledgement?--from the v7 side to let it know the transmission was > > > successful. > > > > > > Any help would be appreciated. > > > > I've not messed with this particular problem in probably 2 years and > > I've forgotten more than comments above. > > > > > > > > -- > > Grant. . . . > > unix || die > > > > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/3340357a/attachment-0001.htm > > > > ------------------------------ > > Message: 6 > Date: Fri, 3 Jul 2020 20:31:05 -0400 > From: Clem Cole > To: Grant Taylor > Cc: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: > < > CAC20D2Mt4t+Y4hqeDusB1rxw_CdzJsFySJnEcr2g1T6vUgDHbw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Grant. I wrote e for Ethernet based ( ip/ tcp ) connections at Masscomp so > we didn’t have hack the mailer at time. > > On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS > > wrote: > > > On 7/3/20 2:52 PM, Adam Thornton wrote: > > > I've built UUCP, set a node name, and set it up on the pi. > > > > > > I can execute uucico to send files, and it, frustratingly, almost > works. > > > > Which system are you referring to here? The Pi or V7? > > > > > From the Pi side, I see (with uulog): > > > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > > for packet > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > > 86, resent 6, received 1 > > > > I'm a little surprised that you're trying to use the 'g' protocol to > > talk to v7. I thought the 'g' protocol came out later for TCP over > > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > > protocol. > > > > I think that Clem knows a LOT more about this than I do. > > > > I'm ignorantly asking questions. > > > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum > 0, > > > order 0, remote rejects 0 > > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > > 5440 bytes 19 bps) > > > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > > starting uucico as expected: > > > > > > login: pi-uucp > > > Password: > > > Shere > > > > Shouldn't that be something more like the following? > > > > Shere=v7 > > > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > > Taylor UUCP than I am the UUCP in v7. > > > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > > spool directory, which I suspect is a direct result of the timeout > > > waiting for packet. > > > > > > So my question is, what else do I do to debug this? Clearly the pi > > > (Taylor UUCP) side is expecting something else--maybe an > > > acknowledgement?--from the v7 side to let it know the transmission was > > > successful. > > > > > > Any help would be appreciated. > > > > I've not messed with this particular problem in probably 2 years and > > I've forgotten more than comments above. > > > > > > > > -- > > Grant. . . . > > unix || die > > > > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/eeebfeff/attachment-0001.htm > > > > ------------------------------ > > Message: 7 > Date: Fri, 3 Jul 2020 20:35:52 -0400 (EDT) > From: norman at oclsc.org (Norman Wilson) > To: tuhs at tuhs.org > Subject: Re: [TUHS] v7 uucp debugging help requested > Message-ID: <20200704003552.EB5914422E at lignose.oclsc.org> > > Grant Taylor: > > I'm a little surprised that you're trying to use the 'g' protocol to > talk to v7. I thought the 'g' protocol came out later for TCP over > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > protocol. > > ===== > > You're mis-remembering. g was the original protocol, > intended for use over possibly-noisy serial lines (e.g. > modems on POTS). It does error checking of various > sorts with retransmission. I believe it is named g > after the protocol's original designer, Greg Chesson. > > Later protocols meant to work over reliable, error- > checked links like a TCP/IP circuit were t and e. > > Norman Wilson > Toronto ON > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > > ------------------------------ > > End of TUHS Digest, Vol 56, Issue 3 > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.allan.palmer at gmail.com Sat Jul 4 16:16:38 2020 From: paul.allan.palmer at gmail.com (Paul Palmer) Date: Sat, 4 Jul 2020 01:16:38 -0500 Subject: [TUHS] s editor In-Reply-To: References: Message-ID: Never mind. I see John Cowan has already asked. I'll crawl back in my hole now On Sat, Jul 4, 2020, 1:10 AM Paul Palmer Could someone point me to some information about s editor? > > Googling didn't help > > On Fri, Jul 3, 2020, 9:00 PM >> Send TUHS mailing list submissions to >> tuhs at minnie.tuhs.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs >> or, via email, send a message with subject or body 'help' to >> tuhs-request at minnie.tuhs.org >> >> You can reach the person managing the list at >> tuhs-owner at minnie.tuhs.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TUHS digest..." >> >> >> Today's Topics: >> >> 1. v7 uucp debugging help requested (Adam Thornton) >> 2. Re: v7 uucp debugging help requested (Clem Cole) >> 3. Re: v7 uucp debugging help requested (Grant Taylor) >> 4. Re: v7 uucp debugging help requested (John Cowan) >> 5. Re: v7 uucp debugging help requested (Clem Cole) >> 6. Re: v7 uucp debugging help requested (Clem Cole) >> 7. Re: v7 uucp debugging help requested (Norman Wilson) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 3 Jul 2020 13:52:42 -0700 >> From: Adam Thornton >> To: The Eunuchs Hysterical Society >> Subject: [TUHS] v7 uucp debugging help requested >> Message-ID: >> > g at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> (if this is better suited for COFF, that'd be fine too) >> >> I've been trying to set up UUCP on my V7 system and its raspberry Pi host. >> This plus the "s" editor (already working) are really all that's needed to >> make this something pretty close to a daily driver, if all I wanted to do >> was write text files (which in some sense is all my job _is_, but to be >> fair I get a much more immediate feedback loop in my current environment). >> >> I was following >> >> https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf >> more or less--I had already rebuilt v7 with the DZ terminal driver and was >> using it for interactive sessions (albeit, before I started trying to get >> UUCP running, with 7-bit line discipline--but I've since changed that). >> >> I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, >> because I can use them for terminal sessions. >> >> I've built UUCP, set a node name, and set it up on the pi. >> >> I can execute uucico to send files, and it, frustratingly, almost works. >> >> >From the Pi side, I see (with uulog): >> >> uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) >> uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful >> uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol >> 'g' sending packet/window 64/3 receiving 64/7) >> uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending >> /home/adam/git/simh/sim_scsi.h (6780 bytes) >> uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for >> packet >> uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86, >> resent 6, received 1 >> uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, >> order 0, remote rejects 0 >> uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440 >> bytes 19 bps) >> >> So it's clearly logging in, and if I telnet in directly, the v7 end is >> starting uucico as expected: >> >> login: pi-uucp >> Password: >> Shere >> >> uulog -x on the v7 side has no output, and nothing ever appears in the >> spool directory, which I suspect is a direct result of the timeout waiting >> for packet. >> >> So my question is, what else do I do to debug this? Clearly the pi >> (Taylor >> UUCP) side is expecting something else--maybe an acknowledgement?--from >> the >> v7 side to let it know the transmission was successful. >> >> Any help would be appreciated. >> >> Adam >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/fbc5f57a/attachment-0001.htm >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 3 Jul 2020 17:26:48 -0400 >> From: Clem Cole >> To: Adam Thornton >> Cc: The Eunuchs Hysterical Society >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: >> < >> CAC20D2Mxug+DdwUcS-FDvWzt4ysmZkZDtVgQ8_HYAz2kpPVS8g at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: >> >> > (if this is better suited for COFF, that'd be fine too) >> > >> > I've been trying to set up UUCP on my V7 system and its raspberry Pi >> > host. This plus the "s" editor (already working) are really all that's >> > needed to make this something pretty close to a daily driver, if all I >> > wanted to do was write text files (which in some sense is all my job >> _is_, >> > but to be fair I get a much more immediate feedback loop in my current >> > environment). >> > >> > I was following >> > >> https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf >> > more or less--I had already rebuilt v7 with the DZ terminal driver and >> was >> > using it for interactive sessions (albeit, before I started trying to >> get >> > UUCP running, with 7-bit line discipline--but I've since changed that). >> > >> > I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, >> > because I can use them for terminal sessions. >> > >> As a long time UUCP person on PDP-11's, "Danger Will Robinson." >> >> Just for grins and giggles on the V7/PDP-11 side, try it over a DH (VH >> driver in simh) emulation (or even a KL/DL - although the >> simulated interrupts will be a mother). That said, the VH driver is a not >> exactly a DH as I understand it, its the later QBUS version which was >> similar but different. It's been on my list of things I want to chase >> down at some point to make work to get it closer to the original. >> >> FYI: Running UUCP over real DZ's was always troublesome. There were a ton >> of updates/patches done post the original V7 release in the DZ drivers to >> make them play better. Most of us that ran large UUCP set up in the old >> days, installed ABLE DMAX (DH/DM) that were a single board DH replacement >> - >> they are DMA, and buffered (and supported proper modem control which the >> DZ's don't - although later UCB work on the driver sort of faked it enough >> to make to it work for basic dial-up use reasonably reliably). >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/093ff539/attachment-0001.htm >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 3 Jul 2020 16:38:31 -0600 >> From: Grant Taylor >> To: tuhs at minnie.tuhs.org >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: <01f8f896-9921-6c55-8dc2-6b9859f2f230 at tnetconsulting.net> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> On 7/3/20 2:52 PM, Adam Thornton wrote: >> > I've built UUCP, set a node name, and set it up on the pi. >> > >> > I can execute uucico to send files, and it, frustratingly, almost works. >> >> Which system are you referring to here? The Pi or V7? >> >> > From the Pi side, I see (with uulog): >> > >> > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) >> > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful >> > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful >> > (protocol 'g' sending packet/window 64/3 receiving 64/7) >> > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending >> > /home/adam/git/simh/sim_scsi.h (6780 bytes) >> > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting >> > for packet >> > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent >> > 86, resent 6, received 1 >> >> I'm a little surprised that you're trying to use the 'g' protocol to >> talk to v7. I thought the 'g' protocol came out later for TCP over >> Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' >> protocol. >> >> I think that Clem knows a LOT more about this than I do. >> >> I'm ignorantly asking questions. >> >> > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum >> 0, >> > order 0, remote rejects 0 >> > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds >> > 5440 bytes 19 bps) >> > >> > So it's clearly logging in, and if I telnet in directly, the v7 end is >> > starting uucico as expected: >> > >> > login: pi-uucp >> > Password: >> > Shere >> >> Shouldn't that be something more like the following? >> >> Shere=v7 >> >> What does 'uuname -l' (or '--local') show? (I'm much more familiar with >> Taylor UUCP than I am the UUCP in v7. >> >> > uulog -x on the v7 side has no output, and nothing ever appears in the >> > spool directory, which I suspect is a direct result of the timeout >> > waiting for packet. >> > >> > So my question is, what else do I do to debug this? Clearly the pi >> > (Taylor UUCP) side is expecting something else--maybe an >> > acknowledgement?--from the v7 side to let it know the transmission was >> > successful. >> > >> > Any help would be appreciated. >> >> I've not messed with this particular problem in probably 2 years and >> I've forgotten more than comments above. >> >> >> >> -- >> Grant. . . . >> unix || die >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: smime.p7s >> Type: application/pkcs7-signature >> Size: 4013 bytes >> Desc: S/MIME Cryptographic Signature >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/b827f997/attachment-0001.bin >> > >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 3 Jul 2020 18:50:24 -0400 >> From: John Cowan >> To: Adam Thornton >> Cc: The Eunuchs Hysterical Society >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: >> > DzyQnUZg at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: >> >> >> > I've been trying to set up UUCP on my V7 system and its raspberry Pi >> > host. This plus the "s" editor (already working) >> > >> >> What is this "s" editor? The v7 man pages say nothing about it, and of >> course Dr. Google is equally unhelpful. >> >> >> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org >> We call nothing profound that is not wittily expressed. >> --Northrop Frye (improved) >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/83879cf0/attachment-0001.htm >> > >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 3 Jul 2020 20:28:49 -0400 >> From: Clem Cole >> To: Grant Taylor >> Cc: tuhs at minnie.tuhs.org >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: >> > ze2pdY5wRJnYbiYFxb-GcXK1P7SbZJFoPg at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Grant - The g (greg’s protocol) is correct. IIRC that’s the only line >> protocol Dan distributed in the V7 original code base. >> >> On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS < >> tuhs at minnie.tuhs.org> >> wrote: >> >> > On 7/3/20 2:52 PM, Adam Thornton wrote: >> > > I've built UUCP, set a node name, and set it up on the pi. >> > > >> > > I can execute uucico to send files, and it, frustratingly, almost >> works. >> > >> > Which system are you referring to here? The Pi or V7? >> > >> > > From the Pi side, I see (with uulog): >> > > >> > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port >> TCP) >> > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful >> > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful >> > > (protocol 'g' sending packet/window 64/3 receiving 64/7) >> > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending >> > > /home/adam/git/simh/sim_scsi.h (6780 bytes) >> > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting >> > > for packet >> > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent >> > > 86, resent 6, received 1 >> > >> > I'm a little surprised that you're trying to use the 'g' protocol to >> > talk to v7. I thought the 'g' protocol came out later for TCP over >> > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' >> > protocol. >> > >> > I think that Clem knows a LOT more about this than I do. >> > >> > I'm ignorantly asking questions. >> > >> > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum >> 0, >> > > order 0, remote rejects 0 >> > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds >> > > 5440 bytes 19 bps) >> > > >> > > So it's clearly logging in, and if I telnet in directly, the v7 end is >> > > starting uucico as expected: >> > > >> > > login: pi-uucp >> > > Password: >> > > Shere >> > >> > Shouldn't that be something more like the following? >> > >> > Shere=v7 >> > >> > What does 'uuname -l' (or '--local') show? (I'm much more familiar with >> > Taylor UUCP than I am the UUCP in v7. >> > >> > > uulog -x on the v7 side has no output, and nothing ever appears in the >> > > spool directory, which I suspect is a direct result of the timeout >> > > waiting for packet. >> > > >> > > So my question is, what else do I do to debug this? Clearly the pi >> > > (Taylor UUCP) side is expecting something else--maybe an >> > > acknowledgement?--from the v7 side to let it know the transmission was >> > > successful. >> > > >> > > Any help would be appreciated. >> > >> > I've not messed with this particular problem in probably 2 years and >> > I've forgotten more than comments above. >> > >> > >> > >> > -- >> > Grant. . . . >> > unix || die >> > >> > -- >> Sent from a handheld expect more typos than usual >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/3340357a/attachment-0001.htm >> > >> >> ------------------------------ >> >> Message: 6 >> Date: Fri, 3 Jul 2020 20:31:05 -0400 >> From: Clem Cole >> To: Grant Taylor >> Cc: tuhs at minnie.tuhs.org >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: >> < >> CAC20D2Mt4t+Y4hqeDusB1rxw_CdzJsFySJnEcr2g1T6vUgDHbw at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Grant. I wrote e for Ethernet based ( ip/ tcp ) connections at Masscomp so >> we didn’t have hack the mailer at time. >> >> On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS < >> tuhs at minnie.tuhs.org> >> wrote: >> >> > On 7/3/20 2:52 PM, Adam Thornton wrote: >> > > I've built UUCP, set a node name, and set it up on the pi. >> > > >> > > I can execute uucico to send files, and it, frustratingly, almost >> works. >> > >> > Which system are you referring to here? The Pi or V7? >> > >> > > From the Pi side, I see (with uulog): >> > > >> > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port >> TCP) >> > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful >> > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful >> > > (protocol 'g' sending packet/window 64/3 receiving 64/7) >> > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending >> > > /home/adam/git/simh/sim_scsi.h (6780 bytes) >> > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting >> > > for packet >> > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent >> > > 86, resent 6, received 1 >> > >> > I'm a little surprised that you're trying to use the 'g' protocol to >> > talk to v7. I thought the 'g' protocol came out later for TCP over >> > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' >> > protocol. >> > >> > I think that Clem knows a LOT more about this than I do. >> > >> > I'm ignorantly asking questions. >> > >> > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum >> 0, >> > > order 0, remote rejects 0 >> > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds >> > > 5440 bytes 19 bps) >> > > >> > > So it's clearly logging in, and if I telnet in directly, the v7 end is >> > > starting uucico as expected: >> > > >> > > login: pi-uucp >> > > Password: >> > > Shere >> > >> > Shouldn't that be something more like the following? >> > >> > Shere=v7 >> > >> > What does 'uuname -l' (or '--local') show? (I'm much more familiar with >> > Taylor UUCP than I am the UUCP in v7. >> > >> > > uulog -x on the v7 side has no output, and nothing ever appears in the >> > > spool directory, which I suspect is a direct result of the timeout >> > > waiting for packet. >> > > >> > > So my question is, what else do I do to debug this? Clearly the pi >> > > (Taylor UUCP) side is expecting something else--maybe an >> > > acknowledgement?--from the v7 side to let it know the transmission was >> > > successful. >> > > >> > > Any help would be appreciated. >> > >> > I've not messed with this particular problem in probably 2 years and >> > I've forgotten more than comments above. >> > >> > >> > >> > -- >> > Grant. . . . >> > unix || die >> > >> > -- >> Sent from a handheld expect more typos than usual >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://minnie.tuhs.org/pipermail/tuhs/attachments/20200703/eeebfeff/attachment-0001.htm >> > >> >> ------------------------------ >> >> Message: 7 >> Date: Fri, 3 Jul 2020 20:35:52 -0400 (EDT) >> From: norman at oclsc.org (Norman Wilson) >> To: tuhs at tuhs.org >> Subject: Re: [TUHS] v7 uucp debugging help requested >> Message-ID: <20200704003552.EB5914422E at lignose.oclsc.org> >> >> Grant Taylor: >> >> I'm a little surprised that you're trying to use the 'g' protocol to >> talk to v7. I thought the 'g' protocol came out later for TCP over >> Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' >> protocol. >> >> ===== >> >> You're mis-remembering. g was the original protocol, >> intended for use over possibly-noisy serial lines (e.g. >> modems on POTS). It does error checking of various >> sorts with retransmission. I believe it is named g >> after the protocol's original designer, Greg Chesson. >> >> Later protocols meant to work over reliable, error- >> checked links like a TCP/IP circuit were t and e. >> >> Norman Wilson >> Toronto ON >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs >> >> >> ------------------------------ >> >> End of TUHS Digest, Vol 56, Issue 3 >> *********************************** >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sun Jul 5 02:33:38 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jul 2020 09:33:38 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: The "s" editor is written by Webb Miller and appears in his book "A Software Tools Sampler." There was a discussion about it...here, or COFF, or cctalk, or the PiDP-11 mailing list....a few months ago. Someone had already done the lifting to make it classic v7-compatible, but I don't remember who. Its interface is very close to vi, but it is quite compact and works well on v7. I have a fork of it that has the needed tweaks for PDP-11 v7 up at https://github.com/athornton/s . Since I find ed thoroughly unpleasant to use, having a screen editor was a must for me to use v7 for any length of time, and s fills that role rather nicely. Adam On Fri, Jul 3, 2020 at 3:50 PM John Cowan wrote: > > On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton wrote: > > >> I've been trying to set up UUCP on my V7 system and its raspberry Pi >> host. This plus the "s" editor (already working) >> > > What is this "s" editor? The v7 man pages say nothing about it, and of > course Dr. Google is equally unhelpful. > > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > We call nothing profound that is not wittily expressed. > --Northrop Frye (improved) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Jul 5 04:34:07 2020 From: cowan at ccil.org (John Cowan) Date: Sat, 4 Jul 2020 14:34:07 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Sat, Jul 4, 2020 at 12:33 PM Adam Thornton wrote: The "s" editor is written by Webb Miller and appears in his book "A > Software Tools Sampler." > Wow, I never knew about this book, though I know ST and STP well, and used ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s. Is the rest of the source code for the book available online anywhere? Jez Higgins is rewriting the STP tools into modern C++. His blog posts are at and the code is at . He's rewritten the tools in chapters 1 and 2 and part of 3. Since I find ed thoroughly unpleasant to use, having a screen editor was a > must for me to use v7 for any length of time, and s fills that role rather > nicely. > Gotcha. I actually like line editors (you can't mung your file so thoroughly with a single stray keystroke), but I'm willing to trade a little standardosity for additional convenience, so I do almost all my editing of prose and programs in `ex`, occasionally dropping into vi-mode for matching open and close markers in Lisp and XML. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org If you have ever wondered if you are in hell, it has been said, then you are on a well-traveled road of spiritual inquiry. If you are absolutely sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, New York Times, 2002-09-20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Sun Jul 5 04:44:22 2020 From: nobozo at gmail.com (Jon Forrest) Date: Sat, 4 Jul 2020 11:44:22 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: <0328b6ce-e748-468a-8e9f-d3c321962413@gmail.com> On 7/4/2020 11:34 AM, John Cowan wrote: > The "s" editor is written by Webb Miller and appears in his book "A > Software Tools Sampler." > > > Wow, I never knew about this book, though I know ST and STP well, and > used ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s. As I mentioned last time this topic came up, I have a copy of this book for sale. Please contact me offlist if you're interested. Jon From athornton at gmail.com Sun Jul 5 05:33:03 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jul 2020 12:33:03 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and uuclean. The makefile also includes uurecover but it's not part of the default targets. uucp, uulog, and uux go in /bin, the others in /usr/lib/uucp. It does look like there are debug statements in cico.c; I'll try connecting from the pi side manually and invoking uucico -x 7 and seeing what happens. Adam On Fri, Jul 3, 2020 at 3:46 PM Grant Taylor via TUHS wrote: > On 7/3/20 2:52 PM, Adam Thornton wrote: > > I've built UUCP, set a node name, and set it up on the pi. > > > > I can execute uucico to send files, and it, frustratingly, almost works. > > Which system are you referring to here? The Pi or V7? > > > From the Pi side, I see (with uulog): > > > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful > > (protocol 'g' sending packet/window 64/3 receiving 64/7) > > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > > /home/adam/git/simh/sim_scsi.h (6780 bytes) > > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting > > for packet > > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent > > 86, resent 6, received 1 > > I'm a little surprised that you're trying to use the 'g' protocol to > talk to v7. I thought the 'g' protocol came out later for TCP over > Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' > protocol. > > I think that Clem knows a LOT more about this than I do. > > I'm ignorantly asking questions. > > > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > > order 0, remote rejects 0 > > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds > > 5440 bytes 19 bps) > > > > So it's clearly logging in, and if I telnet in directly, the v7 end is > > starting uucico as expected: > > > > login: pi-uucp > > Password: > > Shere > > Shouldn't that be something more like the following? > > Shere=v7 > > What does 'uuname -l' (or '--local') show? (I'm much more familiar with > Taylor UUCP than I am the UUCP in v7. > > > uulog -x on the v7 side has no output, and nothing ever appears in the > > spool directory, which I suspect is a direct result of the timeout > > waiting for packet. > > > > So my question is, what else do I do to debug this? Clearly the pi > > (Taylor UUCP) side is expecting something else--maybe an > > acknowledgement?--from the v7 side to let it know the transmission was > > successful. > > > > Any help would be appreciated. > > I've not messed with this particular problem in probably 2 years and > I've forgotten more than comments above. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sun Jul 5 05:34:42 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jul 2020 12:34:42 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: I don't know of the other tools being available, but...it does look like I will have this book on Interlibrary Loan for .... quite a while longer. No promises, but if I get bored this summer..... Adam On Sat, Jul 4, 2020 at 11:34 AM John Cowan wrote: > > > On Sat, Jul 4, 2020 at 12:33 PM Adam Thornton wrote: > > The "s" editor is written by Webb Miller and appears in his book "A >> Software Tools Sampler." >> > > Wow, I never knew about this book, though I know ST and STP well, and used > ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s. Is the rest of the > source code for the book available online anywhere? > > Jez Higgins is rewriting the STP tools into modern C++. His blog posts > are at and the > code is at . He's rewritten the > tools in chapters 1 and 2 and part of 3. > > Since I find ed thoroughly unpleasant to use, having a screen editor was a >> must for me to use v7 for any length of time, and s fills that role rather >> nicely. >> > > Gotcha. I actually like line editors (you can't mung your file so > thoroughly with a single stray keystroke), but I'm willing to trade a > little standardosity for additional convenience, so I do almost all my > editing of prose and programs in `ex`, occasionally dropping into vi-mode > for matching open and close markers in Lisp and XML. > > > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > If you have ever wondered if you are in hell, it has been said, then > you are on a well-traveled road of spiritual inquiry. If you are > absolutely sure you are in hell, however, then you must be on the Cross > Bronx Expressway. --Alan Feuer, New York Times, 2002-09-20 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 5 06:02:17 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 4 Jul 2020 16:02:17 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton wrote: > v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and > uuclean. > Yep - that was BSDism, the version 3BSD -- uuname.c should just recompile and manpage is very google-able. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sun Jul 5 07:58:46 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jul 2020 14:58:46 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: Yup, and the output is exactly what I would expect: # ./uuname Format 16bitpi # ./uuname -l v7 That is, locally I am v7, and the only remote host I know about is 16bitpi. Adam On Sat, Jul 4, 2020 at 1:02 PM Clem Cole wrote: > > > On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton wrote: > >> v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and >> uuclean. >> > Yep - that was BSDism, the version 3BSD -- uuname.c > should > just recompile and manpage is very google-able. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jul 5 10:05:57 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jul 2020 10:05:57 +1000 (EST) Subject: [TUHS] VFS prior to 1984 In-Reply-To: <20200624193647.GB14302@mcvoy.com> References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> Message-ID: On Wed, 24 Jun 2020, Larry McVoy wrote: >> In the end, early NFS was notorious for putting 'holes' in the files >> because of the automatic seek in every operation and errors not coming >> until close(2) time. > > You have no idea how many of those holes that 16 bit SCCS checksum has > found (BitKeeper kept it). Aren't holes part of the file system semantics? Seek beyond EOF, write a block, and you've created unallocated holes. Of course, they are filled with zeroes as soon as you copy the file... I did fiddle with "cp" to detect those holes and preserve them, but gave up for some reason (performance hit in checking for all-zero blocks, I think, along with some weird problem with the last block being all zeroes). I used NFS when it first appeared and got bitten quite badly; I've never really trusted it ever since, but I understand that it's vastly improved. -- Dave From lm at mcvoy.com Sun Jul 5 10:16:09 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 4 Jul 2020 17:16:09 -0700 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> Message-ID: <20200705001609.GO29318@mcvoy.com> On Sun, Jul 05, 2020 at 10:05:57AM +1000, Dave Horsfall wrote: > On Wed, 24 Jun 2020, Larry McVoy wrote: > > >>In the end, early NFS was notorious for putting 'holes' in the files > >>because of the automatic seek in every operation and errors not coming > >>until close(2) time. > > > >You have no idea how many of those holes that 16 bit SCCS checksum has > >found (BitKeeper kept it). > > Aren't holes part of the file system semantics? I'm not talking about legit holes, I'm talking about where your data used be served up as a list of zeros. The SCCS checksum is weak but kinda handy. You could see single bit errors with it (at least you could in BitKeeper). It would say checksum error: wanted %d, got %d and you could look at the numbers and see that it was one bit off. We found a bunch of those because computers used to be ECC or parity and then 15 years ago or so, they just dumped the parity bit so single bit errors go unreported (noice, computer industry). From dave at horsfall.org Sun Jul 5 11:34:22 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jul 2020 11:34:22 +1000 (EST) Subject: [TUHS] Origins and life of the pg pager In-Reply-To: <20200625015009.GB4655@mit.edu> References: <7wsgewophe.fsf@junk.nocrew.org> <10160f8c-62a3-014b-43a1-65025f27cde5@mhorton.net> <20200622162406.GA48733@clarinet.employees.org> <0F78CB9D-870B-4008-B975-23756EFC6F83@iitbombay.org> <20200622224301.kdouj%steffen@sdaoden.eu> <20200625015009.GB4655@mit.edu> Message-ID: On Wed, 24 Jun 2020, Theodore Y. Ts'o wrote: > P.S. Of course, the fact that the The Open Group tried to convince the > world to stop using tar and cpio in favor to pax seems to be a strong > indication that they forgot the lesson of King Canute. :-) Minor nit: King Canute never tried to hold back the waves. His subjects were convinced that he could, so he demonstrated otherwise. -- Dave From clemc at ccc.com Sun Jul 5 11:43:04 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 4 Jul 2020 21:43:04 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> Message-ID: On Sat, Jul 4, 2020 at 8:07 PM Dave Horsfall wrote: > Aren't holes part of the file system semantics? > Exactly - and that was the problem with NFS. Consider two write operations. Remember each op is a complete operation with a seek to where it's going. If the first fails, but the error is not reported (NFS returns errors on close), the second operations seek over the failed write -- UNIX puts zeros in the file. File closes later and the size is fine of course. Oh yeah, whoever bothered to check for errors on close (like the traditional SCCS or RCS commands)? Later to try to read your file back -- it will have a bunch of zeros. As Larry says, running a simple checksum could catch a lot of these. Anyway, I'm going to be good and lay off a diatribe on NFS. It sort of worked 'good enough.' But I will say other systems (like AFS) were much better, in practice, but it lost the war. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sun Jul 5 15:42:09 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jul 2020 22:42:09 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <01f8f896-9921-6c55-8dc2-6b9859f2f230@tnetconsulting.net> Message-ID: Jon Brase on the PiDP-11 list solved the problem for me. For future reference, you need to dedicate a tty line/host TCP port to the UUCP line, and tell simh to use it notelnet. e.g.: set dz en set dz lines=16 att -m dz 1107 # UUCP needs 8 bits set dz 8b att dz -am line=4,1729;notelnet And then on the Taylor UUCP side, point the UUCP port at localhost:1729 (rather than 1107). Adam On Sat, Jul 4, 2020 at 2:58 PM Adam Thornton wrote: > Yup, and the output is exactly what I would expect: > > # ./uuname > Format > 16bitpi > # ./uuname -l > v7 > > That is, locally I am v7, and the only remote host I know about is 16bitpi. > > Adam > > On Sat, Jul 4, 2020 at 1:02 PM Clem Cole wrote: > >> >> >> On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton wrote: >> >>> v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, >>> and uuclean. >>> >> Yep - that was BSDism, the version 3BSD -- uuname.c >> should >> just recompile and manpage is very google-able. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Jul 6 00:43:32 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 5 Jul 2020 07:43:32 -0700 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> Message-ID: <20200705144332.GR29318@mcvoy.com> On Sat, Jul 04, 2020 at 09:43:04PM -0400, Clem Cole wrote: > On Sat, Jul 4, 2020 at 8:07 PM Dave Horsfall wrote: > > > Aren't holes part of the file system semantics? > > > Exactly - and that was the problem with NFS. Consider two write > operations. Remember each op is a complete operation with a seek to where > it's going. If the first fails, but the error is not reported (NFS returns > errors on close), the second operations seek over the failed write -- UNIX > puts zeros in the file. File closes later and the size is fine of > course. Oh yeah, whoever bothered to check for errors on close (like the > traditional SCCS or RCS commands)? > > Later to try to read your file back -- it will have a bunch of zeros. So I've encountered lots of holes in NFS files where there shouldn't be any. So it is/was a thing. But that said, I can't remember a single case of encountering that on Sun's campus. I don't know if my memory is failing me, but I do know that when I left Sun and started working with other NFS implementations, yeah, lots of problems. Somehow Sun got it right where other people didn't. The point I'm trying to make is that I don't think NFS was broken by design, it worked when it was Sun servers and Sun clients. Sun's entire campus, 10's of thousands of machines, used NFS. Sun would have screeched to a halt if NFS didn't work reliably all the time. So it was possible to get it to work. My guess is that other people didn't understand the "rules" and did things that created problems. Sun's clients did understand and did not push NFS in ways that would break it. My memory may not be the greatest but I can still remember being astonished when I first ran into people saying NFS didn't work. It worked great for Sun and Sun's customers. From krewat at kilonet.net Mon Jul 6 04:40:06 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 5 Jul 2020 14:40:06 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: <20200705144332.GR29318@mcvoy.com> References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> Message-ID: <238b6e06-b6d9-20b0-a4d2-ed1207e3168a@kilonet.net> On 7/5/2020 10:43 AM, Larry McVoy wrote: > So I've encountered lots of holes in NFS files where there shouldn't be > any. So it is/was a thing. But that said, I can't remember a single > case of encountering that on Sun's campus. I don't know if my memory > is failing me, but I do know that when I left Sun and started working > with other NFS implementations, yeah, lots of problems. Somehow Sun > got it right where other people didn't. I can say personally, since the early 90's on SunOS, I never ever saw this problem in a variety of environments. One being Nynex Science and Technology where I did a consulting stint. 800+ node Sun 3/4 SunOS workstation/server environment, basically everyone's desktop was a Sun workstation for email, documentation, whatever. Another being a defense contractor I was at for 7 years, they were all Sun for engineering workstations and servers. There is one possibility I just thought of, and that's if the first write fails and then a context switch happens, if enough free space is made available before the next context switch back to the second write, I can see that being a problem ;) As if you weren't already tired of my rambling... When it comes to non-Sun operating systems, all bets were off. They all (mostly) worked with their own kind. That usually wasn't the case when it came to cross-vendor support. Sun<->HP was not great, but that also may have been driver problems in the one instance I tried it for an extended period of time. Two instances at different customers of AIX<->Sun actually worked rather well. The YP integration was key. The entire problem with "holey" files and NFS is certainly related to the usage type of the system in question. What was Sun doing? Email? Software development? Using a common NFS share for the compiler? And then copying their code up to a central location? Not a lot of sync/write/sync/write activity, unless object file generation is a lot of skipping around all over the place. ;) art k. From clemc at ccc.com Mon Jul 6 06:08:39 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 5 Jul 2020 16:08:39 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: <20200705144332.GR29318@mcvoy.com> References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> Message-ID: On Sun, Jul 5, 2020 at 10:43 AM Larry McVoy wrote: > My guess is that other people didn't understand the "rules" and did > things that created problems. Sun's clients did understand and did > not push NFS in ways that would break it. I >>believe<< that a difference was file I/O was based on mmap on SunOS and not on other systems (don't know about Solaris). The error was handled by the OS memory system. You tell me about how SGI handled I/O. Tru64 used mmap and I think macOS does also from the Mach heritage. RTU/Ultrix was traditional BSD. Stellix was SRV3. Both had a file system cache with write-behind. I never knew for sure, but I always suspected that was crux of the difference in how/where the write failure were handled. But as you pointed out, many production NFS sites not running Suns had huge problems with holes in files that were not discovered until it was too late to fix them. SCCS/RCS repositories were particularly suspect and because people tried to use them for shared development areas, it could be a big issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Mon Jul 6 06:42:45 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 5 Jul 2020 16:42:45 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> Message-ID: I always used the design principle "Write locally, read over NFS". This obviated locking issues and fit in with the idea of fate-sharing: a write would always succeed, even if reading would have to wait until R (the machine doing the reading) was up. The only additional thing I needed was the ability for W (the machine doing the writing) to notify R that something had changed, which I did by having R run a process that listened on a port that would be opened and then closed by W: no data flowed over this connection. If this connection could not be made, the process on the W side would loop in bounded exponential backoff. On Sun, Jul 5, 2020 at 4:09 PM Clem Cole wrote: > > > On Sun, Jul 5, 2020 at 10:43 AM Larry McVoy wrote: > >> My guess is that other people didn't understand the "rules" and did >> things that created problems. Sun's clients did understand and did >> not push NFS in ways that would break it. > > I >>believe<< that a difference was file I/O was based on mmap on SunOS > and not on other systems (don't know about Solaris). The error was > handled by the OS memory system. You tell me about how SGI handled I/O. > Tru64 used mmap and I think macOS does also from the Mach heritage. > RTU/Ultrix was traditional BSD. Stellix was SRV3. Both had a file > system cache with write-behind. > > I never knew for sure, but I always suspected that was crux of the > difference in how/where the write failure were handled. But as you > pointed out, many production NFS sites not running Suns had huge problems > with holes in files that were not discovered until it was too late to fix > them. SCCS/RCS repositories were particularly suspect and because people > tried to use them for shared development areas, it could be a big issue. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 6 07:04:06 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 5 Jul 2020 17:04:06 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> Message-ID: On Sun, Jul 5, 2020 at 4:42 PM John Cowan wrote: > I always used the design principle "Write locally, read over NFS". > This was the basic idea of AFS. Originally, the CMU folks did whole file caching, but by AFS 4.0 time, they had a Locus token manager (think DLM) that scaled really well so partial caching was allowed. It actually made a small disk system possible. What tended to happen, on your first boot, of course, you had to fill /bin and lot of heavily used directories. But what happened is that your system quickly had only the files you really needed on the local disk. - the ones you were writing, and the few you used over and over. FWIW: I know a couple of people that still run it. I ran it until a few years ago when I switched NAS units just for cost reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Jul 6 07:14:35 2020 From: crossd at gmail.com (Dan Cross) Date: Sun, 5 Jul 2020 17:14:35 -0400 Subject: [TUHS] VFS prior to 1984 In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> Message-ID: On Sun, Jul 5, 2020 at 5:06 PM Clem Cole wrote: > On Sun, Jul 5, 2020 at 4:42 PM John Cowan wrote: > >> I always used the design principle "Write locally, read over NFS". >> > This was the basic idea of AFS. Originally, the CMU folks did whole file > caching, but by AFS 4.0 time, they had a Locus token manager (think DLM) > that scaled really well so partial caching was allowed. It actually made a > small disk system possible. What tended to happen, on your first boot, of > course, you had to fill /bin and lot of heavily used directories. But > what happened is that your system quickly had only the files you really > needed on the local disk. - the ones you were writing, and the few you > used over and over. > > FWIW: I know a couple of people that still run it. I ran it until a few > years ago when I switched NAS units just for cost reasons. > There was a neat paper out of CERN a few years ago about how they're turning down their AFS (now OpenAFS) cells. https://iopscience.iop.org/article/10.1088/1742-6596/898/6/062040/pdf It seems that the idea of a big, shared, distributed file namespace is sadly disappearing. I feel like most of the web-based replacements are not as seamlessly integrated with my preferred toolset as what they're replacing, but I've also become more and more acutely aware that I am not the target audience for those things. Certainly, real-time collaboration via e.g. Google Drive is pretty amazing and very dynamic, particularly when paired with e.g. real-time video chat, but it also forces one into a particular model of interaction that I've spent most of the last three decades consciously avoiding but now find no escape from. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jul 6 14:12:21 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Jul 2020 14:12:21 +1000 (EST) Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Sat, 4 Jul 2020, Adam Thornton wrote: > Since I find ed thoroughly unpleasant to use, having a screen editor was > a must for me to use v7 for any length of time, and s fills that role > rather nicely. A boss of mine insisted that we all learned "ed", because one day it might be the only editor available to you after a crash; he was right... -- Dave From imp at bsdimp.com Mon Jul 6 14:18:04 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 5 Jul 2020 22:18:04 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall wrote: > On Sat, 4 Jul 2020, Adam Thornton wrote: > > > Since I find ed thoroughly unpleasant to use, having a screen editor was > > a must for me to use v7 for any length of time, and s fills that role > > rather nicely. > > A boss of mine insisted that we all learned "ed", because one day it might > be the only editor available to you after a crash; he was right... > I should do that... So far I've managed to get by with sed :) Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jul 6 14:42:41 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Jul 2020 14:42:41 +1000 (EST) Subject: [TUHS] VFS prior to 1984 In-Reply-To: <20200705001609.GO29318@mcvoy.com> References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705001609.GO29318@mcvoy.com> Message-ID: On Sat, 4 Jul 2020, Larry McVoy wrote: >> Aren't holes part of the file system semantics? > > I'm not talking about legit holes, I'm talking about where your data > used be served up as a list of zeros. Ah; my mistake... Too much blood in my coffee stream. > The SCCS checksum is weak but kinda handy. You could see single bit > errors with it (at least you could in BitKeeper). [...] I used to edit SCCS files if I stuffed up an update (and didn't want to make another update); I discovered that if I zeroed the checksum then it would be recalculated... I have no idea what happened should the "genuine" checksum turn out to be zero. -- Dave From arnold at skeeve.com Mon Jul 6 16:51:36 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 06 Jul 2020 00:51:36 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: <202007060651.0666paxk031885@freefriends.org> Warner Losh wrote: > On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall wrote: > > > On Sat, 4 Jul 2020, Adam Thornton wrote: > > > > > Since I find ed thoroughly unpleasant to use, having a screen editor was > > > a must for me to use v7 for any length of time, and s fills that role > > > rather nicely. > > > > A boss of mine insisted that we all learned "ed", because one day it might > > be the only editor available to you after a crash; he was right... > > > > I should do that... So far I've managed to get by with sed :) > > Warner > > > If you know the ex subset of vi, you know most of what you need to know to use ed ... Arnold From musher at ucsc.edu Mon Jul 6 17:11:33 2020 From: musher at ucsc.edu (Michael Usher) Date: Mon, 6 Jul 2020 00:11:33 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <202007060651.0666paxk031885@freefriends.org> References: <202007060651.0666paxk031885@freefriends.org> Message-ID: I actually like ed and sam. I find it "soothing" to be able to manipulate text almost "programmatically".... As an undergrad at USyd EE Dept, the VT100s in the computer lab were often all taken, but there were a few LA30s still hooked up and no-one wanted to use them. I learned how to optimally enter, compile and debug code through a paper interface. It was VMS of course at EE, but when I started using the Unix systems at CS a year later, the 11/750 was so heavily loaded that "ed" was the best choice for getting assignments done quickly. Line editors were also much more pleasant to use over slow modem connections. I had a 28.8k modem but the dialup pool rarely got you a high speed connection... But back to the original topic... Has the MHSnet code made it into the public domain? Michael On Sun, Jul 5, 2020 at 11:52 PM wrote: > Warner Losh wrote: > > > On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall wrote: > > > > > On Sat, 4 Jul 2020, Adam Thornton wrote: > > > > > > > Since I find ed thoroughly unpleasant to use, having a screen editor > was > > > > a must for me to use v7 for any length of time, and s fills that role > > > > rather nicely. > > > > > > A boss of mine insisted that we all learned "ed", because one day it > might > > > be the only editor available to you after a crash; he was right... > > > > > > > I should do that... So far I've managed to get by with sed :) > > > > Warner > > > > > > > If you know the ex subset of vi, you know most of what you need to > know to use ed ... > > Arnold > -- Michael Usher Senior Wireless Network Engineer University of California, Santa Cruz musher at ucsc.edu 831-459-3697 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 6 23:57:49 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jul 2020 09:57:49 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: I always recommend doing the exercises in Rob and Brian's UPE on ed because then everything else makes sense, like sed or any other editor. Plus you get the advantage you point out, and the reality is that so many simpler editors (like edlin) have similar functionality, it means you can get something done, just about anywhere. On Mon, Jul 6, 2020 at 12:14 AM Dave Horsfall wrote: > On Sat, 4 Jul 2020, Adam Thornton wrote: > > > Since I find ed thoroughly unpleasant to use, having a screen editor was > > a must for me to use v7 for any length of time, and s fills that role > > rather nicely. > > A boss of mine insisted that we all learned "ed", because one day it might > be the only editor available to you after a crash; he was right... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at torek.net Tue Jul 7 02:51:27 2020 From: torek at torek.net (Chris Torek) Date: Mon, 06 Jul 2020 09:51:27 -0700 Subject: [TUHS] VFS prior to 1984 In-Reply-To: Your message of "Sat, 04 Jul 2020 17:16:09 -0700." <20200705001609.GO29318@mcvoy.com> Message-ID: <202007061651.066GpW9s048139@elf.torek.net> >On Sun, Jul 05, 2020 at 10:05:57AM +1000, Dave Horsfall wrote: >We found a bunch of those because computers used to be ECC or parity and >then 15 years ago or so, they just dumped the parity bit so single bit >errors go unreported (noice, computer industry). To be fair, there are still some ECC systems. Unfortunately most of the home-use Intel boxes aren't. My own home-use box isn't and (now 6+ years ago) I had bad RAM in it that produced single-bit errors in an inode block that led to panics that led to me finding the single-bit errors, but I don't know if there are some damaged files. I keep thinking I'll replace it with a new box that does have ECC, but haven't gotten around to it yet. I see some consumer-priced AMD CPUs have at least theoretical ECC support but I haven't found anything that says the ECC actually works, and have seen a few articles that hint that it doesn't. iX sells NAS boxes that do have ECC, though. Chris From cowan at ccil.org Tue Jul 7 04:51:04 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 6 Jul 2020 14:51:04 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: I fall back to ed or tr when I hit the bug in vim that prevents you from inserting a newline with the s command (it inserts a NUL instead). On Mon, Jul 6, 2020 at 9:59 AM Clem Cole wrote: > I always recommend doing the exercises in Rob and Brian's UPE on ed > because then everything else makes sense, like sed or any other editor. > Plus you get the advantage you point out, and the reality is that so many > simpler editors (like edlin) have similar functionality, it means you can > get something done, just about anywhere. > > On Mon, Jul 6, 2020 at 12:14 AM Dave Horsfall wrote: > >> On Sat, 4 Jul 2020, Adam Thornton wrote: >> >> > Since I find ed thoroughly unpleasant to use, having a screen editor >> was >> > a must for me to use v7 for any length of time, and s fills that role >> > rather nicely. >> >> A boss of mine insisted that we all learned "ed", because one day it >> might >> be the only editor available to you after a crash; he was right... >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jul 7 05:19:05 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 06 Jul 2020 13:19:05 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: <202007061919.066JJ51w031385@freefriends.org> John Cowan wrote: > I fall back to ed or tr when I hit the bug in vim that prevents you from > inserting a newline with the s command (it inserts a NUL instead). Huh? I've never seen this, in over 20 years of using vim. To insert a newline just use s/foobar/foo^V^Mbar/ where ^V^M are Control-V Control-M. Arnold From cowan at ccil.org Tue Jul 7 05:36:02 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 6 Jul 2020 15:36:02 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <202007061919.066JJ51w031385@freefriends.org> References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: On Mon, Jul 6, 2020 at 3:19 PM wrote: Huh? I've never seen this, in over 20 years of using vim. To > insert a newline just use > > s/foobar/foo^V^Mbar/ > > where ^V^M are Control-V Control-M. > I never thought of that; I've always tried what works in ed, namely: s/foobar/foo\ bar and that gives me foo^@bar I call that a bug. (This is vim 8.1). It certainly wouldn't occur to me to use ^V^M, anyhow: ^V^J would seem more reasonable, but ^V is ignored in that context. Before vim 7 there was a bug so bad I had to use nvi (and, often enough, compile it from source): at that time, undo undid everything back to the last action in vi-mode. If you had never been in vi-mode (as I usually had not) it undid everything back to the last file-loading command! That one made me grind my teeth a lot. Even now I habitually write before undoing, just in case. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org A male Jang appeared at my side. "Get a grip on yourself," he said. "Get a grip on your graks," I suggested. --Tanith Lee, Drinking Sapphire Wine -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Jul 7 05:58:49 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 6 Jul 2020 15:58:49 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: On Mon, Jul 6, 2020 at 3:36 PM John Cowan wrote: I call that a bug. (This is vim 8.1). > To be precise, this is now https://github.com/vim/vim/issues/6411. Feel free to upvote. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 7 06:48:24 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jul 2020 16:48:24 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: below... On Mon, Jul 6, 2020 at 3:36 PM John Cowan wrote: > > On Mon, Jul 6, 2020 at 3:19 PM wrote: > > Huh? I've never seen this, in over 20 years of using vim. To >> insert a newline just use >> >> s/foobar/foo^V^Mbar/ >> >> where ^V^M are Control-V Control-M. >> > > I never thought of that; I've always tried what works in ed, namely: > > s/foobar/foo\ > bar > need a closing / for ed, but ex/vi accepts the naked version. > > and that gives me > > foo^@bar > > I call that a bug. (This is vim 8.1). > In fairness, early vi did this too. nvi (Bostic's rewrite) which came out around 4.3 or 4.4 fixed it. > > It certainly wouldn't occur to me to use ^V^M, anyhow: ^V^J would seem > more reasonable, but ^V is ignored in that context. > I agree, I have tried to us the ^V^J idiom with different success. Since vim has been forced down my throat, I tend to not try it, and as you say, switch editors when I need to add a newline. > > Before vim 7 there was a bug so bad I had to use nvi (and, often enough, > compile it from source): at that time, undo undid everything back to the > last action in vi-mode. If you had never been in vi-mode (as I usually had > not) it undid everything back to the last file-loading command! That one > made me grind my teeth a lot. Even now I habitually write before undoing, > just in case. > Amen ... vim's undo can be ... a ... challenging for original vi user - but that has been debated here a few times and I'd rather not see another war. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jul 7 07:18:55 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jul 2020 07:18:55 +1000 (EST) Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Mon, 6 Jul 2020, Clem Cole wrote: > I always recommend doing the exercises in Rob and Brian's UPE on ed > because then everything else makes sense, like sed or any other editor.  >  Plus you get the advantage you point out, and the reality is that so > many simpler editors (like edlin) have similar functionality, it means > you can get something done, just about anywhere. There was also the client we had in PNG, where access was via a flakey 1200 modem i.e. no error correction, and VI was out of the question. I learned to use ED when V5 first appeared (down-under) in the 70s (it was the *only* editor) and I'm glad that I did. I must grab a copy of UPE and read it again, just for old times' sake. -- Dave From dave at horsfall.org Tue Jul 7 07:47:12 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jul 2020 07:47:12 +1000 (EST) Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <202007061919.066JJ51w031385@freefriends.org> References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: On Mon, 6 Jul 2020, arnold at skeeve.com wrote: > Huh? I've never seen this, in over 20 years of using vim. To insert a > newline just use > > s/foobar/foo^V^Mbar/ I'm surprised that not more people know about the ^V "escape next character" trick. -- Dave From cowan at ccil.org Tue Jul 7 07:47:49 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 6 Jul 2020 17:47:49 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: Message-ID: On Mon, Jul 6, 2020 at 5:19 PM Dave Horsfall wrote: > There was also the client we had in PNG, where access was via a flakey > 1200 modem i.e. no error correction, and VI was out of the question. > The old 'o' command (which does the same as 'vi' in vim) was designed for that situation, provided your terminal isn't a printing one. A one-line window is cheap enough; backspace and carriage-return give you everything you need. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The Imperials are decadent, 300 pound free-range chickens (except they have teeth, arms instead of wings, and dinosaurlike tails). --Elyse Grasso -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu at toad.com Tue Jul 7 09:23:37 2020 From: gnu at toad.com (John Gilmore) Date: Mon, 06 Jul 2020 16:23:37 -0700 Subject: [TUHS] ECC memory In-Reply-To: <202007061651.066GpW9s048139@elf.torek.net> References: <202007061651.066GpW9s048139@elf.torek.net> Message-ID: <23548.1594077817@hop.toad.com> Chris Torek wrote: > I keep thinking I'll replace it with a new box that does have ECC, > but haven't gotten around to it yet. I see some consumer-priced > AMD CPUs have at least theoretical ECC support but I haven't found > anything that says the ECC actually works, and have seen a few > articles that hint that it doesn't. All the AMD Ryzen CPUs and chipsets have built-in ECC. It's easy since the CPU pins talk directly to main memory. This is one among thousands of reasons to avoid buying Intel CPUs. The machine I'm typing on has ECC memory, and I bought it in 2019. You have to pick a motherboard that wasn't designed by dolts. (I got the Gigabyte Aorus "AX-370-GAMING5", which of course is no longer manufactured.) And you have to spend an extra $5 or $10 on your DIMMs. Get the motherboard maker's "Qualified Vendor List", e.g.: http://download.gigabyte.us/FileList/Memory/mb_memory_ga-ax370-gaming5_pinnacle_v4.pdf Be sure there *are* some approved ECC dimms on the list. Buy those. You may or may not have to fiddle something in the BIOS settings. Check dmesg when you first boot the machine (booting the installer is fine). Make sure the Linux kernel sees the DIMMS, isn't subverted by the BIOS, and understands the CPU/memory control registers. When it works, you'll see something like: [ 0.180161] EDAC MC: Ver: 3.0.0 [ 9.389338] EDAC amd64: Node 0: DRAM ECC enabled. [ 9.389339] EDAC amd64: F17h detected (node 0). [ 9.389375] EDAC MC: UMC0 chip selects: [ 9.389376] EDAC amd64: MC: 0: 0MB 1: 0MB [ 9.389376] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 9.389378] EDAC MC: UMC1 chip selects: [ 9.389379] EDAC amd64: MC: 0: 0MB 1: 0MB [ 9.389379] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 9.389380] EDAC amd64: using x8 syndromes. [ 9.389380] EDAC amd64: MCT channel count: 2 [ 9.389422] EDAC MC0: Giving out device to module amd64_edac controller F17h: DEV 0000:00:18.3 (INTERRUPT) [ 9.389428] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED) [ 9.389429] AMD64 EDAC driver v3.5.0 Success! Non-flaky main memory in a PC clone! Cost: about $50 plus paying attention. John From bakul at iitbombay.org Tue Jul 7 11:07:34 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 6 Jul 2020 18:07:34 -0700 Subject: [TUHS] VFS prior to 1984 In-Reply-To: <202007061651.066GpW9s048139@elf.torek.net> References: <202007061651.066GpW9s048139@elf.torek.net> Message-ID: On Jul 6, 2020, at 9:51 AM, Chris Torek wrote: > >> On Sun, Jul 05, 2020 at 10:05:57AM +1000, Dave Horsfall wrote: >> We found a bunch of those because computers used to be ECC or parity and >> then 15 years ago or so, they just dumped the parity bit so single bit >> errors go unreported (noice, computer industry). > > To be fair, there are still some ECC systems. Unfortunately most > of the home-use Intel boxes aren't. My own home-use box isn't and > (now 6+ years ago) I had bad RAM in it that produced single-bit > errors in an inode block that led to panics that led to me finding > the single-bit errors, but I don't know if there are some damaged > files. > > I keep thinking I'll replace it with a new box that does have ECC, > but haven't gotten around to it yet. I see some consumer-priced > AMD CPUs have at least theoretical ECC support but I haven't found > anything that says the ECC actually works, and have seen a few > articles that hint that it doesn't. iX sells NAS boxes that do > have ECC, though. For my fileserver I am using a Gigabyte X470 Aorus Gaming board with "qualified" ECC RAM (dmidecode confirms this) but I am not sure if FreeBSD has ECC support for such boards. At least I don't know how to tell! What I really want is a laptop with ECC to use as the fileserver to avoid having to deal with UPS that lasts a few minutes, cabling and suboptimal support from NUT. SSDs are fast enough for me. Laptop batteries last long and are easy to replace and easy to test when to shutdown the laptop. And less heat and space! From grog at lemis.com Tue Jul 7 11:30:23 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 7 Jul 2020 11:30:23 +1000 Subject: [TUHS] Editors (was: v7 uucp debugging help requested) In-Reply-To: References: Message-ID: <20200707013023.GB1152@eureka.lemis.com> On Monday, 6 July 2020 at 9:57:49 -0400, Clem Cole wrote: > I always recommend doing the exercises in Rob and Brian's UPE on ed > because then everything else makes sense, like sed or any other > editor... People (not just Clem), when you change the topic, can you please modify the Subject: to match? I'm not overly interested in uucp, but editors are a completely different matter. I'm sure I'm not the only one, so many interested parties will miss these replies. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Tue Jul 7 12:11:43 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 6 Jul 2020 20:11:43 -0600 Subject: [TUHS] Topics... Message-ID: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote: > People (not just Clem), when you change the topic, can you please > modify the Subject: to match? I'm not overly interested in uucp, > but editors are a completely different matter. I'm sure I'm not the > only one, so many interested parties will miss these replies. I see this type of change happen — in my not so humble opinion — /way/ /too/ /often/. So, I'm wondering if people are interested in configuring TUHS and / or COFF mailing list (Mailman) with topics. That way people could subscribe to the topics that they are interested in and not receive copies of topics they aren't interested in. I'm assuming that TUHS and COFF are still on Mailman mailing lists and that Warren would be amicable to such. To clarify, it would still be the same mailing list(s) as they exist today. They would just have the to be utilized option of picking interesting topics. Where topics would be based on keywords in the message body. I'm just trying to gauge people's interest in this idea. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From athornton at gmail.com Tue Jul 7 12:56:53 2020 From: athornton at gmail.com (Adam Thornton) Date: Mon, 6 Jul 2020 19:56:53 -0700 Subject: [TUHS] [COFF] Topics... In-Reply-To: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> Message-ID: <42645CD9-E6FE-4F03-9D74-AD830409A62F@gmail.com> > On Jul 6, 2020, at 7:11 PM, Grant Taylor via COFF wrote: > > On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote: >> People (not just Clem), when you change the topic, can you please modify the Subject: to match? I'm not overly interested in uucp, but editors are a completely different matter. I'm sure I'm not the only one, so many interested parties will miss these replies. > > I see this type of change happen — in my not so humble opinion — /way/ /too/ /often/. > > So, I'm wondering if people are interested in configuring TUHS and / or COFF mailing list (Mailman) with topics. That way people could subscribe to the topics that they are interested in and not receive copies of topics they aren't interested in. > > I'm assuming that TUHS and COFF are still on Mailman mailing lists and that Warren would be amicable to such. > > To clarify, it would still be the same mailing list(s) as they exist today. They would just have the to be utilized option of picking interesting topics. Where topics would be based on keywords in the message body. > > I'm just trying to gauge people's interest in this idea. Meh. These lists aren’t so high-traffic that I feel a need to, but if it happens it won’t bother me. Adam From arnold at skeeve.com Tue Jul 7 16:21:43 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Jul 2020 00:21:43 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: <202007070621.0676LhrH025006@freefriends.org> Clem Cole wrote: > > It certainly wouldn't occur to me to use ^V^M, anyhow: ^V^J would seem > > more reasonable, but ^V is ignored in that context. > > I agree, I have tried to us the ^V^J idiom with different success. Since > vim has been forced down my throat, I tend to not try it, and as you say, > switch editors when I need to add a newline. As I said, ^V^M has worked flawlessly for me for > 20 years. Arnold From arnold at skeeve.com Tue Jul 7 16:23:20 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Jul 2020 00:23:20 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: <202007070623.0676NKNI025053@freefriends.org> Dave Horsfall wrote: > On Mon, 6 Jul 2020, arnold at skeeve.com wrote: > > > Huh? I've never seen this, in over 20 years of using vim. To insert a > > newline just use > > > > s/foobar/foo^V^Mbar/ > > I'm surprised that not more people know about the ^V "escape next > character" trick. > > -- Dave It's described quite clearly in O'Reilly's book on vi and vim (coauthored by yours truly - plug, plug :-). Arnold From salewski at att.net Wed Jul 8 00:38:43 2020 From: salewski at att.net (Alan D. Salewski) Date: Tue, 7 Jul 2020 10:38:43 -0400 Subject: [TUHS] Topics... In-Reply-To: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> Message-ID: <20200707143843.GI11130@att.net> On 2020-07-06 20:11:43, Grant Taylor via TUHS spake thus: [...] > So, I'm wondering if people are interested in configuring TUHS and / or COFF > mailing list (Mailman) with topics. That way people could subscribe to the > topics that they are interested in and not receive copies of topics they > aren't interested in. [...] > To clarify, it would still be the same mailing list(s) as they exist today. > They would just have the to be utilized option of picking interesting > topics. Where topics would be based on keywords in the message body. > > I'm just trying to gauge people's interest in this idea. My preference would be to keep things the way they are. I want to receive all list messages; I would not want to switch to an arrangement where I was in danger of missing messages because my list preferences config became a little stale. -Al -- ----------------------------------------------------------------- a l a n d. s a l e w s k i salewski at att.net 1024D/FA2C3588 EDFA 195F EDF1 0933 1002 6396 7C92 5CB3 FA2C 3588 ----------------------------------------------------------------- From rtomek at ceti.pl Wed Jul 8 00:33:40 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 7 Jul 2020 16:33:40 +0200 Subject: [TUHS] Topics... In-Reply-To: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> Message-ID: <20200707143340.GA20201@tau1.ceti.pl> On Mon, Jul 06, 2020 at 08:11:43PM -0600, Grant Taylor via TUHS wrote: > On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote: > >People (not just Clem), when you change the topic, can you please > >modify the Subject: to match? I'm not overly interested in uucp, > >but editors are a completely different matter. I'm sure I'm not > >the only one, so many interested parties will miss these replies. > > I see this type of change happen — in my not so humble opinion — > /way/ /too/ /often/. > > So, I'm wondering if people are interested in configuring TUHS and / > or COFF mailing list (Mailman) with topics. That way people could > subscribe to the topics that they are interested in and not receive > copies of topics they aren't interested in. [...] > I'm just trying to gauge people's interest in this idea. I would not care. I would want to get everything, because one day my interests could change (I might want to know what people said about editors, for example :-) ) and who knows, maybe a list would be gone already. I even archive the spam, just in case I want to do some big data stuff on it one day. My yearly mailbox is on par with two cdroms, so any savings would be rather minimal. And boy, the more the better. Just think about those scripts to process (hundred) thousands of mails. Displaying stuff on text terminal. Green text terminal emulator. Better than norp, if you ask me. Actually, this is norp. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From cowan at ccil.org Wed Jul 8 01:26:42 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 7 Jul 2020 11:26:42 -0400 Subject: [TUHS] Topics... In-Reply-To: <20200707143843.GI11130@att.net> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> <20200707143843.GI11130@att.net> Message-ID: On Tue, Jul 7, 2020 at 10:39 AM Alan D. Salewski wrote: > I'm just trying to gauge people's interest in this idea. > > My preference would be to keep things the way they are. > > I want to receive all list messages; I would not want to switch to an > arrangement where I was in danger of missing messages because my list > preferences config became a little stale. > Very much +1. Part of the trouble is that Gmail and similar clients don't routinely show you the Subject: line to make it easy to edit it; you have to take affirmative action when you want to change the subject matter. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org It's the old, old story. Droid meets droid. Droid becomes chameleon. Droid loses chameleon, chameleon becomes blob, droid gets blob back again. It's a classic tale. --Kryten, Red Dwarf -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Wed Jul 8 02:16:13 2020 From: norman at oclsc.org (Norman Wilson) Date: Tue, 7 Jul 2020 12:16:13 -0400 (EDT) Subject: [TUHS] Topics... Message-ID: <20200707161613.929A04422E@lignose.oclsc.org> John Cowan: Very much +1. Part of the trouble is that Gmail and similar clients don't routinely show you the Subject: line to make it easy to edit it; you have to take affirmative action when you want to change the subject matter. ==== Perhaps we should take a leaf from 1980s Rob Pike, and just automatically change every message to be Subject: The content of this message (There is an actual story behind that, but I'll leave it to Rob to tell.) Norman Wilson Toronto ON From norman at oclsc.org Wed Jul 8 05:20:58 2020 From: norman at oclsc.org (Norman Wilson) Date: Tue, 07 Jul 2020 15:20:58 -0400 Subject: [TUHS] v7 uucp debugging help requested Message-ID: <1594149663.18455.for-standards-violators@oclsc.org> Dave Horsfall: A boss of mine insisted that we all learned "ed", because one day it might be the only editor available to you after a crash; he was right... ==== Besides which, as The Blessed Manual said in every Research edition: ed is the standard text editor. Norman Wilson Toronto ON (typing this in Toronto qed) From dave at horsfall.org Wed Jul 8 07:45:48 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jul 2020 07:45:48 +1000 (EST) Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <202007070623.0676NKNI025053@freefriends.org> References: <202007061919.066JJ51w031385@freefriends.org> <202007070623.0676NKNI025053@freefriends.org> Message-ID: On Tue, 7 Jul 2020, arnold at skeeve.com wrote: >> I'm surprised that not more people know about the ^V "escape next >> character" trick. > > It's described quite clearly in O'Reilly's book on vi and vim > (coauthored by yours truly - plug, plug :-). Never read the book, since I'd already known VI by then :-) I'm not sure where I picked it up; possibly from the manpage? But we know the saying about programmers not reading documentation... -- Dave From robpike at gmail.com Wed Jul 8 08:47:38 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 8 Jul 2020 08:47:38 +1000 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: <1594149663.18455.for-standards-violators@oclsc.org> References: <1594149663.18455.for-standards-violators@oclsc.org> Message-ID: The thing about ed that is missed by johnny-come-latelys who mock it for its lowness is that it was so much higher than most, if not all the commercially available text editors of its time. The gold standard was perhaps Son of Stopgap, whose very name tells you the state of things. I remember spending a couple of days baking inside a radio telescope control cabin implementing a miniature version of ed in forth just so I work more effectively on the task to come. -rob On Wed, Jul 8, 2020 at 5:22 AM Norman Wilson wrote: > Dave Horsfall: > > A boss of mine insisted that we all learned "ed", because one day it > might > be the only editor available to you after a crash; he was right... > > ==== > > Besides which, as The Blessed Manual said in every > Research edition: > ed is the standard text editor. > > Norman Wilson > Toronto ON > (typing this in Toronto qed) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jul 8 08:53:30 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jul 2020 08:53:30 +1000 (EST) Subject: [TUHS] [COFF] Topics... In-Reply-To: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> Message-ID: On Mon, 6 Jul 2020, Grant Taylor via COFF wrote: > I see this type of change happen — in my not so humble opinion — /way/ > /too/ /often/. It is the nature of unmoderated mailing lists that topics will drift over time until someone jumps in to change the Subject: (and it really ought to be a new thread) and hope that others will take the hint. Yes, I'm just as guilty as others; then again, I've also changed the subject when I realise my transgression. > So, I'm wondering if people are interested in configuring TUHS and / or > COFF mailing list (Mailman) with topics. That way people could > subscribe to the topics that they are interested in and not receive > copies of topics they aren't interested in. They would then need to see what new topics come up from time to time... > I'm assuming that TUHS and COFF are still on Mailman mailing lists and > that Warren would be amicable to such. I believe they are on Mailman, but I have little experience with running it. > To clarify, it would still be the same mailing list(s) as they exist > today. They would just have the to be utilized option of picking > interesting topics. Where topics would be based on keywords in the > message body. On one list I use, a predecessor of it used to require a subject tag in the form [Blah] (taken from a set of known tags); I've always hated that, but I'm still in the habit of putting my own tag there as a hint. -- Dave From dugo at xs4all.nl Wed Jul 8 09:23:28 2020 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 08 Jul 2020 01:23:28 +0200 Subject: [TUHS] [COFF] Topics... In-Reply-To: References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> Message-ID: <97902a98ce76c281160840d78ed838be@xs4all.nl> On 2020-07-08 00:53, Dave Horsfall wrote: > On one list I use, a predecessor of it used to require a subject tag > in the form [Blah] (taken from a set of known tags); I've always hated > that, but I'm still in the habit of putting my own tag there as a > hint. When I have tuned out of a long running thread and the topic drifts significantly I'm always grateful to the kind soul that tags..: Subject: Re: new [was: old] From athornton at gmail.com Wed Jul 8 09:42:40 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 7 Jul 2020 16:42:40 -0700 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <1594149663.18455.for-standards-violators@oclsc.org> Message-ID: <545C8523-3D56-4B6F-8C9D-85DAEBC19B45@gmail.com> > On Jul 7, 2020, at 3:47 PM, Rob Pike wrote: > > The thing about ed that is missed by johnny-come-latelys who mock it for its lowness is that it was so much higher than most, if not all the commercially available text editors of its time. The gold standard was perhaps Son of Stopgap, whose very name tells you the state of things. > > I remember spending a couple of days baking inside a radio telescope control cabin implementing a miniature version of ed in forth just so I work more effectively on the task to come. As the person who kicked off this last round of editor wars by saying I wanted “s” on my v7 system to make it into a daily driver: sure, ed’s not terrible. I can, and have, used it, although in most places where I *would* use it, I also have sed available, and using sed and then comparing the output and the input is just as fast for me and carries less risk of hosing my input file. As line editors go it’s just fine and indeed rather easier than TECO or EDLIN, which are the other two I’ve used from time to time. Oh. And CMS EDIT which it is about on a par with. But I still find it much less pleasant to use than a moderately-OK screen editor, which “s” certainly is. Largely that’s because I don’t think before I type anymore, and I hit keys fast and sometimes inaccurately, because the last 35 years have taught me that I can always go back and fix it up. Now that I have working editing-for-the-sloppy and a way that I can reliably transfer files to and from v7, really all I need to do is mess with the terminal driver so that ^? isn’t immediately-cancel-line, because that too is a finger habit too hard for me to break. Adam From musher at ucsc.edu Wed Jul 8 09:45:57 2020 From: musher at ucsc.edu (Michael Usher) Date: Tue, 7 Jul 2020 16:45:57 -0700 Subject: [TUHS] [COFF] Topics... In-Reply-To: <97902a98ce76c281160840d78ed838be@xs4all.nl> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> <97902a98ce76c281160840d78ed838be@xs4all.nl> Message-ID: I usually edit it to say "Was (not Was)". Hmmm. Wouldn't it be great if we had a Markov chain subject generator that sourced the actual email thread contents as its driver, and then when the topic drifted far enough, it simply replaced the subject line with a new creation ? Ooohhh -- another idea -- RFC5322 states that subject may occur from 0 to 1 times per email. Why don't we just delete the subject lines entirely? Michael (it's late. I need to poke a bear) On Tue, Jul 7, 2020 at 4:30 PM Jacob Goense wrote: > On 2020-07-08 00:53, Dave Horsfall wrote: > > On one list I use, a predecessor of it used to require a subject tag > > in the form [Blah] (taken from a set of known tags); I've always hated > > that, but I'm still in the habit of putting my own tag there as a > > hint. > > When I have tuned out of a long running thread and the topic drifts > significantly I'm always grateful to the kind soul that tags..: > > Subject: Re: new [was: old] > -- Michael Usher Senior Wireless Network Engineer University of California, Santa Cruz musher at ucsc.edu 831-459-3697 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jul 8 12:09:42 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jul 2020 12:09:42 +1000 (EST) Subject: [TUHS] [COFF] Topics... In-Reply-To: <97902a98ce76c281160840d78ed838be@xs4all.nl> References: <8af3a571-aeb5-21fc-0041-be8649e3f9ba@spamtrap.tnetconsulting.net> <97902a98ce76c281160840d78ed838be@xs4all.nl> Message-ID: On Wed, 8 Jul 2020, Jacob Goense wrote: > When I have tuned out of a long running thread and the topic drifts > significantly I'm always grateful to the kind soul that tags..: > > Subject: Re: new [was: old] Yeah, I try and remember to do that... -- Dave From doug at cs.dartmouth.edu Wed Jul 8 23:06:28 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 08 Jul 2020 09:06:28 -0400 Subject: [TUHS] Topics... Message-ID: <202007081306.068D6SZo082218@tahoe.cs.Dartmouth.EDU> Preferring fewer emails, but not wanting to miss out on topics that had not occurred to me, I would continue to subscribe to the digest and not switch to a topic-filtering option. Doug From treese at acm.org Fri Jul 10 15:05:17 2020 From: treese at acm.org (Win Treese) Date: Fri, 10 Jul 2020 01:05:17 -0400 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: > On Jul 6, 2020, at 4:48 PM, Clem Cole wrote: > >> >> I never thought of that; I've always tried what works in ed, namely: >> >> s/foobar/foo\ >> bar > need a closing / for ed, but ex/vi accepts the naked version. In the mid 1980s, when I was working at MIT’s Project Athena, one day Jerry Saltzer (MIT CS professor, known for work on CTSS and Multics, among other things, and Technical Director for Athena) called me into his office. He was trying to edit a file with ed on his IBM PC/RT workstation, which was running IBM’s variant of 4.2BSD on it, and he wanted to know why his search /foo wasn’t working. I typed /foo/, and everything was fine. He looked at it and muttered, “Oh, you have to end it with a slash? When I wrote this for CTSS, you didn’t need to do that.” - Win From imp at bsdimp.com Fri Jul 10 15:19:12 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Jul 2020 23:19:12 -0600 Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: On Thu, Jul 9, 2020, 11:13 PM Win Treese wrote: > > > On Jul 6, 2020, at 4:48 PM, Clem Cole wrote: > > > >> > >> I never thought of that; I've always tried what works in ed, namely: > >> > >> s/foobar/foo\ > >> bar > > need a closing / for ed, but ex/vi accepts the naked version. > > In the mid 1980s, when I was working at MIT’s Project Athena, > one day Jerry Saltzer (MIT CS professor, known for work on CTSS > and Multics, among other things, and Technical Director for Athena) > called me into his office. > > He was trying to edit a file with ed on his IBM PC/RT workstation, > which was running IBM’s variant of 4.2BSD on it, and he wanted > to know why his search > > /foo > > wasn’t working. > > I typed /foo/, and everything was fine. > > He looked at it and muttered, “Oh, you have to end it with a slash? > When I wrote this for CTSS, you didn’t need to do that.” > Kids today.... get off my damn regex... even turning couldn't complete this lot. Bah :) Warner > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Sat Jul 11 11:08:51 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 10 Jul 2020 21:08:51 -0400 Subject: [TUHS] AT&T Research Message-ID: I'm hearing that 50% of what's left of AT&T research got the axe today. I'm hoping to hear from friends about details. God's gift to google, as we have said in the past. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jul 11 11:32:15 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 10 Jul 2020 18:32:15 -0700 Subject: [TUHS] AT&T Research In-Reply-To: References: Message-ID: <20200711013215.GM29318@mcvoy.com> Well that sucks but Bell Labs has not been Bell Labs for a long time. I think most of us here know what Bell Labs contributed to the world, you youngsters who don't know, look it up, it is one of the greatest research/business stories in history. On Fri, Jul 10, 2020 at 09:08:51PM -0400, John P. Linderman wrote: > I'm hearing that 50% of what's left of AT&T research got the axe today. > I'm hoping to hear from friends about details. > God's gift to google, as we have said in the past. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jpl.jpl at gmail.com Sat Jul 11 11:51:10 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 10 Jul 2020 21:51:10 -0400 Subject: [TUHS] AT&T Research In-Reply-To: <20200711013215.GM29318@mcvoy.com> References: <20200711013215.GM29318@mcvoy.com> Message-ID: Every "divestiture" had an adverse effect on critical mass. The split between AT&T and Bellcore was a big hurt. The split between AT&T and Lucent was another. When I joined the Labs in 1973, it was an honor to work there. I don't see anything special about any of the remaining fragments, and they seem to be determined to make themselves less and less attractive. ("Come work for AT&T instead of Google and we'll allow you to spend several weeks each year training for strike duty for which you'll have to be prepared to show up on 48 hours notice, and, by the way, that vacation time you cannot take because you have to have to remain available cannot be carried over.") -- jpl On Fri, Jul 10, 2020 at 9:32 PM Larry McVoy wrote: > Well that sucks but Bell Labs has not been Bell Labs for a long time. > I think most of us here know what Bell Labs contributed to the world, > you youngsters who don't know, look it up, it is one of the greatest > research/business stories in history. > > On Fri, Jul 10, 2020 at 09:08:51PM -0400, John P. Linderman wrote: > > I'm hearing that 50% of what's left of AT&T research got the axe today. > > I'm hoping to hear from friends about details. > > God's gift to google, as we have said in the past. > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 12 01:36:35 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 11 Jul 2020 11:36:35 -0400 Subject: [TUHS] AT&T Research In-Reply-To: References: Message-ID: https://spinroot.com/pico/watertower.jpg On Fri, Jul 10, 2020 at 9:10 PM John P. Linderman wrote: > I'm hearing that 50% of what's left of AT&T research got the axe today. > I'm hoping to hear from friends about details. > God's gift to google, as we have said in the past. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sun Jul 12 06:30:20 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 12 Jul 2020 06:30:20 +1000 Subject: [TUHS] AT&T Research In-Reply-To: References: Message-ID: <20200711203020.GA1884@minnie.tuhs.org> On Sat, Jul 11, 2020 at 11:36:35AM -0400, Clem Cole wrote: > https://spinroot.com/pico/watertower.jpg So there's a question. Obviously all the anecdotes I've heard about Bell Labs have come from Unix people. But there were many others working and researching there. How was the interaction between the Unix people and the non-Unix people at the Labs? Especially when Unix became "big"? Did the non-Unix people also pull pranks like the watertower? Cheers, Warren From jon at fourwinds.com Sun Jul 12 06:36:50 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 11 Jul 2020 13:36:50 -0700 Subject: [TUHS] AT&T Research In-Reply-To: <20200711203020.GA1884@minnie.tuhs.org> References: <20200711203020.GA1884@minnie.tuhs.org> Message-ID: <202007112036.06BKaouX154046@darkstar.fourwinds.com> Warren Toomey writes: > On Sat, Jul 11, 2020 at 11:36:35AM -0400, Clem Cole wrote: > > https://spinroot.com/pico/watertower.jpg > > So there's a question. Obviously all the anecdotes I've heard about > Bell Labs have come from Unix people. But there were many others > working and researching there. > > How was the interaction between the Unix people and the non-Unix people > at the Labs? Especially when Unix became "big"? Did the non-Unix people > also pull pranks like the watertower? > > Cheers, Warren That's kind of a strange question. I was never a "UNIX person" when I was there because UNIX just wasn't that big a deal then (versions 3-6). I worked on other stuff, and used UNIX for documentation. I was intrigued and learned a lot more about it, and hung out in the UNIX room late at night because it was the place to be, but UNIX was a negligible blip compared to everything else going on there. Astonishingly enough, people worked on things related (even if tangentially) to telephony. Jon From robpike at gmail.com Sun Jul 12 07:58:01 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 12 Jul 2020 07:58:01 +1000 Subject: [TUHS] AT&T Research In-Reply-To: <20200711203020.GA1884@minnie.tuhs.org> References: <20200711203020.GA1884@minnie.tuhs.org> Message-ID: The interactions were great. Research at least was a multidisciplinary utopia, in my experience. People knew what was going on in other departments, talks were open to anyone who wanted to attend, and doors were always open. During my time there, I worked or at least had substantive conversations with mathematicians, physicists, statisticians, astronomers, acoustics researchers, and many others. Various eople in 1127 had longer-term collaborations with essentially every other group in Murray Hill at one time or another. It was an environment of sharing progress, ideas, and advancements. Not everyone played with the rest, and we didn't do as much work with development was management asked, but that world was very special. I miss it every day. But to answer your question: Yes, there were many pranks by many pranksters, but the water tower was undoubtedly the most visible. -rob On Sun, Jul 12, 2020 at 6:32 AM Warren Toomey wrote: > On Sat, Jul 11, 2020 at 11:36:35AM -0400, Clem Cole wrote: > > https://spinroot.com/pico/watertower.jpg > > So there's a question. Obviously all the anecdotes I've heard about > Bell Labs have come from Unix people. But there were many others > working and researching there. > > How was the interaction between the Unix people and the non-Unix people > at the Labs? Especially when Unix became "big"? Did the non-Unix people > also pull pranks like the watertower? > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Sun Jul 12 06:28:44 2020 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Sat, 11 Jul 2020 13:28:44 -0700 Subject: [TUHS] old Unix poster available Message-ID: <579d1ac2-2331-fcf6-c5bd-5d7e75d4cbc6@solar.stanford.edu> I have an old "Unix Feuds" poster (image attached). Anyone want it? I'll ship (free) to any reasonable address. Deborah -------------- next part -------------- A non-text attachment was scrubbed... Name: Unix_Feuds.jpg Type: image/jpeg Size: 97206 bytes Desc: not available URL: From jcapp at anteil.com Sun Jul 12 08:19:45 2020 From: jcapp at anteil.com (Jim Capp) Date: Sat, 11 Jul 2020 18:19:45 -0400 Subject: [TUHS] old Unix poster available In-Reply-To: <579d1ac2-2331-fcf6-c5bd-5d7e75d4cbc6@solar.stanford.edu> References: <579d1ac2-2331-fcf6-c5bd-5d7e75d4cbc6@solar.stanford.edu> Message-ID: <038531B6-F706-49F2-85B5-6EE722A5711F@anteil.com> I’d love that! Jim Capp 515 Park Ter Harrisburg PA 17111 > On Jul 11, 2020, at 6:07 PM, Deborah Scherrer wrote: > > I have an old "Unix Feuds" poster (image attached). Anyone want it? I'll ship (free) to any reasonable address. > > Deborah > From lm at mcvoy.com Sun Jul 12 08:29:35 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 11 Jul 2020 15:29:35 -0700 Subject: [TUHS] AT&T Research In-Reply-To: References: <20200711203020.GA1884@minnie.tuhs.org> Message-ID: <20200711222935.GU29318@mcvoy.com> On Sun, Jul 12, 2020 at 07:58:01AM +1000, Rob Pike wrote: > Not everyone played with the rest, and we didn't do as much work with > development was management asked, but that world was very special. I miss > it every day. I'm super jealous of your experiences there. I've told anyone who would listen that Bell Labs held more of what I'd call my heroes than any other place. I went to Sun because it was as close as I could get in my day, and it was good, but Bell Labs seems like it was magic. From dscherrer at solar.stanford.edu Sun Jul 12 08:35:43 2020 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Sat, 11 Jul 2020 15:35:43 -0700 Subject: [TUHS] old Unix poster available In-Reply-To: <038531B6-F706-49F2-85B5-6EE722A5711F@anteil.com> References: <579d1ac2-2331-fcf6-c5bd-5d7e75d4cbc6@solar.stanford.edu> <038531B6-F706-49F2-85B5-6EE722A5711F@anteil.com> Message-ID: OK, it's your. Will send. And thanks for taking it! Deborah On 7/11/20 3:19 PM, Jim Capp wrote: > I’d love that! > > Jim Capp > 515 Park Ter > Harrisburg PA 17111 > >> On Jul 11, 2020, at 6:07 PM, Deborah Scherrer wrote: >> >> I have an old "Unix Feuds" poster (image attached). Anyone want it? I'll ship (free) to any reasonable address. >> >> Deborah >> From doug at cs.dartmouth.edu Sun Jul 12 12:22:55 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 11 Jul 2020 22:22:55 -0400 Subject: [TUHS] BTL pranks [was AT&T Research] Message-ID: <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> > Did the non-Unix people also pull pranks like the watertower? One of my favorites was by John Kelly, a Texas original, who refused the department-head perk of a rug so he could stamp his cigarettes out on the vinyl floor. John came from Visual and Acoustics Research, where digital signal processing pressed the frontiers of computing. Among his publications was the completely synthetic recording of "Daisy, Daisy" released circa 1963. Kelly electrified the computer center with a blockbuster prank a year or two before that. As was typical of many machine rooms, a loudspeaker hooked to the low-order bit of the accumulator played gentle white noise in the background. The noise would turn into a shriek when the computer got into a tight loop, calling the operators to put the program out of its misery. Out of the blue one day, the loudspeaker called for help more articulately: "Help, I'm caught in a loop. Help, I'm caught in a loop. ..." it intoned in a slow Texas drawl. News of the talking computer spread instantly and folks croweded into the machine room to marvel before the operators freed the poor prisoner. Doug From egbegb2 at gmail.com Sun Jul 12 17:55:27 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Sun, 12 Jul 2020 02:55:27 -0500 Subject: [TUHS] AT&T Research In-Reply-To: <20200711222935.GU29318@mcvoy.com> References: <20200711203020.GA1884@minnie.tuhs.org> <20200711222935.GU29318@mcvoy.com> Message-ID: 2020-07-12 Indian Hill, Columbus, Whippany, Holmdel, and other BTL sites worked on automating the Telephone system. A lot of the software was designed, implemented, and deployed into the telcos and AT&T Longlines on Unix. Operating telcos welcomed all Unix based systems. I worked on the NOC (Network Operating Center) in Bedminster, NJ, and the LMOS (Loop Maintenance Operations system) both of which were designed, implemented, and deployed using Unix as the operating system. Unix was a huge thing throughout the labs for developing solutions for the Telcos from 1976 onwards. I was at BTL from 1976-1983 and traveled to Murray Hill often. I met and engaged with many of the folks (Feldman, Chesson, Aho, Bourne, Thompson, Ritchie, Lesk, Weinberger, and even Doug). All of them were welcoming and extremely patient with me and to this day I remember all of them. Unix was a godsend to me after having to deal with IBM operating systems for scientific calculations. I arrived into BTL in 1976 in Columbus, Ohio and all I had ever used before was punched cards and OS/360 systems. (cbunix uber alles :-). "Messages" and "semaphores" were what was in the Unix (cbunix) we used and I don't recall who implemented them.("Messages" was interprocess messages. I even forget how they worked, but using "messages", I implemented inter-processor messages where processes on one computer could msg processes on a 2nd computer without any modification to the Unix source code.) The most depressing thing even to today is the deplorable lack of wisdom demonstrated by IBM, Microsoft, and AT&T in bringing computing to the public. LSX could have been deployed on the first IBM PC (1982). I suspect IBM and its vaunted research lab and Gates/Allen were singularly ignorant of the revolutionary ideas from 1127 even in 1981. AT&T was complicit by holding Unix close to its chest (in search of profit) while enjoying a government protected monopoly. Indeed, after spending 17 years in IBM, it is more than likely IBM was arrogant and dismissive of 'unix' (as was DEC - Digital Equipment Corporation) and especially the C programming language. One only needs to look at the source code of AIX to see that all of Doug's "principals" were missing and presumed dead in the IBM AIX software culture. No software invention in the world of computing compares to what Ken, Dennis and 1127 folks have given the world. Now, 50 years later, the world is embracing Unix. There is a political story here about excellence and profit and how they relate; not to be told by me, here. Ed PS: I spent approximately 2 hours trying to get the presentation of this post to look like what I produced in gvim (vi = Bill Joy). All formatting WORK is a direct result of Bill Gates (and Steve Jobs) not understanding or listening to Doug and his principles of text, simplicity, and pipes. On Sat, Jul 11, 2020 at 5:30 PM Larry McVoy wrote: > On Sun, Jul 12, 2020 at 07:58:01AM +1000, Rob Pike wrote: > > Not everyone played with the rest, and we didn't do as much work with > > development was management asked, but that world was very special. I miss > > it every day. > > I'm super jealous of your experiences there. I've told anyone who would > listen that Bell Labs held more of what I'd call my heroes than any other > place. > > I went to Sun because it was as close as I could get in my day, and it was > good, but Bell Labs seems like it was magic. > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sun Jul 12 21:58:11 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 12 Jul 2020 11:58:11 +0000 Subject: [TUHS] Monitoring by loudspeaker (was: BTL pranks) In-Reply-To: <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> References: <20200711203020.GA1884@minnie.tuhs.org> <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> Message-ID: <738ab925-586b-4921-b891-a4ec20348d4c@localhost> (This should probably be on COFF because I don't think this has much to do with UNIX.) On 11 Jul 2020 22:22 -0400, from doug at cs.dartmouth.edu (Doug McIlroy): > a loudspeaker hooked to the low-order bit of the accumulator played > gentle white noise in the background. The noise would turn into a > shriek when the computer got into a tight loop, How did that work? I can see how tying the low-order bit of the accumulator to a loudspeaker would generate white noise as the computer is doing work; but I fail to see how doing so would even somewhat reliably generate a shrieking sound when the computer is in a tight loop. Please, enlighten me. :-) -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From crossd at gmail.com Sun Jul 12 23:25:34 2020 From: crossd at gmail.com (Dan Cross) Date: Sun, 12 Jul 2020 09:25:34 -0400 Subject: [TUHS] Monitoring by loudspeaker (was: BTL pranks) In-Reply-To: <738ab925-586b-4921-b891-a4ec20348d4c@localhost> References: <20200711203020.GA1884@minnie.tuhs.org> <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> <738ab925-586b-4921-b891-a4ec20348d4c@localhost> Message-ID: On Sun, Jul 12, 2020 at 7:59 AM Michael Kjörling wrote: > (This should probably be on COFF because I don't think this has much > to do with UNIX.) > > > On 11 Jul 2020 22:22 -0400, from doug at cs.dartmouth.edu (Doug McIlroy): > > a loudspeaker hooked to the low-order bit of the accumulator played > > gentle white noise in the background. The noise would turn into a > > shriek when the computer got into a tight loop, > > How did that work? I can see how tying the low-order bit of the > accumulator to a loudspeaker would generate white noise as the > computer is doing work; but I fail to see how doing so would even > somewhat reliably generate a shrieking sound when the computer is in a > tight loop. Please, enlighten me. :-) > I would imagine a cap as a low-pass filter and a transistor as a poor-man's analog comparator triggering a tape player on loop. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuz at fuz.su Mon Jul 13 00:58:22 2020 From: fuz at fuz.su (Robert Clausecker) Date: Sun, 12 Jul 2020 16:58:22 +0200 Subject: [TUHS] Monitoring by loudspeaker (was: BTL pranks) In-Reply-To: <738ab925-586b-4921-b891-a4ec20348d4c@localhost> References: <20200711203020.GA1884@minnie.tuhs.org> <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> <738ab925-586b-4921-b891-a4ec20348d4c@localhost> Message-ID: <20200712145822.GA72854@fuz.su> When the computer is in a tight endless loop, the accumulator takes the same series of values every time it's in the loop. Thus, instead of white noise you get a sound whose frequency is the clock frequency of the machine divided by the number of cycles spent by one loop iteration. That's how you know that the machine is stuck in an endless loop: if it was doing something useful, the values would change every iteration and you would get white noise again. Yours, Robert C On Sun, Jul 12, 2020 at 11:58:11AM +0000, Michael Kjörling wrote: > (This should probably be on COFF because I don't think this has much > to do with UNIX.) > > > On 11 Jul 2020 22:22 -0400, from doug at cs.dartmouth.edu (Doug McIlroy): > > a loudspeaker hooked to the low-order bit of the accumulator played > > gentle white noise in the background. The noise would turn into a > > shriek when the computer got into a tight loop, > > How did that work? I can see how tying the low-order bit of the > accumulator to a loudspeaker would generate white noise as the > computer is doing work; but I fail to see how doing so would even > somewhat reliably generate a shrieking sound when the computer is in a > tight loop. Please, enlighten me. :-) > > -- > Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From aek at bitsavers.org Mon Jul 13 02:09:56 2020 From: aek at bitsavers.org (Al Kossow) Date: Sun, 12 Jul 2020 09:09:56 -0700 Subject: [TUHS] Monitoring by loudspeaker In-Reply-To: <20200712145822.GA72854@fuz.su> References: <20200711203020.GA1884@minnie.tuhs.org> <202007120222.06C2MtdJ140032@tahoe.cs.Dartmouth.EDU> <738ab925-586b-4921-b891-a4ec20348d4c@localhost> <20200712145822.GA72854@fuz.su> Message-ID: <8cf76d2d-c598-9c5c-3bcc-8b3e0518e313@bitsavers.org> On 7/12/20 7:58 AM, Robert Clausecker wrote: > That's how you know that the machine is stuck in an endless loop: if it > was doing something useful, the values would change every iteration and > you would get white noise again. Computers are capable of generating PWM speech with a single bit output https://www.youtube.com/watch?v=IIejqWEV_8w is an example on the Apple II or multi-voice music using multiple bits https://www.youtube.com/watch?v=dTaVffknxEY the sound is not 'white noise' which implies totally random output any loop in the code will produce a unique sound when it is running From rdm at cfcl.com Mon Jul 13 06:10:15 2020 From: rdm at cfcl.com (Rich Morin) Date: Sun, 12 Jul 2020 13:10:15 -0700 Subject: [TUHS] Fwd: Monitoring by loudspeaker References: <8cf76d2d-c598-9c5c-3bcc-8b3e0518e313@bitsavers.org> Message-ID: <58A78A18-4CD1-4338-A49F-CA2140070328@cfcl.com> On the CDC 3800, the top three bits of the accumulator were scaled and summed by a set of three resistors, then fed into the console speaker. Generally, this produced noise of very little interest (except to indicate that the machine was running). However, when I ran my Shellsort (https://en.wikipedia.org/wiki/Shellsort ), the speaker made a very distinctive sound. It was a series of rising tones whose durations got shorter and shorter. Something like Vwooooooooooop, Vwooooooop, Vwooooop, Vroop, ... -r -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Jul 13 06:38:56 2020 From: norman at oclsc.org (Norman Wilson) Date: Sun, 12 Jul 2020 16:38:56 -0400 Subject: [TUHS] AT&T Research Message-ID: <1594586339.4851.for-standards-violators@oclsc.org> John Linderman: Every "divestiture" had an adverse effect on critical mass. The split between AT&T and Bellcore was a big hurt. The split between AT&T and Lucent was another. When I joined the Labs in 1973, it was an honor to work there. ==== Maybe I'm blinded because I wasn't there earlier, but to me, joining Bell Labs in 1984, just after the original divestiture that split off Bellcore, was still an honour. There were certainly good people I never had a chance to work with because they went to Bellcore, but in 1127 at least, morale was good, management stayed out of our way and encouraged researchers to work on whatever interested them, and a lot of good work was done even if that group was no longer the source of All UNIX Truth. (In fact I think we missed the boat on some things by being too inwardly-focussed, TCP/IP in particular, but divestiture didn't cause that.) It seemed to me that the rot didn't really begin to show until around 1990, the time I left (though not for that reason; this is hindsight). Upper management were visibly shifting focus from encouraging researchers to do what they did best to treating researchers as a source of new products to be marketed. The urge to break the company up further seems to me to have been a symptom, not a cause; the cause was a general corporate shift toward short-term profits rather than AT&T's traditional long-term view. AT&T was far from alone in making this mistake, and research in the US has suffered greatly all over as a result. I remember visiting a couple of years after I left, and chatting with my former department head. He said 1127 was having trouble convincing new researchers to join up because they'd heard (correctly) that the physics and chemistry research groups were being cut back, and feared computing science would have its own reckoning soon enough. In fact the corporate direction of the time was to cut back on the physical sciences and push to expand software research and development, but I don't blame the new researchers for being concerned (nor did my ex-DH), and in the long term they turned out to be more right than wrong. Nothing lasts forever, but the classic Bell Labs lasted a long time. We have nothing like it now. I don't think we'll have anything like it any time soon. That's sad. Norman Wilson Toronto ON From dave at horsfall.org Tue Jul 14 12:52:37 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 14 Jul 2020 12:52:37 +1000 (EST) Subject: [TUHS] v7 uucp debugging help requested In-Reply-To: References: <202007061919.066JJ51w031385@freefriends.org> Message-ID: On Thu, 9 Jul 2020, Warner Losh wrote: > He looked at it and muttered, “Oh, you have to end it with a > slash? > When I wrote this for CTSS, you didn’t need to do that.” > > > Kids today.... get off my damn regex...  even turning couldn't complete this > lot. Bah I can see that a lot of people havent used CDC gear :-) s:/old//new/ -- Dave From imp at bsdimp.com Wed Jul 15 08:53:46 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 14 Jul 2020 16:53:46 -0600 Subject: [TUHS] 2.11BSD Update Message-ID: I've managed to reach an important milestone in my efforts to recreate 2.11BSD pl 0 from sources. I've managed to unwind the patches, recreated some programs that were lost (the patches destroyed data and weren't modern context diffs). So I've managed to unwind back to pl 0, I've managed to bootstrap the assembler (it wouldn't build on pl 195), recreate ld, ranlib and ar. I've rebuilt the libraries and many binaries. https://bsdimp.blogspot.com/2020/07/211bsd-original-tapes-recreation.html No tapes yet, but I thought people here would like to know. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Jul 15 16:36:17 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 15 Jul 2020 06:36:17 +0000 Subject: [TUHS] 2.11BSD Update In-Reply-To: (Warner Losh's message of "Tue, 14 Jul 2020 16:53:46 -0600") References: Message-ID: <7w8sflb7z2.fsf@junk.nocrew.org> Warner Losh wrote: > I've managed to reach an important milestone in my efforts to recreate > 2.11BSD pl 0 from sources. I've managed to unwind the patches, > recreated some programs that were lost (the patches destroyed data and > weren't modern context diffs). Having done some similar things, I really appreciate the effort that went into this. Congratulations! From arnold at skeeve.com Thu Jul 16 02:45:45 2020 From: arnold at skeeve.com (Arnold Robbins) Date: Wed, 15 Jul 2020 19:45:45 +0300 Subject: [TUHS] 1993 book on Mach programming available for shipping Message-ID: Hi All. I have a copy of https://www.amazon.com/Programming-Under-Mach-UNIX-systems/dp/0201527391/ref=sr_1_2?dchild=1&keywords=programming+under+mach&qid=1594831478&sr=8-2 For the cost of shipping from Israel, to the first one who wants it. Let me know. Thanks, Arnold From dugo at xs4all.nl Thu Jul 16 04:37:56 2020 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 15 Jul 2020 20:37:56 +0200 Subject: [TUHS] 2.11BSD Update In-Reply-To: References: Message-ID: On 2020-07-15 00:53, Warner Losh wrote: > No tapes yet, but I thought people here would like to know. From back when digging into this I vaguely recall there was corruption in the pl 0 tapes. Maybe you are on the brink of finding out why there are no pl 0 tapes ;) /Jacob From gregg.drwho8 at gmail.com Thu Jul 16 07:13:58 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 15 Jul 2020 17:13:58 -0400 Subject: [TUHS] 1993 book on Mach programming available for shipping In-Reply-To: References: Message-ID: Hello! Um Arnold if I provide my address under private cover, could you tell me how many shekels it would cost me to cover the postage from where you are to where I am? Amazon wants an interesting price for the book. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Jul 15, 2020 at 1:02 PM Arnold Robbins wrote: > > Hi All. > > I have a copy of > https://www.amazon.com/Programming-Under-Mach-UNIX-systems/dp/0201527391/ref=sr_1_2?dchild=1&keywords=programming+under+mach&qid=1594831478&sr=8-2 > > For the cost of shipping from Israel, to the first one who wants it. > > Let me know. > > Thanks, > > Arnold From imp at bsdimp.com Thu Jul 16 10:35:55 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 15 Jul 2020 18:35:55 -0600 Subject: [TUHS] 2.11BSD Update In-Reply-To: References: Message-ID: On Wed, Jul 15, 2020 at 12:39 PM Jacob Goense wrote: > On 2020-07-15 00:53, Warner Losh wrote: > > No tapes yet, but I thought people here would like to know. > > From back when digging into this I vaguely recall there was > corruption in the pl 0 tapes. Maybe you are on the brink of > finding out why there are no pl 0 tapes ;) > You may be on to something. Patch 40, sent on Christmas day 1991, says: Several files in the /usr/src/games hierarchy are corrupt. This likely happened about a year ago when the master tapes were being created on a system which had suffered a hardware problem (disc controller and/or memory). The affected files are: /usr/src/games/mille/end.c /usr/src/games/banner.c /usr/src/games/warp/{sig.c,smap.1,smp.5} If you have earlier 2.10.1BSD tapes the files may be recovered from them as the above files have not changed. About 9 months later, around September 9, 1992, patch 80 was released, which was just a remastering of all the patches to date: A master update kit has been created which will bring a base 2.11BSD distribution up to the current revision level (#78). There is one later patch (#79) which is a trivial update to 'tftp', but it was made after this kit and so was not included. (there's references to this coming kit in patch 72, released in late August too). Since 2.11BSD was released in March 1991, this is 15 months after the initial release and would be all of the tapes made by USENIX going forward after that point. It's unclear if the USENIX tapes were remaster after patch 40 was issued 9 months after the original release or not (my reconstruction assumes that this corruption never happened, btw). This would give a small window in which to have ordered the tape to get an original, perhaps? The files from patch 80 are available (and I have them), but I haven't tried to see if they give me But my 'no tapes yet' comment was that I've not built bootable 2.11BSD as released/reconstructed tapes yet. I can't build the kernel. There's something wonky with my reconstruction of the kernel config. It's not consistent, and also fails to build a kernel that's small enough. But there's likely to be more sleepless nights during which to ponder this mystery. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Thu Jul 16 13:46:10 2020 From: jsteve at superglobalmegacorp.com (Jason) Date: Thu, 16 Jul 2020 03:46:10 +0000 (UTC) Subject: [TUHS] 1993 book on Mach programming available for shipping In-Reply-To: References: Message-ID: Seems like an interesting book. I might have to buy a copy regardless. Any other good Mach books to recommend? On Thu, Jul 16, 2020 at 1:02 AM +0800, "Arnold Robbins" wrote: Hi All. I have a copy of https://www.amazon.com/Programming-Under-Mach-UNIX-systems/dp/0201527391/ref=sr_1_2?dchild=1&keywords=programming+under+mach&qid=1594831478&sr=8-2 For the cost of shipping from Israel, to the first one who wants it. Let me know. Thanks, Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Jul 16 14:17:06 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 15 Jul 2020 22:17:06 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks Message-ID: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Is it okay for me to ask a question about Linux that's from '91~'92? Does anyone happen to have copies of H.J. Lu's Bootable Root and the associated Linux Base System disk images from the early '90s? I've managed to find a copy of 0.98.pl5-31 bootable root disk. But I can't find any base disks to go along with it. The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and basedisk subdirectories. Unfortunately all of the mirrors I'm finding of tsx-11 are newer, have the basedisk directories, but no image files there in. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From davida at pobox.com Thu Jul 16 16:15:59 2020 From: davida at pobox.com (David Arnold) Date: Thu, 16 Jul 2020 16:15:59 +1000 Subject: [TUHS] 1993 book on Mach programming available for shipping In-Reply-To: References: Message-ID: <4500EBE0-2878-45EA-B041-084E2C09F9B0@pobox.com> Amit Singh’s “Mac OS X Internals: A Systems Approach” has a bunch of Mach content, as it applied to macOS around 2006. It’s pretty expensive though (maybe it’s priced by weight). d > On 16 Jul 2020, at 13:46, Jason wrote: > > Seems like an interesting book. > > I might have to buy a copy regardless. > > Any other good Mach books to recommend? > > > > On Thu, Jul 16, 2020 at 1:02 AM +0800, "Arnold Robbins" > wrote: > > Hi All. > > I have a copy of > https://www.amazon.com/Programming-Under-Mach-UNIX-systems/dp/0201527391/ref=sr_1_2?dchild=1&keywords=programming+under+mach&qid=1594831478&sr=8-2 > > For the cost of shipping from Israel, to the first one who wants it. > > Let me know. > > Thanks, > > Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu at toad.com Fri Jul 17 11:40:45 2020 From: gnu at toad.com (John Gilmore) Date: Thu, 16 Jul 2020 18:40:45 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: <13529.1594950045@hop.toad.com> > The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and > basedisk subdirectories. There's a copy of the tsx-11 archives in the Internet Archive here, along with 8 other archival CDs from Pacific HiTech, but it doesn't seem to include the directories you want: https://archive.org/details/OfficialRedHatCommercialLiNUXV3.0.3 The same item also has a copy of the old Sunsite archive on 4 CD images. Was there a mirror of H.J. Lu's early stuff in sunsite? Searching for "tsx-11" in the search box at the Internet Archive turns up half a dozen (typically CDROM .ISO) images of various copies of the tsx-11 archives. Unfortunately, the Internet Archive never directly crawled tsx-11.mit.edu, seemingly because it was never accessible via http? John From lm at mcvoy.com Fri Jul 17 11:59:14 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Jul 2020 18:59:14 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <13529.1594950045@hop.toad.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> Message-ID: <20200717015914.GA12704@mcvoy.com> I have to go look but I think I might have this on CD. I used to have a drawer full of install cds that went back to the 1990's. If I don't follow up, they are gone. On Thu, Jul 16, 2020 at 06:40:45PM -0700, John Gilmore wrote: > > The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and > > basedisk subdirectories. > > There's a copy of the tsx-11 archives in the Internet Archive here, > along with 8 other archival CDs from Pacific HiTech, but it doesn't > seem to include the directories you want: > > https://archive.org/details/OfficialRedHatCommercialLiNUXV3.0.3 > > The same item also has a copy of the old Sunsite archive on 4 CD images. > Was there a mirror of H.J. Lu's early stuff in sunsite? > > Searching for "tsx-11" in the search box at the Internet Archive > turns up half a dozen (typically CDROM .ISO) images of various copies > of the tsx-11 archives. > > Unfortunately, the Internet Archive never directly crawled tsx-11.mit.edu, > seemingly because it was never accessible via http? > > John > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Fri Jul 17 13:35:55 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Jul 2020 20:35:55 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717015914.GA12704@mcvoy.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> Message-ID: <20200717033555.GA18565@mcvoy.com> I looked, don't have it. There was a red 4 CD set, I want to say it was ImageMagick but that's the graphics program. It was a 4 cd set of at least one Linux distro and a boat load of open source stuff. It predated redhat so it was huge back in the day, way better to buy that than spend a bizillion days on ftp over a modem. H.J. Lu's stuff was on it. Does anyone know where he is? I can go look if that helps. On Thu, Jul 16, 2020 at 06:59:14PM -0700, Larry McVoy wrote: > I have to go look but I think I might have this on CD. I used to have > a drawer full of install cds that went back to the 1990's. If I don't > follow up, they are gone. > > On Thu, Jul 16, 2020 at 06:40:45PM -0700, John Gilmore wrote: > > > The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and > > > basedisk subdirectories. > > > > There's a copy of the tsx-11 archives in the Internet Archive here, > > along with 8 other archival CDs from Pacific HiTech, but it doesn't > > seem to include the directories you want: > > > > https://archive.org/details/OfficialRedHatCommercialLiNUXV3.0.3 > > > > The same item also has a copy of the old Sunsite archive on 4 CD images. > > Was there a mirror of H.J. Lu's early stuff in sunsite? > > > > Searching for "tsx-11" in the search box at the Internet Archive > > turns up half a dozen (typically CDROM .ISO) images of various copies > > of the tsx-11 archives. > > > > Unfortunately, the Internet Archive never directly crawled tsx-11.mit.edu, > > seemingly because it was never accessible via http? > > > > John > > > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From athornton at gmail.com Fri Jul 17 15:24:42 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 16 Jul 2020 22:24:42 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717033555.GA18565@mcvoy.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> Message-ID: I usually think of him and Theodore Ts'o in the same context (which is to say, tsx-11/MIT), so perhaps he would know? LinkedIn claims he's at Intel somewhere in the Bay area, but his employment there dates (LinkedIn claims) to 2003...so, possible, or maybe he just dropped off the radar sometime between then and now. Adam On Thu, Jul 16, 2020 at 8:36 PM Larry McVoy wrote: > I looked, don't have it. There was a red 4 CD set, I want to say it > was ImageMagick but that's the graphics program. It was a 4 cd set > of at least one Linux distro and a boat load of open source stuff. > > It predated redhat so it was huge back in the day, way better to > buy that than spend a bizillion days on ftp over a modem. > > H.J. Lu's stuff was on it. > > Does anyone know where he is? I can go look if that helps. > > On Thu, Jul 16, 2020 at 06:59:14PM -0700, Larry McVoy wrote: > > I have to go look but I think I might have this on CD. I used to have > > a drawer full of install cds that went back to the 1990's. If I don't > > follow up, they are gone. > > > > On Thu, Jul 16, 2020 at 06:40:45PM -0700, John Gilmore wrote: > > > > The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk > and > > > > basedisk subdirectories. > > > > > > There's a copy of the tsx-11 archives in the Internet Archive here, > > > along with 8 other archival CDs from Pacific HiTech, but it doesn't > > > seem to include the directories you want: > > > > > > https://archive.org/details/OfficialRedHatCommercialLiNUXV3.0.3 > > > > > > The same item also has a copy of the old Sunsite archive on 4 CD > images. > > > Was there a mirror of H.J. Lu's early stuff in sunsite? > > > > > > Searching for "tsx-11" in the search box at the Internet Archive > > > turns up half a dozen (typically CDROM .ISO) images of various copies > > > of the tsx-11 archives. > > > > > > Unfortunately, the Internet Archive never directly crawled > tsx-11.mit.edu, > > > seemingly because it was never accessible via http? > > > > > > John > > > > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Fri Jul 17 15:18:36 2020 From: random832 at fastmail.com (Random832) Date: Fri, 17 Jul 2020 01:18:36 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717033555.GA18565@mcvoy.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> Message-ID: <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> On Thu, Jul 16, 2020, at 23:35, Larry McVoy wrote: > I looked, don't have it. There was a red 4 CD set, I want to say it > was ImageMagick but that's the graphics program. It was a 4 cd set > of at least one Linux distro and a boat load of open source stuff. The CD collection was called InfoMagic, and when he posted his question on Twitter I was able to find a mirror here: http://grumbeer.dyndns.org/ftp/servers/sunsite/1994-06-28/GCC/basedisk/ As for the internet archive, the CD *might* be this one https://archive.org/details/cdrom-ldr-0694, these entries don't seem to be very well tagged or have listings of contents. From petr at titera.eu Fri Jul 17 15:23:16 2020 From: petr at titera.eu (=?UTF-8?Q?Petr_Tit=c4=9bra?=) Date: Fri, 17 Jul 2020 07:23:16 +0200 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717033555.GA18565@mcvoy.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> Message-ID: <48230b60-d64a-eded-c839-1322025c1448@titera.eu> It was InfoMagic and that set is Linux Developer Resources. You can find some releases of it on archive.org. I hunt it and similar sets to try to reconstruct Linux libc release history. But this is off topic for this list. Petr Titera Dne 17. 7. 2020 v 5:35 Larry McVoy napsal(a): > I looked, don't have it. There was a red 4 CD set, I want to say it > was ImageMagick but that's the graphics program. It was a 4 cd set > of at least one Linux distro and a boat load of open source stuff. > > It predated redhat so it was huge back in the day, way better to > buy that than spend a bizillion days on ftp over a modem. > > H.J. Lu's stuff was on it. > > Does anyone know where he is? I can go look if that helps. > > On Thu, Jul 16, 2020 at 06:59:14PM -0700, Larry McVoy wrote: >> I have to go look but I think I might have this on CD. I used to have >> a drawer full of install cds that went back to the 1990's. If I don't >> follow up, they are gone. >> >> On Thu, Jul 16, 2020 at 06:40:45PM -0700, John Gilmore wrote: >>>> The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and >>>> basedisk subdirectories. >>> >>> There's a copy of the tsx-11 archives in the Internet Archive here, >>> along with 8 other archival CDs from Pacific HiTech, but it doesn't >>> seem to include the directories you want: >>> >>> https://archive.org/details/OfficialRedHatCommercialLiNUXV3.0.3 >>> >>> The same item also has a copy of the old Sunsite archive on 4 CD images. >>> Was there a mirror of H.J. Lu's early stuff in sunsite? >>> >>> Searching for "tsx-11" in the search box at the Internet Archive >>> turns up half a dozen (typically CDROM .ISO) images of various copies >>> of the tsx-11 archives. >>> >>> Unfortunately, the Internet Archive never directly crawled tsx-11.mit.edu, >>> seemingly because it was never accessible via http? >>> >>> John >>> >> >> -- >> --- >> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > From gtaylor at tnetconsulting.net Fri Jul 17 15:30:15 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 16 Jul 2020 23:30:15 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: On 7/15/20 10:17 PM, Grant Taylor via TUHS wrote: > Does anyone happen to have copies of H.J. Lu's Bootable Root and the > associated Linux Base System disk images from the early '90s? I manged to find something after sending the email last night. But I'm having trouble accessing them. As such, I'm still interested to know if other people have a copy. I say trouble accessing them because the HJ 0.99pl7 Bootable Root disk can't mount the XiaFS base disk images. Further, when I try to mount them from Slackware 3.1 ('96) after loading the XiaFS module, things don't work correctly. df shows that there is different amounts of content on the three base disk images. But doing an ls on the mount point returns an error. (I don't have the error handy.) Someone responded to me on Twitter this morning with a link to some other files, but I've not yet had an opportunity to try them. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Jul 17 15:41:44 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 16 Jul 2020 23:41:44 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <48230b60-d64a-eded-c839-1322025c1448@titera.eu> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> Message-ID: <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> On 7/16/20 11:23 PM, Petr Titěra wrote: > But this is off topic for this list. Why is this off topic for this list? Is it because I'm trying to find software? Or is it because it's a question about Linux? I'd like to point out that I'm asking about software that is decidedly in the broad category of unix and unix like operating systems. Note the lower case u to avoid any licensing issues. Further, I'm asking about a unix (if you will) from 1991, which actually predates 2.11BSD from 1992. I suspect that Warner's discussions about 2.11BSD are decidedly on topic. So, I ask, why is this off topic for this list? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From petr at titera.eu Fri Jul 17 16:04:49 2020 From: petr at titera.eu (=?UTF-8?Q?Petr_Tit=c4=9bra?=) Date: Fri, 17 Jul 2020 08:04:49 +0200 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> Message-ID: <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> Dne 17. 7. 2020 v 7:41 Grant Taylor via TUHS napsal(a): > On 7/16/20 11:23 PM, Petr Titěra wrote: >> But this is off topic for this list. > > Why is this off topic for this list? > > Is it because I'm trying to find software?  Or is it because it's a > question about Linux? No, I consider my effort to reconstruct Linux libc release history as off topic communication. If someone think otherwise I would be wery glad. Petr Titera > > I'd like to point out that I'm asking about software that is decidedly > in the broad category of unix and unix like operating systems.  Note the > lower case u to avoid any licensing issues.  Further, I'm asking about a > unix (if you will) from 1991, which actually predates 2.11BSD from 1992. >  I suspect that Warner's discussions about 2.11BSD are decidedly on topic. > > So, I ask, why is this off topic for this list? > > > From amp1ron at gmail.com Fri Jul 17 23:12:31 2020 From: amp1ron at gmail.com (Ron Pool) Date: Fri, 17 Jul 2020 09:12:31 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> Message-ID: On 7/17/20, 1:28 AM, "TUHS on behalf of Random832" wrote: > On Thu, Jul 16, 2020, at 23:35, Larry McVoy wrote: > > I looked, don't have it. There was a red 4 CD set, I want to say it > > was ImageMagick but that's the graphics program. It was a 4 cd set > > of at least one Linux distro and a boat load of open source stuff. > > The CD collection was called InfoMagic, and when he posted his question on Twitter I was able to find a mirror here: > > http://grumbeer.dyndns.org/ftp/servers/sunsite/1994-06-28/GCC/basedisk/ > > As for the internet archive, the CD *might* be this one https://archive.org/details/cdrom-ldr-0694, these entries don't seem to be very well tagged or have listings of contents. FYI, you can get listings of contents of most ISOs, DMGs, ZIPs, etc that are on archive.org. If you visit an archive.org page like https://archive.org/details/cdrom-ldr-0694, then in the DOWNLOAD OPTIONS section you can click SHOW ALL and that will display a list of all files (including ISOs) that archive.org has squirrelled away, like this: Name Last modified Size Go to parent directory README 18-Dec-2012 01:48 8.8K cdrom-ldr-0694_archive.torrent 01-Sep-2016 14:02 26.8K cdrom-ldr-0694_files.xml 21-Jun-2020 06:17 1.6K cdrom-ldr-0694_meta.xml 21-Jun-2020 06:17 2.4K ldr_0694_disc1.iso (View Contents) 18-Dec-2012 01:43 637.4M ldr_0694_disc2.iso (View Contents) 18-Dec-2012 01:44 646.5M Click on one of the (View Contents) links to view a listing of all files in that archive. Works for at least .iso, .DMG, .zip, .tar. -- Ron From gtaylor at tnetconsulting.net Sat Jul 18 01:12:23 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 17 Jul 2020 09:12:23 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> Message-ID: <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> On 7/17/20 12:04 AM, Petr Titěra wrote: > No, I consider my effort to reconstruct Linux libc release history > as off topic communication. Interesting. Where can I learn more about your work efforts? > If someone think otherwise I would be wery glad. I'm decidedly not an authority on the matter. But I think there are some in the global Unix community that shun Linux, and things (directly) related to it because it's not a Unix descended from AT&T. Hence my comment in my original post. I would love to find a forum for Linux history like TUHS is for Unix history. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Sat Jul 18 03:19:16 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Jul 2020 10:19:16 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: <20200717171916.GG18565@mcvoy.com> On Fri, Jul 17, 2020 at 09:12:23AM -0600, Grant Taylor via TUHS wrote: > On 7/17/20 12:04 AM, Petr Tit?ra wrote: > >No, I consider my effort to reconstruct Linux libc release history as off > >topic communication. > > Interesting. Where can I learn more about your work efforts? > > >If someone think otherwise I would be wery glad. > > I'm decidedly not an authority on the matter. But I think there are some in > the global Unix community that shun Linux, and things (directly) related to > it because it's not a Unix descended from AT&T. Hence my comment in my > original post. > > I would love to find a forum for Linux history like TUHS is for Unix > history. Me too. For the record, I'm fine with Linux on this list but it is probably up to Warren to decide. I came from BSD roots, SunOS, but I've been using Linux since maybe 1994 or 95 as my daily desktop/laptop (and yes, it was pretty sketchy back then, I've been playing with Linux since before it had TCP/IP, it's gotten a lot better). I think there are some legit complaints about Linux but a lot of those could be said about BSD. Bell Labs Unix was very terse, they took less is more as far as you can. Linux was far more pragmatic, the Linux /proc is nothing like AT&T /proc, Linux is all strings and has tons of info and knobs that /proc didn't have. AT&T /proc is about processes and Linux /proc is a generic bunghole where you can see everything and control everything. It's a bit much but in general, I like the Linux /proc, it's pleasant being able to poke around without having the write a C program to grovel through the binary data structures. That said, /proc came from the time of 100mhz processors, the idea that you were going to parse all those strings probably gave people heartburn then. Now it is fine. From imp at bsdimp.com Sat Jul 18 03:26:03 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jul 2020 11:26:03 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: On Fri, Jul 17, 2020 at 9:13 AM Grant Taylor via TUHS wrote: > On 7/17/20 12:04 AM, Petr Titěra wrote: > > No, I consider my effort to reconstruct Linux libc release history > > as off topic communication. > > Interesting. Where can I learn more about your work efforts? > I'd like to know as well... > > If someone think otherwise I would be wery glad. > > I'm decidedly not an authority on the matter. But I think there are > some in the global Unix community that shun Linux, and things (directly) > related to it because it's not a Unix descended from AT&T. Hence my > comment in my original post. > > I would love to find a forum for Linux history like TUHS is for Unix > history. > I would too... The early days were fun to live through, but much of what I recall from the time isn't mentioned much, if at all, anymore. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From salewski at att.net Sat Jul 18 03:42:29 2020 From: salewski at att.net (salewski at att.net) Date: Fri, 17 Jul 2020 13:42:29 -0400 Subject: [TUHS] Linux on TUHS [was: H.J. Lu Bootable Root & Base System disks] In-Reply-To: <20200717171916.GG18565@mcvoy.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> <20200717171916.GG18565@mcvoy.com> Message-ID: <20200717174229.GH3712@att.net> On 2020-07-17 10:19:16, Larry McVoy spake thus: > For the record, I'm fine with Linux on this list but it is > probably up to Warren to decide. +1 -- ----------------------------------------------------------------- a l a n d. s a l e w s k i salewski at att.net 1024D/FA2C3588 EDFA 195F EDF1 0933 1002 6396 7C92 5CB3 FA2C 3588 ----------------------------------------------------------------- From spedraja at gmail.com Sat Jul 18 03:47:46 2020 From: spedraja at gmail.com (Sergio Pedraja) Date: Fri, 17 Jul 2020 19:47:46 +0200 Subject: [TUHS] Linux on TUHS [was: H.J. Lu Bootable Root & Base System disks] In-Reply-To: <20200717174229.GH3712@att.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> <20200717171916.GG18565@mcvoy.com> <20200717174229.GH3712@att.net> Message-ID: +1 too El vie., 17 jul. 2020 19:44, escribió: > On 2020-07-17 10:19:16, Larry McVoy spake thus: > > For the record, I'm fine with Linux on this list but it is > > probably up to Warren to decide. > > +1 > > > -- > ----------------------------------------------------------------- > a l a n d. s a l e w s k i salewski at att.net > 1024D/FA2C3588 EDFA 195F EDF1 0933 1002 6396 7C92 5CB3 FA2C 3588 > ----------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Jul 18 03:50:01 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 17 Jul 2020 10:50:01 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: > > I would too... The early days were fun to live through, but much of what I recall from the time isn't mentioned much, if at all, anymore. > I count Linux as a Unix. It certainly ACTS a lot more like one (and did from day one) than, say, early AIX. Early Linux was kind of where I came in, so I feel like I actually might have a bit to contribute if we’re talking about it here. Adam From norman at oclsc.org Sat Jul 18 04:08:31 2020 From: norman at oclsc.org (Norman Wilson) Date: Fri, 17 Jul 2020 14:08:31 -0400 (EDT) Subject: [TUHS] H.J. Lu Bootable Root & Base System disks Message-ID: <20200717180831.5D4AB43F88@lignose.oclsc.org> In my humble-but-correct opinion*, Linux and its origins fit into the general topic of UNIX history just as well as those of Research UNIX or BSD or SVr4.2.2.2.2.2.2.2 or SunOS or IRIX or Ultrix or Tru64-compaqted-HPSauce or whatever. It all stems from the same roots, despite the protestations of purists from all sides. Warren gets final say, of course, but to encourage him I will say: Ploooogie! Norman Wilson Toronto ON * One of Peter Weinberger's sayings that I still enjoy overusing. From cowan at ccil.org Sat Jul 18 04:14:50 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 17 Jul 2020 14:14:50 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717180831.5D4AB43F88@lignose.oclsc.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> Message-ID: On Fri, Jul 17, 2020 at 2:10 PM Norman Wilson wrote: > Warren gets final say, of course, but to encourage > him I will say: Ploooogie! > Is that the plural of Plugh? John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org One time I called in to the central system and started working on a big thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists came by, looked over my shoulder and said 'Oh, that happens to me too. Try hanging up and phoning in again.' --Beverly Erlebacher -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Jul 18 04:16:18 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 17 Jul 2020 12:16:18 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: At the risk of the probably deserved flames for replying to my own original post.... On 7/15/20 10:17 PM, Grant Taylor via TUHS wrote: > Is it okay for me to ask a question about Linux that's from '91~'92? It sounds like Linux, as a history / development there of, is generally on topic. Obviously pending comments from Warren. But I do think that we probably want to avoid turning this into a general Linux support forum. There are many of those already and we don't need yet another one. Just my 2¢ worth. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Sat Jul 18 04:19:17 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Jul 2020 11:19:17 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200717180831.5D4AB43F88@lignose.oclsc.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> Message-ID: <20200717181917.GJ18565@mcvoy.com> I agree but the purists will say linux is more like minux or other rewrites from scratch. All the other stuff listed below that isn't Linux, all traces back to v7, v6, etc. Given that Linux is so wide spread, yeah, it would be nice to have a place for old fuddy duddies like me to smack our gums and say "sonny boy, you and your fancy TCP/IP, a modem was good enough for me and it was uphill in both directions" :-) Actually, TCP/IP was awesome when we got it. Modems were better than nothing but they sucked until they were fast enough for SLIP. On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > In my humble-but-correct opinion*, Linux and its > origins fit into the general topic of UNIX history > just as well as those of Research UNIX or BSD or > SVr4.2.2.2.2.2.2.2 or SunOS or IRIX or Ultrix or > Tru64-compaqted-HPSauce or whatever. It all stems > from the same roots, despite the protestations of > purists from all sides. > > Warren gets final say, of course, but to encourage > him I will say: Ploooogie! > > Norman Wilson > Toronto ON > > * One of Peter Weinberger's sayings that I still > enjoy overusing. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From skogtun at gmail.com Sat Jul 18 05:46:08 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 17 Jul 2020 21:46:08 +0200 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: <580cb698-55d7-f5b5-71cd-231ef0d497d8@gmail.com> Grant Taylor via TUHS [17.07.2020 17:12]: > I'm decidedly not an authority on the matter. But I think there are > some in the global Unix community that shun Linux, and things (directly) > related to it because it's not a Unix descended from AT&T. Hence my > comment in my original post. Dennis Richie seemed to think Linux was a worthy descendant: -- Hilsen Harald From wkt at tuhs.org Sat Jul 18 05:53:58 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Jul 2020 05:53:58 +1000 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717180831.5D4AB43F88@lignose.oclsc.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> Message-ID: <20200717195358.GA14847@minnie.tuhs.org> On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > In my humble-but-correct opinion*, Linux and its > origins fit into the general topic of UNIX history.. > Warren gets final say, of course, but to encourage > him I will say: Ploooogie! I'm happy with it, you silly twisted boy, you. Cheers, Warren From lm at mcvoy.com Sat Jul 18 05:57:18 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Jul 2020 12:57:18 -0700 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195358.GA14847@minnie.tuhs.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> Message-ID: <20200717195718.GM18565@mcvoy.com> On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > In my humble-but-correct opinion*, Linux and its > > origins fit into the general topic of UNIX history.. > > Warren gets final say, of course, but to encourage > > him I will say: Ploooogie! > > I'm happy with it, you silly twisted boy, you. But +1 to Grant's point not to turn TUHS into a Linux support forum. Quite frankly, I'm old dude who relies on his kids to fix his phone and I can google and find answers to just about any Linux problem. So no need for that here. From athornton at gmail.com Sat Jul 18 06:00:27 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 17 Jul 2020 13:00:27 -0700 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: I think that "Where can I find a clean copy of an HJ Lu boot/root set?" is an acceptable-for-here Linux tech support question, to be honest. On Fri, Jul 17, 2020 at 12:58 PM Larry McVoy wrote: > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > > In my humble-but-correct opinion*, Linux and its > > > origins fit into the general topic of UNIX history.. > > > Warren gets final say, of course, but to encourage > > > him I will say: Ploooogie! > > > > I'm happy with it, you silly twisted boy, you. > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jul 18 06:04:22 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Jul 2020 13:04:22 -0700 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: <20200717200422.GN18565@mcvoy.com> Oh yeah, I wasn't talking about your post, your post was fine. I was thinking more like "Does anyone know how to get $DEVICE to work in ubuntu 5.13?". I think that is what Grant meant as well. Historical is great. On Fri, Jul 17, 2020 at 01:00:27PM -0700, Adam Thornton wrote: > I think that "Where can I find a clean copy of an HJ Lu boot/root set?" is > an acceptable-for-here Linux tech support question, to be honest. > > On Fri, Jul 17, 2020 at 12:58 PM Larry McVoy wrote: > > > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > > > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > > > In my humble-but-correct opinion*, Linux and its > > > > origins fit into the general topic of UNIX history.. > > > > Warren gets final say, of course, but to encourage > > > > him I will say: Ploooogie! > > > > > > I'm happy with it, you silly twisted boy, you. > > > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > > Quite frankly, I'm old dude who relies on his kids to fix his phone > > and I can google and find answers to just about any Linux problem. > > So no need for that here. > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From crossd at gmail.com Sat Jul 18 06:03:46 2020 From: crossd at gmail.com (Dan Cross) Date: Fri, 17 Jul 2020 16:03:46 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: On Fri, Jul 17, 2020 at 3:58 PM Larry McVoy wrote: > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. > "Back in my day, we had VAXen! And you couldn't carry them anywhere! And the disc drives weighed a hundred pounds! AND WE LIKED IT THAT WAY!" :-D - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Jul 18 06:07:11 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Jul 2020 06:07:11 +1000 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: <20200717200711.GA21567@minnie.tuhs.org> On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: > But +1 to Grant's point not to turn TUHS into a Linux support forum. Correct. It's all about Heritage on The Unix Heritage Society mailing list. Chat about the early days of Linux is fine; helping to get Wayland to work isn't (at least, not for another 20 years or so). Cheers, Warren From imp at bsdimp.com Sat Jul 18 06:12:46 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jul 2020 14:12:46 -0600 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717200711.GA21567@minnie.tuhs.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <20200717200711.GA21567@minnie.tuhs.org> Message-ID: On Fri, Jul 17, 2020, 2:08 PM Warren Toomey wrote: > On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > > Correct. It's all about Heritage on The Unix Heritage Society mailing list. > Chat about the early days of Linux is fine; helping to get Wayland to work > isn't (at least, not for another 20 years or so). > That's in line with the rest: I can't come here for FreeBSD or Illumos support either. But talking about how they forked, etc is fine. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sat Jul 18 06:08:35 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 17 Jul 2020 20:08:35 +0000 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> On 17 Jul 2020 12:57 -0700, from lm at mcvoy.com (Larry McVoy): > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: >> I'm happy with it, you silly twisted boy, you. > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. I agree. For topicality, I think it's reasonable to draw the line somewhere similar to what's already the case with the "true" unixes, if I'm allowed to use such a designation. As a rule of thumb, something along the lines of: if it's got a historical application (say, "how do I get UUCP running on this Linux installation designed to replicate a 1992 system?") then it's on topic; if it's solely about modern systems ("how do I get Wayland running with my Nvidia GeForce RTX 2060 Super?") then it's off topic. So, really, no significant change there. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From petr at titera.eu Sat Jul 18 06:16:52 2020 From: petr at titera.eu (=?UTF-8?Q?Petr_Tit=c4=9bra?=) Date: Fri, 17 Jul 2020 22:16:52 +0200 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: <16c5c149-3eb0-128c-4a99-baa5accbf87b@titera.eu> Dne 17. 7. 2020 v 19:26 Warner Losh napsal(a): > > > On Fri, Jul 17, 2020 at 9:13 AM Grant Taylor via TUHS > > wrote: > > On 7/17/20 12:04 AM, Petr Titěra wrote: > > No, I consider my effort to reconstruct Linux libc release history > > as off topic communication. > > Interesting.  Where can I learn more about your work efforts? > > > I'd like to know as well... >   I will post nearly same list I did send Grant off-list. This is what I have now (I can provide full listing): libc-5.4 - quite good coverage some versions only as a patch against previous version but I was able to find most original distribution source and binary archives libc-5.3 - most versions only as patch against older versions (this was short live series) libc-5.2 - not much of it was preserved on the net, again short lived series mostly patches but with wide gaps libc-5.1 - one of the shortest series (only 4 releases) again I have mostly patches libc-5.0 - first used ELF series. I have mostly diffs of it. with only one full release libc-4.8 - transitional release to ELF. there was only one version of it and I think it was never widely used in production. (you must be careful here as there is another libc4.8 series which is completely different) libc-4.7 - this was last official a.out series I've got most releases of it In addition to above I was even able to find CVS repository containing all changes from 4.6.27 to 5.4.46. Previous repository was unfortunately destroyed when computer of H.J.Lu crashed on April 6th 1994. Before version 4.7 thing get worse. These versions are oldest and they were not archived. Sometimes you can find bits of binaries of those versions in old Linux distributions but mostly on binary form. Another problem is that CDs started to be mass published only around 1993 and you will not find a lot of mirrors so old. libc-4.6 - I have only few full releases and just some bits like diffs of includes or release notes libc-4.5 - only some bits and patches. You can easily find CVS repository with commits of releases 4.5.7-4.5.19 (not development repository, just release by release pushed into CVS) as a side note same author created CVS repository of linux versions from LINUX_0_99_14 to LINUX_0_99_15I but these releases are quite easy to find libc-4.4 - again not much one full release and some bits libc-4.3 - one full release and some bits libc-4.2 - only some fixes from mailing lists libc-4.1 - it seem that I have source of it but nothing more Versions before 4.1 were released together with compiler libc-2.2 - only one release, nothing more libc-1.4 - I have some sources claiming to be package for gcc 1.4 from 1992 but I do not know its exact source (it contains copyright of DJ Delorie and I do not know if it was distributed with that copyright at that time). It seems to me that I found GCC binary for this library too but I was not able to test it. libc-0.12 - I do not know much about this version. I did not try to collect binutils for those libraries (I was mostly after sources) but as I tend to mirror whole tree I think I will get a lot of those too. Petr Titera > > > If someone think otherwise I would be wery glad. > > I'm decidedly not an authority on the matter.  But I think there are > some in the global Unix community that shun Linux, and things > (directly) > related to it because it's not a Unix descended from AT&T.  Hence my > comment in my original post. > > I would love to find a forum for Linux history like TUHS is for Unix > history. > > > I would too... The early days were fun to live through, but much of what > I recall from the time isn't mentioned much, if at all, anymore. > > Warner From clemc at ccc.com Sat Jul 18 06:19:41 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Jul 2020 16:19:41 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717200711.GA21567@minnie.tuhs.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <20200717200711.GA21567@minnie.tuhs.org> Message-ID: On Fri, Jul 17, 2020 at 4:08 PM Warren Toomey wrote: > On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > > Correct. It's all about Heritage on The Unix Heritage Society mailing list. > Chat about the early days of Linux is fine; helping to get Wayland to work > isn't (at least, not for another 20 years or so). > > Cheers, Warren > +1 works for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr at titera.eu Sat Jul 18 06:37:48 2020 From: petr at titera.eu (=?UTF-8?Q?Petr_Tit=c4=9bra?=) Date: Fri, 17 Jul 2020 22:37:48 +0200 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: Dne 17. 7. 2020 v 7:30 Grant Taylor via TUHS napsal(a): > On 7/15/20 10:17 PM, Grant Taylor via TUHS wrote: >> Does anyone happen to have copies of H.J. Lu's Bootable Root and the >> associated Linux Base System disk images from the early '90s? > > I manged to find something after sending the email last night.  But I'm > having trouble accessing them.  As such, I'm still interested to know if > other people have a copy. > > I say trouble accessing them because the HJ 0.99pl7 Bootable Root disk > can't mount the XiaFS base disk images.  Further, when I try to mount > them from Slackware 3.1 ('96) after loading the XiaFS module, things > don't work correctly.  df shows that there is different amounts of > content on the three base disk images.  But doing an ls on the mount > point returns an error.  (I don't have the error handy.) There were some inconsistencies with XiaFS at that time. See this note from release notes: NOTE: If you are using this rootdisk for the kernel 0.99 pl7 and xiafs. you should run "xfsck -a /dev/xxxxx" on your xiafs partitions after booting this rootdisk from the floppy drive first. After you have done that, YOU HAVE TO USE THE KERNEL ON THIS DISK TO ACCESS YOUR XIAFS PARTITIONS. Please read LILO docs for how to do it. You have to use the kernel built with Frank Xia's patch for 0.99 pl 7, which is appended below. THIS PATCH IS ONLY NEEDED BY THE KERNEL 0.99 pl 7. DON'T USE IT ON ANY OTHER KERNELS. Petr > > Someone responded to me on Twitter this morning with a link to some > other files, but I've not yet had an opportunity to try them. > > > From gtaylor at tnetconsulting.net Sat Jul 18 06:55:28 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 17 Jul 2020 14:55:28 -0600 Subject: [TUHS] Linux is on-topic In-Reply-To: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> Message-ID: <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> On 7/17/20 2:08 PM, Michael Kjörling wrote: > I agree. For topicality, I think it's reasonable to draw the line > somewhere Agree. I use the following questions as a litmus test, requiring both to be true. 1) Does it fall into the broad category of Unix or Unix like operating systems? 2) Is it old ~> historic? I use the "historic car" definition as a guideline for how old "old" is. Specifically 25 years old, or older. If both of those answers are "yes", then I figure that at worst, someone might ask "please take this topic to COFF or elsewhere. I figure that there's a little bit of wiggle room for other topics, but would not be surprised if I needed to justify why it belongs on TUHS vs COFF. E.g. trying to resurrect an ancient protocol used by . > similar to what's already the case with the "true" unixes, if I'm > allowed to use such a designation. Eh ... can I get something to wash that down? I'm "okay" with such designations if you will back them up with a hard definition of what qualifies or not. > As a rule of thumb, something along the lines of: if it's got a > historical application (say, "how do I get UUCP running on this > Linux installation designed to replicate a 1992 system?") then it's > on topic; if it's solely about modern systems ("how do I get Wayland > running with my Nvidia GeForce RTX 2060 Super?") then it's off topic. ACK -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From michael at kjorling.se Sat Jul 18 07:28:48 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 17 Jul 2020 21:28:48 +0000 Subject: [TUHS] Linux is on-topic In-Reply-To: <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> Message-ID: <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> On 17 Jul 2020 14:55 -0600, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS): >> similar to what's already the case with the "true" unixes, if I'm >> allowed to use such a designation. > > Eh ... can I get something to wash that down? > > I'm "okay" with such designations if you will back them up with a hard > definition of what qualifies or not. Well, that was sort of the point I tried to imply by my "if I'm allowed to use such a designation". It's hard to define precisely. For the moment, I think I'll go with "an operating system and associated userspace toolset that traces an unbroken source code lineage back to the original UNIX system". With the specific caveat that my intent was to go _beyond_ that, by including Unix derivatives such as Linux. Which, by the way, and also meeting your "25 years old or older" criteria, looks like it would also include every version (with the possible exception of the last version or so; that was 1995-1996) of A/UX. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From a.phillip.garcia at gmail.com Sat Jul 18 07:48:07 2020 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Fri, 17 Jul 2020 17:48:07 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <48230b60-d64a-eded-c839-1322025c1448@titera.eu> <2132473e-9059-7e3e-2090-efb9b7cfc9db@tnetconsulting.net> <8c447141-2c04-e12f-47de-b994853425c9@titera.eu> <1f239047-3ae0-9a4e-2e41-13b2ce69f566@tnetconsulting.net> Message-ID: On Fri, Jul 17, 2020, 1:27 PM Warner Losh wrote: > > I would love to find a forum for Linux history like TUHS is for Unix >> history. >> > > I would too... The early days were fun to live through, but much of what I > recall from the time isn't mentioned much, if at all, anymore. > > Warner > Those days were fun. I just went down memory lane with the book "Rebel Code" by Glyn Moody. Good stuff. How different those days were, for me at least. I was just a Linux advocate, enthusiast, and hobbyist until 2000 or so, when I started work as a sysadmin. Red Hat Enterprise Linux was not yet a thing. It was just Red Hat, i.e. just another distro, just one voice of many that were shaping the future of the OS. Nowadays, in the corporate world at least, Red Hat IS Linux, or rather, Linux is whatever Red Hat says it is. That isn't entirely a bad thing. Gentoo is great for my personal use, in the same way that FreeBSD is. But if I have to support a few hundred servers, I'd rather do it with vSphere, RHEL, and Ansible. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alec at sensi.org Sat Jul 18 07:56:59 2020 From: alec at sensi.org (Alexander Voropay) Date: Sat, 18 Jul 2020 00:56:59 +0300 Subject: [TUHS] Linux is on-topic Message-ID: IMMSMC the early Linux had problems with some old-good programs i.e. Sendmail. New-born Linux hesitated between POSIX-BSD-Solaris semantic i.e. in file-locking, pty, network interface binding e.t.c. >From the early Sendmail README: === Linux Something broke between versions 0.99.13 and 0.99.14 of Linux: the flock() system call gives errors. If you are running .14, you must not use flock. You can do this with -DHASFLOCK=0. Around the inclusion of bind-4.9.3 & linux libc-4.6.20, the initialization of the _res structure changed. If /etc/hosts.conf was configured as "hosts, bind" the resolver code could return "Name server failure" errors. This is supposedly fixed in later versions of libc (>= 4.6.29?), and later versions of sendmail (> 8.6.10) try to work around the problem. Some older versions (< 4.6.20?) of the libc/include files conflict with sendmail's version of cdefs.h. Deleting sendmail's version on those systems should be non-harmful, and new versions don't care. Sendmail assumes that libc has snprintf, which has been true since libc 4.7.0. If you are running an older version, you will need to use -DHASSNPRINTF=0 in the Makefile. If may be able to use -lbsd (which includes snprintf) instead of turning this off on versions of libc between 4.4.4 and 4.7.0 (snprintf improves security, so you want to use this if at all possible). NOTE ON LINUX & BIND: By default, the Makefiles for linux include header files in /usr/local/include and libraries in /usr/local/lib. If you've installed BIND on your system, the header files typically end up in the search path and you need to add "-lresolv" to the LIBS line in your Makefile. Really old versions may need to include "-l44bsd" as well (particularly if the link phase complains about missing strcasecmp, strncasecmp or strpbrk). Complaints about an undefined reference to `__dn_skipname' in domain.o are a sure sign that you need to add -lresolv to LIBS. Newer versions of linux are basically threaded BIND, so you may or may not see complaints if you accidentally mix BIND headers/libraries with virginal libc. If you have BIND headers in /usr/local/include (resolv.h, etc) you *should* be adding -lresolv to LIBS. Data structures may change and you'd be asking for a core dump. From a.phillip.garcia at gmail.com Sat Jul 18 09:31:32 2020 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Fri, 17 Jul 2020 19:31:32 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: On Fri, Jul 17, 2020, 6:43 PM Dan Cross wrote: > On Fri, Jul 17, 2020 at 3:58 PM Larry McVoy wrote: > >> Quite frankly, I'm old dude who relies on his kids to fix his phone >> and I can google and find answers to just about any Linux problem. >> So no need for that here. >> > > "Back in my day, we had VAXen! And you couldn't carry them anywhere! And > the disc drives weighed a hundred pounds! AND WE LIKED IT THAT WAY!" > > :-D > > - Dan C. > > Those VAXen weren't just colossal physically. What, with that huge address space, all the meticulous care that was put into making Unix small and beautiful went right out the window. Truly, it was the beginning of the end. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Jul 18 09:50:13 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 17 Jul 2020 17:50:13 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> Message-ID: On 7/16/20 11:18 PM, Random832 wrote: > The CD collection was called InfoMagic, and when he posted his question > on Twitter I was able to find a mirror here: > > http://grumbeer.dyndns.org/ftp/servers/sunsite/1994-06-28/GCC/basedisk/ Unfortunately, neither rootdisk that I've found, 0.98.pl5-31 nor 0.99.pl14, will access any of the basedisks that I've found. They will mount, df shows that there is data on them. But ls says that there's no "." file or I get an "XIA-FS: bad directory entry (dir.c 91)" error message. > As for the internet archive, the CD *might* be this one > https://archive.org/details/cdrom-ldr-0694, these entries don't seem > to be very well tagged or have listings of contents. I get the same type of errors from this disk too. I downloaded all the LDR that I could find on I.A. and looked through them. Only '94-06 has basedisk images on them. I have yet to be able to access any data on any basedisk sets. :-/ -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From rtomek at ceti.pl Sat Jul 18 13:34:00 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Sat, 18 Jul 2020 05:34:00 +0200 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: <20200718033359.GA15887@tau1.ceti.pl> On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > > In my humble-but-correct opinion*, Linux and its > > > origins fit into the general topic of UNIX history.. > > > Warren gets final say, of course, but to encourage > > > him I will say: Ploooogie! > > > > I'm happy with it, you silly twisted boy, you. > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. I think that perhaps some codewords should be adopted for various *nix flavours/implementations/reimplementations. For example: linux = frogboat. Nobody will ever come here to ask about fixing problem with this. And besides, I would really not mind if there was a single place where I could read something about frogboat and other dolls. Reusing this list for such purpose is ok for me, since I am already subscribed. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From cbbrowne at gmail.com Sun Jul 19 02:45:07 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Sat, 18 Jul 2020 12:45:07 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717195718.GM18565@mcvoy.com> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: On Fri, 17 Jul 2020 at 15:58, Larry McVoy wrote: > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > > In my humble-but-correct opinion*, Linux and its > > > origins fit into the general topic of UNIX history.. > > > Warren gets final say, of course, but to encourage > > > him I will say: Ploooogie! > > > > I'm happy with it, you silly twisted boy, you. > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. > I think back to those mouldy oldie days, and my set of early things were... - First got exposed to BSD 4.1 with MFCF extensions ('86) - Couldn't afford *real* hardware, so I tracked whatever could run on Atari ST, and the biggest improvement I was able to get there was to be able to run Bash, early GCC, and sundry GNU tools, where I couldn't spawn multiple processes, but there was still plenty of useful - Then followed the MiNT period (https://en.wikipedia.org/wiki/MiNT) where we accepted that MiNT is NOT TOS, but still lended a POSIX interface, only to be briefly overjoyed at the rename to "MiNT is NOW TOS" - First paid work on Unix ('93) involved SCO (where that was the debugging platform for some C code targeting VMS!); that was a platform where I was pretty overjoyed to discover I could run multiple terms on a single console. And found it odd when people thought this was a huge innovation of Linux... I'm not sure I have much that's extraordinarily interesting to say about MiNT, but I'd think that to be pretty on-topic for TUHS :-). -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Sun Jul 19 06:22:21 2020 From: erc at pobox.com (Ed Carp) Date: Sat, 18 Jul 2020 15:22:21 -0500 Subject: [TUHS] Linux is on-topic In-Reply-To: <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: Oh, boy, now you've got me started. I worked on A/UX at Apple back around 1992. I'd love to find a copy of that! On 7/17/20, Michael Kjörling wrote: > Which, by the way, and also meeting your "25 years old or older" > criteria, looks like it would also include every version (with the > possible exception of the last version or so; that was 1995-1996) of > A/UX. From imp at bsdimp.com Sun Jul 19 06:29:43 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 18 Jul 2020 14:29:43 -0600 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: On Sat, Jul 18, 2020, 2:23 PM Ed Carp wrote: > Oh, boy, now you've got me started. I worked on A/UX at Apple back > around 1992. I'd love to find a copy of that! > Google can find it, if you really need it. Warner On 7/17/20, Michael Kjörling wrote: > > > Which, by the way, and also meeting your "25 years old or older" > > criteria, looks like it would also include every version (with the > > possible exception of the last version or so; that was 1995-1996) of > > A/UX. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Sun Jul 19 12:31:00 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Sat, 18 Jul 2020 22:31:00 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: Hello! Wow. I actually met with the folks at Apple, here in NYC regarding that OS. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sat, Jul 18, 2020 at 4:31 PM Warner Losh wrote: > > > > On Sat, Jul 18, 2020, 2:23 PM Ed Carp wrote: >> >> Oh, boy, now you've got me started. I worked on A/UX at Apple back >> around 1992. I'd love to find a copy of that! > > > Google can find it, if you really need it. > > Warner > >> On 7/17/20, Michael Kjörling wrote: >> >> > Which, by the way, and also meeting your "25 years old or older" >> > criteria, looks like it would also include every version (with the >> > possible exception of the last version or so; that was 1995-1996) of >> > A/UX. From wobblygong at gmail.com Sun Jul 19 13:46:01 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 19 Jul 2020 15:46:01 +1200 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: I remember in the early 90s, just when I was needing to use computers, thus getting actively interested in them, reading an article in one of the Mac mags on A/UX and thinking, that and a top performing Macintosh! life couldn't get any sweeter! Almost thirty years later, worked my way through Mac, MS/PC DOS plus Windows, OS/2, Windows NT/2K,XP/7/8.1/10, Linux and running a few OSes now on virtual machines, and I'd still love to have that running. Though I suspect it'd be more in the background ... Wesley Parish On 7/19/20, Warner Losh wrote: > On Sat, Jul 18, 2020, 2:23 PM Ed Carp wrote: > >> Oh, boy, now you've got me started. I worked on A/UX at Apple back >> around 1992. I'd love to find a copy of that! >> > > Google can find it, if you really need it. > > Warner > > On 7/17/20, Michael Kjörling wrote: >> >> > Which, by the way, and also meeting your "25 years old or older" >> > criteria, looks like it would also include every version (with the >> > possible exception of the last version or so; that was 1995-1996) of >> > A/UX. >> > From gtaylor at tnetconsulting.net Sun Jul 19 14:42:19 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 18 Jul 2020 22:42:19 -0600 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> On 7/18/20 9:46 PM, Wesley Parish wrote: > I'd still love to have that running. I think I've seen articles about people running it running virtualization / emulation. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From lars at nocrew.org Sun Jul 19 17:32:48 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 19 Jul 2020 07:32:48 +0000 Subject: [TUHS] Linux is on-topic In-Reply-To: (Christopher Browne's message of "Sat, 18 Jul 2020 12:45:07 -0400") References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: <7w365o6jtr.fsf@junk.nocrew.org> Christopher Browne wrote: > - Then followed the MiNT period (https://en.wikipedia.org/wiki/MiNT) > where we accepted that MiNT is NOT TOS, but still lended a POSIX > interface Another MiNT user here. After that, I tried both NetBSD and Linux on a Falcon030. NetBSD wouldn't work, which may be why I keep to Linux now. From spedraja at gmail.com Sun Jul 19 19:54:16 2020 From: spedraja at gmail.com (Sergio Pedraja) Date: Sun, 19 Jul 2020 11:54:16 +0200 Subject: [TUHS] Linux is on-topic In-Reply-To: <20200717200711.GA21567@minnie.tuhs.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <20200717200711.GA21567@minnie.tuhs.org> Message-ID: El vie., 17 jul. 2020 22:08, Warren Toomey escribió: > On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > > Correct. It's all about Heritage on The Unix Heritage Society mailing list. > Chat about the early days of Linux is fine; helping to get Wayland to work > isn't (at least, not for another 20 years or so). > Absolutely right :-) Sergio -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Sun Jul 19 20:26:24 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Sun, 19 Jul 2020 06:26:24 -0400 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> Message-ID: On 2020-07-17 16:03, Dan Cross wrote: > "Back in my day, we had VAXen! And you couldn't carry them anywhere! And > the disc drives weighed a hundred pounds! AND WE LIKED IT THAT WAY!" > > :-D That's why DEC made also the MicroVAX. I had once a MVII/BA23 in my samsonite. Weird look at customs, but worked ;-) From mparson at bl.org Mon Jul 20 04:01:28 2020 From: mparson at bl.org (Michael Parson) Date: Sun, 19 Jul 2020 13:01:28 -0500 Subject: [TUHS] Linux is on-topic In-Reply-To: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> Message-ID: On 2020-07-18 23:42, Grant Taylor via TUHS wrote: > On 7/18/20 9:46 PM, Wesley Parish wrote: >> I'd still love to have that running. > > I think I've seen articles about people running it running > virtualization / emulation. As far as I've been able to find, there is only one emulator that can run A/UX, shoebill[0]. I've got a Mac Quadra 950 with a Workgroup Server 95 card in it in the garage that I've been planning on someday trying to get A/UX running on, but haven't found enough round tuits. Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), A/UX might work there. -- Michael Parson Pflugerville, TX KF5LGQ [0] https://github.com/emaculation/shoebill From paul.winalski at gmail.com Mon Jul 20 06:42:49 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 19 Jul 2020 16:42:49 -0400 Subject: [TUHS] MicroVAX architecture (was: Linux is on-topic) Message-ID: On 7/19/20, emanuel stiebler wrote: > > That's why DEC made also the MicroVAX. I had once a MVII/BA23 in my > samsonite. Weird look at customs, but worked ;-) > By the early 1980s it was apparent that some of the more complicated VAX instructions weren't worth the space they took up in firmware. Especially POLY and EMOD, which turned out to be both slower and less accurate than coding them up as subroutines. And the PL/I and COBOL compilers were implementing packed decimal using decimal shadowing. Chucking out those instructions and doing them by emulation in the OS freed up enough chip real estate to allow the remaining VAX architecture to be implemented on a chip. All the later VAXen supported only the MicroVAX subset architecture in hardware/firmware. I don't recall which was the last VAX to support the whole architecture in hardware/firmware. Perhaps the VAX 8200/8300 (Scorpio)? That was a single-board implementation. It could be paired with a high-end Evans & Sutherland 3D graphics monitor. DEC tried unsuccessfully to use that combination to compete with Apollo in the workstation market, but it was too little too late. One reviewer said that coupling the E&S graphics to the VAX 8200 was like turbocharging a lawn mower. Did Unix support that configuration, or was it VMS-only? -Paul W. From cowan at ccil.org Mon Jul 20 08:11:11 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 19 Jul 2020 18:11:11 -0400 Subject: [TUHS] MicroVAX architecture (was: Linux is on-topic) In-Reply-To: References: Message-ID: On Sun, Jul 19, 2020 at 4:43 PM Paul Winalski wrote: And the PL/I and COBOL > compilers were implementing packed decimal using decimal shadowing. > What is decimal shadowing? I see a few references to the term on line, but no explanations. Thanks. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org There are books that are at once excellent and boring. Those that at once leap to the mind are Thoreau's Walden, Emerson's Essays, George Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at inf.ed.ac.uk Mon Jul 20 09:32:07 2020 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Mon, 20 Jul 2020 00:32:07 +0100 (BST) Subject: [TUHS] CR delay for VT05 Message-ID: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Looking at the 6th edition man page tty(2), I see Carriage-return delay type 1 lasts about .08 seconds and is suitable for the Terminet 300. Delay type 2 lasts about .16 seconds and is suitable for the VT05 and the TI 700. Delay type 3 is unimplemented and is 0. New-line delay type 1 is dependent on the current column and is tuned for Teletype model 37's. Type 2 is useful for the VT05 and is about .10 seconds. Type 3 is unimplemented and is 0. Why would the VT05 (a VDU) need a delay for carriage return? I can just about imagine that it might need one for linefeed if it shifted the characters in memory. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From erc at pobox.com Mon Jul 20 10:24:12 2020 From: erc at pobox.com (Ed Carp) Date: Sun, 19 Jul 2020 19:24:12 -0500 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: I look about once a year. Haven't found it yet. :(

Virus-free. www.avast.com
On 7/18/20, Warner Losh wrote: > On Sat, Jul 18, 2020, 2:23 PM Ed Carp wrote: > >> Oh, boy, now you've got me started. I worked on A/UX at Apple back >> around 1992. I'd love to find a copy of that! >> > > Google can find it, if you really need it. > > Warner > > On 7/17/20, Michael Kjörling wrote: >> >> > Which, by the way, and also meeting your "25 years old or older" >> > criteria, looks like it would also include every version (with the >> > possible exception of the last version or so; that was 1995-1996) of >> > A/UX. >> > From erc at pobox.com Mon Jul 20 12:55:32 2020 From: erc at pobox.com (Ed Carp) Date: Sun, 19 Jul 2020 21:55:32 -0500 Subject: [TUHS] A/UX Message-ID: Thanks to all who responded!! From random832 at fastmail.com Mon Jul 20 14:28:09 2020 From: random832 at fastmail.com (Random832) Date: Mon, 20 Jul 2020 00:28:09 -0400 Subject: [TUHS] CR delay for VT05 In-Reply-To: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> References: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Message-ID: <798e20fd-addf-4f9a-a4f9-b3dabb8ebe3c@www.fastmail.com> On Sun, Jul 19, 2020, at 19:32, Richard Tobin wrote: > Looking at the 6th edition man page tty(2), I see > > Carriage-return delay type 1 lasts about .08 seconds and is > suitable for the Terminet 300. Delay type 2 lasts about .16 > seconds and is suitable for the VT05 and the TI 700. Delay > type 3 is unimplemented and is 0. > > New-line delay type 1 is dependent on the current column and > is tuned for Teletype model 37's. Type 2 is useful for the > VT05 and is about .10 seconds. Type 3 is unimplemented and > is 0. > > Why would the VT05 (a VDU) need a delay for carriage return? > I can just about imagine that it might need one for linefeed > if it shifted the characters in memory. According to the VT05 manual, it only required a line feed delay [and other functions, most of which other than erase screen had in common that they moved or could move the cursor's vertical position] and only needed about .02 seconds ["slightly greater than one full cycle of the AC line", and the examples given were 1 character per 600 baud] https://vt100.net/docs/vt05-rm/chapter2.html From arnold at skeeve.com Mon Jul 20 18:47:08 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Jul 2020 02:47:08 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> Message-ID: <202007200847.06K8l8DF026646@freefriends.org> ISTR that A/UX was nothing special as a Unix. Am I failing to remember? I had had a DMD 5620 at my job, and after I moved to a different place and requested one, they graced me with a Macintosh. It could sort of do multiple windows, but it was like having a piper cub after being used to a 747. Other interesting bits for the Mac to maybe recover would be Mach Ten, which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) There was also a Mach/Linux that I think ran on the Mac at some point. Arnold Michael Parson wrote: > On 2020-07-18 23:42, Grant Taylor via TUHS wrote: > > On 7/18/20 9:46 PM, Wesley Parish wrote: > >> I'd still love to have that running. > > > > I think I've seen articles about people running it running > > virtualization / emulation. > > As far as I've been able to find, there is only one emulator that can > run A/UX, shoebill[0]. > > I've got a Mac Quadra 950 with a Workgroup Server 95 card in it in the > garage that I've been planning on someday trying to get A/UX running on, > but haven't found enough round tuits. > > Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE > (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), > A/UX might work there. > > -- > Michael Parson > Pflugerville, TX > KF5LGQ > > [0] https://github.com/emaculation/shoebill From andreww591 at gmail.com Mon Jul 20 19:48:29 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Mon, 20 Jul 2020 03:48:29 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <202007200847.06K8l8DF026646@freefriends.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: On 7/19/20, Michael Parson wrote: > > Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE > (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), > A/UX might work there. > Basilisk will never run anything other than Mac OS, not because it lacks an MMU, but because it HLEs everything other than the CPU, patching the Mac OS ROM to call drivers implemented on the host. A better idea would be to fix MAME's NCR 5380 SCSI device model to work properly, because AFAIK that's the only thing that stops it from running A/UX. I did look at it a bit quite a while ago, but had other stuff to work on, so it fell by the wayside for me. On 7/20/20, arnold at skeeve.com wrote: > ISTR that A/UX was nothing special as a Unix. Am I failing to remember? > > I had had a DMD 5620 at my job, and after I moved to a different place > and requested one, they graced me with a Macintosh. It could sort of > do multiple windows, but it was like having a piper cub after being > used to a 747. > > Other interesting bits for the Mac to maybe recover would be Mach Ten, > which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) > There was also a Mach/Linux that I think ran on the Mac at some point. > A/UX runs Mac OS as a Unix process (its default GUI is Mac OS although it does also support a traditional X server), making it the opposite of MachTen. It has considerable integration between Mac OS and Unix, and supports "hybrid" programs (Unix programs that make Mac OS system calls and Mac OS programs that make Unix system calls) (which I don't think MachTen supports, but I'm not completely sure of that). It is one of only two Unices that I'm aware of that runs another OS in a process to provide its main GUI (the other is a much more recent Linux distribution that runs AROS; I'm not counting things like running Windows under Merge or VP/IX because those were usually used in addition to X11). From arno.griffioen at ieee.org Mon Jul 20 19:46:48 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Mon, 20 Jul 2020 11:46:48 +0200 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <202007200847.06K8l8DF026646@freefriends.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: <20200720094648.GE15253@ancienthardware.org> On Mon, Jul 20, 2020 at 02:47:08AM -0600, arnold at skeeve.com wrote: > ISTR that A/UX was nothing special as a Unix. Am I failing to remember? No, that's absolutely true. It was a fairly plain-jane SVR2.2 with some back-ported bits from SVR3 (and perhaps some SVR4?), mostly for networking and filesystem work. However, it's an interesting setup in the fact how it ran the a normal MacOS instance basically 'virtualised' next to it and allowed some limited interaction between the two. Also the Mac IIfx was basically desgined and built for AU/X and had on-board hardware that was way over-specced for plain MacOS. The hardware really was more UNIX workstation than Mac. Eg. it had full DMA support on most I/O and such.. Unheard of on simpler macs and not even used by MacOS of the day which simply ignored that an ran everything in PIO mode happily. Mid 90's I did a number of UUCP and (Send)Mail, Usenet, etc. setups on these and by some creative interaction with the MacOS side and clients it allowed the 'Mac ecosystem' LAN and software of the day to send and receive 'internet' mail and such. (leased lines in Europe were very, very expensive and slow until the late 90's and early 00's so UUCP and dailup was quite common for a long time for small businesses..) It was a time that Apple engineers were really making some strides to kickstart a change to a *IX based multitasking MacOS, but it all fizzled out as A/UX was never succesful and Apple at the time was not in the best of spots finance-wise. As such, it's an 'interesting oddball' in UNIX history IMHO, but not from a viewpoint of having brought anything new or revolutionary to the table that has stuck around. Bye, Arno. From lm at mcvoy.com Mon Jul 20 21:49:57 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Jul 2020 04:49:57 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: <20200720114957.GL26294@mcvoy.com> On Mon, Jul 20, 2020 at 03:48:29AM -0600, Andrew Warkentin wrote: > A/UX runs Mac OS as a Unix process (its default GUI is Mac OS although > it does also support a traditional X server), making it the opposite > of MachTen. It has considerable integration between Mac OS and Unix, > and supports "hybrid" programs (Unix programs that make Mac OS system > calls and Mac OS programs that make Unix system calls) (which I don't > think MachTen supports, but I'm not completely sure of that). It is > one of only two Unices that I'm aware of that runs another OS in a > process to provide its main GUI (the other is a much more recent Linux > distribution that runs AROS; I'm not counting things like running > Windows under Merge or VP/IX because those were usually used in > addition to X11). This isn't quite the same but Victor Yodaiken wrote a real time kernel that ran all of Linux as a user process. Super cool idea and it worked great, he would demo it sampling the parallel port while Linux was running some X11 perf thing, tarring up /usr and untarring on nfs://server/tmp/usr and doing a ftp transfer. Basically beating the crap out of Linux as hard as he could while running a real time sampler and it never missed. Clem should pay attention, in my opinion, this is how you do Unix and real time. Because Unix is time sharing and throughput, that is the opposite of what real time is. Wedging real time into Unix is a mistake. http://mcvoy.com/lm/papers/rtlmanifesto.pdf --lm From dwalker at doomd.net Mon Jul 20 22:32:10 2020 From: dwalker at doomd.net (Derrik Walker v2.0) Date: Mon, 20 Jul 2020 08:32:10 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <202007200847.06K8l8DF026646@freefriends.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> I used Mach10 and Later MkLinux as my UNIXy systems while in College before I got my first Sun Workstation in the mid ’90’s. Interestingly enough. MkLinux was actually ported to Old World PowerMacs by Apple and HP. I think they also made.a version PCs too. And Mach10 was interesting. Different. I also had Minix for the Mac, it worked much the same, as an app that sat onto of MacOS. - Derrik > On Jul 20, 2020, at 4:47 AM, arnold at skeeve.com wrote: > > ISTR that A/UX was nothing special as a Unix. Am I failing to remember? > > I had had a DMD 5620 at my job, and after I moved to a different place > and requested one, they graced me with a Macintosh. It could sort of > do multiple windows, but it was like having a piper cub after being > used to a 747. > > Other interesting bits for the Mac to maybe recover would be Mach Ten, > which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) > There was also a Mach/Linux that I think ran on the Mac at some point. > > Arnold > > Michael Parson wrote: > >> On 2020-07-18 23:42, Grant Taylor via TUHS wrote: >>> On 7/18/20 9:46 PM, Wesley Parish wrote: >>>> I'd still love to have that running. >>> >>> I think I've seen articles about people running it running >>> virtualization / emulation. >> >> As far as I've been able to find, there is only one emulator that can >> run A/UX, shoebill[0]. >> >> I've got a Mac Quadra 950 with a Workgroup Server 95 card in it in the >> garage that I've been planning on someday trying to get A/UX running on, >> but haven't found enough round tuits. >> >> Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE >> (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), >> A/UX might work there. >> >> -- >> Michael Parson >> Pflugerville, TX >> KF5LGQ >> >> [0] https://github.com/emaculation/shoebill > From andreww591 at gmail.com Mon Jul 20 22:54:40 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Mon, 20 Jul 2020 06:54:40 -0600 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> Message-ID: On 7/20/20, Derrik Walker v2.0 wrote: > > Interestingly enough. MkLinux was actually ported to Old World PowerMacs by > Apple and HP. I think they also made.a version PCs too. > There was an early version of MkLinux for PCs but I'm not sure if there was ever a complete distribution. On 7/20/20, Larry McVoy wrote: > > This isn't quite the same but Victor Yodaiken wrote a real time kernel > that ran all of Linux as a user process. Super cool idea and it worked > great, he would demo it sampling the parallel port while Linux was running > some X11 perf thing, tarring up /usr and untarring on nfs://server/tmp/usr > and doing a ftp transfer. Basically beating the crap out of Linux as > hard as he could while running a real time sampler and it never missed. > > Clem should pay attention, in my opinion, this is how you do Unix and > real time. Because Unix is time sharing and throughput, that is the > opposite of what real time is. Wedging real time into Unix is a mistake. > QNX manages to do realtime fairly decently while still being Unix-like, although it's certainly not a conventional Unix. With a multi-server OS with a properly designed microkernel, it is possible for realtime threads to more or less ignore the fact that they're running on a Unix-like OS (provided that they can access some kind of IPC API that closely matches that of the kernel) since all the OS services other than the microkernel are running beside them at non-realtime priorities, and not underneath them as in a conventional OS. It's kind of doing the same thing as running a Unix kernel as a process under a realtime kernel, but the Unix environment is implemented by servers and libraries instead of a monolithic kernel. From doug at cs.dartmouth.edu Mon Jul 20 23:42:01 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 20 Jul 2020 09:42:01 -0400 Subject: [TUHS] G R Emlin Message-ID: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> Coming upon this dedication in W.B. Yeats's book, "Irish Folk stories and Fairy Tales", I felt a frisson of connection: "Inscribed to my mystical friend, G. R." Mystically present in the Unix room and on the 1127 org chart, G. R. Emlin took a place in our little community akin to that of fairies in Irish peasant culture. First encountered by Fred Grampp, G. R. manifested to others in various guises, ranging from Grace Emlin, whom I remember as a security guru, to a Labs-badged apparition now housed in the corporate archives (www.peteradamsphoto.com/unix-folklore/). My most memorable personal encounter was when I received from G. R. a receipt for paint for the water-tower project (spinrooot.com/pico/pjw.html) as part of a request for reimbursement. I passed the voucher up the chain of command to our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, despite his masterful ability to bypass bureaucratic obstacles, declared he wasn't authorized to approve plant improvements. Doug From arnold at skeeve.com Mon Jul 20 23:49:01 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Jul 2020 07:49:01 -0600 Subject: [TUHS] G R Emlin In-Reply-To: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> Message-ID: <202007201349.06KDn1SG005869@freefriends.org> Brian Kernighan acknowledges Grace's contribution as a reviewer of his memoir on Unix (published last year). I asked Brian to follow up with Gerard Holzmann to add her to his alumni page (https://www.spinroot.com/gerard/1127_alumni.html); he did so. The curious can look there to see where she went. :-) Arnold Doug McIlroy wrote: > Coming upon this dedication in W.B. Yeats's book, "Irish Folk > stories and Fairy Tales", I felt a frisson of connection: "Inscribed > to my mystical friend, G. R." Mystically present in the Unix room > and on the 1127 org chart, G. R. Emlin took a place in our little > community akin to that of fairies in Irish peasant culture. First > encountered by Fred Grampp, G. R. manifested to others in various > guises, ranging from Grace Emlin, whom I remember as a security guru, > to a Labs-badged apparition now housed in the corporate archives > (www.peteradamsphoto.com/unix-folklore/). My most memorable personal > encounter was when I received from G. R. a receipt for paint for the > water-tower project (spinrooot.com/pico/pjw.html) as part of a request > for reimbursement. I passed the voucher up the chain of command to > our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, > despite his masterful ability to bypass bureaucratic obstacles, > declared he wasn't authorized to approve plant improvements. > > Doug From crossd at gmail.com Tue Jul 21 00:16:17 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 20 Jul 2020 10:16:17 -0400 Subject: [TUHS] G R Emlin In-Reply-To: <202007201349.06KDn1SG005869@freefriends.org> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> <202007201349.06KDn1SG005869@freefriends.org> Message-ID: On Mon, Jul 20, 2020 at 9:50 AM wrote: > I asked Brian to follow up with Gerard Holzmann to add her to his > alumni page (https://www.spinroot.com/gerard/1127_alumni.html); > he did so. The curious can look there to see where she went. :-) > Witness protection, indeed! I had heard, rather, that she eloped with a soldier, a young Lieutenant named Kije, but the relocation schedule involved in being married to the Army made collaboration difficult so she left active research. He seems to have died; I wonder if she'll make a reappearance? - Dan C. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Tue Jul 21 00:03:17 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 20 Jul 2020 14:03:17 +0000 Subject: [TUHS] G R Emlin In-Reply-To: <202007201349.06KDn1SG005869@freefriends.org> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> <202007201349.06KDn1SG005869@freefriends.org> Message-ID: <0F580225-4AA7-476D-A9B4-A23ABA9BCA1A@coraid.com> I can't keep her from using her email address. She's the contact for coraid.com. She came south with me after the the last International Workshop on Plan 9 at Bell Labs in 200?. cessna% who bwc gremlin charlie jcf kaushal none tor cessna% grep eml /adm/users 34:gremlin:gremlin: cessna% > On Jul 20, 2020, at 9:49 AM, arnold at skeeve.com wrote: > > Brian Kernighan acknowledges Grace's contribution as a reviewer > of his memoir on Unix (published last year). > > I asked Brian to follow up with Gerard Holzmann to add her to his > alumni page (https://www.spinroot.com/gerard/1127_alumni.html); > he did so. The curious can look there to see where she went. :-) > > Arnold > > Doug McIlroy wrote: > >> Coming upon this dedication in W.B. Yeats's book, "Irish Folk >> stories and Fairy Tales", I felt a frisson of connection: "Inscribed >> to my mystical friend, G. R." Mystically present in the Unix room >> and on the 1127 org chart, G. R. Emlin took a place in our little >> community akin to that of fairies in Irish peasant culture. First >> encountered by Fred Grampp, G. R. manifested to others in various >> guises, ranging from Grace Emlin, whom I remember as a security guru, >> to a Labs-badged apparition now housed in the corporate archives >> (www.peteradamsphoto.com/unix-folklore/). My most memorable personal >> encounter was when I received from G. R. a receipt for paint for the >> water-tower project (spinrooot.com/pico/pjw.html) as part of a request >> for reimbursement. I passed the voucher up the chain of command to >> our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, >> despite his masterful ability to bypass bureaucratic obstacles, >> declared he wasn't authorized to approve plant improvements. >> >> Doug From clemc at ccc.com Tue Jul 21 00:28:50 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jul 2020 10:28:50 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <202007200847.06K8l8DF026646@freefriends.org> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: On Mon, Jul 20, 2020 at 4:49 AM wrote: > Other interesting bits for the Mac to maybe recover would be Mach Ten, > which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) > Interesting (not sure I would say 'cool'). I saw running it once next to NeXT Cube when I was visiting some friends in the Mach group at CMU at some point. I had always been under the impression it just used MacOS 7 to load it and then took over the system. But I never ran 'under it' as it were. > There was also a Mach/Linux that I think ran on the Mac at some point. I think I remember seeing that announced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 21 00:36:48 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jul 2020 10:36:48 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720114957.GL26294@mcvoy.com> References: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> Message-ID: On Mon, Jul 20, 2020 at 7:51 AM Larry McVoy wrote: > This isn't quite the same but Victor Yodaiken wrote a real time kernel > that ran all of Linux as a user process. Super cool idea and it worked > great, he would demo it sampling the parallel port while Linux was running > some X11 perf thing, tarring up /usr and untarring on nfs://server/tmp/usr > and doing a ftp transfer. Basically beating the crap out of Linux as > hard as he could while running a real time sampler and it never missed. > > Clem should pay attention, in my opinion, this is how you do Unix and > real time. Because Unix is time sharing and throughput, that is the > opposite of what real time is. Wedging real time into Unix is a mistake. > > http://mcvoy.com/lm/papers/rtlmanifesto.pdf As often true, I really don't disagree with you. Around the time I left Masscomp for Stellar we were working on a rewrite with some ex-CMU folks (Doug ... I don't remember is his last name now) that used a preemptive RT microkernel under the covers and then supplied RTU system calls. Tom and I left for Stellar and a couple of other people left too. This was time of the reign of Mr. Potato Head (ex-IBM guy that was named CEO) and things blew up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Jul 21 02:35:44 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 20 Jul 2020 12:35:44 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720094648.GE15253@ancienthardware.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On 7/20/2020 5:46 AM, Arno Griffioen wrote: > Mid 90's I did a number of UUCP and (Send)Mail, Usenet, etc. setups on > these and by some creative interaction with the MacOS side and clients > it allowed the 'Mac ecosystem' LAN and software of the day to send and receive > 'internet' mail and such. I was involved in USENET back in the early-to-mid 90's, and never heard of Mac stuff going on, but then, I'm in the US. The USENET stuff I built was Intel as front-end w/SVR4.2, and SPARC (-LX) as the backend file server. I never realized there was any sort of "-nix" for Macs back then. art k. From will.senn at gmail.com Tue Jul 21 02:45:44 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 11:45:44 -0500 Subject: [TUHS] 211BSD Version in the Unix Archive Message-ID: <327c5b98-c48f-7855-0503-9c0f503af09c@gmail.com> Hi All, I'm currently doing some work with 211BSD and the best version that I've come across for my investigations is the one put together by Andre Luvisi, based on the distro in the Unix Archive at https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD So far as I can figure out (and I'm a little bit fuzzy around the edges), this appears to be patch level 431, at least according to https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD/VERSION. I have a number of questions that hopefully, someone can shed some light on: 1. Is it really pl 431? 2. How can I tell? 3. Is it the latest tape image available (I've seen plenty of disk images, but those are already installed)? 4. Is there a howto bring it up to the next patch level document lying around somewhere? I've seen Warner's work on going the other direction and that's fascinating in it's own right, but I'd like to see about patching up to latest. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 21 03:06:39 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 12:06:39 -0500 Subject: [TUHS] 211BSD Version in the Unix Archive Message-ID: Well, I figured out number 4, duh! 4. Is there a howto bring it up to the next patch level document lying around somewhere? Each patch is self documenting :). Just do what it says and it should work... we'll see! Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 21 03:23:59 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 12:23:59 -0500 Subject: [TUHS] Traditional method of dealing with embedded shar files Message-ID: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> As y'all know, I'm a relative latecomer to the world of Unix, but I do try to figure out how y'all did it back when. So, sometimes, as in this case, I can figure out how to do something, but I'm curious how it was done back in the day, moreso than how I can get it done today. I'm looking at the patching of my shiny new 2.11 BSD pl 431 system running on my speedy little virtual PDP-11/70, so I grabbed patch 432 (here's a portion of the patch): ...     To install the update cut where indicated below and save to a file     (/tmp/432) and then:         cd /tmp         sh 432         ./432.sh         ./432.rm         sh 432.shar         patch -p0 < 432.patch     Watch carefully for any rejected parts of the patch.   Failure of a     patch typically means the system was not current on all preceeding     updates _or_ that local modifications have been made. ... ====== cut here #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: #    432.rm #    432.sh #    432.shar #    432.patch ... #    End of shell archive This seems straightforward. Just follow the directions et voila magic happens. My questions for y'all are how would you go about doing this? Use vi to delete everything through the ==== cut here line? Use some combination of standard unix tools to chop it up? What was your workflow for patching up the system using these files? In my world, if I screw something up, it's 15 seconds to run a restore script in my simh directory and I can try again, so my level of concern for a mistake is pretty low. If I was doing this in 1980, on real hardware, I would have had many concerns, as I'm sure some of y'all can remember, how did you prepare and protect yourselves so a patch was successful. BTW, I thought .shar was an archive format, so when I saw the patch was a shar file, I was worried it would be in some binary form, lo and behold, it looks like text to me... not even b64. So much to learn, so little time. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Jul 21 03:24:20 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 20 Jul 2020 13:24:20 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720114957.GL26294@mcvoy.com> References: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> Message-ID: On Mon, Jul 20, 2020 at 7:51 AM Larry McVoy wrote: > This isn't quite the same but Victor Yodaiken wrote a real time kernel > that ran all of Linux as a user process. The Bell Labs MERT system did almost the same thing: its low-priority process was a Unix emulator along the lines of MS WSL 1. See < https://en.wikipedia.org/wiki/Multi-Environment_Real-Time> for basics and links. Similarly, the PDP-8's modular real-time system RTS/8 had a symbiotic relationship with OS/8, the single-user operating system; you programmed and built instances of RTS/8 under OS/8 and then booted them, but if you had enough memory, you could include the OS8 [sic] task in the RTS build and it would run OS/8 as the lowest priority task. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 21 03:44:35 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jul 2020 13:44:35 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: > As y'all know, I'm a relative latecomer to the world of Unix, but I do try > to figure out how y'all did it back when. So, sometimes, as in this case, I > can figure out how to do something, but I'm curious how it was done back in > the day, moreso than how I can get it done today. I'm looking at the > patching of my shiny new 2.11 BSD pl 431 system running on my speedy little > virtual PDP-11/70, so I grabbed patch 432 (here's a portion of the patch): > ... > To install the update cut where indicated below and save to a file > (/tmp/432) and then: > > cd /tmp > sh 432 > ./432.sh > ./432.rm > sh 432.shar > patch -p0 < 432.patch > > Watch carefully for any rejected parts of the patch. Failure of a > patch typically means the system was not current on all preceeding > updates _or_ that local modifications have been made. > ... > ====== cut here > #! /bin/sh > # This is a shell archive, meaning: > # 1. Remove everything above the #! /bin/sh line. > # 2. Save the resulting text in a file. > # 3. Execute the file with /bin/sh (not csh) to create: > # 432.rm > # 432.sh > # 432.shar > # 432.patch > ... > # End of shell archive > > This seems straightforward. Just follow the directions et voila magic > happens. > > My questions for y'all are how would you go about doing this? Use vi to > delete everything through the ==== cut here line? Use some combination of > standard unix tools to chop it up? What was your workflow for patching up > the system using these files? > > In my world, if I screw something up, it's 15 seconds to run a restore > script in my simh directory and I can try again, so my level of concern for > a mistake is pretty low. If I was doing this in 1980, on real hardware, I > would have had many concerns, as I'm sure some of y'all can remember, how > did you prepare and protect yourselves so a patch was successful. > > BTW, I thought .shar was an archive format, so when I saw the patch was a > shar file, I was worried it would be in some binary form, lo and behold, it > looks like text to me... not even b64. So much to learn, so little time. > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 21 03:49:00 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Jul 2020 11:49:00 -0600 Subject: [TUHS] 211BSD Version in the Unix Archive In-Reply-To: <327c5b98-c48f-7855-0503-9c0f503af09c@gmail.com> References: <327c5b98-c48f-7855-0503-9c0f503af09c@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 10:46 AM Will Senn wrote: > Hi All, > > I'm currently doing some work with 211BSD and the best version that I've > come across for my investigations is the one put together by Andre Luvisi, > based on the distro in the Unix Archive at > https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD > You should look at the canonical tuhs archive at https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/ > So far as I can figure out (and I'm a little bit fuzzy around the edges), > this appears to be patch level 431, at least according to > https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD/VERSION. > I have a number of questions that hopefully, someone can shed some light on: > 1. Is it really pl 431? > Yes. It is. > 2. How can I tell? > VERSION is always updated, so it is. If you are in doubt, you can look at the patch files that's at https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/ and they all update VERSION. > 3. Is it the latest tape image available (I've seen plenty of disk images, > but those are already installed)? > Yes. Well, almost. https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD_patch457/ has a tape that's updated to 457, lacking only the last 12 changes. A most current tape hasn't been regenerated, at least in the archives. A quick search of github shows there's a few PiDP-11 oriented versions but I've not looked closely at them. > 4. Is there a howto bring it up to the next patch level document lying > around somewhere? > There's two or three efforts to create shell scripts to apply the patches. I've not looked closely at them all yet... > I've seen Warner's work on going the other direction and that's > fascinating in it's own right, but I'd like to see about patching up to > latest > When my work is done, there will be a github repo that has all the changes applied, one at a time which can be used to generate context diffs or something else that can be pushed to the PDP-11s that can be updated. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno.griffioen at ieee.org Tue Jul 21 03:44:48 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Mon, 20 Jul 2020 19:44:48 +0200 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: <20200720174448.GF15253@ancienthardware.org> On Mon, Jul 20, 2020 at 12:35:44PM -0400, Arthur Krewat wrote: > On 7/20/2020 5:46 AM, Arno Griffioen wrote: > > Mid 90's I did a number of UUCP and (Send)Mail, Usenet, etc. setups on > > these and by some creative interaction with the MacOS side and clients > > it allowed the 'Mac ecosystem' LAN and software of the day to send and receive > > 'internet' mail and such. > I was involved in USENET back in the early-to-mid 90's, and never heard of > Mac stuff going on, but then, I'm in the US. The USENET stuff I built was > Intel as front-end w/SVR4.2, and SPARC (-LX) as the backend file server. I > never realized there was any sort of "-nix" for Macs back then. To be fair.. The number of installs I did on SCO boxes and such far, far outnumbered those of A/UX ones. They were pretty special in those days, not to mention horrendously expensive if you compared a fully loaded IIfx with A/UX to a 486 with SCO UNIX, even on a decent Compaq. SCO being pretty much the bread&butter of most small to medium companies at that time to run things like their accounting software and such across many remote terminals (either actual ones or other PC's telnetting in..). Bye, Arno. From clemc at ccc.com Tue Jul 21 03:52:57 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jul 2020 13:52:57 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: > My questions for y'all are how would you go about doing this? Use vi to > delete everything through the ==== cut here line? > Yep > In my world, if I screw something up, it's 15 seconds to run a restore > script in my simh directory and I can try again, so my level of concern for > a mistake is pretty low. If I was doing this in 1980, on real hardware, I > would have had many concerns, as I'm sure some of y'all can remember, how > did you prepare and protect yourselves so a patch was successful. > Run an incremental backup and/or copy the files you new you we were messing with. The good news was that patch makes backups. > > BTW, I thought .shar was an archive format, so when I saw the patch was a > shar file, > It was so of. It was a way to send files around that people could easily execute and you new would work through 7-bit based email which is all the SMTP guaranteed in the early days. Yeh but .. uucp was 8 yep. But some of the legs of the USENET were luck to be based on Arpanet site, which might have had a mailer running BITNET. When shar was created the 'least needed' style assumptions were used. As it was it was often that people put tarballs, then compressed them and then uuencoded them inside. Often a space savings and made it easier -> compressed tar was pretty good, and even with the 3 8-bit chars as 4 6-bit chars of uuencode it will worked out well in practice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 21 03:55:27 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Jul 2020 11:55:27 -0600 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 11:25 AM Will Senn wrote: > As y'all know, I'm a relative latecomer to the world of Unix, but I do try > to figure out how y'all did it back when. So, sometimes, as in this case, I > can figure out how to do something, but I'm curious how it was done back in > the day, moreso than how I can get it done today. I'm looking at the > patching of my shiny new 2.11 BSD pl 431 system running on my speedy little > virtual PDP-11/70, so I grabbed patch 432 (here's a portion of the patch): > ... > To install the update cut where indicated below and save to a file > (/tmp/432) and then: > > cd /tmp > sh 432 > ./432.sh > ./432.rm > sh 432.shar > patch -p0 < 432.patch > > Watch carefully for any rejected parts of the patch. Failure of a > patch typically means the system was not current on all preceeding > updates _or_ that local modifications have been made. > ... > ====== cut here > #! /bin/sh > # This is a shell archive, meaning: > # 1. Remove everything above the #! /bin/sh line. > # 2. Save the resulting text in a file. > # 3. Execute the file with /bin/sh (not csh) to create: > # 432.rm > # 432.sh > # 432.shar > # 432.patch > ... > # End of shell archive > > This seems straightforward. Just follow the directions et voila magic > happens. > > My questions for y'all are how would you go about doing this? Use vi to > delete everything through the ==== cut here line? Use some combination of > standard unix tools to chop it up? What was your workflow for patching up > the system using these files? > sed -e '1,/---cut here---/d' < $patch | sh -x is what I use, but there's a wide variety of 'cut here' lines in the 2.11BSD patches, so I have had to taylor to each patch. > In my world, if I screw something up, it's 15 seconds to run a restore > script in my simh directory and I can try again, so my level of concern for > a mistake is pretty low. If I was doing this in 1980, on real hardware, I > would have had many concerns, as I'm sure some of y'all can remember, how > did you prepare and protect yourselves so a patch was successful. > Yea, it was always a crap-shoot back in the day on slow hardware. Backups on tape were your best bet :(. > BTW, I thought .shar was an archive format, so when I saw the patch was a > shar file, I was worried it would be in some binary form, lo and behold, it > looks like text to me... not even b64. So much to learn, so little time. > It is and it isn't. Mostly isn't for these patches. libarchive supports it, but there's no standard and what libarchive supports is quite limited. Warner > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 21 03:56:59 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Jul 2020 11:56:59 -0600 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 11:54 AM Clem Cole wrote: > > > On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: > >> My questions for y'all are how would you go about doing this? Use vi to >> delete everything through the ==== cut here line? >> > Yep > > > > >> In my world, if I screw something up, it's 15 seconds to run a restore >> script in my simh directory and I can try again, so my level of concern for >> a mistake is pretty low. If I was doing this in 1980, on real hardware, I >> would have had many concerns, as I'm sure some of y'all can remember, how >> did you prepare and protect yourselves so a patch was successful. >> > Run an incremental backup and/or copy the files you new you we were > messing with. The good news was that patch makes backups. > >> >> BTW, I thought .shar was an archive format, so when I saw the patch was a >> shar file, >> > It was so of. It was a way to send files around that people could easily > execute and you new would work through 7-bit based email which is all the > SMTP guaranteed in the early days. Yeh but .. uucp was 8 yep. But some > of the legs of the USENET were luck to be based on Arpanet site, which > might have had a mailer running BITNET. When shar was created the 'least > needed' style assumptions were used. As it was it was often that people > put tarballs, then compressed them and then uuencoded them inside. Often a > space savings and made it easier -> compressed tar was pretty good, and > even with the 3 8-bit chars as 4 6-bit chars of uuencode it will worked out > well in practice. > There's various 'unshar' programs, but they are all just restricted versions of the shell because of the wide diversity of 'shar' implementation... uuencoded compressed tar balls added another layer to this mess as well :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 21 04:03:57 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 13:03:57 -0500 Subject: [TUHS] 211BSD Version in the Unix Archive In-Reply-To: References: <327c5b98-c48f-7855-0503-9c0f503af09c@gmail.com> Message-ID: <2928e03c-8d02-6a15-1f21-dfbf576633ea@gmail.com> On 7/20/20 12:49 PM, Warner Losh wrote: > > You should look at the canonical tuhs archive at > https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/ I'll do that. > So far as I can figure out (and I'm a little bit fuzzy around the > edges), this appears to be patch level 431, at least according to > https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD/VERSION. > I have a number of questions that hopefully, someone can shed some > light on: > > > > 1. Is it really pl 431? > > > Yes.  It is. Excellent. Thanks for the confirmation. > 2. How can I tell? > > > VERSION is always updated, so it is. If you are in doubt, you can look > at the patch files that's at > https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/ and > they all update VERSION. Got it. > 3. Is it the latest tape image available (I've seen plenty of disk > images, but those are already installed)? > > > Yes. Well, almost. > https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD_patch457/ has a > tape that's updated to 457, lacking only the last 12 changes. A most > current tape hasn't been regenerated, at least in the archives. A > quick search of github shows there's a few PiDP-11 oriented versions > but I've not looked closely at them. When folks 'regenerate' the tape, is it simply a matter of writing to the tape device from the patched disk inside the 211BSD instance or are there some arcane activities involved? > 4. Is there a howto bring it up to the next patch level document > lying around somewhere? > > > There's two or three efforts to create shell scripts to apply the > patches. I've not looked closely at them all yet... > > I've seen Warner's work on going the other direction and that's > fascinating in it's own right, but I'd like to see about patching > up to latest > > When my work is done, there will be a github repo that has all the > changes applied, one at a time which can be used to generate context > diffs or something else that can be pushed to the PDP-11s that can be > updated. Nice. You said something like this the other day, but at the time, I didn't quite get how relevant it would be. Now that I understand what you're talking about, it sounds great. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 21 04:07:00 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 13:07:00 -0500 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On 7/20/20 12:52 PM, Clem Cole wrote: > > > On Mon, Jul 20, 2020 at 1:25 PM Will Senn > wrote: > > My questions for y'all are how would you go about doing this? Use > vi to delete everything through the ==== cut here line? > > Yep Nice, seemed easy enough to me, but I was expecting real Unix folks use sed | awk | indent type answers. > It was so of.  It was a way to send files around that people could > easily execute and you new would work through 7-bit based email which > is all the SMTP guaranteed in the early days.   Yeh but .. uucp was 8 > yep.  But some of the legs of the USENET were luck to be based on > Arpanet site, which might have had a mailer running BITNET.  When shar > was created the 'least needed' style assumptions were used.   As it > was it was often that people put tarballs, then compressed them and > then uuencoded them inside.  Often a space savings and made it easier > -> compressed tar was pretty good, and even with the 3 8-bit chars as > 4 6-bit chars of uuencode it will worked out well in practice. Hmm... can't wait to run across all of these variants :). -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Jul 21 04:08:23 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 20 Jul 2020 14:08:23 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: shar, by the way, stands for "shell archive." That is, it's an archive that could be unpacked by feeding the file into sh. The most complete unshar is probably at http://sources.vsta.org/comp.sources.unix/volume15/cshar/ It's portable C (for its time, 20 years ago). Safety, in terms of not trashing an existing file, was a goal. On Mon, Jul 20, 2020 at 1:59 PM Warner Losh wrote: > > > On Mon, Jul 20, 2020 at 11:54 AM Clem Cole wrote: > >> >> >> On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: >> >>> My questions for y'all are how would you go about doing this? Use vi to >>> delete everything through the ==== cut here line? >>> >> Yep >> >> >> >> >>> In my world, if I screw something up, it's 15 seconds to run a restore >>> script in my simh directory and I can try again, so my level of concern for >>> a mistake is pretty low. If I was doing this in 1980, on real hardware, I >>> would have had many concerns, as I'm sure some of y'all can remember, how >>> did you prepare and protect yourselves so a patch was successful. >>> >> Run an incremental backup and/or copy the files you new you we were >> messing with. The good news was that patch makes backups. >> >>> >>> BTW, I thought .shar was an archive format, so when I saw the patch was >>> a shar file, >>> >> It was so of. It was a way to send files around that people could easily >> execute and you new would work through 7-bit based email which is all the >> SMTP guaranteed in the early days. Yeh but .. uucp was 8 yep. But >> some of the legs of the USENET were luck to be based on Arpanet site, which >> might have had a mailer running BITNET. When shar was created the 'least >> needed' style assumptions were used. As it was it was often that people >> put tarballs, then compressed them and then uuencoded them inside. Often a >> space savings and made it easier -> compressed tar was pretty good, and >> even with the 3 8-bit chars as 4 6-bit chars of uuencode it will worked out >> well in practice. >> > > There's various 'unshar' programs, but they are all just restricted > versions of the shell because of the wide diversity of 'shar' > implementation... uuencoded compressed tar balls added another layer to > this mess as well :) > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 21 04:11:11 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 20 Jul 2020 13:11:11 -0500 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On 7/20/20 12:55 PM, Warner Losh wrote: > Will said: > > My questions for y'all are how would you go about doing this? Use > vi to delete everything through the ==== cut here line? Use some > combination of standard unix tools to chop it up? What was your > workflow for patching up the system using these files? > > > sed -e '1,/---cut here---/d' < $patch | sh -x > > is what I use, but there's a wide variety of 'cut here' lines in the > 2.11BSD patches, so I have had to taylor to each patch. Thanks, this is nice and simple. I'll be on the lookout for the differences. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 21 04:41:31 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jul 2020 14:41:31 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020 at 2:12 PM Will Senn wrote: > sed -e '1,/---cut here---/d' < $patch | sh -x > > is what I use, but there's a wide variety of 'cut here' lines in the > 2.11BSD patches, so I have had to taylor to each patch. > > Yep and you usually only running one or two at a time. Your work As Wernflow of a applying a lot of patches is a tad different. As Warner said, there were plenty of different shar/unshars back in the day. Just remember to thank Mary Ann for uuencode/decode which started it all ;-) Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Tue Jul 21 05:07:25 2020 From: rdm at cfcl.com (Rich Morin) Date: Mon, 20 Jul 2020 12:07:25 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720094648.GE15253@ancienthardware.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: <2966979D-066B-408E-A4D7-D0F50BE14109@cfcl.com> My spouse (Vicki Brown) worked in the initial A/UX group and I contracted for it (reviewing the man pages). Here are a few historical tidbits... A number of A/UX boxes were purchased and immediately reloaded with Mac OS (because only the A/UX boxes were available with 80 MB disk drives). A/UX had an "Eschatology" feature whose purpose was to bring a damaged operting system back to a known working state. It was based on a text file of metadata and a small set of replacement files (e.g., commands). The A/UX installation kit was delivered on several dozen floppy disks. In order to minimize the number of disks, Vicki implemented a bin packing algorithm. It grabbed promising sets of files, compressed them, and checked the resulting size. One challenge in building the kit was creating a boot floppy. To make this possible, Vicki created a precursor to busybox: a single program which ran under various names, providing subsets of common commands' functionalities. Because this shared the libraries, it saved lots of space... -r From aek at bitsavers.org Tue Jul 21 05:45:50 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 20 Jul 2020 12:45:50 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <2966979D-066B-408E-A4D7-D0F50BE14109@cfcl.com> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <2966979D-066B-408E-A4D7-D0F50BE14109@cfcl.com> Message-ID: <661b03fd-83c6-0941-74bd-ac1c712f58ed@bitsavers.org> On 7/20/20 12:07 PM, Rich Morin wrote: > A number of A/UX boxes were purchased and immediately reloaded with Mac OS (because only the A/UX boxes were available with 80 MB disk drives). A/UX didn't get a whole lot of love inside Apple in the 80s. I remember going to the talk on the version that introduced Mac as a process and there were less than a dozen people who attended. From aek at bitsavers.org Tue Jul 21 05:49:38 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 20 Jul 2020 12:49:38 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <661b03fd-83c6-0941-74bd-ac1c712f58ed@bitsavers.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <2966979D-066B-408E-A4D7-D0F50BE14109@cfcl.com> <661b03fd-83c6-0941-74bd-ac1c712f58ed@bitsavers.org> Message-ID: <31bad2be-a67c-aa2f-a479-d7434955d271@bitsavers.org> On 7/20/20 12:45 PM, Al Kossow wrote: > A/UX didn't get a whole lot of love inside Apple in the 80s. > I remember going to the talk on the version that introduced Mac as a process and > there were less than a dozen people who attended. > > > I also had one of the few copies of MacMach that ran on a IIfx. No one in Cupertino was very interested in Mach. From andrew at humeweb.com Tue Jul 21 05:35:35 2020 From: andrew at humeweb.com (Andrew Hume) Date: Mon, 20 Jul 2020 12:35:35 -0700 Subject: [TUHS] G R Emlin In-Reply-To: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> Message-ID: <62C59B48-7FD2-4125-A302-A6A55401349C@humeweb.com> at one point, Bell Labs instituted a new policy to segregate contractors by making them wear a greenish badge. they marked the occasion by sending round a memo showing what the badge would look like. as soon as i got my copy of the memo, i immediately went to Brian Kernighan’s office so we could ridicule this administrative missive. except, i found him cutting the fake badge out and was faking a G. R. Emlin name plate. Brian remarked that Vyssotsky had already been round earlier suggesting the same idea. the fake badge was good; Jon Bentley used it a couple of times to enter the building. Andrew > On Jul 20, 2020, at 6:42 AM, Doug McIlroy wrote: > > Coming upon this dedication in W.B. Yeats's book, "Irish Folk > stories and Fairy Tales", I felt a frisson of connection: "Inscribed > to my mystical friend, G. R." Mystically present in the Unix room > and on the 1127 org chart, G. R. Emlin took a place in our little > community akin to that of fairies in Irish peasant culture. First > encountered by Fred Grampp, G. R. manifested to others in various > guises, ranging from Grace Emlin, whom I remember as a security guru, > to a Labs-badged apparition now housed in the corporate archives > (www.peteradamsphoto.com/unix-folklore/). My most memorable personal > encounter was when I received from G. R. a receipt for paint for the > water-tower project (spinrooot.com/pico/pjw.html) as part of a request > for reimbursement. I passed the voucher up the chain of command to > our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, > despite his masterful ability to bypass bureaucratic obstacles, > declared he wasn't authorized to approve plant improvements. > > Doug From brantley at coraid.com Tue Jul 21 06:02:56 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 20 Jul 2020 20:02:56 +0000 Subject: [TUHS] G R Emlin In-Reply-To: <62C59B48-7FD2-4125-A302-A6A55401349C@humeweb.com> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> <62C59B48-7FD2-4125-A302-A6A55401349C@humeweb.com> Message-ID: <5EDF3B45-4F28-4C41-BA22-7C17BE2C1FD6@coraid.com> I used it when I was there, waiting for my own badge. When Dennis heard I didn't have my badge yet, he jumped up, ran off, returning a few minutes later with G R's badge for me to use. I did. Brantley > On Jul 20, 2020, at 3:35 PM, Andrew Hume wrote: > > at one point, Bell Labs instituted a new policy to segregate contractors by > making them wear a greenish badge. they marked the occasion by sending round > a memo showing what the badge would look like. > > as soon as i got my copy of the memo, i immediately went to Brian Kernighan’s > office so we could ridicule this administrative missive. except, i found him cutting > the fake badge out and was faking a G. R. Emlin name plate. Brian remarked that > Vyssotsky had already been round earlier suggesting the same idea. the fake > badge was good; Jon Bentley used it a couple of times to enter the building. > > Andrew > >> On Jul 20, 2020, at 6:42 AM, Doug McIlroy wrote: >> >> Coming upon this dedication in W.B. Yeats's book, "Irish Folk >> stories and Fairy Tales", I felt a frisson of connection: "Inscribed >> to my mystical friend, G. R." Mystically present in the Unix room >> and on the 1127 org chart, G. R. Emlin took a place in our little >> community akin to that of fairies in Irish peasant culture. First >> encountered by Fred Grampp, G. R. manifested to others in various >> guises, ranging from Grace Emlin, whom I remember as a security guru, >> to a Labs-badged apparition now housed in the corporate archives >> (www.peteradamsphoto.com/unix-folklore/). My most memorable personal >> encounter was when I received from G. R. a receipt for paint for the >> water-tower project (spinrooot.com/pico/pjw.html) as part of a request >> for reimbursement. I passed the voucher up the chain of command to >> our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, >> despite his masterful ability to bypass bureaucratic obstacles, >> declared he wasn't authorized to approve plant improvements. >> >> Doug > From erc at pobox.com Tue Jul 21 06:20:28 2020 From: erc at pobox.com (Ed Carp) Date: Mon, 20 Jul 2020 15:20:28 -0500 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720094648.GE15253@ancienthardware.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On 7/20/20, Arno Griffioen wrote: > As such, it's an 'interesting oddball' in UNIX history IMHO, but not from > a viewpoint of having brought anything new or revolutionary to the table > that has stuck around. Except that it had a rudimentary option completion feature that was sort of cool. When you typed "ls", for example, it would pop up a window that would show you all the options that you could select for that command. That was new and different. Too bad it didn't stick around. From cowan at ccil.org Tue Jul 21 07:02:31 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 20 Jul 2020 17:02:31 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On Mon, Jul 20, 2020 at 4:21 PM Ed Carp wrote: Except that it had a rudimentary option completion feature that was > sort of cool. When you typed "ls", for example, it would pop up a > window that would show you all the options that you could select for > that command. That was new and different. Too bad it didn't stick > around. > I remember reading about something like that, though it's not connected in my mind with A/UX. What I do remember is that you had to type "Ls" to pop up the options window: After all, most of the time you don't *want* options for "ls". On a text terminal, the top half of the screen became the options window; its scrolling content was restored when the window was dismissed. The window had checkboxes corresponding to the options and text fields corresponding to their values, if any. I can't remember if it parsed the output of --help or equivalent, though. I also don't recall if such commands were supported in pipelines, though I see no reason why they should not have been. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Samuel Johnson on playing the violin: "Difficult do you call it, Sir? I wish it were impossible." -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Tue Jul 21 08:11:48 2020 From: erc at pobox.com (Ed Carp) Date: Mon, 20 Jul 2020 17:11:48 -0500 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200720114957.GL26294@mcvoy.com> References: <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> Message-ID: On 7/20/20, Larry McVoy wrote: > Clem should pay attention, in my opinion, this is how you do Unix and > real time. Because Unix is time sharing and throughput, that is the > opposite of what real time is. Wedging real time into Unix is a mistake. Agreed. From erc at pobox.com Tue Jul 21 08:27:18 2020 From: erc at pobox.com (Ed Carp) Date: Mon, 20 Jul 2020 17:27:18 -0500 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On 7/20/20, John Cowan wrote: > The window had checkboxes corresponding to the options and text fields > corresponding to their values, if any. I can't remember if it parsed the > output of --help or equivalent, though. I also don't recall if such > commands were supported in pipelines, though I see no reason why they > should not have been. They were, as I recall. I don't recall if it parsed --help or if it was builtin via another mechanism. As someone else mentioned, A/UX didn't get a lot of love in Cupertino. Oh, well. From lm at mcvoy.com Tue Jul 21 11:04:11 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Jul 2020 18:04:11 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> Message-ID: <20200721010411.GS26294@mcvoy.com> On Mon, Jul 20, 2020 at 05:11:48PM -0500, Ed Carp wrote: > On 7/20/20, Larry McVoy wrote: > > > Clem should pay attention, in my opinion, this is how you do Unix and > > real time. Because Unix is time sharing and throughput, that is the > > opposite of what real time is. Wedging real time into Unix is a mistake. > > Agreed. So many people get this wrong, they want to make "real time" in Unix "good enough" and it messes with everything. Victor's idea was awesome. And you know what sucks? I was on the Usenix review committee and I gave it 2 thumbs up but someone else, looking at you, Rob, said it was not interesting because the real time kernel wasn't POSIX. Even though the real time kernel had pipes, signals, and shared memory with Linux. He was a bigger deal than me so it didn't get published. I love the Rob in question, not Pike, but this was one of the most bone headed calls I've ever seen him make. The world needed to see this. Wind River bought it and buried it because it competed with their stuff that was nowhere near as good. From lm at mcvoy.com Tue Jul 21 11:50:57 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Jul 2020 18:50:57 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> Message-ID: <20200721015057.GV26294@mcvoy.com> On Mon, Jul 20, 2020 at 06:54:40AM -0600, Andrew Warkentin wrote: > On 7/20/20, Larry McVoy wrote: > > This isn't quite the same but Victor Yodaiken wrote a real time kernel > > that ran all of Linux as a user process. Super cool idea and it worked > > great, he would demo it sampling the parallel port while Linux was running > > some X11 perf thing, tarring up /usr and untarring on nfs://server/tmp/usr > > and doing a ftp transfer. Basically beating the crap out of Linux as > > hard as he could while running a real time sampler and it never missed. > > > > Clem should pay attention, in my opinion, this is how you do Unix and > > real time. Because Unix is time sharing and throughput, that is the > > opposite of what real time is. Wedging real time into Unix is a mistake. > > > > QNX manages to do realtime fairly decently while still being > Unix-like, although it's certainly not a conventional Unix. With a > multi-server OS with a properly designed microkernel, it is possible > for realtime threads to more or less ignore the fact that they're > running on a Unix-like OS (provided that they can access some kind of > IPC API that closely matches that of the kernel) since all the OS > services other than the microkernel are running beside them at > non-realtime priorities, and not underneath them as in a conventional > OS. It's kind of doing the same thing as running a Unix kernel as a > process under a realtime kernel, but the Unix environment is > implemented by servers and libraries instead of a monolithic kernel. QNX is awesome. I was friends with Dan Hildebrandt, he was one of the 3 people who were allowed to touch the microkernel code. That kernel could fit easily in a 4K instruction cache and leave room for other processes. They measured everything in cache misses, every commit had them thinking about cache misses. I'm definitely a unikernel guy but I had mad respect for QNX, Dan and I would talk often about stuff, like how would this work in your world and how would it work in my world. The QNX core team was amazing. Sadly, we lost Dan to brain cancer (I think) in 1998. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From gregg.drwho8 at gmail.com Tue Jul 21 12:30:03 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 20 Jul 2020 22:30:03 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200721015057.GV26294@mcvoy.com> References: <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> <20200721015057.GV26294@mcvoy.com> Message-ID: Hello! Larry? I'm surprised. I've worked with QNX a few times. I also grok that you're one who has mad respect for QNX. Because I'm one also. It's an interesting OS, ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Jul 20, 2020 at 9:53 PM Larry McVoy wrote: > > On Mon, Jul 20, 2020 at 06:54:40AM -0600, Andrew Warkentin wrote: > > On 7/20/20, Larry McVoy wrote: > > > This isn't quite the same but Victor Yodaiken wrote a real time kernel > > > that ran all of Linux as a user process. Super cool idea and it worked > > > great, he would demo it sampling the parallel port while Linux was running > > > some X11 perf thing, tarring up /usr and untarring on nfs://server/tmp/usr > > > and doing a ftp transfer. Basically beating the crap out of Linux as > > > hard as he could while running a real time sampler and it never missed. > > > > > > Clem should pay attention, in my opinion, this is how you do Unix and > > > real time. Because Unix is time sharing and throughput, that is the > > > opposite of what real time is. Wedging real time into Unix is a mistake. > > > > > > > QNX manages to do realtime fairly decently while still being > > Unix-like, although it's certainly not a conventional Unix. With a > > multi-server OS with a properly designed microkernel, it is possible > > for realtime threads to more or less ignore the fact that they're > > running on a Unix-like OS (provided that they can access some kind of > > IPC API that closely matches that of the kernel) since all the OS > > services other than the microkernel are running beside them at > > non-realtime priorities, and not underneath them as in a conventional > > OS. It's kind of doing the same thing as running a Unix kernel as a > > process under a realtime kernel, but the Unix environment is > > implemented by servers and libraries instead of a monolithic kernel. > > QNX is awesome. > > I was friends with Dan Hildebrandt, he was one of the 3 people who were > allowed to touch the microkernel code. That kernel could fit easily in > a 4K instruction cache and leave room for other processes. They measured > everything in cache misses, every commit had them thinking about cache > misses. > > I'm definitely a unikernel guy but I had mad respect for QNX, Dan and > I would talk often about stuff, like how would this work in your world > and how would it work in my world. The QNX core team was amazing. > > Sadly, we lost Dan to brain cancer (I think) in 1998. > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From tytso at mit.edu Tue Jul 21 14:15:47 2020 From: tytso at mit.edu (tytso at mit.edu) Date: Tue, 21 Jul 2020 00:15:47 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> Message-ID: <20200721041547.GH388817@mit.edu> Sorry for not responding on this thread earlier; I've been pretty swamped lately. Xiafs was introduced at about the same time of ext2; Wikipedia states that "Initially, Xiafs was more stable than ext2, but being a fairly minimalistic modification of the MINIX file system, it was not very well suited for future extension." The first part wasn't quite accurate. It turns out that xiafs had the same bug as ext2, but ext2 had the necessary sanity checking so that it actually issued a warning when the bug was triggered, where xiafs just silently corrupted the file system. The real issue was that xiafs was mostly a one-person show (namely Frank Xia) and he suffered blowback when he tried to rename xiafs to linuxfs, which was interpreted by many as a marketing effort --- about as tone-deaf as Stallman trying to jawbone people to rename "Linux" to "LiGNUx" ten years later. And xiafs was technically worse compared to ext2, and ext2 had a larger number of developers. So xiafs never really stood much of a chance. Also, by that point, very few people were actually using HJ's boot/root disks. Most developers had moved on to the MCC distribution by that time, since it was more comprehensive, and it was easier to bootstrap a working development system. So to be honest, I had never noticed that HJ was trying to use xiafs in his boot/root disks. Cheers, - Ted From gtaylor at tnetconsulting.net Wed Jul 22 03:49:41 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jul 2020 11:49:41 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <20200721041547.GH388817@mit.edu> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <13529.1594950045@hop.toad.com> <20200717015914.GA12704@mcvoy.com> <20200717033555.GA18565@mcvoy.com> <0b2edf76-7199-4fc8-80bb-abeb00bb1334@www.fastmail.com> <20200721041547.GH388817@mit.edu> Message-ID: On 7/20/20 10:15 PM, tytso at mit.edu wrote: > Sorry for not responding on this thread earlier; I've been pretty > swamped lately. Better late than never. I've found that truly interesting threads on TUHS, COFF, cctalk, et al. tend to go on for weeks. > Xiafs was introduced at about the same time of ext2; Wikipedia > states that > > "Initially, Xiafs was more stable than ext2, but being a fairly > minimalistic modification of the MINIX file system, it was not very > well suited for future extension." > > The first part wasn't quite accurate. It turns out that xiafs had > the same bug as ext2, but ext2 had the necessary sanity checking so > that it actually issued a warning when the bug was triggered, where > xiafs just silently corrupted the file system. Now I'm curious what said bug was. > The real issue was that xiafs was mostly a one-person show (namely > Frank Xia) and he suffered blowback when he tried to rename xiafs > to linuxfs, which was interpreted by many as a marketing effort --- > about as tone-deaf as Stallman trying to jawbone people to rename > "Linux" to "LiGNUx" ten years later. Hum. :-/ To be perfectly honest, I hadn't heard of Xia-FS until I started messing with H.J. Lu's bootable root disk. I started messing with Linux in late '90s. By then, everything was ext2. > And xiafs was technically worse compared to ext2, and ext2 had a larger > number of developers. So xiafs never really stood much of a chance. That makes sense, retrospectively. > Also, by that point, very few people were actually using HJ's boot/root > disks. Most developers had moved on to the MCC distribution by that > time, since it was more comprehensive, and it was easier to bootstrap > a working development system. Ya. It seems as if H.J. Lu's disk had largely fallen to the annals of history by '95. MCC and SLS had come and gone, being replaced with Slackware and Debian by the time that I started messing with Linux. > So to be honest, I had never noticed that HJ was trying to use xiafs > in his boot/root disks. I can't guarantee that H.J. Lu used xiafs for his bootable root disk. I want to say that he was using the minux file system. It's the base disk images that seem to be using xiafs. I've found a treasure trove of old Linux disk images on OldLinux [1] and am messing with them in Bochs. (Bochs is working out better than VirtualBox.) [1] http://www.oldlinux.org/ -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Jul 22 03:55:18 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jul 2020 11:55:18 -0600 Subject: [TUHS] /bin vs /sbin Message-ID: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> One of the things that I've noticed in my explorations into the H.J. Lu bootable root disks is that some of them predate the /sbin split in Linux. One of them has exactly one file in /sbin and other commands spread across /bin, /usr/bin, and /etc. The single file in /sbin is sln. To me, this makes it fairly self evident that /sbin was originally for statically linked binaries. At least in Linux. Does anyone have any history of /sbin from other traditional Unixes? I'd be quite interested in learning more. I also noticed that (at least) one of the early versions of the H.J. Lu disks had root's home directory in /usr/root. I seem to recall that one version used an atypical of /users vs /usr. Which as I understand it, goes back to the original / vs /usr split in Unix, before /home became a thing. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Wed Jul 22 04:15:26 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jul 2020 12:15:26 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> Message-ID: On Tue, Jul 21, 2020 at 11:56 AM Grant Taylor via TUHS wrote: > One of the things that I've noticed in my explorations into the H.J. Lu > bootable root disks is that some of them predate the /sbin split in Linux. > > One of them has exactly one file in /sbin and other commands spread > across /bin, /usr/bin, and /etc. The single file in /sbin is sln. > > To me, this makes it fairly self evident that /sbin was originally for > statically linked binaries. At least in Linux. > The root disks date from a time before Linux had shared libraries, I thought, though I've not looked at HJ Lu's disks in a very, very long time. And I stopped looking very early on once I had my system bootstrapped... I do recall going through some pain to bootstrap shared libraries on my system... > Does anyone have any history of /sbin from other traditional Unixes? > I'd be quite interested in learning more. > /sbin has never been for static binaries in BSD land. It's always for system admin binaries that used to live in /etc. They moved to /sbin or /usr/sbin. This split is due to historically tiny / filesystems and the need to have just enough binaries on them to check and mount /usr later in boot. It dates from 4.3-RENO. There were no shared libraries in BSD at the time (though I think contemporaneous Sun systems had them, which is where Linux got its first a.out shared library scheme from (kinda, sorta, more inspired by with some code snatched from gcc/binutils SunOS compat impl, but with more limitations)). > I also noticed that (at least) one of the early versions of the H.J. Lu > disks had root's home directory in /usr/root. > > I seem to recall that one version used an atypical of /users vs /usr. > Which as I understand it, goes back to the original / vs /usr split in > Unix, before /home became a thing. > Early days this was actually quite common. You put your users under /usr/foo because there weren't many of them, and you'd save a inode lookup over /usr/users/foo and you didn't need a separate filesystem for your users. I saw it more on 'small' systems with limited number of users rather than big, university systems with student populations on them (which needed a separate filesystem to hold all the user content, even with draconian quota limits). Warner > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jul 22 04:22:11 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 21 Jul 2020 12:22:11 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> Message-ID: <202007211822.06LIMBJ4018831@freefriends.org> Grant Taylor via TUHS wrote: > To me, this makes it fairly self evident that /sbin was originally for > statically linked binaries. At least in Linux. Dunno about that. > Does anyone have any history of /sbin from other traditional Unixes? > I'd be quite interested in learning more. /sbin and /usr/sbin came into being in the late 80s when Berkeley and USG were standardizing on file system layouts for diskless workstations; Sun and DEC and others were also in on this. /sbin specifically was meant to hold the executables meant for use by root that previously had been in /etc along with config files. (sbin ==> super-user bin.) The idea was that /etc held things specific to a box, while /bin, /sbin, /usr could be remote mounted from a server. This is also when /home came into practice as the place to hold home directories. This avoided having umpteen zillion copies of the same files (executables, man pages, libraries, etc.) since they could be mounted read-only from one or a few servers. At the time, disk space was not nearly as cheap as it is now. This is also when /var came into being for log files and such; again - it was per machine space, so it lived either on a small disk in the workstation or on a per-client chunk of space on the server if the client was totally diskless. HTH, Arnold From imp at bsdimp.com Wed Jul 22 04:33:25 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jul 2020 12:33:25 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: <202007211822.06LIMBJ4018831@freefriends.org> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: On Tue, Jul 21, 2020 at 12:23 PM wrote: > Grant Taylor via TUHS wrote: > > > To me, this makes it fairly self evident that /sbin was originally for > > statically linked binaries. At least in Linux. > > Dunno about that. > I'm skeptical as well. > > Does anyone have any history of /sbin from other traditional Unixes? > > I'd be quite interested in learning more. > > /sbin and /usr/sbin came into being in the late 80s when Berkeley > and USG were standardizing on file system layouts for diskless > workstations; > Sun and DEC and others were also in on this. > > /sbin specifically was meant to hold the executables meant for use by > root that previously had been in /etc along with config files. > (sbin ==> super-user bin.) > /sbin showed up in 4.3-Reno (1990), but wasn't in 4.3-Tahoe (1988). This predates Linux by a year or so. The changes were due to the filesystem standardization and layout changes prompted by, among other things, diskless workstations as you stated later. Sun's NFS drove a lot of the adaptation in this area since it quickly became the de-facto network file system (though others did exist). > The idea was that /etc held things specific to a box, while /bin, /sbin, > /usr could be remote mounted from a server. This is also when /home > came into practice as the place to hold home directories. > > This avoided having umpteen zillion copies of the same files > (executables, man pages, libraries, etc.) since they could be mounted > read-only from one or a few servers. At the time, disk space was not > nearly as cheap as it is now. > A big cost savings in having 20 diskless workstations was that you didn't need the 2-4gb of disks for each individual one, but instead could have one copy of the 100MB-200MB of the core OS. When. X started getting libraries out the wazoo with toolkit wars, it saved even more. IIRC, the Sun 3/50's ethernet port was faster than its disk port, so your diskless workstation could be faster than one with a disk (assuming the network wasn't overloaded). >From an era that will be remembered best by "The network is the connector" corruption of a famous marketing slogan... > This is also when /var came into being for log files and such; > again - it was per machine space, so it lived either on a small disk > in the workstation or on a per-client chunk of space on the server > if the client was totally diskless. > All true. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jul 22 04:43:35 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Jul 2020 11:43:35 -0700 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: <20200721184335.GK26294@mcvoy.com> On Tue, Jul 21, 2020 at 12:33:25PM -0600, Warner Losh wrote: > A big cost savings in having 20 diskless workstations was that you didn't > need the 2-4gb of disks for each individual one, but instead could have one > copy of the 100MB-200MB of the core OS. When. X started getting libraries > out the wazoo with toolkit wars, it saved even more. IIRC, the Sun 3/50's > ethernet port was faster than its disk port, so your diskless workstation > could be faster than one with a disk (assuming the network wasn't > overloaded). Huh, I'm not sure about the Sun 3/50 ethernet being faster than disk. It is possible because diskless 3/50's worked fairly well. The similar era Apollos were miserable without disk, I wanted nothing to do with them but I was fine on a 3/50. Not great but it worked. They worked better with 8MB of ram, 4 was tight. From clemc at ccc.com Wed Jul 22 05:24:09 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jul 2020 15:24:09 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: <202007211822.06LIMBJ4018831@freefriends.org> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: On Tue, Jul 21, 2020 at 2:23 PM wrote: > /sbin and /usr/sbin came into being in the late 80s when Berkeley > and USG were standardizing on file system layouts for diskless > workstations; > Sun and DEC and others were also in on this. > Right, I was part of that discussion. Although the real driver economically was the ISVs were getting really annoyed and pushing for a cleaner namespace. *The excuse to compromise was the diskless systems. * I think I may even have a memo or two from the discussion in a file cabinet. So was IBM and CMU IIRC. This is before UI or OSF, but was an effort that was started by the /usr/group folks. Pretty much a similar group behind Heinz's Standard's committee and what would eventually become POSIX for IEEE. Bostic, Jim Issack, Armando, myself, Shannon, are some of the people I remember at the early meetings. But it was still pretty contentious. Getting Bostic to come helped a great deal because without CSRG buying in it was not going to happen. A few years later (post the first POSIX), UI would fund Locus to do the SPEC 1170 study, finding 1170 different interfaces in Unix that an ISV had to deal with to make code portable. But IIRC, that worked started before the big UI vs. OSF battle but completed after it started. > > /sbin specifically was meant to hold the executables meant for use by > root that previously had been in /etc along with config files. > (sbin ==> super-user bin.) > Right... (and a few random strays from /lib if I remember on a couple of systems) > > The idea was that /etc held things specific to a box, while /bin, /sbin, > /usr could be remote mounted from a server. This is also when /home > came into practice as the place to hold home directories. > I offer a slight rewording but agree with intention ... {/usr,}/etc was supposed to be databases that customized the node itself and changed infrequently. {/usr,}/lib was stuff that was also mostly readonly, but did not need customization. {/usr,}/sbin was supposed to be binaries that only an admin needs {/usr,}/bin was simple binaries needed to boot the system {/usr,}/opt was supposed to be were ISV's installed things [IMHO: to bad not enough people use(s) it]. /var was introduced to remove the stuff that was mostly in /usr/spool or /usr/lib to a place for things that were systems specific and updated. As opposed to {/usr,}/tmp which was supposed to be clearly scratch space and shared. Using /usr or not, was a concession to UCB left over from the original Research namespace split leftover from RK05's being 2.5M. By then user directories were all over the place, often in /u1 /u2 /u3, etc... And nobody could agree to what to do. If my memory serves me it was someone like Pat Parsigiean that suggested a whole new name and /home was born. -------------- next part -------------- An HTML attachment was scrubbed... URL: From treese at acm.org Wed Jul 22 07:59:16 2020 From: treese at acm.org (Win Treese) Date: Tue, 21 Jul 2020 17:59:16 -0400 Subject: [TUHS] G R Emlin In-Reply-To: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> References: <202007201342.06KDg1Ex033163@tahoe.cs.Dartmouth.EDU> Message-ID: > On Jul 20, 2020, at 9:42 AM, Doug McIlroy wrote: > > My most memorable personal > encounter was when I received from G. R. a receipt for paint for the > water-tower project (spinrooot.com/pico/pjw.html) as part of a request > for reimbursement. I passed the voucher up the chain of command to > our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, > despite his masterful ability to bypass bureaucratic obstacles, > declared he wasn't authorized to approve plant improvements. I starting working for Vic right as he was starting up Digital’s Cambridge Research Lab in the late 80s. The lab had a dedicated smoking room, used almost exclusively by Vic. I discovered that hanging out with him there was a great way to learn some things, and he told a lot of stories about the Bell Labs. In Vic's version, he told me that he returned the form as not being the right one for reimbursements for physical plant expenses. Which fits delightfully with bypassing bureaucratic obstacles, and using the obstacles when it suited him. He also told me that right after the painting happened, he went out into a large central area of the offices (I have no idea what the layout was) and loudly said something along the lines of “I’m sure they're never going to find out who did this!” - Win From henry.r.bent at gmail.com Wed Jul 22 08:19:25 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 21 Jul 2020 18:19:25 -0400 Subject: [TUHS] Bell Labs Sysadmins Message-ID: Are there any former Bell Labs sysadmins on this list? My father was the sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the mid-late '80s and early '90s and I would be especially interested to hear from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and the like. I'm very curious about what life was like on the ground, so to speak. I'll start off with a quick anecdote. When I started college I began working for the computing center doing menial jobs. There was an older, ex-army guy leading the networking department who extolled the virtues of the VAX up and down; I think Oberlin would have kept the VAX 6620 running VMS 5.5 forever if he had his way. Anyway, I mentioned his position to my father and he told me that the best thing he ever did was replace the VAX systems (and the endless mounting/remounting of RL02s for user data) with early generation Sun 4 systems. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Wed Jul 22 08:42:21 2020 From: davida at pobox.com (David Arnold) Date: Wed, 22 Jul 2020 08:42:21 +1000 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> Message-ID: <305889B3-25B5-4C28-BB84-57470D845BBF@pobox.com> > On 22 Jul 2020, at 04:15, Warner Losh wrote: <…> > The root disks date from a time before Linux had shared libraries, I thought, IIRC, Linux had two different shared library implementations? I haven’t looked, and don’t remember the details, but it might have been linked to the switch from a.out to ELF for executables? IIRC, the pre-ELF shared libs were a hack on the a.out executable format. Not sure where that fits into the /etc vs. /sbin timeline. ISTR Linux was somewhat inclined away from the BSD way of doing things (in favour of Solaris/SVR4). d From tytso at mit.edu Wed Jul 22 11:16:03 2020 From: tytso at mit.edu (tytso at mit.edu) Date: Tue, 21 Jul 2020 21:16:03 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: <20200722011603.GA1536749@mit.edu> On Tue, Jul 21, 2020 at 12:33:25PM -0600, Warner Losh wrote: > On Tue, Jul 21, 2020 at 12:23 PM wrote: > > > Grant Taylor via TUHS wrote: > > > > > To me, this makes it fairly self evident that /sbin was originally for > > > statically linked binaries. At least in Linux. > > > > Dunno about that. > > I'm skeptical as well. Yeah, that's definitely not right. /sbin had been around for "essential system binaries" long before Linux, and Linux took it from there. You can see this from the Linux Filesystem Hierarchy Standard (earlier named fsstnd, which specified /sbin as "essential system binaries"). SunOS used that nomenclature and the GNU tools all used /sbin for that purpose. The other thing I'd again urge is that you not take HJ Lu's boot/root disks as being influencial after early 1992. The Manchester Computing Centre (MCC) released their "MCC Interim Linux" distribution in February 1992, and it was so much more convenient than HJ's boot/root disk that it very quickly swept the field. MCC was succeeded by TAMU, Yggdrasil, SLS, Slackware, and by '94 you started seeing names like Debian, Red Hat, Caldera, SuSE, etc. that would be recognizeable today. Xiafs and ext2 date from '93, and so by that point while HJ was still producing his distribution, most Linux users were using other distributions. So whatever choices HJ may have made should not be considered as being representative of what "Linux" was doing at that time. > > The idea was that /etc held things specific to a box, while /bin, /sbin, > > /usr could be remote mounted from a server. This is also when /home > > came into practice as the place to hold home directories. Well, /bin and /sbin contained those binaries which would be needed so you could *mount* /usr from a server. /bin would be in normal users' PATH; while /sbin would have those binaries which only root could profitably use. So /bin/sh, /bin/cat, etc., because users and root needed to use those binaries. But /sbin/ifconfig and /sbin/route because they were primarily only useful if you were root. I'll also note that MIT Project Athena had architected a scheme using Remote Virtual Disk (essentially a network block device) so that large numbers of workstations (mostly MicroVaxen, but also some IBM PC/RT's) could share /usr mounted over RVD. This was documented in Professor Saltzer's Project Athena Technical Plan dated November 1986[1]. [1] http://web.mit.edu/saltzer/www/publications/athenaplan/e.3.1.pdf Cheers, - Ted From crossd at gmail.com Wed Jul 22 11:44:31 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Jul 2020 21:44:31 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: On Tue, Jul 21, 2020 at 2:35 PM Warner Losh wrote: > On Tue, Jul 21, 2020 at 12:23 PM wrote: > >> [snip] > > The idea was that /etc held things specific to a box, while /bin, /sbin, >> /usr could be remote mounted from a server. This is also when /home >> came into practice as the place to hold home directories. >> >> This avoided having umpteen zillion copies of the same files >> (executables, man pages, libraries, etc.) since they could be mounted >> read-only from one or a few servers. At the time, disk space was not >> nearly as cheap as it is now. >> > > A big cost savings in having 20 diskless workstations was that you didn't > need the 2-4gb of disks for each individual one, but instead could have one > copy of the 100MB-200MB of the core OS. When. X started getting libraries > out the wazoo with toolkit wars, it saved even more. IIRC, the Sun 3/50's > ethernet port was faster than its disk port, so your diskless workstation > could be faster than one with a disk (assuming the network wasn't > overloaded). > When I first came on the scene, there was a convention that I thought worked well: the "dataless" node. I have no idea why it was called that; I suppose because most interesting data was on a centrally managed file server. Anyway, this was under SunOS 4: the idea was that each node had a small disk; enough to hold / and swap, but mounted /usr, /usr/local and user directories from a file server. So commonly used stuff (/bin/csh, ls, etc etc) all came from a local disk, while everything else was shared. Disks in workstations were small and basically turn-key so that we didn't back them up: if one crashed, oh well: throw a new one in it and reimage /. Swap was transient anyway. A variation was to have an owning-user's home directory on the node if the local disk was big enough. Sometimes there'd be a /scratch partition for bulk storage that persisted across reboots (/tmp came from tmpfs and was a swap-backed RAM disk). We'd back up local home dirs and maybe the scratch directories. In our network, we used `amd` and NIS (YP!) to get access to everyone's home dir on every node. I rather liked the overall setup; it was nice. It became a deprecated configuration on the move to Solaris 2.x: a workstation was either diskfull or diskless. The idea of a compromise between the two extremes went away. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Wed Jul 22 12:17:18 2020 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 21 Jul 2020 19:17:18 -0700 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: <5489aab7-efb4-8bcd-3ca7-9b47e9b7b305@gmail.com> On 7/21/2020 6:44 PM, Dan Cross wrote: > When I first came on the scene, there was a convention that I thought > worked well: the "dataless" node. I have no idea why it was called that; I don't know either, but I implemented a dataless architecture for all the OSF/1 machines in the CS department at UC Berkeley in the 1990s. I wrote this up (see https://groups.google.com/forum/#!msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J and it eventually made the OSF1 FAQ. It made a huge difference back when disks were small. This was done with NFS 3.X which had no local caching. I've always wondered how a dataless environment would work on NFS 4.X, which could do local caching. Jon From athornton at gmail.com Wed Jul 22 12:20:55 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 21 Jul 2020 19:20:55 -0700 Subject: [TUHS] /bin vs /sbin In-Reply-To: <5489aab7-efb4-8bcd-3ca7-9b47e9b7b305@gmail.com> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <5489aab7-efb4-8bcd-3ca7-9b47e9b7b305@gmail.com> Message-ID: <66196367-0522-4636-8113-F829F6288153@gmail.com> > On Jul 21, 2020, at 7:17 PM, Jon Forrest wrote: > > > It made a huge difference back when disks were small. > This was done with NFS 3.X which had no local caching. > I've always wondered how a dataless environment would > work on NFS 4.X, which could do local caching. > I miss AFS. Adam From khm at sciops.net Wed Jul 22 12:27:54 2020 From: khm at sciops.net (Kurt H Maier) Date: Tue, 21 Jul 2020 19:27:54 -0700 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: <20200722022754.GC90608@wopr> On Tue, Jul 21, 2020 at 09:44:31PM -0400, Dan Cross wrote: > > When I first came on the scene, there was a convention that I thought > worked well: the "dataless" node. I have no idea why it was called that; I > suppose because most interesting data was on a centrally managed file > server. Anyway, this was under SunOS 4: the idea was that each node had a > small disk; enough to hold / and swap, but mounted /usr, /usr/local and > user directories from a file server. So commonly used stuff (/bin/csh, ls, > etc etc) all came from a local disk, while everything else was shared. > Disks in workstations were small and basically turn-key so that we didn't > back them up: if one crashed, oh well: throw a new one in it and reimage /. > Swap was transient anyway. A variation was to have an owning-user's home > directory on the node if the local disk was big enough. Sometimes there'd > be a /scratch partition for bulk storage that persisted across reboots > (/tmp came from tmpfs and was a swap-backed RAM disk). We'd back up local > home dirs and maybe the scratch directories. > > In our network, we used `amd` and NIS (YP!) to get access to everyone's > home dir on every node. > > I rather liked the overall setup; it was nice. It became a deprecated > configuration on the move to Solaris 2.x: a workstation was either diskfull > or diskless. The idea of a compromise between the two extremes went away. > > - Dan C. This is how we run our clusters, but instead of NFS-mounting the system directories, it fetches a cpio archive and unpacks it into a RAM disk, then switches root to that. Any local disk is mounted as scratch space, home directories come from an NFS server, and the main working filesystem is a high-performance distributed filesystem. It works exceptionally well at the cost of whatever RAM is used to store the root filesystem -- these days, negligible. AFS is available but not much engaged by our users. Everything boots over PXE and entirely changing the purpose and loadout of a computer is one or two commands away. It's very pleasant. khm From tytso at mit.edu Wed Jul 22 13:13:13 2020 From: tytso at mit.edu (tytso at mit.edu) Date: Tue, 21 Jul 2020 23:13:13 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200721010411.GS26294@mcvoy.com> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> <20200721010411.GS26294@mcvoy.com> Message-ID: <20200722031313.GC1536749@mit.edu> On Mon, Jul 20, 2020 at 06:04:11PM -0700, Larry McVoy wrote: > On Mon, Jul 20, 2020 at 05:11:48PM -0500, Ed Carp wrote: > > On 7/20/20, Larry McVoy wrote: > > > > > Clem should pay attention, in my opinion, this is how you do Unix and > > > real time. Because Unix is time sharing and throughput, that is the > > > opposite of what real time is. Wedging real time into Unix is a mistake. > > > > Agreed. > > So many people get this wrong, they want to make "real time" in Unix "good > enough" and it messes with everything. Victor's idea was awesome. > > And you know what sucks? I was on the Usenix review committee and I gave > it 2 thumbs up but someone else, looking at you, Rob, said it was not > interesting because the real time kernel wasn't POSIX. Even though the > real time kernel had pipes, signals, and shared memory with Linux. > > He was a bigger deal than me so it didn't get published. > > I love the Rob in question, not Pike, but this was one of the most bone > headed calls I've ever seen him make. The world needed to see this. Never fear, Victor's work got published in a number of Linux conference, so it wasn't totally buried. > Wind River bought it and buried it because it competed with their stuff > that was nowhere near as good. I can't get into the mind of Wind River. but having worked on a commercial real-time extension to Linux, and having gotten a IBM Systems Journal publication[1] out of it, I have a slightly different perspective. [1] https://ieeexplore.ieee.org/document/5386551 The issue is that there aren't that many good real-time programmers Tavailable. Furthermore, many real-time applications need to do a lot more than data acquisition, so having access to POSIX API's in the real time task is very attractive. Sure, you can try to interchange information between the real-time task and the POSIX task, but that's a lot more complicated, and that's where the "not enough real-time programmers" rears its head again. This is even worse if you are working in a military application, since small population of "can program real-time programmers" is further reduced by "can get a security clearance". Fortunately, with modern, fast CPU's, it's possible to do real-time via brute force, and as it turns out, there are a very large number ofJ real-time tasks which can deal with real-time latency that are tens of milliseconds, at which point you even use real-time Java with a real-time garbage collector running on a real-time Linux. And that's what Raytheon and the US Navy chose to use on their Zumwalt Class destroyers, and that's how I and my team got the IBM Systems Journal publication. :-) Sure, there will be some number of real-time task which needs single-digit millisecond real-time guarantees --- in which case you can write it in C using Real-time Linux. And for those really cases where you need latencies which are in the tens of microsecnds; then yeah, at that point you might need specialized OS's. But the cases where you need fast, hard real-time is pretty rare compared to those cases where real-time Java is sufficient. Cheers, - Ted From gtaylor at tnetconsulting.net Wed Jul 22 13:27:59 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jul 2020 21:27:59 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: <20200722011603.GA1536749@mit.edu> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <20200722011603.GA1536749@mit.edu> Message-ID: On 7/21/20 7:16 PM, tytso at mit.edu wrote: > Yeah, that's definitely not right. /sbin had been around for > "essential system binaries" long before Linux, and Linux took it > from there. I'm sorry, I think there has been a misunderstanding. I did not mean to imply that Linux influenced the larger Unix community with /sbin. Rather the other way around, that that's the time that Linux had been influenced about /sbin. > You can see this from the Linux Filesystem Hierarchy Standard (earlier > named fsstnd, which specified /sbin as "essential system binaries"). I should revisit that, particularly in light of an older name and use. > SunOS used that nomenclature and the GNU tools all used /sbin for > that purpose. Did Solaris follow in SunOS's foot steps? Or did Solaris do something different? > The other thing I'd again urge is that you not take HJ Lu's boot/root > disks as being influencial after early 1992. Okay. I naively thought that HJ Lu's boot/root was falling out of favor in '93, a year later. Thank you for clarifying Warner. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Wed Jul 22 13:33:18 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jul 2020 21:33:18 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: <305889B3-25B5-4C28-BB84-57470D845BBF@pobox.com> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <305889B3-25B5-4C28-BB84-57470D845BBF@pobox.com> Message-ID: On Tue, Jul 21, 2020, 4:52 PM David Arnold wrote: > > On 22 Jul 2020, at 04:15, Warner Losh wrote: > > <…> > > > The root disks date from a time before Linux had shared libraries, I > thought, > > IIRC, Linux had two different shared library implementations? I haven’t > looked, and don’t remember the details, but it might have been linked to > the switch from a.out to ELF for executables? IIRC, the pre-ELF shared > libs were a hack on the a.out executable format. > Yes. Those were the SunOS like ones, but with weird address location quirks. Warner Not sure where that fits into the /etc vs. /sbin timeline. ISTR Linux was > somewhat inclined away from the BSD way of doing things (in favour of > Solaris/SVR4). > > > > > d > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jul 22 13:35:56 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jul 2020 21:35:56 -0600 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <20200722011603.GA1536749@mit.edu> Message-ID: On Tue, Jul 21, 2020, 9:30 PM Grant Taylor via TUHS wrote: > On 7/21/20 7:16 PM, tytso at mit.edu wrote: > > Yeah, that's definitely not right. /sbin had been around for > > "essential system binaries" long before Linux, and Linux took it > > from there. > > I'm sorry, I think there has been a misunderstanding. I did not mean to > imply that Linux influenced the larger Unix community with /sbin. > Rather the other way around, that that's the time that Linux had been > influenced about /sbin. > > > You can see this from the Linux Filesystem Hierarchy Standard (earlier > > named fsstnd, which specified /sbin as "essential system binaries"). > > I should revisit that, particularly in light of an older name and use. > > > SunOS used that nomenclature and the GNU tools all used /sbin for > > that purpose. > > Did Solaris follow in SunOS's foot steps? Or did Solaris do something > different? > > > The other thing I'd again urge is that you not take HJ Lu's boot/root > > disks as being influencial after early 1992. > > Okay. I naively thought that HJ Lu's boot/root was falling out of favor > in '93, a year later. Thank you for clarifying Warner. > I think it was Ted clarifying me :) Warner > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed Jul 22 13:41:03 2020 From: jsteve at superglobalmegacorp.com (Jason) Date: Wed, 22 Jul 2020 03:41:03 +0000 (UTC) Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: The emulator Shoebill can run A/UX https://github.com/pruten/Shoebill It’s pretty awesome. 3.0 is the last version that is stable(ish).  Naturally the MacOS installer won’t run so a bunch of Unix legwork is required. I’m not sure if this email will make the list but I’ll try.... Anyway the developer of Shoebill got snapped up by a certain fruit vendor so no updates... As for A/UX it’s SYSV with the c and fortran compilers built in.  Apparently it was going to be Steve’s “Big Mac” project that was sidelined after he was pushed out.  Although there is so many crazy rumours of that window at the end of Apple and the start of NeXT. On Sun, Jul 19, 2020 at 4:24 AM +0800, "Ed Carp" wrote: Oh, boy, now you've got me started. I worked on A/UX at Apple back around 1992. I'd love to find a copy of that! On 7/17/20, Michael Kjörling wrote: > Which, by the way, and also meeting your "25 years old or older" > criteria, looks like it would also include every version (with the > possible exception of the last version or so; that was 1995-1996) of > A/UX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed Jul 22 13:44:28 2020 From: jsteve at superglobalmegacorp.com (Jason) Date: Wed, 22 Jul 2020 03:44:28 +0000 (UTC) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> Message-ID: MachTen was interesting as heck to find.  I ran it on a LC recently and it was so slow.  I couldn’t work out how to build a linker, but I got a cross compiler (GCC) set your a sun-2 target and gas just worked fine letting me use my Xeon for cross compiling on NFS, and just linking on the Mac. With only a 68020 it’s just too slow, and with no mmu it’s just too unstable.   But the cool factor is awesome. Sadly my attempt at building gopher didn’t work so well. On Mon, Jul 20, 2020 at 8:33 PM +0800, "Derrik Walker v2.0" wrote: I used Mach10 and Later MkLinux as my UNIXy systems while in College before I got my first Sun Workstation in the mid ’90’s. Interestingly enough. MkLinux was actually ported to Old World PowerMacs by Apple and HP. I think they also made.a version PCs too. And Mach10 was interesting. Different. I also had Minix for the Mac, it worked much the same, as an app that sat onto of MacOS. - Derrik > On Jul 20, 2020, at 4:47 AM, arnold at skeeve.com wrote: > > ISTR that A/UX was nothing special as a Unix. Am I failing to remember? > > I had had a DMD 5620 at my job, and after I moved to a different place > and requested one, they graced me with a Macintosh. It could sort of > do multiple windows, but it was like having a piper cub after being > used to a 747. > > Other interesting bits for the Mac to maybe recover would be Mach Ten, > which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) > There was also a Mach/Linux that I think ran on the Mac at some point. > > Arnold > > Michael Parson wrote: > >> On 2020-07-18 23:42, Grant Taylor via TUHS wrote: >>> On 7/18/20 9:46 PM, Wesley Parish wrote: >>>> I'd still love to have that running. >>> >>> I think I've seen articles about people running it running >>> virtualization / emulation. >> >> As far as I've been able to find, there is only one emulator that can >> run A/UX, shoebill[0]. >> >> I've got a Mac Quadra 950 with a Workgroup Server 95 card in it in the >> garage that I've been planning on someday trying to get A/UX running on, >> but haven't found enough round tuits. >> >> Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE >> (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), >> A/UX might work there. >> >> -- >> Michael Parson >> Pflugerville, TX >> KF5LGQ >> >> [0] https://github.com/emaculation/shoebill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed Jul 22 13:50:28 2020 From: jsteve at superglobalmegacorp.com (Jason) Date: Wed, 22 Jul 2020 03:50:28 +0000 (UTC) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: MachTen runs as a background accessory on MacOS.  Apparently it’ll turn on mmu protection if you have one. But you are still able to run macOS software just fine. A/UX boots macOS, then loads a loader app that takes over the machine and boots the kernel.  The emulator Shoebill “cheats” and reads the kernel from the UFS disk directly and jumps to that. Previous (the emulator) runs all the versions of nextstep for the 68k machines but also supports the true colour card, along with i860 emulation. It’s pretty impressive what can be done with processors in the multiple GHz range with megabytes of l2/l3 cache. From: TUHS on behalf of Clem Cole Sent: Monday, July 20, 2020 10:30 PM To: Aharon Robbins Cc: The Eunuchs Hysterical Society Subject: Re: [TUHS] A/UX [was Linux is on-topic]  On Mon, Jul 20, 2020 at 4:49 AM wrote: Other interesting bits for the Mac to maybe recover would be Mach Ten, which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) Interesting (not sure I would say 'cool').  I saw running it once next to NeXT Cube when I was visiting some friends in the Mach group at CMU at some point. I had always been under the impression it just used MacOS 7 to load it and then took over the system.  But I never ran 'under it' as it were.  There was also a Mach/Linux that I think ran on the Mac at some point.I think I remember seeing that announced.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Jul 22 14:26:29 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 22 Jul 2020 00:26:29 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: On Tue, 21 Jul 2020 at 23:53, Jason wrote: > > A/UX boots macOS, then loads a loader app that takes over the machine and > boots the kernel. The emulator Shoebill “cheats” and reads the kernel from > the UFS disk directly and jumps to that. > > That was always really funny to me. Your machine boots MacOS, presumably because it was easier to let it deal with hardware initialization than to rewrite it, then hands control over to A/UX which promptly runs MacOS as a Unix process. Which you can kill. Oberlin College had a Workgroup Server 95, basically a repurposed Quadra 950, running as an AppleShare file server for a significant number of users. That was how Apple was marketing these things, and thinking about it - use our Unix to serve your MacOS boxes! But we have no real interest in Unix, just buy more MacOS boxes! See: Apple Network Server. I remember my father mentioning talking to someone from Apple at a USENIX, probably late '80s or very early '90s, and them admitting that A/UX was essentially a glorified public beta. That might have been in the A/UX 1.0 or 2.0 timeframe but it says a lot about the sorts of resources Apple was dedicating to the idea. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Jul 22 15:40:21 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 21 Jul 2020 22:40:21 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <20200722031313.GC1536749@mit.edu> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> <20200721010411.GS26294@mcvoy.com> <20200722031313.GC1536749@mit.edu> Message-ID: <8CA15A51-E251-40B9-BA6C-82063BCEC5F4@iitbombay.org> On Jul 21, 2020, at 8:13 PM, tytso at mit.edu wrote: > > The issue is that there aren't that many good real-time programmers > Tavailable. Furthermore, many real-time applications need to do a lot > more than data acquisition, so having access to POSIX API's in the > real time task is very attractive. Sure, you can try to interchange > information between the real-time task and the POSIX task, but that's > a lot more complicated, and that's where the "not enough real-time > programmers" rears its head again. > > ... > Sure, there will be some number of real-time task which needs > single-digit millisecond real-time guarantees --- in which case you > can write it in C using Real-time Linux. And for those really cases > where you need latencies which are in the tens of microsecnds; then > yeah, at that point you might need specialized OS's. But the cases > where you need fast, hard real-time is pretty rare compared to those > cases where real-time Java is sufficient. The approach taken by Massalin in their Synthesis Kernel seemed quite promising. By using runtime code synthesis they were able to run realtime music synthesis at 25Khz sampling rate on a 20Mhz 68K machine. Too bad these ideas didn't take off. I wanted to use similar ideas in lieu of code like netgraph (in FreeBSD) or N layers of networking code but no tools existed. Today, on a computing device your browser may freeze for a few seconds due to garbage collection or whatever. Seems to me, a bigger issue than not-enough-real-time-real-programmers is a lack of good real time programming abstractions and tools. No way to specify or test a timing budget or required maximum latency. There are things like CBQ (class based queueing) for managing traffci flows but no such general purpose support for mapping code to hardware to meet timing and latency requirements. From dwalker at doomd.net Wed Jul 22 22:23:56 2020 From: dwalker at doomd.net (Derrik Walker v2.0) Date: Wed, 22 Jul 2020 08:23:56 -0400 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <6528890D-947F-4393-8578-5B797AF6FF8E@doomd.net> Message-ID: It’s funny you mention how slow it can be. On a decent Mac with enough ram, it was fine. The later PowerPC native version, running on just about any new world Mac, was really fast. Having said that, running it via Mini vMac on my 2020 MacBook Air, it feels about 1 million times faster than on any physical Mac I ever ran it on. And Gopher …. There is a program I’ve not seen in a very long time. I remember in the early days of the Power Mac, Apple released this really cool 3D gopher client. It ran pretty well on the 6100 I had at the time. - Derrik > On Jul 21, 2020, at 11:44 PM, Jason wrote: > > MachTen was interesting as heck to find. I ran it on a LC recently and it was so slow. I couldn’t work out how to build a linker, but I got a cross compiler (GCC) set your a sun-2 target and gas just worked fine letting me use my Xeon for cross compiling on NFS, and just linking on the Mac. > > With only a 68020 it’s just too slow, and with no mmu it’s just too unstable. But the cool factor is awesome. > > Sadly my attempt at building gopher didn’t work so well. > > > > > > On Mon, Jul 20, 2020 at 8:33 PM +0800, "Derrik Walker v2.0" > wrote: > > I used Mach10 and Later MkLinux as my UNIXy systems while in College before I got my first Sun Workstation in the mid ’90’s. > > Interestingly enough. MkLinux was actually ported to Old World PowerMacs by Apple and HP. I think they also made.a version PCs too. > > And Mach10 was interesting. Different. I also had Minix for the Mac, it worked much the same, as an app that sat onto of MacOS. > > - Derrik > > > On Jul 20, 2020, at 4:47 AM, arnold at skeeve.com wrote: > > > > ISTR that A/UX was nothing special as a Unix. Am I failing to remember? > > > > I had had a DMD 5620 at my job, and after I moved to a different place > > and requested one, they graced me with a Macintosh. It could sort of > > do multiple windows, but it was like having a piper cub after being > > used to a 747. > > > > Other interesting bits for the Mac to maybe recover would be Mach Ten, > > which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) > > There was also a Mach/Linux that I think ran on the Mac at some point. > > > > Arnold > > > > Michael Parson wrote: > > > >> On 2020-07-18 23:42, Grant Taylor via TUHS wrote: > >>> On 7/18/20 9:46 PM, Wesley Parish wrote: > >>>> I'd still love to have that running. > >>> > >>> I think I've seen articles about people running it running > >>> virtualization / emulation. > >> > >> As far as I've been able to find, there is only one emulator that can > >> run A/UX, shoebill[0]. > >> > >> I've got a Mac Quadra 950 with a Workgroup Server 95 card in it in the > >> garage that I've been planning on someday trying to get A/UX running on, > >> but haven't found enough round tuits. > >> > >> Maybe if someone could rip the 680[34]0+MMU bits out of Win/FS-UAE > >> (Amiga emulator) and patch them into Basilisk II (Mac 68K emulator), > >> A/UX might work there. > >> > >> -- > >> Michael Parson > >> Pflugerville, TX > >> KF5LGQ > >> > >> [0] https://github.com/emaculation/shoebill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jul 22 23:30:05 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jul 2020 09:30:05 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: <66196367-0522-4636-8113-F829F6288153@gmail.com> References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <5489aab7-efb4-8bcd-3ca7-9b47e9b7b305@gmail.com> <66196367-0522-4636-8113-F829F6288153@gmail.com> Message-ID: On Tue, Jul 21, 2020 at 10:22 PM Adam Thornton wrote: > I miss AFS. > The server still runs on BSD. Ran it at home for a fairly long time. Its really too bad AFS 4.0 got mixed up in the Sun vs OSF wars and ended up as part of DCE as opposed to being its own technology. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jul 22 23:39:17 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jul 2020 09:39:17 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> Message-ID: On Tue, Jul 21, 2020 at 3:24 PM Clem Cole wrote: > > I think I may even have a memo or two from the discussion in a file > cabinet. > Just for grins, I peaked in a file I had last night. I found about 4-5 cm's thickness of the 'requirements for a next-gen kernel' documents from the UI kernel group. They went to dev null as they are so unuseful at this point and I'm short on filing space/my wife has been on me to weed. I did decide to save the who was on the committee page, that seems like it might have value. It was 1993, and Linux was just appearing, who knew? UI was backing the SRV4 ABI on top of Chorus as a reaction to OSF's Mach system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Wed Jul 22 23:43:58 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 22 Jul 2020 09:43:58 -0400 Subject: [TUHS] /bin vs /sbin In-Reply-To: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <5489aab7-efb4-8bcd-3ca7-9b47e9b7b305@gmail.com> <66196367-0522-4636-8113-F829F6288153@gmail.com> Message-ID: > Its really too bad AFS 4.0 got mixed up in the Sun vs OSF wars and ended > up as part of DCE as opposed to being its own technology. > OpenAFS is (still) a thing. Runs at Morgan-Stanley (or some other finsvc house) and is kept going, reasonably healthy, by hackers. www.openafs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jul 23 00:16:05 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Jul 2020 07:16:05 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <8CA15A51-E251-40B9-BA6C-82063BCEC5F4@iitbombay.org> References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720114957.GL26294@mcvoy.com> <20200721010411.GS26294@mcvoy.com> <20200722031313.GC1536749@mit.edu> <8CA15A51-E251-40B9-BA6C-82063BCEC5F4@iitbombay.org> Message-ID: <20200722141605.GK29892@mcvoy.com> On Tue, Jul 21, 2020 at 10:40:21PM -0700, Bakul Shah wrote: > On Jul 21, 2020, at 8:13 PM, tytso at mit.edu wrote: > > > > The issue is that there aren't that many good real-time programmers > > Tavailable. Furthermore, many real-time applications need to do a lot > > more than data acquisition, so having access to POSIX API's in the > > real time task is very attractive. Sure, you can try to interchange > > information between the real-time task and the POSIX task, but that's > > a lot more complicated, and that's where the "not enough real-time > > programmers" rears its head again. > > > > ... > > Sure, there will be some number of real-time task which needs > > single-digit millisecond real-time guarantees --- in which case you > > can write it in C using Real-time Linux. And for those really cases > > where you need latencies which are in the tens of microsecnds; then > > yeah, at that point you might need specialized OS's. But the cases > > where you need fast, hard real-time is pretty rare compared to those > > cases where real-time Java is sufficient. > > > The approach taken by Massalin in their Synthesis Kernel seemed quite > promising. One of the few CS PhD thesis worth reading. http://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesis.pdf From ches at cheswick.com Thu Jul 23 00:23:10 2020 From: ches at cheswick.com (William Cheswick) Date: Wed, 22 Jul 2020 10:23:10 -0400 Subject: [TUHS] Bell Labs Sysadmins In-Reply-To: References: Message-ID: Yep. I was postmaster in MH starting in early 1988. ches > On Jul 21, 2020, at 6:19 PM, Henry Bent wrote: > > Are there any former Bell Labs sysadmins on this list? My father was the sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the mid-late '80s and early '90s and I would be especially interested to hear from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and the like. I'm very curious about what life was like on the ground, so to speak. From mparson at bl.org Thu Jul 23 02:15:30 2020 From: mparson at bl.org (Michael Parson) Date: Wed, 22 Jul 2020 11:15:30 -0500 Subject: [TUHS] Linux is on-topic In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> Message-ID: On 2020-07-21 22:41, Jason wrote: > The emulator Shoebill can run A/UX > https://github.com/pruten/Shoebill > > It’s pretty awesome. > > > 3.0 is the last version that is stable(ish).  Naturally the MacOS > installer won’t run so a bunch of Unix legwork is required. > I’m not sure if this email will make the list but I’ll try.... > Anyway the developer of Shoebill got snapped up by a certain fruit > vendor so no updates... Guess that explains why he's not touched it since 2014. The 'emaculation' github account[0] seems to be where the primary dev work on it is being done now, but seems to be slow going, the last commit was Sept 2019. > As for A/UX it’s SYSV with the c and fortran compilers built in. >  Apparently it was going to be Steve’s “Big Mac” project that was > sidelined after he was pushed out.  Although there is so many crazy > rumours of that window at the end of Apple and the start of NeXT. -- Michael Parson Pflugerville, TX KF5LGQ [0] https://github.com/emaculation/shoebill From scj at yaccman.com Thu Jul 23 14:13:21 2020 From: scj at yaccman.com (scj at yaccman.com) Date: Wed, 22 Jul 2020 21:13:21 -0700 Subject: [TUHS] AT&T Research In-Reply-To: <20200711203020.GA1884@minnie.tuhs.org> References: <20200711203020.GA1884@minnie.tuhs.org> Message-ID: <03a8a0a84960ca40be4ea04b5cd1d780@yaccman.com> I think that's an interesting topic. I interned at BTL for three summers before coming on permanently in 1967. At the time, it was running an IBM 7090 (later 7094) with a home-grown operating system. Punched card decks were put on mag tape and fed to the system in batches. There was no memory protection, so after running one job the system would checksum itself to make sure it was sane. At one point, someone was testing a sort routine that ran amock and sorted a good portion of the OS, but not the checksum routine, which did an exclusive OR of the instructions and attempted to run the next job. The instruction core dump was quite amusing. One of the first computer games I became aware of happened on that mainframe. It was called "Darwin", and was a contest. Each contestant submitted a card deck, and there was a monitor that ran the program--its object was to attack other programs by returning an address. If the address was protected, you died and the other program reproduced itself in your place. Otherwise, they died and you reproduced yourself. The game ran for several weeks until a program described to me as "all teeth, claws and sex organs" proved to be unbeatable. In my opinion, the initial view of Unix at Bell Labs was quite negative. After all, these were the people who promised Multics with great hype and failed to deliver. When I started work in 1067, I was given a memo that began "In six months, we expect the dominant programming language at Bell Labs to be PL/1." There were some amazing simulation programs written in assembler with macros -- all of these were lost when the comp center pushed everyone on to FORTRAN. I actually think it was a good thing that Unix in the early days was not taken seriously. Having users is a mixed blessing when the rate of change was rapid. For example, the transition from B to C to C with strong typing would have driven most application developers bonkers when they were trying to serve their customers. One of the things that got me interested in management was visiting a number of groups with my then boss, Eliot Pinson, to try to "sell" Unix. It was amazing to me that some groups that urgently needed it were unwilling to try it, while groups that were doing just fine without it embraced it and ran with it. The technical people I met all seemed competent -- it must be the management that was the difference... --- On 2020-07-11 13:30, Warren Toomey wrote: > On Sat, Jul 11, 2020 at 11:36:35AM -0400, Clem Cole wrote: >> https://spinroot.com/pico/watertower.jpg > > So there's a question. Obviously all the anecdotes I've heard about > Bell Labs have come from Unix people. But there were many others > working and researching there. > > How was the interaction between the Unix people and the non-Unix people > at the Labs? Especially when Unix became "big"? Did the non-Unix people > also pull pranks like the watertower? > > Cheers, Warren From arnold at skeeve.com Thu Jul 23 16:02:04 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 23 Jul 2020 00:02:04 -0600 Subject: [TUHS] Technical decisions based on political considerations [was Re: AT&T Research] In-Reply-To: <03a8a0a84960ca40be4ea04b5cd1d780@yaccman.com> References: <20200711203020.GA1884@minnie.tuhs.org> <03a8a0a84960ca40be4ea04b5cd1d780@yaccman.com> Message-ID: <202007230602.06N6243i013099@freefriends.org> scj at yaccman.com wrote: > The technical people I met all seemed > competent -- it must be the management that was the difference... I saw this *a lot* when I worked at Intel; being forced to use the wrong tools for software development because of political considerations instead of technical ones. One of the reasons I was super glad to leave there and why I think that Intel as a whole will never make it as a software company. (There are pockets there that understand software, but the majority of the company does not.) Sorry, Arnold From lm at mcvoy.com Fri Jul 24 00:42:36 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Jul 2020 07:42:36 -0700 Subject: [TUHS] Technical decisions based on political considerations [was Re: AT&T Research] In-Reply-To: <202007230602.06N6243i013099@freefriends.org> References: <20200711203020.GA1884@minnie.tuhs.org> <03a8a0a84960ca40be4ea04b5cd1d780@yaccman.com> <202007230602.06N6243i013099@freefriends.org> Message-ID: <20200723144236.GK21077@mcvoy.com> Amen to both comments. Especially Intel, I'm so happy to not be dealing with them. Just an example, they used Netapp's mirroring stuff - stuff that says in big bold letters "Mirrors are read only, you may not write to them". Of course they wrote to them and it didn't go well. They were using BitKeeper and they cloned a repo to a mirror. A clone in BK is basically ( cd from; tar cf - . ) | (mkdir to; cd to; tar xf -; bk repocheck) It is more complicated than that, it doesn't do a tar, it finds all the SCCS files and transfers those and a handful of etc files. And it has a bill of materials file that lists all the SCCS files. So a repocheck is sort of like find . -name 's.*' | check that list against the bill of materials When we unpacked the files and went to go look for them, half the files that we just wrote were "not there". They were there but there were no entries for them in the directory so it looked like they were not there. Intel said that BitKeeper was broken. For 3 months. After I gave them scripts that replicated what BitKeeper was doing but had no BitKeeper in them. After tuning those scripts so their so-called filer validation team could use them as a test system to verify that the filers worked. As a kernel guy, I did the most in depth work in file systems. I know what I'm talking about. But Intel said it was all Bitkeeper's fault. It wasn't, it was just that BitKeeper was the only application they had that did integrity checks. They finally backed down when I called Steve Kleinman who was CTO at Netapp and my mentor at Sun, he immediately said yeah, I know, it's us, that mirror shit sucks. And he called Intel. Intel is just an awful company. I know they pay Clem's bills, go Cleam, but Intel sucks. On Thu, Jul 23, 2020 at 12:02:04AM -0600, arnold at skeeve.com wrote: > scj at yaccman.com wrote: > > > The technical people I met all seemed > > competent -- it must be the management that was the difference... > > > I saw this *a lot* when I worked at Intel; being forced to use > the wrong tools for software development because of political > considerations instead of technical ones. One of the reasons I > was super glad to leave there and why I think that Intel as a > whole will never make it as a software company. (There are pockets > there that understand software, but the majority of the company > does not.) > > > Sorry, > > Arnold -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From doug at cs.dartmouth.edu Fri Jul 24 04:33:23 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 23 Jul 2020 14:33:23 -0400 Subject: [TUHS] Groff on Windows (for PDF output)? Message-ID: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Echoing other answers, I regularly use groff in Cygwin. If you're into Unix/Linux, Cygwin is a great tool with a remarkably clean installation process. I use default PostScript output by choice, because I can tinker with PostScript but not with PDF. ps2pdf (available from Cygwin) has always worked when I need PDF. I must admit, tough, that this approach will be pretty onerous if you do not want Cygwin for any other reason. And I should add that PoscScript requires a special viewer; I use gsview. Doug From gtaylor at tnetconsulting.net Fri Jul 24 06:51:29 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 23 Jul 2020 14:51:29 -0600 Subject: [TUHS] Groff on Windows (for PDF output)? In-Reply-To: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> References: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Message-ID: On 7/23/20 12:33 PM, Doug McIlroy wrote: > I must admit, tough, that this approach will be pretty onerous if > you do not want Cygwin for any other reason. Do you have any idea how Windows Subsystem for Linux compares to Cygwin? For this use case and / or in general? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From cowan at ccil.org Fri Jul 24 08:35:06 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 23 Jul 2020 18:35:06 -0400 Subject: [TUHS] Groff on Windows (for PDF output)? In-Reply-To: References: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Message-ID: On Thu, Jul 23, 2020 at 4:52 PM Grant Taylor via TUHS wrote: > Do you have any idea how Windows Subsystem for Linux compares to Cygwin? > For this use case and / or in general? > Very short version: First, Windows is a layered OS. At the bottom is the NT Executive, a fairly conventional kernel. Running on top of that is the Win32 subsystem (note that this name is used for both 32-bit and 64-bit windows). Peers of Win32 have existed in the past, notably an OS/2 subsystem and a Posix-compatible third-party subsystem. Cygwin is a shim DLL that provides a Posix environment to programs running in the Win32 layer of Windows. It is fairly source-code compatible with Linux. Cygwin programs and ordinary Windows programs can coexist freely. In particular, they share the same filesystems, and Cygwin programs understand both Posix and Windows pathnames (where C: is mapped to /cygdrive/c). Most Cygwin APIs are implemented using Win32 APIs, but some require NT Executive APIs. WSL version 1 is a Linux kernel emulator running on the NT Executive. It is binary-compatible with Linux (but not with 32-bit Linux programs) as a result, and gets special services from the Executive, including lightweight processes. (Win32 processes are very heavyweight, which makes long shell scripts like ./configure quite slow on Cygwin.) There is an X server called Cygwin/X; any other X server for Windows can also be used. Interoperation allows WSL1 to mount Win32 file systems and exec() Win32 programs (the lightweight process is upgraded to a Win32 process). WSL1 and Win32 share the same TCP and UDP port space. Unfortunately, a WSL1 program that tries to invoke a Linux kernel operation not yet supported by the emulator will crash. The Linux file system is stored in a dedicated section of the Win32 file system; files stored there can be read by Win32 programs but not written. There is no X server, but once again Cygwin/X or alternatives can be used on the Win32 side. WSL version 2, which is very new, is an ultra-lightweight VM that can run a Linux kernel. This means that all kernel services are automatically provided. The filesystem is a virtual disk formatted as ext4, which gives WSL2 much better local filesystem performance than WSL1. The same interoperations exist as for WSL1, except that the VM has a different IP address from the Win32 system, so ports are not shared. The filesystems are fully shared through the 9P2000 (yes!) protocol, allowing Linux to mount Win32 filesystems and vice versa. Unfortunately the 9P support is not exposed to users. This may indeed be the year of Linux on the (Windows) desktop. (Comments and corrections always welcome.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Fri Jul 24 10:01:01 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 23 Jul 2020 17:01:01 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: <31bad2be-a67c-aa2f-a479-d7434955d271@bitsavers.org> References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <2966979D-066B-408E-A4D7-D0F50BE14109@cfcl.com> <661b03fd-83c6-0941-74bd-ac1c712f58ed@bitsavers.org> <31bad2be-a67c-aa2f-a479-d7434955d271@bitsavers.org> Message-ID: <89091667-C3E8-4FC1-A125-CC0E0755412E@eschatologist.net> On Jul 20, 2020, at 12:49 PM, Al Kossow wrote: > I also had one of the few copies of MacMach that ran on a IIfx. > No one in Cupertino was very interested in Mach. I really wish this had been preserved. MacMach from what I saw meeting the last of the people involved at CMU in 1993-4 was a lot like A/UX in having System 6 as a process under Mach with BSD either colocated or running as a single server. I have a friend who still had one of CMU's distribution CD right up until a couple years ago, when he trashed a bunch of stuff to move to another continent. :( If anyone else has one, it'd be news to me. The closest I have is an image of the bootstrap floppy; you normally got MacMach on campus by booting from a floppy that would start up a minimal Mach+BSD+shell; you would boot it, configure TCP/IP, partition your disk, and then SUP the rest of the distribution. -- Chris From clemc at ccc.com Fri Jul 24 10:13:57 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Jul 2020 20:13:57 -0400 Subject: [TUHS] Groff on Windows (for PDF output)? In-Reply-To: References: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Message-ID: On Thu, Jul 23, 2020 at 4:52 PM Grant Taylor via TUHS wrote: > On 7/23/20 12:33 PM, Doug McIlroy wrote: > > I must admit, tough, that this approach will be pretty onerous if > > you do not want Cygwin for any other reason. > > Do you have any idea how Windows Subsystem for Linux compares to Cygwin? > For this use case and / or in general? > The short answer is that Cygwin can never work as well as WSL because it's layered on top of Windows and has to map. So the API is inherently only as good as what Windows presents to the user. Which is often good enough... but it is incomplete and different workarounds are needed. When I was as DEC I was involved with the whole story ... so let me pull much of the rest of the answer from my Quora answer to is 'Windows POSIX compliant'[1]. The long answer is this…. In the late 1990’s US Gov with the FIPS-151 standard, required all systems sold to the US Government be “POSIX” compliant [details of much of this is spelled out in John Quarterman's book UNIX, POSIX, and Open Systems ]. At one time after the publishing of FIPS-151, the US Air Force tender a bid that DEC and Microsoft wanted to chase with NT/Alpha. Microsoft/DEC (having only completed that *.1 interface with their POSIX subsystem), and did win the tender. Unisys sued saying that *.1 only subsystem, was not the spirit of the requirement. Microsoft’s defense was that they had built the API and that they were enabling 3rd parties to do the userspace work since their own user space was Windows and its Win32API. In the end, Microsoft/DEC was allowed to proceed provided a 3rd party appeared to fill that hole by some date (I’ve forgotten the details). In effect, they were required to produce a fully functioning POSIX based NT system by said date. To meet the requirement, Microsoft cut a deal with a small firm (Softway Systems - our old friend from Univ of Toronto, Steve Walhi for other old-time-Unix folks) to develop the same which was released as Softway’s “Interix” product. Which in fact, did not suck For real UNIX types like me, Steve and the team made Windows bear-able and frankly has fewer 'strangeness' that later/other UNIX for windows efforts because the Softway solution actually lives side-by-side with Windows as an NT client, so it calls the NT uKernel directly. *i.e.* it does not use the Window API under the covers (Cygin, UWIN, *et al* - sit on top of the Win32S so are ultimately limited to what features and conventions Windows provide under the covers). The Softway folks actually had sources to NT from Microsoft and added some missing APIs (for instance NT’s file system has always support hard and softlinks, but Win32S does not have calls to create them). The fixes/changes were then taken back and released in Windows updates as needed. The original commands were primarily taken from FreeBSD and Gnu as needed, and all of the “open source” requirements were met - in that anything that Softway had taken with a GPL was made available (which was only userspace code, such as gcc and its libraries). Because it is a microkernel, the POSIX subsystem and NT share the native file system. A problem is that UNIX (Posix) file permissions are not as refined as NT's, so there are things that the subsystem can not do, because it does not have a mechanism to do it. But it means, that as a user, you could compile run POSIX code as expected without any real mapping. So primary issue when “porting” code from a “real UNIX” such as Solaris, Tru64, or a Linux distro; tended to be that the NT file system supports a different security model than POSIX requires and POSIX APIs do not have ways of supporting some of those features. Eventually, Microsoft bought Steve and the Softway folks and brought the Interix product in-house, released it as SFU - Services for Unix, and later renamed it SUA - Subsystem for UNIX-based Applications. However, in Windows 8, SUA was depreciated and then later removed it from Windows 8.1. Starting with Windows 10, Microsoft (re)released it as WSL - Windows Subsystem for Linux, which resurrected the subsystem, but working with Canonical, make the API a Linux API and the commands based on Linux (Debian) versions instead of FreeBSD. The Linux kernel emulation was “clean room” and based on the earlier code, so none of that is tainted by the GPL. But anything in userspace that uses GPL is again available for download per the GPL licenses. You can recompile locally, although I believe that intentions were that userspace binaries from an Ubuntu 14.04 image are supposed to be able to run as-is under the subsystem. Changes in userspace code were really to make the command interact in a manner that is easier to utilize the base NTFS and live reasonably on the same uKernel side-by-side with a Win10 subsystem. Also remember POSIX never defined X-windows, so that was always interesting. When Interix was released there were a number of X-Windows systems for NT. Those days, Hummingbird was the most popular. However, Softway (and later Microsoft) was always careful to ensure that it did not matter which X subsystem you ran. Today the Cygwin/X is what most people use if you need to use X under Windows (NT). Since WSL runs side-by-side, it all 'just works' (and I say, don't suck). So coming back to it, WSL tends to have fewer 'rough edges' than Cygwin because it really is UNIX (Linux) under the covers, not trying to force Windows into doing its will by trying to map UNIX (Linux) into Win32S (or Win64). But, in all cases, UWIN, Cygwin or WSL, the file namespace is the same and shared (*i.e.* one disk file system), although windows are needed to support some (permission) style operations that POSIX never defined. My experience with the subsystem, if you plan to run it, then I would also recommend not using some of the NT file system (well Culter/VMS-ism to be more specific) additions, as UNIX (Linux) programs can get confused. [But a few of us ex-DEC Unix types have fought with Culter about those differences since the 1980s, so that's nothing new]. Anyway, my own experience is IF you have to use Windows 10, WSL pretty much 'just works.' We do a lot a Linux and Windows mixed work at Intel, and many (??most??) people turn it on and stopped using MKS/UWIN/Cygwin if they had to deal with Windows 10. That said, my personal solution for a number of years is to try to not use Windows at all, and run Mac OS, which is a different set of issues but at least for a old-time UNIX guy, less troublesome. Clem [1] https://www.quora.com/Is-Windows-POSIX-compliant/answer/Clem-Cole which might be worth reading the comments. Basically the guys at Microsoft have pointed out I tell the story as it happened, which is not surprising since I was a player on the DEC side when it all went down. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Fri Jul 24 10:10:59 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 23 Jul 2020 17:10:59 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717180831.5D4AB43F88@lignose.oclsc.org> <20200717195358.GA14847@minnie.tuhs.org> <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> Message-ID: <382061AD-AD33-4D03-93A0-8A02B4CBE31A@eschatologist.net> On Jul 21, 2020, at 9:26 PM, Henry Bent wrote: > > That was always really funny to me. Your machine boots MacOS, presumably because it was easier to let it deal with hardware initialization than to rewrite it This is actually because the Mac OS is already in the middle of booting, because big chunks of it were ROM-resident. The ROM didn't just exist as a bootstrap loader for any OS; it was a subset of the OS that just loaded more of itself, replaced parts of itself, etc. This only ended with the adoption of Open Firmware by the "New World" PCI-based Power Macintosh series. Even there, the second-stage bootstrap invoked by Open Firmware to get Mac OS up and running was actually a file on disk named "Mac OS ROM." -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Fri Jul 24 10:18:26 2020 From: paul at rileyriot.com (Paul Riley) Date: Fri, 24 Jul 2020 08:18:26 +0800 Subject: [TUHS] V6 Console IO Message-ID: I am using C in V6 to create a Forth compiler. I don;t have any interest in Forth as a general purpose language, however I do like it. It's satisfying to create a language from the ground up. I'm interested in it a simple and extensible interpreted language for toying with my PDP-11s, so I'll have some with it in the future. I have a very basic problem. I am simply using getchar and putchar for console IO, which is convenient indeed. I'm struggling however with how C processes the IO. It seems that when I type at the console, my typing is immediately echoed to my terminal window. When I press backspace the system responds with the character that was deleted, which is fine, as I assume it was from the paper teletype days. However, my code is receiving input and also echoing the output, but nothing appears on the terminal until I press enter, when the system displays the whole line of input, which is essentially a duplicate of what the terminal originally displayed, but with the consolidated edits. My code is reading and echoing the input character by character. Here's my question. How can I suppress the original C/Unix echo, and get my output to appear immediately? This simple sample code form the C programming manual behaves the same. int main() { int c; while ((c = getchar()) != EOF) { putchar(c); } } Paul *Paul Riley* Mo: +86 186 8227 8332 Email: paul at rileyriot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Fri Jul 24 10:04:51 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 23 Jul 2020 17:04:51 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: On Jul 20, 2020, at 2:02 PM, John Cowan wrote: > > The window had checkboxes corresponding to the options and text fields corresponding to their values, if any. I can't remember if it parsed the output of --help or equivalent, though. It was all driven by data custom-created for each command, it wasn't done by parsing -h (no --help in those days) or man pages. That would've been some combination of research project and nightmare. (It also wasn't done the VMS way, by having a nice set of libraries for defining commands and their arguments and flags and how to parse them.) > I also don't recall if such commands were supported in pipelines, though I see no reason why they should not have been. At least in Macintosh Programmer's Workshop, what Commando produced for you was the command line invocation, not the actual running process. So you'd type a command, invoke Commando, and when you clicked OK the command line you were entering would be updated with what you'd selected in the dialog box. -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Fri Jul 24 10:02:03 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 23 Jul 2020 17:02:03 -0700 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <20200717195718.GM18565@mcvoy.com> <77c0536b-87b8-44dd-96fd-76d8ceba30f2@localhost> <2135afdb-db52-05d2-9af6-24ad36367db3@tnetconsulting.net> <40a70393-894a-4b21-8678-a71bbca4aa69@localhost> <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> Message-ID: <7EE9FFEE-E116-472F-8497-C2B7B5F3FA3D@eschatologist.net> On Jul 20, 2020, at 1:20 PM, Ed Carp wrote: > > Except that it had a rudimentary option completion feature that was > sort of cool. When you typed "ls", for example, it would pop up a > window that would show you all the options that you could select for > that command. That was new and different. Too bad it didn't stick > around. You had to invoke Commando, it didn't pop up automatically as that'd be annoying as all heck. Commando was also an integral part of Macintosh Programmer's Workshop, and extremely useful there for figuring out the various commands and options. -- Chris From jnc at mercury.lcs.mit.edu Fri Jul 24 12:28:07 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Jul 2020 22:28:07 -0400 (EDT) Subject: [TUHS] V6 Console IO Message-ID: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> > From: Paul Riley > I'm struggling however with how C processes the IO. It seems that when I > type at the console, my typing is immediately echoed to my terminal > window. ... nothing appears on the terminal until I press enter, when > the system displays the whole line of input ... How > can I suppress the original C/Unix echo, and get my output to appear > immediately? This is not a C issue; it's the Unix I/O system (and specifically, terminal I/O). Normally, Unix terminal input is done line-at-a-time: i.e. the read() call to the OS (whether for 1 character, or a large number) doesn't return until an enire line has been typed, and [Retrurn] has been hit; then the entire line is available. While it's being buffered by the OS, echoing is done, and rubout processing is also performed. One can suppress all this; there's a mode call 'raw' (the normal mode is sometime labelled 'cooked') which suppresses all that, and just gives one the characters actually typed, as they are typed. The stty() system call can be used to turn this on. See the V6 tty(IV) manual entry for more. stty() is in stty(II). Noel From lm at mcvoy.com Fri Jul 24 12:57:12 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 23 Jul 2020 19:57:12 -0700 Subject: [TUHS] V6 Console IO In-Reply-To: References: Message-ID: <20200724025712.GL10855@mcvoy.com> > int main() { > int c; > while ((c = getchar()) != EOF) { > putchar(c); > } > } int main() { int c; char C; while ((c = getchar()) != EOF) { C = c; write(1, &C, 1); } } From paul at rileyriot.com Fri Jul 24 14:41:38 2020 From: paul at rileyriot.com (Paul Riley) Date: Fri, 24 Jul 2020 12:41:38 +0800 Subject: [TUHS] V6 Console IO In-Reply-To: <20200724025712.GL10855@mcvoy.com> References: <20200724025712.GL10855@mcvoy.com> Message-ID: Larry, Thanks for that. The documentation for putchar says that it only puts the low byte of the argument, so I assume that passing an int is ok. Paul *Paul Riley* On Fri, 24 Jul 2020 at 10:57, Larry McVoy wrote: > > int main() { > > int c; > > while ((c = getchar()) != EOF) { > > putchar(c); > > } > > } > > int > main() > { > int c; > char C; > > while ((c = getchar()) != EOF) { > C = c; > write(1, &C, 1); > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Fri Jul 24 14:54:16 2020 From: paul at rileyriot.com (Paul Riley) Date: Fri, 24 Jul 2020 12:54:16 +0800 Subject: [TUHS] V6 Console IO In-Reply-To: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: Noel, Thanks for your reply. I had suspected that the Unix behaviour was responsible, and you've made that clear with the "line at a time" assertion. I tried removing echo in STTY, but haven't tried raw. Paul *Paul Riley* Mo: +86 186 8227 8332 Email: paul at rileyriot.com On Fri, 24 Jul 2020 at 10:28, Noel Chiappa wrote: > > From: Paul Riley > > > I'm struggling however with how C processes the IO. It seems that > when I > > type at the console, my typing is immediately echoed to my terminal > > window. ... nothing appears on the terminal until I press enter, > when > > the system displays the whole line of input ... How > > can I suppress the original C/Unix echo, and get my output to appear > > immediately? > > This is not a C issue; it's the Unix I/O system (and specifically, > terminal I/O). > > Normally, Unix terminal input is done line-at-a-time: i.e. the read() call > to > the OS (whether for 1 character, or a large number) doesn't return until an > enire line has been typed, and [Retrurn] has been hit; then the entire > line is > available. While it's being buffered by the OS, echoing is done, and rubout > processing is also performed. > > One can suppress all this; there's a mode call 'raw' (the normal mode is > sometime labelled 'cooked') which suppresses all that, and just gives one > the > characters actually typed, as they are typed. The stty() system call can be > used to turn this on. > > See the V6 tty(IV) manual entry for more. stty() is in stty(II). > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Fri Jul 24 14:54:40 2020 From: paul at rileyriot.com (Paul Riley) Date: Fri, 24 Jul 2020 12:54:40 +0800 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724025712.GL10855@mcvoy.com> Message-ID: Sorry, I see you used "write". *Paul Riley* On Fri, 24 Jul 2020 at 12:41, Paul Riley wrote: > Larry, > > Thanks for that. The documentation for putchar says that it only puts the > low byte of the argument, so I assume that passing an int is ok. > > Paul > > *Paul Riley* > > > On Fri, 24 Jul 2020 at 10:57, Larry McVoy wrote: > >> > int main() { >> > int c; >> > while ((c = getchar()) != EOF) { >> > putchar(c); >> > } >> > } >> >> int >> main() >> { >> int c; >> char C; >> >> while ((c = getchar()) != EOF) { >> C = c; >> write(1, &C, 1); >> } >> } >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jul 25 00:01:38 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 24 Jul 2020 07:01:38 -0700 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724025712.GL10855@mcvoy.com> Message-ID: <20200724140138.GD11199@mcvoy.com> Yeah, write is unbuffered though I think Noel is correct, it's going to a tty and the tty will buffer until \n So you probably have to set the tty in raw mode (sorry that I'm vague, I never ran V6). On Fri, Jul 24, 2020 at 12:54:40PM +0800, Paul Riley wrote: > Sorry, I see you used "write". > > *Paul Riley* > > > > On Fri, 24 Jul 2020 at 12:41, Paul Riley wrote: > > > Larry, > > > > Thanks for that. The documentation for putchar says that it only puts the > > low byte of the argument, so I assume that passing an int is ok. > > > > Paul > > > > *Paul Riley* > > > > > > On Fri, 24 Jul 2020 at 10:57, Larry McVoy wrote: > > > >> > int main() { > >> > int c; > >> > while ((c = getchar()) != EOF) { > >> > putchar(c); > >> > } > >> > } > >> > >> int > >> main() > >> { > >> int c; > >> char C; > >> > >> while ((c = getchar()) != EOF) { > >> C = c; > >> write(1, &C, 1); > >> } > >> } > >> > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Sat Jul 25 00:33:20 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 24 Jul 2020 10:33:20 -0400 (EDT) Subject: [TUHS] V6 Console IO Message-ID: <20200724143320.18E9C18C073@mercury.lcs.mit.edu> > From: Larry McVoy > Yeah, write is unbuffered though I think Noel is correct, it's going to > a tty and the tty will buffer until \n The 'wait until newline' is on the input side. Output is buffered (in the sense that characters are held in the kernel until the output device can take them); but normally output will start to happen as soon as the device is able to take them. Only a certain amount can be buffered though, after that (the 'high water', I think it's called), the process is blocked if it tries to do output, and awakened when the buffered output level goes past the 'low water' mark. Note that getchar() and putchar() are subroutines in a library; looking at the source: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/getchr.s you can see how they relate to the actual read/write calls to the OS. > So you probably have to set the tty in raw mode Probably best to run such programs from something other than the main console, because if there's a bug in the program, and the terminal is in raw mode, if you're on the console, you may have to reboot the system to regain control of the system. (Interrupt characters, ^D etc won't work.) > (sorry that I'm vague, I never ran V6). Tnat's OK, I pretty much have the V6 kernel memorized, from working with it back in the day... :-) Noel From clemc at ccc.com Sat Jul 25 00:34:53 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Jul 2020 10:34:53 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa wrote: > ... > This is not a C issue; it's the Unix I/O system (and specifically, > terminal I/O). > ... One can suppress all this; there's a mode call 'raw' > Just be sure to turn raw mode off so canonization is performed again after your program stops running. Remember this a 'system wide' settings for that try and all programs start to use that setting. So if some reason, your program stops and a new program (like the shell) takes back over input from the try, if you do not have a way to get it back you are screwed. Back in the day, I have a shell script in my path stored in ~/.bin called: ft (fix tty) which called the stty command with the way I wanted the terminal to be set up. Thus is I was running a program that core dumped and left the try in raw mode, if I could find a way to run the ft script (usually by typing ^Jft^J ) life was good again. Paul, as an exercise why would ft not be good enough? (hint read and study the section 4 man page for stty) FWIW: is how the original UCB ex/vi and Cornell's Fred editors for v6 works by the way. I suspect that iyou look at any of the video editors of the day it will show you the details. One of the differences between V7 and earlier UNIX tty handlers was that they tty canonization was split into multiple parts. Also the other hint with Sixthedition's version of raw and cooked modes, you get all or nothing so you if you turn on raw, your program, will have do things like backspace processing, *etc*.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 25 00:36:40 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Jul 2020 10:36:40 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: <20200724143320.18E9C18C073@mercury.lcs.mit.edu> References: <20200724143320.18E9C18C073@mercury.lcs.mit.edu> Message-ID: On Fri, Jul 24, 2020 at 10:34 AM Noel Chiappa wrote: > I pretty much have the V6 kernel memorized, from working with > it back in the day... :-) > Amen bro -- not sure if we should be proud or ashamed of that use of brain cells. -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Sat Jul 25 02:37:59 2020 From: random832 at fastmail.com (Random832) Date: Fri, 24 Jul 2020 12:37:59 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: <3b4e50f0-5ab9-4726-99a3-b39568b2a7bb@www.fastmail.com> On Fri, Jul 24, 2020, at 00:54, Paul Riley wrote: > Noel, > > Thanks for your reply. > > I had suspected that the Unix behaviour was responsible, and you've > made that clear with the "line at a time" assertion. I tried removing > echo in STTY, but haven't tried raw. You'll have a hard time exiting your program if you use raw mode - cbreak should be enough, and in that case ctrl-c will still work [but even in cbreak mode I believe there is no way to send "EOF".] From clemc at ccc.com Sat Jul 25 03:15:58 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Jul 2020 13:15:58 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: <3b4e50f0-5ab9-4726-99a3-b39568b2a7bb@www.fastmail.com> References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> <3b4e50f0-5ab9-4726-99a3-b39568b2a7bb@www.fastmail.com> Message-ID: On Fri, Jul 24, 2020 at 12:39 PM Random832 wrote: > On Fri, Jul 24, 2020, at 00:54, Paul Riley wrote: > > Noel, > > > > Thanks for your reply. > > > > I had suspected that the Unix behaviour was responsible, and you've > > made that clear with the "line at a time" assertion. I tried removing > > echo in STTY, but haven't tried raw. > > You'll have a hard time exiting your program if you use raw mode - cbreak > should be enough, and in that case ctrl-c will still work [but even in > cbreak mode I believe there is no way to send "EOF".] > There is no such thing as cbreak in sixth edition. http://man.cat-v.org/unix-6th/1/stty It's raw or cooked. Life is more interesting ;-) Good luck -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Sat Jul 25 04:29:21 2020 From: random832 at fastmail.com (Random832) Date: Fri, 24 Jul 2020 14:29:21 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Mon, Jul 20, 2020, at 14:07, Will Senn wrote: > On 7/20/20 12:52 PM, Clem Cole wrote: > > > > > > On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: > >> My questions for y'all are how would you go about doing this? Use vi to delete everything through the ==== cut here line? > > Yep > Nice, seemed easy enough to me, but I was expecting real Unix folks use > sed | awk | indent type answers. For whatever it's worth, you can do the exact same thing as vi with sed in this case: 1,/====/d I wasn't there, so I can't say if this was done in practice or if there was even enough uniformity in the markers for it to be reliable in theory [perhaps /^#!/,$p ?] From will.senn at gmail.com Sat Jul 25 04:46:00 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 24 Jul 2020 13:46:00 -0500 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: <83465487-ed5e-8d1c-91e3-a201ccda6464@gmail.com> On 7/24/20 1:29 PM, Random832 wrote: > On Mon, Jul 20, 2020, at 14:07, Will Senn wrote: >> On 7/20/20 12:52 PM, Clem Cole wrote: >>> >>> On Mon, Jul 20, 2020 at 1:25 PM Will Senn wrote: >>>> My questions for y'all are how would you go about doing this? Use vi to delete everything through the ==== cut here line? >>> Yep >> Nice, seemed easy enough to me, but I was expecting real Unix folks use >> sed | awk | indent type answers. > For whatever it's worth, you can do the exact same thing as vi with sed in this case: 1,/====/d > > I wasn't there, so I can't say if this was done in practice or if there was even enough uniformity in the markers for it to be reliable in theory [perhaps /^#!/,$p ?] I'm just getting comfortable using sed, thanks for the simplification. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 25 04:57:26 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Jul 2020 14:57:26 -0400 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: <83465487-ed5e-8d1c-91e3-a201ccda6464@gmail.com> References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> <83465487-ed5e-8d1c-91e3-a201ccda6464@gmail.com> Message-ID: On Fri, Jul 24, 2020 at 2:47 PM Will Senn wrote: > I'm just getting comfortable using sed, thanks for the simplification. > > The issue with sed is that different shar programs used different cut/here markers. Using vi was safer and as I said, since you did not do it everyday, it was no big deal. Maybe since you have a number of these you want to apply, check with a grep for the expected marker before you try to apply the sed script and only do it in a more automated matter catching the vast majority of the markers.] You asked how we did it. As was said, there were a number of unshar(1) commands out there, that did the sed for you. Go looking in the archives, but generally speaking using vi was 'good enough' for day to day work because you did not run it that often / every day / were >>usually<< not apply a lot of them in a row. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jul 25 05:21:31 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 24 Jul 2020 14:21:31 -0500 Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> <83465487-ed5e-8d1c-91e3-a201ccda6464@gmail.com> Message-ID: <28e558bd-d047-9a13-09d2-638df537a915@gmail.com> On 7/24/20 1:57 PM, Clem Cole wrote: > > > On Fri, Jul 24, 2020 at 2:47 PM Will Senn > wrote: > >> I'm just getting comfortable using sed, thanks for the >> simplification. > > The issue with sed is that different shar programs used different > cut/here markers. Using vi was safer and as I said, since you did not > do it everyday, it was no big deal. > Maybe since you have a number of these you want to apply, check with a > grep for the expected marker before you try to apply the sed script > and only do it in a more automated matter catching the vast majority > of the markers.] > > You asked how we did it.  As was said, there were a number of > unshar(1) commands out there, that did the sed for you.  Go looking in > the archives, but generally speaking using vi was 'good enough' for > day to day work because you did not run it that often / every day / > were >>usually<< not apply a lot of them in a row. > > Clem Yup, I was curious what it looked like in the day. After hearing from everybody, I will use vi the first time and if I have to do it a bunch of ties, will test a sed script... or just wait 'til Warner's done and just check it from source code :). Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Jul 25 11:53:20 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Jul 2020 11:53:20 +1000 (EST) Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724143320.18E9C18C073@mercury.lcs.mit.edu> Message-ID: On Fri, 24 Jul 2020, Clem Cole wrote: > I pretty much have the V6 kernel memorized, from working with it > back in the day... :-) > > Amen bro -- not sure if we should be proud or ashamed of that use of > brain cells.  Add me to that list too; in fact, you'll see my name in the back of the Lions book (I helped to proof-read, and arranged its printing). Mind you, I grabbed so much from V7 that I was known as "Mr Unix 6-1/2" (we could not run V7 on our 40-class boxes so I put in what I liked and what would fit). -- Dave From dave at horsfall.org Sat Jul 25 12:00:23 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Jul 2020 12:00:23 +1000 (EST) Subject: [TUHS] Traditional method of dealing with embedded shar files In-Reply-To: References: <78041442-c5e5-1b5c-8565-b6d31f23ec1b@gmail.com> Message-ID: On Fri, 24 Jul 2020, Random832 wrote: > For whatever it's worth, you can do the exact same thing as vi with sed > in this case: 1,/====/d It's been a while since I had to use it, but didn't "unshar" do this sort of thing, and in a safe manner too? You'd be out of your mind to blindly run the shell on some anonymous shar file... -- Dave From random832 at fastmail.com Sat Jul 25 12:45:34 2020 From: random832 at fastmail.com (Random832) Date: Fri, 24 Jul 2020 22:45:34 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> <3b4e50f0-5ab9-4726-99a3-b39568b2a7bb@www.fastmail.com> Message-ID: <6cb00586-aa3b-434a-b3d7-5ec5b5315672@www.fastmail.com> On Fri, Jul 24, 2020, at 13:15, Clem Cole wrote: > On Fri, Jul 24, 2020 at 12:39 PM Random832 wrote: > > You'll have a hard time exiting your program if you use raw mode - > cbreak should be enough, and in that case ctrl-c will still work [but > even in cbreak mode I believe there is no way to send "EOF".] > There is no such thing as cbreak in sixth edition. > http://man.cat-v.org/unix-6th/1/stty > It's raw or cooked. Life is more interesting ;-) my mistake, though that does mean the rest of my point definitely stands: the program will need to have some other way (either a sequence of characters input or e.g. some amount of time passing with no input - did v6 have any mechanism like alarm?) to make the program recognize the end of its input. From paul at rileyriot.com Sat Jul 25 12:48:07 2020 From: paul at rileyriot.com (Paul Riley) Date: Sat, 25 Jul 2020 10:48:07 +0800 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: Yep already fallen into that trap. Glad I'm running on a sim! Yes I'd considered writing a small program to reset the STTY settings, and you've helped me to understand how I can run it! In answer to the CR question, is it that in raw mode, the CR does not get mapped to LF, and therefore the shell doesn't see the LF character and recognize the end of the line? Incidentally, why the ^J before ft? Just to clean up the shell input status? I'll write my own ft, thanks. I'll try raw mode, because I want some better line editing capability. Alternatively if I toy around with /dev/tty does that interfere with the operation of the standard console outside of my app? Paul *Paul Riley* On Fri, 24 Jul 2020 at 22:36, Clem Cole wrote: > > > On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa > wrote: > >> ... >> This is not a C issue; it's the Unix I/O system (and specifically, >> terminal I/O). > > >> ... > > One can suppress all this; there's a mode call 'raw' >> > Just be sure to turn raw mode off so canonization is performed again after > your program stops running. Remember this a 'system wide' settings for that > try and all programs start to use that setting. So if some reason, your > program stops and a new program (like the shell) takes back over input from > the try, if you do not have a way to get it back you are screwed. > > Back in the day, I have a shell script in my path stored in ~/.bin called: ft > (fix tty) which called the stty command with the way I wanted the > terminal to be set up. Thus is I was running a program that core dumped > and left the try in raw mode, if I could find a way to run the ft script > (usually by typing ^Jft^J ) life was good again. Paul, as an > exercise why would ft not be good enough? (hint read and study the > section 4 man page for stty) > > FWIW: is how the original UCB ex/vi and Cornell's Fred editors for v6 > works by the way. I suspect that iyou look at any of the video editors of > the day it will show you the details. > > One of the differences between V7 and earlier UNIX tty handlers was that > they tty canonization was split into multiple parts. Also the other hint > with Sixthedition's version of raw and cooked modes, you get all or nothing so > you if you turn on raw, your program, will have do things like backspace > processing, *etc*.. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Jul 25 14:02:07 2020 From: cowan at ccil.org (John Cowan) Date: Sat, 25 Jul 2020 00:02:07 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: Ctrl+J actually is the keystroke for U+000D LINE FEED, so it always works; old-timers got in the habit of typing ^Jreset^J. Note that if a program gets stuck in rare mode rather than raw mode, you can get out of it with ^C (or whatever INTR is set to), a good reason for using rare mode. On Fri, Jul 24, 2020 at 10:49 PM Paul Riley wrote: > Yep already fallen into that trap. Glad I'm running on a sim! Yes I'd > considered writing a small program to reset the STTY settings, and you've > helped me to understand how I can run it! > > In answer to the CR question, is it that in raw mode, the CR does not get > mapped to LF, and therefore the shell doesn't see the LF character and > recognize the end of the line? Incidentally, why the ^J before ft? Just to > clean up the shell input status? > > I'll write my own ft, thanks. I'll try raw mode, because I want some > better line editing capability. > > Alternatively if I toy around with /dev/tty does that interfere with the > operation of the standard console outside of my app? > > Paul > > *Paul Riley* > > > > > On Fri, 24 Jul 2020 at 22:36, Clem Cole wrote: > >> >> >> On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa >> wrote: >> >>> ... >>> This is not a C issue; it's the Unix I/O system (and specifically, >>> terminal I/O). >> >> >>> ... >> >> One can suppress all this; there's a mode call 'raw' >>> >> Just be sure to turn raw mode off so canonization is performed again >> after your program stops running. Remember this a 'system wide' >> settings for that try and all programs start to use that setting. So if >> some reason, your program stops and a new program (like the shell) takes >> back over input from the try, if you do not have a way to get it back you >> are screwed. >> >> Back in the day, I have a shell script in my path stored in ~/.bin >> called: ft (fix tty) which called the stty command with the way I wanted >> the terminal to be set up. Thus is I was running a program that core >> dumped and left the try in raw mode, if I could find a way to run the ft >> script (usually by typing ^Jft^J ) life was good again. Paul, as an >> exercise why would ft not be good enough? (hint read and study the >> section 4 man page for stty) >> >> FWIW: is how the original UCB ex/vi and Cornell's Fred editors for v6 >> works by the way. I suspect that iyou look at any of the video editors of >> the day it will show you the details. >> >> One of the differences between V7 and earlier UNIX tty handlers was that >> they tty canonization was split into multiple parts. Also the other hint >> with Sixthedition's version of raw and cooked modes, you get all or nothing so >> you if you turn on raw, your program, will have do things like backspace >> processing, *etc*.. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jul 25 23:52:18 2020 From: will.senn at gmail.com (Will Senn) Date: Sat, 25 Jul 2020 08:52:18 -0500 Subject: [TUHS] Diff and Patch on v7 Message-ID: I got a diff for adding actual backspace and delete to v7, linked off of gunkies... Anyhow, I can manually edit the referenced files and rebuild, but I would rather do it canonically. I don't see patch anywhere, so did v7 users use diffs to patch source and if so what's the magic? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Sun Jul 26 00:03:43 2020 From: leah at vuxu.org (Leah Neukirchen) Date: Sat, 25 Jul 2020 16:03:43 +0200 Subject: [TUHS] Diff and Patch on v7 In-Reply-To: (Will Senn's message of "Sat, 25 Jul 2020 08:52:18 -0500") References: Message-ID: <878sf7adz3.fsf@vuxu.org> Will Senn writes: > I got a diff for adding actual backspace and delete to v7, linked off > of gunkies... Anyhow, I can manually edit the referenced files and > rebuild, but I would rather do it canonically. I don't see patch > anywhere, so did v7 users use diffs to patch source and if so what's > the magic? patch(1) was written by Larry Wall in 1985, and released over Usenet. v7 users likely used diff -e, and piped to ed to apply it. -- Leah Neukirchen https://leahneukirchen.org/ From will.senn at gmail.com Sun Jul 26 00:28:19 2020 From: will.senn at gmail.com (Will Senn) Date: Sat, 25 Jul 2020 09:28:19 -0500 Subject: [TUHS] Diff and Patch on v7 In-Reply-To: <878sf7adz3.fsf@vuxu.org> References: <878sf7adz3.fsf@vuxu.org> Message-ID: On 7/25/20 9:03 AM, Leah Neukirchen wrote: > Will Senn writes: > >> I got a diff for adding actual backspace and delete to v7, linked off >> of gunkies... Anyhow, I can manually edit the referenced files and >> rebuild, but I would rather do it canonically. I don't see patch >> anywhere, so did v7 users use diffs to patch source and if so what's >> the magic? > patch(1) was written by Larry Wall in 1985, and released over Usenet. > > v7 users likely used diff -e, and piped to ed to apply it. > That makes sense. So, if that's how it went then I'm wondering if my diff is meant to run against source on the host and the results placed into v7, rather than run in v7. Does this look like a modern diff vs the old stuff?: --- usr/src/cmd/getty.c    1979-05-05 08:19:21.000000000 +0100 +++ usr.fix/src/cmd/getty.c    2018-01-09 11:07:37.157953044 +0100 @@ -5,11 +5,11 @@  #include  #include -#define ERASE    '#' -#define KILL    '@' +#define ERASE    '\177' +#define KILL    '\025'  struct sgttyb tmode; -struct tchars tchars = { '\177', '\034', '\021', '\023', '\004', '\377' }; +struct tchars tchars = { '\003', '\034', '\021', '\023', '\004', '\377' };  struct    tab {      char    tname;        /* this table name */ Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From will.senn at gmail.com Sun Jul 26 00:34:02 2020 From: will.senn at gmail.com (Will Senn) Date: Sat, 25 Jul 2020 09:34:02 -0500 Subject: [TUHS] vi in v7 Message-ID: On another front. I know I've asked this before in v6, and possibly related to v7, but I can't find the notes anywhere. vi doesn't come with v7. So, has anybody put it on v7 in simh? I saw a thread sometime back where vi on v7 wasn't the main topic, where Warren? I think it was, said he'd done it and it was "easy." I don't suppose there are any notes laying around telling how this might be accomplished? I do see vi in 2bsd.tar, I don't suppose there is a  'how to install 2bsd on v7" note around either? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 26 00:39:48 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Jul 2020 10:39:48 -0400 Subject: [TUHS] Diff and Patch on v7 In-Reply-To: References: <878sf7adz3.fsf@vuxu.org> Message-ID: Will that is the output that would have go into patch(1). As Leah says, the old days we used diff -e to create the patch and then ed file wrote: > On 7/25/20 9:03 AM, Leah Neukirchen wrote: > > Will Senn writes: > > > >> I got a diff for adding actual backspace and delete to v7, linked off > >> of gunkies... Anyhow, I can manually edit the referenced files and > >> rebuild, but I would rather do it canonically. I don't see patch > >> anywhere, so did v7 users use diffs to patch source and if so what's > >> the magic? > > patch(1) was written by Larry Wall in 1985, and released over Usenet. > > > > v7 users likely used diff -e, and piped to ed to apply it. > > > That makes sense. So, if that's how it went then I'm wondering if my > diff is meant to run against source on the host and the results placed > into v7, rather than run in v7. Does this look like a modern diff vs the > old stuff?: > > --- usr/src/cmd/getty.c 1979-05-05 08:19:21.000000000 +0100 > +++ usr.fix/src/cmd/getty.c 2018-01-09 11:07:37.157953044 +0100 > @@ -5,11 +5,11 @@ > > #include > #include > -#define ERASE '#' > -#define KILL '@' > +#define ERASE '\177' > +#define KILL '\025' > > struct sgttyb tmode; > -struct tchars tchars = { '\177', '\034', '\021', '\023', '\004', '\377' }; > +struct tchars tchars = { '\003', '\034', '\021', '\023', '\004', '\377' }; > > struct tab { > char tname; /* this table name */ > > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Jul 26 00:45:18 2020 From: cowan at ccil.org (John Cowan) Date: Sat, 25 Jul 2020 10:45:18 -0400 Subject: [TUHS] Groff on Windows (for PDF output)? In-Reply-To: References: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Message-ID: On Thu, Jul 23, 2020 at 8:15 PM Clem Cole wrote: > The short answer is that Cygwin can never work as well as WSL because it's > layered on top of Windows and has to map. So the API is inherently only as > good as what Windows presents to the user. > Historically that was true, but no longer. Since 2000, more and more direct calls to the NT Executive have appeared in the cygwin1.dll source: there are about a thousand of them now, invoking about 90 different Executive APIs. Such features as flock(), mmap(), and reading from block devices cannot be done in Win32 and use the Executive directly. Unfortunately, it also makes Cygwin a bit more brittle to Microsoft changes, as the NT Executive API is permanently unstable. So far, Corinna and friends are keeping up nicely. When I was as DEC I was involved with the whole story ... so let me pull > much of the rest of the answer from my Quora answer to is 'Windows POSIX > compliant'[1]. > Thanks for the history! BTW, when you say "Win32S" you mean "Win32". Win32S was a long-obsolete package to let 32-bit Windows apps run on 16-bit Windows if they didn't try to do too much. (Which reminds me that in my list of subsystems running on the NT Executive, I forgot to mention WoW64, which provides a 32-bit WIn32 environment on the 64-bit Windows kernel, and is used to keep 32-bit Windows apps running.) > Anyway, my own experience is IF you have to use Windows 10, WSL pretty > much 'just works.' > I agree. However, I have spent much of my career on corporate Windows boxen, which are often locked down to prevent you from installing things, including WSL. Because Cygwin bypasses the regular Windows install system, it flies under the radar. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org You escaped them by the will-death and the Way of the Black Wheel. I could not. --Great-Souled Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 26 00:45:09 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Jul 2020 10:45:09 -0400 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: 2BSD was the BSD for V7. It was >>not<< a 'distro' as 3.0 and later 2.XBSD became. It is just a set of programs and kernel patches that were built up at UCB. This was the way different sites released things in those days. The "read me" files should tell you what is there and you pick the binaries (if you have them) and install them as is and/or recompile from the makefiles on a case by case basis. Clem On Sat, Jul 25, 2020 at 10:35 AM Will Senn wrote: > On another front. I know I've asked this before in v6, and possibly > related to v7, but I can't find the notes anywhere. vi doesn't come with > v7. So, has anybody put it on v7 in simh? I saw a thread sometime back > where vi on v7 wasn't the main topic, where Warren? I think it was, said > he'd done it and it was "easy." I don't suppose there are any notes laying > around telling how this might be accomplished? > > I do see vi in 2bsd.tar, I don't suppose there is a 'how to install 2bsd > on v7" note around either? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 26 00:55:44 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Jul 2020 10:55:44 -0400 Subject: [TUHS] Groff on Windows (for PDF output)? In-Reply-To: References: <202007231833.06NIXNs5069643@tahoe.cs.Dartmouth.EDU> Message-ID: On Sat, Jul 25, 2020 at 10:45 AM John Cowan wrote: > > > BTW, when you say "Win32S" you mean "Win32". Win32S was a long-obsolete > package to let 32-bit Windows apps run on 16-bit Windows if they didn't try > to do too much. > Can't speak for today. At one point the S stood for Standard/Stable. That used to be a Culter-ism IIRC -- it was what was guaranteed to ISVs to be there. If you used anything else, Microsoft could (and did) pull the rug out from under you. They added a bunch of new APIs and new stuff from 64 bits to et al. When Interix was done, all that they could guarantee was Cutler's interface. I agree. However, I have spent much of my career on corporate Windows > boxen, which are often locked down to prevent you from installing > things, including WSL. Because Cygwin bypasses the regular Windows install > system, it flies under the radar. > WSL should not have that problem these days for the exact reasons you mentioned, as you were correct that SFU/SUA did tend to be something that IT depts did not understand like (it was free but it was separate install). But WSL is just one of the standard options in Windows10 ever system can have it. You just have to enable it in the control panel and it will automatically do everything in a manner that should not be an issue to IT folks. Although it does require >>local<< admin privileges on the machines to enable.; IIRC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 26 01:09:08 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Jul 2020 11:09:08 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: BTW: another old V6 trick is the use file redirection from the different terminal to unlock a hosed tty. Programming on the console was fraught with multiple dragons and not recommended. But due to program crashes that left things in raw mode, I admit that I remember having to uses the redirection trick a few times to get the console back. As Noel said, it could get dicey if the console ended up with canonicalization turned off. V7's ½ cooked (*a.k.a.* CBREAK) was a welcomed edition, but the fact is V6's try handler was good enough most needs and a lot of used it pretty successfully for a long time. Clem On Sat, Jul 25, 2020 at 12:02 AM John Cowan wrote: > Ctrl+J actually is the keystroke for U+000D LINE FEED, so it always works; > old-timers got in the habit of typing ^Jreset^J. > > Note that if a program gets stuck in rare mode rather than raw mode, you > can get out of it with ^C (or whatever INTR is set to), a good reason for > using rare mode. > > > On Fri, Jul 24, 2020 at 10:49 PM Paul Riley wrote: > >> Yep already fallen into that trap. Glad I'm running on a sim! Yes I'd >> considered writing a small program to reset the STTY settings, and you've >> helped me to understand how I can run it! >> >> In answer to the CR question, is it that in raw mode, the CR does not get >> mapped to LF, and therefore the shell doesn't see the LF character and >> recognize the end of the line? Incidentally, why the ^J before ft? Just to >> clean up the shell input status? >> >> I'll write my own ft, thanks. I'll try raw mode, because I want some >> better line editing capability. >> >> Alternatively if I toy around with /dev/tty does that interfere with the >> operation of the standard console outside of my app? >> >> Paul >> >> *Paul Riley* >> >> >> >> >> On Fri, 24 Jul 2020 at 22:36, Clem Cole wrote: >> >>> >>> >>> On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa >>> wrote: >>> >>>> ... >>>> This is not a C issue; it's the Unix I/O system (and specifically, >>>> terminal I/O). >>> >>> >>>> ... >>> >>> One can suppress all this; there's a mode call 'raw' >>>> >>> Just be sure to turn raw mode off so canonization is performed again >>> after your program stops running. Remember this a 'system wide' >>> settings for that try and all programs start to use that setting. So if >>> some reason, your program stops and a new program (like the shell) takes >>> back over input from the try, if you do not have a way to get it back you >>> are screwed. >>> >>> Back in the day, I have a shell script in my path stored in ~/.bin >>> called: ft (fix tty) which called the stty command with the way I >>> wanted the terminal to be set up. Thus is I was running a program >>> that core dumped and left the try in raw mode, if I could find a way to run >>> the ft script (usually by typing ^Jft^J ) life was good again. Paul, >>> as an exercise why would ft not be good enough? (hint read and >>> study the section 4 man page for stty) >>> >>> FWIW: is how the original UCB ex/vi and Cornell's Fred editors for v6 >>> works by the way. I suspect that iyou look at any of the video editors of >>> the day it will show you the details. >>> >>> One of the differences between V7 and earlier UNIX tty handlers was that >>> they tty canonization was split into multiple parts. Also the other hint >>> with Sixthedition's version of raw and cooked modes, you get all or nothing so >>> you if you turn on raw, your program, will have do things like backspace >>> processing, *etc*.. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 26 01:19:31 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Jul 2020 09:19:31 -0600 Subject: [TUHS] Diff and Patch on v7 In-Reply-To: References: <878sf7adz3.fsf@vuxu.org> Message-ID: On Sat, Jul 25, 2020 at 8:41 AM Clem Cole wrote: > Will that is the output that would have go into patch(1). As Leah says, > the old days we used diff -e to create the patch and then ed file > That said, when Larry wrote patch, V7 was still very much alive and > kicking and Larry had come from that world/his code would be likely to be > fairly clean of vax-isms. I bet if you can find a version that will > compile and run on V7. V6 is likely to be more difficult since the > language changes for stdio. But patch(1) is small and simple so I bet even > that would be pretty straight forward. > I'd start with the last larry wall version of patch, before gnu took it up. It likely will compile there out of the box. There's a copy in 2.11BSD that's version 2 that at least fits into a PDP-11 with separate I&D space. It's also on the 2.10.1BSD tape as well. configure will almost certainly work on the V7 shell. Not sure about v6, unlikely. It will compile under V7's c compiler as well, since it's pure K&R. It also runs well enough to apply all the diffs 2.11BSD has produced over the years. It looks like it doesn't require separate I&D space to load, but it's big enough that it helps a lot. V7 had separate i&D space, so you're good there. However, it will only accept context diffs, not unified diffs. You may have to convert newer unified diffs to context diffs. Well, it also accepts normal diffs and ed scripts too :) Looking at the size of FreeBSD's patch, it's only 53kB text and 8kB data on amd64, so there's a chance newer versions will fit (this is the last BSD-licensed version, with bug fixes). It groks everything that gnu patch groks. gnu patch is 175k of text and 8k of data and is quite likely a lost cause on the pdp-11 (with overlays, 176k is the absolute max, but 150k is where it gets hard... but V7 didn't have an overlay linker). Warner > > On Sat, Jul 25, 2020 at 10:29 AM Will Senn wrote: > >> On 7/25/20 9:03 AM, Leah Neukirchen wrote: >> > Will Senn writes: >> > >> >> I got a diff for adding actual backspace and delete to v7, linked off >> >> of gunkies... Anyhow, I can manually edit the referenced files and >> >> rebuild, but I would rather do it canonically. I don't see patch >> >> anywhere, so did v7 users use diffs to patch source and if so what's >> >> the magic? >> > patch(1) was written by Larry Wall in 1985, and released over Usenet. >> > >> > v7 users likely used diff -e, and piped to ed to apply it. >> > >> That makes sense. So, if that's how it went then I'm wondering if my >> diff is meant to run against source on the host and the results placed >> into v7, rather than run in v7. Does this look like a modern diff vs the >> old stuff?: >> >> --- usr/src/cmd/getty.c 1979-05-05 08:19:21.000000000 +0100 >> +++ usr.fix/src/cmd/getty.c 2018-01-09 11:07:37.157953044 +0100 >> @@ -5,11 +5,11 @@ >> >> #include >> #include >> -#define ERASE '#' >> -#define KILL '@' >> +#define ERASE '\177' >> +#define KILL '\025' >> >> struct sgttyb tmode; >> -struct tchars tchars = { '\177', '\034', '\021', '\023', '\004', '\377' >> }; >> +struct tchars tchars = { '\003', '\034', '\021', '\023', '\004', '\377' >> }; >> >> struct tab { >> char tname; /* this table name */ >> >> >> Will >> >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sun Jul 26 01:31:34 2020 From: rich.salz at gmail.com (Richard Salz) Date: Sat, 25 Jul 2020 11:31:34 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: Wasn't there an issue that v7 atty used stdin and BSD used stdout? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 26 01:36:27 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Jul 2020 09:36:27 -0600 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: On Sat, Jul 25, 2020 at 8:47 AM Clem Cole wrote: > 2BSD was the BSD for V7. It was >>not<< a 'distro' as 3.0 and later > 2.XBSD became. It is just a set of programs and kernel patches that were > built up at UCB. This was the way different sites released things in those > days. The "read me" files should tell you what is there and you pick the > binaries (if you have them) and install them as is and/or recompile from > the makefiles on a case by case basis. > 2.8BSD is the first one I've seen with a bootable tape (though i've not booted it). The other caveat with BSD software was it may have made assumptions about being on a Berkeley unix system by default and may need some help. Though having said that, I'd give it a try... Warner > Clem > > On Sat, Jul 25, 2020 at 10:35 AM Will Senn wrote: > >> On another front. I know I've asked this before in v6, and possibly >> related to v7, but I can't find the notes anywhere. vi doesn't come with >> v7. So, has anybody put it on v7 in simh? I saw a thread sometime back >> where vi on v7 wasn't the main topic, where Warren? I think it was, said >> he'd done it and it was "easy." I don't suppose there are any notes laying >> around telling how this might be accomplished? >> >> I do see vi in 2bsd.tar, I don't suppose there is a 'how to install 2bsd >> on v7" note around either? >> >> Thanks, >> >> Will >> >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sun Jul 26 01:45:06 2020 From: rich.salz at gmail.com (Richard Salz) Date: Sat, 25 Jul 2020 11:45:06 -0400 Subject: [TUHS] Diff and Patch on v7 In-Reply-To: References: <878sf7adz3.fsf@vuxu.org> Message-ID: > -#define ERASE '#' > -#define KILL '@' > +#define ERASE '\177' > +#define KILL '\025' > That is a context diff. The wikipedia page https://en.wikipedia.org/wiki/Diff#Context_format has a reasonable history. Short answer is context diffs appeared in 2.8BSD in 1981 and unified context diffs were posted to Usenet in 1990. Context diffs are more robust if you have made local changes (patch's "fuzz" messages), and unified are more compact version and can be more useful to see exactly before/after lines. A comparison of the outputs follows: ; diff a.cpp.orig a.cpp 3d2 < int size; 6c5 < : elem{new int[s]}, size{s} --- > : elem{new int[s]} ; diff -e a.cpp.orig a.cpp 6c : elem{new int[s]} . 3d ; diff -c a.cpp.orig a.cpp *** a.cpp.orig Sat Jul 25 11:37:29 2020 --- a.cpp Sat Jul 25 11:42:21 2020 *************** *** 1,9 **** class x { int *elem; - int size; public: x(int s) ! : elem{new int[s]}, size{s} { } ~x() { delete[] elem; } --- 1,8 ---- class x { int *elem; public: x(int s) ! : elem{new int[s]} { } ~x() { delete[] elem; } ; diff -u a.cpp.orig a.cpp --- a.cpp.orig 2020-07-25 11:37:29.000000000 -0400 +++ a.cpp 2020-07-25 11:42:21.000000000 -0400 @@ -1,9 +1,8 @@ class x { int *elem; - int size; public: x(int s) - : elem{new int[s]}, size{s} + : elem{new int[s]} { } ~x() { delete[] elem; } ; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Jul 26 03:45:01 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Jul 2020 13:45:01 -0400 (EDT) Subject: [TUHS] V6 Console IO Message-ID: <20200725174501.5C03818C09E@mercury.lcs.mit.edu> > From: Clem Cole > another old V6 trick is the use file redirection from the different > terminal to unlock a hosed tty. 'stty {mumble} > /dev/ttyX', in case that wasn't clear. Note that this only works if you have a working shell on _another_ terminal, so if you're e.g. working with an emulation which has only one working terminal, and your raw-mode program on it has gone berserk, 'See Figure 1'. It really is advised to have another working terminal if you want to play with raw-mode programs. Noel From dave at horsfall.org Sun Jul 26 10:06:14 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 26 Jul 2020 10:06:14 +1000 (EST) Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020, Warner Losh wrote: > 2.8BSD is the first one I've seen with a bootable tape (though i've not > booted it). Weren't V5/6/7/etc distributed as bootable tapes? Set the switch register to point to the tape instead of the disk... -- Dave From imp at bsdimp.com Sun Jul 26 10:13:26 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Jul 2020 18:13:26 -0600 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: On Sat, Jul 25, 2020 at 6:08 PM Dave Horsfall wrote: > On Sat, 25 Jul 2020, Warner Losh wrote: > > > 2.8BSD is the first one I've seen with a bootable tape (though i've not > > booted it). > > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch register > to point to the tape instead of the disk... > Yes. They were. We have V6 and V7 tapes (and a V5 disk image). Likely earlier versions likely did too. What I'd meant was that 2.8BSD is the first 2BSD that had a bootable tape. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Jul 26 10:16:55 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Jul 2020 20:16:55 -0400 (EDT) Subject: [TUHS] vi in v7 Message-ID: <20200726001655.107AF18C0B8@mercury.lcs.mit.edu> > From: Dave Horsfall > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch register > to point to the tape instead of the disk... Yes. See here: https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition https://gunkies.org/wiki/Installing_Unix_Seventh_Edition for the details of how it works. Noel From athornton at gmail.com Sun Jul 26 10:39:31 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 25 Jul 2020 17:39:31 -0700 Subject: [TUHS] vi in v7 In-Reply-To: <20200726001655.107AF18C0B8@mercury.lcs.mit.edu> References: <20200726001655.107AF18C0B8@mercury.lcs.mit.edu> Message-ID: I wasn't able to build vi for the v7 image easily available for simh, but Webb Miller's 's' editor wasn't too tough (it has similar keybindings), and the version with the minor tweaks needed for it is up at: https://github.com/athornton/s On Sat, Jul 25, 2020 at 5:18 PM Noel Chiappa wrote: > > From: Dave Horsfall > > > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch > register > > to point to the tape instead of the disk... > > Yes. See here: > > https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition > https://gunkies.org/wiki/Installing_Unix_Seventh_Edition > > for the details of how it works. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 26 10:41:15 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Jul 2020 20:41:15 -0400 Subject: [TUHS] vi in v7 In-Reply-To: References: Message-ID: yes -- sorry, I meant from Berkeley. On Sat, Jul 25, 2020 at 8:08 PM Dave Horsfall wrote: > On Sat, 25 Jul 2020, Warner Losh wrote: > > > 2.8BSD is the first one I've seen with a bootable tape (though i've not > > booted it). > > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch register > to point to the tape instead of the disk... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Sun Jul 26 11:08:16 2020 From: random832 at fastmail.com (Random832) Date: Sat, 25 Jul 2020 21:08:16 -0400 Subject: [TUHS] V6 Console IO In-Reply-To: References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> Message-ID: <26c53489-7683-4b40-bf24-b910af5a9a78@www.fastmail.com> On Sat, Jul 25, 2020, at 11:31, Richard Salz wrote: > Wasn't there an issue that v7 atty used stdin and BSD used stdout? v7 uses stdout, but system iii and v use stdin. oddly enough, later research unix appears to unconditionally open /dev/tty, making the redirection trick entirely unavailable. From will.senn at gmail.com Mon Jul 27 00:56:22 2020 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Jul 2020 09:56:22 -0500 Subject: [TUHS] Troff to ps Message-ID: All, So... I've moved on from v7 to 2.11bsd - shucks, vi and tar and co. just work there and everything else seems to be similar enough for what I'm interested in anyway. So yay, I won't be pestering y'all about vi anymore :). One the other hand, now I'm interested in printing the docs. 2.11bsd comes with docs in, of all places, /usr/doc. In there are makefiles for making the docs - ok, make nroff will make ascii docs, and troff will make troff? docs using Ossana's 'original' troff. So, after adding -t to it so it didn't complain about 'typesetter busy', I got no errors. I mounted a tape, tar'ed my .out file and untar'ed it on my macbook (did it for the nroff and troff output). Then I hit the first snag, groff -Tps -ms troff.out > whatever.ps resulted in cannot adjust line and cannot break line errors and groff -Tps -ms nroff.out > whatever.ps resulted in a bunch of double vision. I seem to recall doing this in v6 and it working ok (at least for nroff). My questions: 1. Is there a troff to postcript conversion utility present in a stock 2.11 system (or even patch level 4xx system)? 2. Is there a way to build postscript directly on the system? 3. Is there an alternative modern way to get to ps or pdf output from the nroff/troff that 2.11 has? I'm still digging into the nroff stuff as that may be just minor diffs between ancient nroff macros and "modern" macros or even just errors (.sp -2 rather than .sp or .sp -1, .in -2 instead of .in +2), etc. Although, the files display ok in 2.11bsd using nroff -ms nroff.out... Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jul 27 01:31:52 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Jul 2020 09:31:52 -0600 Subject: [TUHS] Troff to ps In-Reply-To: References: Message-ID: <202007261531.06QFVqZb027062@freefriends.org> Will Senn wrote: > My questions: > 1. Is there a troff to postcript conversion utility present in a stock > 2.11 system (or even patch level 4xx system)? Troff from that era was designed to drive the C/A/T phototypesetter. There were tools that converted from C/A/T to postscript but they were mostly commercial IIRC. > 2. Is there a way to build postscript directly on the system? Likely not. > 3. Is there an alternative modern way to get to ps or pdf output from > the nroff/troff that 2.11 has? I would recommend tar-ing up the doc and macros, moving them to Linux or other modern system, and using groff -C to create postscript/pdf. That really will be the fastest way. Arnold From clemc at ccc.com Mon Jul 27 01:33:24 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 26 Jul 2020 11:33:24 -0400 Subject: [TUHS] Troff to ps In-Reply-To: References: Message-ID: On Sun, Jul 26, 2020 at 10:58 AM Will Senn wrote: > All, > > So... I've moved on from v7 to 2.11bsd - shucks, vi and tar and co. just > work there and everything else seems to be similar enough for what I'm > interested in anyway. So yay, I won't be pestering y'all about vi anymore > :). One the other hand, now I'm interested in printing the docs. > Wimp .. ;-) seriously at this step, it might be easier for you as a more modern user. > > 2.11bsd comes with docs in, of all places, /usr/doc. > Well that is where is was in V7 ;-) > In there are makefiles for making the docs - ok, make nroff will make > ascii docs, and troff will make troff? docs using Ossana's 'original' troff. > yep > So, after adding -t to it so it didn't complain about 'typesetter busy', I > got no errors. > right... > I mounted a tape, tar'ed my .out file and untar'ed it on my macbook (did > it for the nroff and troff output). Then I hit the first snag, groff -Tps > -ms troff.out > whatever.ps resulted in cannot adjust line and cannot > break line errors and groff -Tps -ms nroff.out > whatever.ps resulted in > a bunch of double vision. I seem to recall doing this in v6 and it working > ok (at least for nroff). > Well let's just save -ms and troff itself were re-implemented and there are likely to be some small differences. At UCB, the command would have been: tbl < input_troff_text | eqn | troff -t -ms | vcat vcat(1) was the virtual CAT typesetter using a Versatec Plotter. Adobe released a source-level product called transcript, that you recompiled and ran on V7 or later (like the PDP-11s). My memory it was ~ $1K back in the day. Transcript 2.0 contained a number of tools. One was a CAT to PS converter. Another was the tables for the ditroff to spit out PS so: ditroff -Tps worked as expected and a program called 'enscript' that converted from txt to PS. All of these tools have modern FOSS equivalents, but it may take some hunting to find them. I think sources to transcript 2.0 can be found if you google around. I'm not sure Adobe ever officially made is FOSS, but after the modern equivalent showed up, I'm not aware of them minding that people did not have the license since it sold more printers with PostScript. That should just recompile on V7 or later and 'just work.' The modern equivalent might take some backporting. BTW: Thinking about this, I believe I remember that there is a directory on Kirk's CD's that have a copy from UCB. Mount his disks and poke around. I'll try to look myself but I'm supposed to be helping my wife get ready for a socially distanced birthday party for our great-niece [we have the big back yard, tent et al that can handle the 6 foot part requirements]. > > My questions: > 1. Is there a troff to postcript conversion utility present in a stock > 2.11 system (or even patch level 4xx system)? > The word "present"t is the operative term. Probably not. > 2. Is there a way to build postscript directly on the system? > Yes, see above. > 3. Is there an alternative modern way to get to ps or pdf output from the > nroff/troff that 2.11 has? > Yep - Ghostscript based tools which is what the Transcript replacements tend to use. > > I'm still digging into the nroff stuff as that may be just minor diffs > between ancient nroff macros and "modern" macros or even just errors (.sp > -2 rather than .sp or .sp -1, .in -2 instead of .in +2), etc. > Be careful - that's not quite the same. Basically groff fixed a number of long-standing issues that older troff/ditroff had worked around. Usually, the difference is that the original nroff/troff has some defaults that now need to make explicit. But most older *roff documents can go through modern groff just fine. The more typical error from old documents is a site that did not have a Versatec or later an Apple Laserwriter and only supported nroff. A number of documents when created for nroff will look ugly when you run them through any version of troff (old or new) as the document authors never took the time to deal with the differences in the output device. > Although, the files display ok in 2.11bsd using nroff -ms nroff.out... > I would expect so. I bet they are fine with troff -t or if you can find ditroff (which also maybe on Kirk's CD) and then run the output through vcat or transcript. Note if you used vcat you will get some printing facsimiles that were there back in the day. The reason is when Tom Ferrin wrote vcat, the only fonts he had were the old Hershey fonts (fonts have gotten >>so<< much better since then). So troff is using Wang CAT4 typesetter font rules and Tim is doing the best he can to map that to Hershey. The PS CAT simulator in Transcript has the same issue BTW. It's a little better since the PS fonts are better but they don't map the 100%. However, if you use ditroff, Adobe supplied the rules in Transcript so that ditroff did its calculations using the proper fonts (Adobe's not Wang's). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jul 27 01:35:57 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Jul 2020 09:35:57 -0600 Subject: [TUHS] Troff to ps In-Reply-To: <202007261531.06QFVqZb027062@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> Message-ID: <202007261535.06QFZvLg027250@freefriends.org> Some web searching turns up something called 'psroff' from the late 80s or so that will convert C/A/T to postscript. Google 'psroff source' and you should find something you can use. Arnold arnold at skeeve.com wrote: > Will Senn wrote: > > > My questions: > > 1. Is there a troff to postcript conversion utility present in a stock > > 2.11 system (or even patch level 4xx system)? > > Troff from that era was designed to drive the C/A/T phototypesetter. > There were tools that converted from C/A/T to postscript but they > were mostly commercial IIRC. > > > 2. Is there a way to build postscript directly on the system? > > Likely not. > > > 3. Is there an alternative modern way to get to ps or pdf output from > > the nroff/troff that 2.11 has? > > I would recommend tar-ing up the doc and macros, moving them to Linux > or other modern system, and using groff -C to create postscript/pdf. > That really will be the fastest way. > > Arnold From clemc at ccc.com Mon Jul 27 02:15:19 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 26 Jul 2020 12:15:19 -0400 Subject: [TUHS] Troff to ps In-Reply-To: <202007261535.06QFZvLg027250@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> Message-ID: psroff was part of the Transcript FWIW. It was the moral equi to the UCB command vtroff which did the call to troff -t ... | vcat BTW: I just peeked, on Disk 4 of Kirk's archives are the source to both ditroff and Adobe's transcript in the 'local' directory. I would suggest starting with transcript, copying to your system and typing 'make' That will allow the BSD troff stuff to 'just work' us pscat/psroff/enscript et al. This is how most sites that did not spring for a ditroff license worked with their Apple Laserwriters or later PS printers. Then if you want to do the same thing with ditroff, that should 'just compile' and build and you replace troff with ditroff. On Sun, Jul 26, 2020 at 11:38 AM wrote: > Some web searching turns up something called 'psroff' from the late 80s > or so that will convert C/A/T to postscript. Google 'psroff source' and > you should find something you can use. > > Arnold > > arnold at skeeve.com wrote: > > > Will Senn wrote: > > > > > My questions: > > > 1. Is there a troff to postcript conversion utility present in a stock > > > 2.11 system (or even patch level 4xx system)? > > > > Troff from that era was designed to drive the C/A/T phototypesetter. > > There were tools that converted from C/A/T to postscript but they > > were mostly commercial IIRC. > > > > > 2. Is there a way to build postscript directly on the system? > > > > Likely not. > > > > > 3. Is there an alternative modern way to get to ps or pdf output from > > > the nroff/troff that 2.11 has? > > > > I would recommend tar-ing up the doc and macros, moving them to Linux > > or other modern system, and using groff -C to create postscript/pdf. > > That really will be the fastest way. > > > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jul 27 03:11:00 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Jul 2020 11:11:00 -0600 Subject: [TUHS] Troff to ps In-Reply-To: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> Message-ID: <202007261711.06QHB07i032409@freefriends.org> There was a different psroff posted to comp.sources.unix volume 20; that's what I was referring to. Clem Cole wrote: > psroff was part of the Transcript FWIW. It was the moral equi to the UCB > command vtroff which did the call to troff -t ... | vcat > > BTW: I just peeked, on Disk 4 of Kirk's archives are the source to both > ditroff and Adobe's transcript in the 'local' directory. > > I would suggest starting with transcript, copying to your system and typing > 'make' > That will allow the BSD troff stuff to 'just work' us pscat/psroff/enscript > et al. > > This is how most sites that did not spring for a ditroff license worked > with their Apple Laserwriters or later PS printers. > > Then if you want to do the same thing with ditroff, that should 'just > compile' and build and you replace troff with ditroff. > > On Sun, Jul 26, 2020 at 11:38 AM wrote: > > > Some web searching turns up something called 'psroff' from the late 80s > > or so that will convert C/A/T to postscript. Google 'psroff source' and > > you should find something you can use. > > > > Arnold > > > > arnold at skeeve.com wrote: > > > > > Will Senn wrote: > > > > > > > My questions: > > > > 1. Is there a troff to postcript conversion utility present in a stock > > > > 2.11 system (or even patch level 4xx system)? > > > > > > Troff from that era was designed to drive the C/A/T phototypesetter. > > > There were tools that converted from C/A/T to postscript but they > > > were mostly commercial IIRC. > > > > > > > 2. Is there a way to build postscript directly on the system? > > > > > > Likely not. > > > > > > > 3. Is there an alternative modern way to get to ps or pdf output from > > > > the nroff/troff that 2.11 has? > > > > > > I would recommend tar-ing up the doc and macros, moving them to Linux > > > or other modern system, and using groff -C to create postscript/pdf. > > > That really will be the fastest way. > > > > > > Arnold > > From clemc at ccc.com Mon Jul 27 04:03:49 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 26 Jul 2020 14:03:49 -0400 Subject: [TUHS] Troff to ps In-Reply-To: <202007261711.06QHB07i032409@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> Message-ID: I wonder if it used troff or ditroff and then what it used for the ps engine (probably Ghostscript) and if ditroff, from where the font metric tables came? I also wonder what it was using for cat4 to ps conversion again like Ghostscript. Like most folks in those days (even most Universities) since Transcript was reasonably inexpensive, most people bought it after they got their first PS based printer, particularly if they had chosen to upgrade to ditroff. For Masscomp (one advantage of being a $10K-$50K machine not a $4K one), I did manage to convince management to buy ditroff and transcript and buy the distribution license for both. It increased our price by less than $100 but we justified it that we really did not want to have to support the original troff and the price to AT&T and Adobe was just cost of doing business and cheaper for us from a cost of maintenance standpoint. We then just bundled ditroff/transcript on every machine. Funny, Sun charged for both, it was fairly cheap - I want to say $500 a node (Larry may remember). But you had to buy it from Sun ala-cart. Many (most) universities did not because they already had the sources for their Vaxen, so then tended to recompile and move it. At Stellar we used Sun's as the 'porting base' - since we had to buy AT&T redistributions licenses anyway, we didn't pay the Sun per node tax. On Sun, Jul 26, 2020 at 1:11 PM wrote: > There was a different psroff posted to comp.sources.unix volume 20; > that's what I was referring to. > > Clem Cole wrote: > > > psroff was part of the Transcript FWIW. It was the moral equi to the UCB > > command vtroff which did the call to troff -t ... | vcat > > > > BTW: I just peeked, on Disk 4 of Kirk's archives are the source to both > > ditroff and Adobe's transcript in the 'local' directory. > > > > I would suggest starting with transcript, copying to your system and > typing > > 'make' > > That will allow the BSD troff stuff to 'just work' us > pscat/psroff/enscript > > et al. > > > > This is how most sites that did not spring for a ditroff license worked > > with their Apple Laserwriters or later PS printers. > > > > Then if you want to do the same thing with ditroff, that should 'just > > compile' and build and you replace troff with ditroff. > > > > On Sun, Jul 26, 2020 at 11:38 AM wrote: > > > > > Some web searching turns up something called 'psroff' from the late 80s > > > or so that will convert C/A/T to postscript. Google 'psroff source' and > > > you should find something you can use. > > > > > > Arnold > > > > > > arnold at skeeve.com wrote: > > > > > > > Will Senn wrote: > > > > > > > > > My questions: > > > > > 1. Is there a troff to postcript conversion utility present in a > stock > > > > > 2.11 system (or even patch level 4xx system)? > > > > > > > > Troff from that era was designed to drive the C/A/T phototypesetter. > > > > There were tools that converted from C/A/T to postscript but they > > > > were mostly commercial IIRC. > > > > > > > > > 2. Is there a way to build postscript directly on the system? > > > > > > > > Likely not. > > > > > > > > > 3. Is there an alternative modern way to get to ps or pdf output > from > > > > > the nroff/troff that 2.11 has? > > > > > > > > I would recommend tar-ing up the doc and macros, moving them to Linux > > > > or other modern system, and using groff -C to create postscript/pdf. > > > > That really will be the fastest way. > > > > > > > > Arnold > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Mon Jul 27 04:09:39 2020 From: aek at bitsavers.org (Al Kossow) Date: Sun, 26 Jul 2020 11:09:39 -0700 Subject: [TUHS] Troff to ps In-Reply-To: References: Message-ID: <791036f2-a54f-9a9b-f4df-b88eca6f272b@bitsavers.org> On 7/26/20 7:56 AM, Will Senn wrote: > All, > > So... I've moved on from v7 to 2.11bsd - shucks, vi and tar and co. just work there and everything else seems to be similar enough for what > I'm interested in anyway. So yay, I won't be pestering y'all about vi anymore :). One the other hand, now I'm interested in printing the docs. Did anyone ever make Type 1 fonts for the C/A/T or Berkeley Versatec plotter fonts? From cym224 at gmail.com Mon Jul 27 05:05:27 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Sun, 26 Jul 2020 15:05:27 -0400 Subject: [TUHS] Troff to ps In-Reply-To: <202007261531.06QFVqZb027062@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> Message-ID: <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> On 07/26/20 11:31, arnold at skeeve.com wrote (in part): > 2. Is there a way to build postscript directly on the system? > Likely not. When was dpost born? N. From noel.hunt at gmail.com Mon Jul 27 08:39:07 2020 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 27 Jul 2020 08:39:07 +1000 Subject: [TUHS] Troff to ps In-Reply-To: <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> References: <202007261531.06QFVqZb027062@freefriends.org> <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> Message-ID: At least from Ninth Edition I think; that's where I first saw it (code brought back to Sydney University by someone who had worked at the labs). On Mon, Jul 27, 2020 at 5:07 AM Nemo Nusquam wrote: > On 07/26/20 11:31, arnold at skeeve.com wrote (in part): > > 2. Is there a way to build postscript directly on the system? > > Likely not. > When was dpost born? > > N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jul 27 15:31:02 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Jul 2020 23:31:02 -0600 Subject: [TUHS] Troff to ps In-Reply-To: <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> References: <202007261531.06QFVqZb027062@freefriends.org> <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> Message-ID: <202007270531.06R5V2OB030883@freefriends.org> Nemo Nusquam wrote: > On 07/26/20 11:31, arnold at skeeve.com wrote (in part): > > 2. Is there a way to build postscript directly on the system? > > Likely not. > When was dpost born? > > N. Eighth Edition, as part of ditroff. It wouldn't help on 2.11BSD anyway, as dpost reads the ascii intermediate form from ditroff, not the C/A/T typesetter codes from original troff. Arnold From paul at rileyriot.com Mon Jul 27 19:11:20 2020 From: paul at rileyriot.com (Paul Riley) Date: Mon, 27 Jul 2020 17:11:20 +0800 Subject: [TUHS] V6 Console IO In-Reply-To: <26c53489-7683-4b40-bf24-b910af5a9a78@www.fastmail.com> References: <20200724022807.D9E1E18C073@mercury.lcs.mit.edu> <26c53489-7683-4b40-bf24-b910af5a9a78@www.fastmail.com> Message-ID: Thanks all for the great input. I replaced line editing code for the time being with a one-liner to get the Unix input, and of course it works ok. I'll replace this with my own line editor some time later ;) Paul *Paul Riley* On Sun, 26 Jul 2020 at 09:10, Random832 wrote: > On Sat, Jul 25, 2020, at 11:31, Richard Salz wrote: > > Wasn't there an issue that v7 atty used stdin and BSD used stdout? > > v7 uses stdout, but system iii and v use stdin. oddly enough, later > research unix appears to unconditionally open /dev/tty, making the > redirection trick entirely unavailable. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaapna at xs4all.nl Mon Jul 27 19:19:36 2020 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Mon, 27 Jul 2020 11:19:36 +0200 Subject: [TUHS] Troff to ps In-Reply-To: <202007270531.06R5V2OB030883@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> <893a66b9-25a6-29c8-4e71-af71c7191176@gmail.com> <202007270531.06R5V2OB030883@freefriends.org> Message-ID: <0D7B784A-1F7E-4377-A307-9C457E8A8C1D@xs4all.nl> >> When was dpost born? >> >> N. > > Eighth Edition, as part of ditroff. It wouldn't help on 2.11BSD anyway, > as dpost reads the ascii intermediate form from ditroff, not the C/A/T > typesetter codes from original troff. I don't know when it was born. It came from the Documentors Work Bench (DWB). The DWB used various to create the appropriate font tables using the target postscript interpreter the fonts were used. As far as I know, dpost and these tools were created by Rich Drechsler. jaap From brad at anduin.eldar.org Mon Jul 27 21:07:11 2020 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 27 Jul 2020 07:07:11 -0400 Subject: [TUHS] Troff to ps In-Reply-To: <0D7B784A-1F7E-4377-A307-9C457E8A8C1D@xs4all.nl> (message from Jaap Akkerhuis on Mon, 27 Jul 2020 11:19:36 +0200) Message-ID: Jaap Akkerhuis writes: >>> When was dpost born? >>> >>> N. >> >> Eighth Edition, as part of ditroff. It wouldn't help on 2.11BSD anyway, >> as dpost reads the ascii intermediate form from ditroff, not the C/A/T >> typesetter codes from original troff. > > I don't know when it was born. It came from the Documentors Work > Bench (DWB). The DWB used various to create the appropriate font > tables using the target postscript interpreter the fonts were used. > As far as I know, dpost and these tools were created by Rich Drechsler. > > jaap I don't know when it was born either, but I do know that there was a port of it to a Vax running System V at 6200 Broad Street where I worked in the late 90s. It is highly likely it was actually a port of DWB running on the Vax, but I could not tell you for sure. We had to use it to get working output for one of the printers we had. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From norman at oclsc.org Thu Jul 23 03:11:16 2020 From: norman at oclsc.org (Norman Wilson) Date: Wed, 22 Jul 2020 13:11:16 -0400 (EDT) Subject: [TUHS] Bell Labs Sysadmins Message-ID: <20200727113023.D1F8C44230@lignose.oclsc.org> Henry Bent: Are there any former Bell Labs sysadmins on this list? My father was the sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the mid-late '80s and early '90s and I would be especially interested to hear from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and the like. I'm very curious about what life was like on the ground, so to speak. ===== It is worth pointing out that, like many universities, Bell Labs had at least two layers of computing and therefore of sysadmins. There were official central Comp Centers, which is the world Henry asks specifically about; but there were also less-central computing facilities at the divisional and center and department level. I never worked for a comp center, but my role in 1127 was basically that of sysadmin for our center's own systems; the ones used both for our day-to-day computing (including that known to the uucp world as research!) and for OS and other experiments and research and hacking. There were also two large VAXes called alice and rabbit, which afforded general-use computing for other departments in Division 112. Us 1127 sysadmins (I wasn't the only one by any means) ran those too; I don't know the full history but I gather that happened because there was some desire to run the Research version of UNIX rather than the comp-center one for that purpose. One system I had hands in straddled the researcher/comp-center boundary: 3k, the Cray X-MP/24 bought specifically for researchers. It was physically located in the comp center, but managed jointly: it ran Cray's UNICOS but with substantial additions from the Research world, including the stream I/O system (which is rather self-contained so it was not too hard to graft into a different UNIX) and Datakit support (using a custom interface board designed and built by Alan Kaplan and debugged by me and Alan over several late-night sessions. (I remember that the string "feefoefum\n", which is an obscure cultural reference from one of my previous workplaces, was particularly effective at shaking out bugs!) Once UNICOS-a-la-Research was running stably, staff from the Murray Hill Comp Center looked after day-to-day operations, with Research involved more for software support as needed. Norman Wilson Toronto ON From norman at oclsc.org Mon Jul 27 09:37:17 2020 From: norman at oclsc.org (Norman Wilson) Date: Sun, 26 Jul 2020 19:37:17 -0400 (EDT) Subject: [TUHS] Troff to ps Message-ID: <20200727113023.D44494422C@lignose.oclsc.org> Nemu Nusquam: When was dpost born? ===== CSTR 97, A Typesetter-Independent TROFF by Brian W Kernighan was issued in 1981 and revised the next year. So that's the earliest possible date. I vaguely remember the existence of Postscript support in general, including at least one Apple Laserwriter kicking around somewhere, starting at some point during my time at 1127 in the latter 1980s. There was even a Postscript display engine that ran on 5620 terminals under mux, though it wasn't normally used for troff previewing because the troff-specific proofer was faster (mainly, I think, it didn't send nearly as much data down the serial line to the terminal). My personal snapshot of V10, and the TUHS archive copy, include dpost; see src/cmd/postscript/dpost. Everything in the postscript directory came from USG, who had packaged everything troff into a separately-licensed Documenter's Workbench package. That may have made us exclude it from the officially-distributed V8 tape and V9 snapshots. In any case, the only V9 snapshot I know of offhand (which is in Warren's archive) has no dpost. Both my copy of V10 and the TUHS copy show dpost's source files with dates in 1991, but it was certainly there earlier if I used it in New Jersey (I left in mid-1990). Dpost is documented in man8/postscript.8; my copy of that file is dated October 1989. Digging around in documents available on the web, I found a bundle of DWB 2.0 docs: http://www.bitsavers.org/pdf/att/unix/Documentors_Workbench_1989/UNIX_System_V_Documentors_Workbench_Reference_Manual_1989.pdf It's a scanned-image PDF so I can't search it by machine, but it includes such things as listings of the source-code directory and manifests of various binary distributions, and dpost doesn't appear anywhere I can see. As the URL implies, the docs seem to be dated 1989. So maybe dpost wasn't part of the product until DWB 3.0; but maybe we in Research got an early copy of the postscript stuff (I think bwk was in regular communication with the USG-troff folks), perhaps in 1989. I confess I've lost track of the original question that spawned this thread, but if it is whether dpost is easily back-ported to PDP-11 UNIX, I don't think that's likely without a good bit of work. It would very likely require a post-1980-type C compiler, since it was written in the late 1980s. It might or might not fit on a PDP-11; I don't remember whether USG's system still officially ran there by the late 1980s. Norman Wilson Toronto ON From jaapna at xs4all.nl Tue Jul 28 01:08:54 2020 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Mon, 27 Jul 2020 17:08:54 +0200 Subject: [TUHS] Troff to ps In-Reply-To: <20200727113023.D44494422C@lignose.oclsc.org> References: <20200727113023.D44494422C@lignose.oclsc.org> Message-ID: > On Jul 27, 2020, at 1:37, Norman Wilson wrote: > > Nemu Nusquam: > > When was dpost born? > > ===== > > CSTR 97, A Typesetter-Independent TROFF by Brian W Kernighan > was issued in 1981 and revised the next year. So that's the > earliest possible date. But that was before postscript, that was for the new typesetter. > I vaguely remember the existence of Postscript support in > general, including at least one Apple Laserwriter kicking > around somewhere, starting at some point during my time at > 1127 in the latter 1980s. First there was the Canon (LP 10 I believe) and postscript came later. SoftQuad licensed the DWB quite early in the process. > It's a scanned-image PDF so I can't search it by > machine, but it includes such things as listings of > the source-code directory and manifests of various > binary distributions, and dpost doesn't appear anywhere > I can see. As the URL implies, the docs seem to > be dated 1989. So maybe dpost wasn't part of the > product until DWB 3.0; but maybe we in Research got > an early copy of the postscript stuff (I think bwk > was in regular communication with the USG-troff > folks), perhaps in 1989. There was quite some communication between Peter Nilson (npn, known for picasso) and bwk. I myself ended up working on the last DWB (3.4.1). jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From will.senn at gmail.com Tue Jul 28 01:53:05 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 10:53:05 -0500 Subject: [TUHS] Troff to ps In-Reply-To: References: Message-ID: Clem, Thanks for explaining it so clearly. I'll give copying the macros back to host and referencing them explicitly a try before I go hacking on the source files. and yes, I'm a wimp. I love tooling around in v6... up until the 15th time I've typed in a program that should work, but doesn't because of some hidden backspace or tab or who knows what little problem (don't paste source into ed, if # is the erase key, cuz ed eats the comments, and so on). I like vi (heck, I love vi, and I don't mean vim, although vim's nice too) so 211 bsd is refreshing :). If I could EVER get vi and tar to cooperate on v6, I think I'd be happy to stick with it, but no matter how many times I try, the best I ever get is a big headache and crippletar and I'm not even sure v6 will run vi, even for gurus,  but if it does, I'm no guru. However, that said, I'm getting pretty good with ed these days :). Thanks, Will On 7/26/20 10:33 AM, Clem Cole wrote: > > > On Sun, Jul 26, 2020 at 10:58 AM Will Senn > wrote: > > All, > > So... I've moved on from v7 to 2.11bsd - shucks, vi and tar and > co. just work there and everything else seems to be similar enough > for what I'm interested in anyway. So yay, I won't be pestering > y'all about vi anymore :). One the other hand, now I'm interested > in printing the docs. > > Wimp .. ;-)  seriously at this step, it might be easier for you as a > more modern user. > > > 2.11bsd comes with docs in, of all places, /usr/doc. > > Well that is where is was in V7 ;-) > > In there are makefiles for making the docs - ok, make nroff will > make ascii docs, and troff will make troff? docs using Ossana's > 'original' troff. > > yep > > So, after adding -t to it so it didn't complain about 'typesetter > busy', I got no errors. > > right... > > I mounted a tape, tar'ed my .out file and untar'ed it on my > macbook (did it for the nroff and troff output). Then I hit the > first snag, groff -Tps -ms troff.out > whatever.ps > resulted in cannot adjust line and cannot > break line errors and groff -Tps -ms nroff.out > whatever.ps > resulted in a bunch of double vision. I seem > to recall doing this in v6 and it working ok (at least for nroff). > > Well let's just save -ms and troff itself were re-implemented and > there are likely to be some small differences. > At UCB, the command would have been: tbl < input_troff_text | eqn | > troff -t -ms | vcat > > vcat(1) was the virtual CAT typesetter using a Versatec Plotter. > > Adobe released a source-level product called transcript, that you > recompiled and ran on V7 or later (like the PDP-11s). My memory > it was ~ $1K back in the day.  Transcript 2.0 contained a number of > tools.  One was a CAT to PS converter. Another was the tables for the > ditroff to spit out PS so: ditroff -Tps worked as expected and a > program called 'enscript' that converted from txt to PS. > > All of these tools have modern FOSS equivalents, but it may take some > hunting to find them.  I think sources to transcript 2.0 can be found > if you google around.  I'm not sure Adobe ever officially made is > FOSS, but after the modern equivalent showed up, I'm not aware of them > minding that people did not have the license since it sold more > printers with PostScript.    That should just recompile on V7 or later > and 'just work.'  The modern equivalent might take some backporting. > > BTW: Thinking about this, I believe I remember that there is a > directory on Kirk's CD's that have a copy from UCB.  Mount his disks > and poke around.  I'll try to look myself but I'm supposed to be > helping my wife get ready for a socially distanced birthday party for > our great-niece [we have the big back yard, tent et al that can handle > the 6 foot part requirements]. > > > My questions: > 1. Is there a troff to postcript conversion utility present in a > stock 2.11 system (or even patch level 4xx system)? > > The word "present"t is the operative term.  Probably not. > > 2. Is there a way to build postscript directly on the system? > > Yes, see above. > > 3. Is there an alternative modern way to get to ps or pdf output > from the nroff/troff that 2.11 has? > > Yep - Ghostscript based tools which is what the Transcript > replacements tend to use. > > > I'm still digging into the nroff stuff as that may be just minor > diffs between ancient nroff macros and "modern" macros or even > just errors (.sp -2 rather than .sp or .sp -1, .in -2 instead of > .in +2), etc. > > Be careful - that's not quite the same.  Basically groff fixed a > number of long-standing issues that older troff/ditroff had worked > around.  Usually, the difference is that the original nroff/troff has > some defaults that now need to make explicit.  But most older *roff > documents can go through modern groff just fine.  The more typical > error from old documents is a site that did not have a Versatec or > later an Apple Laserwriter and only supported nroff.   A number of > documents when created for nroff will look ugly when you run them > through any version of troff (old or new) as the document authors > never took the time to deal with the differences in the output device. > > Although, the files display ok in 2.11bsd using nroff -ms nroff.out... > > I would expect so. I bet they are fine with troff -t or if you can > find ditroff (which also maybe on Kirk's CD) and then run the output > through vcat or transcript.   Note if you used vcat you will get some > printing facsimiles that were there back in the day.  The reason is > when Tom Ferrin wrote vcat, the only fonts he had were the old Hershey > fonts (fonts have gotten >>so<< much better since then).   So troff is > using Wang CAT4 typesetter font rules and Tim is doing the best he can > to map that to Hershey. The PS CAT simulator in Transcript has the > same issue BTW.  It's a little better since the PS fonts are better > but they don't map the 100%.  However, if you use ditroff, Adobe > supplied the rules in Transcript so that ditroff did its calculations > using the proper fonts (Adobe's not Wang's). > > Clem -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 01:58:10 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 10:58:10 -0500 Subject: [TUHS] Troff to ps In-Reply-To: <202007261531.06QFVqZb027062@freefriends.org> References: <202007261531.06QFVqZb027062@freefriends.org> Message-ID: <45106522-da44-1a05-ea57-3864106f0f02@gmail.com> On 7/26/20 10:31 AM, arnold at skeeve.com wrote: > Will Senn wrote: > >> My questions: >> 1. Is there a troff to postcript conversion utility present in a stock >> 2.11 system (or even patch level 4xx system)? > Troff from that era was designed to drive the C/A/T phototypesetter. > There were tools that converted from C/A/T to postscript but they > were mostly commercial IIRC. > >> 2. Is there a way to build postscript directly on the system? > Likely not. > >> 3. Is there an alternative modern way to get to ps or pdf output from >> the nroff/troff that 2.11 has? > I would recommend tar-ing up the doc and macros, moving them to Linux > or other modern system, and using groff -C to create postscript/pdf. > That really will be the fastest way. > > Arnold Arnold, Thanks. This is next up on the to try list. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 28 04:57:59 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 27 Jul 2020 12:57:59 -0600 Subject: [TUHS] reboot(2) system call Message-ID: I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html may be of interest. Please do let me know if I've gotten something wrong... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 28 10:36:33 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Jul 2020 20:36:33 -0400 Subject: [TUHS] reboot(2) system call In-Reply-To: References: Message-ID: Warner - awesome. I would add a few things that were sort of in the story, although not directly. The primary difference between 4.0 and 4.1 was originally a political push with Stanford trying to get VMS as the official OS for Arpa and Joy countering with BSD claiming it was within epsilon of VMS and in some cases faster. The performance was the biggest of the Stanford complaints which Bill fixed with a much a carefully placed assembler. But IIRC, one of the other issues was "UNIX is unreliable" and file system corrupt was tossed out as an example of the same [The lack of real/complete Fortran compiler was never corrected, but I remember that was one of the other reasons given. But it was one of the reasons why a couple of UCB compiler folks worked on improving F77 and building dbx, although it was never in the same league as VMS's compiler or any of the many DEC debuggers]. Anyway, after 4.0 came out, Goble released the 'Purdue file system fixes'. When V6-4.1BSD Unix crashed, the OS was noted for leaving a possible corrupted file system (this was why tjk wrote fsck of course for V6 years before). George really spent time analyzing the order that different writes were done *i.e.* making sure the data, inodes, superblock were updated in the right order. This cut down file system corruption after a system crash. He also had a way to force the buffer cache to be cleared properly and part of that was that George had implemented reboot independently of Joy and I think before Bill. Certainly by 4.1B when McKussick's new FS was being folded into the kernel, Joy had pulled the original file system write order changes from Purdue. He may have done that as part of 4.1 "FASTVAX" work and before he explored reboot. The point is that sync, reboot, and file system block write ordering was all mixed together. On Mon, Jul 27, 2020 at 3:01 PM Warner Losh wrote: > I've done some research for a friend about when the reboot() system call > was added, and how it related to the sync, sync, sync dance. > > https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html > > may be of interest. Please do let me know if I've gotten something wrong... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 10:39:24 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 19:39:24 -0500 Subject: [TUHS] v7 tar and 2bsd.tar Message-ID: I'm trying to get 2bsd.tar extracted into v7. Does anyone have any recollection how to do this. Here's what I'm seeing: in simh: simh> att  tm0 -V -F TAR 2bsd.tar Tape Image '2bsd.tar' scanned as TAR format. contains 4935680 bytes of tape data (482 records, 1 tapemarks) c and in v7: tar xv0 tar: bin/ - cannot create directory checksum error # ls bin What gives - it says it can't create the dir, but it does, it's there... Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 28 11:14:37 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Jul 2020 21:14:37 -0400 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: Message-ID: Will, on your local system, take the tarball and pull off Joy's tar binary then move it over using dd and the trick with the disks. Joy's label told you to use his program. So try it. By on you mac: tar xvf 2bsd.tar tar src/tar <-- the later one because he gave you two ls -l tar <-- you may want a byte and block count dd if=tar of=ucbtar bs=1b conv=sync <-- pad to disk block size then on simh: att ucbtar to the rk05 and attach your tape 2bsd.tar like you did before on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the binary with the padded last block in if you want to strip off the extra bytes, feel free but I don't think it's going to matter. chmod 755 ucbtar ./ucbtar vt0 <--- see it works If that fails, try the other tar he left you on the tape. My guess is that the tarball Warren has was written with a more modern tar and the old tar can not handle the tar threaded tape directory. This is possible as a lot was added to later versions tars and it's clear this is not exactly the tape image that Joy wrote/distributed. So, Ken's original version might just be unable to handle it. Hopefully, it is the contents, but it was not written with Joy's 'tarit' script and maybe not on a V7/2BSD system. Clem On Mon, Jul 27, 2020 at 8:41 PM Will Senn wrote: > I'm trying to get 2bsd.tar extracted into v7. Does anyone have any > recollection how to do this. Here's what I'm seeing: > > in simh: > simh> att tm0 -V -F TAR 2bsd.tar > Tape Image '2bsd.tar' scanned as TAR format. > contains 4935680 bytes of tape data (482 records, 1 tapemarks) > c > > and in v7: > tar xv0 > tar: bin/ - cannot create > directory checksum error > # ls > bin > > > What gives - it says it can't create the dir, but it does, it's there... > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 13:02:47 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 22:02:47 -0500 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: Message-ID: On 7/27/20 8:14 PM, Clem Cole wrote: > on v7:  dd if=/dev/rrkN of=ucbtar bs=1          <-- this should pull > the binary with the padded last block in > Your instructions held up until I tried to read from the rk device - here's my attach: in simh: set rk0 rk05 att rk0 ucbtar then in v7 the rk's aren't in /dev, so: looked in c.c, rk is major dev 0, and rrk is dev 9, so... /etc/mknod /dev/rk0 b 0 0 /etc/mknod /dev/rrk0 c 9 0 chmod 640 /dev/*rk* and dd if=/dev/rrk0 of=ucbtar bs=1 cannot open: /dev/rrk0 Look reasonable? Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 13:20:21 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 22:20:21 -0500 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: Message-ID: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> On 7/27/20 10:02 PM, Will Senn wrote: > On 7/27/20 8:14 PM, Clem Cole wrote: >> on v7:  dd if=/dev/rrkN of=ucbtar bs=1          <-- this should pull >> the binary with the padded last block in >> > Your instructions held up until I tried to read from the rk device - > here's my attach: > > in simh: > set rk0 rk05 > att rk0 ucbtar > > then in v7 the rk's aren't in /dev, so: > > looked in c.c, rk is major dev 0, and rrk is dev 9, so... > /etc/mknod /dev/rk0 b 0 0 > /etc/mknod /dev/rrk0 c 9 0 > chmod 640 /dev/*rk* > > and > dd if=/dev/rrk0 of=ucbtar bs=1 > cannot open: /dev/rrk0 > > Look reasonable? > > Will > OK. I remembered that I needed to recompile the kernel, so in addition to the above: in v7: chdir /usr/sys/conf cc mkconf.c mv a.out mkconf echo rk >> myconf cat myconf hp root hp 0 swap hp 1 swplo 0 nswap 8778 tm 4dc rk mkconf < myconf console at 60 clock at 100 clock at 104 parity at 114 rk at 220 tm at 224 hp at 254 dc at 300 dc at 310 dc at 320 dc at 330 as - -o l.o l.s cc -c c.c ld -o unix -X -i l.o mch.o c.o ../sys/LIB1 ../dev/LIB2 mv unix /munix rebooted and: dd if=/dev/rrk0 of=ucbtar bs=1 read: Bad address 0+0 records in 0+0 records out -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 28 13:20:31 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Jul 2020 23:20:31 -0400 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: Message-ID: below.. On Mon, Jul 27, 2020 at 11:02 PM Will Senn wrote: > On 7/27/20 8:14 PM, Clem Cole wrote: > > on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the > binary with the padded last block in > > ouch my screw up... should be 1b > > Your instructions held up until I tried to read from the rk device - > here's my attach: > > in simh: > set rk0 rk05 att rk0 ucbtar > This is what I have: ; RK05 data disks (4 drives)... ;; SET RK ENABLE SET RK0 WRITEENABLED SET RK1 WRITEENABLED SET RK2 WRITEENABLED SET RK3 WRITEENABLED SET RK4 DISABLED SET RK5 DISABLED SET RK6 DISABLED SET RK7 DISABLED ATTACH RK0 ./scratch.rk05 SHOW RK > > then in v7 the rk's aren't in /dev, so: > there is a makefile in /dev that creates them. Take a look and see what its doing. looked in c.c, rk is major dev 0, and rrk is dev 9, so... > /etc/mknod /dev/rk0 b 0 0 > /etc/mknod /dev/rrk0 c 9 0 > chmod 640 /dev/*rk* > > and > dd if=/dev/rrk0 of=ucbtar bs=1 > bs=1b sorry -- my error, but I don't think that's the issue. try this for grins: dd if=/dev/rrk0 of=/dev/null bs=1b cannot open: /dev/rrk0 > Hmm... be good to see what the errno value is, i.e. why? Maybe a small C program that tries to open /dev/rrk0 and prints out errno on failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 28 13:21:49 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Jul 2020 23:21:49 -0400 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> References: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> Message-ID: try 1b for the blocking. On Mon, Jul 27, 2020 at 11:20 PM Will Senn wrote: > On 7/27/20 10:02 PM, Will Senn wrote: > > On 7/27/20 8:14 PM, Clem Cole wrote: > > on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the > binary with the padded last block in > > Your instructions held up until I tried to read from the rk device - > here's my attach: > > in simh: > set rk0 rk05 > att rk0 ucbtar > > then in v7 the rk's aren't in /dev, so: > > looked in c.c, rk is major dev 0, and rrk is dev 9, so... > /etc/mknod /dev/rk0 b 0 0 > /etc/mknod /dev/rrk0 c 9 0 > chmod 640 /dev/*rk* > > and > dd if=/dev/rrk0 of=ucbtar bs=1 > cannot open: /dev/rrk0 > > Look reasonable? > > Will > > OK. I remembered that I needed to recompile the kernel, so in addition to > the above: > > in v7: > chdir /usr/sys/conf > cc mkconf.c > mv a.out mkconf > > echo rk >> myconf > cat myconf > hp > root hp 0 > swap hp 1 > swplo 0 > nswap 8778 > tm > 4dc > rk > > mkconf < myconf > console at 60 > clock at 100 > clock at 104 > parity at 114 > rk at 220 > tm at 224 > hp at 254 > dc at 300 > dc at 310 > dc at 320 > dc at 330 > as - -o l.o l.s > cc -c c.c > ld -o unix -X -i l.o mch.o c.o ../sys/LIB1 ../dev/LIB2 > mv unix /munix > > rebooted and: > dd if=/dev/rrk0 of=ucbtar bs=1 > read: Bad address > 0+0 records in > 0+0 records out > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 13:47:57 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 22:47:57 -0500 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> Message-ID: <5d2dd1bb-4c4e-6799-47f5-12faae521eb0@gmail.com> On 7/27/20 10:21 PM, Clem Cole wrote: > try 1b for the blocking. Hmm: dd if=/dev/rrk0 of=ucbtar bs=1b no space on dev 6/0 write: No space left on device 1175+0 records in 1175+0 records out ls -l -rw-rw-r-- 1 root   601088 Dec 31 19:41 ucbtar df bad free count, b=1 /dev/rp0 0 yeah, well no kidding, that file is WAY bigger than the file on the host. so... rm ucbtar  (or bad things WILL happen with no space left) set bs explicitly on the mac side of things dd if=tar of=ucbtar bs=512 conv=sync 27+1 records in 28+0 records out ls -l -rwxr-x---  1 wsenn  staff      14156 Jul 27 22:32 tar -rw-r--r--  1 wsenn  staff      14336 Jul 27 22:44 ucbtar so back in v7: set bs explicity  and # blocks to read (otherwise it reads past the size of the file, simh quirk?) dd if=/dev/rrk0 of=ucbtar bs=512 count=28 28+0 records in 28+0 records out # chmod 0755 ucbtar # ls -l total 28 -rwxr-xr-x 1 root    14336 Dec 31 19:47 ucbtar # ./ucbtar x tar: bin/ - cannot create directory checksum error echo $? 2 Haha, I'm learning, but I wanna cry :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 28 13:55:04 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Jul 2020 22:55:04 -0500 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: <5d2dd1bb-4c4e-6799-47f5-12faae521eb0@gmail.com> References: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> <5d2dd1bb-4c4e-6799-47f5-12faae521eb0@gmail.com> Message-ID: On 7/27/20 10:47 PM, Will Senn wrote: > On 7/27/20 10:21 PM, Clem Cole wrote: >> try 1b for the blocking. > Hmm: > dd if=/dev/rrk0 of=ucbtar bs=1b > no space on dev 6/0 > write: No space left on device > 1175+0 records in > 1175+0 records out > > ls -l > -rw-rw-r-- 1 root   601088 Dec 31 19:41 ucbtar > > df > bad free count, b=1 > /dev/rp0 0 > > yeah, well no kidding, that file is WAY bigger than the file on the > host. so... > > rm ucbtar  (or bad things WILL happen with no space left) > > set bs explicitly on the mac side of things > dd if=tar of=ucbtar bs=512 conv=sync > 27+1 records in > 28+0 records out > > ls -l > -rwxr-x---  1 wsenn  staff      14156 Jul 27 22:32 tar > -rw-r--r--  1 wsenn  staff      14336 Jul 27 22:44 ucbtar > > so back in v7: > > set bs explicity  and # blocks to read (otherwise it reads past the > size of the file, simh quirk?) > dd if=/dev/rrk0 of=ucbtar bs=512 count=28 > 28+0 records in > 28+0 records out > > # chmod 0755 ucbtar > # ls -l > total 28 > -rwxr-xr-x 1 root    14336 Dec 31 19:47 ucbtar > > # ./ucbtar x > tar: bin/ - cannot create > directory checksum error > echo $? > 2 > > Haha, I'm learning, but I wanna cry :). > > And the other copy of tar: ucbtar x Tar: blocksize = 20 tar: bin/ - cannot create directory checksum error # echo $? 2 Ah well, I'll pick it back up tomorrow. I remember doing this on v6. I'm gonna see if I can dig up some old notes. Maybe I unpacked the tar on the host and used simtools to repack as magtape... just seems like this oughta work. -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jul 28 14:06:32 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Jul 2020 14:06:32 +1000 (EST) Subject: [TUHS] reboot(2) system call In-Reply-To: References: Message-ID: On Mon, 27 Jul 2020, Warner Losh wrote: > I've done some research for a friend about when the reboot() system call > was added, and how it related to the sync, sync, sync dance. > https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html > > may be of interest. Please do let me know if I've gotten > something wrong... Seems OK to me; I was taught never to use "sync; sync; sync" for precisely those reasons (the buffers may not have time to flush etc, as "sync" merely schedules the I/O, not cause it. -- Dave From steve at quintile.net Tue Jul 28 19:42:53 2020 From: steve at quintile.net (Steve Simon) Date: Tue, 28 Jul 2020 10:42:53 +0100 Subject: [TUHS] Troff to ps (Will Senn) Message-ID: <2D95EE85-DD08-42ED-B7F3-243E423F879D@quintile.net> Hi folks, I used thack to typeset my dissertation on v7 circa 1988. It converts C/A/T codes to postscript. i have no idea if it will cope with eqn or pic but it was enough for nicely formatted text as i remember. this is the patch/bugfix with a link to the original package. https://www.tuhs.org/Usenet/comp.sources.misc/1989-July/001073.html -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Jul 28 21:33:20 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 28 Jul 2020 07:33:20 -0400 Subject: [TUHS] Troff to ps Message-ID: <202007281133.06SBXKwZ075620@tahoe.cs.Dartmouth.EDU> > There was quite some communication between Peter Nilson (npn, known > for picasso) and bwk. In the interest of accuracy npn's full name is Nils-Peter Nelson. He honchoed the Bell Labs Cray and originated . Doug From jaapna at xs4all.nl Tue Jul 28 23:11:21 2020 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Tue, 28 Jul 2020 15:11:21 +0200 Subject: [TUHS] reboot(2) system call In-Reply-To: References: Message-ID: > On Jul 27, 2020, at 20:57, Warner Losh wrote: > > I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. I remember that Piet Beertema (CWI) added a reboot command to our unix V7 on the 11/45. I just asked him and he said that it he did it because he was tired to walk to the computer room. It was way more work then he at first expected. Whether this was picked op by the Berkeley people he doesn't know, but it could be. jaap From will.senn at gmail.com Tue Jul 28 23:38:00 2020 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Jul 2020 08:38:00 -0500 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> <5d2dd1bb-4c4e-6799-47f5-12faae521eb0@gmail.com> Message-ID: After much travail, I found a post in some ancient Asian language (Japanese) and was reminded of Wolfgang's enblock. I didn't bother to translate, but just did the enblock: gunzip -d 2bsd.tar.gz cat 2bsd.tar | enblock > 2bsd.tap I attached the result, et voila: tar xv0 tar: bin/ - cannot create x bin/csh, 40412 bytes, 79 tape blocks tar: bin/etc/ - cannot create x bin/etc/htmp, 0 bytes, 0 tape blocks x bin/etc/install, 81 bytes, 1 tape blocks The cannot create messages are filthy lies :). That brought it all back to me - just like when I built tar from tape for v6... sheesh, why does it have to be so painfully difficult to remember these tricky bits?! Anyhow, afterward, I went back, did the translation from Japanese to English (or google did), and it was good stuff about how to apply 2bsd.tar to v6: https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Forumin.blogspot.com%2F2014%2F06%2Funix-and-2bsd-on-pdp11simh-2.html Thanks for the help and patience. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From clemc at ccc.com Tue Jul 28 23:50:25 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Jul 2020 09:50:25 -0400 Subject: [TUHS] v7 tar and 2bsd.tar In-Reply-To: References: <7b892386-6856-6bb8-9d87-a628645ecf19@gmail.com> <5d2dd1bb-4c4e-6799-47f5-12faae521eb0@gmail.com> Message-ID: Glad it's working. We probably need to create Joy's tarball in the future with the same file ordering he used and get that the Warren. The trick is getting a v6tar that properly works. Maybe one thing we should do is write a tp format 'tape' with the v6tar binary on it and get that in the archives independently. When V7 came out, there was a way to create v6tar (which I suspect is somehow part of Joy's image). The issue is that some of the system calls changed in small but important ways. tar was a much better way to move files around than tp which is why it so quickly became the archive scheme in the Unix community. On Tue, Jul 28, 2020 at 9:38 AM Will Senn wrote: > After much travail, I found a post in some ancient Asian language > (Japanese) and was reminded of Wolfgang's enblock. I didn't bother to > translate, but just did the enblock: > > gunzip -d 2bsd.tar.gz > cat 2bsd.tar | enblock > 2bsd.tap > > I attached the result, et voila: > tar xv0 > tar: bin/ - cannot create > x bin/csh, 40412 bytes, 79 tape blocks > tar: bin/etc/ - cannot create > x bin/etc/htmp, 0 bytes, 0 tape blocks > x bin/etc/install, 81 bytes, 1 tape blocks > > The cannot create messages are filthy lies :). > > That brought it all back to me - just like when I built tar from tape > for v6... sheesh, why does it have to be so painfully difficult to > remember these tricky bits?! > > Anyhow, afterward, I went back, did the translation from Japanese to > English (or google did), and it was good stuff about how to apply > 2bsd.tar to v6: > > > https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Forumin.blogspot.com%2F2014%2F06%2Funix-and-2bsd-on-pdp11simh-2.html > > Thanks for the help and patience. > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From treese at acm.org Wed Jul 29 02:35:13 2020 From: treese at acm.org (Win Treese) Date: Tue, 28 Jul 2020 12:35:13 -0400 Subject: [TUHS] reboot(2) system call In-Reply-To: References: Message-ID: <26006DA8-EF6D-42FC-8A11-E84447E6946A@acm.org> > On Jul 28, 2020, at 12:06 AM, Dave Horsfall wrote: > > On Mon, 27 Jul 2020, Warner Losh wrote: > >> I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html >> may be of interest. Please do let me know if I've gotten something wrong... > > Seems OK to me; I was taught never to use "sync; sync; sync" for precisely those reasons (the buffers may not have time to flush etc, as "sync" merely schedules the I/O, not cause it. This was summarized at MIT’s Project Athena in the mid-80s as: When thou shuttest down the system, thou shalt sync three times. No more, no less. Three shall be the number of the syncing, and the number of the syncing shall be three. Four times shalt thou not sync, neither sync twice, except that thou proceedest to sync a third time. Five is right out. - Win From will.senn at gmail.com Wed Jul 29 09:03:17 2020 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Jul 2020 18:03:17 -0500 Subject: [TUHS] 2bsd tarball Message-ID: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the archive. Neither is an installation tape. It appears that they are just tarballs of their respective systems (there are very minor differences between the two). In the TAPE file in the tarball, it talks about reading the tar program off of the tape using: dd if=/dev/mt0 bs=1b skip=1 of=tar Well, tar is definitely not located at that address, which implies that the tarball isn't a distro tape. This note in the archive used to read: ... The remaining gzipped tar files are other 2BSD distributions supplied by Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer. They do not contain installation tape images. The 2.9BSD-Patch directory contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic. ... now it reads: ... 2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came from Henry Spencer. ... I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? Thanks, Will Here's where I found the tarballs: https://www.tuhs.org/Archive/Distributions/UCB/ -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jul 29 10:09:31 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 28 Jul 2020 18:09:31 -0600 Subject: [TUHS] 2bsd tarball In-Reply-To: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: On Tue, Jul 28, 2020 at 5:04 PM Will Senn wrote: > OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the > archive. Neither is an installation tape. It appears that they are just > tarballs of their respective systems (there are very minor differences > between the two). > > In the TAPE file in the tarball, it talks about reading the tar program > off of the tape using: > dd if=/dev/mt0 bs=1b skip=1 of=tar > > Well, tar is definitely not located at that address, which implies that > the tarball isn't a distro tape. This note in the archive used to read: > > ... > > The remaining gzipped tar files are other 2BSD distributions supplied by > Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer. > They do not contain installation tape images. The 2.9BSD-Patch directory > contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic. > > ... > now it reads: > ... > > 2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied > by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came > from Henry Spencer. > ... > > I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? > > Both of the 2bsd tapes you found are from the days when Berkeley just sent patches to the 7th Edition out. The 2.8BSD tape was the first one to have a kernel that was bootable from the tape. The 2BSD tapes originally had 2 files on them. The first one was a binary copy of tar that ran on V7. The second was a tarball of all the rest. As you discovered, they shipped with a label like: Second Berkeley Software Tape May 10, 1979 TAR 800BPI %dd if=/dev/mt0 bs=1b skip=1 of=tar %chmod 755 tar % tar x 10000 blocks but the 2bsd.tar.gz file has just the second file. The spensor_2bsd.tar.gz has a tar binary in it: tar tvf spencer_2bsd.tar.gz | head -rw-r--r-- 0 0 0 24688 Feb 17 1980 tar -rw-r--r-- 0 0 10 3687 Feb 17 1980 tar.1 -rw-r--r-- 0 0 10 456 Feb 17 1980 tar.ms -rw-r--r-- 0 0 10 15216 Feb 17 1980 install.ms if you are looking for that pre-built. If you are looking to create a tape with tar on it to extract other tar tapes, you'd need to use a variation on the maketape.pl with a block size of 1 so the above dd will work on the target system... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jul 29 10:19:35 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Jul 2020 20:19:35 -0400 Subject: [TUHS] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: Note the UID/GID are numeric not ASCII ;-) I suspect henry's tape is closer to the official tape!! On Tue, Jul 28, 2020 at 8:11 PM Warner Losh wrote: > > > On Tue, Jul 28, 2020 at 5:04 PM Will Senn wrote: > >> OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the >> archive. Neither is an installation tape. It appears that they are just >> tarballs of their respective systems (there are very minor differences >> between the two). >> >> In the TAPE file in the tarball, it talks about reading the tar program >> off of the tape using: >> dd if=/dev/mt0 bs=1b skip=1 of=tar >> >> Well, tar is definitely not located at that address, which implies that >> the tarball isn't a distro tape. This note in the archive used to read: >> >> ... >> >> The remaining gzipped tar files are other 2BSD distributions supplied by >> Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer. >> They do not contain installation tape images. The 2.9BSD-Patch directory >> contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic. >> >> ... >> now it reads: >> ... >> >> 2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied >> by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came >> from Henry Spencer. >> ... >> >> I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? >> >> Both of the 2bsd tapes you found are from the days when Berkeley just > sent patches to the 7th Edition out. The 2.8BSD tape was the first one to > have a kernel that was bootable from the tape. The 2BSD tapes originally > had 2 files on them. The first one was a binary copy of tar that ran on V7. > The second was a tarball of all the rest. As you discovered, they shipped > with a label like: > Second Berkeley Software Tape > May 10, 1979 TAR 800BPI > > %dd if=/dev/mt0 bs=1b skip=1 of=tar > %chmod 755 tar > % tar x > > 10000 blocks > but the 2bsd.tar.gz file has just the second file. > > The spensor_2bsd.tar.gz has a tar binary in it: > > tar tvf spencer_2bsd.tar.gz | head > -rw-r--r-- 0 0 0 24688 Feb 17 1980 tar > -rw-r--r-- 0 0 10 3687 Feb 17 1980 tar.1 > -rw-r--r-- 0 0 10 456 Feb 17 1980 tar.ms > -rw-r--r-- 0 0 10 15216 Feb 17 1980 install.ms > > if you are looking for that pre-built. If you are looking to create a tape > with tar on it to extract other tar tapes, you'd need to use a variation on > the maketape.pl with a block size of 1 so the above dd will work on the > target system... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jul 29 10:21:19 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Jul 2020 20:21:19 -0400 Subject: [TUHS] 2bsd tarball In-Reply-To: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: Cross posting to simh - since much of this has been discussed in the last few days there also.... in for penny, in for pound ... here is the history ... man ... I lived this and I'll need a strong drink later tonight after I write it all up. On Tue, Jul 28, 2020 at 7:04 PM Will Senn wrote: > I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? > > cont.a is a tp-v6 and earlier ism. DECtape had a directory at the front of the tape (think superblock/ilist), but could do cool things and be treated more like a disk. When tp was created for a very early version of Unix (I'm not sure which, could be V2), Ken/Dennis et al had DECtape units and so the original scheme followed the media. This also meant that the program could write files and go back and update the directory, which is a no-no with many tape systems. Then research got a 9-track unit. So tp was changed to calculate how much space was going to be needed, write the directory, then the datablocks. All good ... except... 9-track could write more files than the directory could take. So for many years, people would use the ar(1) program to take a number of files in a directory, create a file called cont.a and then delete the files. Then the tree would be written with tp, when you read it, you reversed the ar(1) process. If you look at the USENIX/Harvard tape on the TUHS you'll see this scheme in use. BTW: tp was written in assembler and all the data structures were using PDP-11 binary formats. Eventually, Harvard wrote stp (super-tp) in C (which is on the USENIX tape Warren has in the archives) that worked like the original assembler tp but also put a redundant directory at the end of the tape. Another issue with tp was if the you had a bad block in the first few blocks you could not decode the rest of the tape. [There were some other issues with the UNIX tree structure as disks got bigger but I'm going to ignore all that - other than to say, tp had lived it life]. Enter Mashey and the PWB 1.0 folks (which is based on V6). Someone in USG created cpio (and volcpy) as part of the PWB 1.0. Like tp it was a PDP-11 binary format, but unlike tp, the tape directory is threaded. *i.e.* block one describes the first file only and includes the size of the following file, then file itself, then a new directory block for the next file and again that file (rinse and repeat). So it improved on tp in the directory threading, but was still binary and for a reasons I'll leave out had a different user interface. As part of V7, Ken wrote a new program, tar [you can ask him why]. But like cpio he used a threaded tape directory, but unlike cpio it was always ASCII and not PDP-11 specific. Furthermore, the user interface was made to parrot tp. So, certainly, it had the advantage that changing tp scripts to use tar was pretty easy i.e. s/tp/tar/ not so for coil. And it was muscle memory compliant. For PWB 2.0, cpio was updated to allow a -c option to write the header in ascii and -s to byte swap the binary. But the damage had been done ... Thus began 'tar wars' which was a battle that raged officially over tape archive formats, but really was an argument about user interfaces. Since tar was part of Research and the Universities and commercial people used it, only USG and the folks inside the Bell System were using cpio, as officially none of us had it since PWB was not released to us (although thanks to many AT&T employees doing an OYOC year, many schools like UCB, MIT and CMU all had the sources to cpio anyway -- for instance you'll see it hidden away on Kirk's CD). I personally had used both, preferred tar for easy of use and ASCII directories. But, note I had written car at Masscomp, but never tpio. This was our trick to use the file scripting list that cpio could do, but create tar format tapes - which was handy. I never wrote tpio which would have been cpio format using tp/tar user interface as I did not need it. Roll forward to the /usr/group UNIX standard that Heinz chaired. We ended up not being able to agree on a distribution format, but the ISVs were PO because now they could create UNIX programs that might actually work across systems, but they had not standard way to distribution. Roll forward again to IEEE. Heinz's committee was officially disbanded (story discussed elsewhere) and we were created as IEEE P1003 with Jim Issack as Chair. This time the ISV's said we had to have a distribution format. Since *.1 was only an API we were allowed to avoid the user interface issue but only examine the on tape format. It turns out while it seems to have been unintended, Ken's original V7 implementation has an interesting coding feature/bug which turns out to be what clinched the deal. When Ken creates the directory block for each file, he did bcopy of 0's to the buffer before he wrote that data that fills it in. Then when he calculated the checksum for the directory header block, he summed the entire block (which because of the bcopy was zeros). This means if you write beyond the end of Ken's original header and include that extra data in the chksum, the original program will ignore the new information but accept the directory block as valid. i.e. he had built an extension mechanism into the tar on-tape format. cpio's ASCII on tape format was not able to do that as the checksum used a sizeof(header struct) in the checksum routine. USTAR was born ... Ken had written things like the UID/GID as ASCII representations of the integer value in the original header. USTAR added the ASCII representation of the username and the group name since that was more often portable between systems than the numbers. There were other additions like more room for the pathname new file types *etc*. But the key is that a USTAR tape can be read by the original V7 (and follow on) tape formats, although may not recognize all the filetype or use all of the new information. A few years later during *.2 discussions, we finally got into the user interface stuff and pax(1) was born. Knowing my hack with car, Keith Bostic, Jim McGuiness and I wrote up a description of a program that could with both users interfaces scheme. USENIX provided funding for a student to implement it and put the sources out on comp.unix.sources at some point. That proposal was originally accepted at the first tape user interface program in *.2 [a few years later after I stopped being part of the committee, the USG folks did get an alternate CPIO format accepted and cpio as an allowed program. USENIX paid to have the program updated to operate like cpio if it was called that, pure V7 tar if called that and if pax, user USTAR]. 'nuf said ... I hope. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Jul 29 10:45:39 2020 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Jul 2020 19:45:39 -0500 Subject: [TUHS] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: <7ef26f20-ad9c-a7f1-d074-82e25e95b095@gmail.com> On 7/28/20 7:09 PM, Warner Losh wrote: > > Both of the 2bsd tapes you found are from the days when Berkeley just > sent patches to the 7th Edition out. The 2.8BSD tape was the first one > to have a kernel that was bootable from the tape. The 2BSD tapes > originally had 2 files on them. The first one was a binary copy of tar > that ran on V7. The second was a tarball of all the rest. As you > discovered, they shipped with a label like: >         Second Berkeley Software Tape >         May 10, 1979    TAR 800BPI > >         %dd if=/dev/mt0 bs=1b skip=1 of=tar >         %chmod 755 tar >         % tar x > >         10000 blocks > but the 2bsd.tar.gz file has just the second file. > > The spensor_2bsd.tar.gz has a tar binary in it: > > tar tvf spencer_2bsd.tar.gz | head > -rw-r--r--  0 0      0       24688 Feb 17  1980 tar > -rw-r--r--  0 0      10       3687 Feb 17  1980 tar.1 > -rw-r--r--  0 0      10        456 Feb 17  1980 tar.ms > -rw-r--r--  0 0      10      15216 Feb 17  1980 install.ms > > > if you are looking for that pre-built. If you are looking to create a > tape with tar on it to extract other tar tapes, you'd need to use a > variation on the maketape.pl with a block size of > 1 so the above dd will work on the target system... > > Warner OK. That makes sense. I'll just work with it as is on my v7 system. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Jul 29 10:46:56 2020 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Jul 2020 19:46:56 -0500 Subject: [TUHS] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: On 7/28/20 7:09 PM, Warner Losh wrote: > Both of the 2bsd tapes you found are from the days when Berkeley just > sent patches to the 7th Edition out. The 2.8BSD tape was the first one > to have a kernel that was bootable from the tape. The 2BSD tapes > originally had 2 files on them. The first one was a binary copy of tar > that ran on V7. The second was a tarball of all the rest. As you > discovered, they shipped with a label like: >         Second Berkeley Software Tape >         May 10, 1979    TAR 800BPI > >         %dd if=/dev/mt0 bs=1b skip=1 of=tar >         %chmod 755 tar >         % tar x > >         10000 blocks > but the 2bsd.tar.gz file has just the second file. > > The spensor_2bsd.tar.gz has a tar binary in it: > > tar tvf spencer_2bsd.tar.gz | head > -rw-r--r--  0 0      0       24688 Feb 17  1980 tar > -rw-r--r--  0 0      10       3687 Feb 17  1980 tar.1 > -rw-r--r--  0 0      10        456 Feb 17  1980 tar.ms > -rw-r--r--  0 0      10      15216 Feb 17  1980 install.ms > > > if you are looking for that pre-built. If you are looking to create a > tape with tar on it to extract other tar tapes, you'd need to use a > variation on the maketape.pl with a block size of > 1 so the above dd will work on the target system... This definitely makes sense. Thanks. This -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Wed Jul 29 19:50:25 2020 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 29 Jul 2020 11:50:25 +0200 Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> Just a small comment. Whoever it was that thought DECtape was a tape was making a serious mistake. DECtapes are very different from magtapes. Johnny On 2020-07-29 02:21, Clement T Cole wrote: > > Cross posting to simh - since much of this has been discussed in the > last few days there also.... > > in for penny, in for pound ... here is the history ...  man ... I lived > this and I'll need a strong drink later tonight after I write it all up. > > > On Tue, Jul 28, 2020 at 7:04 PM Will Senn > wrote: > > I recall having to do something with cont.a files, which are not > present on these images. So, my questions is, does anyone know of or > have an actual 2bsd tape/tape image? > > cont.a is a tp-v6 and earlier ism. > > DECtape had a directory at the front of the tape (think > superblock/ilist), but could do cool things and be treated more like a disk. > When tp was created for a very early version of Unix (I'm not sure > which, could be V2), Ken/Dennis et al had DECtape units and so the > original scheme followed the media.   This also meant that the program > could write files and go back and update the directory, which is a no-no > with many tape systems.  Then research got a 9-track unit.   So tp was > changed to calculate how much space was going to be needed, write the > directory, then the datablocks.  All good ... except... > > 9-track could write more files than the directory could take.   So for > many years, people would use the ar(1) program to take a number of files > in a directory, create a file called cont.a and then delete the files. > Then the tree would be written with tp, when you read it, you reversed > the ar(1) process.  If you look at the USENIX/Harvard tape on the TUHS > you'll see this scheme in use. > > BTW: tp was written in assembler and all the data structures were using > PDP-11 binary formats.  Eventually, Harvard wrote stp (super-tp) in C > (which is on the USENIX tape Warren has in the archives) that worked > like the original assembler tp but also put a redundant directory at the > end of the tape.  Another issue with tp was if the you had a bad block > in the first few blocks you could not decode the rest of the tape. > [There were some other issues with the UNIX tree structure as disks got > bigger but I'm going to ignore all that - other than to say, tp had > lived it life]. > > Enter Mashey and the PWB 1.0 folks (which is based on V6).  Someone in > USG created cpio (and volcpy) as part of the PWB 1.0.   Like tp it was a > PDP-11 binary format, but unlike tp, the tape directory is threaded. > /i.e./ block one describes the first file only and includes the size of > the following file, then file itself, then a new directory block for the > next file and again that file (rinse and repeat).  So it improved on tp > in the directory threading, but was still binary and for a reasons I'll > leave out had a different user interface. > > As part of V7, Ken wrote a new program, tar [you can ask him why].  But > like cpio he used a threaded tape directory, but unlike cpio it was > always ASCII and not PDP-11 specific.  Furthermore, the user interface > was made to parrot tp.  So, certainly, it had the advantage that > changing tp scripts to use tar was pretty easy i.e. s/tp/tar/     not so > for coil.  And it was muscle memory compliant. > > For PWB 2.0, cpio was updated to allow a -c option to write the header > in ascii and -s to byte swap the binary.   But the damage had been done ... > > Thus began 'tar wars' which was a battle that raged officially over tape > archive formats, but really was an argument about user interfaces. > Since tar was part of Research and the Universities and commercial > people used it, only USG and the folks inside the Bell System were using > cpio, as officially none of us had it since PWB was not released to us > (although thanks to many AT&T employees doing an OYOC year, many schools > like UCB, MIT and CMU all had the sources to cpio anyway -- for instance > you'll see it hidden away on Kirk's CD). > > I personally had used both, preferred tar for easy of use and ASCII > directories.  But, note I had written car at Masscomp, but never tpio. > This was our trick to use the file scripting list that cpio could do, > but create tar format tapes - which was handy.  I never wrote tpio which > would have been cpio format using tp/tar user interface as I did not > need it. > > Roll forward to the /usr/group UNIX standard that Heinz chaired.  We > ended up not being able to agree on a distribution format, but the ISVs > were PO because now they could create UNIX programs that might actually > work across systems, but they had not standard way to distribution. > Roll forward again to IEEE.  Heinz's committee was officially disbanded > (story discussed elsewhere) and we were created as IEEE P1003 with Jim > Issack as Chair. This time the ISV's said we had to have a distribution > format.  Since *.1 was only an API we were allowed to avoid the user > interface issue but only examine the on tape format. > > It turns out while it seems to have been unintended, Ken's original V7 > implementation has an interesting coding feature/bug which turns out to > be what clinched the deal.   When Ken creates the directory block for > each file, he did bcopy of 0's to the buffer before he wrote that data > that fills it in.  Then when he calculated the checksum for the > directory header block, he summed the entire block (which because of the > bcopy was zeros).  This means if you write beyond the end of Ken's > original header and include that extra data in the chksum, the original > program will ignore the new information but accept the directory block > as valid.  i.e. he had built an extension mechanism into the tar on-tape > format. > > cpio's ASCII on tape format was not able to do that as the checksum used > a sizeof(header struct) in the checksum routine. > > USTAR was born ... Ken had written things like the UID/GID as ASCII > representations of the integer value in the original header.  USTAR > added the ASCII representation of the username and the group name since > that was more often portable between systems than the numbers.   There > were other additions like more room for the pathname new file types > /etc/.  But the key is that a USTAR tape can be read by the original V7 > (and follow on) tape formats, although may not recognize all the > filetype or use all of the new information. > > A few years later during *.2 discussions, we finally got into the user > interface stuff and pax(1) was born.  Knowing my hack with car, Keith > Bostic, Jim McGuiness and I wrote up a description of a program that > could with both users interfaces scheme.  USENIX provided funding for a > student to implement it and put the sources out on comp.unix.sources at > some point.  That proposal was originally accepted at the first tape > user interface program in *.2 [a few years later after I stopped being > part of the committee, the USG folks did get an alternate CPIO format > accepted and cpio as an allowed program.   USENIX paid to have the > program updated to operate like cpio if it was called that, pure V7 tar > if called that and if pax, user USTAR]. > > 'nuf said ... I hope. > > Clem > > _._,_._,_ > ------------------------------------------------------------------------ > Groups.io Links: > > You receive all messages sent to this group. > > View/Reply Online (#62) | Reply To > Group > > | Reply To Sender > > | Mute This Topic | New Topic > > > Your Subscription | Contact > Group Owner | Unsubscribe > [bqt at softjar.se] > > _._,_._,_ -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From gnu at toad.com Wed Jul 29 23:42:45 2020 From: gnu at toad.com (John Gilmore) Date: Wed, 29 Jul 2020 06:42:45 -0700 Subject: [TUHS] 2bsd tarball -> pdtar, with a side of uuslave In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> Message-ID: <26260.1596030165@hop.toad.com> Clem Cole wrote: > 'nuf said ... I hope. Not quite, Clem! There was another chapter to the "tar wars" after UNIX and after POSIX. After I left Sun in about 1985, I worked on a project with GNU and the BSD folks, to find or write freely available implementations of many popular UNIX commands. Since we didn't find a free "tar" program, I wrote one from scratch, based on the SunOS man page and on running the tar binary from SunOS 3.3. This was eventually posted to Usenet's mod.sources as "pdtar" on 1986-12-10, as Volume 7 Issue 88. A July 1987 version went on the Sun User Group tape. A later version was posted to comp.sources.unix on 1987-11-29 as Volume 12, issue 68 in 3 parts. By then, it built and ran on SunOS, Xenix, Unisoft, Vax 4.2BSD, V7 and USG systems, MSDOS, and Minix. And "Utzoonix", Henry Spencer's customized system. In the process I discovered various quirks in the Unix tar program. It null-terminated some of the fixed-length octal fields in the tar headers and space-terminated others. I made my code produce bit-for-bit identical tar files, except for the leftover buffer garbage at the ends of files and in the last block after the second end-of-file all-zero header, which I zeroed. The UNIX tar program was also reading and writing the files in the file system in 512-byte reads and writes. Eg when extracting a file from a tape with the default blocking factor of 20, it would do 20 writes to the file rather than a single 10k write. pdtar did better. Oh, and by the way, the tar format DID use numerical uid and gid fields, encoded in ascii numerals in octal. Thus they were both numeric and ascii! What it didn't do was put in the NAMES of the user and their group; that idea came in with POSIX drafts, and went into separate fields that had been undefined & ignored in UNIX tar. I put the pdtar code into the public domain, so it could be widely used. This produced a variety of support headaches. In particular, people who used it on MSDOS kept contacting me over the years about bugs or documentation or not working with certain hardware. Those ports were largely distributed as binaries by other people who never bothered to include nor publish the matching source code. So I couldn't support the users who were having trouble, which was frustrating for both them and me. This eventually led me to understand more of the value in using the GNU General Public License. When the GNU Project later wanted someone else to enhance tar to satisfy some of the user requirements from the absence of dump(8), like incremental backups, they asked if I would mind if they put their improved version under the GPL. I had no problem with that, and the pdtar code became the base code for GNU Tar, which (along with the simple BusyBox tar) seems to have become the main implementation in the wild today. John PS: In that period, I also wrote the first reliable free implementation of uucp, called gnuucp. This code was based on "uuslave.c 1.7 08/12/85 12:04:20" which had been posted to the ACGNJ BBS system at +1 201 753 9758. Original author unknown. BSD and I went through a legal interaction with AT&T to verify that the uuslave code had NOT come from any proprietary UNIX code. The uuslave code barely limped (and had CP/M ifdef's), but it did point out the basics of the 'g' protocol. Once I got it working on UNIX, I ran it for a few weeks with my friends at lll-crg in Livermore, CA, then posted it to net.sources on 1987-03-25, article-id hoptoad.1925. By this time it had been ported to MSDOS by Tim Pozar. Soon it became the backbone of Tim's FIDOnet <-> Usenet gateway (UFGATE) software, which enabled thousands of (largely teenage) FIDOnet nodes to join the Usenet and swap email with UNIX machines and thus with the early Internet. Many years later, Ian Taylor wrote a complete free replacement for uucp, called Taylor UUCP, which seems to be what people were using last time I saw anyone using uucp. By coincidence, Ian also later worked with me at Cygnus, the first company doing commercial support for free software. A modern web search turns up this about uuslave's BBS: http://bbslist.textfiles.com/201/oldschool.html "201-753-9758 ACGNJ BBS #2 (1983-1990) Kevin Tillbrook RBBS "I used to run an RBBS system for the Amateur Computer Group of NJ (ACGNJ) for a number of years. It was run on a Zenith PC w/20 meg HD and later using DesqView for multi-tasking (which was way too slow on that hardware). I had a BBS running before that, but this is what I am noted for." - Kevin Tillbrook Does anybody here (from New Jersey perhaps) know where uuslave came from? It's always been a mystery to me. From cowan at ccil.org Wed Jul 29 23:52:58 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 29 Jul 2020 09:52:58 -0400 Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> Message-ID: When I talk about DECtape in my capacity as the local old fart, i describe it as "a disk with one track and about 1500 small sectors that spins ve-ry ve-ry slow-ly.. On Wed, Jul 29, 2020 at 5:58 AM Johnny Billquist wrote: > Just a small comment. Whoever it was that thought DECtape was a tape was > making a serious mistake. DECtapes are very different from magtapes. > > Johnny > > On 2020-07-29 02:21, Clement T Cole wrote: > > > > Cross posting to simh - since much of this has been discussed in the > > last few days there also.... > > > > in for penny, in for pound ... here is the history ... man ... I lived > > this and I'll need a strong drink later tonight after I write it all up. > > > > > > On Tue, Jul 28, 2020 at 7:04 PM Will Senn > > wrote: > > > > I recall having to do something with cont.a files, which are not > > present on these images. So, my questions is, does anyone know of or > > have an actual 2bsd tape/tape image? > > > > cont.a is a tp-v6 and earlier ism. > > > > DECtape had a directory at the front of the tape (think > > superblock/ilist), but could do cool things and be treated more like a > disk. > > When tp was created for a very early version of Unix (I'm not sure > > which, could be V2), Ken/Dennis et al had DECtape units and so the > > original scheme followed the media. This also meant that the program > > could write files and go back and update the directory, which is a no-no > > with many tape systems. Then research got a 9-track unit. So tp was > > changed to calculate how much space was going to be needed, write the > > directory, then the datablocks. All good ... except... > > > > 9-track could write more files than the directory could take. So for > > many years, people would use the ar(1) program to take a number of files > > in a directory, create a file called cont.a and then delete the files. > > Then the tree would be written with tp, when you read it, you reversed > > the ar(1) process. If you look at the USENIX/Harvard tape on the TUHS > > you'll see this scheme in use. > > > > BTW: tp was written in assembler and all the data structures were using > > PDP-11 binary formats. Eventually, Harvard wrote stp (super-tp) in C > > (which is on the USENIX tape Warren has in the archives) that worked > > like the original assembler tp but also put a redundant directory at the > > end of the tape. Another issue with tp was if the you had a bad block > > in the first few blocks you could not decode the rest of the tape. > > [There were some other issues with the UNIX tree structure as disks got > > bigger but I'm going to ignore all that - other than to say, tp had > > lived it life]. > > > > Enter Mashey and the PWB 1.0 folks (which is based on V6). Someone in > > USG created cpio (and volcpy) as part of the PWB 1.0. Like tp it was a > > PDP-11 binary format, but unlike tp, the tape directory is threaded. > > /i.e./ block one describes the first file only and includes the size of > > the following file, then file itself, then a new directory block for the > > next file and again that file (rinse and repeat). So it improved on tp > > in the directory threading, but was still binary and for a reasons I'll > > leave out had a different user interface. > > > > As part of V7, Ken wrote a new program, tar [you can ask him why]. But > > like cpio he used a threaded tape directory, but unlike cpio it was > > always ASCII and not PDP-11 specific. Furthermore, the user interface > > was made to parrot tp. So, certainly, it had the advantage that > > changing tp scripts to use tar was pretty easy i.e. s/tp/tar/ not so > > for coil. And it was muscle memory compliant. > > > > For PWB 2.0, cpio was updated to allow a -c option to write the header > > in ascii and -s to byte swap the binary. But the damage had been done > ... > > > > Thus began 'tar wars' which was a battle that raged officially over tape > > archive formats, but really was an argument about user interfaces. > > Since tar was part of Research and the Universities and commercial > > people used it, only USG and the folks inside the Bell System were using > > cpio, as officially none of us had it since PWB was not released to us > > (although thanks to many AT&T employees doing an OYOC year, many schools > > like UCB, MIT and CMU all had the sources to cpio anyway -- for instance > > you'll see it hidden away on Kirk's CD). > > > > I personally had used both, preferred tar for easy of use and ASCII > > directories. But, note I had written car at Masscomp, but never tpio. > > This was our trick to use the file scripting list that cpio could do, > > but create tar format tapes - which was handy. I never wrote tpio which > > would have been cpio format using tp/tar user interface as I did not > > need it. > > > > Roll forward to the /usr/group UNIX standard that Heinz chaired. We > > ended up not being able to agree on a distribution format, but the ISVs > > were PO because now they could create UNIX programs that might actually > > work across systems, but they had not standard way to distribution. > > Roll forward again to IEEE. Heinz's committee was officially disbanded > > (story discussed elsewhere) and we were created as IEEE P1003 with Jim > > Issack as Chair. This time the ISV's said we had to have a distribution > > format. Since *.1 was only an API we were allowed to avoid the user > > interface issue but only examine the on tape format. > > > > It turns out while it seems to have been unintended, Ken's original V7 > > implementation has an interesting coding feature/bug which turns out to > > be what clinched the deal. When Ken creates the directory block for > > each file, he did bcopy of 0's to the buffer before he wrote that data > > that fills it in. Then when he calculated the checksum for the > > directory header block, he summed the entire block (which because of the > > bcopy was zeros). This means if you write beyond the end of Ken's > > original header and include that extra data in the chksum, the original > > program will ignore the new information but accept the directory block > > as valid. i.e. he had built an extension mechanism into the tar on-tape > > format. > > > > cpio's ASCII on tape format was not able to do that as the checksum used > > a sizeof(header struct) in the checksum routine. > > > > USTAR was born ... Ken had written things like the UID/GID as ASCII > > representations of the integer value in the original header. USTAR > > added the ASCII representation of the username and the group name since > > that was more often portable between systems than the numbers. There > > were other additions like more room for the pathname new file types > > /etc/. But the key is that a USTAR tape can be read by the original V7 > > (and follow on) tape formats, although may not recognize all the > > filetype or use all of the new information. > > > > A few years later during *.2 discussions, we finally got into the user > > interface stuff and pax(1) was born. Knowing my hack with car, Keith > > Bostic, Jim McGuiness and I wrote up a description of a program that > > could with both users interfaces scheme. USENIX provided funding for a > > student to implement it and put the sources out on comp.unix.sources at > > some point. That proposal was originally accepted at the first tape > > user interface program in *.2 [a few years later after I stopped being > > part of the committee, the USG folks did get an alternate CPIO format > > accepted and cpio as an allowed program. USENIX paid to have the > > program updated to operate like cpio if it was called that, pure V7 tar > > if called that and if pax, user USTAR]. > > > > 'nuf said ... I hope. > > > > Clem > > > > _._,_._,_ > > ------------------------------------------------------------------------ > > Groups.io Links: > > > > You receive all messages sent to this group. > > > > View/Reply Online (#62) | Reply > To > > Group > > > > > | Reply To Sender > > > > > | Mute This Topic | New Topic > > > > > > Your Subscription | Contact > > Group Owner | Unsubscribe > > [bqt at softjar.se > ] > > > > _._,_._,_ > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: bqt at softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Thu Jul 30 00:29:31 2020 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 29 Jul 2020 16:29:31 +0200 Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: <5A12E0BB-4FFF-4C3E-B486-D4E852FAA97F@comcast.net> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> <5A12E0BB-4FFF-4C3E-B486-D4E852FAA97F@comcast.net> Message-ID: <2d723104-6461-08ba-9235-99b06622f9fa@softjar.se> On 2020-07-29 15:17, Paul Koning wrote: > > >> On Jul 29, 2020, at 5:50 AM, Johnny Billquist wrote: >> >> Just a small comment. Whoever it was that thought DECtape was a tape was making a serious mistake. DECtapes are very different from magtapes. >> >> Johnny > > Depends on what you're focusing on. Most tapes are not random-write. DECtape and EL-X1 tape are exceptional in that respect. But tapes, DECtape include, have access time proportional to delta block number (and that time is large) unlike disks. > > From the point of view of I/O semantics, the first point is significant and the second one not so much. True. But seek times are in the end only relevant as an aspect of the speed of the thing, nothing else. However, seek times on DECtape aren't really comparable to magtape either. Because DECtape deals with absolute block numbers. So you can always, no matter where you are, find out where you are, and how far you will need to move to get to the correct block. With magtapes, this is pretty much impossible. You'll have to rewind, and then start seeking. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at softjar.se Thu Jul 30 00:30:11 2020 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 29 Jul 2020 16:30:11 +0200 Subject: [TUHS] [simh] 2bsd tarball In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <2cb3ad2a-f8c5-a003-661c-e257f7cbe38c@softjar.se> Message-ID: Yes. That is a much better way to look at it. Johnny On 2020-07-29 15:52, John Cowan wrote: > When I talk about DECtape in my capacity as the local old fart, i > describe it as "a disk with one track and about 1500 small sectors that > spins ve-ry ve-ry slow-ly.. > > On Wed, Jul 29, 2020 at 5:58 AM Johnny Billquist > wrote: > > Just a small comment. Whoever it was that thought DECtape was a tape > was > making a serious mistake. DECtapes are very different from magtapes. > >    Johnny > > On 2020-07-29 02:21, Clement T Cole wrote: > > > > Cross posting to simh - since much of this has been discussed in the > > last few days there also.... > > > > in for penny, in for pound ... here is the history ...  man ... I > lived > > this and I'll need a strong drink later tonight after I write it > all up. > > > > > > On Tue, Jul 28, 2020 at 7:04 PM Will Senn > > >> wrote: > > > >     I recall having to do something with cont.a files, which are not > >     present on these images. So, my questions is, does anyone > know of or > >     have an actual 2bsd tape/tape image? > > > > cont.a is a tp-v6 and earlier ism. > > > > DECtape had a directory at the front of the tape (think > > superblock/ilist), but could do cool things and be treated more > like a disk. > > When tp was created for a very early version of Unix (I'm not sure > > which, could be V2), Ken/Dennis et al had DECtape units and so the > > original scheme followed the media.   This also meant that the > program > > could write files and go back and update the directory, which is > a no-no > > with many tape systems.  Then research got a 9-track unit.   So > tp was > > changed to calculate how much space was going to be needed, write > the > > directory, then the datablocks.  All good ... except... > > > > 9-track could write more files than the directory could take. >  So for > > many years, people would use the ar(1) program to take a number > of files > > in a directory, create a file called cont.a and then delete the > files. > > Then the tree would be written with tp, when you read it, you > reversed > > the ar(1) process.  If you look at the USENIX/Harvard tape on the > TUHS > > you'll see this scheme in use. > > > > BTW: tp was written in assembler and all the data structures were > using > > PDP-11 binary formats.  Eventually, Harvard wrote stp (super-tp) > in C > > (which is on the USENIX tape Warren has in the archives) that worked > > like the original assembler tp but also put a redundant directory > at the > > end of the tape.  Another issue with tp was if the you had a bad > block > > in the first few blocks you could not decode the rest of the tape. > > [There were some other issues with the UNIX tree structure as > disks got > > bigger but I'm going to ignore all that - other than to say, tp had > > lived it life]. > > > > Enter Mashey and the PWB 1.0 folks (which is based on V6). > Someone in > > USG created cpio (and volcpy) as part of the PWB 1.0.   Like tp > it was a > > PDP-11 binary format, but unlike tp, the tape directory is threaded. > > /i.e./ block one describes the first file only and includes the > size of > > the following file, then file itself, then a new directory block > for the > > next file and again that file (rinse and repeat).  So it improved > on tp > > in the directory threading, but was still binary and for a > reasons I'll > > leave out had a different user interface. > > > > As part of V7, Ken wrote a new program, tar [you can ask him > why].  But > > like cpio he used a threaded tape directory, but unlike cpio it was > > always ASCII and not PDP-11 specific.  Furthermore, the user > interface > > was made to parrot tp.  So, certainly, it had the advantage that > > changing tp scripts to use tar was pretty easy i.e. s/tp/tar/ >  not so > > for coil.  And it was muscle memory compliant. > > > > For PWB 2.0, cpio was updated to allow a -c option to write the > header > > in ascii and -s to byte swap the binary.   But the damage had > been done ... > > > > Thus began 'tar wars' which was a battle that raged officially > over tape > > archive formats, but really was an argument about user interfaces. > > Since tar was part of Research and the Universities and commercial > > people used it, only USG and the folks inside the Bell System > were using > > cpio, as officially none of us had it since PWB was not released > to us > > (although thanks to many AT&T employees doing an OYOC year, many > schools > > like UCB, MIT and CMU all had the sources to cpio anyway -- for > instance > > you'll see it hidden away on Kirk's CD). > > > > I personally had used both, preferred tar for easy of use and ASCII > > directories.  But, note I had written car at Masscomp, but never > tpio. > > This was our trick to use the file scripting list that cpio could > do, > > but create tar format tapes - which was handy.  I never wrote > tpio which > > would have been cpio format using tp/tar user interface as I did not > > need it. > > > > Roll forward to the /usr/group UNIX standard that Heinz chaired.  We > > ended up not being able to agree on a distribution format, but > the ISVs > > were PO because now they could create UNIX programs that might > actually > > work across systems, but they had not standard way to distribution. > > Roll forward again to IEEE.  Heinz's committee was officially > disbanded > > (story discussed elsewhere) and we were created as IEEE P1003 > with Jim > > Issack as Chair. This time the ISV's said we had to have a > distribution > > format.  Since *.1 was only an API we were allowed to avoid the user > > interface issue but only examine the on tape format. > > > > It turns out while it seems to have been unintended, Ken's > original V7 > > implementation has an interesting coding feature/bug which turns > out to > > be what clinched the deal.   When Ken creates the directory block > for > > each file, he did bcopy of 0's to the buffer before he wrote that > data > > that fills it in.  Then when he calculated the checksum for the > > directory header block, he summed the entire block (which because > of the > > bcopy was zeros).  This means if you write beyond the end of Ken's > > original header and include that extra data in the chksum, the > original > > program will ignore the new information but accept the directory > block > > as valid.  i.e. he had built an extension mechanism into the tar > on-tape > > format. > > > > cpio's ASCII on tape format was not able to do that as the > checksum used > > a sizeof(header struct) in the checksum routine. > > > > USTAR was born ... Ken had written things like the UID/GID as ASCII > > representations of the integer value in the original header.  USTAR > > added the ASCII representation of the username and the group name > since > > that was more often portable between systems than the numbers. >  There > > were other additions like more room for the pathname new file types > > /etc/.  But the key is that a USTAR tape can be read by the > original V7 > > (and follow on) tape formats, although may not recognize all the > > filetype or use all of the new information. > > > > A few years later during *.2 discussions, we finally got into the > user > > interface stuff and pax(1) was born.  Knowing my hack with car, > Keith > > Bostic, Jim McGuiness and I wrote up a description of a program that > > could with both users interfaces scheme.  USENIX provided funding > for a > > student to implement it and put the sources out on > comp.unix.sources at > > some point.  That proposal was originally accepted at the first tape > > user interface program in *.2 [a few years later after I stopped > being > > part of the committee, the USG folks did get an alternate CPIO > format > > accepted and cpio as an allowed program.   USENIX paid to have the > > program updated to operate like cpio if it was called that, pure > V7 tar > > if called that and if pax, user USTAR]. > > > > 'nuf said ... I hope. > > > > Clem > > > > _._,_._,_ > > > ------------------------------------------------------------------------ > > Groups.io Links: > > > > You receive all messages sent to this group. > > > > View/Reply Online (#62) | > Reply To > > Group > > ?subject=Re:%20Re%3A%20%5Bsimh%5D%20%5BTUHS%5D%202bsd%20tarball> > > > | Reply To Sender > > ?subject=Private:%20Re:%20Re%3A%20%5Bsimh%5D%20%5BTUHS%5D%202bsd%20tarball> > > > | Mute This Topic | New > Topic > > > > > > Your Subscription | > Contact > > Group Owner > | Unsubscribe > > > [bqt at softjar.se ] > > > > _._,_._,_ > > -- > Johnny Billquist                  || "I'm on a bus >                                    ||  on a psychedelic trip > email: bqt at softjar.se              || > Reading murder books > pdp is alive!                     ||  tryin' to stay hip" - B. Idol > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From clemc at ccc.com Thu Jul 30 01:40:41 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Jul 2020 11:40:41 -0400 Subject: [TUHS] 2bsd tarball -> pdtar, with a side of uuslave In-Reply-To: <26260.1596030165@hop.toad.com> References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <26260.1596030165@hop.toad.com> Message-ID: On Wed, Jul 29, 2020 at 9:42 AM John Gilmore wrote: > There was another chapter to the "tar wars" after UNIX and after POSIX. > Ah .. indeed - I left out the Gnu Tar story as I was not 100% sure of how it came about as I had not taken part in it. And pretty much for the purposes of how we go to where we are today, other than it exists, works, is a popular implementation and can read/write things when called upon ... I did not think it would add to the (already) long story. The null vs space filling is an interesting point which I had left out. Thank you for that detail - I do remember it. If I missspoke/was confusing (I hope not) about the UIDs I thought I had said the way you did. The key was that USTAR added the names in ASCII which was not there before in Ken's original version. Again, thanks for the friendly addition/update. After I left Sun in about 1985, I worked on a project with GNU and the > BSD folks, to find or write freely available implementations of many > popular UNIX commands. Yep, I do remember all that... > Since we didn't find a free "tar" program, I wrote one from scratch, > based on the SunOS man page and on running the > tar binary from SunOS 3.3. > I always found that strange the folks that wrote that that tar implementation (i.e. you and your mates) had not found the pax code, as the USENIX version had been previously posted/was in the wild by then. Keith certainly knew about it (he could have even been part of the finding a student to write it, but I don't remember), but he also might have been off at BSDi by that time. I think by then that the USENIX FOSS implementation even knew how to behave like cpio, tar, or pax depending on its name. I'm fairly sure, that Apple and HP had picked it up soon after it's release. DEC had a different set of tar switches, so pax was put in the Ultrix contributed library, and they left theirs alone. That said, the USENIX version did have an MIT/UCB/CMU style license, not the gpl, which our common 'friend' in Cambridge often (??always??) found suspicious. So, I had always >>suspected<< the licensing style was driver for yet another version, and have always been a little curious. But to me it was like C compilers, as long as they all worked, I didn't care. As you know, I have never been super religious about the different license flavors as long as I could use it. Probably a good beer discussion/story behind it all when I see you next at a future conference post CV-19. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Jul 30 05:34:11 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 29 Jul 2020 15:34:11 -0400 Subject: [TUHS] 2bsd tarball -> pdtar, with a side of uuslave In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <26260.1596030165@hop.toad.com> Message-ID: Wasn't the tour header Fields the reason for the strange strncpy semantics? Which came first? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jul 30 05:42:53 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 29 Jul 2020 13:42:53 -0600 Subject: [TUHS] 2bsd tarball -> pdtar, with a side of uuslave In-Reply-To: References: <6a0063f8-128d-751d-114f-a0f811d02098@gmail.com> <26260.1596030165@hop.toad.com> Message-ID: On Wed, Jul 29, 2020 at 1:35 PM Richard Salz wrote: > Wasn't the tour header Fields the reason for the strange strncpy > semantics? Which came first? > strncpy appeared in V7 as far as I can tell. I can't find it in v6 or earlier. I can't find any of the str functions in fact... Also, there's a new libarchive-based tar as well that the BSDs are using since it understands many other formats. It's largely replaced the gnutar that had previously been in BSD. Warneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jul 30 09:23:41 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Jul 2020 09:23:41 +1000 (EST) Subject: [TUHS] CR delay for VT05 In-Reply-To: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> References: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Message-ID: On Mon, 20 Jul 2020, Richard Tobin wrote: > Why would the VT05 (a VDU) need a delay for carriage return? I can just > about imagine that it might need one for linefeed if it shifted the > characters in memory. Given that the VT05 (shudder!) is broken in so many others ways e.g. 20x72 screen, sends upper-case only unless you flip an internal switch, etc, I'm not surprised that it would also need a CR delay... Primitive firmware? -- Dave From clemc at ccc.com Thu Jul 30 10:56:55 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Jul 2020 20:56:55 -0400 Subject: [TUHS] CR delay for VT05 In-Reply-To: References: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Message-ID: You wish. VT05 was designed in 71 - straight TTL, no microprocessor. Same for the VT-52. First micro was an 8085A in the VT1XX Prints are: http://www.pdp8.net/query_docs/query_all.html On Wed, Jul 29, 2020 at 7:25 PM Dave Horsfall wrote: > On Mon, 20 Jul 2020, Richard Tobin wrote: > > > Why would the VT05 (a VDU) need a delay for carriage return? I can just > > about imagine that it might need one for linefeed if it shifted the > > characters in memory. > > Given that the VT05 (shudder!) is broken in so many others ways e.g. 20x72 > screen, sends upper-case only unless you flip an internal switch, etc, I'm > not surprised that it would also need a CR delay... > > Primitive firmware? > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Jul 30 23:16:20 2020 From: will.senn at gmail.com (Will Senn) Date: Thu, 30 Jul 2020 08:16:20 -0500 Subject: [TUHS] Will pdp 11/04 run unix? Message-ID: The question is can I run Unix on a PDP 11/04? I've dug around and it's unclear to me, so I'm asking y'all. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Jul 30 23:47:59 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Jul 2020 09:47:59 -0400 (EDT) Subject: [TUHS] Will pdp 11/04 run unix? Message-ID: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> > From: Will Senn > can I run Unix on a PDP 11/04? No, it doesn't have memory management, so not any of the well-known 'stock' versions (V5/V6/etc). Two choices, though: - If you get the V1 that ran on an -11/20 (which is mostly compatible with the /04 and /05), it should run on an /04. (Not sure what you'd use for mass storage, on a physical /04, though.) I'm not sure when they dropped the /20 - I think V4 n(at the latest)? But V2 and V3 are lost. - There's a 'Unix' for the LSI-11, and with minor changes (the LSI-11 isn't 100% compatible with other MMU-less 11's, but the changes are minor, e.g. MOS, written in MACRO-11, was conditionalized to run on both the LSI-11 and the -11/20) it should run on an /04. Noel From clemc at ccc.com Thu Jul 30 23:53:31 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Jul 2020 09:53:31 -0400 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: References: Message-ID: PDP 11/04, like 11/03,11/05, 11/15, 11/20 lacks an MMU. So the traditional releases from Research, USG, UCB will not boot. That said, V1 which ran without it might work with some tweeking as they did not yet have one. And if you could find a KS-11 MMU that Ken and Dennis had for the 11/20 (which was designed by DEC CSS), theoretically next versions could be made to run. The problem is that while many of us have looked a: we can not find a KS-11 in real life (CSS did make that many), b: we can't even find documentation about it (Ken's surviving code is the best doc we have). FYI: go to bitsavers and download a copy of the PDP-11 Processor Handbook, but note the data. You probably will want (at least) both an early and a later one, as the later ones often dropped details about some of the models that were not being manufactured. For instance, I have a couple of different ones, and the '78 version really one talks about 04/34/45/55/60 - the previous processors like 03/15/40 are not included. So you need an early 70's version to include them, and later versions for the 44/90 etc. BTW: Page 4 of same, have a graphic showing the HW requirements for the DEC OS's. On the X-axis is the OS, the Y axis the model. RT-11, MUMPS-11, RSX-11M, RS-11S are the only OS's that were supported for the 04. Here is a hint, if the processor could not support RSTS, it is unlikely it could support UNIX. On Thu, Jul 30, 2020 at 9:17 AM Will Senn wrote: > The question is can I run Unix on a PDP 11/04? I've dug around and it's > unclear to me, so I'm asking y'all. > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jul 31 00:01:24 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Jul 2020 10:01:24 -0400 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: References: Message-ID: s/note the data/note the date/ <-- dyslexic typing -- sigh. On Thu, Jul 30, 2020 at 9:53 AM Clem Cole wrote: > PDP 11/04, like 11/03,11/05, 11/15, 11/20 lacks an MMU. So the > traditional releases from Research, USG, UCB will not boot. > That said, V1 which ran without it might work with some tweeking as they > did not yet have one. And if you could find a KS-11 MMU that Ken and > Dennis had for the 11/20 (which was designed by DEC CSS), theoretically > next versions could be made to run. The problem is that while many of us > have looked a: we can not find a KS-11 in real life (CSS did make that > many), b: we can't even find documentation about it (Ken's surviving code > is the best doc we have). > > FYI: go to bitsavers and download a copy of the PDP-11 Processor > Handbook, but note the data. You probably will want (at least) both > an early and a later one, as the later ones often dropped details about > some of the models that were not being manufactured. For instance, I have > a couple of different ones, and the '78 version really one talks about > 04/34/45/55/60 - the previous processors like 03/15/40 are not included. > So you need an early 70's version to include them, and later versions for > the 44/90 etc. > > BTW: Page 4 of same, have a graphic showing the HW requirements for the > DEC OS's. On the X-axis is the OS, the Y axis the model. RT-11, MUMPS-11, > RSX-11M, RS-11S are the only OS's that were supported for the 04. > > Here is a hint, if the processor could not support RSTS, it is unlikely it > could support UNIX. > > > > On Thu, Jul 30, 2020 at 9:17 AM Will Senn wrote: > >> The question is can I run Unix on a PDP 11/04? I've dug around and it's >> unclear to me, so I'm asking y'all. >> >> Will >> >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Jul 31 00:08:26 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 30 Jul 2020 10:08:26 -0400 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> References: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> Message-ID: > > - There's a 'Unix' for the LSI-11, and with minor changes (the LSI-11 isn't > 100% compatible with other MMU-less 11's, but the changes are minor, e.g. > MOS, written in MACRO-11, was conditionalized to run on both the LSI-11 > and the -11/20) it should run on an /04. > > Noel There’s always MiniUnix. https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/ We ran that on our MMU-less PDP-11/20s and 11/40 before the LSI-11 was even introduced. It lacks obviously memory protection, traditional UNIX pipes (they’re simulated by the shell if I recall), and preemptive scheduling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jul 31 02:13:18 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Jul 2020 10:13:18 -0600 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> References: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> Message-ID: On Thu, Jul 30, 2020 at 7:49 AM Noel Chiappa wrote: > - If you get the V1 that ran on an -11/20 (which is mostly compatible with > the /04 and /05), it should run on an /04. (Not sure what you'd use for > mass > storage, on a physical /04, though.) I'm not sure when they dropped the > /20 - > I think V4 n(at the latest)? But V2 and V3 are lost. > Yes, the reconstructed 1st edition may run (though from dates and such, it's somewhere between 1st and 2nd edition), though I've no direct experience with 11/04 hardware, nor ideas on how to bootstrap it onto appropriate physical media... I have it in my head that the 4th edition was rewritten for the 11/45 and removed support for 11/20. I thought I knew why, but could only find part of the story in the manuals... There's a strong note in the 4th edition preface that it applies only to the 'c' version of Unix and the 3rd edition preface has a note saying the manual doesn't apply to the 11/20 version and to look in the 2nd or even 1st edition manuals for that. As others have mentioned, Mini-unix and/or LSX might have a shot, but it might be best characterized as a long shot. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Jul 31 02:42:39 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 30 Jul 2020 12:42:39 -0400 Subject: [TUHS] CR delay for VT05 In-Reply-To: References: <20200719233207.BB69D2D9E6DD@macaroni.inf.ed.ac.uk> Message-ID: On 7/29/20, Dave Horsfall wrote: > > Given that the VT05 (shudder!) is broken in so many others ways e.g. 20x72 > screen, sends upper-case only unless you flip an internal switch, etc, I'm > not surprised that it would also need a CR delay... The VT05 was designed to be a glass teletype. Literally. Hence the screen width (same as a model 33 tty) and default upper-case only transmission. The CR delay might be there to mimic the CR delay of a model 33, too. -Paul W. From jnc at mercury.lcs.mit.edu Fri Jul 31 03:20:30 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Jul 2020 13:20:30 -0400 (EDT) Subject: [TUHS] Will pdp 11/04 run unix? Message-ID: <20200730172030.1918D18C0E5@mercury.lcs.mit.edu> > From: Clem Cole > And if you could find a KS-11 MMU that Ken and Dennis had for the 11/20 > ... we can't even find documentation about it (Ken's surviving code is > the best doc we have). Where is that code? The Version 1 at TUHS appears to pre-date it. It would be great to have a look at it, we might be able to partially document the KS11 using it. (Ken had only vague memories of the KS11.) > From: Ronald Natalie > There's always MiniUnix. Ah; I didn't realize that was something different from LSX (the LSI-11 system). Noel From heinz at osta.com Fri Jul 31 04:00:19 2020 From: heinz at osta.com (Heinz Lycklama) Date: Thu, 30 Jul 2020 11:00:19 -0700 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: References: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> Message-ID: As the author of both LSX and Mini-UNIX, I would suggest that the LSX source code is a better starting point for the 11/04, especially if single-user is the target. Mini-UNIX was written to support a small number of users on the PDP 11/10 without an MMU. However, I'm not current on what sources are still available. Heinz On 7/30/2020 9:13 AM, Warner Losh wrote: > On Thu, Jul 30, 2020 at 7:49 AM Noel Chiappa > wrote: > > - If you get the V1 that ran on an -11/20 (which is mostly > compatible with > the /04 and /05), it should run on an /04. (Not sure what you'd > use for mass > storage, on a physical /04, though.) I'm not sure when they > dropped the /20 - > I think V4 n(at the latest)? But V2 and V3 are lost. > > > Yes, the reconstructed 1st edition may run (though from dates and > such, it's somewhere between 1st and 2nd edition), though I've no > direct experience with 11/04 hardware, nor ideas on how to bootstrap > it onto appropriate physical media... > > I have it in my head that the 4th edition was rewritten for the 11/45 > and removed support for 11/20. I thought I knew why, but could only > find part of the story in the manuals... > > There's a strong note in the 4th edition preface that it applies only > to the 'c' version of Unix and the 3rd edition preface has a > note saying the manual doesn't apply to the 11/20 version and to look > in the 2nd or even 1st edition manuals for that. > > As others have mentioned, Mini-unix and/or LSX might have a shot, but > it might be best characterized as a long shot. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Fri Jul 31 04:55:53 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Thu, 30 Jul 2020 20:55:53 +0200 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> References: <20200730134759.3833518C0F6@mercury.lcs.mit.edu> Message-ID: <20200730185553.GA81572@indra.papnet.eu> On 30/07/20, Noel Chiappa wrote: > - If you get the V1 that ran on an -11/20 (which is mostly compatible with > the /04 and /05), it should run on an /04. (Not sure what you'd use for mass > storage, on a physical /04, though.) I'm not sure when they dropped the /20 - > I think V4 n(at the latest)? But V2 and V3 are lost. It looks like v3 was when they forked off 11/45 UNIX. ("The second, or even the first, edition of this manual is likely to be more appropriate.") I believe 11/20 UNIX also needs the EAE. aap From jnc at mercury.lcs.mit.edu Fri Jul 31 07:37:20 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Jul 2020 17:37:20 -0400 (EDT) Subject: [TUHS] Will pdp 11/04 run unix? Message-ID: <20200730213720.109C018C0A5@mercury.lcs.mit.edu> > From: Angelo Papenhoff > I believe 11/20 UNIX also needs the EAE. Some applications might have used it (the story about the KS11 bug with the KW11-A confirms they did use it on that machine), but I found no trace of use of it in a quick scan of the entire Version 1 source (the one which is extant). Also, the first file in the OS source: https://www.tuhs.org/cgi-bin/utree.pl?file=V1/u0.s lists the addresses of all device registers, and the KE11-A isn't there. If the KE11 is needed to run some application on the -11/04, there are KE11-B's (program compatible, but a single hex card) available, ISTR. For emulation, something (SIMH?) supports it, since the TV -11 on ITS (now running in emulation,I'm pretty sure) uses it. Noel From mckusick at mckusick.com Fri Jul 31 10:03:24 2020 From: mckusick at mckusick.com (Kirk McKusick) Date: Thu, 30 Jul 2020 17:03:24 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation Message-ID: <202007310003.06V03OoV073870@chez.mckusick.com> The Computer History Museum has an interesting blog post about Dennis Ritchie's lost dissertation: https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertation/ Interesting fact is that Dennis never received his PhD because he failed to provide a bound copy of his dissertation to the Harvard library. Kirk McKusick From royce at techsolvency.com Fri Jul 31 10:26:59 2020 From: royce at techsolvency.com (Royce Williams) Date: Thu, 30 Jul 2020 16:26:59 -0800 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <202007310003.06V03OoV073870@chez.mckusick.com> References: <202007310003.06V03OoV073870@chez.mckusick.com> Message-ID: On Thu, Jul 30, 2020 at 4:23 PM Kirk McKusick wrote: > The Computer History Museum has an interesting blog post about > Dennis Ritchie's lost dissertation: > > > https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertation/ > > Interesting fact is that Dennis never received his PhD because he failed > to provide a bound copy of his dissertation to the Harvard library. It would seem fitting to try to get this posthumously corrected. If we provided said bound copy, does anyone have any Harvard contacts that could facilitate? Royce -- Royce Williams Tech Solvency -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jul 31 10:30:15 2020 From: crossd at gmail.com (Dan Cross) Date: Thu, 30 Jul 2020 20:30:15 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <202007310003.06V03OoV073870@chez.mckusick.com> References: <202007310003.06V03OoV073870@chez.mckusick.com> Message-ID: I understood from Mike Anshel that he was rather proud of this, though of course I never asked Dennis myself. I wonder if Harvard would posthumously enter it in the books if someone dropped off a bound copy now? I imagine somehow Dennis wouldn't appreciate that. On Thu, Jul 30, 2020 at 8:23 PM Kirk McKusick wrote: > The Computer History Museum has an interesting blog post about > Dennis Ritchie's lost dissertation: > > > https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertation/ > > Interesting fact is that Dennis never received his PhD because he failed > to provide a bound copy of his dissertation to the Harvard library. > > Kirk McKusick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 31 10:35:28 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jul 2020 17:35:28 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <202007310003.06V03OoV073870@chez.mckusick.com> References: <202007310003.06V03OoV073870@chez.mckusick.com> Message-ID: <20200731003528.GR10778@mcvoy.com> "My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones." Amen to that. Me too, I tried functional languages and my head hurt. C seems so natural to me. On Thu, Jul 30, 2020 at 05:03:24PM -0700, Kirk McKusick wrote: > The Computer History Museum has an interesting blog post about > Dennis Ritchie's lost dissertation: > > https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertation/ > > Interesting fact is that Dennis never received his PhD because he failed > to provide a bound copy of his dissertation to the Harvard library. > > Kirk McKusick -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From rdm at cfcl.com Fri Jul 31 10:36:58 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 30 Jul 2020 17:36:58 -0700 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: References: <202007310003.06V03OoV073870@chez.mckusick.com> Message-ID: <105377CB-E19B-4E74-9EAF-E615FD6C3DBF@cfcl.com> It seems odd to me that nobody seems to have given him an honorary PhD. Perhaps offers were made, but declined? -r From cowan at ccil.org Fri Jul 31 10:54:54 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 30 Jul 2020 20:54:54 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation In-Reply-To: <20200731003528.GR10778@mcvoy.com> References: <202007310003.06V03OoV073870@chez.mckusick.com> <20200731003528.GR10778@mcvoy.com> Message-ID: On Thu, Jul 30, 2020 at 8:36 PM Larry McVoy wrote: Amen to that. Me too, I tried functional languages and my head hurt. C > seems so natural to me. > IMO impure functional languages like Common Lisp, ML, Scheme, and the somewhat ironically named Pure language are straightforward extensions of imperative programming: you can make your code less imperative without being completely deprived of it. All of these are tail-recursive (formally CL is not, but most implementations are) which means that recursive loops become non-recursive gotos, and for/do-loops wind up being pure without you noticing. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Fri Jul 31 17:10:08 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 31 Jul 2020 09:10:08 +0200 Subject: [TUHS] Will pdp 11/04 run unix? In-Reply-To: <20200730213720.109C018C0A5@mercury.lcs.mit.edu> References: <20200730213720.109C018C0A5@mercury.lcs.mit.edu> Message-ID: <20200731071008.GA33933@indra.papnet.eu> On 30/07/20, Noel Chiappa wrote: > > From: Angelo Papenhoff > > > I believe 11/20 UNIX also needs the EAE. > > Some applications might have used it (the story about the KS11 bug with the > KW11-A confirms they did use it on that machine), but I found no trace of use > of it in a quick scan of the entire Version 1 source (the one which is > extant). > > Also, the first file in the OS source: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V1/u0.s > > lists the addresses of all device registers, and the KE11-A isn't there. Oh ok. The B runtime uses the EAE so i assumed it was used in other places as well. > If the KE11 is needed to run some application on the -11/04, there are > KE11-B's (program compatible, but a single hex card) available, ISTR. For > emulation, something (SIMH?) supports it, since the TV -11 on ITS (now running > in emulation,I'm pretty sure) uses it. Well the TV-11 is a tough question. I originally wrote an 11/05 emulator because some document said it was an 11/10 (which is the same thing). But other sources claimed it was an 11/20. you can build both versions and both work. My EAE emulation is based on the KE-11A document from bitsavers. (code here: https://github.com/aap/pdp11 ) aap From steve.mynott at gmail.com Fri Jul 31 19:05:55 2020 From: steve.mynott at gmail.com (Steve Mynott) Date: Fri, 31 Jul 2020 10:05:55 +0100 Subject: [TUHS] BSDI git repo? Message-ID: Is there full bsdi git repo anywhere? I've vague recollections parts were merged into FreeBSD in the early 2000s so I assume it was open sourced? There is a tarball of bsdi 2 on venus wetware but that's the best I can do with searching. -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From doug at cs.dartmouth.edu Fri Jul 31 22:56:48 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 31 Jul 2020 08:56:48 -0400 Subject: [TUHS] Dennis Ritchie's Dissertation Message-ID: <202007311256.06VCum8d086137@tahoe.cs.Dartmouth.EDU> > "My graduate school experience convinced me that I was not smart enough to > be an expert in the theory of algorithms and also that I liked procedural > languages better than functional ones." > > Amen to that. Me too, I tried functional languages and my head hurt. C > seems so natural to me. Dennis made quite a generalization from a sample of one--Lisp, the only functional language that existed when he was in grad school. I'm sure he'd agree today that functional languages shine for spplications rooted in algebraic domains. I immodestly point to www.cs.dartmouth.edu/~doug/powser.html, which has nothing to do with Unix, but certainly would have appealed to Dennis. Doug