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: <YYMExofM+xGRrOGq@beryllium.local>
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: <CAC20D2NPj75XS73JV5q_r3jY9ygrLut3-uKN-CYZ8dK0Gwzfvw@mail.gmail.com>
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 <tuhs at minnie.tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211106/0955a4c4/attachment.htm>
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: <CAKH6PiXtsAiCjYmO32C1LJaEAajqjZt+j4mLHxkESzdA5HFZrQ@mail.gmail.com>
> 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: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211114/99369993/attachment.htm>
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.)
<CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
References: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
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: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<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: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<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: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<20211114145541.B53742B56EE@yagi.h-net.msu.edu>
<20211114163538.9F6CD1FB32@orac.inputplus.co.uk>
Message-ID: <CAC20D2OgijuvB_Kb+Nyd564qtta5FsOewji936JPmHbgwW1kkA@mail.gmail.com>
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 <ralph at inputplus.co.uk>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211114/a9f39dbb/attachment.htm>
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: <CAC20D2OgijuvB_Kb+Nyd564qtta5FsOewji936JPmHbgwW1kkA@mail.gmail.com>
References: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<20211114145541.B53742B56EE@yagi.h-net.msu.edu>
<20211114163538.9F6CD1FB32@orac.inputplus.co.uk>
<CAC20D2OgijuvB_Kb+Nyd564qtta5FsOewji936JPmHbgwW1kkA@mail.gmail.com>
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: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<20211114145541.B53742B56EE@yagi.h-net.msu.edu>
<20211114163538.9F6CD1FB32@orac.inputplus.co.uk>
<CAC20D2OgijuvB_Kb+Nyd564qtta5FsOewji936JPmHbgwW1kkA@mail.gmail.com>
<20211114185220.B54B71FB32@orac.inputplus.co.uk>
Message-ID: <CAC20D2O1cOP8VQWUhuWgA+ZSe1zskFvFfhcvNCK60YpHLttPVA@mail.gmail.com>
That the us never from the back cover of my copy
On Sun, Nov 14, 2021 at 1:52 PM Ralph Corderoy <ralph at inputplus.co.uk>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211114/9c385ceb/attachment.htm>
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: <CAC20D2O1cOP8VQWUhuWgA+ZSe1zskFvFfhcvNCK60YpHLttPVA@mail.gmail.com>
References: <CAC20D2NTDfU=-mVrmum-4djJeQbniWzz2ct0ttst-0S9ENMMZQ@mail.gmail.com>
<20211114145541.B53742B56EE@yagi.h-net.msu.edu>
<20211114163538.9F6CD1FB32@orac.inputplus.co.uk>
<CAC20D2OgijuvB_Kb+Nyd564qtta5FsOewji936JPmHbgwW1kkA@mail.gmail.com>
<20211114185220.B54B71FB32@orac.inputplus.co.uk>
<CAC20D2O1cOP8VQWUhuWgA+ZSe1zskFvFfhcvNCK60YpHLttPVA@mail.gmail.com>
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: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/04a5a703/attachment.bin>
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: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
Message-ID: <6882B4A4-EE01-4189-B7E0-2E9BF5383272@alchemistowl.org>
On 15 Nov 2021, at 17:11, Grant Taylor via COFF <coff at minnie.tuhs.org> 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: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
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 <coff at minnie.tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/107be72a/attachment.htm>
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: <CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
Message-ID: <CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/690af66e/attachment.htm>
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: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
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: <CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
<CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
Message-ID: <CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
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 <henry.r.bent at gmail.com> wrote:
> On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/4e2c4398/attachment.htm>
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: <CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
<CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
<CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
Message-ID: <CANCZdfrRG6J8XSxMdo2HL7NTGZY8ePuks-n8y6SH6TiWciuq7Q@mail.gmail.com>
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 <clemc at ccc.com> 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 <henry.r.bent at gmail.com> wrote:
>
>> On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/0e51cf0f/attachment.htm>
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: <CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
<CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
<CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
Message-ID: <CAC20D2MGtB-Ku8ymZ5g7vC8qiO2DCXyke2hX_pT7SUuN0Kg2iA@mail.gmail.com>
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 <clemc at ccc.com> 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 <henry.r.bent at gmail.com> wrote:
>
>> On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/781aa43e/attachment.htm>
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: <CAC20D2MGtB-Ku8ymZ5g7vC8qiO2DCXyke2hX_pT7SUuN0Kg2iA@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
<CAEdTPBeNo-4vEVxxMzDTL_YYWvPb9VgMGTJBs7RaQhcDeJzeAg@mail.gmail.com>
<CAC20D2NeFBMc27-9889R=qg1JNZLpk980Cs-Yh5ZXVZKqD8PNw@mail.gmail.com>
<CAC20D2MGtB-Ku8ymZ5g7vC8qiO2DCXyke2hX_pT7SUuN0Kg2iA@mail.gmail.com>
Message-ID: <CAEdTPBf+JZ420-sRDhoU27kv1M5iOVop=7r_fnp-8wqWOPGSFw@mail.gmail.com>
On Mon, 15 Nov 2021 at 13:56, Clem Cole <clemc at ccc.com> 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 <clemc at ccc.com> 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 <henry.r.bent at gmail.com>
>> wrote:
>>
>>> On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/dadc4a81/attachment.htm>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/6781f484/attachment.htm>
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: <CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
References: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
Message-ID: <202111152017.1AFKH9Om032644@freefriends.org>
Clem Cole <clemc at ccc.com> 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: <a04c7d8c-e9e1-4714-70a3-affc570bd871@spamtrap.tnetconsulting.net>
<CAC20D2N5XpHDXVu9kEdEC8i2ex0SOrBpma6gPYzAxJRUMrwFAg@mail.gmail.com>
<202111152017.1AFKH9Om032644@freefriends.org>
Message-ID: <CAC20D2PvuBOdeRjgyGmKcbG-_QKrZauYfDte0+xtW8K3mfBHkg@mail.gmail.com>
Fair enough.
бђ§
On Mon, Nov 15, 2021 at 3:17 PM <arnold at skeeve.com> wrote:
> Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211115/393713ae/attachment.htm>
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: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
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: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/72ed3a38/attachment.sig>
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: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
Message-ID: <CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/81e6daf4/attachment.htm>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
Message-ID: <CAFH29tomxKDFn-pRBT21-X+m4ugzzn-tuGyY-Cq0hN6i5-=oeQ@mail.gmail.com>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/7ce96924/attachment.htm>
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: <CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
Message-ID: <CAFH29tq3J2=dUEufiUApMgWBAFogYfj-nWL5C2WD950xW59_4A@mail.gmail.com>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/9eeeb408/attachment.htm>
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: <CAFH29tq3J2=dUEufiUApMgWBAFogYfj-nWL5C2WD950xW59_4A@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
<CAFH29tq3J2=dUEufiUApMgWBAFogYfj-nWL5C2WD950xW59_4A@mail.gmail.com>
Message-ID: <CAP2nic0d7Kg1-i3w=6220NfBTQh7TaZ6nMsNx7NWLE+dTn5Z7w@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/279a7cb1/attachment.htm>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
Message-ID: <emc3353aa9-fabd-4bfc-8cc9-30e585ef01aa@alien>
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" <douglas.mcilroy at dartmouth.edu>
To: "TUHS main list" <tuhs at minnie.tuhs.org>
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: <CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
Message-ID: <em0d7c4379-fe76-43d6-80f5-1f5296bc74f0@alien>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/99694bd3/attachment.htm>
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: <CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
<em0d7c4379-fe76-43d6-80f5-1f5296bc74f0@alien>
<CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
Message-ID: <em7feeedaf-fffb-4065-87bb-e3abca7a199f@alien>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/1aac91bb/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
>> 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: <CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
Message-ID: <c3ff2c4c-9214-c537-6a82-941d2d22b731@gmail.com>
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
> <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 (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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/f3c85a08/attachment-0001.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
Message-ID: <em0d1304ef-31a4-4af2-a168-4ef8cfbbc4d6@alien>
Awk bailing out near line 1.
------ Original Message ------
From: "Jon Steinhart" <jon at fourwinds.com>
To: "TUHS main list" <tuhs at minnie.tuhs.org>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
Message-ID: <CAEoi9W4RvB9SDFamPwuzoi-suUr0ts9wy_NHesEhRO5BT6HhyQ@mail.gmail.com>
On Tue, Nov 16, 2021 at 12:57 PM Jon Steinhart <jon at fourwinds.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/e5e7caec/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<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: <CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
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: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
<202111161827.1AGIRU1l930653@darkstar.fourwinds.com>
Message-ID: <c281bc22-1b63-a1f1-12b3-72770fb92cf9@osta.com>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g
mail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
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: <CAKH6PiVgwhuFCY9iWeSO5RaG-oPLywAhjZ96=k79h=eoseen+g@mail.gmail.com>
> 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: <CAKH6PiXyimHaB_eER0-qBVox1C4ky5rsCTZnivHkRtp3f9v3NA@mail.gmail.com>
>>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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<20211116180426.GW10157@mcvoy.com>
Message-ID: <CAFH29tr5EO4EUvLBy=DNw_FTvwq9nPr0R4QSd6uZKkMSKNZQZA@mail.gmail.com>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/4c528888/attachment.htm>
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: <CAKH6PiVgwhuFCY9iWeSO5RaG-oPLywAhjZ96=k79h=eoseen+g@mail.gmail.com>
References: <CAKH6PiVgwhuFCY9iWeSO5RaG-oPLywAhjZ96=k79h=eoseen+g@mail.gmail.com>
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: <CAKH6PiXyimHaB_eER0-qBVox1C4ky5rsCTZnivHkRtp3f9v3NA@mail.gmail.com>
References: <CAKH6PiXyimHaB_eER0-qBVox1C4ky5rsCTZnivHkRtp3f9v3NA@mail.gmail.com>
Message-ID: <CAEoi9W6_PJiPuSjfs76SFc0KTpKAFTnx+g4ryzZwghZujk2jEQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/a4b24fb2/attachment.htm>
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: <CAFH29tr5EO4EUvLBy=DNw_FTvwq9nPr0R4QSd6uZKkMSKNZQZA@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<20211116180426.GW10157@mcvoy.com>
<CAFH29tr5EO4EUvLBy=DNw_FTvwq9nPr0R4QSd6uZKkMSKNZQZA@mail.gmail.com>
Message-ID: <CANCZdfq0GNYnzLLoCp8POk5EB_M-yjs02AbPvurykX7xu0pk2A@mail.gmail.com>
On Tue, Nov 16, 2021 at 12:55 PM Richard Salz <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/9fce2cff/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
Message-ID: <37ED5E0B-22D0-4D6F-8D92-8D71D883C68C@iitbombay.org>
On Nov 16, 2021, at 9:04 AM, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> wrote:
>
> APL is a fascinating invention, but can be so compact as to be
> inscrutable. (I confess not to have practiced APL enough to become
> fluent.) In the same vein, Haskell's powerful higher-level functions
> make middling fragments of code very clear, but can compress large
> code to opacity.
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: <c3ff2c4c-9214-c537-6a82-941d2d22b731@gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
<c3ff2c4c-9214-c537-6a82-941d2d22b731@gmail.com>
Message-ID: <CAD2gp_Q5+wzE2=t6xuS-62j=Rh_=MDoeUxHnG5540fBVAn+Znw@mail.gmail.com>
On Tue, Nov 16, 2021 at 12:06 PM Will Senn <will.senn at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/5947bc37/attachment.htm>
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: <CAD2gp_Q5+wzE2=t6xuS-62j=Rh_=MDoeUxHnG5540fBVAn+Znw@mail.gmail.com>
References: <CAKH6PiU59OwWNC3so20muvECi+2HKaX2PRAizjLjjO1J=Vwgug@mail.gmail.com>
<20211116040858.se3ygq2butxqopcx@localhost.localdomain>
<CAC20D2Phn_VahO7A2MCEHgMRV7isVo9W3s6wqdvw6Q=0koE9jg@mail.gmail.com>
<c3ff2c4c-9214-c537-6a82-941d2d22b731@gmail.com>
<CAD2gp_Q5+wzE2=t6xuS-62j=Rh_=MDoeUxHnG5540fBVAn+Znw@mail.gmail.com>
Message-ID: <b5815116-464d-b8d9-7a3a-b15861a0528d@gmail.com>
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
> <https://en.wikipedia.org/wiki/List_of_BASIC_dialects>.
>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211116/9e527c99/attachment.htm>
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: <CAEoi9W6_PJiPuSjfs76SFc0KTpKAFTnx+g4ryzZwghZujk2jEQ@mail.gmail.com>
References: <CAKH6PiXyimHaB_eER0-qBVox1C4ky5rsCTZnivHkRtp3f9v3NA@mail.gmail.com>
<CAEoi9W6_PJiPuSjfs76SFc0KTpKAFTnx+g4ryzZwghZujk2jEQ@mail.gmail.com>
Message-ID: <CAKH6PiVO1V+3KKH35hAi93dDmL-Mrh63kBRSg_yKt38wDxgS1w@mail.gmail.com>
>> 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 <crossd at gmail.com> wrote:
>
> 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.
>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211117/f6ba9c89/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
Message-ID: <CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211117/d0f767bf/attachment.htm>
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: <CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
Message-ID: <CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
>
> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211117/8e56194b/attachment.htm>
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: <CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
Message-ID: <CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
>
>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211117/8a331bfe/attachment.htm>
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: <CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
Message-ID: <CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
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 <crossd at gmail.com> wrote:
> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
>>
>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211118/7bac081a/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<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 <norman at oclsc.org> 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 '\<foo\>' /dev/null | \
xargs grep -l '\<bar\>' /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: <CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
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 <crossd at gmail.com> wrote:
>
> > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
> >
> >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
> >>
> >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<47CE7A59-B66D-4814-A91A-20A95B15C8FC@iitbombay.org>
Message-ID: <CAGGBd_o1TatVnpqGD_V=+mZPbn8Dpm2nyTz1daOt2dCARqc4TQ@mail.gmail.com>
On Wed, Nov 17, 2021 at 2:40 PM Bakul Shah <bakul at iitbombay.org> 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 '\<foo\>' /dev/null | \
> xargs grep -l '\<bar\>' /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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211117/06f7575e/attachment.htm>
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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
References: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
Message-ID: <202111181903.1AIJ3xqk032412@freefriends.org>
Paul Ruizendaal via TUHS <tuhs at minnie.tuhs.org> 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: <CAKH6PiWZCVZaA6v0YYuWA5mYqKV3TY4kDWR+1aSGAFgPnHky_g@mail.gmail.com>
References: <202110132053.19DKr7pF030263@ultimate.com>
<7wy26vpqeq.fsf@junk.nocrew.org>
<CAKH6PiWZCVZaA6v0YYuWA5mYqKV3TY4kDWR+1aSGAFgPnHky_g@mail.gmail.com>
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 <lars at nocrew.org>
> 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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
<202111181903.1AIJ3xqk032412@freefriends.org>
<7f730812-e0c1-ea96-a253-bf16b25e789d@case.edu>
Message-ID: <202111181920.1AIJKIwd002688@freefriends.org>
Chet Ramey <chet.ramey at case.edu> 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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
<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: <CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
Message-ID: <CAKr6gn19n0hWPcYF9+nBAW1GG5o528ZaPtNWj6tC6QVpxXUnVg@mail.gmail.com>
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, <robpike at gmail.com> 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 <crossd at gmail.com> wrote:
>
>> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
>>>
>>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org>
>>>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/e3ccdce0/attachment.htm>
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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
<202111181903.1AIJ3xqk032412@freefriends.org>
Message-ID: <CAD2gp_TUx97gyP-Fe4dyN--WUWRb+zKBpWxuDWkCq7BHg-ApyQ@mail.gmail.com>
On Thu, Nov 18, 2021 at 2:06 PM <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211118/53bda1a6/attachment.htm>
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: <CAKr6gn19n0hWPcYF9+nBAW1GG5o528ZaPtNWj6tC6QVpxXUnVg@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<CAKr6gn19n0hWPcYF9+nBAW1GG5o528ZaPtNWj6tC6QVpxXUnVg@mail.gmail.com>
Message-ID: <CAKzdPgx6P0heQLhaKY8FWdmn9HKHPLFZ3JXxfsys_Ca6pVWTtA@mail.gmail.com>
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 <ggm at algebras.org> 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, <robpike at gmail.com> 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 <crossd at gmail.com> wrote:
>>>
>>> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
>>>>
>>>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com> wrote:
>>>>>
>>>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org> 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: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
References: <EF7D8E6A-905F-4EAD-A72E-4CC25E16C5AB@planet.nl>
Message-ID: <FB3742CE-EA42-42C3-91BC-0A158FAB632D@cfcl.com>
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
> <youtube.com/watch?v=NTfOnGZUZDk>
>
> [2]VCF East 2019 -- Brian Kernighan interviews Ken Thompson
> <https://www.youtube.com/watch?v=EY6q5dv_B-o>
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: <CMM.0.95.0.1637276350.beebe@gamma.math.utah.edu>
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: <CAKH6PiVVTT0s8ua3pto2iMSrgO4-S0r9mu9rt6iLUq4DLXr_Dw@mail.gmail.com>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<20211118003512.GN15051@mcvoy.com>
Message-ID: <CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.com>
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 <lm at mcvoy.com> 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 <crossd at gmail.com> wrote:
> >
> > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
> > >
> > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com>
> wrote:
> > >>
> > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/49ec2b80/attachment.htm>
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: <CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.com>
References: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<20211118003512.GN15051@mcvoy.com>
<CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.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 <lm at mcvoy.com> 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 <crossd at gmail.com> wrote:
> > >
> > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
> > > >
> > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com>
> > wrote:
> > > >>
> > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org>
> > 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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<20211118003512.GN15051@mcvoy.com>
<CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.com>
<20211119201447.GF15051@mcvoy.com>
Message-ID: <CALpTLGpsWL_YD2sJZRXcyRSmhdg6X+SG0cafN29T8Xv7BeAHNw@mail.gmail.com>
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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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 <crossd at gmail.com> wrote:
> > > >
> > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com>
> wrote:
> > > > >
> > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com>
> > > wrote:
> > > > >>
> > > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org
> >
> > > 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/a151b5ff/attachment.htm>
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: <CALpTLGpsWL_YD2sJZRXcyRSmhdg6X+SG0cafN29T8Xv7BeAHNw@mail.gmail.com>
References: <202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<20211118003512.GN15051@mcvoy.com>
<CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.com>
<20211119201447.GF15051@mcvoy.com>
<CALpTLGpsWL_YD2sJZRXcyRSmhdg6X+SG0cafN29T8Xv7BeAHNw@mail.gmail.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 <pathname> <revision>
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: <CALpTLGqkTgJ6DUHZKfuwg-gNN=FbnC8FA8Dmz3u5PXLsc5jAPA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/a26bff14/attachment.htm>
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: <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.gmail.com>
<202111161754.1AGHsGsN929905@darkstar.fourwinds.com>
<50F3E958-F0A4-4895-B1BC-41A2644A074A@oclsc.org>
<CAGGBd_rRtKF33gUqEvSAc2nD2rpvyYpNY6MfWCnJtEPd2nWbJA@mail.gmail.com>
<CANCZdfp65G_MZRiAQ3pBVW5UCBjhoDk-wu8CLNnX7j4V-9B16g@mail.gmail.com>
<CAEoi9W7EerqquxroDqzaDPeZ03UEcKtC3bXPvyYtUy_8t-pXxQ@mail.gmail.com>
<CAKzdPgyY1eW8O=ky5_88kP7Z0EKC1E2TjDyi4tKkzG0hfooSHw@mail.gmail.com>
<20211118003512.GN15051@mcvoy.com>
Message-ID: <CALpTLGornWBJNfmPdr0FS6ze5QH5ijJFn9_1PxWqQuoPmwtxVg@mail.gmail.com>
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 <lm at mcvoy.com> 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 <crossd at gmail.com> wrote:
> >
> > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp at bsdimp.com> wrote:
> > >
> > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists at gmail.com>
> wrote:
> > >>
> > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman at oclsc.org>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/af875a5f/attachment.htm>
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: <CALpTLGqkTgJ6DUHZKfuwg-gNN=FbnC8FA8Dmz3u5PXLsc5jAPA@mail.gmail.com>
References: <CALpTLGqkTgJ6DUHZKfuwg-gNN=FbnC8FA8Dmz3u5PXLsc5jAPA@mail.gmail.com>
Message-ID: <CAKzdPgxrTs4V0PG9Xae5WmH=_Pp2B45YU9mtWMO49mADmCBgcQ@mail.gmail.com>
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 <alanglasser at gmail.com> 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: <CAKzdPgxrTs4V0PG9Xae5WmH=_Pp2B45YU9mtWMO49mADmCBgcQ@mail.gmail.com>
References: <CALpTLGqkTgJ6DUHZKfuwg-gNN=FbnC8FA8Dmz3u5PXLsc5jAPA@mail.gmail.com>
<CAKzdPgxrTs4V0PG9Xae5WmH=_Pp2B45YU9mtWMO49mADmCBgcQ@mail.gmail.com>
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: <EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
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 <jon at fourwinds.com> 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: <EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com>
<EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
Message-ID: <YZhiCpytvCeUX+/2@mit.edu>
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: <EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com>
<EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
Message-ID: <CAD2gp_Q9RTGUsZ9d4zOaJL7qbk5SFHUYYctUCvUqLLQp8e2Mdw@mail.gmail.com>
On Fri, Nov 19, 2021 at 9:11 PM Alan Glasser <alanglasser at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211119/0994a270/attachment.htm>
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: <EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.com>
References: <202111200130.1AK1UIj51103141@darkstar.fourwinds.com>
<EC840092-F195-4C3D-886B-1370D80BAFC5@gmail.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: <CAKH6PiUnxgGAQHEY=LZKUcsGEi1Vyj9VFAvOjr2auoRiza1HHg@mail.gmail.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".
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: <CAKzdPgxrTs4V0PG9Xae5WmH=_Pp2B45YU9mtWMO49mADmCBgcQ@mail.gmail.com>
References: <CALpTLGqkTgJ6DUHZKfuwg-gNN=FbnC8FA8Dmz3u5PXLsc5jAPA@mail.gmail.com>
<CAKzdPgxrTs4V0PG9Xae5WmH=_Pp2B45YU9mtWMO49mADmCBgcQ@mail.gmail.com>
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 <alanglasser at gmail.com> 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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
Message-ID: <b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
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: <b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
Message-ID: <CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211123/5bbb8682/attachment.htm>
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: <CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
Message-ID: <202111230810.1AN8Ag1c012469@freefriends.org>
Henry Bent <henry.r.bent at gmail.com> wrote:
> On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah at mhorton.net> 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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
<202111230810.1AN8Ag1c012469@freefriends.org>
Message-ID: <CAEdTPBf7JCOyHuqsy1xA7Fei1jLE+Mb11wETbFmsXdDYeXZ35g@mail.gmail.com>
On Tue, 23 Nov 2021 at 03:10, <arnold at skeeve.com> wrote:
> Henry Bent <henry.r.bent at gmail.com> wrote:
>
> > On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211123/4668976a/attachment.htm>
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: <CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<CAEdTPBdVnPQMaDX0jOL81EkL1M7Eg=U4qWPwKMsr6SBc2Zz9vw@mail.gmail.com>
Message-ID: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211123/d5ab0c27/attachment.htm>
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: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
References: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
Message-ID: <A6E163AD-5203-44FF-A4FD-30238D401430@ronnatalie.com>
> On Nov 23, 2021, at 12:31, Adam Thornton <athornton at gmail.com> wrote:
>
> п»ї
>
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211123/002c3be9/attachment.htm>
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: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
References: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
Message-ID: <EFB284D1-B363-4B17-91A2-4B5B471B702F@ronnatalie.com>
Tpl
> On Nov 23, 2021, at 12:31, Adam Thornton <athornton at gmail.com> wrote:
>
> п»ї
>
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211123/6ddd2b05/attachment.htm>
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: <A6E163AD-5203-44FF-A4FD-30238D401430@ronnatalie.com>
References: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
<A6E163AD-5203-44FF-A4FD-30238D401430@ronnatalie.com>
Message-ID: <eafb56b8-67ab-6471-9648-e91ab6ee3aa1@bitsavers.org>
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: <eafb56b8-67ab-6471-9648-e91ab6ee3aa1@bitsavers.org>
References: <CAP2nic03_jegGP2sJh+53ofemnj+p8d5a48hEtumaeCvuPs=nw@mail.gmail.com>
<A6E163AD-5203-44FF-A4FD-30238D401430@ronnatalie.com>
<eafb56b8-67ab-6471-9648-e91ab6ee3aa1@bitsavers.org>
Message-ID: <F304EA0F-DBF7-47C7-B500-B244937282CC@serissa.com>
> On 2021, Nov 23, at 2:04 PM, Al Kossow <aek at bitsavers.org> 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: <b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
Message-ID: <d5c635f412e50be3740bf13c2380d799@firemail.de>
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: <d5c635f412e50be3740bf13c2380d799@firemail.de>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
Message-ID: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/e624024d/attachment.htm>
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: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
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: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com>
<20211124184040.GS3889@mcvoy.com>
Message-ID: <CAC20D2OVvp2XcJ-uH32uSBRDEDi=wzWfiB9T-=c1dHG3XOWJ8w@mail.gmail.com>
On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/42e90003/attachment.htm>
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: <FC821474-FF4A-4525-8076-C1567A9A7275@ronnatalie.com>
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 <clemc at ccc.com> wrote:
>
> п»ї
>
>
>> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/e0bd5ee6/attachment.htm>
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: <CAC20D2OVvp2XcJ-uH32uSBRDEDi=wzWfiB9T-=c1dHG3XOWJ8w@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com>
<20211124184040.GS3889@mcvoy.com>
<CAC20D2OVvp2XcJ-uH32uSBRDEDi=wzWfiB9T-=c1dHG3XOWJ8w@mail.gmail.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 <lm at mcvoy.com> 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: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
Message-ID: <202111242013.1AOKDYNd007770@freefriends.org>
Richard Salz <rich.salz at gmail.com> 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: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
Message-ID: <CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<202111242013.1AOKDYNd007770@freefriends.org>
Message-ID: <a6b73bda-721b-320c-92de-177b403c0034@gmail.com>
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 <rich.salz at gmail.com> 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: <CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
Message-ID: <CAKzdPgwdE_F2XiMGP5BaKEEG+LFJ-ucWw+wJDGAtcJDR0xd_9Q@mail.gmail.com>
Also isn't it PROCEDURE? I don't remember PROC.
-rob
On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike at gmail.com> 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 <rich.salz at gmail.com> 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: <CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
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 <robpike at gmail.com> 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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/cebc7d37/attachment.htm>
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: <CAKzdPgwdE_F2XiMGP5BaKEEG+LFJ-ucWw+wJDGAtcJDR0xd_9Q@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CAKzdPgw7etwK-6ekJV3JyxRGJXmztncsb4QR_UsFCWkKaRN0PA@mail.gmail.com>
<CAKzdPgwdE_F2XiMGP5BaKEEG+LFJ-ucWw+wJDGAtcJDR0xd_9Q@mail.gmail.com>
Message-ID: <CAFH29tr01LABQgjSxzymdfBenAXt4oZjrAv_N3PHSHQ9+VbzYA@mail.gmail.com>
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 <robpike at gmail.com> wrote:
> Also isn't it PROCEDURE? I don't remember PROC.
>
> -rob
>
> On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike at gmail.com> 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 <rich.salz at gmail.com>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/b062fd10/attachment.htm>
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: <CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
Message-ID: <CANV78LQzT4MKm9ECosd62ckNDVzn0wZHbf6hDp4L=gKe3mz=Lg@mail.gmail.com>
On Wed, Nov 24, 2021 at 7:23 AM Richard Salz <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/f117e032/attachment.htm>
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: <CANV78LQzT4MKm9ECosd62ckNDVzn0wZHbf6hDp4L=gKe3mz=Lg@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CANV78LQzT4MKm9ECosd62ckNDVzn0wZHbf6hDp4L=gKe3mz=Lg@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/1827096d/attachment.htm>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CANV78LQzT4MKm9ECosd62ckNDVzn0wZHbf6hDp4L=gKe3mz=Lg@mail.gmail.com>
<94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com>
Message-ID: <CAKzdPgx0XLdKUv-JkAYSiR39UQLHgK6X3psru=6=LBOXYnVN5Q@mail.gmail.com>
Far too many semicolons, no keywords, and adjustable integer sizes.
-rob
On Thu, Nov 25, 2021 at 9:31 AM Will Senn <will.senn at gmail.com> 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 <rich.salz at gmail.com> 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: <CAKzdPgx0XLdKUv-JkAYSiR39UQLHgK6X3psru=6=LBOXYnVN5Q@mail.gmail.com>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<CANV78LQzT4MKm9ECosd62ckNDVzn0wZHbf6hDp4L=gKe3mz=Lg@mail.gmail.com>
<94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com>
<CAKzdPgx0XLdKUv-JkAYSiR39UQLHgK6X3psru=6=LBOXYnVN5Q@mail.gmail.com>
Message-ID: <CAFH29to7z+umL6cZ9DCkAspNBdu__4OCSyZeqkTZHwZEm0ihjA@mail.gmail.com>
On Wed, Nov 24, 2021 at 6:03 PM Rob Pike <robpike at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211124/69312d18/attachment.htm>
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: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
> 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: <CMM.0.95.0.1637804897.beebe@gamma.math.utah.edu>
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: <CMM.0.95.0.1637804897.beebe@gamma.math.utah.edu>
References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com>
<CMM.0.95.0.1637804897.beebe@gamma.math.utah.edu>
Message-ID: <CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<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 <rich.salz at gmail.com> 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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com>
<20211124184040.GS3889@mcvoy.com>
Message-ID: <m28rxcwmyh.fsf@thuvia.hamartun.priv.no>
Larry McVoy <lm at mcvoy.com> 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: <m28rxcwmyh.fsf@thuvia.hamartun.priv.no>
References: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com>
<20211124184040.GS3889@mcvoy.com>
<m28rxcwmyh.fsf@thuvia.hamartun.priv.no>
Message-ID: <CAD0_1cmCU1F3spmyW__JaVn=KyGTykPwdQiZUA9L76sxAZFevQ@mail.gmail.com>
On Thu, 25 Nov 2021, 18:35 Tom Ivar Helbekkmo via TUHS, <
tuhs at minnie.tuhs.org> wrote:
> Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211125/296bffa7/attachment.htm>
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: <CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
References: <94b9315e-86f3-a294-9770-e1768fd1380c@gmail.com>
<CMM.0.95.0.1637804897.beebe@gamma.math.utah.edu>
<CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
Message-ID: <CAC20D2NAXRLVMck3wc-MjxS-U8-t4i+oC5EXPgQgYgEX=tsJuw@mail.gmail.com>
On Wed, Nov 24, 2021 at 9:06 PM George Michaelson <ggm at algebras.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211125/116ec931/attachment.htm>
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: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
Message-ID: <CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
On 11/24/21, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> 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: <CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2111251312050.16592@sd-119843.dedibox.fr>
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: <CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
Message-ID: <CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
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: <CAKH6PiXtVetBZbyvOiWZFSTvNebSTEuaYkOoUx4KPg4wtdvN8g@mail.gmail.com>
<b355e6b8-720d-3078-d54a-2beb5ff79bd4@mhorton.net>
<d5c635f412e50be3740bf13c2380d799@firemail.de>
<CAFH29tp9Rsrh=YBak1sBv8=BzJobeLyCeN2x3Jio76UGvCRP+A@mail.gmail.com>
<530A0404-0542-404F-9E77-484AA2E678C5@cfcl.com>
<20211124184040.GS3889@mcvoy.com>
<CAC20D2OVvp2XcJ-uH32uSBRDEDi=wzWfiB9T-=c1dHG3XOWJ8w@mail.gmail.com>
<20211124200225.GV3889@mcvoy.com>
Message-ID: <m1mqhE4-0036wTC@more.local>
At Wed, 24 Nov 2021 12:02:25 -0800, Larry McVoy <lm at mcvoy.com> 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 <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211126/0d3bd069/attachment.sig>
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: <CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
(Paul Winalski's message of "Fri, 26 Nov 2021 11:59:35 -0500")
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
<CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
Message-ID: <m2sfviirs3.fsf@thuvia.hamartun.priv.no>
Paul Winalski <paul.winalski at gmail.com> 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: <m2sfviirs3.fsf@thuvia.hamartun.priv.no>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
<CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
<m2sfviirs3.fsf@thuvia.hamartun.priv.no>
Message-ID: <CAD2gp_SY+h88i=zduugJCMS1Bpc7UO6jAUQur9mqTqzg0p-WuQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211126/70794b5c/attachment.htm>
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: <CAC20D2NAXRLVMck3wc-MjxS-U8-t4i+oC5EXPgQgYgEX=tsJuw@mail.gmail.com>
References: <CAC20D2NAXRLVMck3wc-MjxS-U8-t4i+oC5EXPgQgYgEX=tsJuw@mail.gmail.com>
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 <clemc at ccc.com> wrote:
>
> п»ї
>
>
>> On Wed, Nov 24, 2021 at 9:06 PM George Michaelson <ggm at algebras.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211126/502ae5cd/attachment.htm>
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: <CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
References: <CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
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 <ggm at algebras.org> 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: <CAD2gp_SY+h88i=zduugJCMS1Bpc7UO6jAUQur9mqTqzg0p-WuQ@mail.gmail.com>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
<CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
<m2sfviirs3.fsf@thuvia.hamartun.priv.no>
<CAD2gp_SY+h88i=zduugJCMS1Bpc7UO6jAUQur9mqTqzg0p-WuQ@mail.gmail.com>
Message-ID: <CAKr6gn2GeJEwcZYLeU6NERrL26D8SbbF4Xie8=20q0QKHL6ZZA@mail.gmail.com>
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, <cowan at ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211127/e1ef963c/attachment.htm>
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>
<CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.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>
<CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.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>
<CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.gmail.com>
<20211127002307.C6E3A2B6CEC@yagi.h-net.msu.edu>
<20211127003006.GK19525@mcvoy.com>
Message-ID: <CANCZdfo1xDhHXnNQ4KeACZBh7LL+ecPfqq=kwEQ6GkoGz1pHvQ@mail.gmail.com>
On Fri, Nov 26, 2021, 5:32 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211126/4c61d1b8/attachment.htm>
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>
<CAKr6gn274v1cYZV=R3kStLaTq8L5ipFGT5hmgDaEvfs_o3pwtQ@mail.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 <sauer at technologists.com> 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 <sauer at technologists.com>
> 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 <sauer at technologists.com>
>
> > 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: <CABH=_VQxKZ3k=kS906sWRg0iRnimaymwG21+46a8TTWH8kx6NQ@mail.gmail.com>
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: <a8ab38fc-e737-85c0-5962-7ce45276aedf@technologists.com>
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: <a8ab38fc-e737-85c0-5962-7ce45276aedf@technologists.com>
References: <20211127152527.591D518C07B@mercury.lcs.mit.edu>
<1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com>
<a8ab38fc-e737-85c0-5962-7ce45276aedf@technologists.com>
Message-ID: <alpine.DEB.2.21.2111271107080.26556@sd-119843.dedibox.fr>
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: <CAKr6gn2GeJEwcZYLeU6NERrL26D8SbbF4Xie8=20q0QKHL6ZZA@mail.gmail.com>
References: <CAKH6PiWUcRErWURZofEOwvnPTJDzwcVeEf41mu4HEe6x9j0qSg@mail.gmail.com>
<CABH=_VQL1+WnaR4Dn44o_vOvKLrVonx0POU6g5CG-fVckp6Znw@mail.gmail.com>
<CABH=_VQpRTMz+=7dFbZFD16qt6h_p54xU93Km77F54QdCR76Bg@mail.gmail.com>
<m2sfviirs3.fsf@thuvia.hamartun.priv.no>
<CAD2gp_SY+h88i=zduugJCMS1Bpc7UO6jAUQur9mqTqzg0p-WuQ@mail.gmail.com>
<CAKr6gn2GeJEwcZYLeU6NERrL26D8SbbF4Xie8=20q0QKHL6ZZA@mail.gmail.com>
Message-ID: <CABH=_VTdNeipR3JRebbk1qNWGLe0GqT9c0Z0+YFS_juPGN7pzw@mail.gmail.com>
On 11/26/21, George Michaelson <ggm at algebras.org> 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: <b8fab452-0603-7462-d98c-7c39a8e984c8@bitsavers.org>
References: <20211127152527.591D518C07B@mercury.lcs.mit.edu>
<1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com>
<a8ab38fc-e737-85c0-5962-7ce45276aedf@technologists.com>
<alpine.DEB.2.21.2111271107080.26556@sd-119843.dedibox.fr>
<b8fab452-0603-7462-d98c-7c39a8e984c8@bitsavers.org>
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: <alpine.DEB.2.21.2111271107080.26556@sd-119843.dedibox.fr>
References: <20211127152527.591D518C07B@mercury.lcs.mit.edu>
<1ae0c3f8-fc2b-84a9-442b-e591dca591fd@technologists.com>
<a8ab38fc-e737-85c0-5962-7ce45276aedf@technologists.com>
<alpine.DEB.2.21.2111271107080.26556@sd-119843.dedibox.fr>
Message-ID: <b8fab452-0603-7462-d98c-7c39a8e984c8@bitsavers.org>
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: <CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
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 <jon at fourwinds.com> 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: <CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.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: <CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.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 <jon at fourwinds.com> 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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
Message-ID: <CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
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 <jon at fourwinds.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211128/2a2de732/attachment.htm>
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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<811d4e0a0c4cd210261b84df286ff53a@firemail.de>
Message-ID: <alpine.DEB.2.21.2111281635020.2433@sd-119843.dedibox.fr>
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: <CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.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 <jon at fourwinds.com> 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: <CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
Message-ID: <CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
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 <jon at fourwinds.com> 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: <alpine.DEB.2.21.2111281635020.2433@sd-119843.dedibox.fr>
References: <alpine.DEB.2.21.2111281635020.2433@sd-119843.dedibox.fr>
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 <usotsuki at buric.co> 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: <CAP2nic2LEg=CQG8JEvtcA1zvgJxbRPak999G4e6QWk-Aao-ksw@mail.gmail.com>
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 <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211128/44167fd7/attachment.htm>
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: <CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
Message-ID: <CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
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 <robpike at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211128/c3a29920/attachment.htm>
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: <CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
<CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.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: <CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
<CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
Message-ID: <CAKr6gn0_h43LoNx7MK0w13cT+Ak=V6dK1FcpUw=eC=vn0dBALg@mail.gmail.com>
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, <clemc at ccc.com> 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 <robpike at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211129/f1e107f5/attachment.htm>
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: <CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
<CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
Message-ID: <6F21364B-0B1E-407D-A3D4-74479CA9CC60@iitbombay.org>
On Nov 28, 2021, at 4:19 PM, Clem Cole <clemc at ccc.com> 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: <CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
Message-ID: <E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
Was B, or rather BCPL, influenced by Algol68? It too had
<var> <op>:= <value>
as a shorthand for
<var> := <var> op <value>
Its declaration
<type> <name>
is the same as in C. Though in A68 this was a shorthand for
ref <type> <name> = loc <type>
> On Nov 28, 2021, at 1:31 PM, Ken Thompson <kenbob at gmail.com> 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 <jon at fourwinds.com> 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: <CAP2nic2LEg=CQG8JEvtcA1zvgJxbRPak999G4e6QWk-Aao-ksw@mail.gmail.com>
References: <20211128231203.3BCB818C075@mercury.lcs.mit.edu>
<CAP2nic2LEg=CQG8JEvtcA1zvgJxbRPak999G4e6QWk-Aao-ksw@mail.gmail.com>
Message-ID: <CAD2gp_QR0WnLnkkj3auuPchsZJg73_CEJcA27aPJzYpBUsummQ@mail.gmail.com>
On Sun, Nov 28, 2021 at 6:37 PM Adam Thornton <athornton at gmail.com> 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 <http://www.xwt.org/mips2java/>: 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211128/a624c11d/attachment.htm>
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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
<CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.com>
<20211129011244.GJ18441@mcvoy.com>
Message-ID: <702642B0-311F-4464-B0EB-44166731EAFC@iitbombay.org>
On Nov 28, 2021, at 5:12 PM, Larry McVoy <lm at mcvoy.com> 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: <E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
Message-ID: <202111290746.1AT7kudb001037@freefriends.org>
Bakul Shah <bakul at iitbombay.org> wrote:
> Was B, or rather BCPL, influenced by Algol68? It too had
> <var> <op>:= <value>
> as a shorthand for
> <var> := <var> op <value>
> Its declaration
> <type> <name>
> is the same as in C. Though in A68 this was a shorthand for
> ref <type> <name> = loc <type>
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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
<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: <E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
References: <202111282026.1ASKQ5X41437843@darkstar.fourwinds.com>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
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
> <var> <op>:= <value>
> as a shorthand for
> <var> := <var> op <value>
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: <CAP2nic2LEg=CQG8JEvtcA1zvgJxbRPak999G4e6QWk-Aao-ksw@mail.gmail.com>
References: <20211128231203.3BCB818C075@mercury.lcs.mit.edu>
<CAP2nic2LEg=CQG8JEvtcA1zvgJxbRPak999G4e6QWk-Aao-ksw@mail.gmail.com>
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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<E4D6B279-07DD-40B5-84C4-432D1E75CABD@iitbombay.org>
<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>
<CAKzdPgwC1yzXWw8E2YvRY4+OnpitD5ijNX9HsBQYLCuhrY3MPA@mail.gmail.com>
<202111282115.1ASLFK1Q1438854@darkstar.fourwinds.com>
<CAMP=X_kFzqPaZPHo9S-BrAgLuwKa9gvJpS1XavVc59XmAqGRUg@mail.gmail.com>
<202111282147.1ASLlND41439656@darkstar.fourwinds.com>
<CAKzdPgxBsFeKRvCktiQvoDOHOMW5M1QuH70VeZBL8cJN9XKNCA@mail.gmail.com>
<CAC20D2P0PPeJMvg9LHERw-kxPFWr_4QTPHCJg1_wTyz=-0-tdw@mail.gmail.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 <tuhs-bounces at minnie.tuhs.org> On Behalf Of Larry McVoy
Sent: Monday, November 29, 2021 10:18 PM
To: Clem Cole <clemc at ccc.com>
Cc: TUHS main list <tuhs at minnie.tuhs.org>; Eugene Miya <eugene at soe.ucsc.edu>
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