From perry at piermont.com Thu Nov 4 06:53:31 2021 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 3 Nov 2021 16:53:31 -0400 Subject: [TUHS] First Edition 50th publication anniversary... Message-ID: <9928bb59-00f6-2232-8add-09ebd27d89c9@piermont.com> According to https://www.bell-labs.com/usr/dmr/www/1stEdman.html : The first edition of the Unix Programmer's Manual was dated November 3, 1971 So, Happy 50th Birthday, First Edition! Perry From hummsmith42 at gmail.com Thu Nov 4 07:53:10 2021 From: hummsmith42 at gmail.com (Humm) Date: Wed, 3 Nov 2021 21:53:10 +0000 Subject: [TUHS] First Edition 50th publication anniversary... In-Reply-To: <9928bb59-00f6-2232-8add-09ebd27d89c9@piermont.com> References: <9928bb59-00f6-2232-8add-09ebd27d89c9@piermont.com> Message-ID: UNIX, it’s the birthday of your first edition. At that point, you didn’t know what would become your mission: You would take over the world, quite rapidly, Having an important place in our little history. Of you, some people were fond. Despite not having pipes, they might have seen a certain ideology, Or it was all practical before later, when it was known as “the philosophy,” Liking which, today, I use 9front. -- Humm From jay-tuhs9915 at toaster.com Sun Nov 7 02:21:59 2021 From: jay-tuhs9915 at toaster.com (Jay Logue) Date: Sat, 6 Nov 2021 09:21:59 -0700 Subject: [TUHS] retro-fuse support for v7 filesystems Message-ID: <20211106163017.CDEF59CEB8@minnie.tuhs.org> Just a quick note to announce that the retro-fuse project now supports mounting seventh-edition file systems for read and write on Linux and MacOS.  As was done for v6, the project incorporates the actual filesystem code from v7 Unix, lightly modernized to run in user space on current systems. The code is available on github for anyone who's interested: https://github.com/jaylogue/retro-fuse --Jay From clemc at ccc.com Sun Nov 7 03:00:29 2021 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Nov 2021 18:00:29 +0100 Subject: [TUHS] retro-fuse support for v7 filesystems In-Reply-To: <20211106163017.CDEF59CEB8@minnie.tuhs.org> References: <20211106163017.CDEF59CEB8@minnie.tuhs.org> Message-ID: Very slick -- can't wait to play with it a little bit. Thank you. ᐧ On Sat, Nov 6, 2021 at 5:32 PM Jay Logue via TUHS wrote: > Just a quick note to announce that the retro-fuse project now supports > mounting seventh-edition file systems for read and write on Linux and > MacOS. As was done for v6, the project incorporates the actual > filesystem code from v7 Unix, lightly modernized to run in user space on > current systems. > > The code is available on github for anyone who's interested: > https://github.com/jaylogue/retro-fuse > > --Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Nov 14 04:45:54 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 13 Nov 2021 13:45:54 -0500 Subject: [TUHS] macro returning a value? Message-ID: > Is there a trick to make a macro or string return a value? I know what you mean. Though a string does return a value, it can't compute an arithmetic result. Alternatively, a macro, which can use arithmetic, can only return the result as a distinct input line. (That might be overcome by a trick with \c, but I don't see one right off.) Though I have no useful advice about this dilemma, it does spur memories. I wrote the pre-Unix roff that was reimplemented on Unix and then superseded by Joe Ossanna's nroff. Joe introduced macros. Curiously, I had implemented macros in an assembler so early on (1959) that I have (incorrectly) been cited as the father of macros, yet it never occurred to me to put them in roff. Joe's work inspired me to add macros to pre-Unix roff. I did one thing differently. A macro could be called the usual way or it could be called inline like an nroff string. The only difference was that a macro's final newline was omitted when it was expanded inline. That implementation might have helped with the dilemma. Doug From alanglasser at gmail.com Sun Nov 14 10:52:11 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Sat, 13 Nov 2021 19:52:11 -0500 Subject: [TUHS] First(?) C Reference Manual Message-ID: <258FA532-EB91-4F50-BA44-4A13420D734E@gmail.com> I have been looking for some time for a C Reference Manual from early 1973 (or late 1972) where Dennis comments that multiple array subscripts will eventually have Fortran-like syntax with commas separating rather than multiple sets of square brackets. That was the first C manual I had back when I first learned the language. Silly me, I discarded it when a newer one was issued, not realizing the historical significance of the earlier one. - Alan From clemc at ccc.com Mon Nov 15 00:37:28 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 14 Nov 2021 09:37:28 -0500 Subject: [TUHS] Book Recommendation Message-ID: I wanted to pass on a recommendation of a new book from MIT Press called: “A New History of Computing” by Thomas Haigh and Paul Cerruzzi, ISBN 978-0-262-54299-0 Full disclosure, I reviewed a bit of it for them and have been eagerly awaiting final publication. I do expect a lot of the readers of this mailing list will enjoy it. They did a super job researching it and it’s very complete and of course, interesting. FWIW: the work of a number people that are part of this list is nice chronicled. Clem -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From drb at msu.edu Mon Nov 15 00:55:41 2021 From: drb at msu.edu (Dennis Boone) Date: Sun, 14 Nov 2021 09:55:41 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: (Your message of Sun, 14 Nov 2021 09:37:28 -0500.) References: Message-ID: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> > I wanted to pass on a recommendation of a new book from MIT Press > called: “A New History of Computing” by Thomas Haigh and Paul Cerruzzi, > ISBN 978-0-262-54299-0 Any info on when it will be released? Even the MIT Press site doesn't seem to know about it yet. De From ralph at inputplus.co.uk Mon Nov 15 02:35:38 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 14 Nov 2021 16:35:38 +0000 Subject: [TUHS] Book Recommendation In-Reply-To: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> Message-ID: <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> Hi De, > > I wanted to pass on a recommendation of a new book from MIT Press > > called: “A New History of Computing” by Thomas Haigh and Paul > > Cerruzzi, ISBN 978-0-262-54299-0 > > Any info on when it will be released? seem to know about it yet. amazon.com, he say 2021-09-14. https://amzn.to/3qDVV8G ISBN-13: 978-0262542906 ISBN-10: 0262542900 -- Cheers, Ralph. From lm at mcvoy.com Mon Nov 15 04:20:11 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 14 Nov 2021 10:20:11 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> Message-ID: <20211114182011.GZ29488@mcvoy.com> On Sun, Nov 14, 2021 at 04:35:38PM +0000, Ralph Corderoy wrote: > Hi De, > > > > I wanted to pass on a recommendation of a new book from MIT Press > > > called: ???A New History of Computing??? by Thomas Haigh and Paul > > > Cerruzzi, ISBN 978-0-262-54299-0 > > > > Any info on when it will be released? seem to know about it yet. > > amazon.com, he say 2021-09-14. > > https://amzn.to/3qDVV8G > ISBN-13: 978-0262542906 > ISBN-10: 0262542900 Thanks for the link, ordered. The reviews make it sound good but Clem's advice was enough. From clemc at ccc.com Mon Nov 15 04:44:05 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 14 Nov 2021 13:44:05 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> Message-ID: Sorry- Two typos it is “Modern Computing” in the title of the book and only one r in Paul’s last name. As I understand it, the Book should be available now. A friend of mine says he had downloaded the Kindle version already and as the lead HW designer of the 360/50 his comment to me today was reading just the the table of contents is already bringing back “some wonderful memories.” On Sun, Nov 14, 2021 at 11:45 AM Ralph Corderoy wrote: > Hi De, > > > > I wanted to pass on a recommendation of a new book from MIT Press > > > called: “A New History of Computing” by Thomas Haigh and Paul > > > Cerruzzi, ISBN 978-0-262-54299-0 > > > > Any info on when it will be released? seem to know about it yet. > > amazon.com, he say 2021-09-14. > > https://amzn.to/3qDVV8G > ISBN-13: 978-0262542906 > ISBN-10: 0262542900 > > -- > Cheers, Ralph. > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Nov 15 04:52:20 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 14 Nov 2021 18:52:20 +0000 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> Message-ID: <20211114185220.B54B71FB32@orac.inputplus.co.uk> Hi Clem, > > > > ISBN 978-0-262-54299-0 ... > > https://amzn.to/3qDVV8G > > ISBN-13: 978-0262542906 > > ISBN-10: 0262542900 > > Sorry- Two typos it is “Modern Computing” in the title of the book and > only one r in Paul’s last name. Three: the ISBN you gave doesn't match Amazon's. :-) That's how I tried finding it first and why I thought the URL might be useful. -- Cheers, Ralph. From clemc at ccc.com Mon Nov 15 05:27:25 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 14 Nov 2021 14:27:25 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: <20211114185220.B54B71FB32@orac.inputplus.co.uk> References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> <20211114185220.B54B71FB32@orac.inputplus.co.uk> Message-ID: That the us never from the back cover of my copy On Sun, Nov 14, 2021 at 1:52 PM Ralph Corderoy wrote: > Hi Clem, > > > > > > ISBN 978-0-262-54299-0 > ... > > > https://amzn.to/3qDVV8G > > > ISBN-13: 978-0262542906 > > > ISBN-10: 0262542900 > > > > Sorry- Two typos it is “Modern Computing” in the title of the book and > > only one r in Paul’s last name. > > Three: the ISBN you gave doesn't match Amazon's. :-) > That's how I tried finding it first and why I thought the URL might be > useful. > > -- > Cheers, Ralph. > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Nov 15 19:49:00 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 15 Nov 2021 09:49:00 +0000 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211114145541.B53742B56EE@yagi.h-net.msu.edu> <20211114163538.9F6CD1FB32@orac.inputplus.co.uk> <20211114185220.B54B71FB32@orac.inputplus.co.uk> Message-ID: <20211115094900.230FC21F15@orac.inputplus.co.uk> Hi Clem, > > > > > > ISBN 978-0-262-54299-0 > > ... > > > > https://amzn.to/3qDVV8G > > > > ISBN-13: 978-0262542906 > > > > ISBN-10: 0262542900 ... > > Three: the ISBN you gave doesn't match Amazon's. :-) > > That's how I tried finding it first and why I thought the URL might > > be useful. > > That the us never from the back cover of my copy > > Sent from a handheld expect more typos than usual I error-correct that to ‘That was the US number from...’. :-) If so, I think you've either missed a subtlety in the emails, something's gone wrong in publishing, or you had a pre-print where they didn't know the final number for the back cover? Yours: 978-0-262-54299-0 Fails ISBN's check-digit Mine: 978-0-262-54290-6 Added dashes to match Diff: ^ ^ Amazon's ‘Look Inside’ shows a paperback ISBN-13 of 9780262542906 which matches what they put on their web page. OpenLibrary give the same, https://openlibrary.org/books/OL32702646M/A_New_History_of_Modern_Computing as does the Library of Congress catalogue entry. Anyway, it does look interesting. I see from the index that they even mention the Acorn Archimedes, the world's first consumer device with a RISC chip, the Acorn RISC Machine, AKA the ARM 2. I learnt ARM assembler on the A310 model before switching to the R140 which shipped with RISC iX, Acorn's Unix, and I still get asked to do the odd bit of swtch() assembler porting on embedded ARM Cortex. -- Cheers, Ralph. From gtaylor at tnetconsulting.net Tue Nov 16 02:11:49 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 15 Nov 2021 09:11:49 -0700 Subject: [TUHS] Will someone please explain the history and usage of gpasswd / newgrp / sg? Message-ID: Hi, Will someone please explain the history and usage of gpasswd / newgrp / sg? I've run across them again recently while reading old Unix texts. I've been aware of them for years, but I've never actually used them for anything beyond kicking the tires. So I figured that I'd inquire of the hive mind that is TUHS / COFF. When was the concept of group passwords introduced? What was the problem that group passwords were the solution for? How common was the use of group passwords? I ran into one comment indicating that they used newgrp to work around a limitation in the number of (secondary) groups in relation to an NFS implementation. Specifically that the implementation of NFS they were using didn't support more than 16 groups. So they would switch their primary group to work around this limit. Does anyone have any interesting stories related to group passwords / gpasswd / newgrp / sg? -- 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 arrigo at alchemistowl.org Tue Nov 16 02:26:03 2021 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Mon, 15 Nov 2021 17:26:03 +0100 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: <6882B4A4-EE01-4189-B7E0-2E9BF5383272@alchemistowl.org> On 15 Nov 2021, at 17:11, Grant Taylor via COFF wrote: > I've run across them again recently while reading old Unix texts. I've been aware of them for years, but I've never actually used them for anything beyond kicking the tires. So I figured that I'd inquire of the hive mind that is TUHS / COFF. The only time I ever used it was back in the early ‘90s when on a SunOS system (dirac, for friends) it was used to allow graduate students access to the grading database (i.e. a text file) which was within a directory normally only accessible to teaching staff. The directory was group writable to a special “marking group” to which the various graduate students were added each term. We’d "newgrp grades” and type the password we had been given to be able to edit the file and add the grades for the assessments we had marked (for food money). I eventually became root on the machine and found my “su -“ screen to be a faster solution to accessing the file (sorry Franco, should you ever read this). Cheers, Arrigo From clemc at ccc.com Tue Nov 16 04:29:29 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 15 Nov 2021 13:29:29 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: Grant, Mashey and crew basically did most of the original group work as part of PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that is one of the places you will find differences. With Seventh Edition (or I believe as part of the UNIX/TS work that Ken picked up), the Mashey group changes went back into the Research stream. With one of the predecessors to 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy introduced the group scheme we all use today. The Mashey scheme allowed an UID to be assigned to multiple groups, but only use (be in) a single group during the process lifetime. IIRC the RJE system was based on it, but there were some other scripts that the PWB team needed. Check the original PWB docs, there is some explanation of them. FWIW: new group was added to be similar to switch user (su), to change the gid when the setguid bit was not set on the file. The truth is the early group stuff was not used by most admins. With BSD and use of UNIX for large systems (particularly academic teaching systems), the desire to have some processes be in more than one group and be able to test the group file protections accordingly was desired -- for things like creating a group for each class - where the hand in system was write-only to the class's TA who was also part of the group. I'm sure it was used in many other ways, but that was certainly one scheme we used at UCB when wnj added them. Again check the 4.2 docs, where the BSD group scheme is explained. This did seem useful and System V picked it up also fairly soon after BSD released it to the world, and fortunately did not change the BSD semantics. ᐧ On Mon, Nov 15, 2021 at 11:12 AM Grant Taylor via COFF wrote: > Hi, > > Will someone please explain the history and usage of gpasswd / newgrp / sg? > > I've run across them again recently while reading old Unix texts. I've > been aware of them for years, but I've never actually used them for > anything beyond kicking the tires. So I figured that I'd inquire of the > hive mind that is TUHS / COFF. > > When was the concept of group passwords introduced? > > What was the problem that group passwords were the solution for? > > How common was the use of group passwords? > > I ran into one comment indicating that they used newgrp to work around a > limitation in the number of (secondary) groups in relation to an NFS > implementation. Specifically that the implementation of NFS they were > using didn't support more than 16 groups. So they would switch their > primary group to work around this limit. > > Does anyone have any interesting stories related to group passwords / > gpasswd / newgrp / sg? > > > > -- > Grant. . . . > unix || die > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Nov 16 04:46:34 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 15 Nov 2021 13:46:34 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 at 13:31, Clem Cole wrote: > Grant, > > Mashey and crew basically did most of the original group work as part of > PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that > is one of the places you will find differences. With Seventh Edition (or I > believe as part of the UNIX/TS work that Ken picked up), the Mashey group > changes went back into the Research stream. With one of the predecessors to > 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy > introduced the group scheme we all use today. > > Looking at the TUHS archives, unless I'm missing something, 3BSD has groups that appear to be in the modern format: % ls -l /bsd/3bsd/etc/group -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group % cat /bsd/3bsd/etc/group staff:*:10:bill,ozalp grad:*:20: prof:*:30: % find . -name 'chgrp*' | xargs ls -l -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Nov 16 03:51:01 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 15 Nov 2021 09:51:01 -0800 Subject: [TUHS] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: <202111151751.1AFHp1ln896624@darkstar.fourwinds.com> Grant Taylor via TUHS writes: > Does anyone have any interesting stories related to group passwords / > gpasswd / newgrp / sg? Well, the most interesting one that I can remember was that there was a bug in 4.1BSD ?? where if you did newgrp and typed in an incorrect password it would make you root. From clemc at ccc.com Tue Nov 16 04:51:30 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 15 Nov 2021 13:51:30 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: 3BSD has the V7 scheme, the new kernel code where there is a group list in the process is not introduced until later/ ᐧ On Mon, Nov 15, 2021 at 1:46 PM Henry Bent wrote: > On Mon, 15 Nov 2021 at 13:31, Clem Cole wrote: > >> Grant, >> >> Mashey and crew basically did most of the original group work as part of >> PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that >> is one of the places you will find differences. With Seventh Edition (or I >> believe as part of the UNIX/TS work that Ken picked up), the Mashey group >> changes went back into the Research stream. With one of the predecessors to >> 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy >> introduced the group scheme we all use today. >> >> > Looking at the TUHS archives, unless I'm missing something, 3BSD has > groups that appear to be in the modern format: > > % ls -l /bsd/3bsd/etc/group > -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group > % cat /bsd/3bsd/etc/group > staff:*:10:bill,ozalp > grad:*:20: > prof:*:30: > % find . -name 'chgrp*' | xargs ls -l > -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp > -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 > -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 16 04:54:40 2021 From: imp at bsdimp.com (Warner Losh) Date: Mon, 15 Nov 2021 11:54:40 -0700 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: Yes. V7 had chgrp too. It dealt only with adjusting the group "ownership" of a file. Warner On Mon, Nov 15, 2021 at 11:52 AM Clem Cole wrote: > 3BSD has the V7 scheme, the new kernel code where there is a group list in > the process is not introduced until later/ > ᐧ > > On Mon, Nov 15, 2021 at 1:46 PM Henry Bent wrote: > >> On Mon, 15 Nov 2021 at 13:31, Clem Cole wrote: >> >>> Grant, >>> >>> Mashey and crew basically did most of the original group work as part of >>> PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that >>> is one of the places you will find differences. With Seventh Edition (or I >>> believe as part of the UNIX/TS work that Ken picked up), the Mashey group >>> changes went back into the Research stream. With one of the predecessors to >>> 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy >>> introduced the group scheme we all use today. >>> >>> >> Looking at the TUHS archives, unless I'm missing something, 3BSD has >> groups that appear to be in the modern format: >> >> % ls -l /bsd/3bsd/etc/group >> -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group >> % cat /bsd/3bsd/etc/group >> staff:*:10:bill,ozalp >> grad:*:20: >> prof:*:30: >> % find . -name 'chgrp*' | xargs ls -l >> -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp >> -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 >> -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c >> >> -Henry >> > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Nov 16 04:56:01 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 15 Nov 2021 13:56:01 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: Henry check out: http://gunkies.org/wiki/UNIX*_System_V_and_4.1C_BSD Page 25 describes the new BSD group and identifier scheme. ᐧ On Mon, Nov 15, 2021 at 1:51 PM Clem Cole wrote: > 3BSD has the V7 scheme, the new kernel code where there is a group list in > the process is not introduced until later/ > ᐧ > > On Mon, Nov 15, 2021 at 1:46 PM Henry Bent wrote: > >> On Mon, 15 Nov 2021 at 13:31, Clem Cole wrote: >> >>> Grant, >>> >>> Mashey and crew basically did most of the original group work as part of >>> PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that >>> is one of the places you will find differences. With Seventh Edition (or I >>> believe as part of the UNIX/TS work that Ken picked up), the Mashey group >>> changes went back into the Research stream. With one of the predecessors to >>> 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy >>> introduced the group scheme we all use today. >>> >>> >> Looking at the TUHS archives, unless I'm missing something, 3BSD has >> groups that appear to be in the modern format: >> >> % ls -l /bsd/3bsd/etc/group >> -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group >> % cat /bsd/3bsd/etc/group >> staff:*:10:bill,ozalp >> grad:*:20: >> prof:*:30: >> % find . -name 'chgrp*' | xargs ls -l >> -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp >> -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 >> -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c >> >> -Henry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Nov 16 05:09:28 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 15 Nov 2021 14:09:28 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 at 13:56, Clem Cole wrote: > Henry check out: http://gunkies.org/wiki/UNIX*_System_V_and_4.1C_BSD > Page 25 describes the new BSD group and identifier scheme. > Ah, I see, thanks for the pointer: "System V uses the old V7/32V group scheme: a user may have access to a login group (specified in /etc/passwd) and also to several other groups (as permitted by /etc/group), but may be in only one group at a time." Looking at https://github.com/robohack/ucb-csrg-bsd/commits/master/usr.sbin/chown/chgrp.c , the commit stating "new with multiple groups" is dated March 5, 1982 which would put it around 4.1a. -Henry > ᐧ > > On Mon, Nov 15, 2021 at 1:51 PM Clem Cole wrote: > >> 3BSD has the V7 scheme, the new kernel code where there is a group list >> in the process is not introduced until later/ >> ᐧ >> >> On Mon, Nov 15, 2021 at 1:46 PM Henry Bent >> wrote: >> >>> On Mon, 15 Nov 2021 at 13:31, Clem Cole wrote: >>> >>>> Grant, >>>> >>>> Mashey and crew basically did most of the original group work as part >>>> of PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, >>>> that is one of the places you will find differences. With Seventh Edition >>>> (or I believe as part of the UNIX/TS work that Ken picked up), the Mashey >>>> group changes went back into the Research stream. With one of the >>>> predecessors to 4.2BSD (it may have 4.1A or 4.1B but frankly I have >>>> forgotten) Joy introduced the group scheme we all use today. >>>> >>>> >>> Looking at the TUHS archives, unless I'm missing something, 3BSD has >>> groups that appear to be in the modern format: >>> >>> % ls -l /bsd/3bsd/etc/group >>> -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group >>> % cat /bsd/3bsd/etc/group >>> staff:*:10:bill,ozalp >>> grad:*:20: >>> prof:*:30: >>> % find . -name 'chgrp*' | xargs ls -l >>> -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp >>> -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 >>> -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c >>> >>> -Henry >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Nov 16 05:27:26 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 15 Nov 2021 14:27:26 -0500 (EST) Subject: [TUHS] Double posting Message-ID: <20211115192726.6AD6818C090@mercury.lcs.mit.edu> Can people **please** send posts to one of these two lists, only? Having to go through and delete every other post (yeah, I know, I could relete _all_ messages to either list, since they are archived, but old habits are hard to break) is _really_ annoying. OK, I can see sending an _initial_ query to both lists, to get it to as wide a circle as possible: _but_ BCC at least one of them, to prevent lazy people just hitting 'reply all' and thereby sanding out multiple copies of their reply. Thank you. Noel From will.senn at gmail.com Tue Nov 16 05:57:59 2021 From: will.senn at gmail.com (Will Senn) Date: Mon, 15 Nov 2021 13:57:59 -0600 Subject: [TUHS] Double posting In-Reply-To: <20211115192726.6AD6818C090@mercury.lcs.mit.edu> References: <20211115192726.6AD6818C090@mercury.lcs.mit.edu> Message-ID: <5402826f-3097-821a-74d0-5ff862ad8056@gmail.com> On 11/15/21 1:27 PM, Noel Chiappa wrote: > Can people **please** send posts to one of these two lists, only? Having to go > through and delete every other post (yeah, I know, I could relete _all_ > messages to either list, since they are archived, but old habits are hard to > break) is _really_ annoying. > > OK, I can see sending an _initial_ query to both lists, to get it to as wide > a circle as possible: _but_ BCC at least one of them, to prevent lazy people > just hitting 'reply all' and thereby sanding out multiple copies of their > reply. > > Thank you. > > Noel > amen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Nov 16 06:57:11 2021 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 16 Nov 2021 06:57:11 +1000 Subject: [TUHS] [COFF] Double posting In-Reply-To: <20211115192726.6AD6818C090@mercury.lcs.mit.edu> References: <20211115192726.6AD6818C090@mercury.lcs.mit.edu> Message-ID: <20211115205711.GA16126@minnie.tuhs.org> On Mon, Nov 15, 2021 at 02:27:26PM -0500, Noel Chiappa wrote: > OK, I can see sending an _initial_ query to both lists, to get it to as wide > a circle as possible: _but_ BCC at least one of them, to prevent lazy people > just hitting 'reply all' and thereby sanding out multiple copies of their > reply. I've just disabled "require explicit destination" on both the TUHS and COFF lists. Let's see if that allows bcc between them. Cheers, Warren From arnold at skeeve.com Tue Nov 16 06:17:09 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 15 Nov 2021 13:17:09 -0700 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: References: Message-ID: <202111152017.1AFKH9Om032644@freefriends.org> Clem Cole wrote: > I'm sure it was used in many other ways, but that was certainly one scheme > we used at UCB when wnj added them. Again check the 4.2 docs, where the > BSD group scheme is explained. This did seem useful and System V picked > it up also fairly soon after BSD released it to the world, and fortunately > did not change the BSD semantics. Not so soon, really. The new group scheme was widely released with 4.2 BSD (~ 1983). System V didn't pick up multiple groups until System V Release 4, circa 1989. Arnold From clemc at ccc.com Tue Nov 16 07:37:55 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 15 Nov 2021 16:37:55 -0500 Subject: [TUHS] [COFF] Will someone please explain the history and usage of gpasswd / newgrp / sg? In-Reply-To: <202111152017.1AFKH9Om032644@freefriends.org> References: <202111152017.1AFKH9Om032644@freefriends.org> Message-ID: Fair enough. ᐧ On Mon, Nov 15, 2021 at 3:17 PM wrote: > Clem Cole wrote: > > > I'm sure it was used in many other ways, but that was certainly one > scheme > > we used at UCB when wnj added them. Again check the 4.2 docs, where the > > BSD group scheme is explained. This did seem useful and System V picked > > it up also fairly soon after BSD released it to the world, and > fortunately > > did not change the BSD semantics. > > Not so soon, really. The new group scheme was widely released with > 4.2 BSD (~ 1983). System V didn't pick up multiple groups until > System V Release 4, circa 1989. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Nov 16 13:16:41 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 15 Nov 2021 22:16:41 -0500 Subject: [TUHS] Book Recommendation Message-ID: While waiting to see the full text, I've poked around the index for subjects of interest. It certainly is copious, and knows about a lot of things that I don't. The authors make a reasonable choice in identifying the dawn of "modern computing" with Eniac and relegating non-electronic machines to prehistory. Still, I was glad to find the prophetic Konrad Zuse mentioned, but disappointed not to find the Bell Labs pioneer, George Stibitz. Among programming languages, Fortran, which changed the nature of programming, is merely hinted at (buried in the forgettable Fortran Monitoring System), while its insignificant offspring PL/I is present. (Possibly this is an indexing oversight. John Backus, who led the Fortran project, is mentioned quite early in the book.) Algol, Lisp, Simula and Smalltalk quite properly make the list, but Basic rates more coverage than any of them. C, obscurely alphabetized as "C language", is treated generously, as is Unix in general. Surprisingly there's almost nothing in the index about security or privacy. The litany of whiggish chapters about various uses of computers needs a cautionary complement. "The computer attracts crooks and spies" would be a stylistically consistent title. Doug From g.branden.robinson at gmail.com Tue Nov 16 14:08:59 2021 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 16 Nov 2021 15:08:59 +1100 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> At 2021-11-15T22:16:41-0500, Douglas McIlroy wrote: > While waiting to see the full text, I've poked around the index for > subjects of interest. It certainly is copious, and knows about a lot > of things that I don't. > > The authors make a reasonable choice in identifying the dawn of > "modern computing" with Eniac and relegating non-electronic machines > to prehistory. Just so long as the antikythera mechanism is in there... ;-) > Among programming languages, Fortran, which changed the nature of > programming, is merely hinted at (buried in the forgettable Fortran > Monitoring System), while its insignificant offspring PL/I is present. PL/I was important enough to rate presentation in _The Elements of Programming Style_. :P I have gotten the impression that it was a language that was beloved by no one. > (Possibly this is an indexing oversight. John Backus, who led the > Fortran project, is mentioned quite early in the book.) Algol, Lisp, > Simula and Smalltalk quite properly make the list, but Basic rates > more coverage than any of them. It's hard to overstate the impact of BASIC on the first generation of people who grew up with computers in the home instead of encountering them only later in a time-sharing environment with professional operators and administrators. This is not because BASIC was a high quality language, especially as stripped down by Microsoft and other implementors. On 8-bit boxes with no memory protection and no privilege structure, it taught one a lot about absolute liberty and the absolute consequences thereof. We power cycled machines with a frequency that would have horrified the staff of any computing center. Everybody knew there were bigger, better, or faster languages out there, but they were priced commercially and marketed at professionals. The same was usually true of editor/assembler/linker packages. But BASIC was packed-in on ROM chips and always available. And you could always assemble your own opcodes (or get listings of hex bytes from hobbyist magazines) and "poke" them into memory--a good way to learn and to polish that machine reset button to a shine. At one time, it was considered good sport to ridicule people whose first programming language was BASIC; after a while I figured out that this was a form of hazing, similar to the snotty attitudes adopted by a subset of student employees who got access to group "wheel" on at least one university-owned machine, lorded it over undergraduates, and who kept the existence of or access to Volume 2 of the Unix Programmer's Manual a secret. ("If you can't learn the system just from the man pages, you must be pretty dumb.") Such was my first exposure to BSD and SunOS partisans. After a while, I learned they weren't _all_ like that... Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Wed Nov 17 00:56:58 2021 From: clemc at ccc.com (Clem Cole) Date: Tue, 16 Nov 2021 09:56:58 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: On Mon, Nov 15, 2021 at 11:09 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > It's hard to overstate the impact of BASIC on the first generation of > people who grew up with computers in the home instead of encountering > them only later in a time-sharing environment with professional > operators and administrators. > FWIW: A number of us learned BASIC in the late 1960s/early 1970s (*i.e.* before the microprocessor versions ever appeared as they did not yet exist). Gates & Allen used it in HS on a PDP-10 with an ASR-33, and I'm their same age. I did the same thing in JHS and HS on a GE-635 [Mark-II DTSS] and then later HP2000 [Community Computer Services] - 10 cps baby, upper case only. What I don't know is if the PDP-8 BASIC came before the PDP-10 version. But the point is that most of the mini's (no matter the manufacturer) had an implementation of BASIC in the late 60s and early 1970s, long before the micro's came on the scene. I would later get to know/work with a number of the people in DEC languages groups and I do know that the syntax and semantics of the BASIC for RSTS implementation originally was based on the PDP-10 BASIC (although they did have some differences). In fact, DEC's RSTS/11 and the HP/2100 running BASIC were the two systems that ended up being used by a lot of small timesharing shops and eventually on-site at the high schools that could afford the HW. The reason being that BASIC became popular on the small system was it required fewer resources and because it was primarily interpreted matched. An urban legend is that when Gates opened in Microsoft in AZ, he bartered time from the local high school running their RSTS system for them in return for being able to use it as their development system [I definitely know that he used their system, I'm just now sure how he renumerated them for the computer time]. > This is not because BASIC was a high quality language, especially as > stripped down by Microsoft and other implementors. It made perfect sense when Gates decided to implement it for the Altair. And he modeled his version on the DEC syntax and semantics - because that was what he knew was used to from the PDP-10, and what he and Paul had learned first. > Everybody knew there were bigger, better, or faster languages out there, > but they were priced commercially and marketed at professionals. And more importantly, *requires many more resources*. Consider UCSD-Pascal, you needed a disk-based system to run it, be an LSI-11, Apple-IIe, or CP/M box. The BASIC's often worked out of ROM. Hey, I can think of implementations of other languages such as FORTRAN's, C, Cobol, PL/M, PL/1, and eventually many Pascals for the different micro's, but they all took more HW to support the edit/compile/link cycle. The point is that for a >>hobbyist<<, running BASIC was 'good enough.' The only HS in the late 1970s that I knew that could afford a PDP 11/45 and actually ran UNIX on it, was Lincoln-Sudbury - which is in a high-end suburban Boston. They also had a lot of help from parents who per professionals here in Boston working for places like DEC, DG, Pr1me, Honeywell, and the like. At that time, I was long gone, but I now my father at my own prep school in suburban Philadelphia dreamed of an 11/40 class system to run RSTS, but they could not afford it. So if they wanted off a timesharing service like the HP/21000, they bought small microprocessor (CP/M or Apple-II) gear and ran them as a hobbyist would. > At one time, it was considered good sport to ridicule people whose first programming > language was BASIC; I'm not so much sure it was that their first language was BASIC, as much as they did not go beyond it. I will say that once the HW started to be able to support more complete languages (such as Pascal), there was some of that. I used to say the problem was that they probably learned it in HS and their teachers did know more. My own father (who taught me BASIC on the GE-635 when I was in JHS), knew only BASIC and FORTRAN because that was what he had learned working part-time as a 'computer' at Rocketdyne in the late 1950s/early 1960s. By the late 60s, he was the first 'computer teacher' at the prep school when I went (in Philadelphia, but not that dissimilar to Bill Gates's experiences in Seattle at a local prep school there). He taught us what he knew and *what he had access to*. Eventually, I outpaced him a bit, and I started to learn a little assembler for the HP because I was curious. But I came to a point where I knew way more than he did before I left HS [BTW: Gates and Allen tell a similar story - of learning PDP-10 assembler at some point -- advancing ahead of their teachers]. The truth is I think my Dad was a bit ahead of his time, *but he did not know what he did not know *and did know to try to teach others anything other than BASIC and FORTRAN*.* FWIW: I went to CMU and had to be re-taught - being introduced to Algol, real FORTRAN, IBM Assembler, APL (and eventually many of other wonders). BTW: By the mid/late '70s, I had taught my Dad Pascal so he could use it with USCD-Pascal with his 'advanced students' now that he had a few Apple-IIe's that could run it. > after a while I figured out that this was a form of hazing, similar to > the snotty attitudes adopted by a > subset of student employees > Point taken... and I there probably was a lot of those, particularly later once the HW ability and cost available made it possible to have a choice. But the problem was that most of the young people had come from places where the educators that taught them BASIC did not know better even if they had had enough HW to do it. Unfortunately, because the hobbyist and much of the press for entry-level of the same, touted BASIC, many did not know better. The fact is I'm still now sure the HS and JHS are a lot better than they were. I'll let Steinhart reply, but he wrote an excellent book recently targeted to just those same students that what to know more, but frankly their HS teachers really are not in a position to teach them properly. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Nov 17 00:57:55 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 16 Nov 2021 09:57:55 -0500 Subject: [TUHS] Book Recommendation Message-ID: The following remark stirred old memories. Apologies for straying off the path of TUHS. > I have gotten the impression that [PL/I] was a language that was beloved by no one. As I was a designer of PL/I, an implementer of EPL (the preliminary PL/I compiler used to build Multics), and author of the first PL/I program to appear in the ACM Collected Algorithms, it's a bit hard to admit that PL/I was "insignificant". I'm proud, though, of having conceived the SIGNAL statement, which pioneered exception handling, and the USES and SETS attributes, which unfortunately sank into oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. After the ACM program I never wrote another line of PL/I. Gratification finally came forty years on when I met a retired programmer who, unaware of my PL/I connection, volunteered that she had loved PL/I above all other programming languages. Doug From rich.salz at gmail.com Wed Nov 17 01:22:52 2021 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 16 Nov 2021 10:22:52 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: > The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > You seem to have a gift for notation. That's rare. Curious what you think of APL? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Wed Nov 17 01:37:47 2021 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 16 Nov 2021 10:37:47 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: > What I don't know is if the PDP-8 BASIC came before the PDP-10 version. This was a fun rat-hole. (My first programming was Edu-24 BASIC on a pdp-8/e my 7-12 school had.) It appears that the DEC-10 BASIC is earlier, at least according to how I intuit the timeline from https://en.wikipedia.org/wiki/BASIC-8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Nov 17 01:50:29 2021 From: athornton at gmail.com (Adam Thornton) Date: Tue, 16 Nov 2021 08:50:29 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: Dijkstra notwithstanding, BASIC has the same strengths and weaknesses as, later, PHP would for the web, and I think that Javascript might have these days (and in the scientific programming world, Python). That is, it's very easy for the novice to get something working that gives them the results they want. Maintainability and efficiency are simply not on their radar for the scope of problem they're trying to solve. I'm not even sure how much of this you can lay at the feet of teachers: I would argue that we see a huge efflorescence of essentially self-taught programming cobbled together from (in the old days) the system manuals and programs in magazines, and (these days) Googling that takes you to Stack Overflow and various tutorials, of wildly varying quality. Maybe we should take the "personal" in "personal computing" seriously. That said, now that your personal project is probably exposed to the world via the Web, maybe that's not a good idea if you have any data behind that project whose integrity or privacy you care about. Disclaimer: my formative experiences were MS BASIC on 6502-based micros, and were fundamentally self-taught. Adam On Tue, Nov 16, 2021 at 8:38 AM Richard Salz wrote: > > What I don't know is if the PDP-8 BASIC came before the PDP-10 version. > > This was a fun rat-hole. (My first programming was Edu-24 BASIC on a > pdp-8/e my 7-12 school had.) It appears that the DEC-10 BASIC is earlier, > at least according to how I intuit the timeline from > https://en.wikipedia.org/wiki/BASIC-8 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Nov 17 01:52:51 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 16 Nov 2021 15:52:51 +0000 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: PL/I was my introduction to structured programming (though it took a somewhat loose approach to that). I always Over my early years I spent time on a couple of implementations and always had been amused by its somewhat COBOLish IO scheme and spent a little time dabbling in variants such as the IBM PL/S, UNIVAC PLUS, and the UofM interpretted PLUM. Then I got introduced to C and it was all downhill from there :) ------ Original Message ------ From: "Douglas McIlroy" To: "TUHS main list" Sent: 11/16/2021 9:57:55 AM Subject: Re: [TUHS] Book Recommendation >The following remark stirred old memories. Apologies for straying off >the path of TUHS. > >> I have gotten the impression that [PL/I] was a language that was beloved by no one. > >As I was a designer of PL/I, an implementer of EPL (the preliminary >PL/I compiler used to build Multics), and author of the first PL/I >program to appear in the ACM Collected Algorithms, it's a bit hard to >admit that PL/I was "insignificant". I'm proud, though, of having >conceived the SIGNAL statement, which pioneered exception handling, >and the USES and SETS attributes, which unfortunately sank into >oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. >The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > >After the ACM program I never wrote another line of PL/I. >Gratification finally came forty years on when I met a retired >programmer who, unaware of my PL/I connection, volunteered that she >had loved PL/I above all other programming languages. > >Doug From ron at ronnatalie.com Wed Nov 17 02:02:03 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 16 Nov 2021 16:02:03 +0000 Subject: [TUHS] BASIC, RSTS, and UNIX In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: My BASIC experience came from the HP/2000 (and the HP/3000) systems the Prince George's County (MD) schools had at the time. When I moved on to Johns Hopkins, I was sent a letter in advance of my freshman year from professor Bill Huggins who taught one of the freshman EE classes. The class was to use Basic Plus on a PDP-11/45s using the UNIX operating system. Now at this point, I had a friend whose mother worked in the local DEC (Lanham, MD) office and would let us raid the stock room for things like processor handbooks and the like. I was able to find out about Basic Plus and PDP-11/45 but I was unable to find anything about this UNIX thing. Of course, once I got there I found that the EE computer center was largely run by students under the name of the Undergraduate Computer Society. Mike Muuss was in charge and they had made a deal that if they could get BasicPlus migrated over from RSTS, they could run UNIX on the machine. It turned out not to be that difficult. RSTS, like most DEC OSes, for some reason used EMT for the system calls (contrary to what the processor handbook would recommend). UNIX used TRAP. This means all they had to do is emulate a few RSTS calls. In addition, the only change I believe was to add a system call that disabled the UNIX idea of stack management (Basic Plus like many DEC programs of the day used a relatively small stack in low memory because the actual register saves, etc... were stored elsewhere, it was just function call linkage). The system call was obviously called "nostack." This hadn't been Mike's only foray into Basic. He had his own IBM 1130 and had written a Basic interpretter under contract for the Baltimore County Public Schools. I remember sitting in the "KSR room" at Hopkins and watching him preparing the invoice for payment. Please remit $3000, no stamps please. That last part caused a bit of consternation at the school district. Amusingly, I have my little Raspberry Pi scale model 11/70 front panel churning away on my desk. I can switch it from booting up various UNIXes (mostly I run 2.9 BSD hacked to somewhat look like JHU UNIX) and RSTS which reinforces why we used to refer to it as the Really Sh-tty Timesharing System. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Nov 17 02:43:23 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 16 Nov 2021 16:43:23 +0000 Subject: [TUHS] Speaking of groups: JHU Ownership In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: A private message with Uh, Clem reminds me of another quaint piece of UNIX group history: JHU Ownership. The original V6 kernel and file systems used a char for UID and GID. This meant that you could only have 255 (plus the root user) distinct users on the machine. The JHU PDP-11/45 was used for the EE classes and we had more than that many users. The kernel was modified to check if the GID was 200 or greater. If it was, that was taken along with the UID to be part of the user identity. We gave all the class accounts such GIDs. Of course, we had to be careful about newgrp and fun and games with setuid/setgid (both the system call and the bits on the executables). I spent a lot of my time looking for exploits there and fixing them once I (or someone else) found them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Nov 17 03:00:52 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 16 Nov 2021 12:00:52 -0500 Subject: [TUHS] Book Recommendation Message-ID: >> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > You seem to have a gift for notation. That's rare. Curious what you think of APL? I take credit as a go-between, not as an inventor. Ken Knowlton introduced the notation ABC in BEFLIX, a pixel-based animation language. Ken didn't need an operator because identifiers were single letters. I showed Ken's scheme to Bud Lawson, the originator of PL/I's pointer facility. Bud liked it and came up with the vivid -> notation to accommodate longer identifiers. If I had a real gift of notation I would have come up with the pipe symbol. In my original notation ls|wc was written ls>wc>. Ken Thompson invented | a couple of months later. That was so influential that recently, in a paper that had nothing to do with Unix, I saw | referred to as the "pipe character"! APL is a fascinating invention, but can be so compact as to be inscrutable. (I confess not to have practiced APL enough to become fluent.) In the same vein, Haskell's powerful higher-level functions make middling fragments of code very clear, but can compress large code to opacity. Jeremy Gibbons, a high priest of functional programming, even wrote a paper about deconstructing such wonders for improved readability. Human impatience balks at tarrying over a saying that puts so much in a small space. Yet it helps once you learn it. Try reading transcripts of medieval Arabic algebra carried out in words rather than symbols. Iverson's hardware descriptions in APL are another case where symbology pays off. Doug From will.senn at gmail.com Wed Nov 17 03:02:57 2021 From: will.senn at gmail.com (Will Senn) Date: Tue, 16 Nov 2021 11:02:57 -0600 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: I still heart BASIC. I enjoy it's simplicity. I started out on BASIC with a Commodore Pet ca. 1978. I still like to fire it up every now and then - Chipmunk on my Macbook, BAS/BAS2 on RSTS/11, RSX-11, BBC basic? on RISC OS, doesn't matter, they all do a fair job of BASIC. I especially like firing up  Berhard's pdp 8 simulator with teletype emulation and coding on the teletype - https://www.bernhard-baehr.de/pdp8e/pdp8e.html. Unix... well, I've not been real successful in getting it to work on v6, other folks maybe, but not me. By work, I mean, I type in reasonable BASIC and it runs reasonably :). The bas executable work fine, it's the human-computer interface that doesn't seem to wanna work, nothing I type in as a program more complex than 'hello, world' will run with any reliability. On another note, I remember the days when people bad mouthed lovers of BASIC (in industry) and acted as though they were simpletons, later they became haters on VB folks. When I learned C, in my twenties, I felt empowered, but at the same time hamstrung, some of the simplest things in BASIC became an odyssey in C. Nowadays, I use Python more than anything else these (boring data sciency stuff). What I like about Python is that it reminds me of BASIC in its simplicity of expression, but to be fair, it goes far, far beyond it in power... I just wish it were as free form as Ruby in how you say, what you say... any, I digress... My favorite BASIC book: My Computer Likes Me* *when I speak in BASIC by Bob Albrecht Written in 1972 (for a teletype interface) On a less positive note. The professors who originally developed it at Dartmouth could never quite see there way clear to open source it. True BASIC? pshaw :). There was a time when I would have loved to run BASIC on linux, bsd, then Mac and have it be consistent across the platforms, other than as a curiosity, that time has gone. My question for the group is what's BASIC's history in the unices? I know it's in v6, cuz I struggled with it there, but I'm curious what the backstory is? I have the impression that the marriage of bas and v6 was one of convenience, maybe there was a thought to draw in the hobbiest? Were Kemeny and Kurtz characters in the same circles as the unix folks? Later, Will On 11/16/21 8:56 AM, Clem Cole wrote: > > > On Mon, Nov 15, 2021 at 11:09 PM G. Branden Robinson > wrote: > > It's hard to overstate the impact of BASIC on the first generation of > people who grew up with computers in the home instead of encountering > them only later in a time-sharing environment with professional > operators and administrators. > > FWIW:   A number of us learned BASIC in the late 1960s/early 1970s > (/i.e./ before the microprocessor versions ever appeared as they did > not yet exist).  Gates & Allen used it in HS on a PDP-10 with an > ASR-33, and I'm their same age.   I did the same thing in JHS and HS > on a GE-635 [Mark-II DTSS] and then later HP2000 [Community Computer > Services] - 10 cps baby, upper case only. > > What I don't know is if the PDP-8 BASIC came before the PDP-10 > version.   But the point is that most of the mini's (nomatter the > manufacturer) had an implementation of BASICin the late 60s and early > 1970s, long before the micro's came on the scene.  I would later get > to know/work with a number of the people in DEC languages groups and I > do know that the syntax and semantics of the BASIC for RSTS > implementation originally was based on the PDP-10 BASIC (although they > did have some differences). > > In fact, DEC's RSTS/11 and the HP/2100 running BASIC were the two > systems that ended up being used by a lot of small timesharing shops > and eventually on-site at the high schools that could afford the HW. > The reason being that BASIC became popular on the small system was it > required fewer resources and because it was primarily interpreted > matched.  An urban legend is that when Gates opened in Microsoft in > AZ, he bartered time from the local high school running their RSTS > system for them in return for being able to use it as their > development system [I definitely know that he used their system, I'm > just now sure how he renumerated them for the computer time]. > > > This is not because BASIC was a high quality language, especially as > stripped down by Microsoft and other implementors. > > It made perfect sense when Gates decided to implement it for the > Altair.   And he modeled his version on the DEC syntax and semantics - > because that was what he knew was used to from the PDP-10, and what he > and Paul had learned first. > > Everybody knew there were bigger, better, or faster languages out > there, > but they were priced commercially and marketed at professionals. > > And more importantly, /requires many more resources/.  > Consider UCSD-Pascal, you needed a disk-based system to run it, be an > LSI-11, Apple-IIe, or CP/M box.  The BASIC's often worked out of ROM. >  Hey, I can think of implementations of other languages such as > FORTRAN's, C, Cobol, PL/M, PL/1, and eventually many Pascals for the > different micro's, but they all took more HW to support the > edit/compile/link cycle. > > The point is that for a >>hobbyist<<, running BASIC was 'good > enough.'  The only HS in the late 1970s that I knew that could afford > a PDP 11/45 and actually ran UNIX on it, was Lincoln-Sudbury - which > is in a high-end suburban Boston.  They also had a lot of help from > parents who per professionals here in Boston working for places like > DEC, DG, Pr1me, Honeywell, and the like.   At that time, I was long > gone, but I now my father at my own prep school in > suburban Philadelphia dreamed of an 11/40 class system to run RSTS, > but they could not afford it. So if they wanted off a timesharing > service like the HP/21000, they bought small microprocessor (CP/M or > Apple-II) gear and ran them as a hobbyist would. > > > At one time, it was considered good sport to ridicule people whose > firstprogramming language was BASIC; > > I'm not so much sure it was that their first language was BASIC, as > much as they did not go beyond it.   I will say that once the HW > started to be able to support more complete languages (such as > Pascal), there was some of that.  I used to say the problem was that > they probably learned it in HS and their teachers did know more. > > My own father (who taught me BASIC on the GE-635 when I was in JHS), > knew only BASIC and FORTRAN because that was what he had learned > working part-time as a 'computer' at Rocketdyne in the late > 1950s/early 1960s.   By the late 60s, he was the first 'computer > teacher' at the prep school when I went (in Philadelphia, but not that > dissimilar to Bill Gates's experiences in Seattle at a local prep > school there). He taught us what he knew and /what he had access to/. > Eventually, I outpaced him a bit, and I started to learn a little > assembler for the HP because I was curious. But I came to a point > where I knew way more than he did before I left HS [BTW: Gates and > Allen tell a similar story - of learning PDP-10 assembler at some > point -- advancing ahead of their teachers].  The truth is I think my > Dad was a bit ahead of his time, /but he did not know what he did not > know /and did know to try to teach others anything other than BASIC > and FORTRAN/./ > > FWIW: I went to CMU and had to be re-taught - being introduced to > Algol, real FORTRAN, IBM Assembler, APL (and eventually many of other > wonders). BTW: By the mid/late '70s, I had taught my Dad Pascal so he > could use it with USCD-Pascal with his 'advanced students' now that he > had a few Apple-IIe's that could run it. > > after a while I figured out that thiswas a form of hazing, similar > to the snotty attitudes adopted by a > subset of student employees > > Point taken... and I there probably was a lot of those, particularly > later once the HW ability and cost available made it possible to have > a choice. But the problem was that most of the young people had come > from places where the educators that taught them BASIC did not know > better even if they had had enough HW to do it. > > Unfortunately, because the hobbyist and much of the press for > entry-level of the same, touted BASIC, many did not know better.   The > fact is I'm still now sure the HS and JHS are a lot better than they were. > > I'll let Steinhart reply, but he wrote an excellent book recently > targeted to just those same students that what to know more, but > frankly their HS teachers really are not in a position to teach them > properly. > > Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Nov 17 03:54:16 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 16 Nov 2021 09:54:16 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: Message-ID: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> Douglas McIlroy writes: > APL is a fascinating invention, but can be so compact as to be > inscrutable. (I confess not to have practiced APL enough to become > fluent.) In the same vein, Haskell's powerful higher-level functions > make middling fragments of code very clear, but can compress large > code to opacity. Jeremy Gibbons, a high priest of functional > programming, even wrote a paper about deconstructing such wonders for > improved readability. Wasn't Perl created to fill this void? From ron at ronnatalie.com Wed Nov 17 03:57:30 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 16 Nov 2021 17:57:30 +0000 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> Message-ID: Awk bailing out near line 1. ------ Original Message ------ From: "Jon Steinhart" To: "TUHS main list" Sent: 11/16/2021 12:54:16 PM Subject: Re: [TUHS] Book Recommendation [ reallly inscrutable languages ] >Douglas McIlroy writes: >> APL is a fascinating invention, but can be so compact as to be >> inscrutable. (I confess not to have practiced APL enough to become >> fluent.) In the same vein, Haskell's powerful higher-level functions >> make middling fragments of code very clear, but can compress large >> code to opacity. Jeremy Gibbons, a high priest of functional >> programming, even wrote a paper about deconstructing such wonders for >> improved readability. > >Wasn't Perl created to fill this void? From crossd at gmail.com Wed Nov 17 04:00:47 2021 From: crossd at gmail.com (Dan Cross) Date: Tue, 16 Nov 2021 13:00:47 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> Message-ID: On Tue, Nov 16, 2021 at 12:57 PM Jon Steinhart wrote: > Douglas McIlroy writes: > > APL is a fascinating invention, but can be so compact as to be > > inscrutable. (I confess not to have practiced APL enough to become > > fluent.) In the same vein, Haskell's powerful higher-level functions > > make middling fragments of code very clear, but can compress large > > code to opacity. Jeremy Gibbons, a high priest of functional > > programming, even wrote a paper about deconstructing such wonders for > > improved readability. > > Wasn't Perl created to fill this void? > I thought Perl was a reaction to exceeding awk's tolerance for abuse? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Nov 17 04:04:26 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 16 Nov 2021 10:04:26 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> Message-ID: <20211116180426.GW10157@mcvoy.com> On Tue, Nov 16, 2021 at 09:54:16AM -0800, Jon Steinhart wrote: > Douglas McIlroy writes: > > APL is a fascinating invention, but can be so compact as to be > > inscrutable. (I confess not to have practiced APL enough to become > > fluent.) In the same vein, Haskell's powerful higher-level functions > > make middling fragments of code very clear, but can compress large > > code to opacity. Jeremy Gibbons, a high priest of functional > > programming, even wrote a paper about deconstructing such wonders for > > improved readability. > > Wasn't Perl created to fill this void? My belief is that perl was written to replace a lot of Unix pipelines, which are awesome when you discover them but less awesome as they become complex (error handling in a pipeline is pretty tricky if you actually want to handle stuff nicely). I was a huge fan of Perl 4, still am, wrote a source management system in it while at Sun. It wanted you to be pretty disciplined in how you wrote it or it becomes write only, but if you are, it was really pleasant. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Wed Nov 17 04:27:30 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 16 Nov 2021 10:27:30 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: <202111161827.1AGIRU1l930653@darkstar.fourwinds.com> Clem Cole writes: > Unfortunately, because the hobbyist and much of the press for entry-level > of the same, touted BASIC, many did not know better. The fact is I'm > still now sure the HS and JHS are a lot better than they were. > > I'll let Steinhart reply, but he wrote an excellent book recently targeted > to just those same students that what to know more, but frankly their HS > teachers really are not in a position to teach them properly. Well thanks Clem :-) I didn't actually hit BASIC until college where freshmen had to learn it on the PDP-8. Took me all of about 5 minutes to learn the language and about a half a day to do the entire semester of coursework. Got me off to a good start on annoying my professors. I think that my first programming language was SNAP running on a PDP8-E in the (I don't remember the exact name) Princeton computer barn. Because my dad worked at IBM I remember going over to his VP's house to learn APL on his home terminal. FORTRAN on I think an IBM 1620 was next. After that was Heinz's FSNAP on the Honeywell DDP-516 at BTL. Never thought to ask before, Heinz - was FSNAP based on SNAP? Assembler came after that, followed by C. I know, what's the difference? Then Pascal in college which was dreadful after C. I asked my professor to give me a few pointers on how to program with fixed length arrays but he couldn't give me any :-) It's my opinion that BASIC was a good thing in its day but that that time has passed. Part of what made it the goto language was its simplicity; there wasn't much to learn and there was no complex toolchain so time was spend on figuring out how to structure a problem so that it could be solved on a computer. In my not very humble opinion, this is the fundamental (or should I say basic) problem with CS education today; the effort is focused on learning the language and the toolchain, not how to think and solve problems. Somehow many of us learned to program in BASIC without a "Hello World" tutorial. Another big factor in those days was that the consequences for getting something wrong were pretty much nonexistent. What was the worst that could happen, you'd accidentally output an obscenity? Give what computers were used for back then, getting the math wrong was more likely than having a logic error. I didn't have to worry about buggy code destroying anything until a project where I modified FSNAP to control semiconductor test equipment. I have tried when mentoring to get people to start with simple character oriented programs but of course everyone (especially boys) want to start with a video game. This immediately means having to deal with multithreaded code (even if it's somewhat hidden) and complex APIs. All of this is a distraction from learning how to think and solve problems. As a result, we're producing a lot of "programmers" who can wrangle this stuff while having no idea how to solve a problem. I think that a glance at stackoverflow backs me up here. It's extremely frustrating: "I want to write a video game where I can shoot something." "Cool. Let's learn some physics." "I don't want to learn physics, I want to shoot something." As an aside, I saw an article recently where someone was lauding the github "AI" code writing thing. The author wrote something like "Wow. I asked it to replace spaces in a string with underscores and it just gave me the code." Arrrrggggghhhh!!! IMNVHO this person should never be allowed near a computer. If you can't do this without help you shouldn't be programming. Like usual, I'm rambling, but one more related thing. I'm mentoring a CS student who has to do a project this year. My advice was that I didn't care what the project actually did, but that it should be based on an Arduino and written in C and assembler without any of the sketch library stuff. The goal being to learn to read a data sheet, program I/O devices, and handle interrupts. All on a processor that's not too complicated. Jon From heinz at osta.com Wed Nov 17 04:44:04 2021 From: heinz at osta.com (Heinz Lycklama) Date: Tue, 16 Nov 2021 10:44:04 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: <202111161827.1AGIRU1l930653@darkstar.fourwinds.com> References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> <202111161827.1AGIRU1l930653@darkstar.fourwinds.com> Message-ID: Jon, regarding FSNAP - wrote it from scratch. Did not know about SNAP at the time. Heinz On 11/16/2021 10:27 AM, Jon Steinhart wrote: > Clem Cole writes: >> Unfortunately, because the hobbyist and much of the press for entry-level >> of the same, touted BASIC, many did not know better. The fact is I'm >> still now sure the HS and JHS are a lot better than they were. >> >> I'll let Steinhart reply, but he wrote an excellent book recently targeted >> to just those same students that what to know more, but frankly their HS >> teachers really are not in a position to teach them properly. > Well thanks Clem :-) > > I didn't actually hit BASIC until college where freshmen had to learn it > on the PDP-8. Took me all of about 5 minutes to learn the language and > about a half a day to do the entire semester of coursework. Got me off > to a good start on annoying my professors. > > I think that my first programming language was SNAP running on a PDP8-E in > the (I don't remember the exact name) Princeton computer barn. Because my > dad worked at IBM I remember going over to his VP's house to learn APL on > his home terminal. FORTRAN on I think an IBM 1620 was next. After that > was Heinz's FSNAP on the Honeywell DDP-516 at BTL. Never thought to > ask before, Heinz - was FSNAP based on SNAP? Assembler came after that, > followed by C. I know, what's the difference? Then Pascal in college > which was dreadful after C. I asked my professor to give me a few pointers > on how to program with fixed length arrays but he couldn't give me any :-) > > It's my opinion that BASIC was a good thing in its day but that that time > has passed. Part of what made it the goto language was its simplicity; > there wasn't much to learn and there was no complex toolchain so time was > spend on figuring out how to structure a problem so that it could be solved > on a computer. In my not very humble opinion, this is the fundamental > (or should I say basic) problem with CS education today; the effort is > focused on learning the language and the toolchain, not how to think and > solve problems. Somehow many of us learned to program in BASIC without a > "Hello World" tutorial. > > Another big factor in those days was that the consequences for getting > something wrong were pretty much nonexistent. What was the worst that > could happen, you'd accidentally output an obscenity? Give what computers > were used for back then, getting the math wrong was more likely than having > a logic error. I didn't have to worry about buggy code destroying anything > until a project where I modified FSNAP to control semiconductor test > equipment. > > I have tried when mentoring to get people to start with simple > character oriented programs but of course everyone (especially boys) > want to start with a video game. This immediately means having to deal > with multithreaded code (even if it's somewhat hidden) and complex APIs. > All of this is a distraction from learning how to think and solve problems. > As a result, we're producing a lot of "programmers" who can wrangle this > stuff while having no idea how to solve a problem. I think that a glance > at stackoverflow backs me up here. It's extremely frustrating: "I want to > write a video game where I can shoot something." "Cool. Let's learn > some physics." "I don't want to learn physics, I want to shoot something." > > As an aside, I saw an article recently where someone was lauding the > github "AI" code writing thing. The author wrote something like "Wow. > I asked it to replace spaces in a string with underscores and it just > gave me the code." Arrrrggggghhhh!!! IMNVHO this person should never be > allowed near a computer. If you can't do this without help you shouldn't > be programming. > > Like usual, I'm rambling, but one more related thing. I'm mentoring a CS > student who has to do a project this year. My advice was that I didn't > care what the project actually did, but that it should be based on an > Arduino and written in C and assembler without any of the sketch library > stuff. The goal being to learn to read a data sheet, program I/O devices, > and handle interrupts. All on a processor that's not too complicated. > > Jon From jfoust at threedee.com Wed Nov 17 04:47:53 2021 From: jfoust at threedee.com (John Foust) Date: Tue, 16 Nov 2021 12:47:53 -0600 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <20211116192105.C0E3A9C841@minnie.tuhs.org> At 11:00 AM 11/16/2021, Douglas McIlroy wrote: >>> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > >> You seem to have a gift for notation. That's rare. Curious what you think of APL? > >I take credit as a go-between, not as an inventor. Ken Knowlton >introduced the notation ABC in BEFLIX, a pixel-based animation >language. In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? - John From douglas.mcilroy at dartmouth.edu Wed Nov 17 05:29:48 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 16 Nov 2021 14:29:48 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] Message-ID: > My belief is that perl was written to replace a lot of Unix pipelines, I understand Perl's motive to have been a lot like PL/I's: subsume several popular styles of programming in one language. PL/I's ensemble wasn't always harmonious. Perl's was cacophony. Doug From douglas.mcilroy at dartmouth.edu Wed Nov 17 05:49:05 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 16 Nov 2021 14:49:05 -0500 Subject: [TUHS] Book Recommendation Message-ID: >>I take credit as a go-between, not as an inventor. Ken Knowlton >>introduced the notation ABC in BEFLIX, a pixel-based animation >>language. > In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? It meant exactly what A->B->C means in C. Pixels had properties, represented in data structures. One valid data type was pointer. Incidentally, another BEFLIX innovation was the buddy system for dynamic storage allocation. Doug From rich.salz at gmail.com Wed Nov 17 05:53:32 2021 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 16 Nov 2021 14:53:32 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <20211116180426.GW10157@mcvoy.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <20211116180426.GW10157@mcvoy.com> Message-ID: > My belief is that perl was written to replace a lot of Unix pipelines, > This is true. I heard it from Larry himself :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Nov 17 05:54:02 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 16 Nov 2021 11:54:02 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: Message-ID: <202111161954.1AGJs2N5934150@darkstar.fourwinds.com> Douglas McIlroy writes: > > My belief is that perl was written to replace a lot of Unix pipelines, > > I understand Perl's motive to have been a lot like PL/I's: subsume > several popular styles of programming in one language. PL/I's ensemble > wasn't always harmonious. Perl's was cacophony. Perl was nice in its early years as it was much more capable than awk. I understood its original intent to be a better glue language. While I find the syntax to be ugly, that's not where I hit a Wall. To me, the thing that makes Perl a bad language is the magic side effects left in things like _0 from many operations. This is stuff that one is not likely to remember unless it's used every day. I think that it's why so many consider Perl to be write-only; too many magic implicit things instead of being explicit. I understand that compactness was a big deal 40 years ago but no longer. From crossd at gmail.com Wed Nov 17 06:02:24 2021 From: crossd at gmail.com (Dan Cross) Date: Tue, 16 Nov 2021 15:02:24 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On Tue, Nov 16, 2021 at 2:51 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Incidentally, another BEFLIX innovation was the buddy system for > dynamic storage allocation. > I thought that was due to Knuth? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Nov 17 06:05:39 2021 From: imp at bsdimp.com (Warner Losh) Date: Tue, 16 Nov 2021 13:05:39 -0700 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <20211116180426.GW10157@mcvoy.com> Message-ID: On Tue, Nov 16, 2021 at 12:55 PM Richard Salz wrote: > > My belief is that perl was written to replace a lot of Unix pipelines, >> > > This is true. I heard it from Larry himself :) > It's certainly what his posts from the time said: Perl was written to cope with the hodge-podge of awk / sed / etc scripts that grew in complexity, but not quite having the power to solve the problems past a certain point in complexity in an understandable, digestible way. Perl was designed to provide an 'all of the above' language that gave a better framework to the pipelining and data processing and transformation than shell + sed + awk could with its disparate utilities. One can debate the extent to which these goals were fulfilled, of course, but that's what Larry was saying on USENET in the late 80s. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Nov 17 06:35:54 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 16 Nov 2021 12:35:54 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <37ED5E0B-22D0-4D6F-8D92-8D71D883C68C@iitbombay.org> On Nov 16, 2021, at 9:04 AM, Douglas McIlroy wrote: > > APL is a fascinating invention, but can be so compact as to be > inscrutable. (I confess not to have practiced APL enough to become > fluent.) In the same vein, Haskell's powerful higher-level functions > make middling fragments of code very clear, but can compress large > code to opacity. I enjoyed using APL in late ‘70s. And now I use and like k, another array language. I am not fond of code golfing (fewest keystrokes win!) in these languages but some problems are certainly easier to solve in them. It’s like a workshop with a well thought out set of power tools. Similarly, a lot of practice is necessary to use them effectively. When I get tired of using grep, send, xargs in a shell pipeline I have wanted to write a shell with similarly powerful builtin features…. From cowan at ccil.org Wed Nov 17 07:38:46 2021 From: cowan at ccil.org (John Cowan) Date: Tue, 16 Nov 2021 16:38:46 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: On Tue, Nov 16, 2021 at 12:06 PM Will Senn wrote: > On a less positive note. The professors who originally developed it at > Dartmouth could never quite see there way clear to open source it. True > BASIC? pshaw :). > Yes, well, universities have always been all about the money. > There was a time when I would have loved to run BASIC on linux, bsd, then > Mac and have it be consistent across the platforms, other than as a > curiosity, that time has gone. > Not so much. Bywater Basic (bwbasic), which is a much-extended clone of GW-Basic, and a clone of Commodore-64 Basic (cbmbasic) are both open source, TTY-oriented, and portable to most operating systems and Windows. There are lots of other Basics around: see < https://en.wikipedia.org/wiki/List_of_BASIC_dialects>. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Nov 17 07:46:50 2021 From: will.senn at gmail.com (Will Senn) Date: Tue, 16 Nov 2021 15:46:50 -0600 Subject: [TUHS] Book Recommendation In-Reply-To: References: <20211116040858.se3ygq2butxqopcx@localhost.localdomain> Message-ID: On 11/16/21 3:38 PM, John Cowan wrote: > > Not so much.  Bywater Basic (bwbasic), which is a much-extended clone > of GW-Basic, and a clone of Commodore-64 Basic (cbmbasic) are both > open source, TTY-oriented, and portable to most operating systems and > Windows.  There are lots of other Basics around: see > . > I meant those times were gone for me. BASIC is alive and well and there are versions for pretty much any platform now :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Nov 17 09:16:21 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 16 Nov 2021 18:16:21 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: >> Incidentally, another BEFLIX innovation was the buddy system for >> dynamic storage allocation. > I thought that was due to Knuth? I believe Knuth christened it. Knuth (TAOCP vol 1) attributes it to Markowitz (1963) and, independently, to Knowlton (1965). So I stand corrected. However, I know that Knowlton had been using it a long time before he published. I should also correct BEFLIX to L6, "[Bell] Labs Low-Level Linked List Language". Knowlton used L6 in animation work, but I believe not in the original BEFLIX. Doug On Tue, Nov 16, 2021 at 3:03 PM Dan Cross wrote: > > On Tue, Nov 16, 2021 at 2:51 PM Douglas McIlroy wrote: >> >> Incidentally, another BEFLIX innovation was the buddy system for >> dynamic storage allocation. > > > I thought that was due to Knuth? > > - Dan C. > From norman at oclsc.org Thu Nov 18 05:12:26 2021 From: norman at oclsc.org (Norman Wilson) Date: Wed, 17 Nov 2021 14:12:26 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> Message-ID: <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Wasn't Perl created to fill this void? Void? I thought Perl was created to fill a much-needed gap. Norman Wilson Toronto ON Not an awk maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Thu Nov 18 06:46:49 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 17 Nov 2021 12:46:49 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: > Wasn't Perl created to fill this void? > > Void? I thought Perl was created to fill a much-needed gap. > There was and is a need for something to sit between Shell and C. But it needn't be filled by Perl. The chief problem with Perl, as I see it, is it's like 10 languages smashed together. To write it, you only need to know one of the 10. But to read it, you never know what subset you're going to see until you're deep in the code. Perl is the victim of an experiment in exuberant, Opensource design, where the bar to adding a new feature was troublingly low. It was undeniably influential. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Nov 18 06:52:29 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 17 Nov 2021 13:52:29 -0700 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: > > On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: > >> Wasn't Perl created to fill this void? >> >> Void? I thought Perl was created to fill a much-needed gap. >> > There was and is a need for something to sit between Shell and C. But it > needn't be filled by Perl. > > The chief problem with Perl, as I see it, is it's like 10 languages > smashed together. To write it, you only need to know one of the 10. But > to read it, you never know what subset you're going to see until you're > deep in the code. > > Perl is the victim of an experiment in exuberant, Opensource design, where > the bar to adding a new feature was troublingly low. > > It was undeniably influential. > It's what paved the way for python to fill that gap... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Nov 18 07:17:02 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 17 Nov 2021 16:17:02 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: > >> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: >> >>> Wasn't Perl created to fill this void? >>> >>> Void? I thought Perl was created to fill a much-needed gap. >>> >> There was and is a need for something to sit between Shell and C. But it >> needn't be filled by Perl. >> >> The chief problem with Perl, as I see it, is it's like 10 languages >> smashed together. To write it, you only need to know one of the 10. But >> to read it, you never know what subset you're going to see until you're >> deep in the code. >> >> Perl is the victim of an experiment in exuberant, Opensource design, >> where the bar to adding a new feature was troublingly low. >> >> It was undeniably influential. >> > > It's what paved the way for python to fill that gap... > I feel that Perl, and to a lesser extent Tcl, opened the floodgates for a number of relatively lightweight "scripting" languages that sat between C and the shell in terms of their functionality and expressive power. From that group, the one I liked best was Ruby, but it got hijacked by Rails and Python swooped in and stole its thunder. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Nov 18 08:21:49 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 18 Nov 2021 09:21:49 +1100 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: Perl certainly had its detractors, but for a few years there it was the lingua franca of system administration. -rob On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: >> >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: >>> >>>> Wasn't Perl created to fill this void? >>>> >>>> Void? I thought Perl was created to fill a much-needed gap. >>>> >>> There was and is a need for something to sit between Shell and C. But >>> it needn't be filled by Perl. >>> >>> The chief problem with Perl, as I see it, is it's like 10 languages >>> smashed together. To write it, you only need to know one of the 10. But >>> to read it, you never know what subset you're going to see until you're >>> deep in the code. >>> >>> Perl is the victim of an experiment in exuberant, Opensource design, >>> where the bar to adding a new feature was troublingly low. >>> >>> It was undeniably influential. >>> >> >> It's what paved the way for python to fill that gap... >> > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates for a > number of relatively lightweight "scripting" languages that sat between C > and the shell in terms of their functionality and expressive power. From > that group, the one I liked best was Ruby, but it got hijacked by Rails and > Python swooped in and stole its thunder. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Nov 18 08:36:48 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 17 Nov 2021 14:36:48 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: <47CE7A59-B66D-4814-A91A-20A95B15C8FC@iitbombay.org> On Nov 17, 2021, at 11:12 AM, Norman Wilson wrote: > > Wasn't Perl created to fill this void? > > Void? I thought Perl was created to fill a much-needed gap. and tcl, rc etc. I just want better builtin support for shell pipelines as they are essentially (flat) list processors! As an example consider something like the following: find . -name '*.[hc]' -type f | \ xargs grep -l '\' /dev/null | \ xargs grep -l '\' /dev/null | \ xargs some-command Just to run some-command on all *.[hc] files with words foo & bar. And this will fall apart if there are spaces or : in filenames. Basically most scripts are about enumerating, filtering, converting and processing. If files, especially text files, are so central to unix, a shell should know about them and provide common operations on them. One can even think of shell variables as files (sort of like the env device in plan9). If you want to name some sub-computation instead of processing it all in one pipeline, it should be trivial but it isn't; you have to find uniq names for these temp files and remember to delete them when done. I want lexically scoped variables (aka files) that disappear once you exist the scope! The difficulty is in coming up with an intuitive, regular & a relatively concise syntax. Even so it would likely be unpopular since people seem to prefer for-loops! From lm at mcvoy.com Thu Nov 18 10:35:12 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 17 Nov 2021 16:35:12 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: <20211118003512.GN15051@mcvoy.com> I'll defend perl, at least perl4, vigorously. I wrote a lot of code in it on 20mhz SPARCs. Yeah, like any kitchen sink language you have to develop a style, but it is possible. All of Solaris 2.0 development happened under a source management system I wrote, NSElite, that was almost 100% perl4. There was one C program, that Marc might like, that took 2 SCCS files that had the initial part of the graph in common but the recent nodes were different in each file, and zippered them together into a new SCCS file that had the newer nodes on a branch. It was F.A.S.T compared to the edit/delta cycles you'd do if you did it by hand. My perl4 was maintainable, I fixed bugs in it quickly. When it happened, perl4 was a God send, as much as I love awk, perl was far more useful for stuff that awk just didn't want to handle. On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote: > Perl certainly had its detractors, but for a few years there it was the > lingua franca of system administration. > > -rob > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: > >> > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: > >>> > >>>> Wasn't Perl created to fill this void? > >>>> > >>>> Void? I thought Perl was created to fill a much-needed gap. > >>>> > >>> There was and is a need for something to sit between Shell and C. But > >>> it needn't be filled by Perl. > >>> > >>> The chief problem with Perl, as I see it, is it's like 10 languages > >>> smashed together. To write it, you only need to know one of the 10. But > >>> to read it, you never know what subset you're going to see until you're > >>> deep in the code. > >>> > >>> Perl is the victim of an experiment in exuberant, Opensource design, > >>> where the bar to adding a new feature was troublingly low. > >>> > >>> It was undeniably influential. > >>> > >> > >> It's what paved the way for python to fill that gap... > >> > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates for a > > number of relatively lightweight "scripting" languages that sat between C > > and the shell in terms of their functionality and expressive power. From > > that group, the one I liked best was Ruby, but it got hijacked by Rails and > > Python swooped in and stole its thunder. > > > > - Dan C. > > > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From drsalists at gmail.com Thu Nov 18 10:56:00 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 17 Nov 2021 16:56:00 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <47CE7A59-B66D-4814-A91A-20A95B15C8FC@iitbombay.org> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <47CE7A59-B66D-4814-A91A-20A95B15C8FC@iitbombay.org> Message-ID: On Wed, Nov 17, 2021 at 2:40 PM Bakul Shah wrote: > I just want better builtin support for shell pipelines as > they are essentially (flat) list processors! As an example > consider something like the following: > > find . -name '*.[hc]' -type f | \ > xargs grep -l '\' /dev/null | \ > xargs grep -l '\' /dev/null | \ > xargs some-command > The GNU tools let you (for EG) : find . -type f -print0 | xargs -0 egrep --null -il mypy | xargs -0 egrep --null -il pylint > /tmp/mypy-and-pylint-hits -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Fri Nov 19 04:47:54 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 18 Nov 2021 19:47:54 +0100 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] Message-ID: Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s accept for a minute that Perl filled the void between C and shell scripts, and that there was a latent need for a scripting language like this on Unix. The shell, awk, sed, etc. had arrived at more or less fully formed versions by 1980. Perl (and TCL) did not appear until the very end of the 1980’s. What filled the gap in that decade, if anything? Ancient Unix has ‘bs’ https://en.wikipedia.org/wiki/Bs_(programming_language) but this seems to have had very little use. Paul From arnold at skeeve.com Fri Nov 19 05:03:59 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 18 Nov 2021 12:03:59 -0700 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: Message-ID: <202111181903.1AIJ3xqk032412@freefriends.org> Paul Ruizendaal via TUHS wrote: > Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s > accept for a minute that Perl filled the void between C and shell scripts, > and that there was a latent need for a scripting language like this > on Unix. > > The shell, awk, sed, etc. had arrived at more or less fully formed > versions by 1980. Perl (and TCL) did not appear until the very end of > the 1980’s. What filled the gap in that decade, if anything? Nothing. It was the need for filling the gap that engendered Perl. Remember that Perl 1 through Perl 3 were around durinig the 80s; Perl 4 sort of settled in for a longer time. "New" awk didn't get out of the labs until 1987/1988, and that was only via SVR3.2 and/or the AT&T Toolchest; it wasn't open source, nor did it provide access to many of the needed system calls in the way that Perl did. Also remember that there were plenty of people who were happy working with the shell and the Unix toolkit as-is. Arnold From scj at yaccman.com Fri Nov 19 05:01:05 2021 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 18 Nov 2021 11:01:05 -0800 Subject: [TUHS] Recreation of the PDP-7 UNIX TMG compiler compiler In-Reply-To: References: <202110132053.19DKr7pF030263@ultimate.com> <7wy26vpqeq.fsf@junk.nocrew.org> Message-ID: <4e700acfcc03155ba918602cc2e7569b@yaccman.com> I was deeply motivated by TMG. The good news is that you could say what you wanted and it just did it. The bad news was the error handling. Because it was recursive if you made a syntax error the program backtracked and tried again. And again. And again. And eventually was back at the first character of the input with nowhere to go. So it issued one of its two messages -- "Syntax Error". No hint as to where it was. The other message was something like "Internal Error: call X1234". It very much encouraged a "write one line and compile" approach. It was my moaning about this in Aho's presence that got us started on LR parsing and led to Yacc. There was actually a similar problem with Yacc. I made an attempt to recover from syntax errors so I could give more than one useful message from Yacc. But there was a lot of cross-checking in the various modules, and the result was usually an internal error that I detected and reported. I naively assumed that if there was a syntax error the user would fix that and rerun. But instead, there was a steady stream of people coming in to tell me about these fatal internal errors in Yacc. When I realized that 95% of those internal errors were triggered by syntax errors, I set a flag when there was a syntax error and if the flag was on I changed the internal error message to "Cannot recover from earlier errors." About a week later, I gave a talk on Yacc and several people mentioned that Yacc used to "crash" all the time, but in the last week it had become much more stable... --- On 2021-10-14 09:53, Douglas McIlroy wrote: > Impressive indeed. And I imagine the feat will impress its brilliant > grandparent, Bob McClure (cc'd), too. > > Even though I wrote that TMG way back when, I'd never have dared to > try resuscitating it. Thank you, Phil. > > Doug > > On Thu, Oct 14, 2021 at 11:56 AM Lars Brinkhoff > wrote: >> >> Phil Budne wrote: >> > In what is perhaps best described as a crazed act, over the past two >> > months I've worked to recreate a working TMG environment on PDP-7 >> > UNIX, including a B compiler in TMGL, currently available at: >> >> Very impressive! From arnold at skeeve.com Fri Nov 19 05:20:18 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 18 Nov 2021 12:20:18 -0700 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <7f730812-e0c1-ea96-a253-bf16b25e789d@case.edu> References: <202111181903.1AIJ3xqk032412@freefriends.org> <7f730812-e0c1-ea96-a253-bf16b25e789d@case.edu> Message-ID: <202111181920.1AIJKIwd002688@freefriends.org> Chet Ramey wrote: > On 11/18/21 2:03 PM, arnold at skeeve.com wrote: > > > Also remember that there were plenty of people who were happy working > > with the shell and the Unix toolkit as-is. > > I would argue that this functionality gap is what inspired David Korn to > put as much into ksh as he did. The first `public' version of ksh was > released in 1983. This is a good point. Those of us with access to ksh made use of its features when scripting. (Speaking for myself.) Arnold From chet.ramey at case.edu Fri Nov 19 05:16:39 2021 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 18 Nov 2021 14:16:39 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111181903.1AIJ3xqk032412@freefriends.org> References: <202111181903.1AIJ3xqk032412@freefriends.org> Message-ID: <7f730812-e0c1-ea96-a253-bf16b25e789d@case.edu> On 11/18/21 2:03 PM, arnold at skeeve.com wrote: > Also remember that there were plenty of people who were happy working > with the shell and the Unix toolkit as-is. I would argue that this functionality gap is what inspired David Korn to put as much into ksh as he did. The first `public' version of ksh was released in 1983. -- ``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 ggm at algebras.org Fri Nov 19 07:03:09 2021 From: ggm at algebras.org (George Michaelson) Date: Fri, 19 Nov 2021 07:03:09 +1000 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: Interesting use of the past tense. I like to think this remains in the past tense but I keep walking into sysadmin tasks where its (regrettably ?) present. G On Thu, 18 Nov 2021, 8:24 am Rob Pike, wrote: > Perl certainly had its detractors, but for a few years there it was the > lingua franca of system administration. > > -rob > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > >> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: >> >>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: >>> >>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson >>>> wrote: >>>> >>>>> Wasn't Perl created to fill this void? >>>>> >>>>> Void? I thought Perl was created to fill a much-needed gap. >>>>> >>>> There was and is a need for something to sit between Shell and C. But >>>> it needn't be filled by Perl. >>>> >>>> The chief problem with Perl, as I see it, is it's like 10 languages >>>> smashed together. To write it, you only need to know one of the 10. But >>>> to read it, you never know what subset you're going to see until you're >>>> deep in the code. >>>> >>>> Perl is the victim of an experiment in exuberant, Opensource design, >>>> where the bar to adding a new feature was troublingly low. >>>> >>>> It was undeniably influential. >>>> >>> >>> It's what paved the way for python to fill that gap... >>> >> >> I feel that Perl, and to a lesser extent Tcl, opened the floodgates for a >> number of relatively lightweight "scripting" languages that sat between C >> and the shell in terms of their functionality and expressive power. From >> that group, the one I liked best was Ruby, but it got hijacked by Rails and >> Python swooped in and stole its thunder. >> >> - Dan C. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Nov 19 07:03:15 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 18 Nov 2021 16:03:15 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <202111181903.1AIJ3xqk032412@freefriends.org> References: <202111181903.1AIJ3xqk032412@freefriends.org> Message-ID: On Thu, Nov 18, 2021 at 2:06 PM wrote: > > The shell, awk, sed, etc. had arrived at more or less fully formed > > versions by 1980. Perl (and TCL) did not appear until the very end of > > the 1980’s. What filled the gap in that decade, if anything? > > Nothing. It was the need for filling the gap that engendered Perl. > ISTR that lwall said his specific problem with using awk was its inability to read from files other than those mentioned on the command line (and them only sequentially). Old awk did not have getline. There were probably other itches he wanted to scratch, but that one was a deal-breaker (or -maker). Remember that Perl 1 through Perl 3 were around durinig the 80s; Perl 4 > sort of settled in for a longer time. > Perl 2 was the faster (though still very slow) regex engine; Perl 3 was binary I/O; Perl 4 was the Camel Book, which is why the version number stayed at 4.xxx until something in the Camel Book broke. "New" awk didn't get out of the labs until 1987/1988, and that was only > via SVR3.2 and/or the AT&T Toolchest; it wasn't open source, nor > did it provide access to many of the needed system calls in the way > that Perl did. > The project I worked on in 1999-2005 was about half Perl and half shell+sed+awk+etc.... I was able to do that because I had worked on an earlier project that was by fiat all Perl 4. I don't use Perl any more, but I still use the shell toolkit constantly. I have a back burner project to allow convenient manual data file transformation. It grew out of my dissatisfaction with using the m,n! command in various editors: you can undo, but it's slow, and you have no access to the full undo tree except in vim. My proposed 'mung' command doesn't actually edit at the micro level, but it lets you use | to create a new state of the tree, and each state is stored in a file (disk is cheap). The tree is persistent. When you have the file the way you want it, you write it out and, if you want, generate a shell script that replicates what you just did so it's repeatable. I'll probably implement it in Python. The commands and other external information are at < https://github.com/johnwcowan/exx/blob/master/mung/mung.txt>. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Nov 19 07:39:36 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 19 Nov 2021 08:39:36 +1100 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> Message-ID: In my limited orbit, Ruby eventually displaced Perl for that, but as to the default today, I don't know. -rob On Fri, Nov 19, 2021 at 8:06 AM George Michaelson wrote: > > Interesting use of the past tense. I like to think this remains in the past tense but I keep walking into sysadmin tasks where its (regrettably ?) present. > > G > > On Thu, 18 Nov 2021, 8:24 am Rob Pike, wrote: >> >> Perl certainly had its detractors, but for a few years there it was the lingua franca of system administration. >> >> -rob >> >> >> On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: >>> >>> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: >>>> >>>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg wrote: >>>>> >>>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson wrote: >>>>>> >>>>>> Wasn't Perl created to fill this void? >>>>>> >>>>>> Void? I thought Perl was created to fill a much-needed gap. >>>>> >>>>> There was and is a need for something to sit between Shell and C. But it needn't be filled by Perl. >>>>> >>>>> The chief problem with Perl, as I see it, is it's like 10 languages smashed together. To write it, you only need to know one of the 10. But to read it, you never know what subset you're going to see until you're deep in the code. >>>>> >>>>> Perl is the victim of an experiment in exuberant, Opensource design, where the bar to adding a new feature was troublingly low. >>>>> >>>>> It was undeniably influential. >>>> >>>> >>>> It's what paved the way for python to fill that gap... >>> >>> >>> I feel that Perl, and to a lesser extent Tcl, opened the floodgates for a number of relatively lightweight "scripting" languages that sat between C and the shell in terms of their functionality and expressive power. From that group, the one I liked best was Ruby, but it got hijacked by Rails and Python swooped in and stole its thunder. >>> >>> - Dan C. >>> From rdm at cfcl.com Fri Nov 19 07:42:36 2021 From: rdm at cfcl.com (Rich Morin) Date: Thu, 18 Nov 2021 13:42:36 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: Message-ID: Not that anyone asked, but... My introduction to Perl was motivated by a performance issue. I had been using a set of sh/awk/... scripts to generate the source files (troff and file trees) for my Prime Time Freeware book/CD-ROM collections. One of the cooler aspects of this approach was that I could use sh as a macro processor, substituting assorted values into the awk (etc) code. However, running the scripts was taking about three hours (!), so I tended to start them up just before going to bed. This worked, for some value of "work", but it was kind of a nuisance... So, upon the recommendation of Erik Fair, I transliterated my scripts into Perl. The similarity of Perl syntax to my previous combination of languages was so strong that the effort was almost mindless. And, even though I made no attempt to use any Perlish features, the new scripts ran about five (!) times faster. My assumption is that this was mostly due to getting rid of the process startup times. My move to Ruby was motivated by the Perl 6 clusterfudge. After watching Perl 5 sit at a siding for a few years, with no relief in sight, I took another friend's advice and tried out Ruby. Aside from a few odd differences, it was quite familiar and a very easy transition. However, the syntax seemed much "cleaner" than Perl's (Matz has very good taste, IMHO). So, it's still my choice for small, single-threaded scripts. That said, if I want to write larger and/or concurrent apps, I turn to Elixir. It gives me Ruby-like syntax (with nifty extensions such as pipes), strong support for concurrency and distribution, macros, etc. -r From silas8642 at hotmail.co.uk Fri Nov 19 08:42:40 2021 From: silas8642 at hotmail.co.uk (silas poulson) Date: Thu, 18 Nov 2021 22:42:40 +0000 Subject: [TUHS] Fwd: Who asked Ken for grep? References: <72DA417A-2A8B-40DD-9931-D676AB90AD70@hotmail.co.uk> Message-ID: <4EA8AE37-E28A-407C-98C3-0463BE0BEF24@hotmail.co.uk> Hello, I tried asking question below awhile back - would anyone know the proper answer? Many Thanks, Silas > > Hello, > > Recently watched couple of videos[1][2] from Ken and Brian Kernighan > on the origin of grep. > > In [1], Brian suggests Lee McMahon asked Ken for grep to help with > federalist papers analysis. > > However Ken states in [2] that Doug Mcllroy asked for someway to “look > for things in files”. > > Is this just Brian misremembering or multiple people asking around similar > times? > > Many thanks, > Silas > > [1]Where GREP Came From - Computerphile > > > [2]VCF East 2019 -- Brian Kernighan interviews Ken Thompson > From beebe at math.utah.edu Fri Nov 19 08:59:10 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 18 Nov 2021 15:59:10 -0700 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] Message-ID: The discussions under this subject line have somewhat strayed from Unix heritage issues, but because several people have contributed views of assorted programming languages that mostly grew up on Unix-family systems, I decided to add this memory. Several years ago, I attended a talk by Dan McCracken (1930--2011), noted book author in computer areas, and VP and later President of the ACM (1978--1980). His talk was about programming languages, and was done in a question/answer format, with Dan offering both parts. He began: Q: In 10 years, which of the following programming languages will still be in use: Basic, Cobol, Fortran, PL/I, .... A: First of all, Basic is not a programming language. Then ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From douglas.mcilroy at dartmouth.edu Fri Nov 19 09:26:45 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 18 Nov 2021 18:26:45 -0500 Subject: [TUHS] > Who asked Ken for grep? Message-ID: I can say unequivocally that I asked Ken for grep, and the next day it was in /bin. But ... I understand now that grep already existed in /usr/ken/bin. My request was the last straw that tipped the balance from private to public. Hopefully Ken can answer whether he made it originally for himself or for Lee. Doug From alanglasser at gmail.com Sat Nov 20 06:04:37 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 19 Nov 2021 15:04:37 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <20211118003512.GN15051@mcvoy.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <20211118003512.GN15051@mcvoy.com> Message-ID: Larry, Did you ever try the -i or -x options on get(1) to include or exclude deltas? Alan On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy wrote: > I'll defend perl, at least perl4, vigorously. I wrote a lot of code in > it on 20mhz SPARCs. Yeah, like any kitchen sink language you have to > develop a style, but it is possible. All of Solaris 2.0 development > happened under a source management system I wrote, NSElite, that was > almost 100% perl4. There was one C program, that Marc might like, > that took 2 SCCS files that had the initial part of the graph in > common but the recent nodes were different in each file, and zippered > them together into a new SCCS file that had the newer nodes on a > branch. It was F.A.S.T compared to the edit/delta cycles you'd > do if you did it by hand. > > My perl4 was maintainable, I fixed bugs in it quickly. > > When it happened, perl4 was a God send, as much as I love awk, perl > was far more useful for stuff that awk just didn't want to handle. > > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote: > > Perl certainly had its detractors, but for a few years there it was the > > lingua franca of system administration. > > > > -rob > > > > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > > > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg > wrote: > > >> > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson > wrote: > > >>> > > >>>> Wasn't Perl created to fill this void? > > >>>> > > >>>> Void? I thought Perl was created to fill a much-needed gap. > > >>>> > > >>> There was and is a need for something to sit between Shell and C. > But > > >>> it needn't be filled by Perl. > > >>> > > >>> The chief problem with Perl, as I see it, is it's like 10 languages > > >>> smashed together. To write it, you only need to know one of the > 10. But > > >>> to read it, you never know what subset you're going to see until > you're > > >>> deep in the code. > > >>> > > >>> Perl is the victim of an experiment in exuberant, Opensource design, > > >>> where the bar to adding a new feature was troublingly low. > > >>> > > >>> It was undeniably influential. > > >>> > > >> > > >> It's what paved the way for python to fill that gap... > > >> > > > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates > for a > > > number of relatively lightweight "scripting" languages that sat > between C > > > and the shell in terms of their functionality and expressive power. > From > > > that group, the one I liked best was Ruby, but it got hijacked by > Rails and > > > Python swooped in and stole its thunder. > > > > > > - Dan C. > > > > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Nov 20 06:14:47 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 19 Nov 2021 12:14:47 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <20211118003512.GN15051@mcvoy.com> Message-ID: <20211119201447.GF15051@mcvoy.com> All the time. A merge in BitKeeper (which is SCCS based, I rewrote SCCS from scratch and evolved it quite a bit) is just a get -e -ir1,r2,r3,r4 where the include list is all the revs on the branch being merged. That's the beauty of SCCS that seems to be lost to the rest of the world: if someone added N bytes on the branch, the merge passes that to the trunk by *reference*, every other SCM that is in current use copies the branch data to the trunk. Suppose Rob had done a bunch of important work on the branch, you had done some work on the trunk, and for whatever reason, I merged Rob's work. Let's say everything automerged. In SCCS or BitKeeper, the only new data in the file is a merge node that says "Include all of Rob's work". In all other systems in use today, there would be a merge node with another copy of Rob's work with me as the author because I did the merge. Blech. Strangely enough, ClearCase has a weave format like SCCS and they could have done merges by reference and they choose to copy it. I dunno who the idiot was that made that decision. On Fri, Nov 19, 2021 at 03:04:37PM -0500, Alan Glasser wrote: > Larry, > > Did you ever try the -i or -x options on get(1) to include or exclude > deltas? > > Alan > > > On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy wrote: > > > I'll defend perl, at least perl4, vigorously. I wrote a lot of code in > > it on 20mhz SPARCs. Yeah, like any kitchen sink language you have to > > develop a style, but it is possible. All of Solaris 2.0 development > > happened under a source management system I wrote, NSElite, that was > > almost 100% perl4. There was one C program, that Marc might like, > > that took 2 SCCS files that had the initial part of the graph in > > common but the recent nodes were different in each file, and zippered > > them together into a new SCCS file that had the newer nodes on a > > branch. It was F.A.S.T compared to the edit/delta cycles you'd > > do if you did it by hand. > > > > My perl4 was maintainable, I fixed bugs in it quickly. > > > > When it happened, perl4 was a God send, as much as I love awk, perl > > was far more useful for stuff that awk just didn't want to handle. > > > > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote: > > > Perl certainly had its detractors, but for a few years there it was the > > > lingua franca of system administration. > > > > > > -rob > > > > > > > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > > > > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > > > > > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg > > wrote: > > > >> > > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson > > wrote: > > > >>> > > > >>>> Wasn't Perl created to fill this void? > > > >>>> > > > >>>> Void? I thought Perl was created to fill a much-needed gap. > > > >>>> > > > >>> There was and is a need for something to sit between Shell and C. > > But > > > >>> it needn't be filled by Perl. > > > >>> > > > >>> The chief problem with Perl, as I see it, is it's like 10 languages > > > >>> smashed together. To write it, you only need to know one of the > > 10. But > > > >>> to read it, you never know what subset you're going to see until > > you're > > > >>> deep in the code. > > > >>> > > > >>> Perl is the victim of an experiment in exuberant, Opensource design, > > > >>> where the bar to adding a new feature was troublingly low. > > > >>> > > > >>> It was undeniably influential. > > > >>> > > > >> > > > >> It's what paved the way for python to fill that gap... > > > >> > > > > > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates > > for a > > > > number of relatively lightweight "scripting" languages that sat > > between C > > > > and the shell in terms of their functionality and expressive power. > > From > > > > that group, the one I liked best was Ruby, but it got hijacked by > > Rails and > > > > Python swooped in and stole its thunder. > > > > > > > > - Dan C. > > > > > > > > > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From alanglasser at gmail.com Sat Nov 20 07:48:40 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 19 Nov 2021 16:48:40 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <20211119201447.GF15051@mcvoy.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <20211118003512.GN15051@mcvoy.com> <20211119201447.GF15051@mcvoy.com> Message-ID: Larry, I have been out of working (retired from AT&T Labs Research in 2013), let alone working on SCCS and related tools for quite a while. I'm happy to hear that some folks appreciated what I called "INEX" (for include/exclude); one of my contributions to SCCS. I've had to argue against RCS and, of course, deal with CVS, much to my chagrin. Are you familiar with the concept of SCCS ID lists (slists), which act as a table of contents of a "unit" (usually a library or load module)? Not much released (from the Labs) documentation on slists; one paper was way back in COMSAC 80 by three former co-workers: Gene Cristofor, Tim Wendt and Bud Wonsiewicz. Alan P.S. Sounds like I should learn more about BitKeeper. On Fri, Nov 19, 2021 at 3:14 PM Larry McVoy wrote: > All the time. A merge in BitKeeper (which is SCCS based, I rewrote SCCS > from scratch and evolved it quite a bit) is just a > > get -e -ir1,r2,r3,r4 > > where the include list is all the revs on the branch being merged. > > That's the beauty of SCCS that seems to be lost to the rest of the > world: if someone added N bytes on the branch, the merge passes that > to the trunk by *reference*, every other SCM that is in current use > copies the branch data to the trunk. > > Suppose Rob had done a bunch of important work on the branch, you had > done some work on the trunk, and for whatever reason, I merged Rob's > work. Let's say everything automerged. In SCCS or BitKeeper, the only > new data in the file is a merge node that says "Include all of Rob's > work". In all other systems in use today, there would be a merge node > with another copy of Rob's work with me as the author because I did > the merge. Blech. > > Strangely enough, ClearCase has a weave format like SCCS and they could > have done merges by reference and they choose to copy it. I dunno who > the idiot was that made that decision. > > On Fri, Nov 19, 2021 at 03:04:37PM -0500, Alan Glasser wrote: > > Larry, > > > > Did you ever try the -i or -x options on get(1) to include or exclude > > deltas? > > > > Alan > > > > > > On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy wrote: > > > > > I'll defend perl, at least perl4, vigorously. I wrote a lot of code in > > > it on 20mhz SPARCs. Yeah, like any kitchen sink language you have to > > > develop a style, but it is possible. All of Solaris 2.0 development > > > happened under a source management system I wrote, NSElite, that was > > > almost 100% perl4. There was one C program, that Marc might like, > > > that took 2 SCCS files that had the initial part of the graph in > > > common but the recent nodes were different in each file, and zippered > > > them together into a new SCCS file that had the newer nodes on a > > > branch. It was F.A.S.T compared to the edit/delta cycles you'd > > > do if you did it by hand. > > > > > > My perl4 was maintainable, I fixed bugs in it quickly. > > > > > > When it happened, perl4 was a God send, as much as I love awk, perl > > > was far more useful for stuff that awk just didn't want to handle. > > > > > > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote: > > > > Perl certainly had its detractors, but for a few years there it was > the > > > > lingua franca of system administration. > > > > > > > > -rob > > > > > > > > > > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > > > > > > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh > wrote: > > > > > > > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg > > > wrote: > > > > >> > > > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson > > > > wrote: > > > > >>> > > > > >>>> Wasn't Perl created to fill this void? > > > > >>>> > > > > >>>> Void? I thought Perl was created to fill a much-needed gap. > > > > >>>> > > > > >>> There was and is a need for something to sit between Shell and C. > > > But > > > > >>> it needn't be filled by Perl. > > > > >>> > > > > >>> The chief problem with Perl, as I see it, is it's like 10 > languages > > > > >>> smashed together. To write it, you only need to know one of the > > > 10. But > > > > >>> to read it, you never know what subset you're going to see until > > > you're > > > > >>> deep in the code. > > > > >>> > > > > >>> Perl is the victim of an experiment in exuberant, Opensource > design, > > > > >>> where the bar to adding a new feature was troublingly low. > > > > >>> > > > > >>> It was undeniably influential. > > > > >>> > > > > >> > > > > >> It's what paved the way for python to fill that gap... > > > > >> > > > > > > > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates > > > for a > > > > > number of relatively lightweight "scripting" languages that sat > > > between C > > > > > and the shell in terms of their functionality and expressive power. > > > From > > > > > that group, the one I liked best was Ruby, but it got hijacked by > > > Rails and > > > > > Python swooped in and stole its thunder. > > > > > > > > > > - Dan C. > > > > > > > > > > > > > > > > -- > > > --- > > > Larry McVoy lm at mcvoy.com > > > http://www.mcvoy.com/lm > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Nov 20 08:28:40 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 19 Nov 2021 14:28:40 -0800 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <20211118003512.GN15051@mcvoy.com> <20211119201447.GF15051@mcvoy.com> Message-ID: <20211119222840.GH15051@mcvoy.com> Hi Alan (and others, should this move to COFF?) > I'm happy to hear that some folks appreciated what I called "INEX" (for > include/exclude); one of my contributions to SCCS. You just got yourself a big fan, anyone who had the insight to add includes and excludes to SCCS is a smart cookie, thank you for those, BitKeeper makes heavy use of them. > I've had to argue against RCS and, of course, deal with CVS, much to my > chagrin. You and me both. > Are you familiar with the concept of SCCS ID lists (slists), which act as a > table of contents of a "unit" (usually a library or load module)? That sounds like BitKeeper's ChangeSet file. BitKeeper's model is repository based, a repository is a collection of SCCS files that are all managed as a unit. It doesn't work this way but you could think of the original content of the ChangeSet file as src/foo.c 1.1 man/foo.1 1.1 It is The ChangeSet file is itself versioned so lets say you added a file, then version 1.2 of the ChangeSet file is src/foo.c 1.1 man/foo.1 1.1 examples/foo.eg 1.1 Because pathnames can change (BitKeeper has pathnames versioned just like the content is version) we had to come up with a non-changing name for pathnames (think inode # but it has to be globally unique). Ditto for revisions, they get changed all the time because of merges. BitKeeper's internal names look like (you can skip this for now): Inode: lm at lm.bitmover.com|man/WhatIs|19980710174007|58324|a9558aeac091a142 or user at host.domain|relative/path|date|chksum|64 bits of /dev/random Revision: lm at work.bitmover.com|man/WhatIs|20000205064107|58704 or same as the inode but skip the 64 bits. Getting back to useful stuff, you can clone a repository to any commit, all that does is check out that version of the ChangeSet file and strips off deltas until the tip matches the revision from that version of the ChangeSet file. BitKeeper was the first fully distributed SCM system, Git, Hg, et al, are all inspired by BitKeeper (and would have done well to copy it more closely, Git in particular is just awful). BitKeeper owes a tremendous nod to SCCS, SCCS taught me the value of that file format. --lm From alanglasser at gmail.com Sat Nov 20 08:41:12 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 19 Nov 2021 17:41:12 -0500 Subject: [TUHS] Two anecdotes Message-ID: Here are two anecdotes that Doug suggested I share with TUHS (I am new to TUHS, having joined just last month). *First*: *The creation of access(2).* [Marc Rochkind documented a version of this on page 56 of his book *Advanced Unix Programming* (1985, First Edition) discussing link(2). The footnote on that page says "Alan L. Glasser and I used this scheme to break into Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] Doug pointed out that the timing was probably later, as access(2) was not in the Sixth Edition release, but probably right after the release (after May 1975?). It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, but he told me that he has renamed directories with the mv command. I said then mv must be setuid to root, so we looked, and, of course, it was. I then looked at the source code for mv and quickly saw that there was no attempt to check permission on the real uid. So I told Marc it would allow anyone to become root. He wanted to see it in action, so I logged into research (I don’t remember what our organization's shared login was). No one in our organization had root access on research. Marc and I didn't have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users). I think the actual sequence of commands was: cd / cp etc/passwd tmp ed tmp/passwd 1s/^root:[^:]*:/root::/ w q mv etc etc2 mv tmp etc su mv etc tmp mv etc2 etc mv etc/as2 etc/.as2 {logout, hangup and wonder} The last bit was a test to see what was noticed about what I did. Marc and I talked for a while about it and discussed if we had any need to be root on our local machines, but couldn't think of any pressing need, but knowing we could was a bit of a comfort. After a short time, Marc suggested logging back in to see what, if anything, had been done. /bin/mv had lost setuid to root /etc/as2 was restored /etc/.as2 was nonexistent And the next day, the motd on research mentioned that there's a new syscall: access. And mv(1) now used it. *Second*: Our organization was one (out of possibly others) subject of Ken's *codenih* that he documented in his Turing Award article in CACM. As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research. Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems. Our C compiler guy, Rich Graveman, who kept in close contact with Dennis and was always getting us the latest compiler to install, had gone to MH and came back with a tape of a new compiler. Rich, being a careful fellow, did a size on c0, c1, c2 on the files from the tape and did the same on the running compiler pieces in /lib. Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it was union). So Rich did nm's on the two different c0's and discovered a name "codenih" in the old compiler that wasn't in the new one from Dennis. He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, followed by a cd codenih. Was he surprised! Then he went back to a local machine and tried to login as root/codenih, which, of course, worked. He was even more surprised and told a number of colleagues, myself included. (I logged into research and printed out the source in /usr/ken/codenih. I was super impressed.) I think you misunderstood the codenih bit. As Ken had given us a (shared among a few of us) login, we had given him one. And Dick Haight refused him root access. And no one in PY had root access on research. So much for denying Ken root access on the PWB systems. Ken "infected" the PWB C compiler with codenih, which gave him free rein. I don't know how or when he first installed it, but I suspect he was aware of any extant security holes (e.g., the mv setuid root) to allow him to replace the compiler the first time. I don't know if the PWB crowd was the impetus for Ken writing codenih or if it was something he had used on others prior to us or if he ever used it on anyone else. Needless to say, Dick Haight was beside himself. I just thought it was a great feat of programming and was thrilled when he described it in CACM. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanglasser at gmail.com Sat Nov 20 09:17:20 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 19 Nov 2021 18:17:20 -0500 Subject: [TUHS] Book Recommendation [ reallly inscrutable languages ] In-Reply-To: <20211118003512.GN15051@mcvoy.com> References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com> <50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org> <20211118003512.GN15051@mcvoy.com> Message-ID: My 2 cents on Perl. Having come up on Ken's original shell, the Mashey shell, the Bourne shell and the Korn shell (and now bash), and a happy awk (and nawk) programmer, I mostly avoided perl. But since many others didn't, I've found myself needing to read perl code, which as Larry stated "It wanted you to be pretty disciplined in how you wrote it or it becomes write only, but if you are, it was really pleasant." Unfortunately, most open source that I looked at felt to me like write only. Also, as Dave stated "The chief problem with Perl, as I see it, is it's like 10 languages smashed together. To write it, you only need to know one of the 10. But to read it, you never know what subset you're going to see until you're deep in the code." Not good for a peruser of perl code (me). And what's with the "special" or "magic" variables? Shades of IBM/OS; not at all Unix-like. >From 1996 until 2013 (when I retired) I was lucky enough to have a Perl aficionado on my team and he spared me much grief. Alan On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy wrote: > I'll defend perl, at least perl4, vigorously. I wrote a lot of code in > it on 20mhz SPARCs. Yeah, like any kitchen sink language you have to > develop a style, but it is possible. All of Solaris 2.0 development > happened under a source management system I wrote, NSElite, that was > almost 100% perl4. There was one C program, that Marc might like, > that took 2 SCCS files that had the initial part of the graph in > common but the recent nodes were different in each file, and zippered > them together into a new SCCS file that had the newer nodes on a > branch. It was F.A.S.T compared to the edit/delta cycles you'd > do if you did it by hand. > > My perl4 was maintainable, I fixed bugs in it quickly. > > When it happened, perl4 was a God send, as much as I love awk, perl > was far more useful for stuff that awk just didn't want to handle. > > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote: > > Perl certainly had its detractors, but for a few years there it was the > > lingua franca of system administration. > > > > -rob > > > > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross wrote: > > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh wrote: > > > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg > wrote: > > >> > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson > wrote: > > >>> > > >>>> Wasn't Perl created to fill this void? > > >>>> > > >>>> Void? I thought Perl was created to fill a much-needed gap. > > >>>> > > >>> There was and is a need for something to sit between Shell and C. > But > > >>> it needn't be filled by Perl. > > >>> > > >>> The chief problem with Perl, as I see it, is it's like 10 languages > > >>> smashed together. To write it, you only need to know one of the > 10. But > > >>> to read it, you never know what subset you're going to see until > you're > > >>> deep in the code. > > >>> > > >>> Perl is the victim of an experiment in exuberant, Opensource design, > > >>> where the bar to adding a new feature was troublingly low. > > >>> > > >>> It was undeniably influential. > > >>> > > >> > > >> It's what paved the way for python to fill that gap... > > >> > > > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates > for a > > > number of relatively lightweight "scripting" languages that sat > between C > > > and the shell in terms of their functionality and expressive power. > From > > > that group, the one I liked best was Ruby, but it got hijacked by > Rails and > > > Python swooped in and stole its thunder. > > > > > > - Dan C. > > > > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Nov 20 10:54:59 2021 From: robpike at gmail.com (Rob Pike) Date: Sat, 20 Nov 2021 11:54:59 +1100 Subject: [TUHS] Two anecdotes In-Reply-To: References: Message-ID: Clever though those anecdotes may be, it was much easier to become root. Sometime around 1981, I was visiting USG and they were in a bit of a panic, checking that their system was intact. Why? Because early that morning, there was a phone call to the machine room: "Hi, this is Ken. What's the root password?" The call was successful. Any sysadmin worth his paycheck would have known that Ken isn't awake in the mornings and could have blocked this interloper. But... -rob On Sat, Nov 20, 2021 at 9:45 AM Alan Glasser wrote: > > Here are two anecdotes that Doug suggested I share with TUHS (I am new to TUHS, having joined just last month). > > First: > > The creation of access(2). > [Marc Rochkind documented a version of this on page 56 of his book Advanced Unix Programming (1985, First Edition) discussing link(2). The footnote on that page says "Alan L. Glasser and I used this scheme to break into Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] > > Doug pointed out that the timing was probably later, as access(2) was not in the Sixth Edition release, but probably right after the release (after May 1975?). > > It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, but he told me that he has renamed directories with the mv command. I said then mv must be setuid to root, so we looked, and, of course, it was. I then looked at the source code for mv and quickly saw that there was no attempt to check permission on the real uid. So I told Marc it would allow anyone to become root. He wanted to see it in action, so I logged into research (I don’t remember what our organization's shared login was). No one in our organization had root access on research. Marc and I didn't have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users). I think the actual sequence of commands was: > cd / > cp etc/passwd tmp > ed tmp/passwd > 1s/^root:[^:]*:/root::/ > w > q > mv etc etc2 > mv tmp etc > su > mv etc tmp > mv etc2 etc > mv etc/as2 etc/.as2 > {logout, hangup and wonder} > The last bit was a test to see what was noticed about what I did. > Marc and I talked for a while about it and discussed if we had any need to be root on our local machines, but couldn't think of any pressing need, but knowing we could was a bit of a comfort. After a short time, Marc suggested logging back in to see what, if anything, had been done. > /bin/mv had lost setuid to root > /etc/as2 was restored > /etc/.as2 was nonexistent > > And the next day, the motd on research mentioned that there's a new syscall: access. And mv(1) now used it. > > Second: > > Our organization was one (out of possibly others) subject of Ken's codenih that he documented in his Turing Award article in CACM. > > As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research. Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems. > > Our C compiler guy, Rich Graveman, who kept in close contact with Dennis and was always getting us the latest compiler to install, had gone to MH and came back with a tape of a new compiler. Rich, being a careful fellow, did a size on c0, c1, c2 on the files from the tape and did the same on the running compiler pieces in /lib. > Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it was union). So Rich did nm's on the two different c0's and discovered a name "codenih" in the old compiler that wasn't in the new one from Dennis. He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, followed by a cd codenih. Was he surprised! Then he went back to a local machine and tried to login as root/codenih, which, of course, worked. He was even more surprised and told a number of colleagues, myself included. (I logged into research and printed out the source in /usr/ken/codenih. I was super impressed.) > > I think you misunderstood the codenih bit. > As Ken had given us a (shared among a few of us) login, we had given him one. > And Dick Haight refused him root access. > And no one in PY had root access on research. > > So much for denying Ken root access on the PWB systems. > Ken "infected" the PWB C compiler with codenih, which gave him free rein. I don't know how or when he first installed it, but I suspect he was aware of any extant security holes (e.g., the mv setuid root) to allow him to replace the compiler the first time. > > I don't know if the PWB crowd was the impetus for Ken writing codenih or if it was something he had used on others prior to us or if he ever used it on anyone else. > Needless to say, Dick Haight was beside himself. > I just thought it was a great feat of programming and was thrilled when he described it in CACM. > > Alan > > > From jon at fourwinds.com Sat Nov 20 11:30:18 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 19 Nov 2021 17:30:18 -0800 Subject: [TUHS] Two anecdotes In-Reply-To: References: Message-ID: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> My recollection from the 70s is that the default root password on all UNIX systems was "foo" and almost nobody ever changed it. From alanglasser at gmail.com Sat Nov 20 12:08:49 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 19 Nov 2021 21:08:49 -0500 Subject: [TUHS] Two anecdotes In-Reply-To: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> Message-ID: Most of the hundreds (thousands?) of Unix systems running in Bell Labs seemed to have well guarded root passwords. There was always social engineering, like Rob mentioned. And, of course, setuid root exploits that I enjoyed. Another anectdote: Sometime around 1975 the NSA became a proud owner of a Unix system. They rewrote a whole bunch. And invited Ken to visit. He surreptitiously observed someone logging into the console as root. A bit later, they asked him to have a seat and try to break in. He sat down and logged in as root. Apparently he was very good at observing keystrokes. He had to explain himself. I wonder if they would’ve let him leave otherwise. - Alan > On Nov 19, 2021, at 8:32 PM, Jon Steinhart wrote: > > My recollection from the 70s is that the default root password on > all UNIX systems was "foo" and almost nobody ever changed it. From tytso at mit.edu Sat Nov 20 12:48:42 2021 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 19 Nov 2021 21:48:42 -0500 Subject: [TUHS] Two anecdotes In-Reply-To: References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> Message-ID: On Fri, Nov 19, 2021 at 09:08:49PM -0500, Alan Glasser wrote: > Most of the hundreds (thousands?) of Unix systems running in Bell > Labs seemed to have well guarded root passwords. There was always > social engineering, like Rob mentioned. And, of course, setuid root > exploits that I enjoyed. Does anyone remember the security vulnerability existed where /bin/mail was setuid root, and you could issue the command "!/bin/ed /etc/passwd" and the editor would be executed as root because /bin/mail failed to drop the setuid root privs before executing the shell escape? When I was a Freshman at MIT I implementing some image processing programming on an old Unix system for a Materials Science professor in 1987 as part of MIT's Undergraduate Research Opportunities Program (UROP). It was some ancient Unix program, and to my amazement, the /bin/mail security vulnerability was there even though it was a famous security oopise that should have been patched long before. I *think* the system was some kind of AT&T Unix (not BSD) system, but I can't remember the hardware or the specific Unix that was on the system. Does anyone know how long and on which Unix variants this particular /bin/mail setuid root vulnerability was around? - Ted From cowan at ccil.org Sat Nov 20 13:08:23 2021 From: cowan at ccil.org (John Cowan) Date: Fri, 19 Nov 2021 22:08:23 -0500 Subject: [TUHS] Two anecdotes In-Reply-To: References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> Message-ID: On Fri, Nov 19, 2021 at 9:11 PM Alan Glasser wrote: > There was always social engineering, like Rob mentioned Me, after a pentesting company had given $EMPLOYER their shpiel: "And do you use social engineering?" "No, we never do that." "Whyever not?" "Because it *always* works, so we don't learn anything." -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sat Nov 20 20:12:30 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 20 Nov 2021 10:12:30 +0000 Subject: [TUHS] Two anecdotes In-Reply-To: References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com> Message-ID: <20211120101230.A2BCF21C4E@orac.inputplus.co.uk> Hi, Alan wrote: > Apparently [Ken] was very good at observing keystrokes. A couple of decades ago, back when I used to work in offices with other people, I got quite proficient at ‘reading’ their typing when viewing the keyboard upside down, i.e. I was the other side of their desk. It's not too hard if they're typing natural-language words and phrases with the odd digit tacked on especially if one doesn't focus on each individual keystroke but the pattern of presses. And it's easy to practice on lots of typing where security isn't important. -- Cheers, Ralph. From douglas.mcilroy at dartmouth.edu Sun Nov 21 01:02:56 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 20 Nov 2021 10:02:56 -0500 Subject: [TUHS] Recreation of the PDP-7 UNIX TMG compiler compiler Message-ID: > I was deeply motivated by TMG. The good news is that you could say what > you wanted and it just did it. The bad news was the error handling. > Because it was recursive if you made a syntax error the program > backtracked and tried again. And again. And again. And eventually was > back at the first character of the input with nowhere to go. So it > issued one of its two messages -- "Syntax Error". This is somewhat of a caricature. If one's compilation strategy were to build an abstract syntax tree of the whole source program before emitting any object code, then things would go as Steve describes. In reality, TMG wasn't used this way. For one thing, ASTs needed too much memory. In TMG one could emit code while parsing. Typically code was generated on a statement-by-statement basis. This limited the backtracking, so even a naive "syntax error" diagnostic could be localized to the statement level. Long-distance connections, such as the branch labels in a nest of if statements, could nevertheless be realized recursively. Thus, in actual use, a TMG "grammar" was partly a parsing program and partly abstract specification. The balance of viewpoints was left to the discretion of the grammar's author. Yacc swung the pendulum toward the abstract. Doug From lm at mcvoy.com Sun Nov 21 12:05:30 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 20 Nov 2021 18:05:30 -0800 Subject: [TUHS] Two anecdotes In-Reply-To: References: Message-ID: <20211121020530.GO15051@mcvoy.com> It was early days. People have to spin up, I can't tell you how many times other people got it and I got it later. On Sat, Nov 20, 2021 at 11:54:59AM +1100, Rob Pike wrote: > Clever though those anecdotes may be, it was much easier to become > root. Sometime around 1981, I was visiting USG and they were in a bit > of a panic, checking that their system was intact. Why? Because early > that morning, there was a phone call to the machine room: > > "Hi, this is Ken. What's the root password?" > > The call was successful. > > Any sysadmin worth his paycheck would have known that Ken isn't awake > in the mornings and could have blocked this interloper. But... > > -rob > > On Sat, Nov 20, 2021 at 9:45 AM Alan Glasser wrote: > > > > Here are two anecdotes that Doug suggested I share with TUHS (I am new to TUHS, having joined just last month). > > > > First: > > > > The creation of access(2). > > [Marc Rochkind documented a version of this on page 56 of his book Advanced Unix Programming (1985, First Edition) discussing link(2). The footnote on that page says "Alan L. Glasser and I used this scheme to break into Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] > > > > Doug pointed out that the timing was probably later, as access(2) was not in the Sixth Edition release, but probably right after the release (after May 1975?). > > > > It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, but he told me that he has renamed directories with the mv command. I said then mv must be setuid to root, so we looked, and, of course, it was. I then looked at the source code for mv and quickly saw that there was no attempt to check permission on the real uid. So I told Marc it would allow anyone to become root. He wanted to see it in action, so I logged into research (I don???t remember what our organization's shared login was). No one in our organization had root access on research. Marc and I didn't have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users). I think the actual sequence of commands was: > > cd / > > cp etc/passwd tmp > > ed tmp/passwd > > 1s/^root:[^:]*:/root::/ > > w > > q > > mv etc etc2 > > mv tmp etc > > su > > mv etc tmp > > mv etc2 etc > > mv etc/as2 etc/.as2 > > {logout, hangup and wonder} > > The last bit was a test to see what was noticed about what I did. > > Marc and I talked for a while about it and discussed if we had any need to be root on our local machines, but couldn't think of any pressing need, but knowing we could was a bit of a comfort. After a short time, Marc suggested logging back in to see what, if anything, had been done. > > /bin/mv had lost setuid to root > > /etc/as2 was restored > > /etc/.as2 was nonexistent > > > > And the next day, the motd on research mentioned that there's a new syscall: access. And mv(1) now used it. > > > > Second: > > > > Our organization was one (out of possibly others) subject of Ken's codenih that he documented in his Turing Award article in CACM. > > > > As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research. Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems. > > > > Our C compiler guy, Rich Graveman, who kept in close contact with Dennis and was always getting us the latest compiler to install, had gone to MH and came back with a tape of a new compiler. Rich, being a careful fellow, did a size on c0, c1, c2 on the files from the tape and did the same on the running compiler pieces in /lib. > > Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it was union). So Rich did nm's on the two different c0's and discovered a name "codenih" in the old compiler that wasn't in the new one from Dennis. He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, followed by a cd codenih. Was he surprised! Then he went back to a local machine and tried to login as root/codenih, which, of course, worked. He was even more surprised and told a number of colleagues, myself included. (I logged into research and printed out the source in /usr/ken/codenih. I was super impressed.) > > > > I think you misunderstood the codenih bit. > > As Ken had given us a (shared among a few of us) login, we had given him one. > > And Dick Haight refused him root access. > > And no one in PY had root access on research. > > > > So much for denying Ken root access on the PWB systems. > > Ken "infected" the PWB C compiler with codenih, which gave him free rein. I don't know how or when he first installed it, but I suspect he was aware of any extant security holes (e.g., the mv setuid root) to allow him to replace the compiler the first time. > > > > I don't know if the PWB crowd was the impetus for Ken writing codenih or if it was something he had used on others prior to us or if he ever used it on anyone else. > > Needless to say, Dick Haight was beside himself. > > I just thought it was a great feat of programming and was thrilled when he described it in CACM. > > > > Alan > > > > > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From mah at mhorton.net Tue Nov 23 12:28:29 2021 From: mah at mhorton.net (Mary Ann Horton) Date: Mon, 22 Nov 2021 18:28:29 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: PL/I was my favorite mainframe programming language my last two years as an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and COBOL. My student job was to enhance a PL/I package for a History professor. As a grad student in 1976, my first job as a TA was to teach PL/I to undergrads. There were a lot of business students in the class. We thought PL/I was likely to be the future of business programming, as a better alternative to COBOL. I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.     Mary Ann On 11/16/2021 6:57 AM, Douglas McIlroy wrote: > The following remark stirred old memories. Apologies for straying off > the path of TUHS. > >> I have gotten the impression that [PL/I] was a language that was beloved by no one. > As I was a designer of PL/I, an implementer of EPL (the preliminary > PL/I compiler used to build Multics), and author of the first PL/I > program to appear in the ACM Collected Algorithms, it's a bit hard to > admit that PL/I was "insignificant". I'm proud, though, of having > conceived the SIGNAL statement, which pioneered exception handling, > and the USES and SETS attributes, which unfortunately sank into > oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. > The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > > After the ACM program I never wrote another line of PL/I. > Gratification finally came forty years on when I met a retired > programmer who, unaware of my PL/I connection, volunteered that she > had loved PL/I above all other programming languages. > > Doug From henry.r.bent at gmail.com Tue Nov 23 17:57:59 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 23 Nov 2021 02:57:59 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton wrote: > PL/I was my favorite mainframe programming language my last two years as > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and > COBOL. My student job was to enhance a PL/I package for a History > professor. > What language were the PL/I compilers written in? Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Nov 23 18:10:42 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 23 Nov 2021 01:10:42 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <202111230810.1AN8Ag1c012469@freefriends.org> Henry Bent wrote: > On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton wrote: > > > PL/I was my favorite mainframe programming language my last two years as > > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and > > COBOL. My student job was to enhance a PL/I package for a History > > professor. > > > > What language were the PL/I compilers written in? > > Wikipedia claims that IBM is still developing a PL/I compiler, which I > suppose I have no reason to disbelieve, but I'm very curious as to who is > using it and for what purpose. > > -Henry PL/1 compiler for Linux: http://www.iron-spring.com/ PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net :-) Arnold From henry.r.bent at gmail.com Tue Nov 23 18:28:23 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 23 Nov 2021 03:28:23 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: <202111230810.1AN8Ag1c012469@freefriends.org> References: <202111230810.1AN8Ag1c012469@freefriends.org> Message-ID: On Tue, 23 Nov 2021 at 03:10, wrote: > Henry Bent wrote: > > > On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton wrote: > > > > > PL/I was my favorite mainframe programming language my last two years > as > > > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, > and > > > COBOL. My student job was to enhance a PL/I package for a History > > > professor. > > > > > > > What language were the PL/I compilers written in? > > > > Wikipedia claims that IBM is still developing a PL/I compiler, which I > > suppose I have no reason to disbelieve, but I'm very curious as to who is > > using it and for what purpose. > > > > -Henry > > PL/1 compiler for Linux: http://www.iron-spring.com/ > > PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net "Expect some more releases soon" and the last release was 0.0.whatever, in 2007. I think that speaks volumes as to how popular PL/I is today. That being said, the Linux compiler does appear to be actively developed, and I suppose I shouldn't be surprised that the two platforms for active development are Linux and OS/2 (!). I have a vague recollection of installing and playing with a PL/I compiler demo for Ultrix, but I figured that the language was essentially dead at that point. I suppose I shouldn't be too surprised that there are still people using it, as this is the world of "we wrote the specifications in 1975 and there's no reason to update them," but I have a hard time imagining those companies being truly competitive, and an even harder time imagining them attracting talent under retirement age. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Nov 24 03:26:41 2021 From: athornton at gmail.com (Adam Thornton) Date: Tue, 23 Nov 2021 10:26:41 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On Tue, Nov 23, 2021 at 1:00 AM Henry Bent wrote: What language were the PL/I compilers written in? Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose. I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS. Does that ring any bells for anyone? Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Nov 24 04:54:33 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 23 Nov 2021 13:54:33 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: > On Nov 23, 2021, at 12:31, Adam Thornton wrote: > >  > >> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent wrote: >> What language were the PL/I compilers written in? >> >> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose. >> >> >> >> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS. Does that ring any bells for anyone? >> >> Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Nov 24 05:08:44 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 23 Nov 2021 14:08:44 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: Tpl > On Nov 23, 2021, at 12:31, Adam Thornton wrote: > >  > >> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent wrote: >> What language were the PL/I compilers written in? >> >> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose. >> >> >> >> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS. Does that ring any bells for anyone? >> >> Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Wed Nov 24 05:04:36 2021 From: aek at bitsavers.org (Al Kossow) Date: Tue, 23 Nov 2021 11:04:36 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On 11/23/21 10:54 AM, Ron Natalie wrote: >> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS. PL/S From stewart at serissa.com Wed Nov 24 05:39:32 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Tue, 23 Nov 2021 14:39:32 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: > On 2021, Nov 23, at 2:04 PM, Al Kossow wrote: > > On 11/23/21 10:54 AM, Ron Natalie wrote: > >>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS. > > PL/S PL/S also led to PL.8 which was used for the first IBM Risc From thomas.paulsen at firemail.de Wed Nov 24 07:54:26 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 23 Nov 2021 22:54:26 +0100 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: Hi, I remember that PL-1 was regarded in the 70-80ths as a superior programming language, incorporating the best concepts of the languages Mary enumerated. There even was a PL-1 inspired SPL language by siemens for the bs2000 mainframe os including bit fields etc. for system programming like C. Large parts of the start-amadeus ticketing-software were written in SPL. Thus PL-1 and its derivates were very high-ranked in the 70ths and 80ths, regarded as the ultimate ratio of the programming languages by many mainframe experts in those days. I mean we are now entering the mainframe horizon, totally different to our UNIX and C mini computer, workstation and PC world we all are firm with. --------------------------------------------------------------------------------------------- PL/I was my favorite mainframe programming language my last two years as an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and COBOL. My student job was to enhance a PL/I package for a History professor. As a grad student in 1976, my first job as a TA was to teach PL/I to undergrads. There were a lot of business students in the class. We thought PL/I was likely to be the future of business programming, as a better alternative to COBOL. I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.     Mary Ann On 11/16/2021 6:57 AM, Douglas McIlroy wrote: > The following remark stirred old memories. Apologies for straying off > the path of TUHS. > >> I have gotten the impression that [PL/I] was a language that was beloved by no one. > As I was a designer of PL/I, an implementer of EPL (the preliminary > PL/I compiler used to build Multics), and author of the first PL/I > program to appear in the ACM Collected Algorithms, it's a bit hard to > admit that PL/I was "insignificant". I'm proud, though, of having > conceived the SIGNAL statement, which pioneered exception handling, > and the USES and SETS attributes, which unfortunately sank into > oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. > The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > > After the ACM program I never wrote another line of PL/I. > Gratification finally came forty years on when I met a retired > programmer who, unaware of my PL/I connection, volunteered that she > had loved PL/I above all other programming languages. > > Doug From rich.salz at gmail.com Thu Nov 25 01:18:56 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 24 Nov 2021 10:18:56 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did. He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux ( http://www.iron-spring.com/)" IBM still uses PL/1. Remember, the main definition of "legacy" is "revenue-producing." TRY:PROC OPTIONS(MAIN); DCL (IF,THEN,ELSE) FIXED BINARY (31); IF = 1; THEN = 2; ELSE = 3; IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; END TRY; -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Nov 25 01:45:09 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 24 Nov 2021 07:45:09 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <20211124154509.GM3889@mcvoy.com> Say hi to Barry for me, I knew him back in the UUCP days, he was always pleasant. That bit of PL/1 is nuts but funny. On Wed, Nov 24, 2021 at 10:18:56AM -0500, Richard Salz wrote: > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax > horror lying around, and he did. He said: "this was tested on the Iron > Spring Software PL/1 compiler running on openSuSe Linux ( > http://www.iron-spring.com/)" > > IBM still uses PL/1. Remember, the main definition of "legacy" is > "revenue-producing." > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > END TRY; -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From norman at oclsc.org Thu Nov 25 01:50:52 2021 From: norman at oclsc.org (Norman Wilson) Date: Wed, 24 Nov 2021 10:50:52 -0500 Subject: [TUHS] Book Recommendation Message-ID: <1637769055.903.for-standards-violators@oclsc.org> Larry McVoy: Say hi to Barry for me, I knew him back in the UUCP days, he was always pleasant. ==== And for me. Knew him back in my DECUS days. Also tell him that since he runs the World, it's all his fault. Norman Wilson Toronto ON From rdm at cfcl.com Thu Nov 25 04:34:08 2021 From: rdm at cfcl.com (Rich Morin) Date: Wed, 24 Nov 2021 10:34:08 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> Speaking of Barry and IBM, I've always loved his snark on AIX: "It will remind you of Unix." -r P.S. My guess is that this code sets ELSE to 2. True? > On Nov 24, 2021, at 07:18, Richard Salz wrote: > > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did. He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)" > > IBM still uses PL/1. Remember, the main definition of "legacy" is "revenue-producing." > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > END TRY; From lm at mcvoy.com Thu Nov 25 04:40:40 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 24 Nov 2021 10:40:40 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> Message-ID: <20211124184040.GS3889@mcvoy.com> On Wed, Nov 24, 2021 at 10:34:08AM -0800, Rich Morin wrote: > Speaking of Barry and IBM, I've always loved his snark on AIX: "It will remind you of Unix." Barely. I think after SCO, AIX is the Unix I loved the least. SMIT - just say no. From clemc at ccc.com Thu Nov 25 05:39:19 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 24 Nov 2021 14:39:19 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: <20211124184040.GS3889@mcvoy.com> References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> <20211124184040.GS3889@mcvoy.com> Message-ID: On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy wrote: > SMIT - just say no. There were a number of things IBM did well with AIX so I'm not quite so glib knocking everything from them. But I agree that SMIT was the not so well thought out piece and never fully understood why it ended up being such a bad example of systems SW. ... but .... I always suspected that SMIT was an example of what IT managers running mainframe thought of UNIX. The folks at IBM set out (and did) a thorough and well thought out requirements study IBM style ... and then ... they only talked to Mainframe IT folks, not people that actually had experience in running UNIX in a production setting from their (like on a BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks that came to a USENIX LISA, they talked to customers that came to a SHARE meeting). So they solved the wrong set of problems. SMIT was a force fit of UNIX to mainframe shop and never was quite right for either group. I'm not sure the IT folks really liked it much better than the UNIX folks, but at least for them it used their terminology and their concepts (*e.g.* DASD *vs.* DISK). BTW: HP, I thought had a similar issue and they did not really understand the UNIX user. DEC parts of so got it/parts did not. Many DECies wanted Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were really better in their hearts), but at least there were a ton of folks inside of DEC doing the Unix work that 'got it.' As I have said before, it was always interesting having all of them as customers at LCC. You got to see the good and bad of all the systems vendors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Nov 25 06:01:12 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 24 Nov 2021 15:01:12 -0500 Subject: [TUHS] IBM Unix Message-ID: I remember getting an early RT without being given the root password. Now there hadn’t been too many Unix boxes I wasn’t able to break into. The Rt you could turn the key to the wrench symbol and get into the maintenance menus. Selecting to view some document which was displayed with more and that you could bang a root shell out of. > On Nov 24, 2021, at 14:42, Clem Cole wrote: > >  > > >> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy wrote: >> SMIT - just say no. > There were a number of things IBM did well with AIX so I'm not quite so glib knocking everything from them. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Nov 25 06:02:25 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 24 Nov 2021 12:02:25 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> <20211124184040.GS3889@mcvoy.com> Message-ID: <20211124200225.GV3889@mcvoy.com> HP was much better than AIX, you could ignore their admin crud and just edit the /etc files and stuff worked. With AIX, I never figured out how to not use SMIT, it was pretty intertwined with everything. It was super annoying, I'm not saying it didn't work, it did, but it was very clunky and you couldn't just go edit /etc/fstab and make stuff work (well, I couldn't, maybe there is someone who could). I hated it. On Wed, Nov 24, 2021 at 02:39:19PM -0500, Clem Cole wrote: > On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy wrote: > > > SMIT - just say no. > > There were a number of things IBM did well with AIX so I'm not quite so > glib knocking everything from them. > > But I agree that SMIT was the not so well thought out piece and never fully > understood why it ended up being such a bad example of systems SW. ... but > .... I always suspected that SMIT was an example of what IT managers > running mainframe thought of UNIX. The folks at IBM set out (and did) a > thorough and well thought out requirements study IBM style ... and then ... > they only talked to Mainframe IT folks, not people that actually had > experience in running UNIX in a production setting from their (like on a > BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks > that came to a USENIX LISA, they talked to customers that came to a SHARE > meeting). So they solved the wrong set of problems. SMIT was a force fit > of UNIX to mainframe shop and never was quite right for either group. I'm > not sure the IT folks really liked it much better than the UNIX folks, but > at least for them it used their terminology and their concepts (*e.g.* DASD > *vs.* DISK). > > BTW: HP, I thought had a similar issue and they did not really understand > the UNIX user. DEC parts of so got it/parts did not. Many DECies wanted > Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were > really better in their hearts), but at least there were a ton of folks > inside of DEC doing the Unix work that 'got it.' > > As I have said before, it was always interesting having all of them as > customers at LCC. You got to see the good and bad of all the systems > vendors. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From arnold at skeeve.com Thu Nov 25 06:13:34 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 24 Nov 2021 13:13:34 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <202111242013.1AOKDYNd007770@freefriends.org> Richard Salz wrote: > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax > horror lying around, and he did. He said: "this was tested on the Iron > Spring Software PL/1 compiler running on openSuSe Linux ( > http://www.iron-spring.com/)" > > IBM still uses PL/1. Remember, the main definition of "legacy" is > "revenue-producing." > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > END TRY; From robpike at gmail.com Thu Nov 25 06:15:47 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 25 Nov 2021 07:15:47 +1100 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: I thought it was TRY:PROC OPTIONS(MAIN); DCL (IF,THEN,ELSE) FIXED BINARY (31); IF = 1; THEN = 2; ELSE = 3; IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE; END TRY; But yeah. Best to Barry. -rob On Thu, Nov 25, 2021 at 2:23 AM Richard Salz wrote: > > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did. He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)" > > IBM still uses PL/1. Remember, the main definition of "legacy" is "revenue-producing." > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > END TRY; > From will.senn at gmail.com Thu Nov 25 06:18:28 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 24 Nov 2021 14:18:28 -0600 Subject: [TUHS] Book Recommendation In-Reply-To: <202111242013.1AOKDYNd007770@freefriends.org> References: <202111242013.1AOKDYNd007770@freefriends.org> Message-ID: Since we're all recommending books, I'd like to recommend: Richard Fitzpatrick's translation of J. L. Heiberg's Euclid's Elements of Geometry. It's fantastic, and without Euclid, we'd prolly not have unix... Will On 11/24/21 2:13 PM, arnold at skeeve.com wrote: > Richard Salz wrote: > >> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax >> horror lying around, and he did. He said: "this was tested on the Iron >> Spring Software PL/1 compiler running on openSuSe Linux ( >> http://www.iron-spring.com/)" >> >> IBM still uses PL/1. Remember, the main definition of "legacy" is >> "revenue-producing." >> >> TRY:PROC OPTIONS(MAIN); >> DCL (IF,THEN,ELSE) FIXED BINARY (31); >> >> IF = 1; >> THEN = 2; >> ELSE = 3; >> >> IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; >> >> END TRY; From robpike at gmail.com Thu Nov 25 06:27:52 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 25 Nov 2021 07:27:52 +1100 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: Also isn't it PROCEDURE? I don't remember PROC. -rob On Thu, Nov 25, 2021 at 7:15 AM Rob Pike wrote: > > I thought it was > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE; > > END TRY; > > But yeah. > > Best to Barry. > > -rob > > On Thu, Nov 25, 2021 at 2:23 AM Richard Salz wrote: > > > > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did. He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)" > > > > IBM still uses PL/1. Remember, the main definition of "legacy" is "revenue-producing." > > > > TRY:PROC OPTIONS(MAIN); > > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > > > IF = 1; > > THEN = 2; > > ELSE = 3; > > > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > > > END TRY; > > From joe at via.net Thu Nov 25 06:21:17 2021 From: joe at via.net (joe mcguckin) Date: Wed, 24 Nov 2021 12:21:17 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: <376D7B09-84A7-4DB3-AFED-97E8A279EEEB@via.net> In PL/I, language keywords are not reserved. Makes for interesting work when writing the lex scanner. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Nov 24, 2021, at 12:15 PM, Rob Pike wrote: > > I thought it was > > TRY:PROC OPTIONS(MAIN); > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > IF = 1; > THEN = 2; > ELSE = 3; > > IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE; > > END TRY; > > But yeah. > > Best to Barry. > > -rob > > On Thu, Nov 25, 2021 at 2:23 AM Richard Salz wrote: >> >> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did. He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)" >> >> IBM still uses PL/1. Remember, the main definition of "legacy" is "revenue-producing." >> >> TRY:PROC OPTIONS(MAIN); >> DCL (IF,THEN,ELSE) FIXED BINARY (31); >> >> IF = 1; >> THEN = 2; >> ELSE = 3; >> >> IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; >> >> END TRY; >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Nov 25 07:27:21 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 24 Nov 2021 16:27:21 -0500 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: Yeah PROCEDURE is the official word, but if you're gonna low DCL heresy, might as well throw in PROC. On Wed, Nov 24, 2021 at 3:28 PM Rob Pike wrote: > Also isn't it PROCEDURE? I don't remember PROC. > > -rob > > On Thu, Nov 25, 2021 at 7:15 AM Rob Pike wrote: > > > > I thought it was > > > > TRY:PROC OPTIONS(MAIN); > > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > > > IF = 1; > > THEN = 2; > > ELSE = 3; > > > > IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE; > > > > END TRY; > > > > But yeah. > > > > Best to Barry. > > > > -rob > > > > On Thu, Nov 25, 2021 at 2:23 AM Richard Salz > wrote: > > > > > > I asked my pal Barry Shein, who many of you know, if he had his PL/1 > syntax horror lying around, and he did. He said: "this was tested on the > Iron Spring Software PL/1 compiler running on openSuSe Linux ( > http://www.iron-spring.com/)" > > > > > > IBM still uses PL/1. Remember, the main definition of "legacy" is > "revenue-producing." > > > > > > TRY:PROC OPTIONS(MAIN); > > > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > > > > > IF = 1; > > > THEN = 2; > > > ELSE = 3; > > > > > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > > > > > END TRY; > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Thu Nov 25 08:19:05 2021 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Wed, 24 Nov 2021 14:19:05 -0800 Subject: [TUHS] Book Recommendation In-Reply-To: References: Message-ID: On Wed, Nov 24, 2021 at 7:23 AM Richard Salz wrote: > .... > Compiled by: Multics PL/I Compiler, Release 33f, of February 11, 2017 Compiled at: Installation and location Compiled on: 11/24/21 1411.5 pst Wed Options: table list 1 try:proc options(main); 2 dcl (if,then,else) fixed binary (31); 3 4 if = 1; 5 then = 2; 6 else = 3; 7 8 if if = then then then = if; else else = then; 9 10 end try; -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Nov 25 08:29:27 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 24 Nov 2021 16:29:27 -0600 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Here, lemme see if I can help more directly... Hopefully, this will help move this PL/I stuff thread off the book recommendation thread. If not, someone with more List knowhow, please help. In line with the new subject,  What, if any, features does PL/I have that are not realized in a modern language? Thanks, Will On 11/24/21 4:19 PM, Charles Anthony wrote: > > > On Wed, Nov 24, 2021 at 7:23 AM Richard Salz wrote: > > .... > > >           Compiled by: Multics PL/I Compiler, Release 33f, of February > 11, 2017 >           Compiled at: Installation and location >           Compiled on: 11/24/21  1411.5 pst Wed >               Options: table list > >         1 try:proc options(main); >         2    dcl (if,then,else) fixed binary (31); >         3 >         4    if = 1; >         5    then = 2; >         6    else = 3; >         7 >         8    if if = then then then = if; else else = then; >         9 >        10 end try; > > -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Nov 25 09:00:47 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 25 Nov 2021 10:00:47 +1100 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Message-ID: Far too many semicolons, no keywords, and adjustable integer sizes. -rob On Thu, Nov 25, 2021 at 9:31 AM Will Senn wrote: > > Here, lemme see if I can help more directly... Hopefully, this will help move this PL/I stuff thread off the book recommendation thread. If not, someone with more List knowhow, please help. > > In line with the new subject, What, if any, features does PL/I have that are not realized in a modern language? > > Thanks, > > Will > > On 11/24/21 4:19 PM, Charles Anthony wrote: > > > > On Wed, Nov 24, 2021 at 7:23 AM Richard Salz wrote: >> >> .... > > > Compiled by: Multics PL/I Compiler, Release 33f, of February 11, 2017 > Compiled at: Installation and location > Compiled on: 11/24/21 1411.5 pst Wed > Options: table list > > 1 try:proc options(main); > 2 dcl (if,then,else) fixed binary (31); > 3 > 4 if = 1; > 5 then = 2; > 6 else = 3; > 7 > 8 if if = then then then = if; else else = then; > 9 > 10 end try; > > -- Charles > > From rich.salz at gmail.com Thu Nov 25 09:13:18 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 24 Nov 2021 18:13:18 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Message-ID: On Wed, Nov 24, 2021 at 6:03 PM Rob Pike wrote: > Far too many semicolons, no keywords, and adjustable integer sizes. > > I don't know if this falls into Rob's list or not, but the PL/1 macro language is powerful; https://en.wikipedia.org/wiki/PL/I_preprocessor -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Nov 25 09:54:57 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 24 Nov 2021 18:54:57 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation Message-ID: > What, if any, features does PL/I have that are not realized in a modern language? Here are a few dredged from the mental cranny where they have mouldered for 50+ years. 1. Assignment by name. If A and B are structs (not official PL/I terminology), then A + B A = B copies similarly named fields of B to corresponding fields in A. 2. Both binary and decimal data with arithmetic rounded to any specified precision. 3. Bit strings of arbitrary length, with bitwise Boolean operations plus substr and catenation. 4. A named array is normally passed by reference, as in F(A). But if the argument is not a bare name, as in F((A)), it is passed by value. 5. IO by name. On input this behaves like assignment from a constant, with appropriate type conversion. 6. A SORT statement. 7. Astonishingly complete set of implicit data conversions. E.g. if X is floating-point and S is a string, the assignment X = S works when S = "2" and raises an exception (not PL/I terminology) when S = "A". My 1967 contribution to ACM collected algorithms exploited 3 and 4. I don't know another language in which that algorithm is as succinct. Doug From beebe at math.utah.edu Thu Nov 25 11:48:17 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 24 Nov 2021 18:48:17 -0700 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Message-ID: Will Senn asks on Wed, 24 Nov 2021 16:29:27 -0600: >> What, if any, features does PL/I have that are not realized >> in a modern language? One that I exploited heavily was the "ON ENDPAGE" trap: I wrote code that we used from both PL/I and Fortran to attach running page headers/footers, with a job name, timestamp, and page number. This mattered to us a lot when our nightly outputs sometimes ran to a box of z-fold paper (1K or 2K sheet? my memory is hazy). In Unix, of course, we would just run myprog | pr > myprog.lst but IBM mainframes of the 1960s and 1970s did not have anything remotely like that at academic customer sites. Alas, all of my PL/I code archives were lost to a dumpster some 30 years ago: we lacked the disk space to make copies of a couple of thousand 9-track tapes, and with the retirement of our DEC mainframes, we no longer had 9-track tape drives to read the tapes. I have long regretted our action, but budgets, and the limited technology of the time, gave us no option. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From ggm at algebras.org Thu Nov 25 12:03:43 2021 From: ggm at algebras.org (George Michaelson) Date: Thu, 25 Nov 2021 12:03:43 +1000 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Message-ID: I have a relative who is an archivist, the sister-discipline to librarians (Mike Lesk was at heart I think, in the library most the time time. I say this, because I always think about Mike when the topic of data and libraries comes up. He was nice to me at UCL and I have a soft spot for anyone who was nice to me.) Anyway, She tells me that the primary role of archivists is to help people throw things away. As a (sometime) scientist in (mostly) data, I know I have serial hoarding disease. But I also know that NASA and other agencies only found some things, by going back into the stacks to re-read old tapes, without the "noise reduction filter" which had taken signal out. So I feel your pain, loosing the tapes will have hurt. But I also know along the path in time, Somebody had a role to play, curating the data into the modern era. You're not alone, the BBC had this problem in spades, re-using Umatic tape to save money. Ephemeral content which turns out to be in some cases the probably only copy of what is data to us now, but was junk to them then. -G From arnold at skeeve.com Thu Nov 25 17:22:02 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 25 Nov 2021 00:22:02 -0700 Subject: [TUHS] Book Recommendation In-Reply-To: <202111242013.1AOKDYNd007770@freefriends.org> References: <202111242013.1AOKDYNd007770@freefriends.org> Message-ID: <202111250722.1AP7M2Tu022646@freefriends.org> What I meant to write here, before my ssh connection dropped, was that FORTRAN also did not reserve keywords. Arnold arnold at skeeve.com wrote: > Richard Salz wrote: > > > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax > > horror lying around, and he did. He said: "this was tested on the Iron > > Spring Software PL/1 compiler running on openSuSe Linux ( > > http://www.iron-spring.com/)" > > > > IBM still uses PL/1. Remember, the main definition of "legacy" is > > "revenue-producing." > > > > TRY:PROC OPTIONS(MAIN); > > DCL (IF,THEN,ELSE) FIXED BINARY (31); > > > > IF = 1; > > THEN = 2; > > ELSE = 3; > > > > IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN; > > > > END TRY; From tih at hamartun.priv.no Thu Nov 25 20:26:14 2021 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Thu, 25 Nov 2021 11:26:14 +0100 Subject: [TUHS] Book Recommendation In-Reply-To: <20211124184040.GS3889@mcvoy.com> (Larry McVoy's message of "Wed, 24 Nov 2021 10:40:40 -0800") References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> <20211124184040.GS3889@mcvoy.com> Message-ID: Larry McVoy writes: > SMIT - just say no. I remember it being useful for one thing: when I was unsure of the correct way to do some AIX specific operation, I could enter SMIT, get to where it was ready to do it for me, and it would show me the command line it was about to run. Then I could reread the man page for that command, knowing which options and parameters SMIT would use. So as a learning tool it wasn't all bad. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From stu at remphrey.net Thu Nov 25 22:20:56 2021 From: stu at remphrey.net (Stuart Remphrey) Date: Thu, 25 Nov 2021 20:20:56 +0800 Subject: [TUHS] AIX/SMIT (was Re: Book Recommendation) In-Reply-To: References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> <20211124184040.GS3889@mcvoy.com> Message-ID: On Thu, 25 Nov 2021, 18:35 Tom Ivar Helbekkmo via TUHS, < tuhs at minnie.tuhs.org> wrote: > Larry McVoy writes: > > > SMIT - just say no. > ... it would show me the command > line it was about to run. Ditto. The only SMIT or AIX feature I used/liked. Oh, that and mksysb. *maybe* the volume manager, if none was the alternative. Eventually got to understand (some of) the AIX stanza files & interactions, though also always hated them -- and no software worked/ported easily. Then I mercifully escaped AIX, after Wang went ch.11 -- a former manager/colleague had hired me into Wang Australia when they started selling HP, IBM & MIPS boxen along with PC office networks to avoid going broke, but weren't quick-footed enough. --- > Lisp is the most important idea in computer science. --Alan Kay > Unless you're a postfix lover?! Long live RPN, postscript, forth,... (ducks behind desk; exits, stage right) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Nov 26 00:47:30 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 25 Nov 2021 09:47:30 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com> Message-ID: On Wed, Nov 24, 2021 at 9:06 PM George Michaelson wrote: > I have a relative who is an archivist, the sister-discipline to librarians > .... > > Anyway, She tells me that the primary role of archivists is to help people > throw things away. George, thank you for the smile both for me and my wife. I am married to a former public director - *a.k.a.* a librarian with the formal degrees to prove it ;-). She always says weeding the collection is the most important part of the job. The key is knowing what you can toss, what is being used. For any library, there is* never a enough space to keep everything, but the problem is you can never fully know what will be valuable in the future.* Anyway, she has been on my case for probably 20 years to 'weed' my collection of things. A basement flood thanks to Hurricane Elsa this spring has finally forced it. Thanks again, Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Nov 26 02:35:13 2021 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 25 Nov 2021 11:35:13 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: On 11/24/21, Douglas McIlroy wrote: >> What, if any, features does PL/I have that are not realized in a modern >> language? > > 7. Astonishingly complete set of implicit data conversions. E.g. if X > is floating-point and S is a string, the assignment X = S works when S > = "2" and raises an exception (not PL/I terminology) when S = "A". This could definitely be a buzz saw without safety shields. Some of the implicit conversion rules, particularly those dealing with fixed point decimal arithmetic of mixed precision, had edge conditions that yielded non-intuitive results. I had a bug once that was due to a typo causing an unwanted implicit conversion. I had meant to type "IF A ~= B" (I'm using ~ here in place of the PL/I "not" operator--the EBCDIC angle character), meaning "IF A is not equal to B". What I actually typed is "IF A =~ B". (if A equals not-B). Both A and B were character strings. To apply the NOT operator, B was converted to a bit string with '0' converted to a zero bit and '1' to a one bit. The NOT was performed, then the bit string was converted back to a character string so that it could be compared to A. My clue as to the bug was a warning diagnostic from the compiler: "data conversion will be done by subroutine call". This almost always meant you'd accidentally invoked some kinky implicit type conversion, as was the case here. Here are some other PL/I features you don't see in modern languages. Some of these were present in the early IBM PL/I compilers but dropped from the ANSI standard: 1. Sterling pictures. These provided a convenient way to do math on and to display numbers representing pre-decimal British currency. They had pounds, shillings, and pence fields. This feature was dropped even from the IBM compilers some years after the Commonwealth nations all went decimal. 2. The DEFAULT statement. This was Forran's IMPLICIT on steroids. It let you say things like "data items with names beginning with A-G are decimal, I-N are binary, and O-Z are decimal". There could also be overlap between DEFAULT declarations. So in addition to the rule I just mentioned, you could say "A-J are fixed point and K-Z are floating point." With both of these rules in effect, identifier FOO would be implicitly "fixed decimal", J would be "fixed biary, and KOOL would be "float binary". At our PL/I shop we considered DEFAULT to be a toxic language feature that was banned. The problem is that in the presence of a complicated nest of DEFAULTs, when you see the declaration for an identifier it can be next to impossible to tell what its complete data type actually is. 3. PL/I declarations cover the entire scope of the innermost BEGIN/END block that contains them, regardless of where within that block the declaration occurs. Thus you can use variables before they are declared. This was mildly useful if you were composing a program at the keypunch. Some programmers would write down the declarations for their variables as they punched the cards, then when they came to the END statement for a block they would punch out the declarations. At our shop this, again, was considered a toxic language feature--we required all declarations to be at the start of their containing block. -Paul W. From usotsuki at buric.co Fri Nov 26 04:15:02 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 25 Nov 2021 13:15:02 -0500 (EST) Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: On Thu, 25 Nov 2021, Paul Winalski wrote: > 2. The DEFAULT statement. This was Forran's IMPLICIT on steroids. It > let you say things like "data items with names beginning with A-G are > decimal, I-N are binary, and O-Z are decimal". There could also be > overlap between DEFAULT declarations. So in addition to the rule I > just mentioned, you could say "A-J are fixed point and K-Z are > floating point." With both of these rules in effect, identifier FOO > would be implicitly "fixed decimal", J would be "fixed biary, and KOOL > would be "float binary". This reminds me of DEFINT, DEFSNG, DEFDBL, DEFSTR in MBASIC and its descendants and DEFLNG in QBASIC. A lot of QBASIC code used "DEFINT A-Z" for a slight speed boost. (Not sure if these work in the Xenix version of MBASIC) -uso. From paul.winalski at gmail.com Sat Nov 27 02:59:35 2021 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 26 Nov 2021 11:59:35 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: Back in the pre-virtual-memory days of the System/360, IBM offered its compilers in at least three variants: F, G, and H. They differed in the amount of memory required and in features and especially the sophistication of the optimizations they performed. IBM PL/I H required the most memory and performed the highest levels of optimization. There were some source language features to aid in optimization. My shop used PL/I F on DOS/360. It had one optimization-related source feature: the RECURSIVE and REORDER keywords on the PROCEDURE statement. A procedure that may be called recursively, either directly or indirectly, must have the RECURSIVE attribute. This tells the compiler to allocate local variables and temporaries on a call stack as opposed to statically. The ABIs for modern OSes always maintain a stack for procedure calls--not so with S/360/70 OS and DOS. The REORDER attribute tells the compiler that it is permitted to execute statements or pieces of statements in an order other than that explicitly specified in the program, as long as the end result has the same semantics. This is taken as a given in modern compilers. The higher-optimizing versions of IBM S/360 PL/I also had two PROCEDURE attributes USES and SETS that allowed the programmer to warn the compiler of side effects. The USES attribute lists identifiers global to the procedure that the procedure may read from, either explicitly or implicitly. The SETS attribute similarly lists identifiers that may be modified by the procedure. If USES is specified, the compiler can assume that no other global data are accessed, ans similarly if SETS is specified the compiler can assume that no other global data will be modified. Modern compilers perform global data flow analysis for all parts of the program accessible to the current compilation. While USES and SETS even today can potentially be helpful in describing obscure side effects, they were a very error-prone feature in their day and a real maintenance nightmare. They never made it into the ANSI standard and I think they've been dropped from modern IBM PL/I compilers. -Paul W. From woods at robohack.ca Sat Nov 27 05:49:40 2021 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 26 Nov 2021 11:49:40 -0800 Subject: [TUHS] AIX/SMIT (was Book Recommendation) In-Reply-To: <20211124200225.GV3889@mcvoy.com> References: <530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com> <20211124184040.GS3889@mcvoy.com> <20211124200225.GV3889@mcvoy.com> Message-ID: At Wed, 24 Nov 2021 12:02:25 -0800, Larry McVoy wrote: Subject: Re: [TUHS] Book Recommendation > > HP was much better than AIX, you could ignore their admin crud and > just edit the /etc files and stuff worked. With AIX, I never figured > out how to not use SMIT, it was pretty intertwined with everything. SMIT was really just a front end to the underlying commands and the files they edited; and as such a useful agent to help one figure out the IBM way of things. Under the hood it was all command-line and files and databases, and SMIT could be configured to tell you exactly what it was doing, and once you learned what to do you could easily avoid it entirely. It was basically created so that the office manager could also be the system manager. AIX though was like a lot of more enterprisy Unixes -- too much Not Invented Here Syndrome affecting their additions to the basic system, and as a result everything beyond what we now call POSIX was unique to it. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From tih at hamartun.priv.no Sat Nov 27 06:30:20 2021 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 26 Nov 2021 21:30:20 +0100 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: (Paul Winalski's message of "Fri, 26 Nov 2021 11:59:35 -0500") References: Message-ID: Paul Winalski writes: > Back in the pre-virtual-memory days of the System/360, IBM offered its > compilers in at least three variants: F, G, and H. They differed in > the amount of memory required and in features and especially the > sophistication of the optimizations they performed. IBM PL/I H > required the most memory and performed the highest levels of > optimization. Is there any relationship, other than pure coincidence, between this naming scheme and DEC's F, G, and H floating point number formats? -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From cowan at ccil.org Sat Nov 27 07:22:15 2021 From: cowan at ccil.org (John Cowan) Date: Fri, 26 Nov 2021 16:22:15 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: On Fri, Nov 26, 2021 at 3:32 PM Tom Ivar Helbekkmo via TUHS < tuhs at minnie.tuhs.org> wrote: Is there any relationship, other than pure coincidence, between this > naming scheme and DEC's F, G, and H floating point number formats? > I don't think so. The System/360 letters referred specifically to the amount of memory available, so a D compiler would run on a D machine with 256K, and E/F/G were 512K/1M/2M. The DEC floats were an extension of Fortran's exponent letters: D=double, E=generic, F=single. G is a variant of F with a different mantissa/exponent balance, and H is double double. S and T floats came later and were bit-for-bit compatible with IEEE binary32 and binary64 formats. Lisp went a different way: to D, E, F they added S for small floats and L for large floats. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanglasser at gmail.com Sat Nov 27 08:20:32 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 26 Nov 2021 17:20:32 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: <62C40630-CEA2-4F9E-B141-AF4AEFABB983@gmail.com> My mom was a librarian, my wife was a librarian, my father-in-law was a librarian and my son is a librarian. What I liked most about “weeding” was when one of my family brought me a “discard/destroy” weeded book. Unfortunately, since I retired I’ve been weeding my stuff. And I think I’ve discarded a bunch of (Bell Labs term) Technical Memoranda that I wrote, the contents of which would likely (possibly?) be of interest to TUHS. I was unaware of its existence until recently. - Alan > On Nov 25, 2021, at 9:50 AM, Clem Cole wrote: > >  > > >> On Wed, Nov 24, 2021 at 9:06 PM George Michaelson wrote: >> I have a relative who is an archivist, the sister-discipline to librarians .... >> >> Anyway, She tells me that the primary role of archivists is to help people throw things away. > George, thank you for the smile both for me and my wife. > > I am married to a former public director - a.k.a. a librarian with the formal degrees to prove it ;-). She always says weeding the collection is the most important part of the job. The key is knowing what you can toss, what is being used. For any library, there is never a enough space to keep everything, but the problem is you can never fully know what will be valuable in the future. > > Anyway, she has been on my case for probably 20 years to 'weed' my collection of things. A basement flood thanks to Hurricane Elsa this spring has finally forced it. > > Thanks again, > Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanglasser at gmail.com Sat Nov 27 08:33:01 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 26 Nov 2021 17:33:01 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> In my experience 9 track tapes were not guaranteed to be readable after some interval. In fact, a standard operations procedure was to copy important tapes to new media periodically. I distinctly remember a rather catastrophic error in the AT&T Worldnet ISP mail system. It was running a third party email server product on a large cluster of big Sun boxes. A new release was installed. It had bugs and curdled all of the customers’ data. It got backed out and a huge restore from backup effort began, only to find that a bunch of recently written tapes were unreadable. Needless to say, we had unhappy customers and, if I remember correctly, some very negative press in the WSJ and the NY Times. - Alan > On Nov 24, 2021, at 9:06 PM, George Michaelson wrote: > > I have a relative who is an archivist, the sister-discipline to > librarians (Mike Lesk was at heart I think, in the library most the > time time. I say this, because I always think about Mike when the > topic of data and libraries comes up. He was nice to me at UCL and I > have a soft spot for anyone who was nice to me.) > > Anyway, She tells me that the primary role of archivists is to help > people throw things away. > > As a (sometime) scientist in (mostly) data, I know I have serial > hoarding disease. But I also know that NASA and other agencies only > found some things, by going back into the stacks to re-read old tapes, > without the "noise reduction filter" which had taken signal out. > > So I feel your pain, loosing the tapes will have hurt. But I also know > along the path in time, Somebody had a role to play, curating the data > into the modern era. You're not alone, the BBC had this problem in > spades, re-using Umatic tape to save money. Ephemeral content which > turns out to be in some cases the probably only copy of what is data > to us now, but was junk to them then. > > -G From ggm at algebras.org Sat Nov 27 10:01:13 2021 From: ggm at algebras.org (George Michaelson) Date: Sat, 27 Nov 2021 10:01:13 +1000 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: I've always felt a huge disconnect between the decus tape philosophy of code, and the IBM approach of "this software feature costs you more" about things like language extensions and -O(n) flags (to use modern c compiler mental models) I did find the hardware trick of detuning the clock to sell more boxes and charging to remove the resistors also a bit iffy but I kind of understood it. But, being asked by some major client (defence) to implement recursion support and then charging everyone feels like the business model designed to kick start people cutting their own code to stop depending in yours -and I believe this is somewhat the story of university multi access systems on IBM and these seven dwarf competitors. Burroughs by comparison had (I am told, I didn't use them) shit hot code, the kernel was in a ci/cd deployment framework with smarts. And DEC had the decus tapes and everything in VMS was on microfiche. On Sat, 27 Nov 2021, 7:24 am John Cowan, wrote: > > > On Fri, Nov 26, 2021 at 3:32 PM Tom Ivar Helbekkmo via TUHS < > tuhs at minnie.tuhs.org> wrote: > > Is there any relationship, other than pure coincidence, between this >> naming scheme and DEC's F, G, and H floating point number formats? >> > > I don't think so. The System/360 letters referred specifically to the > amount of memory available, so a D compiler would run on a D machine with > 256K, and E/F/G were 512K/1M/2M. > > The DEC floats were an extension of Fortran's exponent letters: D=double, > E=generic, F=single. G is a variant of F with a different > mantissa/exponent balance, and H is double double. S and T floats came > later and were bit-for-bit compatible with IEEE binary32 and binary64 > formats. Lisp went a different way: to D, E, F they added S for small > floats and L for large floats. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drb at msu.edu Sat Nov 27 10:23:07 2021 From: drb at msu.edu (Dennis Boone) Date: Fri, 26 Nov 2021 19:23:07 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: (Your message of Fri, 26 Nov 2021 17:33:01 -0500.) <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> References: <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> Message-ID: <20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu> > In my experience 9 track tapes were not guaranteed to be readable after > some interval. In fact, a standard operations procedure was to copy > important tapes to new media periodically. There are always ways in which your backups can go wrong and not be readable, and I'm not arguing that here. But 9 track tapes have turned out to be pretty spectacularly long-lived. I've personally read tapes that were stored for 30+ years in unconditioned spaces. De From lm at mcvoy.com Sat Nov 27 10:30:06 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 26 Nov 2021 16:30:06 -0800 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu> References: <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> <20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu> Message-ID: <20211127003006.GK19525@mcvoy.com> On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote: > > In my experience 9 track tapes were not guaranteed to be readable after > > some interval. In fact, a standard operations procedure was to copy > > important tapes to new media periodically. > > There are always ways in which your backups can go wrong and not be > readable, and I'm not arguing that here. > > But 9 track tapes have turned out to be pretty spectacularly long-lived. > I've personally read tapes that were stored for 30+ years in > unconditioned spaces. Contrast that with the write only exabyte tapes. I lost some stuff to those. From imp at bsdimp.com Sat Nov 27 10:56:09 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 26 Nov 2021 17:56:09 -0700 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <20211127003006.GK19525@mcvoy.com> References: <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> <20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu> <20211127003006.GK19525@mcvoy.com> Message-ID: On Fri, Nov 26, 2021, 5:32 PM Larry McVoy wrote: > On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote: > > > In my experience 9 track tapes were not guaranteed to be readable > after > > > some interval. In fact, a standard operations procedure was to copy > > > important tapes to new media periodically. > > > > There are always ways in which your backups can go wrong and not be > > readable, and I'm not arguing that here. > > > > But 9 track tapes have turned out to be pretty spectacularly long-lived. > > I've personally read tapes that were stored for 30+ years in > > unconditioned spaces. > > Contrast that with the write only exabyte tapes. I lost some stuff to > those. > There is a reason that exabyte no longer exists. It used to take up a big swath of central Boulder. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Sat Nov 27 10:47:49 2021 From: sauer at technologists.com (Charles H. Sauer) Date: Fri, 26 Nov 2021 18:47:49 -0600 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <20211127003006.GK19525@mcvoy.com> References: <0ABB7ECD-049B-4993-938F-82BC924E0F39@gmail.com> <20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu> <20211127003006.GK19525@mcvoy.com> Message-ID: <632335e1-c1ea-0eb8-2629-3e0829057da7@technologists.com> I haven't done anything with 9 track tapes for a long time, but I used to help my father with his statistical research, processing what at the time seemed massive census and similar data sets on 9 track tape (using PL/I on 370s at U. MO Columbia). Some of his tapes were quite old, stored in his basement and then his garage, but I don't recall problems reading any of them. IMNSHO, it all depends on the brand/formulation of the tape. I've been going through old audio tapes and digitizing them (https://notes.technologists.com/notes/2021/08/21/making-private-1960s-and-70s-recordings-public/). Some are over 50 years old and still seem as good to me as when they were recorded. Others, I can anticipate from the brand/formulation that they are going to be trouble, if salvageable at all. Most surprisingly, unbranded and similar budget tapes have survived as well or better than some of the high-priced stuff. A few days ago I tried a reel from 1968. I was dismayed by how many times it had been spliced, but replace the splicing tape and found it viable. I have dozens of DDS-2, 3 & 4 cartridges from the 90s that I occasionally try to read. I don't recall any of them failing. (We probably should be COFFing this up.) Charlie On 11/26/2021 6:30 PM, Larry McVoy wrote: > On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote: >> > In my experience 9 track tapes were not guaranteed to be readable after >> > some interval. In fact, a standard operations procedure was to copy >> > important tapes to new media periodically. >> >> There are always ways in which your backups can go wrong and not be >> readable, and I'm not arguing that here. >> >> But 9 track tapes have turned out to be pretty spectacularly long-lived. >> I've personally read tapes that were stored for 30+ years in >> unconditioned spaces. > > Contrast that with the write only exabyte tapes. I lost some stuff to those. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From alanglasser at gmail.com Sat Nov 27 12:43:10 2021 From: alanglasser at gmail.com (Alan Glasser) Date: Fri, 26 Nov 2021 21:43:10 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <632335e1-c1ea-0eb8-2629-3e0829057da7@technologists.com> References: <632335e1-c1ea-0eb8-2629-3e0829057da7@technologists.com> Message-ID: <40B6AD3F-B40C-4F37-A802-51B1A39C0C51@gmail.com> On second thought, given that the Worldnet outage was late 1996, it was most likely that the backups were to 8mm tape. Exabyte?! - Alan > On Nov 26, 2021, at 8:10 PM, Charles H. Sauer wrote: > > I haven't done anything with 9 track tapes for a long time, but I used to help my father with his statistical research, processing what at the time seemed massive census and similar data sets on 9 track tape (using PL/I on 370s at U. MO Columbia). Some of his tapes were quite old, stored in his basement and then his garage, but I don't recall problems reading any of them. > > IMNSHO, it all depends on the brand/formulation of the tape. I've been going through old audio tapes and digitizing them (https://notes.technologists.com/notes/2021/08/21/making-private-1960s-and-70s-recordings-public/). Some are over 50 years old and still seem as good to me as when they were recorded. Others, I can anticipate from the brand/formulation that they are going to be trouble, if salvageable at all. Most surprisingly, unbranded and similar budget tapes have survived as well or better than some of the high-priced stuff. A few days ago I tried a reel from 1968. I was dismayed by how many times it had been spliced, but replace the splicing tape and found it viable. > > I have dozens of DDS-2, 3 & 4 cartridges from the 90s that I occasionally try to read. I don't recall any of them failing. > > (We probably should be COFFing this up.) > > Charlie > >> On 11/26/2021 6:30 PM, Larry McVoy wrote: >>> On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote: >>> > In my experience 9 track tapes were not guaranteed to be readable after >>> > some interval. In fact, a standard operations procedure was to copy >>> > important tapes to new media periodically. >>> >>> There are always ways in which your backups can go wrong and not be >>> readable, and I'm not arguing that here. >>> >>> But 9 track tapes have turned out to be pretty spectacularly long-lived. >>> I've personally read tapes that were stored for 30+ years in >>> unconditioned spaces. >> Contrast that with the write only exabyte tapes. I lost some stuff to those. > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Twitter: CharlesHSauer From jnc at mercury.lcs.mit.edu Sun Nov 28 01:25:27 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 27 Nov 2021 10:25:27 -0500 (EST) Subject: [TUHS] PL/I stuff - was: Book Recommendation Message-ID: <20211127152527.591D518C07B@mercury.lcs.mit.edu> > From: "Charles H. Sauer"k > I haven't done anything with 9 ktrack tapes for a long time ... > I don't recall problems reading any of them. ... > IMNSHO, it all depends on the brand/formulation of the tape. I've been > going through old audio tapes and digitizing them The vintage computer community has considerable experience with old tapes; in fact Chuck Guzis has a business reading them (which often includes converting old file formats to something modern software can grok). We originally depended heavily on the work of the vintage audio community, who pioneered working with old tapes, including the discovert of 'baking' them to improve their mechanical playability. ("the binder used to adhere the magnetic material to the backing ... becomes unstable" - playing such a tape will transfer much of the magnetic material to the head, destroying the tape's contents.) It's amazing how bad a tape can be, and still be readable. I had a couple of dump tapes of the CSR PWB1 machine at MIT, which I had thoughtlessly stored in my (at one period damp) basement, and they were covered in mold - and not just on the edges! Chuck had to build a special fixture to clean off the mold, but we read most of the first tape. (I had thoughtfully ade a second copy, which read perfectly.) Then I had to work out what the format was - it turned out that even though the machine had a V6 filesystem, my tape was a 'dd' of a BSD4.1c filesystem (for reasons I eventually worked out, but won't bore you all with). Dave Bridgham managed to mount that under Linux, and transform it into a TAR file. That was the source of many old treasures, including the V6 NCP UNIX. Noel From sauer at technologists.com Sun Nov 28 01:53:10 2021 From: sauer at technologists.com (Charles H Sauer) Date: Sat, 27 Nov 2021 09:53:10 -0600 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: <20211127152527.591D518C07B@mercury.lcs.mit.edu> References: <20211127152527.591D518C07B@mercury.lcs.mit.edu> Message-ID: <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> On 11/27/2021 9:25 AM, Noel Chiappa wrote: > > From: "Charles H. Sauer"k > > > I haven't done anything with 9 ktrack tapes for a long time ... > > I don't recall problems reading any of them. ... > > IMNSHO, it all depends on the brand/formulation of the tape. I've been > > going through old audio tapes and digitizing them > > The vintage computer community has considerable experience with old tapes; in > fact Chuck Guzis has a business reading them (which often includes converting > old file formats to something modern software can grok). > > We originally depended heavily on the work of the vintage audio community, who > pioneered working with old tapes, including the discovert of 'baking' them to > improve their mechanical playability. ("the binder used to adhere the magnetic > material to the backing ... becomes unstable" - playing such a tape will > transfer much of the magnetic material to the head, destroying the tape's > contents.) The notion of "baking" is slightly misleading. When done with audio tapes, the practice is to use a dehydrating oven at about 130F for about 24 hours. > It's amazing how bad a tape can be, and still be readable. I had a couple of > dump tapes of the CSR PWB1 machine at MIT, which I had thoughtlessly stored in > my (at one period damp) basement, and they were covered in mold - and not just > on the edges! Chuck had to build a special fixture to clean off the mold, but > we read most of the first tape. (I had thoughtfully ade a second copy, which > read perfectly.) > > Then I had to work out what the format was - it turned out that even though > the machine had a V6 filesystem, my tape was a 'dd' of a BSD4.1c filesystem > (for reasons I eventually worked out, but won't bore you all with). Dave > Bridgham managed to mount that under Linux, and transform it into a TAR > file. That was the source of many old treasures, including the V6 NCP UNIX. > > Noel > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From paul.winalski at gmail.com Sun Nov 28 01:53:35 2021 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 27 Nov 2021 10:53:35 -0500 Subject: [TUHS] 9-track tape (was PL/I stuff) Message-ID: DEC's VAX/VMS group got a customer bug report that was accompanied by a 9-track tape containing the programs and data necessary to reproduce the problem. When the engineer mounted the tape, it contained completely different data. He tried a different tape drive and this time he got the expected data. It turned out that the customer had reused the tape and recorded the reproducer at 1600 bpi on top of previous data recorded at 800 bpi. If the tape was mounted such that the drive didn't see the PE burst, it could still read the NRZI-encoded 800 bpi data. -Paul W. From sauer at technologists.com Sun Nov 28 01:58:52 2021 From: sauer at technologists.com (Charles H Sauer) Date: Sat, 27 Nov 2021 09:58:52 -0600 Subject: [TUHS] tape "baking" [was PL/I stuff - was: Book Recommendation In-Reply-To: <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> References: <20211127152527.591D518C07B@mercury.lcs.mit.edu> <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> Message-ID: On 11/27/2021 9:53 AM, Charles H Sauer wrote: > The notion of "baking" is slightly misleading. When done with audio > tapes, the practice is to use a dehydrating oven at about 130F for about > 24 hours. Ampex patent 5,236,790 says 54C for 16 hours. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From usotsuki at buric.co Sun Nov 28 02:07:45 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 27 Nov 2021 11:07:45 -0500 (EST) Subject: [TUHS] tape "baking" [was PL/I stuff - was: Book Recommendation In-Reply-To: References: <20211127152527.591D518C07B@mercury.lcs.mit.edu> <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> Message-ID: On Sat, 27 Nov 2021, Charles H Sauer wrote: > On 11/27/2021 9:53 AM, Charles H Sauer wrote: > >> The notion of "baking" is slightly misleading. When done with audio tapes, >> the practice is to use a dehydrating oven at about 130F for about 24 hours. > > Ampex patent 5,236,790 says 54C for 16 hours. That's 129F, so pretty much the same diff. -uso. From paul.winalski at gmail.com Sun Nov 28 02:12:28 2021 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 27 Nov 2021 11:12:28 -0500 Subject: [TUHS] PL/I stuff - was: Book Recommendation In-Reply-To: References: Message-ID: On 11/26/21, George Michaelson wrote: > >Burroughs by comparison had (I am > told, I didn't use them) shit hot code, the kernel was in a ci/cd > deployment framework with smarts. And DEC had the decus tapes and > everything in VMS was on microfiche. Originally on the S/360 IBM software was free (the DECUS tapes model) as well, and the source code was available on microfiche. There were some successful third party software products. For example, a lot of very big data centers shelled out the $$$ for SyncSort because it was so much better and faster than the (free) IBM sort/merge program. Then, as part of the settlement for one of the antitrust lawsuits, IBM was forced to unbundle software from hardware. IBM made lemonade out of this bunch of lemons by marketing its software licenses on a subscription basis vs. selling a license for a one-time charge (the model that DEC used, and that is most common in the PC market). Microsoft seems to be trending that way with Windows 10/11. -Paul W. From aek at bitsavers.org Sun Nov 28 03:42:05 2021 From: aek at bitsavers.org (Al Kossow) Date: Sat, 27 Nov 2021 09:42:05 -0800 Subject: [TUHS] tape "baking" [was PL/I stuff - was: Book Recommendation In-Reply-To: References: <20211127152527.591D518C07B@mercury.lcs.mit.edu> <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> Message-ID: <90aef905-c7c2-9856-5dd7-3f736666ddb0@bitsavers.org> On 11/27/21 9:39 AM, Al Kossow wrote: > On 11/27/21 8:07 AM, Steve Nickolas wrote: > >>> Ampex patent 5,236,790 says 54C for 16 hours. > > There are a few other tricks, like forcing air through the tape during baking > that we came up with in the 00s. There are others, like using 32 track 3490 MR > head stacks for recovery. > https://patents.google.com/patent/CA2817359A1 From aek at bitsavers.org Sun Nov 28 03:39:55 2021 From: aek at bitsavers.org (Al Kossow) Date: Sat, 27 Nov 2021 09:39:55 -0800 Subject: [TUHS] tape "baking" [was PL/I stuff - was: Book Recommendation In-Reply-To: References: <20211127152527.591D518C07B@mercury.lcs.mit.edu> <1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com> Message-ID: On 11/27/21 8:07 AM, Steve Nickolas wrote: >> Ampex patent 5,236,790 says 54C for 16 hours. There are a few other tricks, like forcing air through the tape during baking that we came up with in the 00s. There are others, like using 32 track 3490 MR head stacks for recovery. 80's Memorex is some of the worst tape ever made, it was also the cheapest, and way too many distribution and backup tapes were made using it. From jon at fourwinds.com Mon Nov 29 06:26:05 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 28 Nov 2021 12:26:05 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts Message-ID: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Eugene Miya visited by last week and accidentally left his copy of the book here so I decided to read it before he came back to pick it up. My overall impression is that while it contained a lot of information, it wasn't presented in a manner that I found interesting. I don't know the intended target audience, but it's not me. A good part of it is that my interest is in the evolution of technology. I think that a more accurate title for the book would be "A New History of the Business of Modern Computing". The book was thorough in covering the number of each type of machine sold and how much money was made, but that's only of passing interest to me. Were it me I would have just summarized all that in a table and used the space to tell some engaging anecdotes. There were a number of things that I felt the book glossed over or missed completely. One is that I didn't think that they gave sufficient credit to the symbiosis between C and the PDP-11 instruction set and the degree to which the PDP-11 was enormously influential. Another is that I felt that the book didn't give computer graphics adequate treatment. I realize that it was primarily in the workstation market segment which was not as large as some of the other segments, but in my opinion the development of the technology was hugely important as it eventually became commodified and highly profitable. Probably due to my personal involvement I felt that the book missed some important steps along the path toward open source. In particular, it used the IPO of Red Hat as the seminal moment while not even mentioning the role of Cygnus. My opinion is that Cygnus was a huge icebreaker in the adoption of open source by the business world, and that the Red Hat IPO was just the culmination. I also didn't feel that there was any message or takeaways for readers. I didn't get any "based on all this I should go and do that" sort of feeling. If the purpose of the book was to present a dry history then it pretty much did it's job. Obviously the authors had to pick and choose what to write about and I would have made some different choices. But, not my book. Jon From robpike at gmail.com Mon Nov 29 07:07:57 2021 From: robpike at gmail.com (Rob Pike) Date: Mon, 29 Nov 2021 08:07:57 +1100 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Message-ID: Is there a symbiosis between C and the PDP-11 instruction set? The machine was vital to C and Unix's success, but primarily due to the availability of a department-sized machine. Was the instruction set a significant component? Most Unix programmers wrote little to no assembly, although perhaps more read what came out of the compiler. But did it matter? Auto-increment and -decrement are often cited in this story, but they are not that important, really, and were around well before the PDP-11 made its appearance. I'm curious to hear arguments on either side. -rob On Mon, Nov 29, 2021 at 7:29 AM Jon Steinhart wrote: > > Eugene Miya visited by last week and accidentally left his copy of the > book here so I decided to read it before he came back to pick it up. > > My overall impression is that while it contained a lot of information, > it wasn't presented in a manner that I found interesting. I don't know > the intended target audience, but it's not me. > > A good part of it is that my interest is in the evolution of technology. > I think that a more accurate title for the book would be "A New History > of the Business of Modern Computing". The book was thorough in covering > the number of each type of machine sold and how much money was made, but > that's only of passing interest to me. Were it me I would have just > summarized all that in a table and used the space to tell some engaging > anecdotes. > > There were a number of things that I felt the book glossed over or missed > completely. > > One is that I didn't think that they gave sufficient credit to the symbiosis > between C and the PDP-11 instruction set and the degree to which the PDP-11 > was enormously influential. > > Another is that I felt that the book didn't give computer graphics adequate > treatment. I realize that it was primarily in the workstation market segment > which was not as large as some of the other segments, but in my opinion the > development of the technology was hugely important as it eventually became > commodified and highly profitable. > > Probably due to my personal involvement I felt that the book missed some > important steps along the path toward open source. In particular, it used > the IPO of Red Hat as the seminal moment while not even mentioning the role > of Cygnus. My opinion is that Cygnus was a huge icebreaker in the adoption > of open source by the business world, and that the Red Hat IPO was just the > culmination. > > I also didn't feel that there was any message or takeaways for readers. I > didn't get any "based on all this I should go and do that" sort of feeling. > > If the purpose of the book was to present a dry history then it pretty much > did it's job. Obviously the authors had to pick and choose what to write > about and I would have made some different choices. But, not my book. > > Jon From jon at fourwinds.com Mon Nov 29 07:15:20 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 28 Nov 2021 13:15:20 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Message-ID: <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Rob Pike writes: > Is there a symbiosis between C and the PDP-11 instruction set? The > machine was vital to C and Unix's success, but primarily due to the > availability of a department-sized machine. Was the instruction set a > significant component? Most Unix programmers wrote little to no > assembly, although perhaps more read what came out of the compiler. > But did it matter? Auto-increment and -decrement are often cited in > this story, but they are not that important, really, and were around > well before the PDP-11 made its appearance. > > I'm curious to hear arguments on either side. > > -rob Well, might just be my personal experience, but most of the machines that I had used before the 11 were classic accumulator architectures. I feel that the 11's pointer architecture combined with autoincrement and autodecrement was an amazing fit for C. If I remember correctly, it was very cool to have *p++ = *q++ be a single instruction. BTW, one thing that I forgot in my earlier post is that I think that the book also omitted any mention of Creative Commons. The book did talk about the business of the web and such, and it's my opinion that CC was an an essential third prong. The machines were one, the software was another, the third was content and CC was a big enabler. Jon From thomas.paulsen at firemail.de Mon Nov 29 07:23:09 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sun, 28 Nov 2021 22:23:09 +0100 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Message-ID: <811d4e0a0c4cd210261b84df286ff53a@firemail.de> I heard that the null terminated string was a 11-build-in. --- ------------------------------ Is there a symbiosis between C and the PDP-11 instruction set? The machine was vital to C and Unix's success, but primarily due to the availability of a department-sized machine. Was the instruction set a significant component? Most Unix programmers wrote little to no assembly, although perhaps more read what came out of the compiler. But did it matter? Auto-increment and -decrement are often cited in this story, but they are not that important, really, and were around well before the PDP-11 made its appearance. I'm curious to hear arguments on either side. -rob On Mon, Nov 29, 2021 at 7:29 AM Jon Steinhart wrote: > > Eugene Miya visited by last week and accidentally left his copy of the > book here so I decided to read it before he came back to pick it up. > > My overall impression is that while it contained a lot of information, > it wasn't presented in a manner that I found interesting. I don't know > the intended target audience, but it's not me. > > A good part of it is that my interest is in the evolution of technology. > I think that a more accurate title for the book would be "A New History > of the Business of Modern Computing". The book was thorough in covering > the number of each type of machine sold and how much money was made, but > that's only of passing interest to me. Were it me I would have just > summarized all that in a table and used the space to tell some engaging > anecdotes. > > There were a number of things that I felt the book glossed over or missed > completely. > > One is that I didn't think that they gave sufficient credit to the symbiosis > between C and the PDP-11 instruction set and the degree to which the PDP-11 > was enormously influential. > > Another is that I felt that the book didn't give computer graphics adequate > treatment. I realize that it was primarily in the workstation market segment > which was not as large as some of the other segments, but in my opinion the > development of the technology was hugely important as it eventually became > commodified and highly profitable. > > Probably due to my personal involvement I felt that the book missed some > important steps along the path toward open source. In particular, it used > the IPO of Red Hat as the seminal moment while not even mentioning the role > of Cygnus. My opinion is that Cygnus was a huge icebreaker in the adoption > of open source by the business world, and that the Red Hat IPO was just the > culmination. > > I also didn't feel that there was any message or takeaways for readers. I > didn't get any "based on all this I should go and do that" sort of feeling. > > If the purpose of the book was to present a dry history then it pretty much > did it's job. Obviously the authors had to pick and choose what to write > about and I would have made some different choices. But, not my book. > > Jon From kenbob at gmail.com Mon Nov 29 07:31:52 2021 From: kenbob at gmail.com (Ken Thompson) Date: Sun, 28 Nov 2021 13:31:52 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Message-ID: The PDP-11 had very little the syntax of B expressions. All of that was in place in B long before the PDP-11. To be honest, the byte addressing of the 11 was a significant hindrance. It was the genius of Dennis that was able to conquer the 11 as he installed types into the language. So, my opinion, the PDP-11 had no design on the type system of C and moreover it was not even helpful. On Sun, Nov 28, 2021 at 1:17 PM Jon Steinhart wrote: > Rob Pike writes: > > Is there a symbiosis between C and the PDP-11 instruction set? The > > machine was vital to C and Unix's success, but primarily due to the > > availability of a department-sized machine. Was the instruction set a > > significant component? Most Unix programmers wrote little to no > > assembly, although perhaps more read what came out of the compiler. > > But did it matter? Auto-increment and -decrement are often cited in > > this story, but they are not that important, really, and were around > > well before the PDP-11 made its appearance. > > > > I'm curious to hear arguments on either side. > > > > -rob > > Well, might just be my personal experience, but most of the machines > that I had used before the 11 were classic accumulator architectures. > I feel that the 11's pointer architecture combined with autoincrement > and autodecrement was an amazing fit for C. If I remember correctly, > it was very cool to have *p++ = *q++ be a single instruction. > > BTW, one thing that I forgot in my earlier post is that I think that > the book also omitted any mention of Creative Commons. The book did > talk about the business of the web and such, and it's my opinion that > CC was an an essential third prong. The machines were one, the software > was another, the third was content and CC was a big enabler. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Mon Nov 29 07:39:00 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 28 Nov 2021 16:39:00 -0500 (EST) Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <811d4e0a0c4cd210261b84df286ff53a@firemail.de> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <811d4e0a0c4cd210261b84df286ff53a@firemail.de> Message-ID: On Sun, 28 Nov 2021, Thomas Paulsen wrote: > I heard that the null terminated string was a 11-build-in. It's a fairly good fit for 6502, too. When I write 6502 code, all my messages are stored as C strings. Because on an Apple, something like this... putch = $FDED entry: ldy #$00 @1: lda msg, y beq @2 eor #$80 jsr putch iny bne @1 @2: rts msg: .byte "Hello, cruel world.", 13, 0 ...is pretty easy to do. -uso. From lm at mcvoy.com Mon Nov 29 07:40:34 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 28 Nov 2021 13:40:34 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Message-ID: <20211128214034.GG18441@mcvoy.com> It's been a long time but my memory is that PDP-11 instructions were way cleaner than any other system I've seen. My TA for my PDP-11 assembly class could read octal like it was C, I was never that good. He told me it was actually pretty easy once you memorized the instruction set, which he claimed was not hard because it was so uniform. I never learned it well enough to know, just did a handful of programs in assembler, but his description has stuck with me. I've had to learn enough SPARC, MIPS, and (shudder) x86, to do kernel debugging and I've never gotten the sense that they were are clean as PDP-11 was. On Mon, Nov 29, 2021 at 08:07:57AM +1100, Rob Pike wrote: > Is there a symbiosis between C and the PDP-11 instruction set? The > machine was vital to C and Unix's success, but primarily due to the > availability of a department-sized machine. Was the instruction set a > significant component? Most Unix programmers wrote little to no > assembly, although perhaps more read what came out of the compiler. > But did it matter? Auto-increment and -decrement are often cited in > this story, but they are not that important, really, and were around > well before the PDP-11 made its appearance. > > I'm curious to hear arguments on either side. > > -rob > > On Mon, Nov 29, 2021 at 7:29 AM Jon Steinhart wrote: > > > > Eugene Miya visited by last week and accidentally left his copy of the > > book here so I decided to read it before he came back to pick it up. > > > > My overall impression is that while it contained a lot of information, > > it wasn't presented in a manner that I found interesting. I don't know > > the intended target audience, but it's not me. > > > > A good part of it is that my interest is in the evolution of technology. > > I think that a more accurate title for the book would be "A New History > > of the Business of Modern Computing". The book was thorough in covering > > the number of each type of machine sold and how much money was made, but > > that's only of passing interest to me. Were it me I would have just > > summarized all that in a table and used the space to tell some engaging > > anecdotes. > > > > There were a number of things that I felt the book glossed over or missed > > completely. > > > > One is that I didn't think that they gave sufficient credit to the symbiosis > > between C and the PDP-11 instruction set and the degree to which the PDP-11 > > was enormously influential. > > > > Another is that I felt that the book didn't give computer graphics adequate > > treatment. I realize that it was primarily in the workstation market segment > > which was not as large as some of the other segments, but in my opinion the > > development of the technology was hugely important as it eventually became > > commodified and highly profitable. > > > > Probably due to my personal involvement I felt that the book missed some > > important steps along the path toward open source. In particular, it used > > the IPO of Red Hat as the seminal moment while not even mentioning the role > > of Cygnus. My opinion is that Cygnus was a huge icebreaker in the adoption > > of open source by the business world, and that the Red Hat IPO was just the > > culmination. > > > > I also didn't feel that there was any message or takeaways for readers. I > > didn't get any "based on all this I should go and do that" sort of feeling. > > > > If the purpose of the book was to present a dry history then it pretty much > > did it's job. Obviously the authors had to pick and choose what to write > > about and I would have made some different choices. But, not my book. > > > > Jon -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Mon Nov 29 07:47:23 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 28 Nov 2021 13:47:23 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Message-ID: <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Ken Thompson writes: > > The PDP-11 had very little the syntax of B expressions. > All of that was in place in B long before the PDP-11. > To be honest, the byte addressing of the 11 was a > significant hindrance. It was the genius of Dennis > that was able to conquer the 11 as he installed types > into the language. > > So, my opinion, the PDP-11 had no design on the > type system of C and moreover it was not even helpful. OK then. You *would* be the expert. From robpike at gmail.com Mon Nov 29 08:17:24 2021 From: robpike at gmail.com (Rob Pike) Date: Mon, 29 Nov 2021 09:17:24 +1100 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111282147.1ASLlND41439656@darkstar.fourwinds.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Message-ID: It's a just-so story. We have nostalgia for Unix, C, and the PDP-11 and its instruction set, and we combine them all into the story about why it all succeeded. But nostalgia can mislead. I loved the PDP-11 and its instruction set, I loved C, and I loved Unix. Memory has put causation in there that is not altogether true. The PDP-11 as an affordable commercial computer, now _that_ was important. -rob On Mon, Nov 29, 2021 at 8:50 AM Jon Steinhart wrote: > > Ken Thompson writes: > > > > The PDP-11 had very little the syntax of B expressions. > > All of that was in place in B long before the PDP-11. > > To be honest, the byte addressing of the 11 was a > > significant hindrance. It was the genius of Dennis > > that was able to conquer the 11 as he installed types > > into the language. > > > > So, my opinion, the PDP-11 had no design on the > > type system of C and moreover it was not even helpful. > > OK then. You *would* be the expert. From ron at ronnatalie.com Mon Nov 29 08:41:30 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 28 Nov 2021 17:41:30 -0500 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: Message-ID: <5394A5C7-9CE7-4F26-AB98-BFE35C13C629@ronnatalie.com> The ++ operator appears to have been. The PDP-11 had addressing modes to so predecrement and postincrement. > On Nov 28, 2021, at 16:41, Steve Nickolas wrote: > > On Sun, 28 Nov 2021, Thomas Paulsen wrote: > >> I heard that the null terminated string was a 11-build-in. > > It's a fairly good fit for 6502, too. When I write 6502 code, all my messages are stored as C strings. Because on an Apple, something like this... > > putch = $FDED > > entry: ldy #$00 > @1: lda msg, y > beq @2 > eor #$80 > jsr putch > iny > bne @1 > @2: rts > > msg: .byte "Hello, cruel world.", 13, 0 > > ...is pretty easy to do. > > -uso. From jnc at mercury.lcs.mit.edu Mon Nov 29 09:12:03 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 28 Nov 2021 18:12:03 -0500 (EST) Subject: [TUHS] A New History of Modern Computing - my thoughts Message-ID: <20211128231203.3BCB818C075@mercury.lcs.mit.edu> > The ++ operator appears to have been. One would expect that most people on this list would have read "The Development of the C Language", by Dennis Ritchie, which makes perfectly clear (at 'More History') that the PDP-11 had nothing to do with it: Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. https://www.bell-labs.com/usr/dmr/www/chist.html thereby alleviating the need for Ken to chime in (although they do allow a very efficient implementation of it). Too much to hope for, I guess. Noel From athornton at gmail.com Mon Nov 29 09:35:01 2021 From: athornton at gmail.com (Adam Thornton) Date: Sun, 28 Nov 2021 16:35:01 -0700 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <20211128231203.3BCB818C075@mercury.lcs.mit.edu> References: <20211128231203.3BCB818C075@mercury.lcs.mit.edu> Message-ID: Getting a bit far afield from Unixes, but A Quick Rundown Of Instruction Sets I Have Known, more or less in the order I learned them: 6502: you never forget your first love, and, sure, it's constrained, but it's elegant and concise and I still adore it. 68k: Lovely. I used it before I ever used the PDP-11, but in retrospect it's like the PDP-11 but more so. Roomy, comfortable, regular. Too bad it lost to x86 in the marketplace. 8051: I mean, OK, I get it, you need a low-cost embedded architecture and it's the 1980s, but...yuck. x86-and-descendents: the less said the better. Maybe I just don't like Intel's designs? SPARC: It's not bad. Having lots of registers is nice. But by the time it came along compilers were good enough that I never actually needed to use it in anger. S/360-and-descendents: The S/360 is OK, even nice, in a very 1960s IBM way. And then its evolution just KEPT adding ever more baroque filigrees onto it. Don't get me wrong, I love SIE, because I love VM, but even that is kind of a bag on the side, and by the time you get to System z...this is what happens when you don't start over from a clean sheet every so often. PDP-11: There's a very good reason it was used as a model architecture in coursework for decades. Also regular and comfortable. TI-99/4A (more or less TI 9900): I like microcode as much as anyone but honestly this is pretty silly here, folks. These days I'm kinda sorta poking at RISC-V and ARM. Not that I need to, but they seem nifty. Adam On Sun, Nov 28, 2021 at 4:15 PM Noel Chiappa wrote: > > The ++ operator appears to have been. > > One would expect that most people on this list would have read "The > Development of the C Language", by Dennis Ritchie, which makes perfectly > clear > (at 'More History') that the PDP-11 had nothing to do with it: > > Thompson went a step further by inventing the ++ and -- operators, which > increment or decrement; their prefix or postfix position determines > whether > the alteration occurs before or after noting the value of the operand. > They > were not in the earliest versions of B, but appeared along the way. > People > often guess that they were created to use the auto-increment and > auto-decrement address modes provided by the DEC PDP-11 on which C and > Unix > first became popular. This is historically impossible, since there was no > PDP-11 when B was developed. > > https://www.bell-labs.com/usr/dmr/www/chist.html > > thereby alleviating the need for Ken to chime in (although they do allow a > very efficient implementation of it). > > Too much to hope for, I guess. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Nov 29 10:19:08 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 28 Nov 2021 19:19:08 -0500 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Message-ID: Rob, I offer a small tweak to your statement, that I hope you will consider On Sun, Nov 28, 2021 at 5:20 PM Rob Pike wrote: > The PDP-11 as an affordable commercial computer, now _that_ was important. > s/computer/mini-computer/ I really believe that this distinction is important. Bell coined the term in the late 1950s/early 1960s when he called it a minicomputer. The key is that he meant >>minimal computer - in function and price<< (not small). (This would event eventual lead to Bell's law for the birth and death of computer classes). To me, the PDP-111 ISA is the epitome the *minimal computer architecture* - just want you to need to get the job done be it commercial or scientific and it was affordable as you said. The solution is elegant, nothing fancy, little extra added - just the right set of features for a system to do real work. It was also extremely regular as Larry points out, so it was not filled with a ton of special cases. It did have a few more features like addressing modes, and multiple registers that made it more complex than say an accumulator-based PDP-8. But the small set of new features made sense and were* of** use for almost all programmers*. [FWIW: IMHO, most new features we add to Intel*64 is all for some special cases for a specific customer]. I note that the VAX (was is the epitome of the CISC and while extraordinarily successful), has always been an easy target as way too complicated, filled with many special cases (just for the Fortran compiler, or for Cutler's as an assembly programmer). IMHO: C is also made from the same minimal ideal. It took the simplicity of the B and added typing and better data structures, but did not overdo it. Again, what was added was useful to almost all programmers. I note that while the follow-on to both the 11 (the Vax) and C (C++) became working horses, but both are ugly as can be, and neither would I call elegant. I've used them both, however, I have moved on since that time. I do pine for something more like a 64-bit PDP-11 (more in a minute), and still use C when I can in the kernel or Go when in userspace. Having kicked around DEC during some of the Alpha discussions, other than the original lack of byte addressing, I think the PDP-11 influenced the Alpha more than VAX did. There was a definition -- why is the needed -- thinking. Keep it simple a minimal. As for Unix (since this is a Unix history list), again I think it is the minimal view I miss from Sixth and Seventh Edition. I look at Linux and mostly turn green with how much has been lost from those days. But like the PDP-11, I can not really go back. My hope is that something will appear that is "good enough" and '"simple enough" to get people excited again. my 2 cents, Clem ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Nov 29 11:12:44 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 28 Nov 2021 17:12:44 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Message-ID: <20211129011244.GJ18441@mcvoy.com> On Sun, Nov 28, 2021 at 07:19:08PM -0500, Clem Cole wrote: > To me, the PDP-111 ISA is the epitome the *minimal computer architecture* > - just want you to need to get the job done be it commercial or scientific > and it was affordable as you said. The solution is elegant, nothing fancy, > little extra added - just the right set of features for a system to do real > work. It was also extremely regular as Larry points out, so it was not > filled with a ton of special cases. I remember Ken Witte (my TA for the PDP-11 class) trying to get me to see how easy it was to read the octal. If I remember correctly (and I probably don't, this was ~40 years ago), the instructions were divided into fields, so instruction, operand, operand and it was all regular, so you could see that this was some form of an add or whatever, it got the values from these registers and put it in that register. I remember Ken trying to get me to see how uniform it all was and I guess I sort of got it but what I remember the most is his passion for it. We were pretty friendly and if I had some big octal listing that wasn't working, he'd come over and drink a beer and read through it. For him, it was just faster to read the octal than to look at my tortured assembly. > 64 bit PDP-11 That would be pretty cool. Your comments about minimalist approaches ring really true for me. The last conversation I had with Greg Chesson was a 2 hour rant from him about the fact that nobody who is doing anything these days understands the value of a minimalist approach, it's one complex framework or whatever after another. There is a reason that the people I respect the most tend to spend a lot of time on what not to put in, rather than what to put in. I became friends with Linus Torvalds because we spent probably almost a year talking about what not to put in to LMbench, we wanted to get it right. I know people look at Linux and recoil in horror, it's a long way from v6 or v7. But v7 was a uniprocessor Unix that had no networking. Linux scales pretty well on SMPs with lots of CPUs, it has generalized NUMA support, it has a /proc that I'd argue is way more true to Unix than the SysV /proc (I don't know Ron Gomes but I was friends with Rodger Faulkner), the Linux /proc is all strings, it's so useful. Linux just handles way way way way way more than v7 could even imagine handling. Pretty much all of the supercomputers are Linux so it scales up and it scales down to a rasberry pi. A thing that blew my mind in Linux was drivers. PCI drivers. They were portable to different byte order machines. I was so used to drivers being specific to the CPU, that was eye opening. I'd say more but the wife is calling, I just wanted you to know that Linus definitely understands the minimalist approach, Linux started that way but it has been asked to do a lot so you get what you get. --lm From ggm at algebras.org Mon Nov 29 11:18:15 2021 From: ggm at algebras.org (George Michaelson) Date: Mon, 29 Nov 2021 11:18:15 +1000 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Message-ID: I suspect because we believed we understood the pdp11 we felt we'd understand a good operating system on it. If more tertiary education people had been on other hardware of the day, we'd probably have invented the same myths for that host. G On Mon, 29 Nov 2021, 10:22 am Clem Cole, wrote: > Rob, I offer a small tweak to your statement, that I hope you will consider > > On Sun, Nov 28, 2021 at 5:20 PM Rob Pike wrote: > >> The PDP-11 as an affordable commercial computer, now _that_ was important. >> > s/computer/mini-computer/ > > I really believe that this distinction is important. Bell coined the term > in the late 1950s/early 1960s when he called it a minicomputer. The key is > that he meant >>minimal computer - in function and price<< (not small). > (This would event eventual lead to Bell's law for the birth and death of > computer classes). > > To me, the PDP-111 ISA is the epitome the *minimal computer architecture* > - just want you to need to get the job done be it commercial or > scientific and it was affordable as you said. The solution is elegant, > nothing fancy, little extra added - just the right set of features for a > system to do real work. It was also extremely regular as Larry points out, > so it was not filled with a ton of special cases. It did have a few more > features like addressing modes, and multiple registers that made it more > complex than say an accumulator-based PDP-8. But the small set of new > features made sense and were* of** use for almost all programmers*. > [FWIW: IMHO, most new features we add to Intel*64 is all for some special > cases for a specific customer]. > > I note that the VAX (was is the epitome of the CISC and while > extraordinarily successful), has always been an easy target as way too > complicated, filled with many special cases (just for the Fortran > compiler, or for Cutler's as an assembly programmer). > > IMHO: C is also made from the same minimal ideal. It took the > simplicity of the B and added typing and better data structures, but did > not overdo it. Again, what was added was useful to almost all programmers. > > I note that while the follow-on to both the 11 (the Vax) and C (C++) > became working horses, but both are ugly as can be, and neither would I > call elegant. I've used them both, however, I have moved on since that > time. I do pine for something more like a 64-bit PDP-11 (more in a > minute), and still use C when I can in the kernel or Go when in userspace. > > > Having kicked around DEC during some of the Alpha discussions, other than > the original lack of byte addressing, I think the PDP-11 influenced the > Alpha more than VAX did. There was a definition -- why is the needed -- > thinking. Keep it simple a minimal. > > As for Unix (since this is a Unix history list), again I think it is the > minimal view I miss from Sixth and Seventh Edition. I look at Linux and > mostly turn green with how much has been lost from those days. But like > the PDP-11, I can not really go back. My hope is that something will > appear that is "good enough" and '"simple enough" to get people excited > again. > > my 2 cents, > Clem > ᐧ > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Nov 29 11:36:26 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 28 Nov 2021 17:36:26 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> Message-ID: <6F21364B-0B1E-407D-A3D4-74479CA9CC60@iitbombay.org> On Nov 28, 2021, at 4:19 PM, Clem Cole wrote: > > My hope is that something will appear that is "good enough" and > '"simple enough" to get people excited again My hope is for "Unix as a service". Just another service for programs that need a Unix API. I think KeyNIX (Unix on top of KeyKOS) had the right idea but the problem was and is that typically hardware is not optimized for IPC & fast context switching. That may change when we can put zillions of core on a chip but can't speed up individual cores. UAAS may even facilitate a move to a sea-of-cores architecture! From bakul at iitbombay.org Mon Nov 29 11:47:21 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 28 Nov 2021 17:47:21 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Message-ID: Was B, or rather BCPL, influenced by Algol68? It too had := as a shorthand for := op Its declaration is the same as in C. Though in A68 this was a shorthand for ref = loc > On Nov 28, 2021, at 1:31 PM, Ken Thompson wrote: > > The PDP-11 had very little the syntax of B expressions. > All of that was in place in B long before the PDP-11. > To be honest, the byte addressing of the 11 was a > significant hindrance. It was the genius of Dennis > that was able to conquer the 11 as he installed types > into the language. > > So, my opinion, the PDP-11 had no design on the > type system of C and moreover it was not even helpful. > > On Sun, Nov 28, 2021 at 1:17 PM Jon Steinhart wrote: > Rob Pike writes: > > Is there a symbiosis between C and the PDP-11 instruction set? The > > machine was vital to C and Unix's success, but primarily due to the > > availability of a department-sized machine. Was the instruction set a > > significant component? Most Unix programmers wrote little to no > > assembly, although perhaps more read what came out of the compiler. > > But did it matter? Auto-increment and -decrement are often cited in > > this story, but they are not that important, really, and were around > > well before the PDP-11 made its appearance. > > > > I'm curious to hear arguments on either side. > > > > -rob > > Well, might just be my personal experience, but most of the machines > that I had used before the 11 were classic accumulator architectures. > I feel that the 11's pointer architecture combined with autoincrement > and autodecrement was an amazing fit for C. If I remember correctly, > it was very cool to have *p++ = *q++ be a single instruction. > > BTW, one thing that I forgot in my earlier post is that I think that > the book also omitted any mention of Creative Commons. The book did > talk about the business of the web and such, and it's my opinion that > CC was an an essential third prong. The machines were one, the software > was another, the third was content and CC was a big enabler. > > Jon From cowan at ccil.org Mon Nov 29 11:53:39 2021 From: cowan at ccil.org (John Cowan) Date: Sun, 28 Nov 2021 20:53:39 -0500 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <20211128231203.3BCB818C075@mercury.lcs.mit.edu> Message-ID: On Sun, Nov 28, 2021 at 6:37 PM Adam Thornton wrote: > PDP-11: There's a very good reason it was used as a model architecture in > coursework for decades. Also regular and comfortable. > MIPS II / MIPS32 has also been used as a model architecture: it's 32-bit and supported by current gcc (as is the PDP-11). A short paper on running C programs on the JVM is at : you compiled them to MIPS R2K statically linked executables and then compiled the resulting executables to Java. The regularity of the MIPS ISA made the compiled code decently fast even before the JVM JIT. > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Nov 29 12:23:02 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 28 Nov 2021 18:23:02 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <20211129011244.GJ18441@mcvoy.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> <20211129011244.GJ18441@mcvoy.com> Message-ID: <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org> On Nov 28, 2021, at 5:12 PM, Larry McVoy wrote: > > On Sun, Nov 28, 2021 at 07:19:08PM -0500, Clem Cole wrote: > >> 64 bit PDP-11 > > That would be pretty cool. Your comments about minimalist approaches ring > really true for me. The last conversation I had with Greg Chesson was > a 2 hour rant from him about the fact that nobody who is doing anything > these days understands the value of a minimalist approach, it's one > complex framework or whatever after another. Indeed. As far as processor design is concerned, I believe one of the problems is that there are fewer and fewer people who can do both h/w and s/w design competently. This is why I think more programmers should roll up their sleeves and design a processor and understand the issues involved, especially now that programming FPGAs is becoming common. May be start with an existing RISC-V core in some HDL, and push and pull it into (what you think is) an ideal minimalist design. Even adding a codegen target for such a processor (to at least tcc or Ken's C compiler) won't be all that hard. I believe this sort of co-design is what is needed to move past the current designs. It will likely be some young whippersnapper who doesn't know what is impossible, rather than one of us greybeards! From arnold at skeeve.com Mon Nov 29 17:46:56 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 29 Nov 2021 00:46:56 -0700 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Message-ID: <202111290746.1AT7kudb001037@freefriends.org> Bakul Shah wrote: > Was B, or rather BCPL, influenced by Algol68? It too had > := > as a shorthand for > := op > Its declaration > > is the same as in C. Though in A68 this was a shorthand for > ref = loc I don't know if it was purposeful or not, but Algol 68 had the notion of deproceduring - i.e. function call, which seems to have carried over into C where the name of function is a pointer to it. You can do void myproc(); void (*functptr) = myproc; ... funcptr() to call through the pointer. (Even though the K&R book taught us to use (*funcptr)(), the syntax above worked at least as far back as PCC.) Did C pick this up from Algol 68? I have no idea, but it would not surprise me if it had. Arnold From arnold at skeeve.com Mon Nov 29 17:52:06 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 29 Nov 2021 00:52:06 -0700 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111290746.1AT7kudb001037@freefriends.org> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111290746.1AT7kudb001037@freefriends.org> Message-ID: <202111290752.1AT7q6fW001728@freefriends.org> arnold at skeeve.com wrote: > void myproc(); > void (*functptr) = myproc; > ... > funcptr() Make that void (*funcptr)() = myproc. Sorry. From michael at kjorling.se Mon Nov 29 22:11:32 2021 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 29 Nov 2021 12:11:32 +0000 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> Message-ID: <6ebf6db1-fc22-4fa5-84e7-e269badd5035@localhost> On 28 Nov 2021 17:47 -0800, from bakul at iitbombay.org (Bakul Shah): > Was B, or rather BCPL, influenced by Algol68? It too had > := > as a shorthand for > := op The already mentioned https://www.bell-labs.com/usr/dmr/www/chist.html states that "For example, B introduced generalized assignment operators, using x=+y to add y to x. The notation came from Algol 68 [Wijngaarden 75] via McIlroy, who had incorporated it into his version of TMG." -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From halbert at halwitz.org Mon Nov 29 23:48:54 2021 From: halbert at halwitz.org (Dan Halbert) Date: Mon, 29 Nov 2021 08:48:54 -0500 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: References: <20211128231203.3BCB818C075@mercury.lcs.mit.edu> Message-ID: <3b39651b-36c1-140b-e595-830807cca9cf@halwitz.org> On 11/28/21 6:35 PM, Adam Thornton wrote: > Getting a bit far afield from Unixes, but A Quick Rundown Of > Instruction Sets I Have Known, more or less in the order I learned them: > > 6502: you never forget your first love, and, sure, it's constrained, > but it's elegant and concise and I still adore it. > 68k: Lovely.  I used it before I ever used the PDP-11, but in > retrospect it's like the PDP-11 but more so.  Roomy, comfortable, > regular.  Too bad it lost to x86 in the marketplace. > 8051: I mean, OK, I get it, you need a low-cost embedded architecture > and it's the 1980s, but...yuck. > x86-and-descendents: the less said the better.  Maybe I just don't > like Intel's designs? > SPARC: It's not bad.  Having lots of registers is nice. But by the > time it came along compilers were good enough that I never actually > needed to use it in anger. > S/360-and-descendents: The S/360 is OK, even nice, in a very 1960s IBM > way.  And then its evolution just KEPT adding ever more baroque > filigrees onto it.  Don't get me wrong, I love SIE, because I love VM, > but even that is kind of a bag on the side, and by the time you get to > System z...this is what happens when you don't start over from a clean > sheet every so often. > PDP-11: There's a very good reason it was used as a model architecture > in coursework for decades.  Also regular and comfortable. > TI-99/4A (more or less TI 9900): I like microcode as much as anyone > but honestly this is pretty silly here, folks. > When I was in high school, I loved reading about instruction sets. I recommend the first five volumes of Annual Review in Automatic Programming, if you are interested. The DEC instructions sets were all quite elegant, from the minimal PDP-8 (nee PDP-5) 12-bit machine to the PDP-10 (nee 6). I maintained the BCPL compiler at BBN for a while in the 1970's, and it was a pleasure to figure out what machine code to generate. Then there was RISC vs CISC, where the VAX was a major punching bag. I was at Berkeley for RISC-I, and was a part of the small student group that did its register windows scheme. From lm at mcvoy.com Tue Nov 30 00:44:13 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Nov 2021 06:44:13 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111290752.1AT7q6fW001728@freefriends.org> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111290746.1AT7kudb001037@freefriends.org> <202111290752.1AT7q6fW001728@freefriends.org> Message-ID: <20211129144413.GM18441@mcvoy.com> On Mon, Nov 29, 2021 at 12:52:06AM -0700, arnold at skeeve.com wrote: > arnold at skeeve.com wrote: > > > void myproc(); > > void (*functptr) = myproc; > > ... > > funcptr() > > Make that > > void (*funcptr)() = myproc. > > Sorry. Function pointers are the one part of C that I have to relearn every time. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From phil at ultimate.com Tue Nov 30 01:37:59 2021 From: phil at ultimate.com (Phil Budne) Date: Mon, 29 Nov 2021 10:37:59 -0500 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> Message-ID: <202111291537.1ATFbxd1044321@ultimate.com> I had ordered a used copy of the 2nd edition of the book (came from the Cherry Hill Public Library!) before the plug for it on the list came out (because it looked like it covered/credited MIT/Lincoln and DEC systems in shaping interactive computing). I found the book a mile wide, and a millimeter deep, and while I've only randomly scanned it (mostly looking up index references), the organization by time period shatters the stories of each manufacturer into snippets, to a point that I'm hard pressed to believe that most readers would be able to stitch back together in a way that would give them a coherent idea of any particular strain of computing history. Nonetheless, I'd be happy to hear that it was assigned reading for CS students. From lm at mcvoy.com Tue Nov 30 13:18:23 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Nov 2021 19:18:23 -0800 Subject: [TUHS] A New History of Modern Computing - my thoughts In-Reply-To: <20211129011244.GJ18441@mcvoy.com> References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com> <202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com> <202111282147.1ASLlND41439656@darkstar.fourwinds.com> <20211129011244.GJ18441@mcvoy.com> Message-ID: <20211130031823.GS18441@mcvoy.com> On Sun, Nov 28, 2021 at 05:12:44PM -0800, Larry McVoy wrote: > I remember Ken Witte (my TA for the PDP-11 class) trying to get me to see > how easy it was to read the octal. If I remember correctly (and I probably > don't, this was ~40 years ago), the instructions were divided into fields, > so instruction, operand, operand and it was all regular, so you could see > that this was some form of an add or whatever, it got the values from > these registers and put it in that register. I've looked it up and it is pretty much as Ken described. The weird thing is that there is no need to do it like the PDP-11 did it, you could use random numbers for each instruction and lots of processors did pretty much that. The PDP-11 didn't, it was very uniform to the point that Ken's ability to read octal made perfect sense. I was never that good but a little google and reading and I can see how he got there. Charles Sauer contacted me off list and sent me this: https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/ Turns out that Ken was a big deal there. Not surprised at all. --lm From pbirkel at gmail.com Tue Nov 30 18:07:15 2021 From: pbirkel at gmail.com (pbirkel at gmail.com) Date: Tue, 30 Nov 2021 03:07:15 -0500 Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores Message-ID: <010901d7e5c1$4a0c7c20$de257460$@gmail.com> I believe that the PDP-11 ISA was defined at a time when DEC was still using random logic rather than a control store (which came pretty soon thereafter). Given a random logic design it's efficient to organize the ISA encoding to maximize its regularity. Probably also of some benefit to compilers in a memory-constrained environment? I'm not sure at what point in time we can say "lots of processors" had moved to a control store based implementation. Certainly the IBM System/360 was there in the mid-60's. HP was there by the late 60's. -----Original Message----- From: TUHS On Behalf Of Larry McVoy Sent: Monday, November 29, 2021 10:18 PM To: Clem Cole Cc: TUHS main list ; Eugene Miya Subject: Re: [TUHS] A New History of Modern Computing - my thoughts On Sun, Nov 28, 2021 at 05:12:44PM -0800, Larry McVoy wrote: > I remember Ken Witte (my TA for the PDP-11 class) trying to get me to > see how easy it was to read the octal. If I remember correctly (and I > probably don't, this was ~40 years ago), the instructions were divided > into fields, so instruction, operand, operand and it was all regular, > so you could see that this was some form of an add or whatever, it got > the values from these registers and put it in that register. I've looked it up and it is pretty much as Ken described. The weird thing is that there is no need to do it like the PDP-11 did it, you could use random numbers for each instruction and lots of processors did pretty much that. The PDP-11 didn't, it was very uniform to the point that Ken's ability to read octal made perfect sense. I was never that good but a little google and reading and I can see how he got there. ... --lm