From cmhanson at eschatologist.net Sun Nov 1 11:18:03 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 31 Oct 2020 18:18:03 -0700 Subject: [TUHS] Xinu in emulation, e.g. SIMH? Message-ID: <2D81AE28-7163-4B52-BED9-3C5EBCBE5608@eschatologist.net> Has anyone gotten Xinu running in SIMH? It seems like it should be straightforward to run the "support" utilities under BSD on an emulated VAX and then run Xinu itself on an emulated LSI-11. If anyone's done so, I'd be interested to learn what all you had to do to set it up and get it working. -- Chris -- who needs to figure out SIMH config file syntax to match the board set he wants to simulate From lm at mcvoy.com Sun Nov 1 11:58:58 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 31 Oct 2020 18:58:58 -0700 Subject: [TUHS] Xinu in emulation, e.g. SIMH? In-Reply-To: <2D81AE28-7163-4B52-BED9-3C5EBCBE5608@eschatologist.net> References: <2D81AE28-7163-4B52-BED9-3C5EBCBE5608@eschatologist.net> Message-ID: <20201101015858.GS25151@mcvoy.com> Is this Doug Comer's XINU? I haven't talked to him for a while but he was one of my heros like the Bell Labs guys. I loved his code, it was so simple like the Lions doc for v6. I can try and drag him to be here, that would be cool. On Sat, Oct 31, 2020 at 06:18:03PM -0700, Chris Hanson wrote: > Has anyone gotten Xinu running in SIMH? It seems like it should be straightforward to run the "support" utilities under BSD on an emulated VAX and then run Xinu itself on an emulated LSI-11. If anyone's done so, I'd be interested to learn what all you had to do to set it up and get it working. > > -- Chris > -- who needs to figure out SIMH config file syntax to match the board set he wants to simulate -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cmhanson at eschatologist.net Sun Nov 1 13:46:45 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 31 Oct 2020 20:46:45 -0700 Subject: [TUHS] Xinu in emulation, e.g. SIMH? In-Reply-To: <20201101015858.GS25151@mcvoy.com> References: <20201101015858.GS25151@mcvoy.com> Message-ID: <24339552-7ABA-4387-9F62-56E12BBB07A2@eschatologist.net> Yeah, Comer’s XINU book at Tannenbaum’s MINIX book are the books from which I learned C, so now that I have an LSI-11 I’d like to get the former running. (I ran MacMinix in the early 1990s, and even published a patch to flush the 68040 caches on context switch so you could leave them enabled…) — Chris Sent from my iPad > On Oct 31, 2020, at 6:58 PM, Larry McVoy wrote: > > Is this Doug Comer's XINU? I haven't talked to him for a while but he > was one of my heros like the Bell Labs guys. I loved his code, it > was so simple like the Lions doc for v6. > > I can try and drag him to be here, that would be cool. > >> On Sat, Oct 31, 2020 at 06:18:03PM -0700, Chris Hanson wrote: >> Has anyone gotten Xinu running in SIMH? It seems like it should be straightforward to run the "support" utilities under BSD on an emulated VAX and then run Xinu itself on an emulated LSI-11. If anyone's done so, I'd be interested to learn what all you had to do to set it up and get it working. >> >> -- Chris >> -- who needs to figure out SIMH config file syntax to match the board set he wants to simulate > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From wkt at tuhs.org Mon Nov 2 12:45:56 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 2 Nov 2020 12:45:56 +1000 Subject: [TUHS] Xinu in emulation, e.g. SIMH? In-Reply-To: <20201101015858.GS25151@mcvoy.com> References: <2D81AE28-7163-4B52-BED9-3C5EBCBE5608@eschatologist.net> <20201101015858.GS25151@mcvoy.com> Message-ID: <20201102024556.GA10850@minnie.tuhs.org> On Sat, Oct 31, 2020 at 06:58:58PM -0700, Larry McVoy wrote: > Is this Doug Comer's XINU? I haven't talked to him for a while but he > was one of my heros like the Bell Labs guys. I loved his code, it > was so simple like the Lions doc for v6. > I can try and drag him to be here, that would be cool. Yes please. I learned C from the Xinu book when I translated Xinu into 6502 assembly to get it to run on an Apple ][+. Cheers, Warren From grog at lemis.com Mon Nov 2 15:07:17 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 2 Nov 2020 16:07:17 +1100 Subject: [TUHS] Lions notes, early history Message-ID: <20201102050717.GG72955@eureka.lemis.com> Warner Losh and I have been discussing the early history of John Lions' "A commentary on the Sixth Edition UNIX Operating System". I've been hosting Warren Toomey's version (with some correction of scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for some years now, and my understanding had been that the book hadn't been published, just photocopied, until Warren posted it on alt.folklore.computers in 1994. But now it seems that the "book" had been published by UNSW when Lions held the course, and only later was the license revoked. Does anybody have any insights? What restrictions were there on its distribution? What was the format? Was it a real book, or just bound notes? 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 imp at bsdimp.com Mon Nov 2 15:21:23 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Nov 2020 22:21:23 -0700 Subject: [TUHS] Lions notes, early history In-Reply-To: <20201102050717.GG72955@eureka.lemis.com> References: <20201102050717.GG72955@eureka.lemis.com> Message-ID: On Sun, Nov 1, 2020 at 10:16 PM Greg 'groggy' Lehey wrote: > Warner Losh and I have been discussing the early history of John > Lions' "A commentary on the Sixth Edition UNIX Operating System". > I've been hosting Warren Toomey's version (with some correction of > scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for > some years now, and my understanding had been that the book hadn't > been published, just photocopied, until Warren posted it on > alt.folklore.computers in 1994. But now it seems that the "book" had > been published by UNSW when Lions held the course, and only later was > the license revoked. Does anybody have any insights? What > restrictions were there on its distribution? What was the format? > Was it a real book, or just bound notes? > The pictures I've seen online are of a bound book, but lack photos of what's inside. It contained a legend in the front saying you needed a 6th edition license from AT&T to receive a copy. Beyond that, I'd love to hear what others know about this detail. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Mon Nov 2 17:21:57 2020 From: andrew at humeweb.com (Andrew Hume) Date: Sun, 1 Nov 2020 23:21:57 -0800 Subject: [TUHS] Lions notes, early history In-Reply-To: <20201102050717.GG72955@eureka.lemis.com> References: <20201102050717.GG72955@eureka.lemis.com> Message-ID: i was a TA for the course which used this as a textbook. my memory is little faded on this (it was on the other side of my stroke), but i believe they were perfect bound (cloth strip and glue) and had two different colors for the covers (i want to say orange and red). they might have been just stapled but they were thick enough that staples might have been insufficient. i certainly remember john printing them off on the DEC printer. as for the permissions, i can’t recall anything at the time (this was about 45 years ago), but do remember the fuss at the Labs when Bell Labs started printing their own high security copies just a couple of years later. andrew hume > On Nov 1, 2020, at 9:07 PM, Greg 'groggy' Lehey wrote: > > Warner Losh and I have been discussing the early history of John > Lions' "A commentary on the Sixth Edition UNIX Operating System". > I've been hosting Warren Toomey's version (with some correction of > scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for > some years now, and my understanding had been that the book hadn't > been published, just photocopied, until Warren posted it on > alt.folklore.computers in 1994. But now it seems that the "book" had > been published by UNSW when Lions held the course, and only later was > the license revoked. Does anybody have any insights? What > restrictions were there on its distribution? What was the format? > Was it a real book, or just bound notes? > > 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 From davida at pobox.com Mon Nov 2 17:59:23 2020 From: davida at pobox.com (David Arnold) Date: Mon, 2 Nov 2020 18:59:23 +1100 Subject: [TUHS] Lions notes, early history In-Reply-To: References: Message-ID: <359CCDCB-2739-4FDA-8404-16C1B88410EE@pobox.com> The UNSW Library Appears to have a copy in their storage, accessible by special request. It has a copyright date of “c1977” so it’s not the later “properly” published edition. https://primoa.library.unsw.edu.au/primo-explore/fulldisplay?vid=UNSWS&docid=UNSW_ALMA21116225050001731&query=any,contains,John%20lions&_ga=2.60871272.51366765.1604303632-102727300.1604303632 d > On 2 Nov 2020, at 18:44, Andrew Hume wrote: > > i was a TA for the course which used this as a textbook. > my memory is little faded on this (it was on the other side of my stroke), > but i believe they were perfect bound (cloth strip and glue) and had > two different colors for the covers (i want to say orange and red). > they might have been just stapled but they were thick enough that staples > might have been insufficient. > > i certainly remember john printing them off on the DEC printer. > > as for the permissions, i can’t recall anything at the time (this was about 45 years ago), > but do remember the fuss at the Labs when Bell Labs started printing their own > high security copies just a couple of years later. > > andrew hume > >> On Nov 1, 2020, at 9:07 PM, Greg 'groggy' Lehey wrote: >> >> Warner Losh and I have been discussing the early history of John >> Lions' "A commentary on the Sixth Edition UNIX Operating System". >> I've been hosting Warren Toomey's version (with some correction of >> scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for >> some years now, and my understanding had been that the book hadn't >> been published, just photocopied, until Warren posted it on >> alt.folklore.computers in 1994. But now it seems that the "book" had >> been published by UNSW when Lions held the course, and only later was >> the license revoked. Does anybody have any insights? What >> restrictions were there on its distribution? What was the format? >> Was it a real book, or just bound notes? >> >> 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 -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Mon Nov 2 19:51:19 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 2 Nov 2020 19:51:19 +1000 Subject: [TUHS] Lions notes, early history In-Reply-To: References: <20201102050717.GG72955@eureka.lemis.com> Message-ID: <20201102095119.GA16921@minnie.tuhs.org> On Sun, Nov 01, 2020 at 10:21:23PM -0700, Warner Losh wrote: > The pictures I've seen online are of a bound book, but lack photos of > what's inside. It contained a legend in the front saying you needed a > 6th edition license from AT&T to receive a copy. Beyond that, I'd love > to hear what others know about this detail. I have my copies here, and have just taken some photos: https://minnie.tuhs.org/wktcloud/index.php/s/2io7tpmTyn8WWeP 29.7cm by 21.0cm by about 7mm thick, each. They seem to be photocopied sheets, stapled on the left, with coloured front and back pages, with a brown cloth binding glued over the left-hand edge. One is magenta, the other is dull orange. My photos make the orange one brighter than it actually is, sorry it's artifical light (night-time) here. Cheers, Warren From egbegb2 at gmail.com Mon Nov 2 20:26:29 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Mon, 2 Nov 2020 04:26:29 -0600 Subject: [TUHS] Lions notes, early history In-Reply-To: References: Message-ID: I had the orange and red books but I sold them to a fellow in Europe who has a Unix Museum. He also bought one of UNIX lice eggs plates. I took high resolution photos of each page before I sent them to Europe. I can send copies if that is legal and anyone is interested. Ed Bradford Pflugerville, TX Sent from my iPhone > On Nov 1, 2020, at 11:22 PM, Warner Losh wrote: > >  > > >> On Sun, Nov 1, 2020 at 10:16 PM Greg 'groggy' Lehey wrote: >> Warner Losh and I have been discussing the early history of John >> Lions' "A commentary on the Sixth Edition UNIX Operating System". >> I've been hosting Warren Toomey's version (with some correction of >> scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for >> some years now, and my understanding had been that the book hadn't >> been published, just photocopied, until Warren posted it on >> alt.folklore.computers in 1994. But now it seems that the "book" had >> been published by UNSW when Lions held the course, and only later was >> the license revoked. Does anybody have any insights? What >> restrictions were there on its distribution? What was the format? >> Was it a real book, or just bound notes? > > The pictures I've seen online are of a bound book, but lack photos of what's inside. It contained a legend in the front saying you needed a 6th edition license from AT&T to receive a copy. Beyond that, I'd love to hear what others know about this detail. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Nov 2 21:04:21 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Nov 2020 04:04:21 -0700 Subject: [TUHS] Lions notes, early history In-Reply-To: References: Message-ID: <202011021104.0A2B4LDw015231@freefriends.org> Ed Bradford wrote: > I had the orange and red books but I sold them to a fellow in Europe > who has a Unix Museum. He also bought one of UNIX lice eggs plates. > > I took high resolution photos of each page before I sent them to Europe. I > can send copies if that is legal and anyone is interested. > > Ed Bradford > Pflugerville, TX Given that the Lions book was republished for anyone to purchase a few years back (I bought a copy, as well as having a samisdat photocopy), I see no reason why they couldn't be freely distributed. Maybe even added to the archives, if Warren agrees. From clemc at ccc.com Tue Nov 3 00:26:51 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Nov 2020 09:26:51 -0500 Subject: [TUHS] Lions notes, early history In-Reply-To: References: <20201102050717.GG72955@eureka.lemis.com> Message-ID: Andrew - can't speak for the original, but the BTL version was red and orange and was perfect bound. But, I was not on 11x17 - it must have been printed on A3 paper, as copying was always a little funny (maybe it was on traditional 'green bar' size 14 7/8 x 11 - I don't remember - but my copy of the original was on US 11x17). Ordering it originally was difficult. I remember that we tried to order a copy for Tektronix in the summer/fall of 1979 because I had my n-th generation xerographic copy that I had brought from CMU and Tek wanted to legitimate copy. IIRC, I wrote the PO request and it bounced back from Tek purchasing because it had been denied by somebody at AT&T. We had to call the right person (Al Arms if memory serves me), and then I had the restart on the Tek side, but we did eventually get an official version - which as on my desk for a few years [Of course, we immediately made more copies -- I think I made them for Steve Glaser, Mike Zuhl, Ward Cunningham and possibly Jon if he did not yet have a copy from his BTL days]. When I left Tek I gave the original Tektronix copy of the two books to Terry Laskodi. I have wondered what happened to that copy after he tragically died in the early 1980s. I fear it was tossed by someone that had no idea what its value was. Clem On Mon, Nov 2, 2020 at 2:44 AM Andrew Hume wrote: > i was a TA for the course which used this as a textbook. > my memory is little faded on this (it was on the other side of my stroke), > but i believe they were perfect bound (cloth strip and glue) and had > two different colors for the covers (i want to say orange and red). > they might have been just stapled but they were thick enough that staples > might have been insufficient. > > i certainly remember john printing them off on the DEC printer. > > as for the permissions, i can’t recall anything at the time (this was > about 45 years ago), > but do remember the fuss at the Labs when Bell Labs started printing their > own > high security copies just a couple of years later. > > andrew hume > > > On Nov 1, 2020, at 9:07 PM, Greg 'groggy' Lehey wrote: > > > > Warner Losh and I have been discussing the early history of John > > Lions' "A commentary on the Sixth Edition UNIX Operating System". > > I've been hosting Warren Toomey's version (with some correction of > > scan errors) at http://www.lemis.com/grog/Documentation/Lions/ for > > some years now, and my understanding had been that the book hadn't > > been published, just photocopied, until Warren posted it on > > alt.folklore.computers in 1994. But now it seems that the "book" had > > been published by UNSW when Lions held the course, and only later was > > the license revoked. Does anybody have any insights? What > > restrictions were there on its distribution? What was the format? > > Was it a real book, or just bound notes? > > > > 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 -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Nov 3 02:25:53 2020 From: norman at oclsc.org (Norman Wilson) Date: Mon, 2 Nov 2020 11:25:53 -0500 (EST) Subject: [TUHS] Lions notes, early history Message-ID: <20201102162553.D5D884422E@lignose.oclsc.org> There also exists a latter-day AT&T version of the Lions book. White cover with deathstar logo; standard US letter- sized paper, perfect-bound along the short edge. Two volumes: one for the source code, one for the commentary. I have a copy, and I bet Andrew does too: as I remember, he got a handful of them from Judy Macor (who used to handle licensing requests--I remember speaking to her on the phone once in my pre-Labs days) when she was clearing old stuff out of her office, and I nabbed one. Norman Wilson Toronto ON From arnold at skeeve.com Tue Nov 3 03:16:18 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Nov 2020 10:16:18 -0700 Subject: [TUHS] Lions notes, early history In-Reply-To: <20201102162553.D5D884422E@lignose.oclsc.org> References: <20201102162553.D5D884422E@lignose.oclsc.org> Message-ID: <202011021716.0A2HGIeg005278@freefriends.org> The 1996 reprint is available: https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137/ref=sr_1_1?crid=4GU9QHV2HJM&dchild=1&keywords=john+lions+unix&qid=1604337238&sprefix=john+lions%2Caps%2C295&sr=8-1 From dave at horsfall.org Tue Nov 3 07:17:29 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 3 Nov 2020 08:17:29 +1100 (EST) Subject: [TUHS] Lions notes, early history In-Reply-To: <20201102050717.GG72955@eureka.lemis.com> References: <20201102050717.GG72955@eureka.lemis.com> Message-ID: On Mon, 2 Nov 2020, Greg 'groggy' Lehey wrote: > Warner Losh and I have been discussing the early history of John Lions' > "A commentary on the Sixth Edition UNIX Operating System". I've been > hosting Warren Toomey's version (with some correction of scan errors) at > http://www.lemis.com/grog/Documentation/Lions/ for some years now, and > my understanding had been that the book hadn't been published, just > photocopied, until Warren posted it on alt.folklore.computers in 1994. > But now it seems that the "book" had been published by UNSW when Lions > held the course, and only later was the license revoked. Does anybody > have any insights? What restrictions were there on its distribution? > What was the format? Was it a real book, or just bound notes? Nroff, in bound notes at the time; it did not come out in book format until later (I suppose that it depends upon your definition of "book" vs. "bound notes"... I was involved in it (you'll see my name in the credits). I helped to proof-read it, and I lent him our LA-100 for the draft copy. He was one of the best Comp Sci lecturers that I ever had, along with Ken Robinson (no longer with us) and Graham McMahon (ditto). -- Dave From fuz at fuz.su Tue Nov 3 07:32:54 2020 From: fuz at fuz.su (Robert Clausecker) Date: Mon, 2 Nov 2020 22:32:54 +0100 Subject: [TUHS] Plan 9 assembly syntax design history? Message-ID: <20201102213254.GA39017@fuz.su> Ken's (?) Plan 9 assemblers are well known for their idiosyncratic syntax, placing identical behaviour across platforms over a sense of resemblance to people used to normal assemblers. While I am aware of Rob's talk [1] on the basic design ideas and have read both the Plan 9 [2] and Go [3] assembler manuals, many aspects of the design (such as the strange way to specify static data) are unclear and seem poorly documented. Is there some document or other piece of information I can read on the history of these assemblers? Or maybe someone recalls more bits about these details? Yours, Robert Clausecker [1]: https://talks.golang.org/2016/asm.slide [2]: https://9p.io/sys/doc/asm.html [3]: https://golang.org/doc/asm -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From grog at lemis.com Tue Nov 3 11:16:48 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 3 Nov 2020 12:16:48 +1100 Subject: [TUHS] Lions notes, early history In-Reply-To: <202011021104.0A2B4LDw015231@freefriends.org> References: <202011021104.0A2B4LDw015231@freefriends.org> Message-ID: <20201103011648.GD49846@eureka.lemis.com> On Monday, 2 November 2020 at 4:04:21 -0700, arnold at skeeve.com wrote: > Ed Bradford wrote: > >> I had the orange and red books but I sold them to a fellow in Europe >> who has a Unix Museum. He also bought one of UNIX lice eggs plates. >> >> I took high resolution photos of each page before I sent them to Europe. I >> can send copies if that is legal and anyone is interested. >> >> Ed Bradford >> Pflugerville, TX > > Given that the Lions book was republished for anyone to purchase a few > years back (I bought a copy, as well as having a samisdat photocopy), > I see no reason why they couldn't be freely distributed. Maybe even > added to the archives, if Warren agrees. Yes, it's freely available now, as of about 2002. You can download it from http://www.lemis.com/grog/Documentation/Lions/ . My question related to a discussion about its copyright status when it was written, and how it was published. Warren's photos conveniently show the title page (with dedication by Lions himself) with the text This document may contain information covered by one or more licenses, copyright and non-disclosure agreements. Circulation of this document is restricted to holders of a license for the UNIX Software System from Western Electric. All other circulation or reproduction is prohibited. Since the release of the Ancient Unix license in 2002, this no longer applies, of course. 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 ron at ronnatalie.com Wed Nov 4 01:40:37 2020 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 03 Nov 2020 15:40:37 +0000 Subject: [TUHS] /usr/bin/1 Message-ID: This memory just came back to me. There was a UNIX disribution (PWB/UNIX?) that had a program called 1. It printed tis quaint bit of propaganda. One Bell System. It works. This was fine until one day I’m at work in a big bull pen computer room when Bernie, one of my co-workers, shouts. “What’s all this Bell System crud in the editor?” My reaction is, “Well, it’s all Bell System crud.” I walk over to his terminal and find he is typing 1 repeatedly at the shell prompt and getting the above message. (This was back in the old /bin/ed days where 1 got you to the top of the file). I had to point out he wasn’t in the editor. Later that day, the program was changed to say: You’re not in the editor, Bernie. This I think made it into one of the BRL releases and occassionally got inquiries as to who Bernie is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Nov 4 01:53:16 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 3 Nov 2020 10:53:16 -0500 Subject: [TUHS] /usr/bin/1 In-Reply-To: References: Message-ID: 👍 On Tue, Nov 3, 2020 at 10:49 AM Ron Natalie wrote: > This memory just came back to me. There was a UNIX disribution > (PWB/UNIX?) that had a program called 1. > It printed tis quaint bit of propaganda. > > One Bell System. It works. > > This was fine until one day I’m at work in a big bull pen computer room > when Bernie, one of my co-workers, shouts. > “What’s all this Bell System crud in the editor?” > > My reaction is, “Well, it’s all Bell System crud.” I walk over to his > terminal and find he is typing 1 repeatedly at the shell prompt and getting > the above message. (This was back in the old /bin/ed days where 1 got you > to the top of the file). I had to point out he wasn’t in the editor. > > Later that day, the program was changed to say: > > You’re not in the editor, Bernie. > > This I think made it into one of the BRL releases and occassionally got > inquiries as to who Bernie is. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gak at pobox.com Wed Nov 4 02:00:39 2020 From: gak at pobox.com (pobox.com) Date: Tue, 3 Nov 2020 08:00:39 -0800 Subject: [TUHS] /usr/bin/1 In-Reply-To: References: Message-ID: On Nov 3, 2020, at 7:40 AM, Ron Natalie wrote: > This memory just came back to me. There was a UNIX disribution (PWB/UNIX?) that had a program called 1. > It printed tis quaint bit of propaganda. > > One Bell System. It works. > > This was fine until one day I’m at work in a big bull pen computer room when Bernie, one of my co-workers, shouts. > “What’s all this Bell System crud in the editor?” > > My reaction is, “Well, it’s all Bell System crud.” I walk over to his terminal and find he is typing 1 repeatedly at the shell prompt and getting the above message. (This was back in the old /bin/ed days where 1 got you to the top of the file). I had to point out he wasn’t in the editor. > > Later that day, the program was changed to say: > > You’re not in the editor, Bernie. > > This I think made it into one of the BRL releases and occassionally got inquiries as to who Bernie is. Yes, PWB/UNIX. I seem to recall it also had /usr/bin/flog. You pass it a process ID as argument, and it was supposed to make the process work harder. (I can't remember the exact wording on the web page. In fact, I could be confused about it being in PWB.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Nov 4 06:56:21 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 3 Nov 2020 15:56:21 -0500 Subject: [TUHS] /usr/bin/1 In-Reply-To: References: Message-ID: On Tue, Nov 3, 2020 at 10:49 AM Ron Natalie wrote: One Bell System. It works. > I was told, though I didn't see this for myself, that in a post-1982 release it was changed to read "One Bell System. It used to work." Googling turns up "One Bell System. It used to work before they installed the Dimension." (I don't know what that means.) Every day I type "1" (or sometimes "0") to get to the top of the file in `ex`. (I know, of course, that `ed` is the standard editor, but I'm willing to trade off a little standardosity for a little more helpfulness.) As for flog(1), there is a boring modern command called that: it writes stdin to a specified log file and rotates it on receiving SIGHUP. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Yes, chili in the eye is bad, but so is your ear. However, I would suggest you wash your hands thoroughly before going to the toilet. --gadicath -------------- next part -------------- An HTML attachment was scrubbed... URL: From ality at pbrane.org Wed Nov 4 07:49:27 2020 From: ality at pbrane.org (Anthony Martin) Date: Tue, 3 Nov 2020 13:49:27 -0800 Subject: [TUHS] Plan 9 assembly syntax design history? In-Reply-To: <20201102213254.GA39017@fuz.su> References: <20201102213254.GA39017@fuz.su> Message-ID: <20201103214927.GA1091@alice> Robert Clausecker once said: > While I am aware of Rob's talk [1] on the basic design ideas > and have read both the Plan 9 [2] and Go [3] assembler > manuals, many aspects of the design (such as the strange way > to specify static data) are unclear and seem poorly > documented. > > [...] > > [1]: https://talks.golang.org/2016/asm.slide > [2]: https://9p.io/sys/doc/asm.html > [3]: https://golang.org/doc/asm Note that the Plan 9 compilers do not actually generate machine code. They build an intermediate abstract object code that the linkers then translate into machine code. The syntax used by the assemblers is essentially a textual representation of that intermediate code. If you want to understand the design and it's idiosyncrasies, focus on the latter. Cheers, Anthony From coppero1237 at gmail.com Fri Nov 6 08:10:06 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Fri, 6 Nov 2020 00:10:06 +0200 Subject: [TUHS] The Elements Of Style: UNIX As Literature Message-ID: Fun read and it's totally wild that people's emotional comfort with *text* drives a lot of their love or hate of unix. http://theody.net/elements.html Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Fri Nov 6 10:39:35 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 5 Nov 2020 17:39:35 -0700 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: Message-ID: On Thu, Nov 5, 2020 at 3:11 PM Tyler Adams wrote: > Fun read and it's totally wild that people's emotional comfort with *text* > drives a lot of their love or hate of unix. > > http://theody.net/elements.html > > Tyler > I would concur with the adaptation that the modern predictor of unix aptitude is attention span (which is lessened for a number of societal changes). It takes a fair amount of delayed gratification to get comfortable with unix. I was able to intuitively use Mac OS Classic at age 3, and I can see modern youth have the same young intuition for touch devices. But unix takes a bit more discipline and only rewards those who persevere. I suspect that’s why modern tech employers like it. They’ve learned to pick up the cues for people that will perform well in roles that require perseverance and holding a lot of mental context. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Nov 6 11:41:09 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 5 Nov 2020 17:41:09 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: Message-ID: <20201106014109.GP26296@mcvoy.com> That was a good read and a perspective on Unix that I've not seen before. I sort of fit with the author's view, I like to read and I like to write. I am much happier typing than clicking. Don't get me wrong, I live on Linux and it has made some stuff pleasantly clickable. I use virtual desktops, I have 6 of them. There are xterms in 5 out of 6, the last one has firefox. I click but I mostly live in terminal windows. Which are all 80 columns because that's the right width (I can go on and on about that). On Fri, Nov 06, 2020 at 12:10:06AM +0200, Tyler Adams wrote: > Fun read and it's totally wild that people's emotional comfort with *text* > drives a lot of their love or hate of unix. > > http://theody.net/elements.html > > Tyler -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cowan at ccil.org Fri Nov 6 15:04:28 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 6 Nov 2020 00:04:28 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106014109.GP26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> Message-ID: On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: I click but I mostly live in > terminal windows. Which are all 80 columns because that's the right > width (I can go on and on about that). > Aw, c'mon. You're going to tell us that the number of punch holes that IBM could fit on a punch card in 1928 that was exactly the size of the dollar bill used in the U.S. from 1862 to 1923 so that it could be stored in a mechanical cash register is miraculously the Right Thing when it comes to reading monospaced text on a screen? I think that's asking a bit much of ol' man Coincidence. ↓↓ 80-column .sig ↓↓ 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 usotsuki at buric.co Fri Nov 6 15:16:43 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 6 Nov 2020 00:16:43 -0500 (EST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: On Fri, 6 Nov 2020, John Cowan wrote: > On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: > > I click but I mostly live in >> terminal windows. Which are all 80 columns because that's the right >> width (I can go on and on about that). >> > > Aw, c'mon. You're going to tell us that the number of punch holes that IBM > could fit on a punch card in 1928 that was exactly the size of the dollar > bill used in the U.S. from 1862 to 1923 so that it could be stored in a > mechanical cash register is miraculously the Right Thing when it comes to > reading monospaced text on a screen? I think that's asking a bit much of > ol' man Coincidence. I find 120x30 (the Windows 10 default) works a bit better, though I still consider 80x24/25 the "canonical" terminal size - because it's about the width of text on a printout (6.5" x 12 cpi = 78 characters). -uso. From robpike at gmail.com Fri Nov 6 16:34:37 2020 From: robpike at gmail.com (Rob Pike) Date: Fri, 6 Nov 2020 17:34:37 +1100 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83 -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Nov 6 16:37:25 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 6 Nov 2020 17:37:25 +1100 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: <20201106063725.GB99027@eureka.lemis.com> On Friday, 6 November 2020 at 0:04:28 -0500, John Cowan wrote: > On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: > >> I click but I mostly live in terminal windows. Which are all 80 >> columns because that's the right width (I can go on and on about >> that). > > Aw, c'mon. You're going to tell us that the number of punch holes > that IBM could fit on a punch card in 1928 that was exactly the size > of the dollar bill used in the U.S. from 1862 to 1923 so that it > could be stored in a mechanical cash register is miraculously the > Right Thing when it comes to reading monospaced text on a screen? I think you're jumping to conclusions. The importance of 80 characters (for small values of 80) is that it's a comfortable text width for human eyes. Your message adheres to the rule, presumably not because you were thinking of punched cards. Was the US $ bill really that big in those days? > I think that's asking a bit much of ol' man Coincidence. Arguably the coincidence was the other way round. 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 will.senn at gmail.com Fri Nov 6 23:20:14 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 6 Nov 2020 07:20:14 -0600 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: On 11/6/20 12:34 AM, Rob Pike wrote: > https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83 > Hilarious. I use fixed font - Monaco 14. But, 80 columns? not on your life. I hate wrapped text output, if I can avoid it. That said, I set my soft word wrap in the text editor at 72 :). My convention comes from early email though, not punched cards. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From lm at mcvoy.com Sat Nov 7 01:06:09 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 6 Nov 2020 07:06:09 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106063725.GB99027@eureka.lemis.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> Message-ID: <20201106150609.GR26296@mcvoy.com> On Fri, Nov 06, 2020 at 05:37:25PM +1100, Greg 'groggy' Lehey wrote: > On Friday, 6 November 2020 at 0:04:28 -0500, John Cowan wrote: > > On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: > > > >> I click but I mostly live in terminal windows. Which are all 80 > >> columns because that's the right width (I can go on and on about > >> that). > > > > Aw, c'mon. You're going to tell us that the number of punch holes > > that IBM could fit on a punch card in 1928 that was exactly the size > > of the dollar bill used in the U.S. from 1862 to 1923 so that it > > could be stored in a mechanical cash register is miraculously the > > Right Thing when it comes to reading monospaced text on a screen? > > I think you're jumping to conclusions. The importance of 80 > characters (for small values of 80) is that it's a comfortable text > width for human eyes. Exactly this. I'm a very fast reader, easily 2-3x the average. I read by running my eyes down the middle of the page and get the left and right from peripheral vision. It's super fast but it doesn't work when you get much bigger than 80 columns. Even if you read normally, the wider it is, the more back and forth your eyes do so less is more. It's also why I'm fine with smaller screens, I tried the giant apple displays and found that those required head movement along with eye movement. I'm lazy. From clemc at ccc.com Sat Nov 7 01:07:21 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 6 Nov 2020 10:07:21 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: Will, I do still the same thing, but the reason for 72 for email being that way is still card-based. In FORTRAN the first column defines if the card is new (a blank), a comment (a capital C), no zero a 'continuation' of the last card. But column 73-80 were 'special' and used to store sequence #s (this was handy when you dropped your card deck, card sorters could put it back into canonical order). So characters in those columns were typically ignored. Thus when "Model 28 ASR" (a.k.a. ASR-28) created it had 72 columns. It's interesting that when its follow on the Model 33 was created, it actually had 74, but most SW configured it to 72 [search for a manual on bit savers or the like if you want the details]. IIRC, the original DEC 'Glass TTY' - the VT-05 was 72, but later terminals like the VT-52 were 80 columns, as was the ADM 3A. The one thing I will give the 'tyranny of 80-columns" is when I look at code it starts to break that line size by a lot, I often think that is a bell-weather of something that needs to be rewritten and simplified, and/or the abstraction might not be right. Like, most/many rules there >>are<< often break exceptions, but when I do look code with really long lines, I admit I am suspect. Clem On Fri, Nov 6, 2020 at 8:21 AM Will Senn wrote: > On 11/6/20 12:34 AM, Rob Pike wrote: > > > https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83 > > < > https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83 > > > Hilarious. I use fixed font - Monaco 14. But, 80 columns? not on your > life. I hate wrapped text output, if I can avoid it. That said, I set my > soft word wrap in the text editor at 72 :). My convention comes from > early email though, not punched cards. > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Nov 7 01:18:52 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 6 Nov 2020 07:18:52 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106150609.GR26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> Message-ID: <7792C9F9-178F-42F0-AA4F-5C36342FB6B7@iitbombay.org> On Nov 6, 2020, at 7:06 AM, Larry McVoy wrote: > > On Fri, Nov 06, 2020 at 05:37:25PM +1100, Greg 'groggy' Lehey wrote: >> On Friday, 6 November 2020 at 0:04:28 -0500, John Cowan wrote: >>> On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: >>> >>>> I click but I mostly live in terminal windows. Which are all 80 >>>> columns because that's the right width (I can go on and on about >>>> that). >>> >>> Aw, c'mon. You're going to tell us that the number of punch holes >>> that IBM could fit on a punch card in 1928 that was exactly the size >>> of the dollar bill used in the U.S. from 1862 to 1923 so that it >>> could be stored in a mechanical cash register is miraculously the >>> Right Thing when it comes to reading monospaced text on a screen? >> >> I think you're jumping to conclusions. The importance of 80 >> characters (for small values of 80) is that it's a comfortable text >> width for human eyes. > > Exactly this. I'm a very fast reader, easily 2-3x the average. I read by > running my eyes down the middle of the page and get the left and right > from peripheral vision. It's super fast but it doesn't work when you > get much bigger than 80 columns. > > Even if you read normally, the wider it is, the more back and forth your > eyes do so less is more. > > It's also why I'm fine with smaller screens, I tried the giant apple > displays and found that those required head movement along with eye > movement. > > I'm lazy. In Acme almost always I use variable width font but I still adjust column width to 80 (for a monospaced font). That way on a full screen on MBP I get a number of regular width columns and one narrow one which I use to keep my to do list or to note key points. 80 columns is a compromise that allows one to make better use of the screen real estate. I format text or comments in narrower columns so that you can read straight down instead of zigaziing down. Switching columns implies switching context. Lazyness is the mother of invention! Not sure what this has to do with "Unix as Literature"! From will.senn at gmail.com Sat Nov 7 01:40:52 2020 From: will.senn at gmail.com (Will Senn) Date: Fri, 6 Nov 2020 09:40:52 -0600 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: <175409f6-af94-601e-3db3-a5af5d7f64d0@gmail.com> Clem, It figures. I should have known there was a reason for the shorter lines other than display. Conventions are sticky and there appears to be a generation gap. I use single spaces between sentences, but my ancestors used 2... who knows why? :). Will On 11/6/20 9:07 AM, Clem Cole wrote: > Will, I do still the same thing, but the reason for 72 for email being > that way is still card-based.  In FORTRAN the first column defines if > the card is new (a blank), a comment (a capital C), no zero a > 'continuation' of the last card.  But column 73-80 were 'special' and > used to store sequence #s (this was handy when you dropped your card > deck, card sorters could put it back into canonical order).  So > characters in those columns were typically ignored.   Thus when "Model > 28 ASR" (a.k.a. ASR-28) created it had 72 columns. It's interesting > that when its follow on the Model 33 was created, it actually had 74, > but most SW configured it to 72 [search for a manual on bit savers or > the like if you want the details]. > > IIRC, the original DEC 'Glass TTY' - the VT-05 was 72, but later > terminals like the VT-52 were 80 columns, as was the ADM 3A. > > The one thing I will give the 'tyranny of 80-columns" is when I look > at code it starts to break that line size by a lot, I often think that > is a bell-weather of something that needs to be rewritten and > simplified, and/or the abstraction might not be right.   Like, > most/many rules there >>are<< often break exceptions, but when I do > look code with really long lines, I admit I am suspect. > > > Clem > > > On Fri, Nov 6, 2020 at 8:21 AM Will Senn > wrote: > > On 11/6/20 12:34 AM, Rob Pike wrote: > > > https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83 > > > > > > > Hilarious. I use fixed font - Monaco 14. But, 80 columns? not on your > life. I hate wrapped text output, if I can avoid it. That said, I > set my > soft word wrap in the text editor at 72 :). My convention comes from > early email though, not punched cards. > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Sat Nov 7 01:19:24 2020 From: torek at elf.torek.net (Chris Torek) Date: Fri, 6 Nov 2020 07:19:24 -0800 (PST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106150609.GR26296@mcvoy.com> Message-ID: <202011061519.0A6FJOAx034308@elf.torek.net> >> I think you're jumping to conclusions. The importance of 80 >> characters (for small values of 80) is that it's a comfortable text >> width for human eyes. >Exactly this. Yes -- this is the (or at least "an") argument for two-column text on wide (8.5x11 or A4, or larger) paper pages. >It's also why I'm fine with smaller screens, I tried the giant apple >displays and found that those required head movement along with eye >movement. >I'm lazy. I am too, but I still use a big screen: I just fit a lot of smaller windows in it. I'd like to have a literal wall screen, especially if I'm in an interior, windowless (as in physical glass windows) room, so that part of the wall could be a "window" showing a view "outside" (real time, or the ocean, or whatever) and other parts of the wall could be the text I'm working on/with, etc. (But I'll make do with these 27" 4k displays. :-) ) Chris From torek at elf.torek.net Sat Nov 7 01:46:57 2020 From: torek at elf.torek.net (Chris Torek) Date: Fri, 6 Nov 2020 07:46:57 -0800 (PST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <175409f6-af94-601e-3db3-a5af5d7f64d0@gmail.com> Message-ID: <202011061546.0A6Fkv3D034443@elf.torek.net> >I use single spaces between sentences, but my ancestors >used 2... who knows why? :). Typewriters. In typesetting, especially when doing right-margin justification, we have "stretchy spaces" between words. The space after end-of- sentence punctuation marks is supposed to be about 50% larger than the width of the between-words spaces, and if the word spaces get stretched, so should the end-of-sentence space. Note that this is all in the variable-pitch font world. Since typewriters are fixed-pitch, the way to emulate the 1.5-space-wide gap is to expand it to 2. Chris From paul.winalski at gmail.com Sat Nov 7 03:05:38 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 6 Nov 2020 12:05:38 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106063725.GB99027@eureka.lemis.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> Message-ID: On 11/6/20, Greg 'groggy' Lehey wrote: > > Was the US $ bill really that big in those days? Yes, it was. IIRC, the modern, smaller bills first went into circulation in the 1930s. There's an episode of the Beverly Hillbillies based on the old dollar bill size. Jed Clampett's uncle didn't trust banks and in the 1920s had been burying mason jars full of dollar bills in his backyard. Most were the old-style, punch card-size bills. He tells Drysdale the banker that his uncle has "big money". Drysdale of course thinks that if Jed Clampett the millionaire thinks it's big money, that uncle must be very rich, indeed.... -Paul W. From lm at mcvoy.com Sat Nov 7 03:07:40 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 6 Nov 2020 09:07:40 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> Message-ID: <20201106170740.GS26296@mcvoy.com> On Fri, Nov 06, 2020 at 12:05:38PM -0500, Paul Winalski wrote: > On 11/6/20, Greg 'groggy' Lehey wrote: > > > > Was the US $ bill really that big in those days? > > Yes, it was. IIRC, the modern, smaller bills first went into > circulation in the 1930s. > > There's an episode of the Beverly Hillbillies based on the old dollar > bill size. Jed Clampett's uncle didn't trust banks and in the 1920s > had been burying mason jars full of dollar bills in his backyard. > Most were the old-style, punch card-size bills. He tells Drysdale the > banker that his uncle has "big money". Drysdale of course thinks that > if Jed Clampett the millionaire thinks it's big money, that uncle must > be very rich, indeed.... That's hilarious, I missed that joke when watching as a kid. From athornton at gmail.com Sat Nov 7 03:13:19 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 6 Nov 2020 10:13:19 -0700 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106063725.GB99027@eureka.lemis.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> Message-ID: <5BE1CBD5-C9EB-45D4-B135-E58BCCCBE38C@gmail.com> I’m going to chime in on pro-80-columns here, because with the text a comfortable size to read (although this is getting less true as my eyes age), I can read an entire 80-column line without having to sweep my eyes back and forth. I can’t, and never could, do that at 132. As a consequence, I read much, much faster with 80-column-ish text blocks. I also think there is something to the “UNIX is verbal” and “UNIX nerds tend to be polyglots often with a surprising amount of liberal arts background of one kind or another,” argument. That may, however, merely be confirmation bias. Adam From imp at bsdimp.com Sat Nov 7 03:25:07 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 6 Nov 2020 10:25:07 -0700 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106170740.GS26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106170740.GS26296@mcvoy.com> Message-ID: On Fri, Nov 6, 2020 at 10:08 AM Larry McVoy wrote: > On Fri, Nov 06, 2020 at 12:05:38PM -0500, Paul Winalski wrote: > > On 11/6/20, Greg 'groggy' Lehey wrote: > > > > > > Was the US $ bill really that big in those days? > > > > Yes, it was. IIRC, the modern, smaller bills first went into > > circulation in the 1930s. > > > > There's an episode of the Beverly Hillbillies based on the old dollar > > bill size. Jed Clampett's uncle didn't trust banks and in the 1920s > > had been burying mason jars full of dollar bills in his backyard. > > Most were the old-style, punch card-size bills. He tells Drysdale the > > banker that his uncle has "big money". Drysdale of course thinks that > > if Jed Clampett the millionaire thinks it's big money, that uncle must > > be very rich, indeed.... > > That's hilarious, I missed that joke when watching as a kid. > Wow! Me too! Google confirmed the size changed in th 20s as a cost cutting measure. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclark46 at earthlink.net Sat Nov 7 03:26:13 2020 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri, 6 Nov 2020 12:26:13 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <5BE1CBD5-C9EB-45D4-B135-E58BCCCBE38C@gmail.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <5BE1CBD5-C9EB-45D4-B135-E58BCCCBE38C@gmail.com> Message-ID: <3c54b19d-e604-68eb-2b4b-0b65e9cfb896@earthlink.net> On 11/6/20 12:13 PM, Adam Thornton wrote: > I’m going to chime in on pro-80-columns here, because with the text a comfortable size to read (although this is getting less true as my eyes age), I can read an entire 80-column line without having to sweep my eyes back and forth. > > I can’t, and never could, do that at 132. > > As a consequence, I read much, much faster with 80-column-ish text blocks. > > I also think there is something to the “UNIX is verbal” and “UNIX nerds tend to be polyglots often with a surprising amount of liberal arts background of one kind or another,” argument. That may, however, merely be confirmation bias. > > Adam May have had to do with the first terminal commonly used with UNIX. The Model 33 printed on 8.5-inch (220 mm) wide paper, supplied on continuous 5-inch (130 mm) diameter rolls and fed via friction (instead of, e.g., tractor feed). It printed at a fixed 10 characters per inch, and supported 74-character lines,[13] although 72 characters is often commonly stated. From cowan at ccil.org Sat Nov 7 04:24:14 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 6 Nov 2020 13:24:14 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <3c54b19d-e604-68eb-2b4b-0b65e9cfb896@earthlink.net> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <5BE1CBD5-C9EB-45D4-B135-E58BCCCBE38C@gmail.com> <3c54b19d-e604-68eb-2b4b-0b65e9cfb896@earthlink.net> Message-ID: On Fri, Nov 6, 2020 at 12:26 PM Stephen Clark wrote: > May have had to do with the first terminal commonly used with UNIX. > > The Model 33 > In fact the Labs had the more recent Model 37, which did lower case, unlike the 33. Consequently, Unix was (I think) the first case-sensitive operating system. However, it had to work on 33s as well; if you tried to log in using an uppercase username, login would turn on the IUCLC and OLCUC bits of /dev/tty, and if you needed an uppercase letter you had to escape it (I think with \), which the tty driver processed. Thanks to everyone for filling in all the gaps in the chain from dollar bills to 80-column terminal windows that I had left implicit. To clarify my position, what I am opposed to is not the use of 80-column windows for *reading* email. I'm not happy with what happens to text that is hard-wrapped at 80 columns when displayed in a narrower window, as often happens to me now that I use larger fonts than I used to. The text/format-flowed MIME type was supposed to help with this problem, but never really caught on. "Well, I'm back." --Sam John Cowan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Nov 7 04:51:11 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 06 Nov 2020 10:51:11 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106150609.GR26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> Message-ID: <202011061851.0A6IpB7p555742@darkstar.fourwinds.com> Larry McVoy writes: > On Fri, Nov 06, 2020 at 05:37:25PM +1100, Greg 'groggy' Lehey wrote: > > On Friday, 6 November 2020 at 0:04:28 -0500, John Cowan wrote: > > > On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy wrote: > > > > > >> I click but I mostly live in terminal windows. Which are all 80 > > >> columns because that's the right width (I can go on and on about > > >> that). > > > > > > Aw, c'mon. You're going to tell us that the number of punch holes > > > that IBM could fit on a punch card in 1928 that was exactly the size > > > of the dollar bill used in the U.S. from 1862 to 1923 so that it > > > could be stored in a mechanical cash register is miraculously the > > > Right Thing when it comes to reading monospaced text on a screen? > > > > I think you're jumping to conclusions. The importance of 80 > > characters (for small values of 80) is that it's a comfortable text > > width for human eyes. > > Exactly this. I'm a very fast reader, easily 2-3x the average. I read by > running my eyes down the middle of the page and get the left and right > from peripheral vision. It's super fast but it doesn't work when you > get much bigger than 80 columns. > > Even if you read normally, the wider it is, the more back and forth your > eyes do so less is more. > > It's also why I'm fine with smaller screens, I tried the giant apple > displays and found that those required head movement along with eye > movement. We're getting into religion again here, and I've never found that to be a sound basis for policy. I'm going to quote liberally here from a screed that I wrote (but have not published) when trying to understand parts of the linux kernel. I've always been willing to spend buckets of money on the monitors because to me that's an area where bigger and higher resolution is always better. I've been using 132 column terminal windows since sometime in the 90s when I got myself a monster 24" Trinitron monitor from Sun. I seem to recall that it listed for $3,300, thanks to the unnamed person who got me the employee discount :-) I tried going to 160 columns but that was too wide for the monitors that people I worked with had. I hated Shakespeare in high school. One of the big reasons was that I felt that he made up a word whenever he didn't have a good one available. The flipping back and forth to the list of definitions completely interrupted the cadence of reading. The insistence on short line lengths in coding standards and the contortions that people go through to meet them has the same effect for me. I've coined the phrase "mental locality of reference" to describe this; at least I think that I'm the first one to use it. Short lines and modern coding styles ask the human brain to contort itself in ways that we are loath to ask hardware to do. As near as I can tell, the belief that people do best with line lengths between 50 and 75 characters long is the result of people repeating "wisdom" that they heard from someone else that orginates from what I consider to be a misreading of Emil Ruder's book "Typographie: A Manual of Design". While Ruder does make this statement about line length, it's in the context of normal typography. It does not even remotely consider computer code where long lines are long mainly due to leading whitespace. To the best of my knowledge nobody has studied this - does the line length when counting begin at the first column or the first non-whitespace character? While readers might "lose focus" part of the way through long lines, that has to be balanced against the loss of focus that comes from 'mental carriage-returns" when text is too narrow and broken across several lines. Again, not studied as far as I know. The linux coding standard makes the unsubstantiated claim that having more than three levels of indent is a problem. And it's really hard to understand, because on one hand, it says that you "should fix your program", and then says that "nesting functions too deep" is a problem. Sounds like a catch-22 to me; how are you going to minimize indent if you can't nest functions? I'm guessing that someone typed this without reading what they wrote and really meant "statements", not "functions". We're back to the mental locality-of-reference thing that was mentioned earlier. I'd much rather have a few more levels of indent and longer lines than have to go chasing gratuitous function calls. Think about every diversion from the stuff in front of you as a cache miss. When I look at the linux kernel code, I see incredibly bad contortions made in attempts to meet the coding style. I also observed that the code only loosely follows its coding style. How are people limiting their code to three indent levels? By including dozens of header files that contain static inline functions. Gak! I feel that style rules should be observed in some sort of priority order, and mental locality of reference, which isn't in anybody's rules but mine, is at the top of the list. I could go on, but hopefully I've made my point. Jon From dave at horsfall.org Sat Nov 7 07:10:22 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 7 Nov 2020 08:10:22 +1100 (EST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106014109.GP26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> Message-ID: On Thu, 5 Nov 2020, Larry McVoy wrote: > Don't get me wrong, I live on Linux and it has made some stuff > pleasantly clickable. I use virtual desktops, I have 6 of them. There > are xterms in 5 out of 6, the last one has firefox. I click but I > mostly live in terminal windows. Which are all 80 columns because > that's the right width (I can go on and on about that). Almost all of my xterms are 80 cols for the same reason, but I do have one that is about 160 cols for things like "sdiff" etc. Or if I'm feeling nostalgic I'll use 120 cols :-) They are also mostly 24 rows, except for a couple of 40-row ones for email (more context) and source editing (ditto). I was brought up on 80x24 (along with a status line which could be addressed either with an escape sequence or the "25th row") so it feels "right" for me (we'll ignore the 72x20 VT-05 for now). -- Dave From cowan at ccil.org Sat Nov 7 08:09:19 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 6 Nov 2020 17:09:19 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <202011061851.0A6IpB7p555742@darkstar.fourwinds.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> <202011061851.0A6IpB7p555742@darkstar.fourwinds.com> Message-ID: On Fri, Nov 6, 2020 at 1:51 PM Jon Steinhart wrote: > I've always been willing to spend buckets of money on the monitors because > to me that's an area where bigger and higher resolution is always better. > You'd hardly want one the size of a city block, or even of a room wall. > I hated Shakespeare in high school. One of the big reasons was that I felt > that he made up a word whenever he didn't have a good one available. Contrary to Internet opinion, Shakespeare probably never invented any words. At most he is the first person to record in writing a word whose written works have survived (mostly). Why would a commercial playwright (and Shakespeare wrote for money) use a word his audience didn't understand? They'd boo the play off the stage, with or without rotten fruit. He did both invent and reuse a lot of phrases: see < https://inside.mines.edu/~jamcneil/levinquote.html>, or google for "you are quoting Shakespeare". The > flipping back and forth to the list of definitions completely interrupted > the cadence of reading. > Pop-up translations would be much better, of course. I studied R&J with footnotes; my daughter, with an across-the-page translation into Contemporary Modern English. Of course, that meant I had to explain some of the gallows humor to her, like Mercutio's dying words: "Seek for me tomorrow, and you will find me a *grave* man." > While readers might "lose focus" part of the way through long lines, that > has to > be balanced against the loss of focus that comes from 'mental > carriage-returns" > when text is too narrow and broken across several lines. Again, not > studied as > far as I know. > Lispers, of course, have only one kind of bracket, and append as many close-brackets to each line as are needed there. (We don't count them, Emacs and vi do the matching.) Sure saves on vertical whitespace, which means you typically can see a whole function in one screen. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Is a chair finely made tragic or comic? Is the portrait of Mona Lisa good if I desire to see it? Is the bust of Sir Philip Crampton lyrical, epical or dramatic? If a man hacking in fury at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Sat Nov 7 08:12:23 2020 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 6 Nov 2020 23:12:23 +0100 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106150609.GR26296@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> Message-ID: On 11/6/20, Larry McVoy wrote: > It's also why I'm fine with smaller screens, I tried the giant apple > displays and found that those required head movement along with eye > movement. Exactly. I never understood all the fuss about those huge LCD screens in front of your eyes. A few years ago I used a real VT220 (12" in size) for my daily job in the office and it was perfect for command line work. At home I use a lot of Digital text terminals and PC DOS era CRT monitors and they are really great for what they were made for. Text mode can't get any better than 720x400 on 14" CRT monitor. For graphical mode I still love 640x480 -- everything is big enough for me. The 70s, 80s and 90s got a lot of things right. The introduction of widescreen LCD monitors around 2007 ruined a lot of things. And of course the 80 columns output is the only right choice. It especially makes sense if you are still using text mode only CRT monitors, like I do. --Andy From lm at mcvoy.com Sat Nov 7 08:23:02 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 6 Nov 2020 14:23:02 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> Message-ID: <20201106222302.GG26411@mcvoy.com> On Fri, Nov 06, 2020 at 11:12:23PM +0100, Andy Kosela wrote: > The 70s, 80s and 90s got a lot of things right. The introduction > of widescreen LCD monitors around 2007 ruined a lot of things. Yeah, I wasn't a fan of going wider. I'm bucking the old school trend and typing on an 80x44 terminal which is as tall as I can go on my X1 Carbon. It's big enough. For me, taller is more useful than wider, provided I can get about 162 columns so I can do side by side diffs. More than that doesn't do much for me. But I'm pretty old school, I write in C, I debug a lot with printf and asserts, I'm kind of a dinosaur. In the last year or so I reconnected with Kirk and Eric and much to my surprise, and pleasure, I found that Eric and I see things very similarly, I'd be happy to work with/for that guy, we really agree. One thing I will say about big monitors is they are great for photos. I do a lot of digital photography and have no desire to go back to black & white or CRT terminals. From dave at horsfall.org Sat Nov 7 08:31:08 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 7 Nov 2020 09:31:08 +1100 (EST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: [ Getting into COFF territory here, I think ] On Fri, 6 Nov 2020, Clem Cole wrote: > But column 73-80 were 'special' and used to store sequence #s (this was > handy when you dropped your card deck, card sorters could put it back > into canonical order). We used to grab a wide felt-tip pen and draw a diagonal stripe across the top of the deck; at least that got you started. -- Dave, who has dropped the occasional deck From jon at fourwinds.com Sat Nov 7 08:44:14 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 06 Nov 2020 14:44:14 -0800 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> <202011061851.0A6IpB7p555742@darkstar.fourwinds.com> Message-ID: <202011062244.0A6MiEgX575756@darkstar.fourwinds.com> John Cowan writes: > On Fri, Nov 6, 2020 at 1:51 PM Jon Steinhart wrote: > > > I've always been willing to spend buckets of money on the monitors because > > to me that's an area where bigger and higher resolution is always better. > > You'd hardly want one the size of a city block, or even of a room wall. > > > I hated Shakespeare in high school. One of the big reasons was that I felt > > that he made up a word whenever he didn't have a good one available. > > Contrary to Internet opinion, Shakespeare probably never invented any > words. At most he is the first person to record in writing a word whose > written works have survived (mostly). Why would a commercial playwright > (and Shakespeare wrote for money) use a word his audience didn't > understand? They'd boo the play off the stage, with or without rotten > fruit. He did both invent and reuse a lot of phrases: see < > https://inside.mines.edu/~jamcneil/levinquote.html>, or google for "you are > quoting Shakespeare". > > The > > flipping back and forth to the list of definitions completely interrupted > > the cadence of reading. > > Pop-up translations would be much better, of course. I studied R&J with > footnotes; my daughter, with an across-the-page translation into > Contemporary Modern English. Of course, that meant I had to explain some > of the gallows humor to her, like Mercutio's dying words: "Seek for me > tomorrow, and you will find me a *grave* man." > > > While readers might "lose focus" part of the way through long lines, that > > has to > > be balanced against the loss of focus that comes from 'mental > > carriage-returns" > > when text is too narrow and broken across several lines. Again, not > > studied as > > far as I know. > > Lispers, of course, have only one kind of bracket, and append as many > close-brackets to each line as are needed there. (We don't count them, > Emacs and vi do the matching.) Sure saves on vertical whitespace, which > means you typically can see a whole function in one screen. As I said in my original post, we're getting into religion here. So we have different views on monitors; I am contemplating replacing my 32" UHD monitor with a 70" UHD TV. Why? Because I can keep everything on my screen the same which will make everything bigger so I can put the monitor farther away getting me out of my farsighted zone and into my 20-20 range which would eliminate the need for glasses. Not gonna rathole on the Shakespeare analogy - maybe I'm wrong but it's not relevant to the point that I was making. The books that we were given in high school didn't have pop-up translations or footnotes. In case I wasn't clear in my original posting, the topic was mental locality of reference issues as related to terminal size and coding style. Jon From grog at lemis.com Sat Nov 7 08:54:22 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 7 Nov 2020 09:54:22 +1100 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <202011061546.0A6Fkv3D034443@elf.torek.net> References: <175409f6-af94-601e-3db3-a5af5d7f64d0@gmail.com> <202011061546.0A6Fkv3D034443@elf.torek.net> Message-ID: <20201106225422.GD99027@eureka.lemis.com> On Friday, 6 November 2020 at 7:46:57 -0800, Chris Torek wrote: >> I use single spaces between sentences, but my ancestors >> used 2... who knows why? :). > > Typewriters. > > In typesetting, especially when doing right-margin justification, > we have "stretchy spaces" between words. The space after end-of- > sentence punctuation marks is supposed to be about 50% larger than > the width of the between-words spaces, and if the word spaces get > stretched, so should the end-of-sentence space. FWIW, this is the US convention. Other countries have different conventions. My Ausinfo style manual states There is no need to increase the amount of punctuation ... at the end of a sentence. I believe that this also holds for Germany. I'm not sure that the UK didn't have different rules again. 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 steffen at sdaoden.eu Sat Nov 7 09:29:01 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 07 Nov 2020 00:29:01 +0100 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106225422.GD99027@eureka.lemis.com> References: <175409f6-af94-601e-3db3-a5af5d7f64d0@gmail.com> <202011061546.0A6Fkv3D034443@elf.torek.net> <20201106225422.GD99027@eureka.lemis.com> Message-ID: <20201106232901.AkY2I%steffen@sdaoden.eu> Greg 'groggy' Lehey wrote in <20201106225422.GD99027 at eureka.lemis.com>: |On Friday, 6 November 2020 at 7:46:57 -0800, Chris Torek wrote: |>> I use single spaces between sentences, but my ancestors |>> used 2... who knows why? :). |> |> Typewriters. |> |> In typesetting, especially when doing right-margin justification, |> we have "stretchy spaces" between words. The space after end-of- |> sentence punctuation marks is supposed to be about 50% larger than |> the width of the between-words spaces, and if the word spaces get |> stretched, so should the end-of-sentence space. | |FWIW, this is the US convention. Other countries have different |conventions. My Ausinfo style manual states | | There is no need to increase the amount of punctuation ... at the | end of a sentence. | |I believe that this also holds for Germany. I'm not sure that the UK |didn't have different rules again. Yes, the DUDEN of Germany says for typewriters that the punctuation characters period, comma, semicolon, colon, question- and exclamation mark are added without separating whitespace. The next word follows after a space ("Leerschritt", "void step"). However, typewriters often place(d) those characters left in a cell, so that the visual appearance is accordingly. In novels around 66 characters is the recommendation i seem to recall. I have that in mails, 72 in other text modes, and 79 for everything else. (The latter lead to lots of ugly code once i used tabulators, but different tabulator spacing would have resulted in different look in $PAGER and $VISUAL, so ...) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wkt at tuhs.org Sat Nov 7 09:41:52 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 7 Nov 2020 09:41:52 +1000 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> Message-ID: <20201106234152.GA7183@minnie.tuhs.org> On Sat, Nov 07, 2020 at 09:31:08AM +1100, Dave Horsfall wrote: > [ Getting into COFF territory here, I think ] Yes all, we've drifted out of Unix and into old fart territory, so please move over to coff at tuhs.org for future replies! Thanks, Warren From sclark46 at earthlink.net Sat Nov 7 02:46:08 2020 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri, 6 Nov 2020 11:46:08 -0500 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <202011061519.0A6FJOAx034308@elf.torek.net> References: <202011061519.0A6FJOAx034308@elf.torek.net> Message-ID: On 11/6/20 10:19 AM, Chris Torek wrote: >>> I think you're jumping to conclusions. The importance of 80 >>> characters (for small values of 80) is that it's a comfortable text >>> width for human eyes. >> Exactly this. > Yes -- this is the (or at least "an") argument for two-column text > on wide (8.5x11 or A4, or larger) paper pages. > >> It's also why I'm fine with smaller screens, I tried the giant apple >> displays and found that those required head movement along with eye >> movement. >> I'm lazy. > I am too, but I still use a big screen: I just fit a lot of > smaller windows in it. I'd like to have a literal wall screen, > especially if I'm in an interior, windowless (as in physical glass > windows) room, so that part of the wall could be a "window" > showing a view "outside" (real time, or the ocean, or whatever) > and other parts of the wall could be the text I'm working on/with, > etc. > > (But I'll make do with these 27" 4k displays. :-) ) > > Chris Could the 72 characters come from the original terminal ASR 33 Teletype? The Model 33 printed on 8.5-inch (220 mm) wide paper, supplied on continuous 5-inch (130 mm) diameter rolls and fed via friction (instead of, e.g., tractor feed). It printed at a fixed 10 characters per inch, and supported 74-character lines,[13] although 72 characters is often commonly stated. -- From dave at horsfall.org Sat Nov 7 10:16:56 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 7 Nov 2020 11:16:56 +1100 (EST) Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: <20201106222302.GG26411@mcvoy.com> References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> <20201106222302.GG26411@mcvoy.com> Message-ID: [ Moving to COFF (if your MUA respects "Reply-To:") ] On Fri, 6 Nov 2020, Larry McVoy wrote: > But I'm pretty old school, I write in C, I debug a lot with printf and > asserts, I'm kind of a dinosaur. You've never experienced the joy of having your code suddenly working when inserting printf() statements? Oh dear; time to break out GDB... -- Dave From ggm at algebras.org Mon Nov 9 09:23:35 2020 From: ggm at algebras.org (George Michaelson) Date: Mon, 9 Nov 2020 09:23:35 +1000 Subject: [TUHS] The Elements Of Style: UNIX As Literature In-Reply-To: References: <20201106014109.GP26296@mcvoy.com> <20201106063725.GB99027@eureka.lemis.com> <20201106150609.GR26296@mcvoy.com> <20201106222302.GG26411@mcvoy.com> Message-ID: A lot of industrial design is based on inheritance. The nitrocellulose filmstock was nominal 40mm, after cutting and sprockets it was 35. cut it in half you have 16mm single sprocket. Original manufacture was 80 wide cut in half so undo that and you get 70mm. run the film sideways, you now have 700 high for IMAX dimensions. Why was nitrocellulose film stock coming in 80mm wide strips? Ask somebody who knows what George Eastman was doing at the time... My guess is the tank emitted 100mm but the edges were crinkly, and 80mm was what he got after slicing ragged margins. The rest is inheritance down the stack working on 1/2 and 1/4 sizing consequences. IBM was business machines. tabulators. The sheet stock it used for things in business was defined by what it could source coming in, reliably. The US census used hollerith cards, this is probably why the fed reserve used hollerith cards. (My G/F got a 1978 tax cheque refund from a camp school in the midwest on a hollerith-card-cheque, the last time I saw one in anger outside of the computer labs where we were still using them in anger, very anger) the Banks first atm's used card stock for receipts. they were mini-hollerith. I imagine because they understood how to do alignment from a cut corner, and had machinery which worked. I was told that fmt/72 is a post-hoc rationalisation to allow for 4-5 levels of indentation in >>>quoting. I think this is a post-hoc rationalisation of a prompter hoc reality. If you go back into teletype deep history, I bet you find 40/60/72 was coming out of some combination of fixed-width typeface, mechanics, and paper stock sizes available in the supply chain. (Mike Lesk told me the TBL offset in the T/ROFF box drawing was because of a highly specific throwback effect in the printer at Bell. The code was adjusted to deal with this, and the rest of us had to wear the top and bottom lines being misplaced without a patch to the code. This kind of thing, its classic "because we could, and because it works" decision logic) On Sat, Nov 7, 2020 at 10:17 AM Dave Horsfall wrote: > > [ Moving to COFF (if your MUA respects "Reply-To:") ] > > On Fri, 6 Nov 2020, Larry McVoy wrote: > > > But I'm pretty old school, I write in C, I debug a lot with printf and > > asserts, I'm kind of a dinosaur. > > You've never experienced the joy of having your code suddenly working when > inserting printf() statements? Oh dear; time to break out GDB... > > -- Dave From dscherrer at solar.stanford.edu Wed Nov 11 08:52:22 2020 From: dscherrer at solar.stanford.edu (Deborah K Scherrer) Date: Tue, 10 Nov 2020 14:52:22 -0800 Subject: [TUHS] Mach386 manual Message-ID: <99cca36a-af08-4cbf-7c16-8d37194085de@solar.stanford.edu> Anybody want a little manual "Installing and Operating Mt Xinu Mach386? Will send (free). Deborah From clemc at ccc.com Wed Nov 11 09:20:59 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Nov 2020 18:20:59 -0500 Subject: [TUHS] Mach386 manual In-Reply-To: <99cca36a-af08-4cbf-7c16-8d37194085de@solar.stanford.edu> References: <99cca36a-af08-4cbf-7c16-8d37194085de@solar.stanford.edu> Message-ID: I'd love it. On Tue, Nov 10, 2020 at 6:09 PM Deborah K Scherrer < dscherrer at solar.stanford.edu> wrote: > Anybody want a little manual "Installing and Operating Mt Xinu Mach386? > Will send (free). > > Deborah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Nov 19 08:25:59 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 18 Nov 2020 17:25:59 -0500 Subject: [TUHS] Where did the "~" come from Message-ID: A couple of my friends from UC Berkeley were musing on another email thread. The question from one of them came up: *"I'm teaching the undergrad OS course this semester ... Mention where ~ comes."* This comment begets a discussion among the 4 of us at where it showed up in the UNIX heritage and it if was taken from somewhere else. Using the tilde character as a short cut for $HOME was purely a userspace convention and not part of the nami() kernel routine when it came into being. We know that it was supported by Mike Lesk in UUCP and by Bill Joy in cshell. The former was first widely released as part of Seventh Edition but was working on V6 before that inside of BTL. Joy's cshell came out as part of 2BSD (which was V7 based), but he had released "ashell" before that and included it in the original BSD (*a.k.a.* 1BSD) which was for V6 [what I don't remember is if it supported the convention and I can not easily un- ar(1) the cont.a files in the 1BSD tar image in Warren's archives. In our exchange, someone observed suggested that Joy might have picked it up because the HOME key was part of the tilde key on the ADM3A, which were popular at UCB [*i.e.* the reason hjkl are the movement keys on vi is the were embossed on the top of those keys on the ADM3A]. It also was noted that the ASR-33 lacks a ~ key on its keyboard. But Lesk definitely needed something to represent a remote user's home directory because each system was different, so he was forced to use something. It was also noted that there was plenty of cross-pollination going on as students and researchers moved from site to site, so it could have been BTL to UCB, vice-versa, or some other path altogether. So two questions for this august body are: 1. Where did the ~ as $HOME convention come to UNIX? 2. Did UNIX create the idiom, or was there an earlier system such as CTSS, TENEX, ITS, MTS, TSS, or the like supported it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Nov 19 08:41:29 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 19 Nov 2020 09:41:29 +1100 (EST) Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020, Clem Cole wrote: > In our exchange, someone observed suggested that Joy might have picked > it up because the HOME key was part of the tilde key on the ADM3A, which > were popular at UCB [i.e. the reason hjkl are the movement keys on vi is > the were embossed on the top of those keys on the ADM3A].  It also was > noted that the ASR-33 lacks a ~ key on its keyboard.  But Lesk > definitely needed something to represent a remote user's home directory > because each system was different, so he was forced to use something. The ADM-3A was one of the best terminals ever made. > It was also noted that there was plenty of cross-pollination going on as > students and researchers moved from site to site, so it could have been BTL > to UCB, vice-versa, or some other path altogether. > > So two questions for this august body are: > 1. Where did the ~ as $HOME convention come to UNIX? Gawd... I think I saw it in PWB, but I'm likely wrong. > 2. Did UNIX create the idiom, or was there an earlier system such as CTSS, > TENEX, ITS, MTS, TSS, or the like supported it? No idea. but given that Unix inherited a lot of stuff.... -- Dave From ggm at algebras.org Thu Nov 19 10:44:34 2020 From: ggm at algebras.org (George Michaelson) Date: Thu, 19 Nov 2020 10:44:34 +1000 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: A related but different "thing" is when the cd activity became a pushdown stack of 2 (is it more? I never bothered checking) somebody realised going "there and back again" was innately useful. (I will never forget working on systems which had cd-moral-equivalent and no cd-moral-equivalent but having cd-moral-equivalent $HOME making all directory traversals downward, or back to your personal root) sorry for thread hijack. -G On Thu, Nov 19, 2020 at 8:42 AM Dave Horsfall wrote: > > On Wed, 18 Nov 2020, Clem Cole wrote: > > > In our exchange, someone observed suggested that Joy might have picked > > it up because the HOME key was part of the tilde key on the ADM3A, which > > were popular at UCB [i.e. the reason hjkl are the movement keys on vi is > > the were embossed on the top of those keys on the ADM3A]. It also was > > noted that the ASR-33 lacks a ~ key on its keyboard. But Lesk > > definitely needed something to represent a remote user's home directory > > because each system was different, so he was forced to use something. > > The ADM-3A was one of the best terminals ever made. > > > It was also noted that there was plenty of cross-pollination going on as > > students and researchers moved from site to site, so it could have been BTL > > to UCB, vice-versa, or some other path altogether. > > > > So two questions for this august body are: > > 1. Where did the ~ as $HOME convention come to UNIX? > > Gawd... I think I saw it in PWB, but I'm likely wrong. > > > 2. Did UNIX create the idiom, or was there an earlier system such as CTSS, > > TENEX, ITS, MTS, TSS, or the like supported it? > > No idea. but given that Unix inherited a lot of stuff.... > > -- Dave From jon at fourwinds.com Thu Nov 19 11:29:22 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 18 Nov 2020 17:29:22 -0800 Subject: [TUHS] 516-TSS documents Message-ID: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> Well, it's a very rainy day and since COVID is keeping me home I just fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff. Not sure what to do with it since I don't have a place to serve it and since they're scanned images they're too big to post. Here's the list of documents; email me if you're wanting something in a hurry while the archive stuff is figured out. Note that the smell of mildew wasn't preserved in the scanning process. 516-1-516-DOCUMENTATION.pdf 516-3-DDP-516-PRICE-LIST.pdf 516-4-Disk-Layout.pdf 516-5-System-Table-Formats.pdf 516-6-Segment-Format.pdf 516-8-Disk-Hole-Format.pdf 516-7-DMA-Mnemonics.pdf 516-9-Addresses.pdf 516-10-11-12-Ring-Formats.pdf 516-12-Specifications-For-The-Node-Modem-Interface.pdf 516-13-Trac-Character-Strings.pdf 516-14-GMAP-Assembler-for-the-Multi-Programmed-516.pdf 516-15-A-Suggested-Graphic-Display-with-Keyboard-for-Graphic-Terminals.pdf 516-16-516-Assembler-And-Post-Processor-For-Unsegmented-Programs.pdf 516-18-Format-For-Ring-Interrupt.pdf 516-19-Thread-Save-Blocks.pdf 516-20-Card-Reader-Bootstrap-and-Programs.pdf 516-21-Octal-Package.pdf 516-22-A-Repeater-For-The-Node-Modem.pdf 516-23-CLEAR-CORE-CARD.pdf 516-24-SOROBAN-CARD-READER-TEST-PROGRAM.pdf 516-25-IO-Table.pdf 516-26-Disk-DMA-Queue.pdf 516-27-GE-Disc-Files-For-516-Programming.pdf 516-27-Thread-Table.pdf 516-28-IO-Ring_Device-Codes.pdf 516-29-Five-Bit-Character-Codes.pdf 516-30-Text-Editor.pdf 516-31-Relocatable-Segment-Octal-Package.pdf 516-32-ASCII-Character-Mnemonics.pdf 516-34-Display-List-For-Glance.pdf 516-35-Internal-Megacycle-Clock.pdf 516-36-Node-Modem-Interface-For-Computer-Terminals.pdf 516-38-P8SYS.pdf 516-39-Resource-Monitor-Meters.pdf 516-40-SNAP-Time-Sharing-Calculator.pdf 516-41-516-Segment-Assembler.pdf 516-42-Memory-Service-Unit-Format.pdf 516-43-GEBKUP-and-FLOAD.pdf 516-44-FSNAP-Floating-Point-Time-Sharing-Calculator.pdf 516-45-516-316-Assembler-and-Binder.pdf 516-46-CALC-A-Desk-Calculator-Program.pdf 516-47-Remote-Data-Plotting.pdf 516-48-CODING-FOR-GLANCE-G-Graphics.pdf 516-49-516-Segment-Assembler.pdf 516-50-Use-Of-The-516-Segment-Assemblers-Macros-In-Application-Programs.pdf 516-51-FSNAP-Designers-Guide.pdf 516-51-FSNAP-Users-Guide.pdf 516-52-DESK-A-Desk-Calculator.pdf 516-53-FSEOF-Flag-End-Of-File.pdf 516-54-Context-Editing.pdf 516-55-One-Card-Core-Save-Program.pdf 516-56-PRIME-An-Integer-Factoring-Program.pdf 516-57-Format-For-The-516-Node-T-I-U-Spider-Interface.pdf 516-59-Calling-Procedures-For-Math-Routines.pdf 516-59-INITIALIZATION-OF-THE-516-TSS-SYSTEM.pdf 516-60-SORT-SUBR-FOR-SEGMENTED-PROGRAMS.pdf 516-61-516-TSS-SYSTEM-BOLTED-IN-CORE-SUBROUTINES.pdf 516-63-Display-Controller-Glance-G.pdf 516-65-SOME-DIGITAL-FILTER-APPLICATION-PROGRAMS.pdf 516-66-TSS-516-GE-Communication.pdf 516-67-Node-Format-For-PDP-11.pdf 516-68-DFILE-N-A-Program-for-TSS-516.pdf 516-69-GLANCE-G-COMMUNICATION-FORMAT-TSS-516-TO-SCOPE.pdf 516-70-Routines-to-Perform-Character-String-IO-in-a-FSNAP-Program.pdf 516-71-FSNAP-Debugging-Aids.pdf 516-72-Node-Test.pdf 516-73-Node-IO-Software.pdf 516-75-Display-Text-Editor-DTE.pdf 516-76-LOCAL-DATA-PLOTTING.pdf 516-77-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf 516-77-V2-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf 516-78-DUMP.pdf 516-79-New-File-Features-in-FSNAP.pdf 516-81-OPTION-CHANGING-IN-GPLOT.pdf 516-86-MODIFICATIONS-TO-201-DATAPHONE-SOFTWARE.pdf DDP-516-PROGRAMMERS-REFERENCE-CARD.pdf DDP-516-Instruction-Set-Summary.pdf Index.pdf README From gtaylor at tnetconsulting.net Thu Nov 19 13:06:54 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 18 Nov 2020 20:06:54 -0700 Subject: [TUHS] 516-TSS documents In-Reply-To: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> References: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> Message-ID: <86e3c78e-bd28-7f1e-308d-a2a998e680f1@spamtrap.tnetconsulting.net> On 11/18/20 6:29 PM, Jon Steinhart wrote: > Well, it's a very rainy day and since COVID is keeping me home I > just fed my 516-TSS notebooks into the scanner. It's about 17MB > of stuff. Not sure what to do with it since I don't have a place to > serve it and since they're scanned images they're too big to post. > Here's the list of documents; email me if you're wanting something > in a hurry while the archive stuff is figured out. Note that the > smell of mildew wasn't preserved in the scanning process. Let me know if there is something I can do to help archive / host things. Be that hosting, transferring, something else. There are options. -- 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 silent700 at gmail.com Thu Nov 19 14:54:30 2020 From: silent700 at gmail.com (Jason T) Date: Wed, 18 Nov 2020 22:54:30 -0600 Subject: [TUHS] 516-TSS documents In-Reply-To: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> References: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> Message-ID: On Wed, Nov 18, 2020 at 7:30 PM Jon Steinhart wrote: > > Well, it's a very rainy day and since COVID is keeping me home I just > fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff. > Not sure what to do with it since I don't have a place to serve it and > since they're scanned images they're too big to post. Here's the list > of documents; email me if you're wanting something in a hurry while the > archive stuff is figured out. Note that the smell of mildew wasn't > preserved in the scanning process. Hi Jon - I'd be happy to host them at my site here: http://vtda.org/docs. I'd just need you to suggest the best classification for the docs. I can also OCR them if you have not done so already. -j From ron at ronnatalie.com Thu Nov 19 23:45:13 2020 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 19 Nov 2020 08:45:13 -0500 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: Not only were they embossed on the keys but I believe those control keys moved the cursor in those directions. The Adm 1 and 3 were some of my first terminals. Sent from my iPhone > On Nov 18, 2020, at 19:46, George Michaelson wrote: > > A related but different "thing" is when the cd activity became a > pushdown stack of 2 (is it more? I never bothered checking) > > somebody realised going "there and back again" was innately useful. > > (I will never forget working on systems which had cd-moral-equivalent > and no cd-moral-equivalent but having cd-moral-equivalent > $HOME making all directory traversals downward, or back to your > personal root) > > sorry for thread hijack. > > -G > >> On Thu, Nov 19, 2020 at 8:42 AM Dave Horsfall wrote: >> >>> On Wed, 18 Nov 2020, Clem Cole wrote: >>> >>> In our exchange, someone observed suggested that Joy might have picked >>> it up because the HOME key was part of the tilde key on the ADM3A, which >>> were popular at UCB [i.e. the reason hjkl are the movement keys on vi is >>> the were embossed on the top of those keys on the ADM3A]. It also was >>> noted that the ASR-33 lacks a ~ key on its keyboard. But Lesk >>> definitely needed something to represent a remote user's home directory >>> because each system was different, so he was forced to use something. >> >> The ADM-3A was one of the best terminals ever made. >> >>> It was also noted that there was plenty of cross-pollination going on as >>> students and researchers moved from site to site, so it could have been BTL >>> to UCB, vice-versa, or some other path altogether. >>> >>> So two questions for this august body are: >>> 1. Where did the ~ as $HOME convention come to UNIX? >> >> Gawd... I think I saw it in PWB, but I'm likely wrong. >> >>> 2. Did UNIX create the idiom, or was there an earlier system such as CTSS, >>> TENEX, ITS, MTS, TSS, or the like supported it? >> >> No idea. but given that Unix inherited a lot of stuff.... >> >> -- Dave From imp at bsdimp.com Fri Nov 20 01:50:28 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Nov 2020 08:50:28 -0700 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: On Wed, Nov 18, 2020 at 3:27 PM Clem Cole wrote: > Joy's cshell came out as part of 2BSD (which was V7 based), but he had > released "ashell" before that and included it in the original BSD ( > *a.k.a.* 1BSD) which was for V6 [what I don't remember is if it supported > the convention and I can not easily un-ar(1) the cont.a files in the 1BSD > tar image in Warren's archives. > Looking at the ashell sources on the 1BSD tuhs utree viewer suggests that ~ wasn't there yet, but that it was planned: sh.c: ... Features remaining to be fixed up and/or implemented ======== ========= == == ===== == === == =========== ... * Changes to glob to allow ~, prevent too long path, and prevent * perhaps running out of directories. ... Looking at glob.c, there's no ~ nor 126/176/7e in the sources. Editing the cont.a archive directly confirms no ~ or similar constant is present. By 2BSD, it was in sh.glob.c in the 'expand' function. Later versions define TILDE as '~' and used that. V7 had no ~ in the shell, but as you point out uucp there supported ~ for user home directories. V6 didn't have any of this included that I can find. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Fri Nov 20 02:16:47 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 19 Nov 2020 11:16:47 -0500 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: <6da03a38-0645-f90c-1992-bfc99a51cfc9@case.edu> On 11/18/20 7:44 PM, George Michaelson wrote: > A related but different "thing" is when the cd activity became a > pushdown stack of 2 (is it more? I never bothered checking) > > somebody realised going "there and back again" was innately useful. It was definitely in ksh by 1986. It never made it into any of the Bourne shells, but POSIX adopted it because it was in ksh88. I don't know whether it was in the 1983 ksh version. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From mah at mhorton.net Fri Nov 20 03:22:18 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 19 Nov 2020 09:22:18 -0800 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: Message-ID: <4f9b86c5-57e6-180f-6f07-6995763b07ff@mhorton.net> I first saw ~ as part of csh. Bill had an adm3a at home (which is why HJKL in vi) but there was a variety of terminals at Berkeley. I assumed ~ was Bill's idea.     Mary Ann On 11/18/20 2:25 PM, Clem Cole wrote: > A couple of my friends from UC Berkeley were musing on another email > thread.   The question from one of them came up: /"I'm teaching the > undergrad OS course this semester  ... Mention where ~ comes."/ > > This comment begets a discussion among the 4 of us at where it showed > up in the UNIX heritage and it if was taken from somewhere else. > > Using the tilde character as a short cut for $HOME was purely a > userspace convention and not part of the nami() kernel routine when it > came into being.  We know that it was supported by Mike Lesk in UUCP > and by Bill Joy in cshell.  The former was first widely released as > part of Seventh Edition but was working on V6 before that inside of > BTL.  Joy's cshell came out as part of 2BSD (which was V7 based), but > he had released "ashell" before that and included it in the original > BSD (/a.k.a./ 1BSD) which was for V6 [what I don't remember is if it > supported the convention and I can not easily un-ar(1) the > cont.a files in the 1BSD tar image in Warren's archives. > > In our exchange, someone observed suggested that Joy might have picked > it up because the HOME key was part of the tilde key on the ADM3A, > which were popular at UCB [/i.e./ the reason hjkl are the movement > keys on vi is the were embossed on the top of those keys on the > ADM3A].  It also was noted that the ASR-33 lacks a ~ key on its > keyboard.  But Lesk definitely needed something to represent a remote > user's home directory because each system was different, so he was > forced to use something. > > It was also noted that there was plenty of cross-pollination going on > as students and researchers moved from site to site, so it could have > been BTL to UCB, vice-versa, or some other path altogether. > > So two questions for this august body are: > > 1. Where did the ~ as $HOME convention come to UNIX? > 2. Did UNIX create the idiom, or was there an earlier system such as > CTSS, TENEX, ITS, MTS, TSS, or the like supported it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Nov 20 04:43:51 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 19 Nov 2020 13:43:51 -0500 Subject: [TUHS] Where did the "~" come from In-Reply-To: <4f9b86c5-57e6-180f-6f07-6995763b07ff@mhorton.net> References: <4f9b86c5-57e6-180f-6f07-6995763b07ff@mhorton.net> Message-ID: I had always thought that also until Pressotto pointed out the Lesk had used it for UUCP which was running around Bell before Seventh Edition. But ... given Bill talked about it for shell in his comments, as Warner points out, that would have been before UUCP arrived at UCB -- so I don't think it was from Lesk unless someone like Ken had mentioned it, or he knew about it from another source (such as MTS from which Joy had learned/used as an undergrad before UNIX). As you said, Bill had an ADM3A at home (I had an H19 in those days), but as you knew too well, there were a ton of different terminals at UCB -- whichever was cheapest usually had a run of popularity :-) So the thought HOME keycap = home directory also is quite possible. Of course, Mike and Bill certainly could have come up with it independently but to me, it seems like the chance of both using the same char is really unlikely. IIRC a tilde keycap was on the ASR-37 keyboard but frankly, I don't remember, and can't find a pic of the keyboard detail, plus the LCM+L is closed right now for CV-19 reasons so it's hard to check. On Thu, Nov 19, 2020 at 12:23 PM Mary Ann Horton wrote: > I first saw ~ as part of csh. Bill had an adm3a at home (which is why HJKL > in vi) but there was a variety of terminals at Berkeley. I assumed ~ was > Bill's idea. > > Mary Ann > On 11/18/20 2:25 PM, Clem Cole wrote: > > A couple of my friends from UC Berkeley were musing on another email > thread. The question from one of them came up: *"I'm teaching the > undergrad OS course this semester ... Mention where ~ comes."* > > This comment begets a discussion among the 4 of us at where it showed up > in the UNIX heritage and it if was taken from somewhere else. > > Using the tilde character as a short cut for $HOME was purely a userspace > convention and not part of the nami() kernel routine when it came into > being. We know that it was supported by Mike Lesk in UUCP and by Bill Joy > in cshell. The former was first widely released as part of Seventh Edition > but was working on V6 before that inside of BTL. Joy's cshell came out as > part of 2BSD (which was V7 based), but he had released "ashell" before that > and included it in the original BSD (*a.k.a.* 1BSD) which was for V6 > [what I don't remember is if it supported the convention and I can not > easily un-ar(1) the cont.a files in the 1BSD tar image in Warren's > archives. > > In our exchange, someone observed suggested that Joy might have picked it > up because the HOME key was part of the tilde key on the ADM3A, which were > popular at UCB [*i.e.* the reason hjkl are the movement keys on vi is the > were embossed on the top of those keys on the ADM3A]. It also was noted > that the ASR-33 lacks a ~ key on its keyboard. But Lesk definitely needed > something to represent a remote user's home directory because each system > was different, so he was forced to use something. > > It was also noted that there was plenty of cross-pollination going on as > students and researchers moved from site to site, so it could have been BTL > to UCB, vice-versa, or some other path altogether. > > So two questions for this august body are: > > 1. Where did the ~ as $HOME convention come to UNIX? > 2. Did UNIX create the idiom, or was there an earlier system such as > CTSS, TENEX, ITS, MTS, TSS, or the like supported it? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Fri Nov 20 06:02:51 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 19 Nov 2020 20:02:51 +0000 Subject: [TUHS] Where did the "~" come from In-Reply-To: References: <4f9b86c5-57e6-180f-6f07-6995763b07ff@mhorton.net> Message-ID: On 19 Nov 2020 13:43 -0500, from clemc at ccc.com (Clem Cole): > IIRC a tilde keycap was on the ASR-37 keyboard > but frankly, I don't remember, and can't find a pic of the keyboard detail, > plus the LCM+L is closed right now for CV-19 reasons so it's hard to check. http://www.navy-radio.com/manuals-ttycorp.htm#m37 has a copy of "37 KEYBOARD SEND-RECEIVE (KSR) TELETYPEWRITER SET AND 37 AUTOMATIC SEND-RECEIVE (ASR) TELETYPEWRITER SET FOR "DATA-PHONE®" SERVICE GENERAL DESCRIPTION AND OPERATION", issue 1, dated June 1971 which on page 7 has a keyboard layout diagram. It looks to me like the second right, topmost key, at least on the illustrated layout, came with ^ ~ RS. Also 574-321-800TC, "37 Keyboard (YK) and Base (YB) Parts" (issue 1, December 1967, linked from that same page), page 9 indicates that for this you'd want key cap part number 314843, which is listed as ~ RS ^. Judging by that same page, it looks like P/N 313040 might also apply. This isn't as good as an in-person look at an actual unit, of course, but it definitely looks like you at least could have a key cap with a tilde on the 37. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From gnu at toad.com Fri Nov 20 08:54:05 2020 From: gnu at toad.com (John Gilmore) Date: Thu, 19 Nov 2020 14:54:05 -0800 Subject: [TUHS] UNIX NEWS and ; login: archives, particularly from 1975-1978 Message-ID: <1837.1605826445@hop.toad.com> While cleaning up a few shelves of old USENIX proceedings, I found a mysterious manila envelope full of xeroxed copies of all the original UNIX NEWS newsletters from 1975 thru 1977. It was renamed to ;login: in 1977 and has continued publication to this day. The envelope also contained ;login: issues v2n6 thru v3n8 (1977-1978). I scanned those all in today and put them up on my website, here: http://www.toad.com/early-usenix-newsletters/ These have not been OCR'd, and many of the pages were rotated by 90 degrees in the original publication, to fit two pages of typewritten correspondence (or recipient address lists) into one page of newsletter. Still, in a quick web search I was unable to find copies of these anywhere else, so I invested a few hours to scan them in and post them for historical interest. As an example, Sixth Edition (v6) UNIX was announced in issue number 1. These are all free to publish nowadays. USENIX was one of the first technical organizations to establish an Open Access policy for its publications, a step which distinguishes them from ACM and many academic publishers who favor revenue for themselves over the progress of science. (I voted for this policy decades ago when I was a USENIX board member.) This page, for example, says: https://www.usenix.org/conference/usenixsecurity20/presentation/schwarz "USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone." The ;login: archives at USENIX.org are complete from October 1997 to today: https://www.usenix.org/publications/login Also, most but not all issues of ;login: from 1983 to 1997 have been scanned by USENIX and uploaded to the Internet Archive here: https://archive.org/details/usenix-login?&sort=date The USENIX Association apparently has paper copies of the stuff I scanned in today, but they are still trying to locate ;login: issues from 1979 and parts of 1980 and 1981. In addition, they are backlogged on scanning in their old materials (including copies of ;login: between 1978/09 and 1983/02). If you have old copies of ;login: that you don't see visible in these places, please scan them, or offer them to USENIX. Also, if you have old proceedings of USENIX conferences, there are still three that the USENIX staff do not have any copy of: XFree86 Technical Conference https://www.usenix.org/legacy/publications/library/proceedings/xfree86/ 2001-11-08 5th Annual Linux Showcase & Conference https://www.usenix.org/legacy/publications/library/proceedings/als01/tech.html 2001-11-08 WORLDS '04 https://www.usenix.org/legacy/events/worlds04/tech/ 2004-12-05 If you have any of these three, please let know. They also lack about twenty more for which they have posted the academic papers, but don't have the covers or front-matter, so if you have other proceedings from between 1989 and 2004 that you'd be willing to part with or scan, also let them know. Thanks! John From mah at mhorton.net Sat Nov 21 03:14:02 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Fri, 20 Nov 2020 09:14:02 -0800 Subject: [TUHS] UNIX NEWS and ; login: archives, particularly from 1975-1978 In-Reply-To: <1837.1605826445@hop.toad.com> References: <1837.1605826445@hop.toad.com> Message-ID: John, Does Usenix have online proceedings of the technical conferences from the 1980s?  I can't find them. Thanks,     Mary Ann On 11/19/20 2:54 PM, John Gilmore wrote: > While cleaning up a few shelves of old USENIX proceedings, I found a > mysterious manila envelope full of xeroxed copies of all the original > UNIX NEWS newsletters from 1975 thru 1977. It was renamed to ;login: > in 1977 and has continued publication to this day. The envelope also > contained ;login: issues v2n6 thru v3n8 (1977-1978). > > I scanned those all in today and put them up on my website, here: > > http://www.toad.com/early-usenix-newsletters/ > > These have not been OCR'd, and many of the pages were rotated by 90 > degrees in the original publication, to fit two pages of typewritten > correspondence (or recipient address lists) into one page of newsletter. > Still, in a quick web search I was unable to find copies of these > anywhere else, so I invested a few hours to scan them in and post them > for historical interest. As an example, Sixth Edition (v6) UNIX was > announced in issue number 1. > > These are all free to publish nowadays. USENIX was one of the first > technical organizations to establish an Open Access policy for its > publications, a step which distinguishes them from ACM and many academic > publishers who favor revenue for themselves over the progress of > science. (I voted for this policy decades ago when I was a USENIX board > member.) This page, for example, says: > > https://www.usenix.org/conference/usenixsecurity20/presentation/schwarz > > "USENIX is committed to Open Access to the research presented at our > events. Papers and proceedings are freely available to everyone once > the event begins. Any video, audio, and/or slides that are posted > after the event are also free and open to everyone." > > The ;login: archives at USENIX.org are complete from October 1997 to today: > > https://www.usenix.org/publications/login > > Also, most but not all issues of ;login: from 1983 to 1997 have been > scanned by USENIX and uploaded to the Internet Archive here: > > https://archive.org/details/usenix-login?&sort=date > > The USENIX Association apparently has paper copies of the stuff I > scanned in today, but they are still trying to locate ;login: issues > from 1979 and parts of 1980 and 1981. In addition, they are backlogged > on scanning in their old materials (including copies of ;login: between > 1978/09 and 1983/02). If you have old copies of ;login: that you don't > see visible in these places, please scan them, or offer them to USENIX. > > Also, if you have old proceedings of USENIX conferences, there are still > three that the USENIX staff do not have any copy of: > > XFree86 Technical Conference > https://www.usenix.org/legacy/publications/library/proceedings/xfree86/ > 2001-11-08 > > 5th Annual Linux Showcase & Conference > https://www.usenix.org/legacy/publications/library/proceedings/als01/tech.html > 2001-11-08 > > WORLDS '04 > https://www.usenix.org/legacy/events/worlds04/tech/ > 2004-12-05 > > If you have any of these three, please let know. They > also lack about twenty more for which they have posted the academic > papers, but don't have the covers or front-matter, so if you have other > proceedings from between 1989 and 2004 that you'd be willing to part > with or scan, also let them know. Thanks! > > John > From clemc at ccc.com Sat Nov 21 03:28:23 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Nov 2020 12:28:23 -0500 Subject: [TUHS] UNIX NEWS and ; login: archives, particularly from 1975-1978 In-Reply-To: References: <1837.1605826445@hop.toad.com> Message-ID: Some, the original ones that were printed and bound have not been scanned. The directory: Publications is where to start. Some of the paper are online after scanning on a case by case basis. Talk to Casey if there is a specific request, although since the Berkeley office is going to close in about 2 weeks, I don't expect they can do much for a bit. FYI: The last printed edition of *;login* went to bed last week and I believe mailed shortly thereafter. It will be electronic from now on. Clem On Fri, Nov 20, 2020 at 12:15 PM Mary Ann Horton wrote: > John, > > Does Usenix have online proceedings of the technical conferences from > the 1980s? I can't find them. > > Thanks, > > Mary Ann > > On 11/19/20 2:54 PM, John Gilmore wrote: > > While cleaning up a few shelves of old USENIX proceedings, I found a > > mysterious manila envelope full of xeroxed copies of all the original > > UNIX NEWS newsletters from 1975 thru 1977. It was renamed to ;login: > > in 1977 and has continued publication to this day. The envelope also > > contained ;login: issues v2n6 thru v3n8 (1977-1978). > > > > I scanned those all in today and put them up on my website, here: > > > > http://www.toad.com/early-usenix-newsletters/ > > > > These have not been OCR'd, and many of the pages were rotated by 90 > > degrees in the original publication, to fit two pages of typewritten > > correspondence (or recipient address lists) into one page of newsletter. > > Still, in a quick web search I was unable to find copies of these > > anywhere else, so I invested a few hours to scan them in and post them > > for historical interest. As an example, Sixth Edition (v6) UNIX was > > announced in issue number 1. > > > > These are all free to publish nowadays. USENIX was one of the first > > technical organizations to establish an Open Access policy for its > > publications, a step which distinguishes them from ACM and many academic > > publishers who favor revenue for themselves over the progress of > > science. (I voted for this policy decades ago when I was a USENIX board > > member.) This page, for example, says: > > > > > https://www.usenix.org/conference/usenixsecurity20/presentation/schwarz > > > > "USENIX is committed to Open Access to the research presented at our > > events. Papers and proceedings are freely available to everyone once > > the event begins. Any video, audio, and/or slides that are posted > > after the event are also free and open to everyone." > > > > The ;login: archives at USENIX.org are complete from October 1997 to > today: > > > > https://www.usenix.org/publications/login > > > > Also, most but not all issues of ;login: from 1983 to 1997 have been > > scanned by USENIX and uploaded to the Internet Archive here: > > > > https://archive.org/details/usenix-login?&sort=date > > > > The USENIX Association apparently has paper copies of the stuff I > > scanned in today, but they are still trying to locate ;login: issues > > from 1979 and parts of 1980 and 1981. In addition, they are backlogged > > on scanning in their old materials (including copies of ;login: between > > 1978/09 and 1983/02). If you have old copies of ;login: that you don't > > see visible in these places, please scan them, or offer them to USENIX. > > > > Also, if you have old proceedings of USENIX conferences, there are still > > three that the USENIX staff do not have any copy of: > > > > XFree86 Technical Conference > > > https://www.usenix.org/legacy/publications/library/proceedings/xfree86/ > > 2001-11-08 > > > > 5th Annual Linux Showcase & Conference > > > https://www.usenix.org/legacy/publications/library/proceedings/als01/tech.html > > 2001-11-08 > > > > WORLDS '04 > > https://www.usenix.org/legacy/events/worlds04/tech/ > > 2004-12-05 > > > > If you have any of these three, please let know. They > > also lack about twenty more for which they have posted the academic > > papers, but don't have the covers or front-matter, so if you have other > > proceedings from between 1989 and 2004 that you'd be willing to part > > with or scan, also let them know. Thanks! > > > > John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sat Nov 21 07:32:34 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 20 Nov 2020 16:32:34 -0500 Subject: [TUHS] Package Management Message-ID: Hello All, I know I have asked this before, but I am curious about any new replies or insight. How did package management start? Were sites keeping track of packages installed in a flat file that you could grep (as god intended) somewhere, or were upgrades and additions simply done without significant announcement? At what point did someone decide, 'Hey, we need to have a central way to track additional software"? I know of DEC's setld and SGI's inst in the latter half of the '80s. What was the mechanism before that? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Nov 21 10:27:42 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 20 Nov 2020 17:27:42 -0700 Subject: [TUHS] UNIX NEWS and ; login: archives, particularly from 1975-1978 In-Reply-To: <1837.1605826445@hop.toad.com> References: <1837.1605826445@hop.toad.com> Message-ID: Thanks for doing this John.... On Thu, Nov 19, 2020 at 4:06 PM John Gilmore wrote: > While cleaning up a few shelves of old USENIX proceedings, I found a > mysterious manila envelope full of xeroxed copies of all the original > UNIX NEWS newsletters from 1975 thru 1977. It was renamed to ;login: > in 1977 and has continued publication to this day. The envelope also > contained ;login: issues v2n6 thru v3n8 (1977-1978). > > I scanned those all in today and put them up on my website, here: > > http://www.toad.com/early-usenix-newsletters/ I've started to recover the text from the special edition, if anybody is interested. It's so badly faded, though, this may take some time... Warner > > These have not been OCR'd, and many of the pages were rotated by 90 > degrees in the original publication, to fit two pages of typewritten > correspondence (or recipient address lists) into one page of newsletter. > Still, in a quick web search I was unable to find copies of these > anywhere else, so I invested a few hours to scan them in and post them > for historical interest. As an example, Sixth Edition (v6) UNIX was > announced in issue number 1. > > These are all free to publish nowadays. USENIX was one of the first > technical organizations to establish an Open Access policy for its > publications, a step which distinguishes them from ACM and many academic > publishers who favor revenue for themselves over the progress of > science. (I voted for this policy decades ago when I was a USENIX board > member.) This page, for example, says: > > https://www.usenix.org/conference/usenixsecurity20/presentation/schwarz > > "USENIX is committed to Open Access to the research presented at our > events. Papers and proceedings are freely available to everyone once > the event begins. Any video, audio, and/or slides that are posted > after the event are also free and open to everyone." > > The ;login: archives at USENIX.org are complete from October 1997 to today: > > https://www.usenix.org/publications/login > > Also, most but not all issues of ;login: from 1983 to 1997 have been > scanned by USENIX and uploaded to the Internet Archive here: > > https://archive.org/details/usenix-login?&sort=date > > The USENIX Association apparently has paper copies of the stuff I > scanned in today, but they are still trying to locate ;login: issues > from 1979 and parts of 1980 and 1981. In addition, they are backlogged > on scanning in their old materials (including copies of ;login: between > 1978/09 and 1983/02). If you have old copies of ;login: that you don't > see visible in these places, please scan them, or offer them to USENIX. > > Also, if you have old proceedings of USENIX conferences, there are still > three that the USENIX staff do not have any copy of: > > XFree86 Technical Conference > https://www.usenix.org/legacy/publications/library/proceedings/xfree86/ > 2001-11-08 > > 5th Annual Linux Showcase & Conference > > https://www.usenix.org/legacy/publications/library/proceedings/als01/tech.html > 2001-11-08 > > WORLDS '04 > https://www.usenix.org/legacy/events/worlds04/tech/ > 2004-12-05 > > If you have any of these three, please let know. They > also lack about twenty more for which they have posted the academic > papers, but don't have the covers or front-matter, so if you have other > proceedings from between 1989 and 2004 that you'd be willing to part > with or scan, also let them know. Thanks! > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Sat Nov 21 10:55:53 2020 From: reed at reedmedia.net (Jeremy C. Reed) Date: Fri, 20 Nov 2020 18:55:53 -0600 (CST) Subject: [TUHS] Package Management In-Reply-To: References: Message-ID: See The SPMS Software Project Management System documented in the new/spms for 4.3BSD http://www.retro11.de/ouxr/43bsd/usr/src/new/spms/doc/ (I couldn't find link to this at TUHS.) I don't know about it but maybe that will help From arnold at skeeve.com Sun Nov 22 03:50:47 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 21 Nov 2020 10:50:47 -0700 Subject: [TUHS] Package Management In-Reply-To: References: Message-ID: <202011211750.0ALHolUI011814@freefriends.org> Things were pretty much ad hoc. Commercial software likely came as tar/cpio tapes to install however the vendor wanted. Free software was from USENET in source code, so again, however people wanted. The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format for installing software from floppy and tracked what was installed, but that was unique to it. Package managers as we know them today really became a big thing with Linux. Redhat's RPM was one of the earliest. My two cents; I'm sure others remember it differently. Arnold Henry Bent wrote: > Hello All, > > I know I have asked this before, but I am curious about any new replies or > insight. How did package management start? Were sites keeping track of > packages installed in a flat file that you could grep (as god intended) > somewhere, or were upgrades and additions simply done without significant > announcement? At what point did someone decide, 'Hey, we need to have a > central way to track additional software"? > > I know of DEC's setld and SGI's inst in the latter half of the '80s. What > was the mechanism before that? > > -Henry From wkt at tuhs.org Sun Nov 22 06:53:12 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 22 Nov 2020 06:53:12 +1000 Subject: [TUHS] UNIX NEWS and ; login: archives, particularly from 1975-1978 In-Reply-To: <1837.1605826445@hop.toad.com> References: <1837.1605826445@hop.toad.com> Message-ID: <20201121205312.GA7185@minnie.tuhs.org> On Thu, Nov 19, 2020 at 02:54:05PM -0800, John Gilmore wrote: > While cleaning up a few shelves of old USENIX proceedings, I found a > mysterious manila envelope full of xeroxed copies of all the original > UNIX NEWS newsletters from 1975 thru 1977. It was renamed to ;login: > in 1977 and has continued publication to this day. The envelope also > contained ;login: issues v2n6 thru v3n8 (1977-1978). > > I scanned those all in today and put them up on my website, here: > > http://www.toad.com/early-usenix-newsletters/ I've copied these into the Unix Archive here, with attributions to John: https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/ Thanks so much for finding and scanning them in, John! Cheers, Warren From clemc at ccc.com Sun Nov 22 08:23:45 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Nov 2020 17:23:45 -0500 Subject: [TUHS] Package Management In-Reply-To: References: Message-ID: On Fri, Nov 20, 2020 at 4:33 PM Henry Bent wrote: > I know I have asked this before, but I am curious about any new replies or > insight. How did package management start? > Really good question. I thought the PKG_ADD we had on Masscomp in '83 was grabbed from PWB 3.0. Unfortunately, Warren's stuff does not include, but that is known to missing things (like SCCS which was first distributed as part of PWB 1.0 and every version after). So here is what I remember ... When we did the '85 /usr/group standard, one of the things we argued about was how would an ISV >>deliver<< a binary *I.e.* 'interchange' between two systems to use the TOPS-10/TOPS-20 terminology (which is actually what we were using since most of us were familiar with same). By the time we got to IEEE P1003, the whole reason USTAR was created was to solve that - which begat the famous Tar Wars of the Research (TAR format) *vs*. CPIO (AT&T) types [USTAR was a compromise and as I have said previously, was picked due to the code in Ken's original implementation of the header CKSUM so it had an unintended extension mechanism and as ASCII - cpio was binary in those days AND could not be extended so older readers could at least read a new tape). The 'install' was left to each ISV and the assumption had been you would use a USTAR tape (and eventually the PAX program) to read the bits, but each ISV did their own 'installer.' The idea of keeping a system-wide DB on what was installed was still in the future. PWB 3.0/System III PKG_ADD was primitive, but my memory is it was the first attempt. I do remember it was on a number of System III based systems but was very much tied to installing the AT&T supplied SW - which I suspect was leftover from the AT&T external maneuver of trying to supply everything and was difficult to use by ISVs and I don't remember many doing so. As you point out, the first commercial UNIX I remember that really tried to solve it, was Ultrix which had something for both their own use and for their ISV's (setld) - which frankly sucked and I personally hated and railed against. But to DEC's credit, it was there. It was modeled after a similar tool for VMS. Truth is, for a while it was the best. The biggest thing that setld did (which in practice it did poorly) was trying to keep a DB of what you installed so that an admin could type a command and see what had been loaded, and when and also what licenses were installed to run purchased software. Basically, it was driven by field service and SW licensing. When FreeBSD 1.0 came out, the big thing Jordan Hubbard did (and was much better than Linux installs for a long time) was work on install >>for a new system<<. He also created the idea of 'packages' which were all of the thousands of UNIX tools that people had ported to FreeBSD and could optionally be installed. I think it really was the first of the same name and most of the features we know. By today's measure, again it was crude, my memory is that unlike setld, since it was not managing licenses, he didn't think to add a DB/log of what was being installed. He did not try to solve the 'update' problem when a new version of FreeBSD was released BTW. Basically, you needed to do a new install. Roll forward a couple of years and Linux eventually picked up Jordan's basic installer framework which vastly improved the out-of-box for some of the Linux distros. But the important thing that RH did beyond FreeBSD was to create RPM, which added a setld like DB to the scheme, not for licenses, but so that you could easily do updates, add options, etc. They combined Jordans install ideas and packages ideas, which was cool for a system where you got/get everything from the distro. The truth is, none of the Research UNIX, FreeBSD nor Linux really put the effort that DEC, Masscomp, Sun, IBM, HP did in how to update a system. *i.e.* I'm currently running version 10.13.5 and I want to get to 10.14.2 -- what needs to be installed and how will it affect already installed and running ISV codes. [ IMO Microsoft is the worst and Apple is not much better]. Linux is a weird one. Because of the 'open source' thinking, the idea of keeping old binaries running is not the high order bit. DEC, IBM, HP, Masscomp, and to some extent SUN and SGI, because they had a market for commercial SW, have tried to keep old binaries going. So ... now we have apt-get - which for what it is, works pretty well but, it still does not solve a problem someone like my firm has that sells commercial SW. FWIW: Since I actually wrote the spec for it inside Intel, I can tell you what the design/goal/direction to tell the install teams in that my employer distributes using RPM and >>is suppose<< to work unmodified with an RPM-based install (*i.e.* be 'socially compliant' to the norms of a more commercial-like Linux site). The >>idea<< is that the RPMs are supposed to be able to automatically converted to Yum and a few other formats (check the specs here for each tool, however -- this is not a warranty from me - YMMV -- just telling what I >>personal<< scream at the team when I discover they did not test properly as sometimes they do break that - which can cause big issues when trying to install on a supercomputer). The >>idea<< is that the current generation of package tools, like setld of yesterday, will allow the admin to what's running on the local system. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Nov 22 09:24:51 2020 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 22 Nov 2020 10:24:51 +1100 Subject: [TUHS] Package Management In-Reply-To: References: Message-ID: <20201121232448.mwxq4kjjvpth4c4b@localhost.localdomain> At 2020-11-21T17:23:45-0500, Clem Cole wrote: > Roll forward a couple of years and Linux eventually picked up Jordan's > basic installer framework which vastly improved the out-of-box for > some of the Linux distros. But the important thing that RH did beyond > FreeBSD was to create RPM, which added a setld like DB to the scheme, > not for licenses, but so that you could easily do updates, add > options, etc. They combined Jordans install ideas and packages ideas, > which was cool for a system where you got/get everything from the > distro. The complete lack of mention of dpkg and the Debian package format is an error in your narrative. According to rpm.org, the "first commit" to the rpm package management software was on November 27, 1995[1]. By this time, dpkg had already been around for over a year; you can find Ian Jackson's release announcement of dpkg 0.93.63 in July 1995[2], and dpkg's own "ChangeLog.old" file in its source tree documents its history back to August 1994. > So ... now we have apt-get - which for what it is, works pretty well > but, it still does not solve a problem someone like my firm has that > sells commercial SW. It is worth noting that apt also originated in Debian, largely developed by Jason Gunthorpe but originally uploaded by Scott Ellis in April 1998[3]. Despite apt's popularity and obvious technical advantages in upgrade management (a cycle-breaking dependency analyzer)--it drew grudging admiration even from many in the community who abhorred uttering the words "Debian", "GNU/Linux", or both--and a deliberately package-format-agnostic architecture, RPM-based distributions resisted adopting it for years until Conectiva, a commercial distribution from Brazil, wrote the requisite back-end for rpm support (apt-rpm)[4]. > FWIW: Since I actually wrote the spec for it inside Intel, I can tell > you what the design/goal/direction to tell the install teams in that > my employer distributes using RPM and >>is suppose<< to work > unmodified with an RPM-based install (*i.e.* be 'socially compliant' > to the norms of a more commercial-like Linux site). The >>idea<< is > that the RPMs are supposed to be able to automatically converted to > Yum and a few other formats (check the specs here for each tool, > however -- this is not a warranty from me - YMMV -- just telling what > I >>personal<< scream at the team when I discover they did not test > properly as sometimes they do break that - which can cause big issues > when trying to install on a supercomputer). These norms tend to be distribution-specific. Even where technology is the same, the norms that produce integration can differ. Little about Unix kernels prescribes any particular filesystem hierarchy, for instance. It has often been observed that what quality the Debian system enjoys is less due to its technological advantages--though IMO these are clear in package format (deb), source package format (dsc) and administration tools--but in Debian's culture of writing prescriptions for a consistent system configuration in its Policy Manual[5], of maintaining automated checking tools for compliance with those prescriptions[6][7], and of being willing to gate releases on the lack of such compliance. The last used to be a point of emphatic derision by rival distributions, most of which were funded by venture capital and thus motivated to emphasize cadence over technical quality, the former property being more easily measured by non-specialists, deep-pocketed and otherwise. Regards, Branden [1] https://rpm.org/timeline.html [2] https://lists.debian.org/debian-devel/1995/07/msg00009.html [3] https://lists.debian.org/debian-devel-changes/1998/04/msg00140.html [4] https://lwn.net/Articles/30728/ [5] https://www.debian.org/doc/debian-policy/ [6] https://lintian.debian.org/ [7] https://piuparts.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gregg.drwho8 at gmail.com Sun Nov 22 09:30:45 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Sat, 21 Nov 2020 18:30:45 -0500 Subject: [TUHS] Package Management In-Reply-To: <202011211750.0ALHolUI011814@freefriends.org> References: <202011211750.0ALHolUI011814@freefriends.org> Message-ID: Hello! I, myself normally run Slackware Linux. It uses package management in the form of compressed tar files, and a flat file store of the names. It also has a tool which when run will show the user what's there, and what they do if need be. In fact Slackware predates Red Hat by about four years. (Pat and his CS professor introduced themselves to one much earlier one, which was SLS. Neither liked it, and the Prof was convinced that Pat could do better.) ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sat, Nov 21, 2020 at 1:54 PM wrote: > > Things were pretty much ad hoc. Commercial software likely came > as tar/cpio tapes to install however the vendor wanted. Free software > was from USENET in source code, so again, however people wanted. > > The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format > for installing software from floppy and tracked what was installed, > but that was unique to it. > > Package managers as we know them today really became a big thing > with Linux. Redhat's RPM was one of the earliest. > > My two cents; I'm sure others remember it differently. > > Arnold > > Henry Bent wrote: > > > Hello All, > > > > I know I have asked this before, but I am curious about any new replies or > > insight. How did package management start? Were sites keeping track of > > packages installed in a flat file that you could grep (as god intended) > > somewhere, or were upgrades and additions simply done without significant > > announcement? At what point did someone decide, 'Hey, we need to have a > > central way to track additional software"? > > > > I know of DEC's setld and SGI's inst in the latter half of the '80s. What > > was the mechanism before that? > > > > -Henry > From clemc at ccc.com Sun Nov 22 11:17:53 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Nov 2020 20:17:53 -0500 Subject: [TUHS] Package Management In-Reply-To: References: <202011211750.0ALHolUI011814@freefriends.org> Message-ID: 1) No intention to slight debian in any way. 2) dpkg was definitely an improvement over FreeBSds ports scheme. But... In fact freebsd did have a pkg system for ports before that --- which was basically similar to 1983 SysIII scheme 3) also as I understand (and larry feel free to correct me here as a better chronicler of things Linux than I) but I believe that the big thing rpm added was the DB like DEC's setld and system Sun had used which us what I was refering too. Pls remember that I was trying to chronicle the basic ideas and some of the motivation which is what Henry asked. And that the original driver was to support ISVs installs. So I was trying to explain the history of what we did at the time. The be fair one of the more vocal people in the early 80s was Heinz who occasionally add color here. I remember Heinz trying to push us to an ABI and not stop at an API. Today most of the ISVs have abandoned Unix except for the Mac. Msft and the phones have taken that. And the package mngr has been replaced by the app store which has.much great use than any of the current Unix packaging schemes. Funny how the profit motive drove that. Working for one of the few ISVS that do package SW for Unix we basically support two schemes. Apple Mac installs and RPM because that is were the primary customer base has been. I'd not about goodness or being better or being first. It's economic (Larry and I bemoan this a lot). So pls don't take it as a comment about anything other than trying to answer as much of the early history as I could. Heinz, Jon, Larry you all lived this on the commercial side. Care to add anything? Clem On Sat, Nov 21, 2020 at 6:31 PM Gregg Levine wrote: > Hello! > I, myself normally run Slackware Linux. It uses package management in > the form of compressed tar files, and a flat file store of the names. > It also has a tool which when run will show the user what's there, and > what they do if need be. In fact Slackware predates Red Hat by about > four years. (Pat and his CS professor introduced themselves to one > much earlier one, which was SLS. Neither liked it, and the Prof was > convinced that Pat could do better.) > ----- > Gregg C Levine gregg.drwho8 at gmail.com > "This signature fought the Time Wars, time and again." > > On Sat, Nov 21, 2020 at 1:54 PM wrote: > > > > Things were pretty much ad hoc. Commercial software likely came > > as tar/cpio tapes to install however the vendor wanted. Free software > > was from USENET in source code, so again, however people wanted. > > > > The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format > > for installing software from floppy and tracked what was installed, > > but that was unique to it. > > > > Package managers as we know them today really became a big thing > > with Linux. Redhat's RPM was one of the earliest. > > > > My two cents; I'm sure others remember it differently. > > > > Arnold > > > > Henry Bent wrote: > > > > > Hello All, > > > > > > I know I have asked this before, but I am curious about any new > replies or > > > insight. How did package management start? Were sites keeping track > of > > > packages installed in a flat file that you could grep (as god intended) > > > somewhere, or were upgrades and additions simply done without > significant > > > announcement? At what point did someone decide, 'Hey, we need to have > a > > > central way to track additional software"? > > > > > > I know of DEC's setld and SGI's inst in the latter half of the '80s. > What > > > was the mechanism before that? > > > > > > -Henry > > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Nov 22 11:39:08 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 21 Nov 2020 18:39:08 -0700 Subject: [TUHS] Package Management In-Reply-To: References: <202011211750.0ALHolUI011814@freefriends.org> Message-ID: On Sat, Nov 21, 2020, 6:19 PM Clem Cole wrote: > 1) No intention to slight debian in any way. > 2) dpkg was definitely an improvement over FreeBSds ports scheme. But... > In fact freebsd did have a pkg system for ports before that --- which was > basically similar to 1983 SysIII scheme > FreeBSD's ports/pkg system did keep track of what was installed on the system. There was a database in /var/db so pkg_delete could remove things and pkg_which to know what pkg a given file belonged to. It was first-ish, but there was some package system for the early linux root disks. I think this is how SLS started, but I might be misremembering. But despite being early, and being ported to other BSDs, it sucked at upgrading for 20-odd years until it was completely rewritten.... latter day pkg is so much better, though its repo management has been a little weak relative to the professional efforts in the linux world. /usr/ports none the less was ground breaking because it handled both the local patching, the build depends and the packaging under one umbrella. It's been on the whole a good thing and has reinvented itself several times over the years. When I was managing SunOS systems it seemed like everyone rolled their own. There was nothing like VMSINSTALL... Warner 3) also as I understand (and larry feel free to correct me here as a better > chronicler of things Linux than I) but I believe that the big thing rpm > added was the DB like DEC's setld and system Sun had used which us what I > was refering too. > > Pls remember that I was trying to chronicle the basic ideas and some of > the motivation which is what Henry asked. And that the original driver > was to support ISVs installs. So I was trying to explain the history of > what we did at the time. > > The be fair one of the more vocal people in the early 80s was Heinz who > occasionally add color here. I remember Heinz trying to push us to an ABI > and not stop at an API. > > Today most of the ISVs have abandoned Unix except for the Mac. Msft and > the phones have taken that. And the package mngr has been replaced by the > app store which has.much great use than any of the current Unix packaging > schemes. Funny how the profit motive drove that. > > Working for one of the few ISVS that do package SW for Unix we basically > support two schemes. Apple Mac installs and RPM because that is were the > primary customer base has been. I'd not about goodness or being better or > being first. It's economic (Larry and I bemoan this a lot). > > So pls don't take it as a comment about anything other than trying to > answer as much of the early history as I could. > > Heinz, Jon, Larry you all lived this on the commercial side. Care to add > anything? > > Clem > > On Sat, Nov 21, 2020 at 6:31 PM Gregg Levine > wrote: > >> Hello! >> I, myself normally run Slackware Linux. It uses package management in >> the form of compressed tar files, and a flat file store of the names. >> It also has a tool which when run will show the user what's there, and >> what they do if need be. In fact Slackware predates Red Hat by about >> four years. (Pat and his CS professor introduced themselves to one >> much earlier one, which was SLS. Neither liked it, and the Prof was >> convinced that Pat could do better.) >> ----- >> Gregg C Levine gregg.drwho8 at gmail.com >> "This signature fought the Time Wars, time and again." >> >> On Sat, Nov 21, 2020 at 1:54 PM wrote: >> > >> > Things were pretty much ad hoc. Commercial software likely came >> > as tar/cpio tapes to install however the vendor wanted. Free software >> > was from USENET in source code, so again, however people wanted. >> > >> > The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format >> > for installing software from floppy and tracked what was installed, >> > but that was unique to it. >> > >> > Package managers as we know them today really became a big thing >> > with Linux. Redhat's RPM was one of the earliest. >> > >> > My two cents; I'm sure others remember it differently. >> > >> > Arnold >> > >> > Henry Bent wrote: >> > >> > > Hello All, >> > > >> > > I know I have asked this before, but I am curious about any new >> replies or >> > > insight. How did package management start? Were sites keeping track >> of >> > > packages installed in a flat file that you could grep (as god >> intended) >> > > somewhere, or were upgrades and additions simply done without >> significant >> > > announcement? At what point did someone decide, 'Hey, we need to >> have a >> > > central way to track additional software"? >> > > >> > > I know of DEC's setld and SGI's inst in the latter half of the '80s. >> What >> > > was the mechanism before that? >> > > >> > > -Henry >> > >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Nov 23 10:16:06 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 22 Nov 2020 16:16:06 -0800 Subject: [TUHS] 516-TSS Documents Message-ID: <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> These are in Warren's hands now and he'll let us know where their permanent home ends up being. Since these are pretty much uncirculated unlike the UNIX documents I wrote a README to go along with them which Heinz reviewed so it's the best that two aging sets of memories can do. Here it is: - - - 516-TSS is a little-known but groundbreaking and influential operating system that was developed at Bell Telephone Laboratories. I came across this system because Carl Christensen and later Heinz Lycklama were major contributors to it, and they were also advisors for the Bell Labs Explorer Scout Post at Murray Hill. I was a member of that post which allowed us to play with computers on Monday evenings, and 516-TSS was what most of us used. Through a series of amazingly lucky events, I ended up working as a summer student for Carl and Heinz and got to contribute to the system. Long before the term "code spelunking" was coined Carl and Heinz taught us both code and spelunking. This is not a complete set of 516-TSS documents, it's a couple of notebooks that I found in a box in the basement. Probably my ancient work-at-home copy. I don't know enough history to know if it was the first, but 516-TSS was an early department-level time-sharing system. It was built around a Honeywell DDP-516. While other time-sharing systems predate 516-TSS, they weren't systems that one's department could afford. CTSS certainly came earlier, but it used a monster IBM 7090 mainframe. In round numbers, a 7090 cost $3,000,000 dollars, a DDP-516 cost $50,000. 516-TSS was also a virtual memory system; again not the first but a rarity in that era. My recollection is that it used the 516's index register as the base address register, and there was some complicated mucking around that a program had to do if it needed to use the index register including disabling interrupts and eventually restoring the register from .PRESB (present base address), one of those weird things stuck in my memory from long ago. I believe that the system's development predated UNIX although I remember our department getting a PDP-11/45 running UNIX Version 3 in the summer of 1973. This machine was acquired so that Doug Bayer and Heinz Lycklama could develop the MERT operating system. The 516 was a testbed for a lot of novel technologies. It had a local area network called the ring which was later made to work on PDP-11s including Ken and Dennis's machine up in the attic of building 2. It was also used to develop the GLANCE graphics terminals. My recollection is that one of the main drivers behind getting the ring to work on PDP-11s and UNIX was so that Ken could get a GLANCE-G terminal for playing chess. Sandy Fraser's Spider network was developed there. It supported a number of novel applications including Dick Hause's DTE graphics editor; way ahead of its time. I remember that one GLANCE terminal was fitted with an array of LEDs and photodiodes to make an early version of a touch screen. While it wasn't exactly work related, a number of the people in the department had purchased property up in Vermont for ski cabins. An important use of the 516-TSS system and GLANCE-G terminals was to figure out survey closures. The property surveys were ancient, of the "from the big rock to the left of the tree that's no longer there" sorts of things, so figuring out the actual property lines was an interesting problem. The 516 also had a wide area network which consisted of picking up the phone and calling the computer center. It had a monster GE-635 or maybe 645 left over from the Multics project. It may have been renamed to be a Honeywell 6070 with Honeywell's acquisition of GE's computer business. The computer center kept department costs down by hoarding all of the really expensive peripherals. For example, we didn't have a card punch; that was effectively done via remote job entry. We didn't have a graphics printer either, so when I was working on GPLOT I'd submit remote jobs to the computer center for printing. Matter of fact, I don't think that we even had a printer in our department; we sent stuff up to the computer center for printing. Although, in those days many terminals used paper. The 516 console was an ASR-33. There was also the ability to send jobs to the computer center and have it call back with results. This early approach to a WAN showed up as the tss command in UNIX. One of the missions of the department was the development of an all-digital telephone exchange which is why some of the documents describe programs that assist with digital filter design. Both Jim Kaiser and Hal Alles were in the department. One of the side-effects of all this was Hal figuring out how to use the filter hardware connected to a LSI-11/03 to make sound, followed by Dave Hagelbarger building a very interesting keyboard for it, culminating in a visit by Stevie Wonder trailed by a large number of screaming secretaries. No sexism intended, it was a different world back then. The LSI-11 was one of the motivations for Heinz to create the LSX operating system. My recollection is that on Dave's keyboard each key was an antenna, and that there was strip of ribbon cable underneath where each wire was driven by a different bit on a binary counter. This allowed the position of each key to be determined which I think was way ahead of its time. I don't think that any commercially available keyboards did this at the time, they were all just on/off. Dave also designed the GLANCE keyboard which spoiled me for life. I don't remember how he did it, but the keys had a really good feel where once they got pushed past a certain point they snapped down. I do recall that there was a small solenoid mounted on the circuit board so that the keys gave a satisfying click that you could feel in your fingers. Another of Dave's gizmos was the chess board that he made for Ken. My recollection is that there was a tuned circuit in the base of each chess piece and an antenna grid in the board so that the PDP-11 could read the position of each piece. Some of the success of the 516 system was that other departments used it. I spent some time working an a 516-based integrated circuit test system where the test equipment stations were on the ring. Seems really dumb now, it's hard to believe that there was a time in which a computer cost more than a wafer stepper. In addition to his work on 516-TSS, Carl Christensen was one of the people who interviewed Ken Thompson for a job at the labs and gave a thumbs up. The 516-TSS documents don't have author names, just initials. Here's who they are to the best of my recollection. ADH Dick Hause CC Carl Christensen DJB Doug Bayer DRW Dave Weller EPR ? HL Heinz Lycklama JCS John Schwartzwelder JES Jon Steinhart JFK Jim Kaiser JHC Joe Condon JVC John Camlet LIS ? MAS ? RFG Rudy Garcia There is one mysterious document in the collection about a "memory service unit". I had this filed under "zapper". To the best of my recollection it was the PROM programmer that we used to burn the microcode PROMs for the GLANCE terminals. Jon Steinhart, 11/20/2020 From fair-tuhs at netbsd.org Mon Nov 23 12:18:24 2020 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sun, 22 Nov 2020 18:18:24 -0800 Subject: [TUHS] 516-TSS Documents In-Reply-To: <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> Message-ID: <23147.1606097904@cesium.clock.org> The Honeywell DDP-516 was the computer (running specialized software written by Bolt, Bernanek & Newman (BBN)) which was the initial model of the ARPANET Interface Message Processors (IMP). https://en.wikipedia.org/wiki/Interface_Message_Processor Erik Fair From ggm at algebras.org Mon Nov 23 13:10:30 2020 From: ggm at algebras.org (George Michaelson) Date: Mon, 23 Nov 2020 13:10:30 +1000 Subject: [TUHS] 516-TSS Documents In-Reply-To: <23147.1606097904@cesium.clock.org> References: <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> <23147.1606097904@cesium.clock.org> Message-ID: https://photos.app.goo.gl/dS2d4sEJQ5oWx8bo7 -G On Mon, Nov 23, 2020 at 12:28 PM Erik E. Fair wrote: > > The Honeywell DDP-516 was the computer (running specialized software written by Bolt, Bernanek & Newman (BBN)) which was the initial model of the ARPANET Interface Message Processors (IMP). > > https://en.wikipedia.org/wiki/Interface_Message_Processor > > Erik Fair From drb at msu.edu Mon Nov 23 14:00:45 2020 From: drb at msu.edu (Dennis Boone) Date: Sun, 22 Nov 2020 23:00:45 -0500 Subject: [TUHS] 516-TSS Documents In-Reply-To: (Your message of Sun, 22 Nov 2020 16:16:06 -0800.) <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> References: <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> Message-ID: <20201123040045.C732E18E749@yagi.h-net.msu.edu> > 516-TSS is a little-known but groundbreaking and influential > operating system that was developed at Bell Telephone Laboratories. Can you put any dates to the creation / development of this system? Even some estimate of its maturity when you first saw it would be of interest. There was a timeshared os for the Series 16 developed by a group at Tech Square, I think the NASA center that was there, late '60s. It involved some custom memory mapping hardware. The os became the basis of Prime's offering in the early 70s. De From jon at fourwinds.com Mon Nov 23 16:41:57 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 22 Nov 2020 22:41:57 -0800 Subject: [TUHS] 516-TSS Documents In-Reply-To: <20201123040045.C732E18E749@yagi.h-net.msu.edu> References: <202011230016.0AN0G6K2158571@darkstar.fourwinds.com> <20201123040045.C732E18E749@yagi.h-net.msu.edu> Message-ID: <202011230641.0AN6fvoS194686@darkstar.fourwinds.com> Dennis Boone writes: > > 516-TSS is a little-known but groundbreaking and influential > > operating system that was developed at Bell Telephone Laboratories. > > Can you put any dates to the creation / development of this system? > Even some estimate of its maturity when you first saw it would be of > interest. > > There was a timeshared os for the Series 16 developed by a group at Tech > Square, I think the NASA center that was there, late '60s. It involved > some custom memory mapping hardware. The os became the basis of Prime's > offering in the early 70s. > > De This was also late 60s as far as I know. The documents are dated, and the first one is in June 1968. It was a fully functional system when I first started using it. Heinz may be able to say more about it if he remembers. In many respects it wasn't a hugely interesting system in itself as much as it was a platform for the development of many other interesting technologies. Jon From jnc at mercury.lcs.mit.edu Mon Nov 23 23:42:34 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Nov 2020 08:42:34 -0500 (EST) Subject: [TUHS] 516-TSS Documents Message-ID: <20201123134234.8F52218C096@mercury.lcs.mit.edu> > On Mon, Nov 23, 2020 at 12:28 PM Erik E. Fair wrote: > The Honeywell DDP-516 was the computer (running specialized software > written by Bolt, Bernanek & Newman (BBN)) which was the initial model of > the ARPANET Interface Message Processors (IMP). The IMPs had a lot of custom interface hardware; sui generis serial interlocked host interfaces (so-called 1822), and also the high-speed modem interfaces. I think there was also a watchdog time, IIRC (this is all from memory, but the ARPANET papers from JCC cover it all). Noel From stu at remphrey.net Tue Nov 24 17:35:21 2020 From: stu at remphrey.net (Stuart Remphrey) Date: Tue, 24 Nov 2020 15:35:21 +0800 Subject: [TUHS] Package Management In-Reply-To: References: <202011211750.0ALHolUI011814@freefriends.org> Message-ID: "When I was managing SunOS systems it seemed like everyone rolled their own..." Yep, IIRC, tarball or cpio tape, no tracking or update support. Lucky if the ISV install script asked where to install it. SunOS filesystem layout was thoughtfully designed though, when diskless & diskfull systems were introduced supporting multiple architectures (2.5? 3.x?): CPU-architecture-specific and architecture-independent mount points, directories for Sun, ISV and local apps, etc (/usr /opt /usr/local and their variations), read-only /usr support (link writeables into /var). Though, mostly just Sun used this flexibility/complexity, few ISVs: they generally wanted their installs to be consistent across HP-UX, MIPS RISC/os, Pyramid dualPort DC/OSx, Sequent (Dynix?), SunOS, (maybe-AIX??,) etc; which made sense from a support training point of view. Beyond ./configure; make; make install which I'd count as build but barely packaging, I don't recall any packaging until Solaris pkgadd et al? Unfortunately with pkgadd came patchadd & friends. They did their level best to cross-patch random binaries and muddy the patch/package interdependency-waters as much as humanly possible. Partly as a result, the early OS/patch/firmware support matrices for FibreChannel were horrible. I'll probably have nightmares about that tonight... On Sun, 22 Nov 2020, 09:40 Warner Losh, wrote: > > > On Sat, Nov 21, 2020, 6:19 PM Clem Cole wrote: > >> 1) No intention to slight debian in any way. >> 2) dpkg was definitely an improvement over FreeBSds ports scheme. But... >> In fact freebsd did have a pkg system for ports before that --- which was >> basically similar to 1983 SysIII scheme >> > > FreeBSD's ports/pkg system did keep track of what was installed on the > system. There was a database in /var/db so pkg_delete could remove things > and pkg_which to know what pkg a given file belonged to. > > It was first-ish, but there was some package system for the early linux > root disks. I think this is how SLS started, but I might be misremembering. > But despite being early, and being ported to other BSDs, it sucked at > upgrading for 20-odd years until it was completely rewritten.... latter day > pkg is so much better, though its repo management has been a little weak > relative to the professional efforts in the linux world. > > /usr/ports none the less was ground breaking because it handled both the > local patching, the build depends and the packaging under one umbrella. > It's been on the whole a good thing and has reinvented itself several times > over the years. > > When I was managing SunOS systems it seemed like everyone rolled their > own. There was nothing like VMSINSTALL... > > Warner > > 3) also as I understand (and larry feel free to correct me here as a >> better chronicler of things Linux than I) but I believe that the big thing >> rpm added was the DB like DEC's setld and system Sun had used which us what >> I was refering too. >> >> Pls remember that I was trying to chronicle the basic ideas and some of >> the motivation which is what Henry asked. And that the original driver >> was to support ISVs installs. So I was trying to explain the history of >> what we did at the time. >> >> The be fair one of the more vocal people in the early 80s was Heinz who >> occasionally add color here. I remember Heinz trying to push us to an ABI >> and not stop at an API. >> >> Today most of the ISVs have abandoned Unix except for the Mac. Msft and >> the phones have taken that. And the package mngr has been replaced by the >> app store which has.much great use than any of the current Unix packaging >> schemes. Funny how the profit motive drove that. >> >> Working for one of the few ISVS that do package SW for Unix we basically >> support two schemes. Apple Mac installs and RPM because that is were the >> primary customer base has been. I'd not about goodness or being better or >> being first. It's economic (Larry and I bemoan this a lot). >> >> So pls don't take it as a comment about anything other than trying to >> answer as much of the early history as I could. >> >> Heinz, Jon, Larry you all lived this on the commercial side. Care to >> add anything? >> >> Clem >> >> On Sat, Nov 21, 2020 at 6:31 PM Gregg Levine >> wrote: >> >>> Hello! >>> I, myself normally run Slackware Linux. It uses package management in >>> the form of compressed tar files, and a flat file store of the names. >>> It also has a tool which when run will show the user what's there, and >>> what they do if need be. In fact Slackware predates Red Hat by about >>> four years. (Pat and his CS professor introduced themselves to one >>> much earlier one, which was SLS. Neither liked it, and the Prof was >>> convinced that Pat could do better.) >>> ----- >>> Gregg C Levine gregg.drwho8 at gmail.com >>> "This signature fought the Time Wars, time and again." >>> >>> On Sat, Nov 21, 2020 at 1:54 PM wrote: >>> > >>> > Things were pretty much ad hoc. Commercial software likely came >>> > as tar/cpio tapes to install however the vendor wanted. Free software >>> > was from USENET in source code, so again, however people wanted. >>> > >>> > The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format >>> > for installing software from floppy and tracked what was installed, >>> > but that was unique to it. >>> > >>> > Package managers as we know them today really became a big thing >>> > with Linux. Redhat's RPM was one of the earliest. >>> > >>> > My two cents; I'm sure others remember it differently. >>> > >>> > Arnold >>> > >>> > Henry Bent wrote: >>> > >>> > > Hello All, >>> > > >>> > > I know I have asked this before, but I am curious about any new >>> replies or >>> > > insight. How did package management start? Were sites keeping >>> track of >>> > > packages installed in a flat file that you could grep (as god >>> intended) >>> > > somewhere, or were upgrades and additions simply done without >>> significant >>> > > announcement? At what point did someone decide, 'Hey, we need to >>> have a >>> > > central way to track additional software"? >>> > > >>> > > I know of DEC's setld and SGI's inst in the latter half of the >>> '80s. What >>> > > was the mechanism before that? >>> > > >>> > > -Henry >>> > >>> >> -- >> Sent from a handheld expect more typos than usual >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Nov 26 03:14:55 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 25 Nov 2020 10:14:55 -0700 Subject: [TUHS] Seeking wisdom from Unix Greybeards Message-ID: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Hi, As I find myself starting yet another project that that wants to use ANSI control sequences for colorization of text, I find myself -- yet again -- wondering if there is a better way to generate the output from the code in a way that respects TERMinal capabilites. Is there a better / different control sequence that I can ~> should use for colorizing / stylizing output that will account for the differences in capabilities between a VT100 and XTerm? Can I wrap things that I output so that I don't send color control sequences to a TERMinal that doesn't support 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 ralph at inputplus.co.uk Thu Nov 26 03:22:55 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 25 Nov 2020 17:22:55 +0000 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Message-ID: <20201125172255.83D252146F@orac.inputplus.co.uk> Hi Grant, > wondering if there is a better way to generate the output from > the code in a way that respects TERMinal capabilites. tput setf 4; date; tput sgr0 See terminfo(5). (BTW, I don't think the question is worthy of TUHS.) -- Cheers, Ralph. From lm at mcvoy.com Thu Nov 26 03:38:14 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 25 Nov 2020 09:38:14 -0800 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Message-ID: <20201125173814.GB9589@mcvoy.com> man 1 tput is what I use. On Wed, Nov 25, 2020 at 10:14:55AM -0700, Grant Taylor via TUHS wrote: > Hi, > > As I find myself starting yet another project that that wants to use ANSI > control sequences for colorization of text, I find myself -- yet again -- > wondering if there is a better way to generate the output from the code in a > way that respects TERMinal capabilites. > > Is there a better / different control sequence that I can ~> should use for > colorizing / stylizing output that will account for the differences in > capabilities between a VT100 and XTerm? > > Can I wrap things that I output so that I don't send color control sequences > to a TERMinal that doesn't support them? > > > > -- > Grant. . . . > unix || die > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From steffen at sdaoden.eu Thu Nov 26 04:00:48 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 25 Nov 2020 19:00:48 +0100 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Message-ID: <20201125180048.IvtOI%steffen@sdaoden.eu> Grant Taylor wrote in <9c1595cc-54a1-8af9-0c2d-083cb04dd97c at spamtrap.tnetconsulting.net>: |Hi, | |As I find myself starting yet another project that that wants to use |ANSI control sequences for colorization of text, I find myself -- yet |again -- wondering if there is a better way to generate the output from |the code in a way that respects TERMinal capabilites. | |Is there a better / different control sequence that I can ~> should use |for colorizing / stylizing output that will account for the differences |in capabilities between a VT100 and XTerm? | |Can I wrap things that I output so that I don't send color control |sequences to a TERMinal that doesn't support them? color_init() { [ -n "${NOCOLOUR}" ] && return [ -n "${MAILX_CC_TEST_NO_COLOUR}" ] && return # We do not want color for "make test > .LOG"! if (command -v stty && command -v tput) >/dev/null 2>&1 && (<&1 >/dev/null stty -a) 2>/dev/null; then { sgr0=`tput sgr0`; } 2>/dev/null [ $? -eq 0 ] || return { saf1=`tput setaf 1`; } 2>/dev/null [ $? -eq 0 ] || return { saf2=`tput setaf 2`; } 2>/dev/null [ $? -eq 0 ] || return { saf3=`tput setaf 3`; } 2>/dev/null [ $? -eq 0 ] || return { b=`tput bold`; } 2>/dev/null [ $? -eq 0 ] || return COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0} COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0} COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0} unset saf1 saf2 saf3 b fi } Is what i use for a make system. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Nov 26 06:03:08 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 25 Nov 2020 21:03:08 +0100 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201125180048.IvtOI%steffen@sdaoden.eu> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <20201125180048.IvtOI%steffen@sdaoden.eu> Message-ID: <20201125200308.Kc4ne%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20201125180048.IvtOI%steffen at sdaoden.eu>: |Grant Taylor wrote in | <9c1595cc-54a1-8af9-0c2d-083cb04dd97c at spamtrap.tnetconsulting.net>: ||As I find myself starting yet another project that that wants to use ||ANSI control sequences for colorization of text, I find myself -- yet ||again -- wondering if there is a better way to generate the output from ||the code in a way that respects TERMinal capabilites. || ||Is there a better / different control sequence that I can ~> should use ||for colorizing / stylizing output that will account for the differences ||in capabilities between a VT100 and XTerm? || ||Can I wrap things that I output so that I don't send color control ||sequences to a TERMinal that doesn't support them? | | color_init() { | [ -n "${NOCOLOUR}" ] && return | [ -n "${MAILX_CC_TEST_NO_COLOUR}" ] && return | # We do not want color for "make test > .LOG"! | if (command -v stty && command -v tput) >/dev/null 2>&1 && Of course that subshell (..if it is one..) is not necessary, it could be { ..; } or x&&y&&, whatever. Must be a leftover, or whatever i have thought once i wrote this. | (<&1 >/dev/null stty -a) 2>/dev/null; then | { sgr0=`tput sgr0`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf1=`tput setaf 1`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf2=`tput setaf 2`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf3=`tput setaf 3`; } 2>/dev/null | [ $? -eq 0 ] || return | { b=`tput bold`; } 2>/dev/null | [ $? -eq 0 ] || return | | COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0} | COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0} | COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0} | unset saf1 saf2 saf3 b | fi |} | |Is what i use for a make system. A sh(1)-based test, to be exact. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tytso at mit.edu Fri Nov 27 00:51:34 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Thu, 26 Nov 2020 09:51:34 -0500 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201125172255.83D252146F@orac.inputplus.co.uk> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <20201125172255.83D252146F@orac.inputplus.co.uk> Message-ID: <20201126145134.GB394251@mit.edu> On Wed, Nov 25, 2020 at 05:22:55PM +0000, Ralph Corderoy wrote: > Hi Grant, > > > wondering if there is a better way to generate the output from > > the code in a way that respects TERMinal capabilites. > > tput setf 4; date; tput sgr0 > > See terminfo(5). > > (BTW, I don't think the question is worthy of TUHS.) To make this a bit more TUHS-focused, was there anything that had similar functionality which pre-dated Bill Joy and termcap in late 70's? (I'll note that in recent years, most people seem to have not bothered with terminfo, given that all the world's a Vax^H^H^HSun^H^H^HLinux ^H^H^H^Hxterm. :-) - Ted From erc at pobox.com Fri Nov 27 02:26:28 2020 From: erc at pobox.com (Ed Carp) Date: Thu, 26 Nov 2020 09:26:28 -0700 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Message-ID: You could write something in C using curses/ncurses (which will do the ANSI sequences for you automatically). From cym224 at gmail.com Fri Nov 27 04:26:30 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 26 Nov 2020 13:26:30 -0500 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> Message-ID: <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> On 11/26/20 11:26, Ed Carp wrote: > You could write something in C using curses/ncurses (which will > do the ANSI sequences for you automatically). True but I wonder whether curses would be bit heavy handed for this. N. From lm at mcvoy.com Fri Nov 27 04:29:37 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 26 Nov 2020 10:29:37 -0800 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> Message-ID: <20201126182937.GN9589@mcvoy.com> Um, as has been stated multiple time, this is why tputs(1) exists. Problem. Solved. On Thu, Nov 26, 2020 at 01:26:30PM -0500, Nemo Nusquam wrote: > On 11/26/20 11:26, Ed Carp wrote: > > You could write something in C using curses/ncurses (which will > > do the ANSI sequences for you automatically). > > True but I wonder whether curses would be bit heavy handed for this. > > N. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Fri Nov 27 04:37:46 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 26 Nov 2020 13:37:46 -0500 (EST) Subject: [TUHS] Seeking wisdom from Unix Greybeards Message-ID: <20201126183746.DD93218C087@mercury.lcs.mit.edu> > From: "Theodore Y. Ts'o" > was there anything that had similar functionality which pre-dated Bill > Joy and termcap in late 70's? Is your question purely in Unix, or more general? If the latter, there's the terminal-independent support of video terminals in ITS; that dates to the mid-1970's (i.e. circa V5 or so). User programs output device-independent display control codes (I have this memory that they were called P-Codes, but that could be my memory failing), and the OS translated them to the appropriate screen-control characters. One additional hack was that the number of terminal types supported in the OS was limited; there was however a protocol called SUPDUP which sent (basically) those device-independent codes over a remote login (originally over NCP) frm the server machine to the client. The User SUPDUP client supported a lot more terminal types; so people with odd-ball terminals used to log in, SUPDUP _back_ to their machine, and away they went. Noel From bakul at iitbombay.org Fri Nov 27 04:50:23 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 26 Nov 2020 10:50:23 -0800 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201126183746.DD93218C087@mercury.lcs.mit.edu> References: <20201126183746.DD93218C087@mercury.lcs.mit.edu> Message-ID: <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> RFC734 > On Nov 26, 2020, at 10:38 AM, jnc at mercury.lcs.mit.edu wrote: > >  >> >> From: "Theodore Y. Ts'o" > >> was there anything that had similar functionality which pre-dated Bill >> Joy and termcap in late 70's? > > Is your question purely in Unix, or more general? > > If the latter, there's the terminal-independent support of video terminals in > ITS; that dates to the mid-1970's (i.e. circa V5 or so). User programs output > device-independent display control codes (I have this memory that they were > called P-Codes, but that could be my memory failing), and the OS translated > them to the appropriate screen-control characters. > > One additional hack was that the number of terminal types supported in the OS > was limited; there was however a protocol called SUPDUP which sent (basically) > those device-independent codes over a remote login (originally over NCP) frm > the server machine to the client. The User SUPDUP client supported a lot more > terminal types; so people with odd-ball terminals used to log in, SUPDUP > _back_ to their machine, and away they went. > > Noel From lars at nocrew.org Fri Nov 27 05:02:22 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Nov 2020 19:02:22 +0000 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> (Bakul Shah's message of "Thu, 26 Nov 2020 10:50:23 -0800") References: <20201126183746.DD93218C087@mercury.lcs.mit.edu> <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> Message-ID: <7wr1ogdjr5.fsf@junk.nocrew.org> Noel Chiappa wrote: > If the latter, there's the terminal-independent support of video > terminals in ITS; that dates to the mid-1970's (i.e. circa V5 or > so). User programs output device-independent display control codes (I > have this memory that they were called P-Codes, but that could be my > memory failing), and the OS translated them to the appropriate > screen-control characters. That's correct. Or ^P-codes, from the character that signalled a control code. It would be interesting to figure out when they were introduced. They were not present in 1972; at this point ITS only supported printing terminals, Datapoints, and Imlacs. WAITS allegedly had an even better abstration of terminal control codes. > One additional hack was that the number of terminal types supported in > the OS was limited; there was however a protocol called SUPDUP which > sent (basically) those device-independent codes over a remote login Basically, but another set of equivalent codes internal to ITS. SUPDUP means super-duper image mode, which alludes to image mode. > (originally over NCP) frm the server machine to the client. The User > SUPDUP client supported a lot more terminal types; so people with > odd-ball terminals used to log in, SUPDUP _back_ to their machine, and > away they went. See also CRTSTY. From steffen at sdaoden.eu Fri Nov 27 07:48:25 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 26 Nov 2020 22:48:25 +0100 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201126145134.GB394251@mit.edu> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <20201125172255.83D252146F@orac.inputplus.co.uk> <20201126145134.GB394251@mit.edu> Message-ID: <20201126214825.bDDjr%steffen@sdaoden.eu> Theodore Y. Ts'o wrote in <20201126145134.GB394251 at mit.edu>: |On Wed, Nov 25, 2020 at 05:22:55PM +0000, Ralph Corderoy wrote: |>> wondering if there is a better way to generate the output from |>> the code in a way that respects TERMinal capabilites. |> |> tput setf 4; date; tput sgr0 |> |> See terminfo(5). |> |> (BTW, I don't think the question is worthy of TUHS.) | |To make this a bit more TUHS-focused, was there anything that had |similar functionality which pre-dated Bill Joy and termcap in late |70's? | |(I'll note that in recent years, most people seem to have not bothered |with terminfo, given that all the world's a Vax^H^H^HSun^H^H^HLinux |^H^H^H^Hxterm. :-) ANSI escape sequences aka ISO 6429 came via ECMA-48 i have learned, and that appeared first in 1976 (that via Wikidpedia). I made a survey about twenty years ago over terminfo (source) entries, and found it not worth the effort to care for anything else, and not to padding, too. (My experience with hardware does not even cause a little cough in this audience, however.) | - Ted | --End of <20201126145134.GB394251 at mit.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From will.senn at gmail.com Fri Nov 27 07:55:59 2020 From: will.senn at gmail.com (Will Senn) Date: Thu, 26 Nov 2020 15:55:59 -0600 Subject: [TUHS] Apple IIe Unix? Message-ID: Hi All, So, I'm about to get my very own Apple IIe and while it's an incredibly versatile machine for assembly language and hardware hackery, I'm not aware of any Unices that run on the machine, natively. Does anybody know of any from back in the day? It's got a 65c02 processor and somewhere around 128k of RAM, but it's also pretty expandable w/7 slots and a huge amount of literature about how to do stuff w/those slots. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Nov 27 07:56:53 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 26 Nov 2020 22:56:53 +0100 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> References: <20201126183746.DD93218C087@mercury.lcs.mit.edu> <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> Message-ID: <20201126215653.INoK4%steffen@sdaoden.eu> Bakul Shah wrote in <7DBB40AE-259D-494E-8ABF-2FE4D47F4052 at iitbombay.org>: |RFC734 Interesting! Off-topic, but i have downloaded this via #!/bin/sh - FROM=https://www.rfc-editor.org/rfc/ #FROM=https://tools.ietf.org/rfc/ MYDIR=/x/doc/coding/rfc : ${WGET:=`command -v curl` --silent} #: ${WGET:=`command -v wget` -q -O -} ## cd "${MYDIR}" || { echo >&2 'Cannot cd to '"${MYDIR}" exit 21 } xfiles= estat=0 while [ ${#} -gt 0 ]; do RFC=${1} shift [ -f "rfc${RFC}.txt" ] && { echo 'RFC '${RFC}': a local copy of this RFC yet exists' continue } printf 'Fetching RFC %s.txt ... ' "${RFC}" if ${WGET} "${FROM}"rfc${RFC}.txt > rfc${RFC}.txt; then xfiles="${xfiles} rfc${RFC}.txt" printf 'ok\n' else printf 'failed!\n' estat=1 fi done if [ -n "${xfiles}" ]; then "${EDITOR}" INDEX.txt ${xfiles} fi exit ${estat} and the file is contaminated with NULs. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dave at horsfall.org Fri Nov 27 07:59:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 27 Nov 2020 08:59:27 +1100 (EST) Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201126145134.GB394251@mit.edu> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <20201125172255.83D252146F@orac.inputplus.co.uk> <20201126145134.GB394251@mit.edu> Message-ID: On Thu, 26 Nov 2020, Theodore Y. Ts'o wrote: > To make this a bit more TUHS-focused, was there anything that had > similar functionality which pre-dated Bill Joy and termcap in late 70's? As I recall, one wrote code "knowing" that it was a VT-05 etc if you wanted escape sequences; I dimly recall using a getty-like file to get the terminal type. Thus, /dev/tty8 was invariably (but not always) the dreaded VT-05 (one client used a Duckwriter as the console, because he wanted a hard-copy of everything; one day, the system went berserk (a bad sector smack on the error log) and so did the hard copy, as Unix faithfully tried to record each error). -- Dave From usotsuki at buric.co Fri Nov 27 08:22:32 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 26 Nov 2020 17:22:32 -0500 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020, Will Senn wrote: > Hi All, > > So, I'm about to get my very own Apple IIe and while it's an incredibly > versatile machine for assembly language and hardware hackery, I'm not aware > of any Unices that run on the machine, natively. Does anybody know of any > from back in the day? > > It's got a 65c02 processor and somewhere around 128k of RAM, but it's also > pretty expandable w/7 slots and a huge amount of literature about how to do > stuff w/those slots. > > Thanks, > > Will > > Big problem is there's no easy way to do preemptive multitasking without extra hardware. The Apple //e and //c are basically the machine I cut my teeth on. -uso. From nikke.karlsson at gmail.com Fri Nov 27 08:30:04 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Thu, 26 Nov 2020 23:30:04 +0100 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: Hi, I seriously doubt there's a "real" Unix for such a small machine from that era. There may be workalikes, of course. I know of a Unix workalike for the Commodore 64 called LUnix, but it isn't really a full Unix. That's almost (almost!) the same CPU, at least. Best regards, Niklas Den tors 26 nov. 2020 kl 22:56 skrev Will Senn : > Hi All, > > So, I'm about to get my very own Apple IIe and while it's an incredibly > versatile machine for assembly language and hardware hackery, I'm not aware > of any Unices that run on the machine, natively. Does anybody know of any > from back in the day? > > It's got a 65c02 processor and somewhere around 128k of RAM, but it's also > pretty expandable w/7 slots and a huge amount of literature about how to do > stuff w/those slots. > > Thanks, > > 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 Fri Nov 27 08:47:40 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 27 Nov 2020 09:47:40 +1100 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020, Will Senn wrote: > So, I'm about to get my very own Apple IIe and while it's an incredibly > versatile machine for assembly language and hardware hackery, I'm not > aware of any Unices that run on the machine, natively. Does anybody know > of any from back in the day? I'm not aware of any, but I would start with something like Mini-Unix (a really cut-down Unix). You'd have to do the assembler stuff yourself, of course. -- Dave From clemc at ccc.com Fri Nov 27 09:00:22 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Nov 2020 18:00:22 -0500 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: On Thu, Nov 26, 2020 at 4:56 PM Will Senn wrote: > Hi All, > > So, I'm about to get my very own Apple IIe and while it's an incredibly > versatile machine for assembly language and hardware hackery, I'm not aware > of any Unices that run on the machine, natively. Does anybody know of any > from back in the day? > > It's got a 65c02 processor and somewhere around 128k of RAM, but it's also > pretty expandable w/7 slots and a huge amount of literature about how to do > stuff w/those slots. > My favorite 8-bit processor, maybe my favorite all around. So simple, one accumulator and two index registers but it is only 64K of total address - although with bank switching more memory could be added in 4K banks on a number of Apple II's, but you have 16 address bits and worked a register that switched in and out the 4K banks. and there is of course no protection hardware nor the concept of user/kernel in the hardware. The size of the Apple Floppy disk was rather small, and your need 3 to run things like the UCSD Pascal system to have any experience other than constantly switching disks. There are a number of C compilers available but with its limited and fixed stack (8 bits only), so it is difficult to run programs of any size (in any language - automatics are often managed off the stack). Running a full UNIX on it was not really possible although a few of the Unix style utilities were moved to it and a number of simple monitors were written that swapped programs in and out DOS style. At one time, I had a fairly good version of the Bourne (V7) syntax shell we got running, but it had to be swapped in and out slowly. That is; you run the shell, type a command, when exec is done, the shell is tossed out and the new program installed in memory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Fri Nov 27 09:14:13 2020 From: erc at pobox.com (Ed Carp) Date: Thu, 26 Nov 2020 16:14:13 -0700 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: <20201126182937.GN9589@mcvoy.com> References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> <20201126182937.GN9589@mcvoy.com> Message-ID: Larry, as was stated in the original post (and multiple times in the replies), I believe they were looking for another solution. On 11/26/20, Larry McVoy wrote: > Um, as has been stated multiple time, this is why tputs(1) exists. > Problem. Solved. From katolaz at freaknet.org Fri Nov 27 09:07:55 2020 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Thu, 26 Nov 2020 23:07:55 +0000 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: <20201126230755.GC48281@wontolla.jungle> On Fri, Nov 27, 2020 at 09:47:40AM +1100, Dave Horsfall wrote: > On Thu, 26 Nov 2020, Will Senn wrote: > > > So, I'm about to get my very own Apple IIe and while it's an incredibly > > versatile machine for assembly language and hardware hackery, I'm not > > aware of any Unices that run on the machine, natively. Does anybody know > > of any from back in the day? > > I'm not aware of any, but I would start with something like Mini-Unix (a > really cut-down Unix). > > You'd have to do the assembler stuff yourself, of course. > > -- Dave There is FUZIX by Alan Cox: https://www.fuzix.org https://github.com/EtchedPixels/FUZIX which is a blend of V7+BSD userland plus a mix of different UZI implementations from the '80s and a lot of new code. It runs on a variety of "small" CPUs, including pdp-11, Z80/Z180/Z280, 8080, 8085, 8086, 6502, 6803, 6809, 68k, and a few dozens platforms. There is some initial support for Apple IIe there. I have used it myself on several retrobrew Z80/Z180 systems, but not on an Apple IIe, so I can't tell it will work for sure. It's worth trying it out though. HTH Enzo -- From lm at mcvoy.com Fri Nov 27 09:23:40 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 26 Nov 2020 15:23:40 -0800 Subject: [TUHS] Seeking wisdom from Unix Greybeards In-Reply-To: References: <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net> <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> <20201126182937.GN9589@mcvoy.com> Message-ID: <20201126232340.GE9609@mcvoy.com> Did I miss a reason for the alternative? Because if you add a caching layer this approach has been working for me for decades. I rewrote dired in perl just because perl was everywhere and I could. I've been dragging the perl one around since at least 1990 and it worked for me on pretty much any version of Unix. I think MacOS isn't supported but I'm sure it could be. To avoid calling tput over and over again, I cached the output for each terminal and then just evaled the cache which sets a bunch of variables to the escapes I needed. It performed just fine on 20mhz SPARCstations so I'm sort of wondering why the solution for the problem isn't good enough. # Dig out all the terminal info so we know the escape chars for this terminal. sub terminal_init { local($term) = "$ENV{'HOME'}/.term/$ENV{'TERM'}"; local($i) = 0; $| = 1; @pids = (); $SIG{TERM} = sub { exit(0); }; $SIG{PIPE} = 'IGNORE'; # RedHat 5.0 seems to get this wrong somehow. #chop($tc_rows = `tput lines`); #chop($tc_cols = `tput cols`); open(STTY, "stty -a|"); while (defined($_ = )) { last if /rows = \d/ || /\d rows/ || /rows \d/; } close(STTY); #speed 9600 baud; rows 58; columns 80; line = 0; #speed 9600 baud; 47 rows; 80 columns; #rows = 66; columns = 80 $tc_cols = 0; if (/rows (\d+); columns (\d+);/) { $tc_rows = $1; $tc_cols = $2; } elsif (/(\d+) rows; (\d+) columns;/) { $tc_rows = $1; $tc_cols = $2; } elsif (/rows = (\d+); columns = (\d+)/) { $tc_rows = $1; $tc_cols = $2; } if ($tc_cols == 0) { die "Can't get terminal settings.\n"; } $half_of_screen = int($tc_rows / 2); # it's cached, go grab it. if (-f $term) { open(T, $term); @t = ; close(T); eval "@t"; &ttyraw; return unless $i < $tc_rows; } print "Getting terminal info just this once and saving it..."; mkdir("$ENV{'HOME'}/.term", 0755); open(T, ">$term"); $tc_smcup = `tput smcup`; $tc_rmcup = `tput rmcup`; $tc_bold = `tput bold`; $tc_normal = `tput sgr0`; $tc_clear = `tput clear`; $tc_clreos = `tput ed`; $tc_clreol = `tput el`; if ($tc_cols < 60) { die "$0: needs 60 columns"; } if (length($tc_clreos) == 0) { die "$0: needs clear to end of screen"; } if (length($tc_clreol) == 0) { die "$0: needs clear to end of line"; } print T "\$tc_smcup = \"$tc_smcup\";\n"; print T "\$tc_rmcup = \"$tc_rmcup\";\n"; print T "\$tc_bold = \"$tc_bold\";\n"; print T "\$tc_normal = \"$tc_normal\";\n"; print T "\$tc_clear = \"$tc_clear\";\n"; print T "\$tc_clreol = \"$tc_clreol\";\n"; print T "\$tc_clreos = \"$tc_clreos\";\n"; for ($i = 0; $i < $tc_rows; ++$i) { $left[$i] = `tput cup $i 0`; print T '$left[' . "$i] = \"" . $left[$i] . "\";\n"; if ($i < $half_of_screen) { $middle[$i] = `tput cup $i 44`; print T '$middle[' . "$i] = \"" . $middle[$i] . "\";\n"; } } print T '$i = ' . "$i;\n"; close(T); print "done\n"; &ttyraw; } From jason-tuhs at shalott.net Fri Nov 27 09:22:56 2020 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Thu, 26 Nov 2020 15:22:56 -0800 (PST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: > So, I'm about to get my very own Apple IIe and while it's an incredibly > versatile machine for assembly language and hardware hackery, I'm not > aware of any Unices that run on the machine, natively. Does anybody know > of any from back in the day? I don't think there are any for the 8-bit Apple IIs, but for the 16-bit Apple IIgs, there's GNO/ME unix: http://www.gno.org/gno/ I actually ran this on my IIgs; it was cute, and quite usable considering the limitations of the hardware. I don't know anything about its provenance, though. Anyone else run GNO/ME? Anyone know if it was based on some previous source base or distribution? Or know the folks behind it? -Jason From drsalists at gmail.com Fri Nov 27 10:24:39 2020 From: drsalists at gmail.com (Dan Stromberg) Date: Thu, 26 Nov 2020 16:24:39 -0800 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: There was also Kix for the Atari 800 - also a 65*02 processor system. It felt a little bit *ixy, but wasn't really. On Thu, Nov 26, 2020 at 2:31 PM Niklas Karlsson wrote: > Hi, > > I seriously doubt there's a "real" Unix for such a small machine from that > era. There may be workalikes, of course. I know of a Unix workalike for the > Commodore 64 called LUnix, but it isn't really a full Unix. That's almost > (almost!) the same CPU, at least. > > Best regards, > Niklas > > Den tors 26 nov. 2020 kl 22:56 skrev Will Senn : > >> Hi All, >> >> So, I'm about to get my very own Apple IIe and while it's an incredibly >> versatile machine for assembly language and hardware hackery, I'm not aware >> of any Unices that run on the machine, natively. Does anybody know of any >> from back in the day? >> >> It's got a 65c02 processor and somewhere around 128k of RAM, but it's >> also pretty expandable w/7 slots and a huge amount of literature about how >> to do stuff w/those slots. >> >> Thanks, >> >> Will >> >> -- >> GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Nov 27 10:47:48 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 26 Nov 2020 17:47:48 -0700 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: <9BEF7600-93F3-4EE0-8A1C-0AA4CF3DD0C0@gmail.com> I too am a big 6502 fan. XINU was a thing …. buuuuut it was written for a clone with weird bankswitching. https://comp.sys.apple2.programmer.narkive.com/xN2z7e8K/fixing-xinu-for-apple-ii As mentioned somewhere in this thread, Fusix might work or be workable with a little elbow grease but I haven’t tried it myself. Doesn’t look like there’s a boot disk set for it. https://github.com/EtchedPixels/FUZIX I mean, it’s not going to feel like a modern Unix or even 211bsd if you get it working, but it might be comparable to a Mini-Unix or v6 on a small PDP-11. Adam > On Nov 26, 2020, at 4:00 PM, Clem Cole wrote: > > > > On Thu, Nov 26, 2020 at 4:56 PM Will Senn > wrote: > Hi All, > > So, I'm about to get my very own Apple IIe and while it's an incredibly versatile machine for assembly language and hardware hackery, I'm not aware of any Unices that run on the machine, natively. Does anybody know of any from back in the day? > > It's got a 65c02 processor and somewhere around 128k of RAM, but it's also pretty expandable w/7 slots and a huge amount of literature about how to do stuff w/those slots. > My favorite 8-bit processor, maybe my favorite all around. So simple, one accumulator and two index registers but it is only 64K of total address - although with bank switching more memory could be added in 4K banks on a number of Apple II's, but you have 16 address bits and worked a register that switched in and out the 4K banks. and there is of course no protection hardware nor the concept of user/kernel in the hardware. The size of the Apple Floppy disk was rather small, and your need 3 to run things like the UCSD Pascal system to have any experience other than constantly switching disks. > > There are a number of C compilers available but with its limited and fixed stack (8 bits only), so it is difficult to run programs of any size (in any language - automatics are often managed off the stack). > > Running a full UNIX on it was not really possible although a few of the Unix style utilities were moved to it and a number of simple monitors were written that swapped programs in and out DOS style. At one time, I had a fairly good version of the Bourne (V7) syntax shell we got running, but it had to be swapped in and out slowly. That is; you run the shell, type a command, when exec is done, the shell is tossed out and the new program installed in memory. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Nov 27 12:02:13 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 27 Nov 2020 12:02:13 +1000 Subject: [TUHS] 516-TSS documents In-Reply-To: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> References: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> Message-ID: <20201127020213.GA27387@minnie.tuhs.org> On Wed, Nov 18, 2020 at 05:29:22PM -0800, Jon Steinhart wrote: > Well, it's a very rainy day and since COVID is keeping me home I just > fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff. > Not sure what to do with it since I don't have a place to serve it and > since they're scanned images they're too big to post. Here's the list > of documents; email me if you're wanting something in a hurry while the > archive stuff is figured out. Note that the smell of mildew wasn't > preserved in the scanning process. All, with Jon's permission I've placed a copy of these documents at https://www.tuhs.org/Archive/Documentation/Other/516-TSS/ Cheers, Warren From clemc at ccc.com Fri Nov 27 12:13:05 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Nov 2020 21:13:05 -0500 Subject: [TUHS] 516-TSS documents In-Reply-To: <20201127020213.GA27387@minnie.tuhs.org> References: <202011190129.0AJ1TM7v543138@darkstar.fourwinds.com> <20201127020213.GA27387@minnie.tuhs.org> Message-ID: Thanks Warren This is great stuff On Thu, Nov 26, 2020 at 9:03 PM Warren Toomey wrote: > On Wed, Nov 18, 2020 at 05:29:22PM -0800, Jon Steinhart wrote: > > Well, it's a very rainy day and since COVID is keeping me home I just > > fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff. > > Not sure what to do with it since I don't have a place to serve it and > > since they're scanned images they're too big to post. Here's the list > > of documents; email me if you're wanting something in a hurry while the > > archive stuff is figured out. Note that the smell of mildew wasn't > > preserved in the scanning process. > > All, with Jon's permission I've placed a copy of these documents at > https://www.tuhs.org/Archive/Documentation/Other/516-TSS/ > > Cheers, Warren > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Nov 27 12:23:36 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 26 Nov 2020 18:23:36 -0800 Subject: [TUHS] free dead trees, to the best possible home Message-ID: Back in mid-January, I posted a note saying: > TL; DR. I'm trying to find the best possible home for some dead trees. ... A lot (far too much, IMNSHO!) has happened since then. In any case, I thought folks here might appreciate an update. In brief, Iain Maoileoin offered to pay for shipping a largely unknown amount of technical (mostly computer-related) books to his repurposed missile sile (!) near Inverness, Scotland. Early this Fall, I packed up 16 cardboard boxes (designated 0-F, of course :-) and the shippers hauled them off. Dunno when they'll arrive, let alone in what condition, but trying to save them from recycling seemed worth the effort. FYI, the total weight was a bit over a ton. Meanwhile, my spouse and I gave away and/or packed up the rest of our things and drove ourselves and five cats up to Seattle, WA, USA. Somewhere in a shipping container, there is still a cubic foot or so of historical Unix papers from Jim Joyce; when it surfaces, I'll post again about rehoming it. -r From usotsuki at buric.co Fri Nov 27 13:16:52 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 26 Nov 2020 22:16:52 -0500 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020, Clem Cole wrote: > My favorite 8-bit processor, maybe my favorite all around. Ditto. > Running a full UNIX on it was not really possible although a few of the > Unix style utilities were moved to it and a number of simple monitors were > written that swapped programs in and out DOS style. At one time, I had a > fairly good version of the Bourne (V7) syntax shell we got running, but it > had to be swapped in and out slowly. That is; you run the shell, type a > command, when exec is done, the shell is tossed out and the new program > installed in memory. One would have better luck with the Apple IIgs except I don't think there's a good free C compiler for 65816. There's GNO which is very BSD, but obviously cut back for the necessity of running on top of GS/OS (and the shell is written in asm, it's not a true Bourne shell AFAIK). -uso. From usotsuki at buric.co Fri Nov 27 13:18:47 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 26 Nov 2020 22:18:47 -0500 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020, jason-tuhs at shalott.net wrote: >> of any Unices that run on the machine, natively. Does anybody know of any >> from back in the day? > > I don't think there are any for the 8-bit Apple IIs, but for the 16-bit Apple > IIgs, there's GNO/ME unix: http://www.gno.org/gno/ > > I actually ran this on my IIgs; it was cute, and quite usable considering the > limitations of the hardware. I don't know anything about its provenance, > though. > > Anyone else run GNO/ME? Anyone know if it was based on some previous source > base or distribution? Or know the folks behind it? I know that a lot of the code bears the 4-clause BSD license. So maybe it's based on 4.4BSD, but with some parts rewritten? -uso. From jnc at mercury.lcs.mit.edu Fri Nov 27 21:54:44 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 27 Nov 2020 06:54:44 -0500 (EST) Subject: [TUHS] Apple IIe Unix? Message-ID: <20201127115444.E581018C091@mercury.lcs.mit.edu> > From: Steve Nickolas > there's no easy way to do preemptive multitasking without extra > hardware. Perhaps you're using some idiosyncratic definition of "preemptive" and "multitasking", but to me that statement's not accurate. Let's take the "multitasking" part first: that just means 'two or more computations can run at the same time, sharing the machine' - and that's not hard to do, without special hardware, provided there's some way (in the organization of the software) to save the state of one when the other is running. Many simple systems do this; e.g. the MOS system that I used on LSI-11's, BITD. "Preemptive" is a bit trickier, because things have to be organized so that one 'task' can be temporarily stopped arbitrarily (i.e. without it explicitly giving up the processor, which is what e.g.MOS did) to let another run. There does need to be some asynchronous way of inciting the second 'task' to run, but interrupts (either clock, or device) do that, and pretty much every machine has those. MINI-UNIX, for example, has premptive multitasking. The thing that takes special hardware is _protecting_ one task from a bug in another - a bug which could trash the first tasks's (or the system's!) memory. One has to have memory management of some kind to do that. > From: Dave Horsfall > I would start with something like Mini-Unix MINI-UNIX would be a good place to start if one wanted to bring up a system on a machine without memory management; there's nothing in the kernel which is PDP-11 dependent that I can think of (unlike V6, which had a fairly heavy dependency on the PDP-11 memory management hardware - although one could of course rip that all out, as MINI-UNIX did). However, one's still looking at a fair amount of work, both to get rid of any traces of PDP-11isms (e.g. stack growth direction), and translate the assembler part (startup, and access to non-C operations). Something like FUZIX might be an easier option. Noel From usotsuki at buric.co Fri Nov 27 22:20:38 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 27 Nov 2020 07:20:38 -0500 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: <20201127115444.E581018C091@mercury.lcs.mit.edu> References: <20201127115444.E581018C091@mercury.lcs.mit.edu> Message-ID: On Fri, 27 Nov 2020, Noel Chiappa wrote: > > From: Steve Nickolas > > > there's no easy way to do preemptive multitasking without extra > > hardware. > > Perhaps you're using some idiosyncratic definition of "preemptive" and > "multitasking", but to me that statement's not accurate. > > Let's take the "multitasking" part first: that just means 'two or more > computations can run at the same time, sharing the machine' - and that's not > hard to do, without special hardware, provided there's some way (in the > organization of the software) to save the state of one when the other is > running. Many simple systems do this; e.g. the MOS system that I used on > LSI-11's, BITD. That's cooperative multitasking, though. And there's actually a program for the Apple //e that lets you do it from *BASIC*, "Extra.Apple" from Beagle Bros (they did a ton of "enhancement" utilities like this). > "Preemptive" is a bit trickier, because things have to be organized so that > one 'task' can be temporarily stopped arbitrarily (i.e. without it explicitly > giving up the processor, which is what e.g.MOS did) to let another run. There > does need to be some asynchronous way of inciting the second 'task' to run, > but interrupts (either clock, or device) do that, and pretty much every > machine has those. MINI-UNIX, for example, has premptive multitasking. You'd at least need interrupts, but a stock Apple //e literally doesn't have any way to generate a hardware interrupt. I do believe the //c (which has a built-in mouse controller which is interrupt-driven) can be programmed to do that, but without something like a 6522 card, a //e can't. It's pretty primordial, really. -uso. From hans at hanshq.net Fri Nov 27 22:59:06 2020 From: hans at hanshq.net (Hans Wennborg) Date: Fri, 27 Nov 2020 13:59:06 +0100 Subject: [TUHS] Why do compress(1) and pack(1) use the .Z / .z extension? Message-ID: I'm trying to find out why compress(1) uses .Z as filename extension. My theory is that it was inspired by pack(1), which uses the .z extension. However, I haven't been able to find any info on why pack(1) uses that extension. Does anyone here know? Some searching led me to [1] which is a man page for pack from AUSAM. It's written by Steve Zucker in 1975, so perhaps the extension is z for Zucker? Was Zucker's pack(1) the first, though? This message [2] talks about a Bell version. Does anyone here have any information about this? Cheers, Hans 1. https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/doc/man/man1/pack.1 2. https://tech-insider.org/unix/research/1984/0319.html From lm at mcvoy.com Sat Nov 28 01:01:44 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 27 Nov 2020 07:01:44 -0800 Subject: [TUHS] W. Richard Stevens wife's email? Message-ID: <20201127150144.GA25974@mcvoy.com> I was making coffee into the cup I've had for decades that talks about his networking books. I realized I might have something that would help his wife a bit. I had her email but long since lost it. Anyone have it? --lm From cowan at ccil.org Sat Nov 28 01:57:43 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 27 Nov 2020 10:57:43 -0500 Subject: [TUHS] Why do compress(1) and pack(1) use the .Z / .z extension? In-Reply-To: References: Message-ID: On Fri, Nov 27, 2020 at 8:07 AM Hans Wennborg wrote: I'm trying to find out why compress(1) uses .Z as filename extension. > > My theory is that it was inspired by pack(1), which uses the .z extension. > I think that connection is plain. As for the .z extension, I'd guess (and it's nothing better than that, just a conclusion I jumped to long ago) that it makes compressed files sort after files that share the same root name. IIRC, compress(1) used to be able to unpack files as well as uncompressing them. I don't know if that's still true. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org May the hair on your toes never fall out! --Thorin Oakenshield (to Bilbo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Nov 28 02:22:00 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 27 Nov 2020 11:22:00 -0500 Subject: [TUHS] Apple IIe Unix? In-Reply-To: <20201127115444.E581018C091@mercury.lcs.mit.edu> References: <20201127115444.E581018C091@mercury.lcs.mit.edu> Message-ID: On Fri, Nov 27, 2020 at 6:55 AM Noel Chiappa wrote: > The thing that takes special hardware is _protecting_ one task from a bug > in > another - a bug which could trash the first tasks's (or the system's!) > memory. One has to have memory management of some kind to do that. > Actually, a modified version of the * approach will also work. When switching processes, swap the whole process out to your fastest device (on * this was a single write to the drum) and swap in the new process. * hardware had a bounds register, so it was only necessary to swap out enough of the previous process to fit the smaller process in. So after a while, core started to look like an onion, with the current process at the bottom and pieces of larger non-current processes above that. (I thought that * was MIT CTSS, but I can't confirm that.) As for interrupts, the stock 2e has both IRQ and NMI lines. Erann Gat aka Ron Garret explains in < https://www.atarimagazines.com/compute/issue9/030_1_THE_25C_APPLE_II_REAL_TIME_CLOCK.php> how to make an external clock and hook it to the NMI pin for 25 cents in 1981 dollars (about $1.67 today; h/t measuringworth.com). John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org A mosquito cried out in his pain, "A chemist has poisoned my brain!" The cause of his sorrow / Was para-dichloro- Diphenyltrichloroethane. (aka DDT) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Nov 28 03:16:01 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 27 Nov 2020 12:16:01 -0500 Subject: [TUHS] Why do compress(1) and pack(1) use the .Z / .z extension? In-Reply-To: References: Message-ID: On Fri, Nov 27, 2020 at 8:08 AM Hans Wennborg wrote: > I'm trying to find out why compress(1) uses .Z as filename extension. > > My theory is that it was inspired by pack(1), which uses the .z extension. > Yes. > > However, I haven't been able to find any info on why pack(1) uses that > extension. Does anyone here know? > No idea - but yes, Zucker used a .z at Rand when he wrote. > > Some searching led me to [1] which is a man page for pack from AUSAM. > It's written by Steve Zucker in 1975, so perhaps the extension is z for > Zucker? > > Was Zucker's pack(1) the first, though? This message [2] talks about a > Bell version. Zucker wrote it at Rand - early/mid 1970s. IIRC, It was later included in the original Harvard USENIX tape in the 'Rand' directory. I believe that Rand Pipes (named pipes) are in the same directory. Although some of the Rand stuff was being shared by folks on the ArpaNet before USENIX existed and I think it made it to the wild before the first USENIX tape. It was really important back in the day. Remember RK05's are only 2.5M bytes - source archiving and packing files was pretty important given the cost / byte of disk. I think there may have been an early version @ BTL - PWB may have distributed it also, but I'm fairly sure it was the Rand code that started it. Noel might remember more than I. I'm 90% sure we had it at CMU before we got either PWB 1.0 or UNIX/TS from Ted -- I want to say it we had it on 5th edition but maybe not. One of the PDP-10 folks will need to chime in here. My memory is there was something like pack(1) on the CMU PDP-10s and 20s that I saw before I saw the UNIX tool [not sure why I think this, but it may have been SAIL program - I remember looking at a number of simple tools when I learn SAIL years and years ago - 74/75-ish]. IIRC they were not exactly the same format as the 10's were 36-bit words, stored 5 chars in a word, but it was the same idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Nov 28 05:00:25 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 27 Nov 2020 12:00:25 -0700 Subject: [TUHS] Why do compress(1) and pack(1) use the .Z / .z extension? In-Reply-To: References: Message-ID: On Fri, Nov 27, 2020 at 10:17 AM Clem Cole wrote: > > > On Fri, Nov 27, 2020 at 8:08 AM Hans Wennborg wrote: > >> I'm trying to find out why compress(1) uses .Z as filename extension. >> >> My theory is that it was inspired by pack(1), which uses the .z extension. >> > Yes. > > > >> >> However, I haven't been able to find any info on why pack(1) uses that >> extension. Does anyone here know? >> > No idea - but yes, Zucker used a .z at Rand when he wrote. > >> >> Some searching led me to [1] which is a man page for pack from AUSAM. >> It's written by Steve Zucker in 1975, so perhaps the extension is z for >> Zucker? >> >> Was Zucker's pack(1) the first, though? This message [2] talks about a >> Bell version. > > Zucker wrote it at Rand - early/mid 1970s. IIRC, It was later included in > the original Harvard USENIX tape in the 'Rand' directory. I believe that > Rand Pipes (named pipes) are in the same directory. Although some of the > Rand stuff was being shared by folks on the ArpaNet before USENIX existed > and I think it made it to the wild before the first USENIX tape. > > It was really important back in the day. Remember RK05's are only 2.5M > bytes - source archiving and packing files was pretty important given the > cost / byte of disk. > > I think there may have been an early version @ BTL - PWB may have > distributed it also, but I'm fairly sure it was the Rand code that started > it. Noel might remember more than I. I'm 90% sure we had it at CMU before > we got either PWB 1.0 or UNIX/TS from Ted -- I want to say it we had it on > 5th edition but maybe not. > > One of the PDP-10 folks will need to chime in here. My memory is there > was something like pack(1) on the CMU PDP-10s and 20s that I saw before I > saw the UNIX tool [not sure why I think this, but it may have been SAIL > program - I remember looking at a number of simple tools when I learn SAIL > years and years ago - 74/75-ish]. IIRC they were not exactly the same > format as the 10's were 36-bit words, stored 5 chars in a word, but it was > the same idea. > Regardless of the early history, this is why gzip files end in .gz and not .z. The pack'd files were considered too prevalent at the time to crowd into that name space, even though this happened maybe 12 years after compress started to displace pack. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Nov 28 05:17:44 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 27 Nov 2020 14:17:44 -0500 Subject: [TUHS] Why do compress(1) and pack(1) use the .Z / .z extension? In-Reply-To: References: Message-ID: I thought the gz was because dos voilf not tell the difference between Z and z which was strange of course since it stored it on 8 bits unlike rt11 which used RAD50 (5bits) sigh. On Fri, Nov 27, 2020 at 2:00 PM Warner Losh wrote: > > > On Fri, Nov 27, 2020 at 10:17 AM Clem Cole wrote: > >> >> >> On Fri, Nov 27, 2020 at 8:08 AM Hans Wennborg wrote: >> >>> I'm trying to find out why compress(1) uses .Z as filename extension. >>> >>> My theory is that it was inspired by pack(1), which uses the .z >>> extension. >>> >> Yes. >> >> >> >>> >>> However, I haven't been able to find any info on why pack(1) uses that >>> extension. Does anyone here know? >>> >> No idea - but yes, Zucker used a .z at Rand when he wrote. >> >>> >>> Some searching led me to [1] which is a man page for pack from AUSAM. >>> It's written by Steve Zucker in 1975, so perhaps the extension is z for >>> Zucker? >>> >>> Was Zucker's pack(1) the first, though? This message [2] talks about a >>> Bell version. >> >> Zucker wrote it at Rand - early/mid 1970s. IIRC, It was later included in >> the original Harvard USENIX tape in the 'Rand' directory. I believe that >> Rand Pipes (named pipes) are in the same directory. Although some of the >> Rand stuff was being shared by folks on the ArpaNet before USENIX existed >> and I think it made it to the wild before the first USENIX tape. >> >> It was really important back in the day. Remember RK05's are only 2.5M >> bytes - source archiving and packing files was pretty important given the >> cost / byte of disk. >> >> I think there may have been an early version @ BTL - PWB may have >> distributed it also, but I'm fairly sure it was the Rand code that started >> it. Noel might remember more than I. I'm 90% sure we had it at CMU before >> we got either PWB 1.0 or UNIX/TS from Ted -- I want to say it we had it on >> 5th edition but maybe not. >> >> One of the PDP-10 folks will need to chime in here. My memory is there >> was something like pack(1) on the CMU PDP-10s and 20s that I saw before I >> saw the UNIX tool [not sure why I think this, but it may have been SAIL >> program - I remember looking at a number of simple tools when I learn SAIL >> years and years ago - 74/75-ish]. IIRC they were not exactly the same >> format as the 10's were 36-bit words, stored 5 chars in a word, but it was >> the same idea. >> > > Regardless of the early history, this is why gzip files end in .gz and not > .z. The pack'd files were considered too prevalent at the time to crowd > into that name space, even though this happened maybe 12 years after > compress started to displace pack. > > Warner > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Nov 29 09:12:52 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 29 Nov 2020 10:12:52 +1100 (EST) Subject: [TUHS] Apple IIe Unix? In-Reply-To: <20201127115444.E581018C091@mercury.lcs.mit.edu> References: <20201127115444.E581018C091@mercury.lcs.mit.edu> Message-ID: On Fri, 27 Nov 2020, Noel Chiappa wrote: > > I would start with something like Mini-Unix > > MINI-UNIX would be a good place to start if one wanted to bring up a > system on a machine without memory management; there's nothing in the > kernel which is PDP-11 dependent that I can think of (unlike V6, which > had a fairly heavy dependency on the PDP-11 memory management hardware - > although one could of course rip that all out, as MINI-UNIX did). Yeah, that's why I suggested it; I did play with it on one those PDT thingies some decades ago (just to see if I could; the thing was on loan). > However, one's still looking at a fair amount of work, both to get rid > of any traces of PDP-11isms (e.g. stack growth direction), and translate > the assembler part (startup, and access to non-C operations). Something > like FUZIX might be an easier option. Hadn't heard of FUZIX, but after looking at the web page then I concur; I'll keep it in mind should I ever get a tiny machine :-) I did have a fine collections of Microbees (Aussie Z-80 box) once, but they're long gone, along with enough bits to make an Applix 1616 (Aussie 68000 box). -- Dave From j at tllds.com Mon Nov 30 13:10:17 2020 From: j at tllds.com (Joachim) Date: Sun, 29 Nov 2020 19:10:17 -0800 Subject: [TUHS] The UNIX Command Language (1976) Message-ID: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Apologies if this has already been linked here. "The UNIX Command Languageis the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." https://github.com/susam/tucl Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Mon Nov 30 18:30:03 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 30 Nov 2020 09:30:03 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: An HTML attachment was scrubbed... URL: From brantley at coraid.com Mon Nov 30 23:36:58 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 30 Nov 2020 13:36:58 +0000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: Thank you very much! I've been looking for where Ken used the "much needed gap" phrase. Brantley > On Nov 29, 2020, at 10:10 PM, Joachim via TUHS wrote: > > Apologies if this has already been linked here. > > "The UNIX Command Language is the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl > > > Joachim