From lyndon at orthanc.ca  Mon Oct  1 06:57:55 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 30 Sep 2018 13:57:55 -0700
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
Message-ID: <7aa1b665a2b5ef23@orthanc.ca>

John P. Linderman writes:

> We always referred to HP-UX as "H-Pukes".

For us canucks, it has always been called "hockey pucks" :-)


From lyndon at orthanc.ca  Mon Oct  1 07:32:05 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 30 Sep 2018 14:32:05 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903185616.ZnkRk%ca6c@bitmessage.ch>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
Message-ID: <7aa1b69655bc35bb@orthanc.ca>

> > "Unavailable on the console" is kind of a cheap shot when talking about
> > an operating system that deliberately doesn't support consoles.  Part of
> > the point was outgrowing TTYs.
>
> Yeah, I guess I should've started with that :) I love Unix for the
> console.

But in Plan9, the console is assumed to be a bitmap device.  Perhaps
with the exception of, say, the file server.  But there is no reason
why that has to be the case - certainly not on modern "file server"
hardware.  It's just an artifact of how cpurc is set up.  It's
trivially changable, should you desire to.

--lyndon


From lyndon at orthanc.ca  Mon Oct  1 07:56:02 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 30 Sep 2018 14:56:02 -0700
Subject: [TUHS] plan9 first edition
In-Reply-To: <2BEA2847-0FFE-4835-A59C-098E62DB5C0F@planet.nl>
References: <2BEA2847-0FFE-4835-A59C-098E62DB5C0F@planet.nl>
Message-ID: <7aa1b6a687c027f5@orthanc.ca>

Paul Ruizendaal writes:

> I'm looking for source code of Plan9's first edition. A
> quick search on Google came up dry.

> Would that source be publicly available?

It's not.  I asked Geoff about this when he resurrecected a
copy of the v2 sources for me.  There was no "v1 release" as
such, just adhoc distributions to a few sites.

--lyndon


From lyndon at orthanc.ca  Mon Oct  1 11:52:44 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 30 Sep 2018 18:52:44 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <20180928005001.GA2320@thunk.org>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
 <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
 <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
 <20180928005001.GA2320@thunk.org>
Message-ID: <7aa1b7ca02a5d7fa@orthanc.ca>

Surely /home come out of the automounter convention to point
/home/<foo> at whichever /export/<host>/<filesystem>/<homedir>
directory YP said was the logged in users home directory?  This all
originates from the days of diskless/dataless Sun workstations.

--lyndon


From steve at quintile.net  Mon Oct  1 19:35:08 2018
From: steve at quintile.net (Steve Simon)
Date: Mon, 1 Oct 2018 10:35:08 +0100
Subject: [TUHS] plan9 first edition
In-Reply-To: <mailman.1.1538359202.15039.tuhs@minnie.tuhs.org>
Message-ID: <b99f97eb854186082177b02ff4f38bad@quintile.net>

I can only speak from my experience, but I think there was a more or less
official 1st Ed release. in 1993 I was working as a system manager
at UNSW I requested and receicved a Plan9 CDROM with about 5 inches of
printed manual (but unbound) manual from the labs.

Here is some bits and pieces about the Ed1 I scraped together some years ago,
including the artwork for the CD :-)

https://plan9.io/sources/contrib/steve/historic/1st-edition/

I also believe that the CD contained some music in RedBook form
(sadly I never got around to putting the disk in an audio cd drive).
If I am right, then this has been reissued.

https://bauhaus.bandcamp.com/

Everyone sing along now, Undead undead, undead...

-Steve


From paul.winalski at gmail.com  Tue Oct  2 02:26:51 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 1 Oct 2018 12:26:51 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <7aa1b665a2b5ef23@orthanc.ca>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <7aa1b665a2b5ef23@orthanc.ca>
Message-ID: <CABH=_VQR6r-VBb7vB6GTBi-p9ZB9+POhqHP_WRTMbxn5u_JVsw@mail.gmail.com>

On 9/30/18, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> John P. Linderman writes:
>
>> We always referred to HP-UX as "H-Pukes".
>
> For us canucks, it has always been called "hockey pucks" :-)
>
Back at DEC Engineering we had the saying, "you can't teach a new dog ULTRIX."

-Paul W.


From steffen at sdaoden.eu  Tue Oct  2 02:35:24 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 01 Oct 2018 18:35:24 +0200
Subject: [TUHS] plan9 first edition
In-Reply-To: <b99f97eb854186082177b02ff4f38bad@quintile.net>
References: <b99f97eb854186082177b02ff4f38bad@quintile.net>
Message-ID: <20181001163524.wHEHy%steffen@sdaoden.eu>

Steve Simon wrote in <b99f97eb854186082177b02ff4f38bad at quintile.net>:
 |I can only speak from my experience, but I think there was a more or less
 |official 1st Ed release. in 1993 I was working as a system manager
 |at UNSW I requested and receicved a Plan9 CDROM with about 5 inches of
 |printed manual (but unbound) manual from the labs.
 |
 |Here is some bits and pieces about the Ed1 I scraped together some \
 |years ago,
 |including the artwork for the CD :-)
 |
 |https://plan9.io/sources/contrib/steve/historic/1st-edition/
 |
 |I also believe that the CD contained some music in RedBook form
 |(sadly I never got around to putting the disk in an audio cd drive).
 |If I am right, then this has been reissued.
 |
 |https://bauhaus.bandcamp.com/

You are better off buying the "1979-1983" collection, "Volume One"
and "Volume Two", White and Black they are.

 |Everyone sing along now, Undead undead, undead...

"Paranoia, Paranoia".  But for Plan9 "Stigmata Martyr" would
possibly fit better.  Or "All we ever wanted".  Then again:
"Who killed Mr. Moonlight?"

The German news magazine "DER SPIEGEL" celebrated when they
released a new album after about twenty years, that must have been
13 or so years go, now.

"The Passion of Lovers" is forget says
"God In An Alcove".

Puuuhh....

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From beebe at math.utah.edu  Sun Oct  7 10:00:55 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sat, 6 Oct 2018 18:00:55 -0600
Subject: [TUHS]  Unix source code archive in the news
Message-ID: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>

I've just finished reading another article in the latest print issue
of Communications of the ACM that arrived in my mailbox earlier this
week:

	Jean-Fran{\c{c}}ois Abramatic, Roberto Di Cosmo, and Stefano Zacchiroli
	Viewpoint: Building the universal archive of source code
	Comm. ACM 61(20) 29--31 October 2018
	https://doi.org/10.1145/3183558
	https://dl.acm.org/citation.cfm?doid=3281635.3183558

I draw it to your attention to it because it has favorable mention of
the Computer History Museum, and of Diomidis Spinellis's work on the
Unix source code archive, described in his article

	A repository of Unix history and evolution
	Empirical Software Engineering 22(3) 1372--1404 June 2017
	https://doi.org/10.1007/s10664-016-9445-5
	https://link.springer.com/article/10.1007/s10664-016-9445-5

The project that Abramatic describe is impressive: a goal of a
triplicated complete archive of the world's software history,
including both open source and proprietary code.  They report holding
200TB of data already, covering 80 million code projects.

-------------------------------------------------------------------------------
- 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 nw at retrocomputingtasmania.com  Sun Oct  7 10:07:33 2018
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 7 Oct 2018 11:07:33 +1100
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>
Message-ID: <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>

On Sun, Oct 7, 2018 at 11:01 AM Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> The project that Abramatic describe is impressive: a goal of a
> triplicated complete archive of the world's software history...

They have a website too: https://www.softwareheritage.org/


From wlc at jctaylor.com  Sun Oct  7 10:55:42 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Sun, 7 Oct 2018 00:55:42 +0000
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>,
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
Message-ID: <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>

Half the programmers in this world could not code themselves out of a brown paper bag.  Sounds more like a software sewer than a great work of art.  

Bill Corcoran  

> On Oct 6, 2018, at 8:08 PM, Nigel Williams <nw at retrocomputingtasmania.com> wrote:
> 
>> On Sun, Oct 7, 2018 at 11:01 AM Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>> The project that Abramatic describe is impressive: a goal of a
>> triplicated complete archive of the world's software history...
> 
> They have a website too: https://www.softwareheritage.org/


From jnc at mercury.lcs.mit.edu  Sun Oct  7 11:04:59 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  6 Oct 2018 21:04:59 -0400 (EDT)
Subject: [TUHS] Unix source code archive in the news
Message-ID: <20181007010459.9098E18C096@mercury.lcs.mit.edu>

    > From: "Nelson H. F. Beebe"

    > a goal of a triplicated complete archive of the world's software
    > history, including both open source and proprietary code.  They report
    > holding 200TB of data already, covering 80 million code projects.

I should ask them if they have a copy of MERT!

Now that we have Multics, ITS, PDP-7 UNIX and UNIX V0, etc MERT (which may
have been the first micro-kernel - although perhaps THE gets that palm) is
perhaps the most significant 'missing' OS.

If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's
been saved.) The THE system? (Ditto - although I know someone has saved the
last X8.) The Atlas OS?

     Noel


From akosela at andykosela.com  Sun Oct  7 11:28:37 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 6 Oct 2018 20:28:37 -0500
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
 <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
Message-ID: <CALMnNGgOayCbW9yTd2-TFvyT+rus=tW9L11h8iQh4+75MX59Jw@mail.gmail.com>

On Saturday, October 6, 2018, William Corcoran <wlc at jctaylor.com> wrote:

> Half the programmers in this world could not code themselves out of a
> brown paper bag.  Sounds more like a software sewer than a great work of
> art.
>
> Bill Corcoran
>


Exactly my thoughts too.  Code inflation[1] is a huge problem today.  There
was a day when one person could understand the whole UNIX kernel... now
with millions of lines of code in Linux and FreeBSD I don't think this is
possible anymore and definitely it is not fun.  That is why you see more
and more paid code in Linux -- who else would like to debug this bloated
monster it became just for fun... like back in the days.

Programming these days (especially in bussiness sector with projects
written in C++ or Java) is not fun and I feel sorry for those poor people
that must maintain such projects.

We need to come back to simple and minimalistic systems, otherwise we will
all be buried soon underneath terabytes of unmaintainable bloated code...

--Andy

[1] Code Inflation, Gerald J Holzmann
https://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/04/mso2015020010.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181006/564e9204/attachment.html>

From paul at mcjones.org  Sun Oct  7 12:31:06 2018
From: paul at mcjones.org (Paul McJones)
Date: Sat, 6 Oct 2018 19:31:06 -0700
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <mailman.1.1538877601.18358.tuhs@minnie.tuhs.org>
References: <mailman.1.1538877601.18358.tuhs@minnie.tuhs.org>
Message-ID: <2305E5A1-878A-49B9-BF21-39D0155F8379@mcjones.org>

> On Oct 6, 2018 ,jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
> 
> Date: Sat,  6 Oct 2018 21:04:59 -0400 (EDT)
> From: jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu> (Noel Chiappa)
> Subject: Re: [TUHS] Unix source code archive in the news
> Message-ID: <20181007010459.9098E18C096 at mercury.lcs.mit.edu <mailto:20181007010459.9098E18C096 at mercury.lcs.mit.edu>>
> 
> If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's
> been saved.) The THE system? (Ditto - although I know someone has saved the
> last X8.) The Atlas OS?

The Computer History Museum’s Donald Knuth digital archive project  (http://www.computerhistory.org/collections/catalog/102726297 <http://www.computerhistory.org/collections/catalog/102726297>) contains a scan of a listing of the source code of the THE Operating System by Bron, Dijkstra, et al. The finding aid for the collection is here: http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/KnuthDigitalArchive-Index.html <http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/KnuthDigitalArchive-Index.html> — scan down for “Source code of the THE Operating System”.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181006/a4740382/attachment.html>

From lars at nocrew.org  Sun Oct  7 14:08:05 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 07 Oct 2018 04:08:05 +0000
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <20181007010459.9098E18C096@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Sat, 6 Oct 2018 21:04:59 -0400 (EDT)")
References: <20181007010459.9098E18C096@mercury.lcs.mit.edu>
Message-ID: <7wva6eqtzu.fsf@junk.nocrew.org>

Noel Chiappa writes:
> If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno
> if that's been saved.)

I think it has.


From jsteve at superglobalmegacorp.com  Sun Oct  7 14:56:06 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Sun, 7 Oct 2018 12:56:06 +0800
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <20181007010459.9098E18C096@mercury.lcs.mit.edu>
References: <20181007010459.9098E18C096@mercury.lcs.mit.edu>
Message-ID: <51288659-0e61-4ba8-9bbb-9e2a24f2f3b1@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>

I'd say TripOS.  There is some surce fragments but I never could get any BCPL to cross build anything.

Also Mach 1.x to 2.5

Sent from my Windows 10 Nokia Lumia 1520

From: Noel Chiappa
Sent: Sunday, 7 October 2018 9:05 AM
To: tuhs at minnie.tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] Unix source code archive in the news

    > From: "Nelson H. F. Beebe"

    > a goal of a triplicated complete archive of the world's software
    > history, including both open source and proprietary code.  They report
    > holding 200TB of data already, covering 80 million code projects.

I should ask them if they have a copy of MERT!

Now that we have Multics, ITS, PDP-7 UNIX and UNIX V0, etc MERT (which may
have been the first micro-kernel - although perhaps THE gets that palm) is
perhaps the most significant 'missing' OS.

If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's
been saved.) The THE system? (Ditto - although I know someone has saved the
last X8.) The Atlas OS?

     Noel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181007/e0498cb1/attachment.html>

From arnold at skeeve.com  Sun Oct  7 16:07:33 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 07 Oct 2018 00:07:33 -0600
Subject: [TUHS] Software Archeology: QED
Message-ID: <201810070607.w9767Xrl014901@freefriends.org>

Hi All.

I am starting to collect, if possible, different versions of the QED
editor; with a hope to put up a git repo.

If you have a tarball of code, please send it to me with as much info
about it as you have.  I would like to track down the qedbuf(1) man page
also.

I have contacted Rob Pike and got one tarball from him. I have another
tarball that I got sometime in 1987 and have a promise of code coming
Donald Mitchell.

Much thanks!

Arnold


From lars at nocrew.org  Sun Oct  7 20:05:05 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 07 Oct 2018 10:05:05 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810070607.w9767Xrl014901@freefriends.org>
 (arnold@skeeve.com's message of "Sun, 07 Oct 2018 00:07:33 -0600")
References: <201810070607.w9767Xrl014901@freefriends.org>
Message-ID: <7w7eiuqdgu.fsf@junk.nocrew.org>

Arnold wrote:
> I am starting to collect, if possible, different versions of the QED
> editor; with a hope to put up a git repo.

Very good!  Editors need preservation too.

Anyone curious about Pratt's ZED aka DOC?


From arrigo at alchemistowl.org  Sun Oct  7 20:23:50 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Sun, 7 Oct 2018 12:23:50 +0200
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <7w7eiuqdgu.fsf@junk.nocrew.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>
Message-ID: <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>

> Arnold wrote:
>> I am starting to collect, if possible, different versions of the QED
>> editor; with a hope to put up a git repo.
> 
> Very good!  Editors need preservation too.
> 
> Anyone curious about Pratt's ZED aka DOC?

What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?

Arrigo 


From jnc at mercury.lcs.mit.edu  Sun Oct  7 21:23:44 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  7 Oct 2018 07:23:44 -0400 (EDT)
Subject: [TUHS] Unix source code archive in the news
Message-ID: <20181007112344.0398D18C08F@mercury.lcs.mit.edu>

    > From: jsteve

    > I'd say TripOS.  There is some surce fragments but I never could get any
    > BCPL to cross build anything.

I'm somewhat stunned to hear that, given that Martin Richards did both! What kind
of things are the compilers complaining about? (And I'm also kind of amazed that
Cambridge didn't make an effort to save Tripos.)

	  Noel


From arnold at skeeve.com  Sun Oct  7 21:48:55 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 07 Oct 2018 05:48:55 -0600
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <20181007112344.0398D18C08F@mercury.lcs.mit.edu>
References: <20181007112344.0398D18C08F@mercury.lcs.mit.edu>
Message-ID: <201810071148.w97BmtTF001629@freefriends.org>

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>     > From: jsteve
>
>     > I'd say TripOS.  There is some surce fragments but I never could get any
>     > BCPL to cross build anything.
>
> I'm somewhat stunned to hear that, given that Martin Richards did both! What kind
> of things are the compilers complaining about? (And I'm also kind of amazed that
> Cambridge didn't make an effort to save Tripos.)
>
> 	  Noel

Isn't Martin Richards still around?  Can't someone "just" ask him?
See https://www.cl.cam.ac.uk/~mr10/

Arnold


From mutiny.mutiny at india.com  Sun Oct  7 22:33:31 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sun, 7 Oct 2018 12:33:31 +0000 (UTC)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>,
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
Message-ID: <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>

At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi <a target="_blank"rrigo at alchemistowl.org>:
> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
em.  
http://pgas.freeshell.org/C/em/

> Arrigo 


From mutiny.mutiny at india.com  Sun Oct  7 22:41:11 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sun, 7 Oct 2018 12:41:11 +0000 (UTC)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810070607.w9767Xrl014901@freefriends.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
Message-ID: <1924064959.28358.1538916071406.JavaMail.tomcat@india-live-be01>

At 7 Oct 2018 06:08:57 +0000 (+00:00) from arnold at skeeve.com:
> I have contacted Rob Pike and got one tarball from him. I have another
> tarball that I got sometime in 1987 and have a promise of code coming
> Donald Mitchell.

there is already a git repo at https://github.com/chneukirchen/qed-caltech

Then se, a very ed like screen editor:
http://se-editor.org/
https://github.com/screen-editor/se


From arrigo at alchemistowl.org  Sun Oct  7 22:52:34 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Sun, 7 Oct 2018 14:52:34 +0200
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
 <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
Message-ID: <AC1880D8-1859-49C5-9DCE-99BC2D8ADBDC@alchemistowl.org>

On 7 Oct 2018, at 14:33, Donald ODona <mutiny.mutiny at india.com> wrote:
> 
> At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi <a target="_blank"rrigo at alchemistowl.org>:
>> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
> em.  
> http://pgas.freeshell.org/C/em/

Ah, thank you.

Arrigo



From usotsuki at buric.co  Sun Oct  7 22:46:59 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 7 Oct 2018 08:46:59 -0400 (EDT)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>,
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
 <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
Message-ID: <alpine.BSF.2.02.1810070845380.96737@frieza.hoshinet.org>

On Sun, 7 Oct 2018, Donald ODona wrote:

> At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi <a target="_blank"rrigo at alchemistowl.org>:
>> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
> em.
> http://pgas.freeshell.org/C/em/
>
>> Arrigo
>

When I think of "e", I think of IBM's text editor, which I had on one of 
my XTs before it became part of PC DOS 6.1.

-uso.

From arnold at skeeve.com  Mon Oct  8 00:11:37 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 07 Oct 2018 08:11:37 -0600
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <1924064959.28358.1538916071406.JavaMail.tomcat@india-live-be01>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <1924064959.28358.1538916071406.JavaMail.tomcat@india-live-be01>
Message-ID: <201810071411.w97EBbTS006608@freefriends.org>

Donald ODona <mutiny.mutiny at india.com> wrote:

> At 7 Oct 2018 06:08:57 +0000 (+00:00) from arnold at skeeve.com:
> > I have contacted Rob Pike and got one tarball from him. I have another
> > tarball that I got sometime in 1987 and have a promise of code coming
> > Donald Mitchell.
>
> there is already a git repo at https://github.com/chneukirchen/qed-caltech

Thanks, I'll take a look at that too.

> Then se, a very ed like screen editor:
> http://se-editor.org/
> https://github.com/screen-editor/se

I'm quite familiar with this. I'm the one who posted the original C version
of se to comp.sources.unix > 30 years ago.  :-)

It's quite ironic. To get se going on Unix I had to learn vi. Then
vi became hardwired into my finger ROMs such that I didn't feel like
going back to using se.

se is derived from the Software Tools Ratfor editor, so it's an ed
clone, not based on Unix ed code.

Arnold


From mutiny.mutiny at india.com  Mon Oct  8 01:41:07 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sun, 7 Oct 2018 15:41:07 +0000 (UTC)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810071411.w97EBbTS006608@freefriends.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <1924064959.28358.1538916071406.JavaMail.tomcat@india-live-be01>,
 <201810071411.w97EBbTS006608@freefriends.org>
Message-ID: <1866708223.28413.1538926867786.JavaMail.tomcat@india-live-be01>



At 7 Oct 2018 14:16:56 +0000 (+00:00) from arnold at skeeve.com:
> Donald ODona <mutiny.mutiny at india.com> wrote:
> 
> > At 7 Oct 2018 06:08:57 +0000 (+00:00) from arnold at skeeve.
> It's quite ironic. To get se going on Unix I had to learn vi. Then
> vi became hardwired into my finger ROMs such that I didn't feel like
> going back to using se.
> 
> se is derived from the Software Tools Ratfor editor, so it's an ed
> clone, not based on Unix ed code.
I know that. se has somewhat limited regexp syntax, but otherwise is a nice editor. You'll wonder but I'm still using it occasionally.


From leah at vuxu.org  Mon Oct  8 01:52:29 2018
From: leah at vuxu.org (Leah Neukirchen)
Date: Sun, 07 Oct 2018 17:52:29 +0200
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810071411.w97EBbTS006608@freefriends.org> (arnold's message
 of "Sun, 07 Oct 2018 08:11:37 -0600")
References: <201810070607.w9767Xrl014901@freefriends.org>
 <1924064959.28358.1538916071406.JavaMail.tomcat@india-live-be01>
 <201810071411.w97EBbTS006608@freefriends.org>
Message-ID: <87in2d92ki.fsf@vuxu.org>

arnold at skeeve.com writes:

> Donald ODona <mutiny.mutiny at india.com> wrote:
>
>> At 7 Oct 2018 06:08:57 +0000 (+00:00) from arnold at skeeve.com:
>> > I have contacted Rob Pike and got one tarball from him. I have another
>> > tarball that I got sometime in 1987 and have a promise of code coming
>> > Donald Mitchell.
>>
>> there is already a git repo at https://github.com/chneukirchen/qed-caltech
>
> Thanks, I'll take a look at that too.

Yep, that's mine.

I tried contacting David Tilbrook several times and got no replies.

I think some people around Toronto still use qed, but they seem to be
very secretive about it.

hth,
-- 
Leah Neukirchen  <leah at vuxu.org>  http://leah.zone


From jgevaryahu at hotmail.com  Mon Oct  8 02:41:26 2018
From: jgevaryahu at hotmail.com (Jonathan Gevaryahu)
Date: Sun, 7 Oct 2018 16:41:26 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
Message-ID: <BL2PR04MB20017F46644DE2E10D702243C7E50@BL2PR04MB2001.namprd04.prod.outlook.com>

On 10/7/2018 6:23 AM, Arrigo Triulzi wrote:
>> Arnold wrote:
>>> I am starting to collect, if possible, different versions of the QED
>>> editor; with a hope to put up a git repo.
>> Very good!  Editors need preservation too.
>>
>> Anyone curious about Pratt's ZED aka DOC?
> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
>
> Arrigo
> .
>
I remember when digging for the speak.c/h stuff in the v6_doc disk pack 
image, there were incomplete fragments of an editor (restricted ed? ed?) 
source code in there, earlier than any version of the source code I 
could find at the time, so that might be interesting to dig into as well.

-- 
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com


From lars at nocrew.org  Mon Oct  8 03:00:57 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 07 Oct 2018 17:00:57 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810070607.w9767Xrl014901@freefriends.org>
 (arnold@skeeve.com's message of "Sun, 07 Oct 2018 00:07:33 -0600")
References: <201810070607.w9767Xrl014901@freefriends.org>
Message-ID: <7wtvlxpu7q.fsf@junk.nocrew.org>

Arnold wrote:
> I am starting to collect, if possible, different versions of the QED
> editor; with a hope to put up a git repo.

I'm asking around for 940, CTSS, and Multics versions of QED.


From lars at nocrew.org  Mon Oct  8 03:11:09 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 07 Oct 2018 17:11:09 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <7wtvlxpu7q.fsf@junk.nocrew.org> (Lars Brinkhoff's message of
 "Sun, 07 Oct 2018 17:00:57 +0000")
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7wtvlxpu7q.fsf@junk.nocrew.org>
Message-ID: <7wh8hxptqq.fsf@junk.nocrew.org>

> I'm asking around for 940, CTSS, and Multics versions of QED.

CTSS QED is here:

https://github.com/rcornwell/ctss/tree/master/src/edit


From jsteve at superglobalmegacorp.com  Sun Oct  7 23:20:29 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Sun, 7 Oct 2018 21:20:29 +0800
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <alpine.BSF.2.02.1810070845380.96737@frieza.hoshinet.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>,
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
 <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
 <alpine.BSF.2.02.1810070845380.96737@frieza.hoshinet.org>
Message-ID: <d69f079c-f73f-49e5-8ea4-792fd1b10894@SG2APC01FT030.eop-APC01.prod.protection.outlook.com>

IBM bundled it in with OS/2 Warp.  I forget if the edlin was a family API app.

Now that edlin is MIT licensed I guess it may live on

Sent from my Windows 10 Nokia Lumia 1520

From: Steve Nickolas
Sent: Sunday, 7 October 2018 8:56 PM
To: Donald ODona
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] Software Archeology: QED

On Sun, 7 Oct 2018, Donald ODona wrote:

> At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi <a target="_blank"rrigo at alchemistowl.org>:
>> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
> em.
> http://pgas.freeshell.org/C/em/
>
>> Arrigo
>

When I think of "e", I think of IBM's text editor, which I had on one of 
my XTs before it became part of PC DOS 6.1.

-uso.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181007/509bbbc9/attachment.html>

From lars at nocrew.org  Mon Oct  8 13:21:47 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 08 Oct 2018 03:21:47 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <7wtvlxpu7q.fsf@junk.nocrew.org> (Lars Brinkhoff's message of
 "Sun, 07 Oct 2018 17:00:57 +0000")
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7wtvlxpu7q.fsf@junk.nocrew.org>
Message-ID: <7wsh1hnmwk.fsf@junk.nocrew.org>

> I'm asking around for 940, CTSS, and Multics versions of QED.

QED for the 940 timesharing system might appear later.

Multics QEDX:
https://ban.ai/~jhj/misc/qedx/


From trnsz at pobox.com  Mon Oct  8 13:58:27 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Sun, 7 Oct 2018 23:58:27 -0400
Subject: [TUHS] Software Archeology: QED
References: <A5B0EEC4-9AC1-4E7D-8D26-DEEFAF4DAD2C@pobox.com>
Message-ID: <F220EBBB-7AA5-41AD-9739-36333B0F3DE3@pobox.com>

Might as well send this to the list:

There are Multics QEDX sources, but I haven't run across QED - however, there is an overview of it's use and commands in the General Electric June 1969 Multics Condensed Guide (http://bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf)

I pulled the QEDX source at put it at https://ban.ai/~jhj/misc/qedx/ for easy access - this is the MR12.5 version and last modified in 1989, sadly, I don't ever recall seeing the BCPL QED. [ I'll be sure to remember now if I see it. ]

[ Somewhat off-topic ] How about Yale 'Z' as long as we're talking editors? Or another editor (that I very much like) is the 'G' editor, which has a long history, originating on Honeywell 6000 GCOS/TSS, originally written in B: https://github.com/ascheepe/g-editor - works nicely today. There is also the Ecce editor, which includes versions in IMP, BASIC, C, BCPL, and FORTRAN at http://history.dcs.ed.ac.uk/archive/apps/ecce/ - bringing Ecce up on Multics is an item on my todo list. 

-- Jeff - https://ban.ai/multics/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181007/eb33e04a/attachment.html>

From trnsz at pobox.com  Mon Oct  8 13:58:27 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Sun, 7 Oct 2018 23:58:27 -0400
Subject: [TUHS] Software Archeology: QED
References: <A5B0EEC4-9AC1-4E7D-8D26-DEEFAF4DAD2C@pobox.com>
Message-ID: <F220EBBB-7AA5-41AD-9739-36333B0F3DE3@pobox.com>

Might as well send this to the list:

There are Multics QEDX sources, but I haven't run across QED - however, there is an overview of it's use and commands in the General Electric June 1969 Multics Condensed Guide (http://bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf)

I pulled the QEDX source at put it at https://ban.ai/~jhj/misc/qedx/ for easy access - this is the MR12.5 version and last modified in 1989, sadly, I don't ever recall seeing the BCPL QED. [ I'll be sure to remember now if I see it. ]

[ Somewhat off-topic ] How about Yale 'Z' as long as we're talking editors? Or another editor (that I very much like) is the 'G' editor, which has a long history, originating on Honeywell 6000 GCOS/TSS, originally written in B: https://github.com/ascheepe/g-editor - works nicely today. There is also the Ecce editor, which includes versions in IMP, BASIC, C, BCPL, and FORTRAN at http://history.dcs.ed.ac.uk/archive/apps/ecce/ - bringing Ecce up on Multics is an item on my todo list. 

-- Jeff - https://ban.ai/multics/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181007/eb33e04a/attachment-0001.html>

From dave at horsfall.org  Mon Oct  8 15:34:01 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 8 Oct 2018 16:34:01 +1100 (EST)
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>,
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
 <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
Message-ID: <alpine.BSF.2.21.9999.1810081627550.66838@aneurin.horsfall.org>

On Sun, 7 Oct 2018, William Corcoran wrote:

> Half the programmers in this world could not code themselves out of a 
> brown paper bag.  Sounds more like a software sewer than a great work of 
> art.

These days, anyone who can do VB etc can call themselves a programmer; in 
my day, you had to know PDP-11 or VAX assembler...  Or Z-80...

-- Dave (An ROF, i.e. a Retired Old Fart)


From usotsuki at buric.co  Mon Oct  8 15:55:23 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 8 Oct 2018 01:55:23 -0400 (EDT)
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <alpine.BSF.2.21.9999.1810081627550.66838@aneurin.horsfall.org>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>,
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
 <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
 <alpine.BSF.2.21.9999.1810081627550.66838@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1810080155020.57190@frieza.hoshinet.org>

On Mon, 8 Oct 2018, Dave Horsfall wrote:

> On Sun, 7 Oct 2018, William Corcoran wrote:
>
>> Half the programmers in this world could not code themselves out of a brown 
>> paper bag.  Sounds more like a software sewer than a great work of art.
>
> These days, anyone who can do VB etc can call themselves a programmer; in my 
> day, you had to know PDP-11 or VAX assembler...  Or Z-80...

I know 65C02, is that good enough? xD

-uso.


From dot at dotat.at  Mon Oct  8 20:03:21 2018
From: dot at dotat.at (Tony Finch)
Date: Mon, 8 Oct 2018 11:03:21 +0100
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <201810071148.w97BmtTF001629@freefriends.org>
References: <20181007112344.0398D18C08F@mercury.lcs.mit.edu>
 <201810071148.w97BmtTF001629@freefriends.org>
Message-ID: <alpine.DEB.2.20.1810081049570.3596@grey.csi.cam.ac.uk>

arnold at skeeve.com <arnold at skeeve.com> wrote:
>
> Isn't Martin Richards still around?  Can't someone "just" ask him?

There's a TRIPOS archive on his web pages; I don't know if there's
anything more comprehensive dating back to when it was being used in the
1980s.

He retired in 2007, though I think he can be found in his college if not
in the Computer Lab.

https://www.cl.cam.ac.uk/newlabphotos/MR-retirement/

A few notes on the pictures:

Maurice Wilkes can be seen on the left in photo 1967.

Chris Cheney is on the left in photo 8317. Chris invented his eponymous
copying garbage collector algorithm when working on ALGOL 68 with
Steve Bourne.

The green door was preserved from the original Mathematical Laboratory
building that housed EDSAC and its successors until about 1970; the brass
plaque records the names of those who worked in the old building and
stuck around long enough to retire after Wilkes.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
oppose all forms of entrenched privilege and inequality


From katolaz at freaknet.org  Mon Oct  8 20:18:32 2018
From: katolaz at freaknet.org (KatolaZ)
Date: Mon, 8 Oct 2018 12:18:32 +0200
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <AC1880D8-1859-49C5-9DCE-99BC2D8ADBDC@alchemistowl.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <7w7eiuqdgu.fsf@junk.nocrew.org>
 <A04CD830-B8D6-4817-81BD-CED235C051E3@alchemistowl.org>
 <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01>
 <AC1880D8-1859-49C5-9DCE-99BC2D8ADBDC@alchemistowl.org>
Message-ID: <20181008101832.axbowysei6s4xzse@katolaz.homeunix.net>

On Sun, Oct 07, 2018 at 02:52:34PM +0200, Arrigo Triulzi wrote:
> On 7 Oct 2018, at 14:33, Donald ODona <mutiny.mutiny at india.com> wrote:
> > 
> > At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi <a target="_blank"rrigo at alchemistowl.org>:
> >> What was the name of the editor which George Coulouris wrote at Queen Mary College (then Queen Mary and Westfield, now Queen Mary, University of London)? “e”?
> > em.  
> > http://pgas.freeshell.org/C/em/
> 
> Ah, thank you.
> 

I tried the "modernised" version of em by Pierre Gaston a few months
back, and unfortunately it crashes repreatedly on some em-specific
commands. I shall look deeper, but it would be nice to have a
functioning version... ;)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181008/fb746a40/attachment.sig>

From reed at reedmedia.net  Tue Oct  9 05:00:48 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon, 8 Oct 2018 14:00:48 -0500 (CDT)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810070607.w9767Xrl014901@freefriends.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
Message-ID: <alpine.NEB.2.20.1810081352350.4300@t1.m.reedmedia.net>

On Sun, 7 Oct 2018, arnold at skeeve.com wrote:

> I would like to track down the qedbuf(1) man page also.

Not sure if that is different that qedbufs.1 (with an "s").
It is in two usenix sets:

usenix79+80/boulder/caltech/doc/qedbufs.1
usenix_80_delaware/boulder/caltech/doc/qedbufs.1

https://www.tuhs.org/Archive/Applications/Spencer_Tapes/

https://www.tuhs.org/Archive/Applications/Shoppa_Tapes/


From arnold at skeeve.com  Tue Oct  9 16:01:15 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 09 Oct 2018 00:01:15 -0600
Subject: [TUHS] QED editor - thanks!
Message-ID: <201810090601.w9961FZR008685@freefriends.org>

Thanks to everyone who replied with tarballs, zip files, pointers to
stuff in the archive, web links ...  I will try (eventually) to thank
everyone individually as well, but in the meantime please accept this
broadcast. :-)

This has now become Yet Another Back Burner Project; I hope putting things
together into a reasonable github repo (or two) will happen without
too much of a delay.

This is a great group of people!

Thanks,

Arnold


From mutiny.mutiny at india.com  Tue Oct  9 16:28:24 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Tue, 9 Oct 2018 06:28:24 +0000 (UTC)
Subject: [TUHS] QED editor - thanks!
In-Reply-To: <201810090601.w9961FZR008685@freefriends.org>
References: <201810090601.w9961FZR008685@freefriends.org>
Message-ID: <1244255036.29941.1539066504242.JavaMail.tomcat@india-live-be01>

Hello,

no, Arnold, we have to thank you for the great idea publishing sources and docs of ancient editors in git{hub,lab,or elsewhere}.
This will make life easier for me and others collecting retro computing stuff.
Again thanks a lot!

At 9 Oct 2018 06:02:35 +0000 (+00:00) from arnold at skeeve.com:
> Thanks to everyone who replied with tarballs, zip files, pointers to
> stuff in the archive, web links ...  I will try (eventually) to thank
> everyone individually as well, but in the meantime please accept this
> broadcast. :-)
> 
> This has now become Yet Another Back Burner Project; I hope putting things
> together into a reasonable github repo (or two) will happen without
> too much of a delay.
> 
> This is a great group of people!
> 
> Thanks,
> 
> Arnold


From arnold at skeeve.com  Tue Oct  9 19:26:28 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 09 Oct 2018 03:26:28 -0600
Subject: [TUHS] QED editor - thanks!
In-Reply-To: <1244255036.29941.1539066504242.JavaMail.tomcat@india-live-be01>
References: <201810090601.w9961FZR008685@freefriends.org>
 <1244255036.29941.1539066504242.JavaMail.tomcat@india-live-be01>
Message-ID: <201810090926.w999QSAk019015@freefriends.org>

It is fun, when I can steal the time!

Donald ODona <mutiny.mutiny at india.com> wrote:

> Hello,
>
> no, Arnold, we have to thank you for the great idea publishing sources and docs of ancient editors in git{hub,lab,or elsewhere}.
> This will make life easier for me and others collecting retro computing stuff.
> Again thanks a lot!
>
> At 9 Oct 2018 06:02:35 +0000 (+00:00) from arnold at skeeve.com:
> > Thanks to everyone who replied with tarballs, zip files, pointers to
> > stuff in the archive, web links ...  I will try (eventually) to thank
> > everyone individually as well, but in the meantime please accept this
> > broadcast. :-)
> > 
> > This has now become Yet Another Back Burner Project; I hope putting things
> > together into a reasonable github repo (or two) will happen without
> > too much of a delay.
> > 
> > This is a great group of people!
> > 
> > Thanks,
> > 
> > Arnold


From dave at horsfall.org  Wed Oct 10 09:02:09 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 10 Oct 2018 10:02:09 +1100 (EST)
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <alpine.BSF.2.02.1810080155020.57190@frieza.hoshinet.org>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>,
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
 <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
 <alpine.BSF.2.21.9999.1810081627550.66838@aneurin.horsfall.org>
 <alpine.BSF.2.02.1810080155020.57190@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.21.9999.1810100956110.66838@aneurin.horsfall.org>

>> These days, anyone who can do VB etc can call themselves a programmer; 
>> in my day, you had to know PDP-11 or VAX assembler...  Or Z-80...
>
> I know 65C02, is that good enough? xD

I arrived too late for the 6502; my first was the Z-80 Microbee (when 
everyone else I knew was into the Apple-I; then again, I've never been a 
conformist, just like my RAF parents).

-- Dave


From ckeck at texoma.net  Wed Oct 10 10:11:15 2018
From: ckeck at texoma.net (Cornelius Keck)
Date: Tue, 09 Oct 2018 19:11:15 -0500
Subject: [TUHS] Unix source code archive in the news
In-Reply-To: <alpine.BSF.2.21.9999.1810100956110.66838@aneurin.horsfall.org>
References: <CMM.0.96.0.1538870455.beebe@gamma.math.utah.edu>,
 <CACCFpdyPc2o4RbGk7qzH2=hKhdK9AEW4E=4FZaMEP+WRe5VFbQ@mail.gmail.com>
 <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com>
 <alpine.BSF.2.21.9999.1810081627550.66838@aneurin.horsfall.org>
 <alpine.BSF.2.02.1810080155020.57190@frieza.hoshinet.org>
 <alpine.BSF.2.21.9999.1810100956110.66838@aneurin.horsfall.org>
Message-ID: <20181010001115.4935754.38380.10710@texoma.net>

Similar here... 6502 assembler on a CBM3032, while everybody else had an Apple II. Later 8080 on a simulator, Z80, 68000, Z8000, 8088, in that order. Z8000 is still my favourite, spent a lot of time with that.


Gesendet von meinem BlackBerry 10-Smartphone.
  Originalnachricht  
Von: Dave Horsfall
Gesendet: Dienstag, 9. Oktober 2018 18:03
An: The Eunuchs Hysterical Society
Betreff: Re: [TUHS] Unix source code archive in the news

>> These days, anyone who can do VB etc can call themselves a programmer; 
>> in my day, you had to know PDP-11 or VAX assembler... Or Z-80...
>
> I know 65C02, is that good enough? xD

I arrived too late for the 6502; my first was the Z-80 Microbee (when 
everyone else I knew was into the Apple-I; then again, I've never been a 
conformist, just like my RAF parents).

-- Dave


From dave at horsfall.org  Wed Oct 10 12:38:39 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 10 Oct 2018 13:38:39 +1100 (EST)
Subject: [TUHS] The origin of /home
In-Reply-To: <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
 <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
 <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1810101332460.66838@aneurin.horsfall.org>

I'm quite amused by this thread.

Before I started using /home (Slowaris had yet to appear), I used /u/* 
instead (I didn't want to pollute /usr with home directories).

-- Dave


From gtaylor at tnetconsulting.net  Wed Oct 10 13:07:06 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 9 Oct 2018 21:07:06 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <alpine.BSF.2.21.9999.1810101332460.66838@aneurin.horsfall.org>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
 <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
 <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
 <alpine.BSF.2.21.9999.1810101332460.66838@aneurin.horsfall.org>
Message-ID: <025cbe25-05f1-f5b4-344a-58f36b05e7a6@spamtrap.tnetconsulting.net>

On 10/09/2018 08:38 PM, Dave Horsfall wrote:
> I'm quite amused by this thread.

As am I.

> Before I started using /home (Slowaris had yet to appear), I used /u/* 
> instead (I didn't want to pollute /usr with home directories).

@thatcks on Twitter indicates that they still use /u/$USER on their systems.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181009/1096f4fb/attachment.bin>

From kevin.bowling at kev009.com  Wed Oct 10 16:54:15 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 9 Oct 2018 23:54:15 -0700
Subject: [TUHS] Cellular Irix
Message-ID: <CAK7dMtAaMb5u8dLfqe1t35tp5t_0o5RALimLUBzOSAzAxLYJ-Q@mail.gmail.com>

https://cug.org/5-publications/proceedings_attendee_lists/1998CD/S98PROC/AUTHORS/BRONER/ACROBAT.PDF
anyone know more about this?

Seems like they were thinking about the interesting problems at the time

Regards,
Kevin


From norman at oclsc.org  Thu Oct 11 00:43:41 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 10 Oct 2018 10:43:41 -0400
Subject: [TUHS] The origin of /home
Message-ID: <1539182625.28839.for-standards-violators@oclsc.org>

Dave Horsfall:

  Before I started using /home (Slowaris had yet to appear), I used /u/* 
  instead (I didn't want to pollute /usr with home directories).

===

I'm late to the party, but I'll chime in too:

The first UNIX system I ever used, ca. 1980, had users' home
directories in /u.  I suspect it was that way (as suggested
in some earlier messages) just for storage management: separate
file system from /usr.

I've carried /u around with me ever since to other systems
I've set up from scratch, except in my home environment
where I've made a radical departure: everything that isn't
part of the base OS is in a tree rooted at /con, so home
directories are /con/u.  /con was `constant,' inspired
by /var, meaning stuff that should be preserved when the OS
is reinstalled--everything else should come from installation
media or configuration management.

But in any case there's nothing especially novel about moving
users' home directories out of /usr, and since it's UNIX,
nothing that says there has to be any standard at all.  On
the systems I am currently paid to help run, most users have
home-directory names like /h/u12/c4/00/c4ntest.  There is no
attempt to glue together a single name hierarchy; we have in
excess of 17000 users so that would be something of a mess.
(I guess enormous directories aren't the resource pigs they
used to be, though symlinks are just as bad as they have
ever been.)  There's the ~user shell syntax for those who like
that; I don't, but I have a little shell script in my personal
bin directory so I can do things like ls `home c4ntest`; it all
just works.

I once thought of writing a paper entitled `/usr and /etc
considered harmful,' in which I would have proposed:

a.  It no longer matters a whit whether the (real) root file
system can fit into a 5MB slice of the disk or the like, so
just merge everything that spilled into /usr in the tiny-disk
days back into the root where it belongs.
b.  /etc is largely junk.  Executables have long since moved
into /sbin.  Pretty much everything else that's there belongs
(according to the original scheme, not the latter-day complications
inflicted by those who didn't understand) in /lib.

Unfortunately all the quick hacks and poorly-considered tweaks
of the past have long since been cast in stone by widespread
convention, so it's fruitless to try to clean any of this up.

Norman Wilson
Toronto ON


From jnc at mercury.lcs.mit.edu  Thu Oct 11 01:26:49 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 10 Oct 2018 11:26:49 -0400 (EDT)
Subject: [TUHS] The origin of /home
Message-ID: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>

    > From: Norman Wilson

    > Unfortunately all the quick hacks and poorly-considered tweaks of the
    > past have long since been cast in stone by widespread convention

There seem to be two kind of people in the world; i) those who cannot bring
themselves to change anything, and ii) those who change all sort of things,
usually with no good reason (perhaps just to be different).

The world of Unix seems to be thickly stocked with both.

    Noel


From clemc at ccc.com  Thu Oct 11 01:45:49 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 10 Oct 2018 11:45:49 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MZDwSXoatLFE=unzWzEVwYaRozooJ0pH+FMZ5kV70LRA@mail.gmail.com>

On Wed, Oct 10, 2018 at 11:27 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> There seem to be two kind of people in the world; i) those who cannot bring
> themselves to change anything, and ii) those who change all sort of things,
> usually with no good reason (perhaps just to be different).
>
> The world of Unix seems to be thickly stocked with both.
>
Demonstrating that we are, after all, human. ;-)

Although I suggest that there miight be a third kind, which I think might
be defined as usually those that have had some experience:  *"iii) Those
that have learned when its now wise to break from the past, but have
learned enough from it to change just the amount that needs to be changed
and no more."*

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181010/cc668a3c/attachment.html>

From david at kdbarto.org  Thu Oct 11 01:48:20 2018
From: david at kdbarto.org (David)
Date: Wed, 10 Oct 2018 08:48:20 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <CAC20D2MZDwSXoatLFE=unzWzEVwYaRozooJ0pH+FMZ5kV70LRA@mail.gmail.com>
References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
 <CAC20D2MZDwSXoatLFE=unzWzEVwYaRozooJ0pH+FMZ5kV70LRA@mail.gmail.com>
Message-ID: <358EC61B-9C6B-4238-9DC6-DE7C9049F4B3@kdbarto.org>


> On Oct 10, 2018, at 8:45 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Wed, Oct 10, 2018 at 11:27 AM Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> wrote:
> There seem to be two kind of people in the world; i) those who cannot bring
> themselves to change anything, and ii) those who change all sort of things,
> usually with no good reason (perhaps just to be different).
> 
> The world of Unix seems to be thickly stocked with both.
> Demonstrating that we are, after all, human. ;-) 
> 
> Although I suggest that there miight be a third kind, which I think might be defined as usually those that have had some experience:  "iii) Those that have learned when its now wise to break from the past, but have learned enough from it to change just the amount that needs to be changed and no more."
> 
> Clem
> 
> ᐧ

That third kind is so rare as to be unheard-of in common software circles.

	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181010/55b4cd11/attachment.html>

From arnold at skeeve.com  Thu Oct 11 02:26:01 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 10 Oct 2018 10:26:01 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <1539182625.28839.for-standards-violators@oclsc.org>
References: <1539182625.28839.for-standards-violators@oclsc.org>
Message-ID: <201810101626.w9AGQ1Wt028098@freefriends.org>

Norman Wilson <norman at oclsc.org> wrote:

> a.  It no longer matters a whit whether the (real) root file
> system can fit into a 5MB slice of the disk or the like, so
> just merge everything that spilled into /usr in the tiny-disk
> days back into the root where it belongs.

Plan 9 did exactly that, no?

Arnold


From gtaylor at tnetconsulting.net  Thu Oct 11 03:08:58 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 10 Oct 2018 11:08:58 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <1539182625.28839.for-standards-violators@oclsc.org>
References: <1539182625.28839.for-standards-violators@oclsc.org>
Message-ID: <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net>

On 10/10/2018 08:43 AM, Norman Wilson wrote:
> The first UNIX system I ever used, ca. 1980, had users' home directories 
> in /u.  I suspect it was that way (as suggested in some earlier messages) 
> just for storage management: separate file system from /usr.

I sort of like /u because I'm lazy and it's shorter than /usr or /home. 
}:-)

> I've carried /u around with me ever since to other systems I've set up 
> from scratch, except in my home environment where I've made a radical 
> departure: everything that isn't part of the base OS is in a tree 
> rooted at /con, so home directories are /con/u.  /con was `constant,' 
> inspired by /var, meaning stuff that should be preserved when the OS 
> is reinstalled--everything else should come from installation media or 
> configuration management.

Save for /etc, I like the spirit of /con.

> But in any case there's nothing especially novel about moving users' home 
> directories out of /usr, and since it's UNIX, nothing that says there has 
> to be any standard at all.

The wonderful thing about standards is that we have so many to choose from.

> On the systems I am currently paid to help run, most users have 
> home-directory names like /h/u12/c4/00/c4ntest.  There is no attempt to 
> glue together a single name hierarchy; we have in excess of 17000 users 
> so that would be something of a mess.  (I guess enormous directories 
> aren't the resource pigs they used to be,

I don't know if it's still the performance penalty that it used to be, 
or if the systems are just faster and / or better and overcoming said 
performance penalty of big directories.

> though symlinks are just as bad as they have ever been.)

Would you please elaborate on what you mean by that?

> There's the ~user shell syntax for those who like that; I don't, but 
> I have a little shell script in my personal bin directory so I can do 
> things like ls `home c4ntest`; it all just works.

I use tilde somewhat frequently, particularly when I want to manipulate 
contents from someone else's home directory.  (Usually copy something 
from my directory elsewhere when running as root.  I.e. scp a file to my 
home, then move said file to where it belongs, which my normal user 
can't write to.)

I've done some other things like your "home" script (or variables).  But 
I found them lacking when wanting to do file manipulations like above.

> I once thought of writing a paper entitled `/usr and /etc considered 
> harmful,' in which I would have proposed:

I would be interested in reading such a paper.

> a.  It no longer matters a whit whether the (real) root file system can 
> fit into a 5MB slice of the disk or the like, so just merge everything 
> that spilled into /usr in the tiny-disk days back into the root where 
> it belongs.

Are you talking about just things like /usr ~> /home or all other 
mounted file systems too?

I still see a reason to have other files systems, particularly if they 
come from block devices with different storage criteria.  I.e. RAID 1 
for root, RAID 5 for user data, RAID 0 for news spool & HTTP cache, etc.

> b.  /etc is largely junk.  Executables have long since moved into /sbin. 
> Pretty much everything else that's there belongs (according to the 
> original scheme, not the latter-day complications inflicted by those 
> who didn't understand) in /lib.

I never liked executable (think binaries vs scripts) in /etc or /lib. 
Maybe it's just my ignorance.

I've never had a really good grasp on the difference between bin and 
sbin.  Different people have different explanations.  Then there's 
Solaris sym-linking /bin to /usr/bin.

(I think) I get the /{bin,lib,…} vs /usr/{bin,lib,…} vs 
/usr/local/{bin,lib,…}.  At least / being what's required to boot strap 
and bring the system up to run level 1 (or comparable).  Then /usr being 
the rest of the things installed by the OS vendor.  With /usr/local 
being where the site would install all of their customizations.

To me, this is more about scoping of who's responsible for what and what 
it's primary purpose is.

Given Norman's comments, I could see how / and /usr could be merged back 
together.  Then I suppose that they could be restructured to remove /usr.

Question:  Where do the following things belong, if not in /etc?

  · passwd / shadow
  · group / gshadow
  · inittab

In other words, where do system configuration files live?  —  IMHO they 
should be separate from the location of the files the programs consist 
of.  Much like /con above allowing most everything else to be replaced 
wholesale.

> Unfortunately all the quick hacks and poorly-considered tweaks of the 
> past have long since been cast in stone by widespread convention, so 
> it's fruitless to try to clean any of this up.

That doesn't make it any less of a thought experiment or enlightening 
discussion.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181010/20595cbe/attachment.bin>

From norman at oclsc.org  Thu Oct 11 05:21:27 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 10 Oct 2018 15:21:27 -0400
Subject: [TUHS] Software Archeology: QED
Message-ID: <1539199293.4401.for-standards-violators@oclsc.org>

Leah Neukirchen:

  I tried contacting David Tilbrook several times and got no replies.

  I think some people around Toronto still use qed, but they seem to be
  very secretive about it.

====

David is likely well-retired by now, but I don't really know.
Even though I walk within a block of his house fairly often,
we've never really been consistently in touch.

But he was responsible for a distinct branch of the qed that
originated at the University of Toronto in the late 1970s
(same one Rob supplied).  Certainly worth tracking down.

I don't know your definitions of `people around Toronto' or
`secretive.'  I still use qed daily; my copy is one I've been
carrying around, and occasionally tweaking, since my time at
Caltech (where I got it from Rob).  I'll send Arnold a copy.
I'm really tired both of having to recompile it (and deal with
yet another bit of obsolete-C assumption that no previous
compiler or C library has shown up) now and then, and with
its private variant of regular expressions, so I keep threatening
(mainly to myself) to rewrite it in Python, but I have no idea
whether I'll ever get around to that.  If I do I suspect I'll
throw away some of the programmability hooks, which I never use,
and perhaps extend it here and there (I really want nesting
globals, and they're not that hard to do--I did them in my
half-baked personal mail reader, which has an ed-like interface).

I don't know offhand of anyone else around Toronto using my
branch of qed.  I do know of a couple of friends in California,
one who left Caltech before I did but is now back there, another
elsewhere in Los Angeles, who still use my version at least
occasionally.  It wouldn't surprise me if there were people
around Toronto who use Tilbrook's branch, since it was part
of his qef toolkit and he introduced several companies to it
when consulting for them; but I don't know of any specifics.

None of which is as archaeologically interesting as the
non-UNIX qeds, of course.

Norman Wilson
Toronto ON


From usotsuki at buric.co  Thu Oct 11 10:22:34 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 10 Oct 2018 20:22:34 -0400 (EDT)
Subject: [TUHS] The origin of /home
In-Reply-To: <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net>
References: <1539182625.28839.for-standards-violators@oclsc.org>
 <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.02.1810102014060.92712@frieza.hoshinet.org>

On Wed, 10 Oct 2018, Grant Taylor via TUHS wrote:

> On 10/10/2018 08:43 AM, Norman Wilson wrote:
>
>> I once thought of writing a paper entitled `/usr and /etc considered 
>> harmful,' in which I would have proposed:
>
> I would be interested in reading such a paper.
>
>> a.  It no longer matters a whit whether the (real) root file system can fit 
>> into a 5MB slice of the disk or the like, so just merge everything that 
>> spilled into /usr in the tiny-disk days back into the root where it 
>> belongs.
>>
>> b.  /etc is largely junk.  Executables have long since moved into /sbin. 
>> Pretty much everything else that's there belongs (according to the original 
>> scheme, not the latter-day complications inflicted by those who didn't 
>> understand) in /lib.
>
> I never liked executable (think binaries vs scripts) in /etc or /lib. Maybe 
> it's just my ignorance.
>
> I've never had a really good grasp on the difference between bin and sbin. 
> Different people have different explanations.  Then there's Solaris 
> sym-linking /bin to /usr/bin.
>
> (I think) I get the /{bin,lib,…} vs /usr/{bin,lib,…} vs 
> /usr/local/{bin,lib,…}.  At least / being what's required to boot strap and 
> bring the system up to run level 1 (or comparable).  Then /usr being the rest 
> of the things installed by the OS vendor.  With /usr/local being where the 
> site would install all of their customizations.
>
> To me, this is more about scoping of who's responsible for what and what it's 
> primary purpose is.
>
> Given Norman's comments, I could see how / and /usr could be merged back 
> together.  Then I suppose that they could be restructured to remove /usr.
>
> Question:  Where do the following things belong, if not in /etc?
>
> · passwd / shadow
> · group / gshadow
> · inittab
>
> In other words, where do system configuration files live?  —  IMHO they 
> should be separate from the location of the files the programs consist of. 
> Much like /con above allowing most everything else to be replaced wholesale.

Here is how I understand the current system is intended to work:

1. /sbin for binaries for use by root that must be available before the 
system is fully brought up (and for an emergency copy of the Bourne 
shell), which should all be linked static.

2. /bin for binaries for use by all users that must be available before 
the system is fully brought up.  These may be linked dynamic.

3. /lib for libraries which are needed for binaries in /bin to work, and 
for kernel plugin modules in /lib/modules.

4. /usr/sbin for other binaries in the base system to be available to 
root only.

5. /usr/bin for other binaries in the base system to be available to all 
users.

6. /etc for global configuration files used by the kernel and the base OS.

7. /opt/PACKAGE contains a full bin, etc, lib etc. folder tree for every 
non-base package (I would put almost everything here, including X Window 
in /opt/X11/bin etc.).

8. /home as the base for all user folders.

(Scripts and binaries are not differentiated in this system.)

I think I would be prone to do a cleanup of the system to isolate 
everything into some form of the above.  Just my opinion.

-uso.

From davida at pobox.com  Thu Oct 11 12:33:30 2018
From: davida at pobox.com (David Arnold)
Date: Thu, 11 Oct 2018 13:33:30 +1100
Subject: [TUHS] The origin of /home
In-Reply-To: <alpine.BSF.2.02.1810102014060.92712@frieza.hoshinet.org>
References: <1539182625.28839.for-standards-violators@oclsc.org>
 <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1810102014060.92712@frieza.hoshinet.org>
Message-ID: <9274C5DE-5087-4295-A765-C20BA29FCC2E@pobox.com>

Some (most?) Linux distributions have followed Solaris’ lead, and put all of /bin into /usr/bin, and /sbin into /usr/sbin, and then symlinked /bin to /usr/bin (and /sbin to /usr/sbin) to make everything effectively available in both locations.

Some rationale here: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ <https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>

Most (all?) Linux distributions never followed the "should be static, needed for boot to runlevel 1", logic for /bin & /sbin anyway, so the locations were largely based on a perception of traditional or most common location anyway.  sh was thus in /bin, while env was in /usr/bin, for example.


d

> Here is how I understand the current system is intended to work:
> 1. /sbin for binaries for use by root that must be available before the system is fully brought up (and for an emergency copy of the Bourne shell), which should all be linked static.
> 
> 2. /bin for binaries for use by all users that must be available before the system is fully brought up.  These may be linked dynamic.
> 
> 3. /lib for libraries which are needed for binaries in /bin to work, and for kernel plugin modules in /lib/modules.
> 
> 4. /usr/sbin for other binaries in the base system to be available to root only.
> 
> 5. /usr/bin for other binaries in the base system to be available to all users.
> 
> 6. /etc for global configuration files used by the kernel and the base OS.
> 
> 7. /opt/PACKAGE contains a full bin, etc, lib etc. folder tree for every non-base package (I would put almost everything here, including X Window in /opt/X11/bin etc.).
> 
> 8. /home as the base for all user folders.
> 
> (Scripts and binaries are not differentiated in this system.)
> 
> I think I would be prone to do a cleanup of the system to isolate everything into some form of the above.  Just my opinion.
> 
> -uso.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181011/909c77a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181011/909c77a2/attachment.sig>

From lyndon at orthanc.ca  Fri Oct 12 05:10:43 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 11 Oct 2018 12:10:43 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <201810101626.w9AGQ1Wt028098@freefriends.org>
References: <1539182625.28839.for-standards-violators@oclsc.org>
 <201810101626.w9AGQ1Wt028098@freefriends.org>
Message-ID: <7aa20b6d9fcbce7d@orthanc.ca>

arnold at skeeve.com writes:
> Norman Wilson <norman at oclsc.org> wrote:

> > a.  It no longer matters a whit whether the (real) root file
> > system can fit into a 5MB slice of the disk or the like, so
> > just merge everything that spilled into /usr in the tiny-disk
> > days back into the root where it belongs.

> Plan 9 did exactly that, no?

Yes, but no.  With namespaces, There Is No Root.  You can pretzel up
the filesystem to your heart's content, and nobody else will ever know.

But on the filserver, there are some required conventions.

* /usr is for home directories

* /bin is an empty mountpoint

* /sys contains "the system" in the form of reference files, configs,
  source code, etc.

* /lib is a semi-sparse directory tree that non-system programs can use
  to store data/configs/etc.

* every CPU architecture gets its own top level directory (e.g.
  /386,  /sparc, ...)

But the fileserver conventions are only there because the cpu/terminal
diskless boot scripts need a basically consistent fileserver
environment to do their initial bootstrap from.  After that, the
namespace is your to pervert at your pleasure.  And such perversion
is actively encouraged :-)

http://doc.cat-v.org/plan_9/4th_edition/papers/9 (e.g. "Implementation of Name Spaces")

http://doc.cat-v.org/plan_9/4th_edition/papers/names

--lyndon


From dave at horsfall.org  Fri Oct 12 06:58:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 12 Oct 2018 07:58:49 +1100 (EST)
Subject: [TUHS] In memoriam: Dennis Ritchie
Message-ID: <alpine.BSF.2.21.9999.1810120755350.45822@aneurin.horsfall.org>

Co-inventor of Unix, we lost him in 2011.

-- Dave


From dave at horsfall.org  Fri Oct 12 10:15:17 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 12 Oct 2018 11:15:17 +1100 (EST)
Subject: [TUHS] The origin of /home
In-Reply-To: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1810121111090.45822@aneurin.horsfall.org>

On Wed, 10 Oct 2018, Noel Chiappa wrote:

> There seem to be two kind of people in the world; i) those who cannot 
> bring themselves to change anything, and ii) those who change all sort 
> of things, usually with no good reason (perhaps just to be different).

I tend to fall into the former category; I don't change anything unless 
there's a damned good reason e.g. a security update (which doesn't seem to 
happen often, unlike a certain other OS).

-- Dave


From michael at kjorling.se  Sat Oct 13 16:58:18 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 13 Oct 2018 06:58:18 +0000
Subject: [TUHS] The origin of /home
In-Reply-To: <CAC20D2MZDwSXoatLFE=unzWzEVwYaRozooJ0pH+FMZ5kV70LRA@mail.gmail.com>
References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu>
 <CAC20D2MZDwSXoatLFE=unzWzEVwYaRozooJ0pH+FMZ5kV70LRA@mail.gmail.com>
Message-ID: <20181013065818.spbnl6wazdlvpvtt@h-174-65.A328.priv.bahnhof.se>

On 10 Oct 2018 11:45 -0400, from clemc at ccc.com (Clem Cole):
>> There seem to be two kind of people in the world; i) those who cannot bring
>> themselves to change anything, and ii) those who change all sort of things,
>> usually with no good reason (perhaps just to be different).
> 
> Although I suggest that there miight be a third kind, which I think might
> be defined as usually those that have had some experience:  *"iii) Those
> that have learned when its now wise to break from the past, but have
> learned enough from it to change just the amount that needs to be changed
> and no more."*

I know I'm a bit late to the party here too, but from personal
experience, I'd add *"iv) those who change all sort of things, and
thereby end up with something eerily similar to that which was
recently changed away from"*.

Case in point: "the cloud".

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From wkt at tuhs.org  Tue Oct 16 05:56:22 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 16 Oct 2018 05:56:22 +1000
Subject: [TUHS] Ultrix Tape: Block Size?
Message-ID: <20181015195622.GB25749@minnie.tuhs.org>

All, I received this request from Matthew who isn't subscribed to either
the TUHS or cctalk lists. He knows how to read the lists archives. Many
thanks for any help you can provide.
Cheers, Warren

----- Forwarded message from Matthew Whitehead -----

Date: Mon, 15 Oct 2018 08:25:39 -0400
From: Matthew Whitehead
Subject: Ultrix Tape Blocks

   Warren,
     I wonder if you can give me a referral. I want to install Ultrix-32
   on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
   files are on your archive, but I need to know the block size for each
   of the many files; it can vary a lot.
   Who might be able to help me with this?
   Matthew Whitehead

----- End forwarded message -----


From clemc at ccc.com  Tue Oct 16 07:00:27 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 15 Oct 2018 17:00:27 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <20181015195622.GB25749@minnie.tuhs.org>
References: <20181015195622.GB25749@minnie.tuhs.org>
Message-ID: <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>

Be careful, TK-50 is different than 9-track.  It's a streamer tape like
QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
blovk size if just how a DMA is done.  I recommend that you pre-fetch the
read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
the output to the reader (tar/cpio or the like) [if that fails try
obs=1b].   This should work well as can (TK-50 overall suck - don't set
your hopes high on anything with them -- they were DECtape from a
realiabilty standpoint, they were different from the reset of the world,
the performance was poor and they were expensive).

Anyway, by using dd or the like a front end, it will allow the read
streamer to read as fast as it can.  The problem is that the way it works
under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
anything more than 64K on a VAX (or PDP-11) will not help because of the
dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
Tru64 on a Alpha), you can try using really large ibs sizes depending on
your physical memory size.

BTW: What will help the most is actually finding a copy of the old
double-dd program (from the UUNET archives) which forks off two child
procees to perform the actual I/O and alternates between the two processes
via pipe between them and controller - so one dd process is reading when
the other dd process is writing.  [It used to be called: ddd before the Gnu
guys grabbed that name for the debugger].   The command line might be
something like:   ddd ibs=64k obs=20b | tar xvpf -

FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
semaphore that I should still have kicking around.   At one point when I
was dealing with streamer tapes for backup, I definitely ran it on Tru64
and FreeBSD, but  I've forgotten where Ultrix fell.
ᐧ

On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey <wkt at tuhs.org> wrote:

> All, I received this request from Matthew who isn't subscribed to either
> the TUHS or cctalk lists. He knows how to read the lists archives. Many
> thanks for any help you can provide.
> Cheers, Warren
>
> ----- Forwarded message from Matthew Whitehead -----
>
> Date: Mon, 15 Oct 2018 08:25:39 -0400
> From: Matthew Whitehead
> Subject: Ultrix Tape Blocks
>
>    Warren,
>      I wonder if you can give me a referral. I want to install Ultrix-32
>    on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>    files are on your archive, but I need to know the block size for each
>    of the many files; it can vary a lot.
>    Who might be able to help me with this?
>    Matthew Whitehead
>
> ----- End forwarded message -----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/8003688e/attachment.html>

From clemc at ccc.com  Tue Oct 16 07:01:42 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 15 Oct 2018 17:01:42 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
Message-ID: <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>

#$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
ᐧ

On Mon, Oct 15, 2018 at 5:00 PM Clem Cole <clemc at ccc.com> wrote:

> Be careful, TK-50 is different than 9-track.  It's a streamer tape like
> QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
> blovk size if just how a DMA is done.  I recommend that you pre-fetch the
> read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
> the output to the reader (tar/cpio or the like) [if that fails try
> obs=1b].   This should work well as can (TK-50 overall suck - don't set
> your hopes high on anything with them -- they were DECtape from a
> realiabilty standpoint, they were different from the reset of the world,
> the performance was poor and they were expensive).
>
> Anyway, by using dd or the like a front end, it will allow the read
> streamer to read as fast as it can.  The problem is that the way it works
> under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
> anything more than 64K on a VAX (or PDP-11) will not help because of the
> dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
> Tru64 on a Alpha), you can try using really large ibs sizes depending on
> your physical memory size.
>
> BTW: What will help the most is actually finding a copy of the old
> double-dd program (from the UUNET archives) which forks off two child
> procees to perform the actual I/O and alternates between the two processes
> via pipe between them and controller - so one dd process is reading when
> the other dd process is writing.  [It used to be called: ddd before the
> Gnu guys grabbed that name for the debugger].   The command line might be
> something like:   ddd ibs=64k obs=20b | tar xvpf -
>
> FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
> semaphore that I should still have kicking around.   At one point when I
> was dealing with streamer tapes for backup, I definitely ran it on Tru64
> and FreeBSD, but  I've forgotten where Ultrix fell.
> ᐧ
>
> On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey <wkt at tuhs.org> wrote:
>
>> All, I received this request from Matthew who isn't subscribed to either
>> the TUHS or cctalk lists. He knows how to read the lists archives. Many
>> thanks for any help you can provide.
>> Cheers, Warren
>>
>> ----- Forwarded message from Matthew Whitehead -----
>>
>> Date: Mon, 15 Oct 2018 08:25:39 -0400
>> From: Matthew Whitehead
>> Subject: Ultrix Tape Blocks
>>
>>    Warren,
>>      I wonder if you can give me a referral. I want to install Ultrix-32
>>    on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>>    files are on your archive, but I need to know the block size for each
>>    of the many files; it can vary a lot.
>>    Who might be able to help me with this?
>>    Matthew Whitehead
>>
>> ----- End forwarded message -----
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/e893d5b5/attachment.html>

From imp at bsdimp.com  Tue Oct 16 07:34:09 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 15 Oct 2018 15:34:09 -0600
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
Message-ID: <CANCZdfojLahTsUnfoe8sv-SBr1Fm=QwMpnj9wuqz9ip0S+Km=w@mail.gmail.com>

I'm glad you corrected because when they worked, they were awesome. When
they didn't, life had a lot of swearing in it... And when I was sysadmin
for the MicroVAX II that had them, I swore like a sailor....

Warner

On Mon, Oct 15, 2018 at 3:04 PM Clem Cole <clemc at ccc.com> wrote:

> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
>
> On Mon, Oct 15, 2018 at 5:00 PM Clem Cole <clemc at ccc.com> wrote:
>
>> Be careful, TK-50 is different than 9-track.  It's a streamer tape like
>> QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
>> blovk size if just how a DMA is done.  I recommend that you pre-fetch the
>> read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
>> the output to the reader (tar/cpio or the like) [if that fails try
>> obs=1b].   This should work well as can (TK-50 overall suck - don't set
>> your hopes high on anything with them -- they were DECtape from a
>> realiabilty standpoint, they were different from the reset of the world,
>> the performance was poor and they were expensive).
>>
>> Anyway, by using dd or the like a front end, it will allow the read
>> streamer to read as fast as it can.  The problem is that the way it works
>> under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
>> anything more than 64K on a VAX (or PDP-11) will not help because of the
>> dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
>> Tru64 on a Alpha), you can try using really large ibs sizes depending on
>> your physical memory size.
>>
>> BTW: What will help the most is actually finding a copy of the old
>> double-dd program (from the UUNET archives) which forks off two child
>> procees to perform the actual I/O and alternates between the two processes
>> via pipe between them and controller - so one dd process is reading when
>> the other dd process is writing.  [It used to be called: ddd before the
>> Gnu guys grabbed that name for the debugger].   The command line might be
>> something like:   ddd ibs=64k obs=20b | tar xvpf -
>>
>> FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
>> semaphore that I should still have kicking around.   At one point when I
>> was dealing with streamer tapes for backup, I definitely ran it on Tru64
>> and FreeBSD, but  I've forgotten where Ultrix fell.
>> ᐧ
>>
>> On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey <wkt at tuhs.org> wrote:
>>
>>> All, I received this request from Matthew who isn't subscribed to either
>>> the TUHS or cctalk lists. He knows how to read the lists archives. Many
>>> thanks for any help you can provide.
>>> Cheers, Warren
>>>
>>> ----- Forwarded message from Matthew Whitehead -----
>>>
>>> Date: Mon, 15 Oct 2018 08:25:39 -0400
>>> From: Matthew Whitehead
>>> Subject: Ultrix Tape Blocks
>>>
>>>    Warren,
>>>      I wonder if you can give me a referral. I want to install Ultrix-32
>>>    on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>>>    files are on your archive, but I need to know the block size for each
>>>    of the many files; it can vary a lot.
>>>    Who might be able to help me with this?
>>>    Matthew Whitehead
>>>
>>> ----- End forwarded message -----
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/ff6667f6/attachment.html>

From aaron at aaronsplace.co.uk  Tue Oct 16 07:52:40 2018
From: aaron at aaronsplace.co.uk (Aaron Jackson)
Date: Mon, 15 Oct 2018 22:52:40 +0100
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <20181015195622.GB25749@minnie.tuhs.org>
References: <20181015195622.GB25749@minnie.tuhs.org>
Message-ID: <87woqiubbr.fsf@walrus.rhwyd.co.uk>

If it is anything like installing NetBSD, which I have done on a
VAXstation with a DLT4 drive, it should be 512 byte.

So, while I do not know for sure for Ultrix and MicroVAX, 512 is
probably a good starting point? Hopefully someone else will *actually*
know.

Aaron



Warren Toomey via cctalk writes:

> All, I received this request from Matthew who isn't subscribed to either
> the TUHS or cctalk lists. He knows how to read the lists archives. Many
> thanks for any help you can provide.
> Cheers, Warren
>
> ----- Forwarded message from Matthew Whitehead -----
>
> Date: Mon, 15 Oct 2018 08:25:39 -0400
> From: Matthew Whitehead
> Subject: Ultrix Tape Blocks
>
>    Warren,
>      I wonder if you can give me a referral. I want to install Ultrix-32
>    on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>    files are on your archive, but I need to know the block size for each
>    of the many files; it can vary a lot.
>    Who might be able to help me with this?
>    Matthew Whitehead
>
> ----- End forwarded message -----


--
Aaron Jackson - M6PIU
http://aaronsplace.co.uk/


From crossd at gmail.com  Tue Oct 16 08:18:46 2018
From: crossd at gmail.com (Dan Cross)
Date: Mon, 15 Oct 2018 18:18:46 -0400
Subject: [TUHS] Paul Allen dead at 65.
Message-ID: <CAEoi9W4SbJZHO0TOuNn=fQXvc=Xs=rigMM4rkbY4H3xP2URhxA@mail.gmail.com>

I just saw this headline. Microsoft co-founder Paul Allen dead of cancer,
aged 65. Relevancy to TUHS as Microsoft has been both a competitor to and
supporter of both Unix and (much more recently) Linux.

Allen also funded the Living Computer Museum in Seattle, where one can log
into a real PDP-11/70 running 7th Edition Unix.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/f047ac1e/attachment.html>

From norman at oclsc.org  Tue Oct 16 09:08:24 2018
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 15 Oct 2018 19:08:24 -0400 (EDT)
Subject: [TUHS]  Paul Allen dead at 65.
Message-ID: <20181015230824.8BDE54422F@lignose.oclsc.org>

Dan Cross:

  Allen also funded the Living Computer Museum in Seattle, where one can log
  into a real PDP-11/70 running 7th Edition Unix.

And see a real live PDP-7, and many other marvellous artifacts.
Their basic idea is to be a museum of history that runs.  Well
worth a visit when in Seattle.

Norman Wilson
Toronto ON


From akosela at andykosela.com  Tue Oct 16 09:13:57 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 15 Oct 2018 18:13:57 -0500
Subject: [TUHS] Paul Allen dead at 65.
In-Reply-To: <CAEoi9W4SbJZHO0TOuNn=fQXvc=Xs=rigMM4rkbY4H3xP2URhxA@mail.gmail.com>
References: <CAEoi9W4SbJZHO0TOuNn=fQXvc=Xs=rigMM4rkbY4H3xP2URhxA@mail.gmail.com>
Message-ID: <CALMnNGiqmXnW=ofHGcM++kP-qFcSDkYA0VDFhHHSS6dSQ0aOpA@mail.gmail.com>

On Monday, October 15, 2018, Dan Cross <crossd at gmail.com> wrote:

> I just saw this headline. Microsoft co-founder Paul Allen dead of cancer,
> aged 65. Relevancy to TUHS as Microsoft has been both a competitor to and
> supporter of both Unix and (much more recently) Linux.
>
> Allen also funded the Living Computer Museum in Seattle, where one can log
> into a real PDP-11/70 running 7th Edition Unix.
>
>
>
He was always the "good" side of Microsoft to me.  He left the company over
disagreements with Bill in early 80s though.

Great loss.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/f7cbb7c1/attachment.html>

From rminnich at gmail.com  Tue Oct 16 10:43:52 2018
From: rminnich at gmail.com (ron minnich)
Date: Mon, 15 Oct 2018 17:43:52 -0700
Subject: [TUHS] Paul Allen dead at 65.
In-Reply-To: <CALMnNGiqmXnW=ofHGcM++kP-qFcSDkYA0VDFhHHSS6dSQ0aOpA@mail.gmail.com>
References: <CAEoi9W4SbJZHO0TOuNn=fQXvc=Xs=rigMM4rkbY4H3xP2URhxA@mail.gmail.com>
 <CALMnNGiqmXnW=ofHGcM++kP-qFcSDkYA0VDFhHHSS6dSQ0aOpA@mail.gmail.com>
Message-ID: <CAP6exYJ56fxVtrL+im4aYz+Oi0qMwHscdsmZ4NDqcBQMb8SUcA@mail.gmail.com>

A terrible loss IMHO, just considering StratoLaunch alone.

On Mon, Oct 15, 2018 at 4:22 PM Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Monday, October 15, 2018, Dan Cross <crossd at gmail.com> wrote:
>
>> I just saw this headline. Microsoft co-founder Paul Allen dead of cancer,
>> aged 65. Relevancy to TUHS as Microsoft has been both a competitor to and
>> supporter of both Unix and (much more recently) Linux.
>>
>> Allen also funded the Living Computer Museum in Seattle, where one can
>> log into a real PDP-11/70 running 7th Edition Unix.
>>
>>
>>
> He was always the "good" side of Microsoft to me.  He left the company
> over disagreements with Bill in early 80s though.
>
> Great loss.
>
> --Andy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181015/9ce64c1c/attachment.html>

From dave at horsfall.org  Tue Oct 16 14:35:23 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 16 Oct 2018 15:35:23 +1100 (EST)
Subject: [TUHS] In memoriam: Jon Postel
Message-ID: <alpine.BSF.2.21.9999.1810161531500.70955@aneurin.horsfall.org>

We lost Jon Postel, regarded as the Father of the Internet (due to his many 
RFCs) on this day in 1998.

-- Dave


From jnc at mercury.lcs.mit.edu  Tue Oct 16 21:13:07 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 16 Oct 2018 07:13:07 -0400 (EDT)
Subject: [TUHS] In memoriam: Jon Postel
Message-ID: <20181016111307.26DD318C08D@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > We lost Jon Postel, regarded as the Father of the Internet

Vint and Bob Kahn might disagree with that that... :-)

    > (due to his many RFCs)

You need to distinguish between the many for which he was an editor (e.g. IP,
TCP, etc), and the (relatively few, compared to the others) which he actually
wrote himself, e.g. RFC-925, "Multi-LAN address resolution".

Not that he didn't make absolutely huge contributions, but we should be
accurate.

	Noel



From kranjbar at yahoo.com  Wed Oct 17 00:01:00 2018
From: kranjbar at yahoo.com (Kaveh Ranjbar)
Date: Tue, 16 Oct 2018 16:01:00 +0200
Subject: [TUHS] In memoriam: Jon Postel
In-Reply-To: <alpine.BSF.2.21.9999.1810161531500.70955@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1810161531500.70955@aneurin.horsfall.org>
Message-ID: <71AE0424-34ED-4069-B4FE-3E233896FACD@yahoo.com>


> On 16 Oct 2018, at 06:35, Dave Horsfall <dave at horsfall.org> wrote:
> 
> We lost Jon Postel, regarded as the Father of the Internet (due to his many RFCs) on this day in 1998.
> ...

RIPE 77 is in action right now in Amsterdam and DFK did a short talk titled "Why It is Important to Remember Jon Postel” during the second plenary session of today.

You can find a link to the video at https://ripe77.ripe.net/programme/meeting-plan/plenary/#tues2

Daniel’s talk starts at 54:42 in the current video, I’ve been told the video will be cut to reflect each presentation individually in a few days time.

— Kaveh



From jnc at mercury.lcs.mit.edu  Wed Oct 17 00:39:11 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 16 Oct 2018 10:39:11 -0400 (EDT)
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
Message-ID: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > We lost ... on this day

An email from someone on a related topic has reminded me of someone else you
should make sure is only your list (not sure if you already have him):
J. C. R. Licklider; we lost him on June 26, 1990.

He didn't write much code himself, but the work of people he funded (e.g.
Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
vision has led to today's computerized, information-rich world. For people who
only know today's networked world, the change from what came before, and thus
his impact on the world (since his ideas and the work of people he sponsored
led, directly and indirectly, to much of it), is probably hard to truly
fathom.

He is, in my estimation, one of the most important and influential computer
scientists of all. I wonder how many computer science people had more of an
impact; the list is surely pretty short. Babbage; Turing; who else?

	Noel


From clemc at ccc.com  Wed Oct 17 00:41:43 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 16 Oct 2018 10:41:43 -0400
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
In-Reply-To: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
Message-ID: <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@mail.gmail.com>

+1
ᐧ

On Tue, Oct 16, 2018 at 10:40 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall
>
>     > We lost ... on this day
>
> An email from someone on a related topic has reminded me of someone else
> you
> should make sure is only your list (not sure if you already have him):
> J. C. R. Licklider; we lost him on June 26, 1990.
>
> He didn't write much code himself, but the work of people he funded (e.g.
> Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
> vision has led to today's computerized, information-rich world. For people
> who
> only know today's networked world, the change from what came before, and
> thus
> his impact on the world (since his ideas and the work of people he
> sponsored
> led, directly and indirectly, to much of it), is probably hard to truly
> fathom.
>
> He is, in my estimation, one of the most important and influential computer
> scientists of all. I wonder how many computer science people had more of an
> impact; the list is surely pretty short. Babbage; Turing; who else?
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181016/c9442bc9/attachment.html>

From david at kdbarto.org  Wed Oct 17 01:14:31 2018
From: david at kdbarto.org (David)
Date: Tue, 16 Oct 2018 08:14:31 -0700
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
In-Reply-To: <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@mail.gmail.com>
References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
 <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@mail.gmail.com>
Message-ID: <2187F56D-F0F6-4756-B0F1-4AB813A11E4D@kdbarto.org>

The book “where wizards stay up late”, mentioned here earlier, is an excellent read
and shows how J. C. R. Licklider brought it all together.

	David

> On Oct 16, 2018, at 7:41 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> +1
> ᐧ
> 
> On Tue, Oct 16, 2018 at 10:40 AM Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> wrote:
>     > From: Dave Horsfall
> 
>     > We lost ... on this day
> 
> An email from someone on a related topic has reminded me of someone else you
> should make sure is only your list (not sure if you already have him):
> J. C. R. Licklider; we lost him on June 26, 1990.
> 
> He didn't write much code himself, but the work of people he funded (e.g.
> Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
> vision has led to today's computerized, information-rich world. For people who
> only know today's networked world, the change from what came before, and thus
> his impact on the world (since his ideas and the work of people he sponsored
> led, directly and indirectly, to much of it), is probably hard to truly
> fathom.
> 
> He is, in my estimation, one of the most important and influential computer
> scientists of all. I wonder how many computer science people had more of an
> impact; the list is surely pretty short. Babbage; Turing; who else?
> 
>         Noel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181016/a89e2d36/attachment.html>

From crossd at gmail.com  Wed Oct 17 02:08:11 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 16 Oct 2018 12:08:11 -0400
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
In-Reply-To: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W6hpCCumqVnU2N+kkjURrOV+EHJD-YLUAO_jV2Z5JGEtA@mail.gmail.com>

On Tue, Oct 16, 2018 at 10:40 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall
>
>     > We lost ... on this day
>
> An email from someone on a related topic has reminded me of someone else
> you
> should make sure is only your list (not sure if you already have him):
> J. C. R. Licklider; we lost him on June 26, 1990.
>
> He didn't write much code himself, but the work of people he funded (e.g.
> Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
> vision has led to today's computerized, information-rich world. For people
> who
> only know today's networked world, the change from what came before, and
> thus
> his impact on the world (since his ideas and the work of people he
> sponsored
> led, directly and indirectly, to much of it), is probably hard to truly
> fathom.
>
> He is, in my estimation, one of the most important and influential computer
> scientists of all. I wonder how many computer science people had more of an
> impact; the list is surely pretty short. Babbage; Turing; who else?
>

Perhaps I've mentioned this short movie from 1971 before, but it's well
worth a watch: "Computer Networks: The Heralds of Resource Sharing" (
https://www.youtube.com/watch?v=GjZ7ktIlSM0)

Licklider, Khan and other players from the early days of the ARPAnet figure
prominently. It's amazingly prescient.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181016/8d5e02fb/attachment.html>

From steffen at sdaoden.eu  Wed Oct 17 02:10:17 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 16 Oct 2018 18:10:17 +0200
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
In-Reply-To: <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@mail.gmail.com>
References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
 <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@mail.gmail.com>
Message-ID: <20181016161017.iKPHz%steffen@sdaoden.eu>

Clem Cole wrote in <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg@\
mail.gmail.com>:
 |+1

I have indeed watched "Computer Networks: The Heralds of Resource
Sharing"[1] again today, at least in parts, after i heard that
Paul Allen died.  And John Postel died exactly twenty years ago,
i have read his name a thousand times.

  [1] https://www.youtube.com/watch?v=GjZ7ktIlSM0

 |On Tue, Oct 16, 2018 at 10:40 AM Noel Chiappa <[1]jnc at mercury.lcs.mit.ed\
 |u[/1]> wrote:
 |
 |  [1] mailto:jnc at mercury.lcs.mit.edu
 |
 ||    > From: Dave Horsfall
 |
 ||    > We lost ... on this day
 |
 ||An email from someone on a related topic has reminded me of someone \
 ||else you
 ||should make sure is only your list (not sure if you already have him):
 ||J. C. R. Licklider; we lost him on June 26, 1990.
 |
 ||He didn't write much code himself, but the work of people he funded (e.g.
 ||Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
 ||vision has led to today's computerized, information-rich world. For \
 ||people who
 ||only know today's networked world, the change from what came before, \
 ||and thus
 ||his impact on the world (since his ideas and the work of people he \
 ||sponsored
 ||led, directly and indirectly, to much of it), is probably hard to truly
 ||fathom.
 |
 ||He is, in my estimation, one of the most important and influential \
 ||computer
 ||scientists of all. I wonder how many computer science people had more \
 ||of an
 ||impact; the list is surely pretty short. Babbage; Turing; who else?
 |
 ||        Noel
 --End of <CAC20D2P_OJhV7QG=uJwnk0Asn-z9h9k3BZqaeTZPQzGtPwoYVg at mail.gmail\
 .com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From paul.winalski at gmail.com  Wed Oct 17 02:57:58 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 16 Oct 2018 12:57:58 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
Message-ID: <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>

On 10/15/18, Clem Cole <clemc at ccc.com> wrote:
> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
The original DECtape was extremely reliable.  Not so the TK50.
Calling it "DECtape II" was an insult to the original DECtape.  The
problem wasn't so much the drive itself, but the controller.  In an
effort to reduce costs, DEC used a controller that had insufficient
buffering capability for a streaming, block-replacement tape device
such as the TK50.  TK50s were prone to both data-late and overrun
errors.

The block size is almost certainly 512 bytes.

-Paul W.


From beebe at math.utah.edu  Wed Oct 17 02:58:15 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 16 Oct 2018 10:58:15 -0600
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
Message-ID: <CMM.0.95.0.1539709095.beebe@gamma.math.utah.edu>

For more information on J. C. R. Licklider, see these books

	Cyber reader
	ISBN 0-7148-4071-8

	The Innovators: How a Group of Hackers, Geniuses and Geeks
	Created the Digital Revolution
	ISBN 1-4711-3879-8

	The Dream Machine: J. C. R. Licklider and the Revolution That
	Made Computing Personal
	ISBN 0-670-89976-3

	The computing universe: a journey through a revolution
	ISBN 0-521-76645-1

Detailed BibTeX entries, with table of contents information, can be
found at

	http://www.math.utah.edu/pub/tex/bib/master.html
	http://www.math.utah.edu/pub/bibnet/authors/t/turing-alan-mathison.html
	http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.html

(change .html to .bib for a BibTeX file).

A Library of Congress search found another book, by Licklider himself:

	Libraries of the future
	xvii + 219 pp
	Bolt, Beranek, and Newman, Inc., Cambridge, MA (1965)
	LCCN: Z699 .L5

Given its age and small publisher, I suspect that it may be hard to
find; I have not seen it myself.

-------------------------------------------------------------------------------
- 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 pechter at gmail.com  Wed Oct 17 03:23:42 2018
From: pechter at gmail.com (William Pechter)
Date: Tue, 16 Oct 2018 13:23:42 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
Message-ID: <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>

DEC Tape II was the serial driven TU58.
The TK50 was CompacTape or something like that.  It was the predecessor of a number of square tapes...

See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape

Bill

-----Original Message-----
From: Paul Winalski <paul.winalski at gmail.com>
To: Clem Cole <clemc at ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>, cctalk at classiccmp.org
Sent: Tue, 16 Oct 2018 13:14
Subject: Re: [TUHS] Ultrix Tape: Block Size?

On 10/15/18, Clem Cole <clemc at ccc.com> wrote:
> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
The original DECtape was extremely reliable.  Not so the TK50.
Calling it "DECtape II" was an insult to the original DECtape.  The
problem wasn't so much the drive itself, but the controller.  In an
effort to reduce costs, DEC used a controller that had insufficient
buffering capability for a streaming, block-replacement tape device
such as the TK50.  TK50s were prone to both data-late and overrun
errors.

The block size is almost certainly 512 bytes.

-Paul W.


From clemc at ccc.com  Wed Oct 17 03:24:12 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 16 Oct 2018 13:24:12 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
Message-ID: <CAC20D2N-EW-A7RL3n0BSbW+aNmUmD5VnDtROzDR85feHth57Aw@mail.gmail.com>

On Tue, Oct 16, 2018 at 12:57 PM Paul Winalski <paul.winalski at gmail.com>
wrote:

> The block size is almost certainly 512 bytes.
>
Which is what I said - the block siize is set by the HW.
But ... the issue is trying to get the TK-50 to stream.  Hence the
traditional unix: dd ibs=64K obs=XXX | tar xvfp -  trick.

This will tell the driver to read upto 128 blocks in one DMA and then pump
the bits into tar a 'XXX block' at a time (which is is usually 20b for
tar/cpio/dump et al and Ultrix obey's).
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181016/dba5f9eb/attachment.html>

From clemc at ccc.com  Wed Oct 17 03:34:08 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 16 Oct 2018 13:34:08 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
Message-ID: <CAC20D2NWJDbjExiVmd2jOrdDBLeYTuam-PvPv=wPC4MA-=4UZA@mail.gmail.com>

But Paul's comment is still right on - the controller for both was a 1MHz
i8085 and just could not keep up.
I hated both .. its' too bad DEC refused to use QIC.   They did eventually
use 4mm DAT on an SCSI (and actually OEM'ed the drive from HP it turns
out).   The 8mm [Exabyte Unit] was from CSS and many of us in UNIX land had
them on our Alpha's - Tru64 supports as a 'latent' device - but the
politics of the day were TK-50 and TK-70 was the DEC official drive.

It's interesting until DEC sold off the team and DLT  to Quantum, it was
not very popular except at VMS sites since the Unix world knew that the
SCSI driver had full support for the standard devices.   To Quantum credit,
they redid the controller (put in a 68K IIRC) and life got much better.

But it was always way more expensive than QIC, 4 or 8 mm.

Clem
ᐧ

On Tue, Oct 16, 2018 at 1:23 PM William Pechter <pechter at gmail.com> wrote:

> DEC Tape II was the serial driven TU58.
> The TK50 was CompacTape or something like that.  It was the predecessor of
> a number of square tapes...
>
> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>
> Bill
>
> -----Original Message-----
> From: Paul Winalski <paul.winalski at gmail.com>
> To: Clem Cole <clemc at ccc.com>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>, cctalk at classiccmp.org
> Sent: Tue, 16 Oct 2018 13:14
> Subject: Re: [TUHS] Ultrix Tape: Block Size?
>
> On 10/15/18, Clem Cole <clemc at ccc.com> wrote:
> > #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> > ᐧ
> The original DECtape was extremely reliable.  Not so the TK50.
> Calling it "DECtape II" was an insult to the original DECtape.  The
> problem wasn't so much the drive itself, but the controller.  In an
> effort to reduce costs, DEC used a controller that had insufficient
> buffering capability for a streaming, block-replacement tape device
> such as the TK50.  TK50s were prone to both data-late and overrun
> errors.
>
> The block size is almost certainly 512 bytes.
>
> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181016/be4e5bf8/attachment.html>

From paul.winalski at gmail.com  Wed Oct 17 03:34:40 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 16 Oct 2018 13:34:40 -0400
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
Message-ID: <CABH=_VR_uRM2m3WndQBZmuHLE005X=8N8vPvtQxvACq0bb2=vA@mail.gmail.com>

On 10/16/18, William Pechter <pechter at gmail.com> wrote:
> DEC Tape II was the serial driven TU58.
> The TK50 was CompacTape or something like that.  It was the predecessor of a
> number of square tapes...
>
> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>
My mistake.  Yes, I was thinking of the TU58, a most miserable device.

-Paul W.


From emu at e-bbes.com  Wed Oct 17 16:14:20 2018
From: emu at e-bbes.com (emanuel stiebler)
Date: Wed, 17 Oct 2018 08:14:20 +0200
Subject: [TUHS] TK50, was: Re:  Ultrix Tape: Block Size?
In-Reply-To: <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
 <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
Message-ID: <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>

On 2018-10-16 20:37, Paul Koning via cctalk wrote:
> 
> 
>> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk <cctalk at classiccmp.org> wrote:
>>
>> DEC Tape II was the serial driven TU58.
>> The TK50 was CompacTape or something like that.  It was the predecessor of a number of square tapes...
>>
>> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>>
>> Bill

> I used DLT on RSTS systems, with a Qbus interface.  Those were modest speed hosts and buses, but I never remember data late or overrun issues, and we drove those tapes quite hard in full time streaming mode for backup and software distribution.  Longer blocks, too (2k or so) which would make any buffering issues more severe.

Just few words here, as I'm not sure anymore we are talking about the
same thing ...

there were
TK50Z as an external drive, on "SCSI"
TZ30 internal drive, on "SCSI", using TK50 tapes
TK50 on QBUS with an TQK50 controller which really didn't stream to often
TK50 on QBUS with an TQK70 controller, which doubled the memory of the
TQK50, which was capable of streaming ...




From tih at hamartun.priv.no  Wed Oct 17 22:57:38 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Wed, 17 Oct 2018 14:57:38 +0200
Subject: [TUHS] TK50, was: Re:  Ultrix Tape: Block Size?
In-Reply-To: <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com> (emanuel
 stiebler's message of "Wed, 17 Oct 2018 08:14:20 +0200")
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
 <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
 <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>
Message-ID: <m2tvlkvigt.fsf@thuvia.hamartun.priv.no>

emanuel stiebler <emu at e-bbes.com> writes:

> TK50 on QBUS with an TQK50 controller which really didn't stream to often
> TK50 on QBUS with an TQK70 controller, which doubled the memory of the
>   TQK50, which was capable of streaming ...

Now *that* I wasn't aware of!  Thanks!

I'll have to open up my PDP-11/83 tonight.  Its TK50 will stream while
writing, as long as what's being written can be read reasonably fast
from (RQDX3/RD54) disk.  The TQK controller is sitting right up at the
top end of the Q-bus, to get high priority -- but I don't know if it's a
TQK70.  I've really just assumed it's a TQK50 without thinking too much
about it...

-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 clemc at ccc.com  Thu Oct 18 01:18:07 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 17 Oct 2018 11:18:07 -0400
Subject: [TUHS] TK50, was: Re:  Ultrix Tape: Block Size?
In-Reply-To: <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
 <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
 <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>
Message-ID: <CAC20D2M9E2OapnL4C4868BMDd7XcH2hfdVy3=XLRgYiDB0MV3Q@mail.gmail.com>

I took most of this off line, but I'll try to close down the discussion, so
we can get back to TUHS history.

Please be careful of your wording as it is easy to get confused
particularly if you never used the original 1/2" tape system you might not
understand the actual terms.  The term for reading Read and Write I/O Sizes in
a user program are different than tape block sizes (or as they were
originally referred LRECL - Logical Record Length).

As I said to Paul K, I sadly know way more about the minutia of tapes that
I really should admit [I broke in during the 60s using 7-track tapes on the
IBM Mainframes which really date me and I remember the 5-track tapes on one
of the systems, but I never personally used it].


On Wed, Oct 17, 2018 at 2:14 AM emanuel stiebler <emu at e-bbes.com> wrote:

>  Longer blocks, too (2k or so) which would make any buffering issues more
> severe.
>


*Your user program read/wrote with 2K or more using DMA reads or writes but
it wrote 512 byte 'blocks.'*

As Paul W pointed out correctly, the TK50 and its children in the DLT*
family all used a fixed format 512 byte *blocks on the tape*.    This
cannot be changed.   The tape format is handled by the tape controller
microcode and all of the blocks on all the streamers (DLT, 1/4, 1/2", 4mm
and 8mm) that I know about were fixed at 512 byte, although the OS could
write multiple (N) blocks at a time to the tape controller which will will
write as N blocks on the tape.

This was different from 1/2" parallel 7 and 9-track tape which was actually
had variable size 'blocks' in the writes and the tape format.  Since the
terminalogy was defined (by IBM) for 5/7/9 track drives, we still use that
terminology.

The trick is that streamer** format write* (which is bit seral):
                 <HW HDR BLK1 bit serial><512 bytes of serial data
[blk1]><HW TLR BLK1 bit serial><HW HDR BLK2 bit serial><512 bytes of serial
data[blk2]><HW TLR BLK2 bit serial>.....<HW HDR BLKn bit serial><512 bytes
of serial data>[blkn]<HW TLR BLKn bit serial>

The key is that there are no inter-record gaps (IRG) between the <HW TKR
BLK x bit serial> and <<HW HDR BLK x+1 bit serial> frames when recording on
a streamer.   BTW: they usually use a serpitine scheme - starting with the
center of the tape and moving outwards in a circular pattern - IIRC down on
tape end and up on tape start -- but that's fuzzy in my memory and I'm at
work so I can not look in any of the controller books  have at home.  If
you lose the bit stream on input (data under run), the tape controller
backs up the tape and when it starts to write again, it goes over the last
block trailer and start its new write at the end of it.   For instance the
original 1/4" QIC format wrote 4 passes, then later when the recording head
got better, it wrote 9 passes and then even more, but in the newer formats
(and withe better media) the head was smaller.

Also remember that EOT is handled different in the streamer formats from
1/2" 7/9 track and IIRC EOT can even differ between the different streamer
formats.

If you look at 1/2" parallel 7/9-track (which is where the terms and basic
concepts originate) 9-track has a 'inter-record gap' between the last
block's trailer and the next block's header.  When IBM originally defined
that 7 and 9 track formats (whch ANSI later codified), these gaps are
defined so that the there is time to start and stop the motors (somewhere,
I have a very old IBM document from the late 60s that describes this very
well using IBM terms like LRECL and DASD - direct access storage device ;-)

The key difference from a streamer tape is that the IBM LRECL or logicial
record size, could (and did) vary ***.  But to try to keep the amount of
wasted space (*i.e.* least amount of inter-record gaps), different programs
use different 'block size' and some formats (like ANSI labeled tapes) the
block size (LRECL) can vary within the tape itself.

Also, I don't think I ever knew why, but for some reason IBM's tape
utilites tended to like LRECL 10240 and 20480.   Since many of us UNIX
folks came from IBM and Multics, we also used the same sizes (*i.e.* 20b or
10240 8 bit bytes) - it was reasonably efficent (we got 150M per
traditional 2400" 1/2 tape at 6250 BPI - you could get 1/3 more space when
3M created a 3600" that fit in the original 1/2" reel) .

Thus the on-tape format of 1/2" (which is parallel encoding and one pass
over the tape):
               <HW HDR1><LRECL BYTES of BLK1><HW TRL2><IRG><HW HDR2><LRECL
BYTES of BLK2><HW TRL2><IRG>......<HW HDRn><LRECL BYTES of BLKn><HW TRn>
<IRG><HW EOT HDR>[if the last last 'file' on the tape a second<IRG><HW EOT
HDR>]
Note:   LRECL BYTES of BLK1 did not have to be the same as <LRECL BYTES of
BLK2> much less <LRECL BYTES of BLKn>

Thus concept (and term) of 'tape blocks' was born.  Also note be careful
the term 'file' has specific meaning to a tape.  DEC started to use the
term 'save set' to disamiguated it BTW.   A tape 'file' N tape blocks,
followed by an a EOT mark.    Thus, two adjacent tape marks actually
delinated end of recorded data in the tape. Thus in 7/9 track formats when
a new file is written the last <IRG><HW EOT HDR> is backed up over and data
frame writing starts over writing the second <HW EOT HDR> after the last
<IRG>

So ...   what this all means is that from the OS side, you start a DMA on X
blocks and then let the tape controller read or write it.  No matter the
number of blocks you write on a streamer, it will always write it as 512
byte blocks (similar to how a disk works when set up in 'fixed' formatting).

One more thing to be careful about...  people also talk about 'ANSI tape'
format.   This usually refered to the *SW format of the data blocks on the
tape*.   UNIX's native tape formats were tp/stp, tar, cpio and dump. VMS
uses the ANSI tape format as its native format under the covers (and if
IIRC, so does RT11) for how to write and exchange data - which BTW, originally
using those variable LRECL blocks on the tape.

So the undustry first had a define a set if physical encoding for the tapes
and these are also ANSI specs.   But you need need to define how the data
itself is written (which byte encoding ASCII vs EBCIDIC) and how to
understand the 'files' on the tape itself (this is usually what is being
tape about when people talk about 'ANSI tapes.' My old housemate at UCB
(Tom Quarles, also known as the author of SPICE3) wrote the UNIX Ansitape
program that went out with BSD (he wrote so we could exchnage tapes with
the DEC CAD team which used VMS).

Clem

* Just to confuse you more, TK50 and the DLT family actually use a 1/2"
media in the closed tape cartridge.  But when DEC developed it (with 3M),
there were also 3rd party 1/2" tape controllers that wrote bit serial
(streamer) format on the traditonal 1/2" (9-track parallel) media.   For
instance the USAF/AWACS planes used to use a traditonal 3M 1/2" tape
>>media<<, but those tapes can only be read on a special streamer drive
[long story - I can make a couple of HW & SW guys shutter when I just say
the word 'Grumman' ****].

**  One other thing to confuse the world is that 'streaming' was a trick
performance trick that originated with 1/2" tape.   You will see many 1/2"
drives from the period such as ones from Cipher and Kenndy that took a
parallel byte stream and wrote/read them - although they obey the 1/2"
format rules on the tape itself.

***  Another thing that was undefined in the ANSI tape specs and you can
sometimes see, but certain HW will toss cookies and not read if you try it,
it mix encoding within a tape (i.e. write 800 BPI, 1600 BPI or even 6250
BPI on the same tape).   This was sometimes done on things like boot tapes
because the pre-boot system might only know about 800 BPI tapes and it
simplified the boot process particularly in the days when you had to toggle
in the boot (or in IBM terms -- IPL -- initial program load -- code).

**** An airman on the AWAC used to spent his entire time on the flight
keeping the 3 drives loaded - it the time it took to write one tape,
another is being rewound and the airman put a new tape on the 3rd - making
that all work at full speed with no data loss was 'interesting'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181017/c7de5d68/attachment.html>

From kevin.bowling at kev009.com  Thu Oct 18 14:45:40 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 17 Oct 2018 21:45:40 -0700
Subject: [TUHS] IBM Mach 3.0 Ports
Message-ID: <CAK7dMtABnewY5DHxjcc4bC1zo2A1mvdv29Jq+-xFiHhTrAs5qA@mail.gmail.com>

Does anyone have these documents or the ports themselves?  Or know who
to talk to so they can be preserved?
https://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/rs6k_announce

Regards,
Kevin


From tih at hamartun.priv.no  Thu Oct 18 17:48:22 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Thu, 18 Oct 2018 09:48:22 +0200
Subject: [TUHS] TK50, was: Re:  Ultrix Tape: Block Size?
In-Reply-To: <m2tvlkvigt.fsf@thuvia.hamartun.priv.no> (Tom Ivar Helbekkmo via
 TUHS's message of "Wed, 17 Oct 2018 14:57:38 +0200")
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
 <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
 <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>
 <m2tvlkvigt.fsf@thuvia.hamartun.priv.no>
Message-ID: <m2tvljofuh.fsf@thuvia.hamartun.priv.no>

I wrote:

> I'll have to open up my PDP-11/83 tonight.  Its TK50 will stream while
> writing, as long as what's being written can be read reasonably fast
> from (RQDX3/RD54) disk.  The TQK controller is sitting right up at the
> top end of the Q-bus, to get high priority -- but I don't know if it's a
> TQK70.  I've really just assumed it's a TQK50 without thinking too much
> about it...

Turns out it's an M7546; a TQK50.  I guess I'll get streaming writes
more often with an M7559 (TQK70) than I do at the moment, then.  :)

-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 tih at hamartun.priv.no  Thu Oct 18 17:48:22 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Thu, 18 Oct 2018 09:48:22 +0200
Subject: [TUHS] TK50, was: Re:  Ultrix Tape: Block Size?
In-Reply-To: <m2tvlkvigt.fsf@thuvia.hamartun.priv.no> (Tom Ivar Helbekkmo via
 TUHS's message of "Wed, 17 Oct 2018 14:57:38 +0200")
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
 <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost>
 <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
 <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com>
 <m2tvlkvigt.fsf@thuvia.hamartun.priv.no>
Message-ID: <m2tvljofuh.fsf@thuvia.hamartun.priv.no>

I wrote:

> I'll have to open up my PDP-11/83 tonight.  Its TK50 will stream while
> writing, as long as what's being written can be read reasonably fast
> from (RQDX3/RD54) disk.  The TQK controller is sitting right up at the
> top end of the Q-bus, to get high priority -- but I don't know if it's a
> TQK70.  I've really just assumed it's a TQK50 without thinking too much
> about it...

Turns out it's an M7546; a TQK50.  I guess I'll get streaming writes
more often with an M7559 (TQK70) than I do at the moment, then.  :)

-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 jsteve at superglobalmegacorp.com  Fri Oct 19 03:19:29 2018
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 19 Oct 2018 01:19:29 +0800
Subject: [TUHS] IBM Mach 3.0 Ports
In-Reply-To: <CAK7dMtABnewY5DHxjcc4bC1zo2A1mvdv29Jq+-xFiHhTrAs5qA@mail.gmail.com>
References: <CAK7dMtABnewY5DHxjcc4bC1zo2A1mvdv29Jq+-xFiHhTrAs5qA@mail.gmail.com>
Message-ID: <3dce7cd7-86f2-4030-ab8c-7a8b95278fb1@SG2APC01FT049.eop-APC01.prod.protection.outlook.com>

I’ve been trying to chase down something usable from CMU Mach for way too long.  I think the afs project is largely on auto-pilot for the last 20+ years, and whatever is accessible is, and whatever isn’t is either lost or locked up with accounts that have moved on in one way or another.

The only sizable release of Mach of the era is on the 4th CD of the CSRG releases.  And it’s far from any buildable state, that I could really see.

Forever ago there was an effort to get Mach 4 + Lites running and I did get it running kind of by accident.  I never could rebuild it from source.  Maybe I’m just missing something.  But it’s not intuitive at all.  I guess it’s like the MT XINU Mach for the i386, basically it was a thing but no copies seem to have survived.

I guess IBM would be scared of people seeing either RS/6000 or the prior ROMP/RT architecture code, and people running their own OS’s.  Much like the MacMach port.  I tried asking the MachTen people about buying their source but they only have binaries on CD.

I guess it’s like my on-going struggle with Attachmate trying to get a SYSV license.


From: Kevin Bowling
Sent: Thursday, October 18, 2018 1:05 PM
To: The Eunuchs Hysterical Society
Subject: [TUHS] IBM Mach 3.0 Ports

Does anyone have these documents or the ports themselves?  Or know who
to talk to so they can be preserved?
https://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/rs6k_announce

Regards,
Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181019/8506d10e/attachment.html>

From dave at horsfall.org  Fri Oct 19 08:28:54 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 19 Oct 2018 09:28:54 +1100 (EST)
Subject: [TUHS] Vaxen, my children...
Message-ID: <alpine.BSF.2.21.9999.1810190924550.92151@aneurin.horsfall.org>

Time to post this classic; I don't recall who wrote it.  Note that the 
references are pretty obscure now...

-----

VAXen, my children, just don't belong some places.  In my business, I am 
frequently called by small sites and startups having VAX problems.  So when 
a friend of mine in an Extremely Large Financial Institution (ELFI) called 
me one day to ask for help, I was intrigued because this outfit is a 
really major VAX user - they have several large herds of VAXen - and 
plenty of sharp VAXherds to take care of them.

So I went to see what sort of an ELFI mess they had gotten into.  It seems 
they had shoved a small 750 with two RA60s running a single application, 
PC style, into a data center with two IBM 3090s and just about all the 
rest of the disk drives in the world.  The computer room was so big it had 
three street addresses.  The operators had only IBM experience and, to 
quote my friend, they were having "a little trouble adjusting to the VAX", 
were a bit hostile towards it and probably needed some help with system 
management.  Hmmm, hostility...  Sigh.

Well, I thought it was pretty ridiculous for an outfit with all that VAX 
muscle elsewhere to isolate a dinky old 750 in their Big Blue Country, and 
said so bluntly.  But my friend patiently explained that although small, it 
was an "extremely sensitive and confidential application."  It seems that 
the 750 had originally been properly clustered with the rest of a herd and 
in the care of one of their best VAXherds.  But the trouble started when 
the Chief User went to visit his computer and its VAXherd.

He came away visibly disturbed and immediately complained to the ELFI's 
Director of Data Processing that, "There are some very strange people in 
there with the computers."  Now since this user person was the Comptroller 
of this Extremely Large Financial Institution, the 750 had been promptly 
hustled over to the IBM data center which the Comptroller said, "was a 
more suitable place."  The people there wore shirts and ties and didn't 
wear head bands or cowboy hats.

So my friend introduced me to the Comptroller, who turned out to be five 
feet tall, 85 and a former gnome of Zurich.  He had a young apprentice 
gnome who was about 65.  The two gnomes interviewed me in whispers for 
about an hour before they decided my modes of dress and speech were 
suitable for managing their system and I got the assignment.

There was some confusion, understandably, when I explained that I would 
immediately establish a procedure for nightly backups.  The senior gnome 
seemed to think I was going to put the computer in reverse, but the 
apprentice's son had an IBM PC and he quickly whispered that "backup" 
meant making a copy of a program borrowed from a friend and why was I 
doing that?  Sigh.

I was shortly introduced to the manager of the IBM data center, who 
greeted me with joy and anything but hostility.  And the operators really 
weren't hostile - it just seemed that way.  It's like the driver of a Mack 
18 wheeler, with a condo behind the cab, who was doing 75 when he ran over 
a moped doing its best to get away at 45.  He explained sadly, "I really 
warn't mad at mopeds but to keep from runnin' over that'n, I'da had to 
slow down or change lanes!"

Now the only operation they had figured out how to do on the 750 was 
reboot it.  This was their universal cure for any and all problems. 
After all it works on a PC, why not a VAX?  Was there a difference? 
Sigh.

But I smiled and said, "No sweat, I'll train you.  The first command you 
learn is HELP" and proceeded to type it in on the console terminal.  So 
the data center manager, the shift supervisor and the eight day-operators 
watched the LA100 buzz out the usual introductory text.  When it finished 
they turned to me with expectant faces and I said in an avuncular manner, 
"This is your most important command!"

The shift supervisor stepped forward and studied the text for about a 
minute.  He then turned with a very puzzled expression on his face and 
asked, "What do you use it for?"  Sigh.

Well, I tried everything.  I trained and I put the doc set on shelves by 
the 750 and I wrote a special 40 page doc set and then a four page doc 
set.  I designed all kinds of command files to make complex operations into 
simple foreign commands and I taped a list of these simplified commands to 
the top of the VAX.  The most successful move was adding my home phone 
number.

The cheat sheets taped on the top of the CPU cabinet needed continual 
maintenance, however.  It seems the VAX was in the quietest part of the 
data center, over behind the scratch tape racks.  The operators ate lunch 
on the CPU cabinet and the sheets quickly became coated with pizza 
drippings, etc.

But still the most used solution to hangups was a reboot and I gradually 
got things organized so that during the day when the gnomes were using the 
system, the operators didn't have to touch it.  This smoothed things out a 
lot.

Meanwhile, the data center was getting new TV security cameras, a halon 
gas fire extinguisher system and an immortal power source.  The data center 
manager apologized because the VAX had not been foreseen in the plan and 
so could not be connected to immortal power.  The VAX and I felt a little 
rejected but I made sure that booting on power recovery was working right. 
At least it would get going again quickly when power came back.

Anyway, as a consolation prize, the data center manager said he would have 
one of the security cameras adjusted to cover the VAX.  I thought to 
myself, "Great, now we can have 24 hour video tapes of the operators 
eating Chinese takeout on the CPU."  I resolved to get a piece of plastic 
to cover the cheat sheets.

One day, the apprentice gnome called to whisper that the senior was going 
to give an extremely important demonstration.  Now I must explain that what 
the 750 was really doing was holding our National Debt.  The Reagan 
administration had decided to privatize it and had quietly put it out for 
bid.  My Extreme Large Financial Institution had won the bid for it and 
was, as ELFIs are wont to do, making an absolute bundle on the float.

On Monday the Comptroller was going to demonstrate to the board of 
directors how he could move a trillion dollars from Switzerland to the 
Bahamas.  The apprentice whispered, "Would you please look in on our 
computer?  I'm sure everything will be fine, sir, but we will feel better 
if you are present.  I'm sure you understand?"  I did.

Monday morning, I got there about five hours before the scheduled demo to 
check things over.  Everything was cool.  I was chatting with the shift 
supervisor and about to go upstairs to the Comptroller's office.  Suddenly 
there was a power failure.

The emergency lighting came on and the immortal power system took over the 
load of the IBM 3090s.  They continued smoothly, but of course the VAX, 
still on city power, died.  Everyone smiled and the dead 750 was no big 
deal because it was 7 AM and gnomes don't work before 10 AM.  I began 
worrying about whether I could beg some immortal power from the data 
center manager in case this was a long outage.

Immortal power in this system comes from storage batteries for the first 
five minutes of an outage.  Promptly at one minute into the outage we hear 
the gas turbine powered generator in the sub-basement under us 
automatically start up getting ready to take the load on the fifth minute. 
We all beam at each other.

At two minutes into the outage we hear the whine of the backup gas turbine 
generator starting.  The 3090s and all those disk drives are doing just 
fine.  Business as usual.  The VAX is dead as a door nail but what the hell.

At precisely five minutes into the outage, just as the gas turbine is 
taking the load, city power comes back on and the immortal power source 
commits suicide.  Actually it was a double murder and suicide because it 
took both 3090s with it.

So now the whole data center was dead, sort of.  The fire alarm system had 
its own battery backup and was still alive.  The lead acid storage 
batteries of the immortal power system had been discharging at a furious 
rate keeping all those big blue boxes running and there was a significant 
amount of sulfuric acid vapor.  Nothing actually caught fire but the smoke 
detectors were convinced it had.

The fire alarm klaxon went off and the siren warning of imminent halon gas 
release was screaming.  We started to panic but the data center manager 
shouted over the din, "Don't worry, the halon system failed its acceptance 
test last week.  It's disabled and nothing will happen."

He was half right, the primary halon system indeed failed to discharge. 
But the secondary halon system observed that the primary had conked and 
instantly did its duty, which was to deal with Dire Disasters.  It had 
twice the capacity and six times the discharge rate.

Now the ear splitting gas discharge under the raised floor was so massive 
and fast, it blew about half of the floor tiles up out of their framework. 
It came up through the floor into a communications rack and blew the cover 
panels off, decking an operator.  Looking out across that vast computer 
room, we could see the air shimmering as the halon mixed with it.

We stampeded for exits to the dying whine of 175 IBM disks.  As I was 
escaping I glanced back at the VAX, on city power, and noticed the usual 
flickering of the unit select light on its system disk indicating it was 
happily rebooting.

Twelve firemen with air tanks and axes invaded.  There were frantic phone 
calls to the local IBM Field Service office because both the live and 
backup 3090s were down.  About twenty minutes later, seventeen IBM CEs 
arrived with dozens of boxes and, so help me, a barrel.  It seems they knew 
what to expect when an immortal power source commits murder.

In the midst of absolute pandemonium, I crept off to the gnome office and 
logged on.  After extensive checking it was clear that everything was just 
fine with the VAX and I began to calm down.  I called the data center 
manager's office to tell him the good news.  His secretary answered with, 
"He isn't expected to be available for some time.  May I take a message?" 
I left a slightly smug note to the effect that, unlike some other 
computers, the VAX was intact and functioning normally.

Several hours later, the gnome was whispering his way into a demonstration 
of how to flick a trillion dollars from country 2 to country 5.  He was 
just coming to the tricky part, where the money had been withdrawn from 
Switzerland but not yet deposited in the Bahamas.  He was proceeding very 
slowly and the directors were spellbound.  I decided I had better check up 
on the data center.

Most of the floor tiles were back in place.  IBM had resurrected one of the 
3090s and was running tests.  What looked like a bucket brigade was 
working on the other one.  The communication rack was still naked and a 
fireman was standing guard over the immortal power corpse.  Life was 
returning to normal, but the Big Blue Country crew was still pretty shaky.

Smiling proudly, I headed back toward the triumphant VAX behind the tape 
racks where one of the operators was eating a plump jelly bun on the 750 
CPU.  He saw me coming, turned pale and screamed to the shift supervisor, 
"Oh my God, we forgot about the VAX!"  Then, before I could open my mouth, 
he rebooted it.  It was Monday, 19-Oct-1987.  VAXen, my children, just 
don't belong some places.

-- Dave


From dave at horsfall.org  Fri Oct 19 09:14:40 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 19 Oct 2018 10:14:40 +1100 (EST)
Subject: [TUHS] In memoriam: Ken Iverson
Message-ID: <alpine.BSF.2.21.9999.1810190958510.92151@aneurin.horsfall.org>

We lost Ken Iverson on this day in 2004; a Canadian mathematician and 
computer scientist, he gave us APL (and its obscure one-liners).

-- Dave


From lars at nocrew.org  Fri Oct 19 21:08:29 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 19 Oct 2018 11:08:29 +0000
Subject: [TUHS] Alan Snyder's portable C compiler
Message-ID: <7w1s8myz0y.fsf@junk.nocrew.org>

Hello,

I have Alan Snyder's C compiler running in case anyone would like to
play with it.  It's from around 1975, so the syntax is yummily archaic.

The primary host is a PDP-10 running ITS, but there may also be machine
descriptions for Honeywell 6000 series and PDP-11.

At some point it seems like this compiler was tangled with Stephen
Johnson's PCC.


From jnc at mercury.lcs.mit.edu  Fri Oct 19 23:08:36 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 19 Oct 2018 09:08:36 -0400 (EDT)
Subject: [TUHS] Alan Snyder's portable C compiler
Message-ID: <20181019130836.391F518C083@mercury.lcs.mit.edu>

    > From: Lars Brinkhoff

    > I have Alan Snyder's C compiler running

Way cool! Congrats!

Where did you find it? Do you have source too?

    > there may also be machine descriptions for Honeywell 6000 series and
    > PDP-11

There _was_ one for the H6000, not sure about the -11.

    > At some point it seems like this compiler was tangled with Stephen
    > Johnson's PCC.

It would be good to find out what, if any, the connection is.

	Noel


From jsteve at superglobalmegacorp.com  Sat Oct 20 01:04:04 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Fri, 19 Oct 2018 23:04:04 +0800
Subject: [TUHS] Anyone have any luck trying to contact Micro Focus regarding
 Unix licensing?
Message-ID: <9f76d002-1530-4745-8fb6-2dba1baf36ce@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>

I've tried calling, emails to sales, using their website and I'm getting nowhere.  I know this is more complicated than v6’s context switching …. 

I've also read that apparently Microsoft swooped in 2010 acting as CPTN Holdings and bought all the Novell patents and turned them over to GPL v2?

I know after the whole SCO personal licenses and then Ransom Loves’s making 32v and all prior open was great but apparently it wasn’t his to give away.  Or am I wrong?

Are Unix licenses transferrable?

Anyone know someone wanting to lease/loan/sell?

I don't want to kick up too much of the hornets nest.  I'd just hate to think that the original Unix is going to languish.

I know many people worked so hard to keep the “Unix lights on”, just want to see that it doesn't die clouded in secrecy like VMS.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181019/4ddaff26/attachment.html>

From dave at horsfall.org  Sat Oct 20 07:17:05 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 20 Oct 2018 08:17:05 +1100 (EST)
Subject: [TUHS] Ultrix Tape: Block Size?
In-Reply-To: <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
References: <20181015195622.GB25749@minnie.tuhs.org>
 <CAC20D2Mj=uia_Mo_Dg1o0=J9saD06ySnLbAiMvjLAOzK+STVgA@mail.gmail.com>
 <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>
 <CABH=_VS-joYBV-+goBJKQwEDYgKbVgsJDuPxCVq+94Rhk2XnNg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1810200813300.92151@aneurin.horsfall.org>

On Tue, 16 Oct 2018, Paul Winalski wrote:

> The original DECtape was extremely reliable.  [...]

Indeed it was; a former boss used to tell the story of a salesman blowing 
cigarette smoke onto it (back when smoking was socially acceptable) and it 
just kept on working...

-- Dave


From clemc at ccc.com  Sat Oct 20 07:25:16 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 19 Oct 2018 16:25:16 -0500
Subject: [TUHS] Anyone have any luck trying to contact Micro Focus
 regarding Unix licensing?
In-Reply-To: <9f76d002-1530-4745-8fb6-2dba1baf36ce@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>
References: <9f76d002-1530-4745-8fb6-2dba1baf36ce@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAC20D2OguYKM0VPxDBX7M7NsQ0hb=p4x=A6gF2kKhTsv7bmc1A@mail.gmail.com>

On Fri, Oct 19, 2018 at 10:57 AM <jsteve at superglobalmegacorp.com> wrote:

> I know after the whole SCO personal licenses and then Ransom Loves’s
> making 32v and all prior open was great but apparently it wasn’t his to
> give away.  Or am I wrong?
>
Sigh ...  Yes...   Where did you hear this?   On second thought, I really I
don't want to know...  Whomever is spreading that information is tad
uninformed and really does understand what happened.

Simply put, the AT&T case made it clear, *the technology has been published*.
 The issue is closed.  It is 'open' - free - 'libre.'  It's all public
information and has been and was required to be by the US Courts in the
AT&T / USL vs UCB/BSDi law suit.   It's really not an interesting argument
at this point. The US courts made is clear, * AT&T was required to make the
barn doors open, and horses left the barn.*

This is why >>Novell<< released the implementation (i.e. source code) and*
it was Novell's to make available - which again the US courts have already
determined. *

All of this has been discussed here and elsewhere and really does not need
to be rehashed (please). *  In fact, *I wrote and published a very long
paper about how UNIX can to be.   The presentation of same can be seen and
the paper downloaded:
http://technique-societe.cnam.fr/colloque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et-appropriation--945215.kjsp


Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181019/5c778346/attachment.html>

From kevin.bowling at kev009.com  Sun Oct 21 07:56:19 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 20 Oct 2018 14:56:19 -0700
Subject: [TUHS] IBM Mach 3.0 Ports
In-Reply-To: <3dce7cd7-86f2-4030-ab8c-7a8b95278fb1@SG2APC01FT049.eop-APC01.prod.protection.outlook.com>
References: <CAK7dMtABnewY5DHxjcc4bC1zo2A1mvdv29Jq+-xFiHhTrAs5qA@mail.gmail.com>
 <3dce7cd7-86f2-4030-ab8c-7a8b95278fb1@SG2APC01FT049.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAK7dMtDwSnrONgCcP43SMx4fuMpcSnZ2XSVt9d+vvt=R5jCa5A@mail.gmail.com>

On Thu, Oct 18, 2018 at 10:19 AM Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
>
> I’ve been trying to chase down something usable from CMU Mach for way too long.  I think the afs project is largely on auto-pilot for the last 20+ years, and whatever is accessible is, and whatever isn’t is either lost or locked up with accounts that have moved on in one way or another.
>
>
>
> The only sizable release of Mach of the era is on the 4th CD of the CSRG releases.  And it’s far from any buildable state, that I could really see.
>
>
>
> Forever ago there was an effort to get Mach 4 + Lites running and I did get it running kind of by accident.  I never could rebuild it from source.  Maybe I’m just missing something.  But it’s not intuitive at all.  I guess it’s like the MT XINU Mach for the i386, basically it was a thing but no copies seem to have survived.
>
>
>
> I guess IBM would be scared of people seeing either RS/6000 or the prior ROMP/RT architecture code, and people running their own OS’s.  Much like the MacMach port.  I tried asking the MachTen people about buying their source but they only have binaries on CD.

Probably not the reason, these machines were fully and publicly
documented.  In fact, there is still a book in print on the ROS
residual data and firmware runtime services.  Most of the register
info was in "Hardware Technical Information" manuals that were
publicly ordered from IBM Publications (I have these).  And in fact I
provided this info and it was used to bring up NetBSD in the mid
2000s.

> From: Kevin Bowling
> Sent: Thursday, October 18, 2018 1:05 PM
> To: The Eunuchs Hysterical Society
> Subject: [TUHS] IBM Mach 3.0 Ports
>
>
>
> Does anyone have these documents or the ports themselves?  Or know who
>
> to talk to so they can be preserved?
>
> https://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/rs6k_announce
>
>
>
> Regards,
>
> Kevin
>
>


From jacob.ritorto at gmail.com  Wed Oct 24 12:59:40 2018
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Tue, 23 Oct 2018 22:59:40 -0400
Subject: [TUHS] System III on 11/34 + rl02
Message-ID: <CAHYQbfDevqhniVE3U3PFtdgb1V4hLz4YWkxendwHWVyXg_PUsQ@mail.gmail.com>

Hi,
  Was wanting to put together a fully functional (meaning able to load the
whole distro and recompile itself) and "reliable" System III machine made
of real, albeit not terribly sexy parts.  I have (4) working rl02 drives
and an 11/34, so I feel like there's a chance it could work.  I'll have to
build it on the emulator, of course, then vtserver it over to the real hw
in chunks.

But the blocker is that System III only supports rl01, not rl02, which
kills the 'full distro' prospect.

Would anyone know if it's trivial to modify the source for the rl01 driver
to just add double the blocks, thereby supporting rl02?  Or am I wildly
underestimating the task at hand?  Has this been done before?  Tips?

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181023/0c5aed78/attachment.html>

From clemc at ccc.com  Wed Oct 24 13:21:19 2018
From: clemc at ccc.com (Clem cole)
Date: Tue, 23 Oct 2018 23:21:19 -0400
Subject: [TUHS] System III on 11/34 + rl02
In-Reply-To: <CAHYQbfDevqhniVE3U3PFtdgb1V4hLz4YWkxendwHWVyXg_PUsQ@mail.gmail.com>
References: <CAHYQbfDevqhniVE3U3PFtdgb1V4hLz4YWkxendwHWVyXg_PUsQ@mail.gmail.com>
Message-ID: <34E96877-0DFF-4988-B07D-C0EFA42482C5@ccc.com>

Should be pretty easy particularly since the rl0x is supported in the BSD environment 

That said why mess with PWB 3.0 on an 11?   BSD 2.9 will be more interesting.  Also if you have a 40 class system like the 34 of 34A see if you can find an Able Enable board.  The memory will make a huge difference. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Oct 23, 2018, at 10:59 PM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> 
> Hi,
>   Was wanting to put together a fully functional (meaning able to load the whole distro and recompile itself) and "reliable" System III machine made of real, albeit not terribly sexy parts.  I have (4) working rl02 drives and an 11/34, so I feel like there's a chance it could work.  I'll have to build it on the emulator, of course, then vtserver it over to the real hw in chunks.  
> 
> But the blocker is that System III only supports rl01, not rl02, which kills the 'full distro' prospect.
> 
> Would anyone know if it's trivial to modify the source for the rl01 driver to just add double the blocks, thereby supporting rl02?  Or am I wildly underestimating the task at hand?  Has this been done before?  Tips?
> 
> thx
> jake


From jnc at mercury.lcs.mit.edu  Wed Oct 24 21:23:49 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 24 Oct 2018 07:23:49 -0400 (EDT)
Subject: [TUHS] System III on 11/34 + rl02
Message-ID: <20181024112349.E94EB18C0AB@mercury.lcs.mit.edu>

    > From: Jacob Ritorto <jacob.ritorto at gmail.com>

    > System III only supports rl01, not rl02

Really? That seems odd; SysII long post-dates (I think) the RL0x, if so it's
odd they only supported the RL01. Looking at:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=SysIII/usr/src/uts/pdp11/io/rl.c

it seems to support RL02's:

  #define RL02 0200	/* bit 7 indicates an rl02 present if set */

    > Would anyone know if it's trivial to modify the source for the rl01
    > driver to just add double the blocks

The only difference between the two is that the RL02 has twice as many
cylinders, so there's an extra bit in use on the high end of the 'disk
address' register.


    > From: Clem cole <clemc at ccc.com>

    > Also if you have a 40 class system like the 34 of 34A see if you can
    > find an Able Enable board.

I'm sure there are a stack of them stored away with Jimmy Hoffa's body and the
Ark of the Covenant in King Solomon's Mine! :-)

Seriously, if anyone has one, I'd pay a very substantial sum for it.

	   Noel


From dave at horsfall.org  Thu Oct 25 08:11:52 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 25 Oct 2018 09:11:52 +1100 (EST)
Subject: [TUHS] Happy birthday, Peter Naur!
Message-ID: <alpine.BSF.2.21.9999.1810250908370.92151@aneurin.horsfall.org>

Computer science pioneer Peter Naur was born on this day in 1928; he was 
responsible for ALGOL60, BNF syntax (he notably insisted upon calling it 
Backus-NORMAL-Form), etc.

-- Dave


From gtaylor at tnetconsulting.net  Thu Oct 25 09:00:18 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 24 Oct 2018 17:00:18 -0600
Subject: [TUHS] X11 Secondary Selection
Message-ID: <fa3f9138-e15a-db56-98c4-ddd8789dc624@spamtrap.tnetconsulting.net>

Does anyone know any history about X11's secondary selection?

What did / still does use it?

I'm fairly familiar with the primary selection and clipboard.  But I'm 
not aware of anything that uses the secondary selection.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181024/5ba9a10d/attachment.bin>

From jacob.ritorto at gmail.com  Thu Oct 25 11:22:51 2018
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 24 Oct 2018 21:22:51 -0400
Subject: [TUHS] System III on 11/34 + rl02
In-Reply-To: <34E96877-0DFF-4988-B07D-C0EFA42482C5@ccc.com>
References: <CAHYQbfDevqhniVE3U3PFtdgb1V4hLz4YWkxendwHWVyXg_PUsQ@mail.gmail.com>
 <34E96877-0DFF-4988-B07D-C0EFA42482C5@ccc.com>
Message-ID: <CAHYQbfCoG+R5+6JzPfEKO80Vp-Ax69KffQj-OH8355wdCQ03Kg@mail.gmail.com>

I did run 2.9bsd on this machine and I like it better, but the distro
struggles to fit on (4) rl02s and then can't recompile itself due to lack
of space.

The System III idea is kind of homage to my Solaris years and for bragging
rights to my teenage friends who know nothing but Linux (and I kinda feel
(as a stretch) like Linux is in the System III line).  That said, I'd was
originally going for System V, but when I recompiled it under the emulator,
I found out that it requires separate I&D, so the 11/34 is out; System III
is next closest.  Eventually I'll be doing this same exercise on mt split
11/45 and then have some serious bragging rights :)

I sure hope there's a pdp11 sdcard / usb disk solution someday like they
did for the Commodore 64 - I could even pay a little for it.  And for some
clever kernel optimizing hack that'll let me run a tcp/ip stack on my poor
little-address-space 11/45 so I can telnet to it with 2.11bsd.

I'm totally in the market for an Able Enable board too!  Out of curiosity,
is it totally out of the question to just find the prints and do a
production run?  I mean if we got 100 people in at a hundred each, wouldn't
that cover it?  There's enough interest in vintage now that that headcount
could realistically happen.

On Tue, Oct 23, 2018 at 11:21 PM Clem cole <clemc at ccc.com> wrote:

> Should be pretty easy particularly since the rl0x is supported in the BSD
> environment
>
> That said why mess with PWB 3.0 on an 11?   BSD 2.9 will be more
> interesting.  Also if you have a 40 class system like the 34 of 34A see if
> you can find an Able Enable board.  The memory will make a huge difference.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
>
> > On Oct 23, 2018, at 10:59 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
> wrote:
> >
> > Hi,
> >   Was wanting to put together a fully functional (meaning able to load
> the whole distro and recompile itself) and "reliable" System III machine
> made of real, albeit not terribly sexy parts.  I have (4) working rl02
> drives and an 11/34, so I feel like there's a chance it could work.  I'll
> have to build it on the emulator, of course, then vtserver it over to the
> real hw in chunks.
> >
> > But the blocker is that System III only supports rl01, not rl02, which
> kills the 'full distro' prospect.
> >
> > Would anyone know if it's trivial to modify the source for the rl01
> driver to just add double the blocks, thereby supporting rl02?  Or am I
> wildly underestimating the task at hand?  Has this been done before?  Tips?
> >
> > thx
> > jake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181024/11ae1ce1/attachment.html>

From mutiny.mutiny at india.com  Thu Oct 25 16:56:19 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Thu, 25 Oct 2018 06:56:19 +0000 (UTC)
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <201810070607.w9767Xrl014901@freefriends.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
Message-ID: <879035458.46411.1540450578994.JavaMail.tomcat@india-live-be01>

just to mention the strange alien lisp machine, desktop environment, operation system, church of emacs in all known flavors:
https://github.com/larsbrinkhoff/emacs-history

At 7 Oct 2018 06:08:57 +0000 (+00:00) from arnold at skeeve.com:
> Hi All.
> 
> I am starting to collect, if possible, different versions of the QED
> editor; with a hope to put up a git repo.
> 
> If you have a tarball of code, please send it to me with as much info
> about it as you have.  I would like to track down the qedbuf(1) man page
> also.
> 
> I have contacted Rob Pike and got one tarball from him. I have another
> tarball that I got sometime in 1987 and have a promise of code coming
> Donald Mitchell.
> 
> Much thanks!
> 
> Arnold


From jnc at mercury.lcs.mit.edu  Thu Oct 25 20:56:47 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 25 Oct 2018 06:56:47 -0400 (EDT)
Subject: [TUHS] System III on 11/34 + rl02
Message-ID: <20181025105647.1929518C0A0@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > If this is true, I wonder why the install only offers rl01?

Where does it say this? (I didn't search for that.)


    > I'm totally in the market for an Able Enable board too! Out of
    > zcuriosity, is it totally out of the question to just find the prints
    > and do a production run?

Rotsa ruck! They're down the same mine as Jimmy Hoffa!! :-)

But seriously, if you could find them, that would be fantastic. I've managed
to collect (thanks Clem!) a tiny bit of info about them:

  http://gunkies.org/wiki/Able_ENABLE

and I _think_ I've worked out how they worked, but more is better. We had a
set of the prints at MIT BITD, but we didn't have the PROM/PLA/PAL/etc
programming info, and one would need that too to reproduce them.

    > I sure hope there's a pdp11 sdcard / usb disk solution someday like they
    > did for the Commodore 64

So Dave Bridgham and I have been working on a QBUS card with an FPGA that uses
an SD card to hold the bits, and emulates an RK11/RP11/etc controller. We have
a wire-wrap prototype working (the RK11's done, the RP11 should be a short
edit of that), and UNIX boots and runs. Now to turn it into PCB's...

We've planned that the next step will be to do a UNIBUS version, which will
also include ENABLE functionality (although it won't be plug compatible with
an ENABLE, the memory will be on-board).

Now to find the time/energy to make it happen... :-(

   Noel


From lars at nocrew.org  Fri Oct 26 02:09:50 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 25 Oct 2018 16:09:50 +0000
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <879035458.46411.1540450578994.JavaMail.tomcat@india-live-be01>
 (Donald ODona's message of "Thu, 25 Oct 2018 06:56:19 +0000 (UTC)")
References: <201810070607.w9767Xrl014901@freefriends.org>
 <879035458.46411.1540450578994.JavaMail.tomcat@india-live-be01>
Message-ID: <7wzhv2nh2p.fsf@junk.nocrew.org>

Donald ODona wrote:
> just to mention the strange alien lisp machine, desktop environment,
> operation system, church of emacs in all known flavors:
> https://github.com/larsbrinkhoff/emacs-history

Thanks.

Does anyone know what happened to SINE?  Or the MagicSix operating
system for that matter; maybe a sibling to Unix?  (To somehow try to
make this on topic.)


From noel.hunt at gmail.com  Fri Oct 26 07:15:51 2018
From: noel.hunt at gmail.com (Noel Hunt)
Date: Fri, 26 Oct 2018 08:15:51 +1100
Subject: [TUHS] Software Archeology: QED
In-Reply-To: <7wzhv2nh2p.fsf@junk.nocrew.org>
References: <201810070607.w9767Xrl014901@freefriends.org>
 <879035458.46411.1540450578994.JavaMail.tomcat@india-live-be01>
 <7wzhv2nh2p.fsf@junk.nocrew.org>
Message-ID: <CAGfO01wAQLwRNZV1tch2sEK9U9+agr0SCks41_PTaaQ1Fg4dOQ@mail.gmail.com>

In addition to SINE, does anyone know what happened to EINE?



On Fri, Oct 26, 2018 at 3:10 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Donald ODona wrote:
> > just to mention the strange alien lisp machine, desktop environment,
> > operation system, church of emacs in all known flavors:
> > https://github.com/larsbrinkhoff/emacs-history
>
> Thanks.
>
> Does anyone know what happened to SINE?  Or the MagicSix operating
> system for that matter; maybe a sibling to Unix?  (To somehow try to
> make this on topic.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181026/cf3b3c4c/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Oct 26 08:47:48 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 25 Oct 2018 18:47:48 -0400 (EDT)
Subject: [TUHS] Software Archeology: QED
Message-ID: <20181025224748.C782118C0A8@mercury.lcs.mit.edu>

    > From: Noel Hunt

    > In addition to SINE, does anyone know what happened to EINE?

Was replaced by ZWEI fairly early on.

Zwei
Was
Eine
Initially

Dunno if it still exists on an MIT dump-tape somewhere.

	Noel


From jacob.ritorto at gmail.com  Fri Oct 26 13:27:18 2018
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Thu, 25 Oct 2018 23:27:18 -0400
Subject: [TUHS] System III on 11/34 + rl02
In-Reply-To: <20181025105647.1929518C0A0@mercury.lcs.mit.edu>
References: <20181025105647.1929518C0A0@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfCP0S8FiTtW1AZ00_-P-pq5OEmvbFesLT4D9dXGGM_NVg@mail.gmail.com>

Isn't there still at least one ABLE ENABLE board out there extant that
could be used to read the PROMs?
Or is the actual original programming info itself needed to duplicate?



On Thu, Oct 25, 2018 at 6:56 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > If this is true, I wonder why the install only offers rl01?
>
> Where does it say this? (I didn't search for that.)
>
>
>     > I'm totally in the market for an Able Enable board too! Out of
>     > zcuriosity, is it totally out of the question to just find the prints
>     > and do a production run?
>
> Rotsa ruck! They're down the same mine as Jimmy Hoffa!! :-)
>
> But seriously, if you could find them, that would be fantastic. I've
> managed
> to collect (thanks Clem!) a tiny bit of info about them:
>
>   http://gunkies.org/wiki/Able_ENABLE
>
> and I _think_ I've worked out how they worked, but more is better. We had a
> set of the prints at MIT BITD, but we didn't have the PROM/PLA/PAL/etc
> programming info, and one would need that too to reproduce them.
>
>     > I sure hope there's a pdp11 sdcard / usb disk solution someday like
> they
>     > did for the Commodore 64
>
> So Dave Bridgham and I have been working on a QBUS card with an FPGA that
> uses
> an SD card to hold the bits, and emulates an RK11/RP11/etc controller. We
> have
> a wire-wrap prototype working (the RK11's done, the RP11 should be a short
> edit of that), and UNIX boots and runs. Now to turn it into PCB's...
>
> We've planned that the next step will be to do a UNIBUS version, which will
> also include ENABLE functionality (although it won't be plug compatible
> with
> an ENABLE, the memory will be on-board).
>
> Now to find the time/energy to make it happen... :-(
>
>    Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181025/beba9883/attachment.html>

From aap at papnet.eu  Sat Oct 27 05:46:36 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Fri, 26 Oct 2018 21:46:36 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
Message-ID: <20181026194636.GA11870@indra.papnet.eu>

The last couple of days I worked on re-setting the V3-V6 manuals.
I reconstructed V5 from the scan as best I could, unfortunately some
pages were missing.
You can find everything I used to do this here,
please read the BUGS section:
https://github.com/aap/unixman

The results can be found here, as HTML and PDF:
http://squoze.net/UNIX/v3man/
http://squoze.net/UNIX/v4man/
http://squoze.net/UNIX/v5man/
http://squoze.net/UNIX/v6man/

Reconstructing V1 and V2 n?roff source and converting the tty 37 output
to ps is something I want to do too, but for now this was exhausting
enough. 

Now for the questions that I arose while I was doing this:
Are there scans of the V4 and V6 manual to check my pdfs against?
Where does the V5 manual come from? As explained in the README,
some pages are missing and some pages seem to be earlier than V4.
Is there another V5 manual that one could check against?
Why is lc (the LIL compiler) not in the TOC but has a page?

And most importantly: is the old troff really lost?
I would love to set the manual on the original systems
at some point (and write a CAT -> ps converter, which should be fun).
Doing all this work made me wish we still had earlier versions
of UNIX and its tools around.

Have fun with this!

aap


From jcapp at anteil.com  Sat Oct 27 05:57:57 2018
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 26 Oct 2018 15:57:57 -0400 (EDT)
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026194636.GA11870@indra.papnet.eu>
Message-ID: <6666214.1893.1540583877528.JavaMail.root@zimbraanteil>

Beautiful! 


From: "Angelo Papenhoff" <aap at papnet.eu> 
To: tuhs at minnie.tuhs.org 
Sent: Friday, October 26, 2018 3:46:36 PM 
Subject: [TUHS] Reconstructed and newly set UNIX Manual 

The last couple of days I worked on re-setting the V3-V6 manuals. 
I reconstructed V5 from the scan as best I could, unfortunately some 
pages were missing. 
You can find everything I used to do this here, 
please read the BUGS section: 
https://github.com/aap/unixman 

The results can be found here, as HTML and PDF: 
http://squoze.net/UNIX/v3man/ 
http://squoze.net/UNIX/v4man/ 
http://squoze.net/UNIX/v5man/ 
http://squoze.net/UNIX/v6man/ 

Reconstructing V1 and V2 n?roff source and converting the tty 37 output 
to ps is something I want to do too, but for now this was exhausting 
enough. 

Now for the questions that I arose while I was doing this: 
Are there scans of the V4 and V6 manual to check my pdfs against? 
Where does the V5 manual come from? As explained in the README, 
some pages are missing and some pages seem to be earlier than V4. 
Is there another V5 manual that one could check against? 
Why is lc (the LIL compiler) not in the TOC but has a page? 

And most importantly: is the old troff really lost? 
I would love to set the manual on the original systems 
at some point (and write a CAT -> ps converter, which should be fun). 
Doing all this work made me wish we still had earlier versions 
of UNIX and its tools around. 

Have fun with this! 

aap 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181026/d53540f6/attachment.html>

From clemc at ccc.com  Sat Oct 27 06:41:13 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 26 Oct 2018 16:41:13 -0400
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026194636.GA11870@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
Message-ID: <CAC20D2MqYoGMKPQtCh3xtNpZQ_ftDv-0k22srNzrrJkyyUdTUA@mail.gmail.com>

On Fri, Oct 26, 2018 at 3:55 PM Angelo Papenhoff <aap at papnet.eu> wrote:

>
> And most importantly: is the old troff really lost?
>
The question is how old?   I thought we found a pre-ditroff (v6 binary) at
one point, but I don't think we have anything older than that.



> I would love to set the manual on the original systems
> at some point (and write a CAT -> ps converter, which should be fun).
>
I'm pretty sure this already exists.  It was part of the Adobe 'transcript'
package back in the day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181026/cbccdb42/attachment.html>

From wkt at tuhs.org  Sat Oct 27 06:59:38 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 27 Oct 2018 06:59:38 +1000
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026194636.GA11870@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
Message-ID: <20181026205938.GA10723@minnie.tuhs.org>

On Fri, Oct 26, 2018 at 09:46:36PM +0200, Angelo Papenhoff wrote:
> The last couple of days I worked on re-setting the V3-V6 manuals.
> Now for the questions that I arose while I was doing this:
> Where does the V5 manual come from?

The scan at 
https://www.tuhs.org//Archive/Distributions/Research/Dennis_v5/v5man.pdf
is a scan I did from a photocopy of the 5th Edition manuals that Norman
Wilson posted to me.

Cheers, Warren


From aap at papnet.eu  Sat Oct 27 07:05:02 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Fri, 26 Oct 2018 23:05:02 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <CAC20D2MqYoGMKPQtCh3xtNpZQ_ftDv-0k22srNzrrJkyyUdTUA@mail.gmail.com>
References: <20181026194636.GA11870@indra.papnet.eu>
 <CAC20D2MqYoGMKPQtCh3xtNpZQ_ftDv-0k22srNzrrJkyyUdTUA@mail.gmail.com>
Message-ID: <20181026210502.GA86931@indra.papnet.eu>

On 26/10/18, Clem Cole wrote:
> On Fri, Oct 26, 2018 at 3:55 PM Angelo Papenhoff <aap at papnet.eu> wrote:
> 
> >
> > And most importantly: is the old troff really lost?
> >
> The question is how old?   I thought we found a pre-ditroff (v6 binary) at
> one point, but I don't think we have anything older than that.

Oh, that sounds good! I thought v7 troff was the first that's been
preserved. Anyone know where to find it?

> > I would love to set the manual on the original systems
> > at some point (and write a CAT -> ps converter, which should be fun).
> >
> I'm pretty sure this already exists.  It was part of the Adobe 'transcript'
> package back in the day.

Hm, that sounds commercial. I'd prefer a free tool, besides, it should
be fun to write it.

aap


From bakul at bitblocks.com  Sat Oct 27 07:58:40 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 26 Oct 2018 14:58:40 -0700
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: Your message of "Fri, 26 Oct 2018 23:05:02 +0200."
 <20181026210502.GA86931@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
 <CAC20D2MqYoGMKPQtCh3xtNpZQ_ftDv-0k22srNzrrJkyyUdTUA@mail.gmail.com>
 <20181026210502.GA86931@indra.papnet.eu>
Message-ID: <20181026215847.4E549156E40C@mail.bitblocks.com>

On Fri, 26 Oct 2018 23:05:02 +0200 Angelo Papenhoff <aap at papnet.eu> wrote:
> On 26/10/18, Clem Cole wrote:
> > On Fri, Oct 26, 2018 at 3:55 PM Angelo Papenhoff <aap at papnet.eu> wrote:
> > 
> > >
> > > And most importantly: is the old troff really lost?
> > >
> > The question is how old?   I thought we found a pre-ditroff (v6 binary) at
> > one point, but I don't think we have anything older than that.
>
> Oh, that sounds good! I thought v7 troff was the first that's been
> preserved. Anyone know where to find it?
>
> > > I would love to set the manual on the original systems
> > > at some point (and write a CAT -> ps converter, which should be fun).
> > >
> > I'm pretty sure this already exists.  It was part of the Adobe 'transcript'
> > package back in the day.

pscat 

> Hm, that sounds commercial. I'd prefer a free tool, besides, it should
> be fun to write it.

IIRC there used to be a program called thack that converted
CAT to ps. Supposedly it didn't work too well but may be a
start? Google search reveals some sources.  See the one here
for example:

http://cd.textfiles.com/sourcecode/unix_c/postscrp/

No idea about the trustworthyness of this site but the program
compiles on freebsd with a few warnings.


From aap at papnet.eu  Sat Oct 27 08:29:09 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Sat, 27 Oct 2018 00:29:09 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026221153.GA19920@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181026214308.GA20796@minnie.tuhs.org>
 <20181026221153.GA19920@indra.papnet.eu>
Message-ID: <20181026222909.GA24093@indra.papnet.eu>

[this was meant to go over the list, Warren quoted it, but it
destroyed the formatting somewhat]

On 27/10/18, Warren Toomey wrote:
> On Fri, Oct 26, 2018 at 09:46:36PM +0200, Angelo Papenhoff wrote:
> > And most importantly: is the old troff really lost?
> 
> Angelo, I just trawled through the Unix Archive. Below is a list
> of tarballs with roff stuff in them. Hope this helps. Sorry that
> they are not in date order.
> Cheers, Warren

Unfortunately that does not include the old troff written in PDP-11
assembly.
The v6 tape and file system contain traces of it in the directory
/usr/source/s7, so we at least know (some of) the file names:

│002655f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |                |
│00265600 6d 01 72 6f 66 66 33 2e-73 00 00 00 00 00 00 00 |m?roff3.s       |
│00265610 6c 01 72 6f 66 66 34 2e-73 00 00 00 00 00 00 00 |l?roff4.s       |
│00265620 6b 01 72 6f 66 66 35 2e-73 00 00 00 00 00 00 00 |k?roff5.s       |
│00265630 6a 01 72 6f 66 66 37 2e-73 00 00 00 00 00 00 00 |j?roff7.s       |
│00265640 69 01 72 6f 66 66 38 2e-73 00 00 00 00 00 00 00 |i?roff8.s       |
│00265650 00 00 73 75 66 72 63 00-00 00 00 00 00 00 00 00 |  sufrc         |
│00265660 67 01 73 75 66 74 61 62-2e 73 00 00 00 00 00 00 |g?suftab.s      |
│00265670 00 00 74 63 61 74 73 69-6d 2e 73 00 00 00 00 00 |  tcatsim.s     |
│00265680 00 00 74 72 63 00 00 00-00 00 00 00 00 00 00 00 |  trc           |
│00265690 00 00 74 72 6f 66 66 31-2e 73 00 00 00 00 00 00 |  troff1.s      |
│002656a0 00 00 74 72 6f 66 66 32-2e 73 00 00 00 00 00 00 |  troff2.s      |
│002656b0 00 00 74 72 6f 66 66 33-2e 73 00 00 00 00 00 00 |  troff3.s      |
│002656c0 00 00 74 72 6f 66 66 34-2e 73 00 00 00 00 00 00 |  troff4.s      |
│002656d0 00 00 74 72 6f 66 66 35-2e 73 00 00 00 00 00 00 |  troff5.s      |
│002656e0 00 00 74 72 6f 66 66 36-2e 73 00 00 00 00 00 00 |  troff6.s      |
│002656f0 00 00 74 72 6f 66 66 36-61 00 00 00 00 00 00 00 |  troff6a       |
│00265700 00 00 74 72 6f 66 66 38-2e 73 00 00 00 00 00 00 |  troff8.s      |
│00265710 00 00 78 78 78 78 78 00-00 00 00 00 00 00 00 00 |  xxxxx         |
│00265720 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |                |

Now it could be that v7 troff is perfectly capable of generating the
manual just like older troff would have, I just haven't dived more
deeply into it all yet. I was more concerned about reconstructing the
actual content rather than the exact looks for now, but it's still
something i want to get right eventually.


This didn't go through the list but I'll reply here:

On 26/10/18, Ken Thompson wrote:
> nice job.

Thanks, You've always been an inspiration to me!

aap


From imp at bsdimp.com  Sat Oct 27 09:06:48 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 26 Oct 2018 17:06:48 -0600
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026222909.GA24093@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181026214308.GA20796@minnie.tuhs.org>
 <20181026221153.GA19920@indra.papnet.eu>
 <20181026222909.GA24093@indra.papnet.eu>
Message-ID: <CANCZdfpfvZG71M++8wsP92HGYRBMz6E-4wggou=+XngdM6BJAA@mail.gmail.com>

On Fri, Oct 26, 2018 at 4:57 PM Angelo Papenhoff <aap at papnet.eu> wrote:

> On 26/10/18, Ken Thompson wrote:
> > nice job.
>
> Thanks, You've always been an inspiration to me!
>

Today, sir, you have won this part of the internet. :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181026/9e40e736/attachment.html>

From lm at mcvoy.com  Sat Oct 27 09:46:15 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 26 Oct 2018 16:46:15 -0700
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <CANCZdfpfvZG71M++8wsP92HGYRBMz6E-4wggou=+XngdM6BJAA@mail.gmail.com>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181026214308.GA20796@minnie.tuhs.org>
 <20181026221153.GA19920@indra.papnet.eu>
 <20181026222909.GA24093@indra.papnet.eu>
 <CANCZdfpfvZG71M++8wsP92HGYRBMz6E-4wggou=+XngdM6BJAA@mail.gmail.com>
Message-ID: <20181026234615.GG16926@mcvoy.com>

On Fri, Oct 26, 2018 at 05:06:48PM -0600, Warner Losh wrote:
> On Fri, Oct 26, 2018 at 4:57 PM Angelo Papenhoff <aap at papnet.eu> wrote:
> 
> > On 26/10/18, Ken Thompson wrote:
> > > nice job.
> >
> > Thanks, You've always been an inspiration to me!
> >
> 
> Today, sir, you have won this part of the internet. :)

Yeah, it's nice when Ken speaks up.  I'm always nervous when I post
because I know Ken wants 100% signal.

It would be nice if we could get Rob Pike here, he's the right combination
of brilliant and kinda snotty, he doesn't suffer fools at all.  I loved
Rob's point that if you think that you need threads your processes are
too fat.  He's mostly right, in theory, but in practice you can't share
memory via mmap across processes at the same low cost as threads.  If you
have N processes sharing the same memory you have N*pages page table
entries; if you have threads you have 1*pages page table entries (for
the shared memory part).  Back when I was active in kernel development
I tried to get Linus to do a page table scheme that would allow more
than one page table per process so you could have private tables and
shared tables.  Dunno if he did that.

But it would be nice to have Rob here, he's sort of old school but sort
of the next gen of Bell Labs.  And a smart cookie.

And to Angelo, Warner is right, I'd keep that email.

--lm


From doug at cs.dartmouth.edu  Sat Oct 27 21:59:35 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 27 Oct 2018 07:59:35 -0400
Subject: [TUHS] Reconstructed and newly set UNIX Manual
Message-ID: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>

 > Now it could be that v7 troff is perfectly capable of generating the
> manual just like older troff would have.

On taking over editorship for v7, I added some macros to the -man
package. I don't specifically recall making any incompatible
changes. If there were any, they'd most likely show up in
the title and synopsis and should be fixable by a minor tweak
to -man. I'm quite confident that there would be no problems
with troff proper.

Doug


From aap at papnet.eu  Sat Oct 27 22:28:34 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Sat, 27 Oct 2018 14:28:34 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
Message-ID: <20181027122834.GA97675@indra.papnet.eu>

On 27/10/18, Doug McIlroy wrote:
>  > Now it could be that v7 troff is perfectly capable of generating the
> > manual just like older troff would have.
> 
> On taking over editorship for v7, I added some macros to the -man
> package. I don't specifically recall making any incompatible
> changes. If there were any, they'd most likely show up in
> the title and synopsis and should be fixable by a minor tweak
> to -man. I'm quite confident that there would be no problems
> with troff proper.

I didn't mean the macros. They are not problematic at all.
It's the idea how much a point is compared to an inch that has
changed over time i think.

aap


From milov at cs.uwlax.edu  Sat Oct 27 23:07:30 2018
From: milov at cs.uwlax.edu (Milo Velimirovic)
Date: Sat, 27 Oct 2018 08:07:30 -0500
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181027122834.GA97675@indra.papnet.eu>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
 <20181027122834.GA97675@indra.papnet.eu>
Message-ID: <D980BC1E-288D-4679-AB86-8028FA5B1E2E@cs.uwlax.edu>



> On Oct 27, 2018, at 7:28 AM, Angelo Papenhoff <aap at papnet.eu> wrote:
> 
> On 27/10/18, Doug McIlroy wrote:
>>> Now it could be that v7 troff is perfectly capable of generating the
>>> manual just like older troff would have.
>> 
>> On taking over editorship for v7, I added some macros to the -man
>> package. I don't specifically recall making any incompatible
>> changes. If there were any, they'd most likely show up in
>> the title and synopsis and should be fixable by a minor tweak
>> to -man. I'm quite confident that there would be no problems
>> with troff proper.
> 
> I didn't mean the macros. They are not problematic at all.
> It's the idea how much a point is compared to an inch that has
> changed over time i think.
> 
> aap

From my experience in the world of prepress 723pts == 10in.

Then Adobe unleashed PostScript on us and redefined the point
so that 72pt == 1in.

I’m unaware of any other definitions of a point.

-Milo

From toby at telegraphics.com.au  Sat Oct 27 23:56:26 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 27 Oct 2018 10:56:26 -0300
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <D980BC1E-288D-4679-AB86-8028FA5B1E2E@cs.uwlax.edu>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
 <20181027122834.GA97675@indra.papnet.eu>
 <D980BC1E-288D-4679-AB86-8028FA5B1E2E@cs.uwlax.edu>
Message-ID: <304c9202-18fb-fc61-5a02-7ebe58f10697@telegraphics.com.au>

On 2018-10-27 10:07 a.m., Milo Velimirovic wrote:
> 
> 
>> On Oct 27, 2018, at 7:28 AM, Angelo Papenhoff <aap at papnet.eu> wrote:
>>
>> On 27/10/18, Doug McIlroy wrote:
>>>> Now it could be that v7 troff is perfectly capable of generating the
>>>> manual just like older troff would have.
>>>
>>> On taking over editorship for v7, I added some macros to the -man
>>> package. I don't specifically recall making any incompatible
>>> changes. If there were any, they'd most likely show up in
>>> the title and synopsis and should be fixable by a minor tweak
>>> to -man. I'm quite confident that there would be no problems
>>> with troff proper.
>>
>> I didn't mean the macros. They are not problematic at all.
>> It's the idea how much a point is compared to an inch that has
>> changed over time i think.
>>
>> aap
> 
> From my experience in the world of prepress 723pts == 10in.
> 
> Then Adobe unleashed PostScript on us and redefined the point
> so that 72pt == 1in.
> 
> I’m unaware of any other definitions of a point.
> 
> -Milo
> 


 Wikipedia lists historical definitions, but the only definitions I've
used myself are TeX's and PostScript's.

https://en.wikipedia.org/wiki/Point_(typography)

--Toby


From beebe at math.utah.edu  Sun Oct 28 00:18:06 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sat, 27 Oct 2018 08:18:06 -0600
Subject: [TUHS] Reconstructed and newly set UNIX Manual
Message-ID: <CMM.0.95.0.1540649886.beebe@gamma.math.utah.edu>

Angelo Papenhoff <aap at papnet.eu> writes about the conversion of
printer points to other units:

>> >From my experience in the world of prepress 723pts == 10in.
>>
>> Then Adobe unleashed PostScript on us and redefined the point
>> so that 72pt == 1in.
>>
>> Ibunaware of any other definitions of a point.

The most important other one is that used by the TeX typesetting
system: 72.27pt is one inch.  TeX calls the Adobe PostScript one a big
point: 72bp == 1in.  Here is what Don Knuth, TeX's author, wrote on
page 58 of The TeXbook (Addison-Wesley, 1986, ISBN 0-201-13447-0):

>> ...
>>     The units have been defined here so that precise conversion to sp
>>     is efficient on a wide variety of machines. In order to achieve
>>     this, TeX's ``pt'' has been made slightly larger than the official
>>     printer's point, which was defined to equal exactly .013837in by
>>     the American Typefounders Association in 1886 [cf. National Bureau
>>     of Standards Circular 570 (1956)]. In fact, one classical point is
>>     exactly .99999999pt, so the ``error'' is essentially one part in
>>     10^8.  This is more than two orders of magnitude less than the
>>     amount by which the inch itself changed during 1959, when it
>>     shrank to 2.54cm from its former value of (1/0.3937)cm; so there
>>     is no point in worrying about the difference. The new definition
>>     72.27pt=1in is not only better for calculation, it is also easier
>>     to remember.
>> ...

Here sp is a scaled point: 65536sp = 1pt.  The distance 1sp is smaller
than the wavelength of visible light, and is thus not visible to
humans.

TeX represents physical dimensions as integer numbers of scaled
points, or equivalently, fixed-point numbers in points, with a 16-bit
fraction.  With a 32-bit word size, that leaves 16 bits for the
integer part, of which the high-order bit is a sign, and the adjacent
bit is an overflow indicator.  That makes TeX's maximum dimension on
such machines 1sp below 2^14 (= 16,384) points, or about 5.75 meters
or 18.89 feet.

-------------------------------------------------------------------------------
- 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 ralph at inputplus.co.uk  Sun Oct 28 01:19:33 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 27 Oct 2018 16:19:33 +0100
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <D980BC1E-288D-4679-AB86-8028FA5B1E2E@cs.uwlax.edu>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
 <20181027122834.GA97675@indra.papnet.eu>
 <D980BC1E-288D-4679-AB86-8028FA5B1E2E@cs.uwlax.edu>
Message-ID: <20181027151933.A834C1FADC@orac.inputplus.co.uk>

Hi Milo,

> I'm unaware of any other definitions of a point.

Below is an extract from GNU units 2.17's
/usr/share/units/definitions.units.

#
# Printing
#

fournierpoint           0.1648 inch / 12  # First definition of the printers
                                          # point made by Pierre Fournier who
                                          # defined it in 1737 as 1|12 of a
                                          # cicero which was 0.1648 inches.
olddidotpoint           1|72 frenchinch   # François Ambroise Didot, one of
                                          # a family of printers, changed
                                          # Fournier's definition around 1770
                                          # to fit to the French units then in
                                          # use.
bertholdpoint           1|2660 m          # H. Berthold tried to create a
                                          # metric version of the didot point
                                          # in 1878.
INpoint                 0.4 mm            # This point was created by a
                                          # group directed by Fermin Didot in
                                          # 1881 and is associated with the
                                          # imprimerie nationale.  It doesn't
                                          # seem to have been used much.
germandidotpoint        0.376065 mm       # Exact definition appears in DIN
                                          # 16507, a German standards document
                                          # of 1954.  Adopted more broadly  in
                                          # 1966 by ???
metricpoint             3|8 mm            # Proposed in 1977 by Eurograf
oldpoint                1|72.27 inch      # The American point was invented
printerspoint           oldpoint          # by Nelson Hawks in 1879 and
texpoint                oldpoint          # dominates USA publishing.
                                          # It was standardized by the American
                                          # Typefounders Association at the
                                          # value of 0.013837 inches exactly.
                                          # Knuth uses the approximation given
                                          # here (which is very close).  The
                                          # comp.fonts FAQ claims that this
                                          # value is supposed to be 1|12 of a
                                          # pica where 83 picas is equal to 35
                                          # cm.  But this value differs from
                                          # the standard.
texscaledpoint          1|65536 texpoint  # The TeX typesetting system uses
texsp                   texscaledpoint    # this for all computations.
computerpoint           1|72 inch         # The American point was rounded
point                   computerpoint
computerpica            12 computerpoint  # to an even 1|72 inch by computer
postscriptpoint         computerpoint     # people at some point.
pspoint                 postscriptpoint
twip                    1|20 point        # TWentieth of an Imperial Point
Q                       1|4 mm            # Used in Japanese phototypesetting
                                          # Q is for quarter
frenchprinterspoint     olddidotpoint
didotpoint              germandidotpoint  # This seems to be the dominant value
europeanpoint           didotpoint        # for the point used in Europe
cicero                  12 didotpoint

stick                   2 inches

# Type sizes

excelsior               3 oldpoint
brilliant               3.5 oldpoint
diamondtype             4 oldpoint
pearl                   5 oldpoint
agate                   5.5 oldpoint  # Originally agate type was 14 lines per
                                      #   inch, giving a value of 1|14 in.
ruby                    agate         # British
nonpareil               6 oldpoint
mignonette              6.5 oldpoint
emerald                 mignonette    # British
minion                  7 oldpoint
brevier                 8 oldpoint
bourgeois               9 oldpoint
longprimer              10 oldpoint
smallpica               11 oldpoint
pica                    12 oldpoint
english                 14 oldpoint
columbian               16 oldpoint
greatprimer             18 oldpoint
paragon                 20 oldpoint
meridian                44 oldpoint
canon                   48 oldpoint

# German type sizes

nonplusultra            2 didotpoint
brillant                3 didotpoint
diamant                 4 didotpoint
perl                    5 didotpoint
nonpareille             6 didotpoint
kolonel                 7 didotpoint
petit                   8 didotpoint
borgis                  9 didotpoint
korpus                  10 didotpoint
corpus                  korpus
garamond                korpus
mittel                  14 didotpoint
tertia                  16 didotpoint
text                    18 didotpoint
kleine_kanon            32 didotpoint
kanon                   36 didotpoint
grobe_kanon             42 didotpoint
missal                  48 didotpoint
kleine_sabon            72 didotpoint
grobe_sabon             84 didotpoint

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From clemc at ccc.com  Sun Oct 28 01:53:20 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 27 Oct 2018 11:53:20 -0400
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2MaUyycL+hUaHo1fJ-Tzqs-gqfb0V=hdBgx7cALtCJk8Q@mail.gmail.com>

> Now it could be that v7 troff is perfectly capable of generating the
> manual just like older troff would have.

Angelo - If you worried about the 'look' of a page, I think the thing to be
more worried about is the differences in very early troff is the definition
of the CAT typesetter and how it maps what you have now (PostScript).
 Programs like vcat and later pscat, that were built by reverse engineering
the output of troff and then did a sort of crude mapping to the raster
fonts that were publically available.

At the time, the primary fonts kicking around (the Arpanet) were the Hershey
Fonts <https://en.wikipedia.org/wiki/Hershey_fonts> (which were vector
fonts for CRTs).  I'm fairly sure that Les Earnest and Larry Tessler used
them with a film recorder at Stanford on the PDP-10 being driven by "Pub"
(which was a contemporary to troff and ran on the PDP-10s).   Rich Johnsson
of CMU wrote the code for the original XGP* (at 200 dpi) and I'm not sure
who did the translation from vectors to bits although Chuck Geschke (Wulf’s
first PhD student @ CMU, founder of Adobe) I think had his hand in it **

The original UNIX 'plotter' emulator for troff (the vcat family of UNIX
tools originally done by Tom Ferin at UCSF IIRC) used the Hershey fonts
that came from the XGP work from the PDP-10.   This worked and as users, we
were pretty happy because most of us did not have access to real
typesetters, much less something as cool at the XGP.   But the fonts were
'ugly' in comparison to future ideas like Metafont an PS, where as, Adobe's
pscat was using a more precise definition.

That said, in those days my eye was not trained enough to see a many of the
differences.   But some production oriented folks (like Tim O'Reilly) used
to complain that is the AT&T output (CAT4) was different from what the
Imagen*** produced [which was the first large scale 'laser printer'
replacement after the Bensen Varian (/dev/va) and other 'wet' plotters].

Clem

* In '64 Xerox invented 'long distance xerography' (LDX) - which was a FAX
system that used a monochrome CRT to draw a single line of pixels on a
xerographic 'drum.'   Xerox loaned/gave one to CMU, Stanford and MIT in
'72.   CMU spliced on to a PDP-11 and had it running my March '72 [BTW, I
recently found pictures of the original toilet paper diploma printing hack
using it].  Stanford and MIT duplicated the CMU trick, with Stanford's XGP
coming online Jan '73 and MIT sometime thereafter].

**Great historical side story - Chuck Geschke filed the first PhD printed
on XGP (at CMU) and it was originally rejected because the CMU library
wanted the 'originals.'   It took Wulf 6-9 months to convince the
administration there were no other 'masters' - the library had the
originals.

***We had a early Imagen at Masscomp, Tim duplicated our set up in
Cambridge shortly there after.   In fact, I know Tim ended buying a CAT/4
early on in ORA's life (used IIRC) -- which I think the first used to set
the X-11 manuals, which of course what what 'made' ORA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181027/c2597c6a/attachment.html>

From lm at mcvoy.com  Sun Oct 28 02:25:54 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 27 Oct 2018 09:25:54 -0700
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <CAC20D2MaUyycL+hUaHo1fJ-Tzqs-gqfb0V=hdBgx7cALtCJk8Q@mail.gmail.com>
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
 <CAC20D2MaUyycL+hUaHo1fJ-Tzqs-gqfb0V=hdBgx7cALtCJk8Q@mail.gmail.com>
Message-ID: <20181027162554.GA25738@mcvoy.com>

On Sat, Oct 27, 2018 at 11:53:20AM -0400, Clem Cole wrote:
> At the time, the primary fonts kicking around (the Arpanet) were the Hershey
> Fonts <https://en.wikipedia.org/wiki/Hershey_fonts> (which were vector
> fonts for CRTs).  

Oh, man, do I remember them.  While better than nothing, they left a lot
to be desired.

> That said, in those days my eye was not trained enough to see a many of the
> differences.   But some production oriented folks (like Tim O'Reilly) used
> to complain that is the AT&T output (CAT4) was different from what the
> Imagen*** produced [which was the first large scale 'laser printer'
> replacement after the Bensen Varian (/dev/va) and other 'wet' plotters].

A friend of mine (cc-ed), used to really care about this stuff.  I can
still remember him getting out an eye loup and looking at the apple laser
printer output.  I can't remember if he liked it or was disappointed
but he cared.


From aap at papnet.eu  Sun Oct 28 03:15:04 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Sat, 27 Oct 2018 19:15:04 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026205938.GA10723@minnie.tuhs.org>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181026205938.GA10723@minnie.tuhs.org>
Message-ID: <20181027171504.GA8362@indra.papnet.eu>

On 27/10/18, Warren Toomey wrote:
> On Fri, Oct 26, 2018 at 09:46:36PM +0200, Angelo Papenhoff wrote:
> > The last couple of days I worked on re-setting the V3-V6 manuals.
> > Now for the questions that I arose while I was doing this:
> > Where does the V5 manual come from?
> 
> The scan at 
> https://www.tuhs.org//Archive/Distributions/Research/Dennis_v5/v5man.pdf
> is a scan I did from a photocopy of the 5th Edition manuals that Norman
> Wilson posted to me.

Is there another copy of that manual perhaps?

I just noticed the v2 scan is not complete either. It's missing at least
one page of ed(I) and the v1 and v3 manuals are different enough that I
don't know what to reconstruct.

aap


From aap at papnet.eu  Sun Oct 28 03:41:29 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Sat, 27 Oct 2018 19:41:29 +0200
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181027171504.GA8362@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181026205938.GA10723@minnie.tuhs.org>
 <20181027171504.GA8362@indra.papnet.eu>
Message-ID: <20181027174129.GA9356@indra.papnet.eu>

On 27/10/18, Angelo Papenhoff wrote:
> I just noticed the v2 scan is not complete either. It's missing at least
> one page of ed(I) and the v1 and v3 manuals are different enough that I
> don't know what to reconstruct.

nvm this. didn't see the page od(I) is just between ed(I) pages.


From lars at nocrew.org  Sun Oct 28 05:45:44 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 27 Oct 2018 19:45:44 +0000
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <CAC20D2MaUyycL+hUaHo1fJ-Tzqs-gqfb0V=hdBgx7cALtCJk8Q@mail.gmail.com>
 (Clem Cole's message of "Sat, 27 Oct 2018 11:53:20 -0400")
References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU>
 <CAC20D2MaUyycL+hUaHo1fJ-Tzqs-gqfb0V=hdBgx7cALtCJk8Q@mail.gmail.com>
Message-ID: <7w5zxnkwbb.fsf@junk.nocrew.org>

Clem Cole <clemc at ccc.com> writes:
> * In '64 Xerox invented 'long distance xerography' (LDX) - which was a
> FAX system that used a monochrome CRT to draw a single line of pixels
> on a xerographic 'drum.' Xerox loaned/gave one to CMU, Stanford and
> MIT in '72.  CMU spliced on to a PDP-11 and had it running my March
> '72 [BTW, I recently found pictures of the original toilet paper
> diploma printing hack using it].  Stanford and MIT duplicated the CMU
> trick, with Stanford's XGP coming online Jan '73 and MIT sometime
> thereafter].

Thanks, that goes into my records.  Can we see the pictures?

MIT attached a PDP-11/10 or 11/20, we don't quite know which.  But we
have the code that ran on it.

MIT later got a Dover, also from Xerox.  I'll share this artistic work
from the AI lab file HUMOR; DOVER POEM.


Dover, oh Dover, arisen from dead.
Dover, oh Dover, awoken from bed.
Dover, oh Dover, welcome back to the Lab.
Dover, oh Dover, we've missed your clean hand...

And now your toner's toney,
And your paper near pure white,
The smudges on your soul are gone
And your output's clean as light..

We've labored with your father,
The venerable XGP,
But his slow artistic hand,
Lacks your clean velocity.

Theses and papers
And code in a queue
Dover, oh Dover,
We've been waiting for you.

Disk blocks aplenty
Await your laser drawn lines,
Your intricate fonts,
Your pictures and signs.

Your amputative absence
Has made the Ten dumb,
Without you, Dover,
We're system untounged-

DRAW Plots and TEXage
Have been biding their time,
With LISP code and programs,
And this crufty rhyme.

Dover, oh Dover,
We welcome you back,
Though still you may jam,
You're on the right track.


From lars at nocrew.org  Mon Oct 29 07:34:49 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 28 Oct 2018 21:34:49 +0000
Subject: [TUHS] Archaic yacc C grammar
Message-ID: <7wsh0piwli.fsf@junk.nocrew.org>

Hello,

This is Alan Snyder's C grammar.  It's supposedly for yacc, but it's
probably using some really ancient version.  Maybe from when Alan did a
stint at Bell labs and converted yacc from B to C.

Does anyone recognize this type of yacc input?  I don't have the
corresponding yacc version, and the one in V6 isn't happy about this
file.  What would it take to update the grammar for V6 yacc?  Add in
some %term, replace \\ with %%?



	#     C GRAMMAR     #
	#    28 May 1978    #
	#    Alan Snyder    #


#	26 acceptable conflicts:

	2 S/R conflicts for (parsing) ambiguity between
		declarators and function_declarators
	1 S/R conflict for the C ELSE ambiguity
	4 R/R conflicts for the (parsing) problem with regard
		to integer constants as initial_values
	12 R/R conflicts for the (parsing) problem with regard
		to identifiers in function calls
	1 R/R conflict for the (parsing) problem with regard
		to identifiers in goto statements
	4 R/R conflicts and 1 S/R conflict for TYPEDEFs
	1 S/R conflict for ambiguous cast types
		(int ()) = (int x()) not (int (x))

	Approximate description:

 18	S/R	(	shift 37	reduce 141
 50	S/R	(	shift 37	reduce 71
 81	S/R	(	shift 37	reduce 71
113	R/R	(	reduce 141	reduce 140
113	R/R	(	reduce 159	reduce 140
113	R/R	*	reduce 159	reduce 141
113	S/R	:	shift 199	reduce 141
183	R/R	,	reduce 203	reduce 24
183	R/R	}	reduce 203	reduce 24
204	R/R	(	reduce 159	reduce 140
206	R/R	(	reduce 148	reduce 139
207	R/R	(	reduce 147	reduce 139
208	R/R	(	reduce 145	reduce 139
209	R/R	(	reduce 144	reduce 139
210	R/R	(	reduce 146	reduce 139
211	R/R	(	reduce 149	reduce 139
212	R/R	(	reduce 150	reduce 139
215	R/R	(	reduce 159	reduce 140
215	R/R	;	reduce 159	reduce 138
225	R/R	(	reduce 151	reduce 139
228	R/R	(	reduce 159	reduce 140
284	R/R	,	reduce 203	reduce 25
284	R/R	}	reduce 203	reduce 25
291	S/R	)	shift 339	reduce 165
343	R/R	(	reduce 153	reduce 139
360	S/R	ELSE	shift 369	reduce 94

#

	#     terminal symbols     #

';' '}' '{' ']' '[' ')' '(' ':'
',' '.' '?' '~' '!' '&' '|' '^'
'%' '/' '*' '-' '+' '=' '<' '>'
'++' '--' '==' '!=' '<=' '>=' '<<' '>>'
'->' '=op' '&&' '||' 'c'
INT CHAR FLOAT DOUBLE STRUCT AUTO STATIC
EXTERN RETURN GOTO IF ELSE SWITCH
BREAK CONTINUE WHILE DO FOR DEFAULT CASE
ENTRY REGISTER SIZEOF LONG SHORT UNSIGNED TYPEDEF 'l'
'm' 'n' 'o' 'p' 'q' 'r' 's'
identifier integer floatcon string

	#     precedence information     #

\< ','
\> '=' '=op'
\> '?' ':'
\< '||'
\< '&&'
\< '|'
\< '^'
\< '&'
\< '==' '!='
\< '<' '>' '<=' '>='
\< '<<' '>>'
\< '+' '-'
\< '*' '/' '%'
\> '!' '~'
\> '++' '--' SIZEOF
\< '[' '(' '.' '->'

\\

	#     external definitions     #

program:
	  program external_definition
	|

external_definition:
	  declaration
	| function_definition

function_definition:
	  function_specification function_body		{afdef(#1,#2);}

function_specification:
	  decl_specifiers function_declarator		{val=afdcl(1);}
	| function_declarator				{val=afdcl(0);}

function_body:
	  formal_declarations compound_statement	{val=#2;}

formal_declarations:
	  formal_decl_list				{afpdcl();}
	| 						{afpdcl();}

compound_statement:
	  begin declaration_list statement_list end	{val=#3;}
	| begin statement_list end			{val=#2;}

init_declarator_list:
	  init_declarator
	| init_declarator_list ',' init_declarator 

init_declarator:
	  $declarator initializer		{aidecl();}
	| declarator				{aidecl();}
	| function_declarator			{adeclr(maktyp());}

initializer:
	  initial_value
	| '{' initial_value_expression_list '}'
	| '{' initial_value_expression_list ',' '}'

initial_value_expression_list:
	  initial_value_expression
	| initial_value_expression_list ',' initial_value_expression

initial_value:
	  integer				{inz(i_int,#1);}
	| '-' integer				{inz(i_int,-#2);}
	| floatcon				{inz(i_float,#1);}
	| '-' floatcon				{inz(i_negfloat,#2);}
	| identifier				{inz(i_idn,#1);}
	| '&' identifier			{inz(i_idn,#2);}
	| string 				{inz(i_string,#1);}

initial_value_expression:
	  constant				{inz(i_int,#1);}
	| initial_value

	#     declarations     #

declaration_list:
	  declaration
	| declaration_list declaration

declaration:
	  decl_specifiers init_declarator_list ';'
	| literal_type_specifier ';'

decl_specifiers:
	  type_specifier			{attrib(-1,#1);}
	| sc_specifier type_specifier		{attrib(#1,#2);}
	| type_specifier sc_specifier		{attrib(#2,#1);}

type_specifier:
	  type_identifier
	| literal_type_specifier

literal_type_specifier:
	  INT					{val=TINT;}
	| CHAR					{val=TCHAR;}
	| FLOAT					{val=TFLOAT;}
	| DOUBLE				{val=TDOUBLE;}
	| LONG					{val=TINT;}
	| LONG INT				{val=TINT;}
	| SHORT					{val=TINT;}
	| SHORT INT				{val=TINT;}
	| LONG FLOAT				{val=TDOUBLE;}
	| UNSIGNED				{val=TINT;}
	| UNSIGNED INT				{val=TINT;}
	| struct '{' type_decl_list '}'			{val=astruct(NULL,#3);}
	| struct $identifier '{' type_decl_list '}'	{val=astruct(#2,#4);}
	| struct identifier	 			{val=aostruct(#2);}

sc_specifier:
	  AUTO					{val=c_auto;}
	| STATIC				{val=c_static;}
	| EXTERN				{val=c_extern;}
	| REGISTER				{val=c_auto;}
	| TYPEDEF				{val=c_typedef;}

declarator_list:
	  declarator
	| declarator_list ',' declarator 

declarator:
	  dclr					{val=adeclr(maktyp());}
	| identifier ':' constant		{val=adeclr(afield(#1,#3));}
	| ':' constant				{val=adeclr(afield(-1,#2));}

$declarator:
	  dclr					{aiinz(adeclr(maktyp()));}

dclr:
	'*' dclr				{val=adclr(#2,MPTR);}
	| dclr '(' ')'				{val=adclr(#1,MFUNC);}
	| dclr '[' ']'				{val=adclr(#1,MARRAY,1);}
	| dclr '[' constant ']'			{val=adclr(#1,MARRAY,#3);}
	| identifier  				{val=adclr(0,0);}
	| '(' dclr ')' 				{val=#2;}

function_declarator:
	  '*' function_declarator		{val=adclr(#2,MPTR);}
	| function_declarator '(' ')'		{val=adclr(#1,MFUNC);}
	| function_declarator '[' ']'		{val=adclr(#1,MARRAY,1);}
	| function_declarator '[' constant ']'	{val=adclr(#1,MARRAY,#3);}
	| identifier '(' ')'			{val=adclr(adclr(0,0),MFUNC);
							parml=0;}
	| identifier '(' parameter_list ')'	{val=adclr(adclr(0,0),MFUNC);
							parml=#3;}
	| '(' function_declarator ')'		{val=#2;}

parameter_list:
	  identifier				{val=push(#1);}
	| parameter_list ',' identifier		{push(#3);}

formal_decl_list:
	  formal_declaration
	| formal_decl_list formal_declaration

formal_declaration:
	  type_declaration
	| REGISTER type_declaration

type_decl_list:
	  type_declaration
	| type_decl_list type_declaration

type_declaration:
	  $type_specifier declarator_list ';'	{in_type_def=0;
						val=#2;}

$type_specifier:
	  type_specifier			{in_type_def=1;
						attrib(-1,#1);}

	#     statements     #

statement_list:
	  statement
	| statement_list statement		{val=astmtl(#1,#2);}

statement:
	  expression  ';'					{val=aexprstmt(#1);}
	| compound_statement
	| IF '(' expression ')' statement	 		{val=aif(#3,#5,0);}
	| IF '(' expression ')' statement ELSE statement	{val=aif(#3,#5,#7);}
	| while '(' expression ')' statement	 		{val=awhile(#3,#5);}
	| for '(' .expression ';' .expression ';' .expression ')' statement
								{val=afor(#3,#5,#7,#9);}
	| do statement WHILE '(' expression ')' ';'		{val=ado(#2,#5);}
	| switch '(' expression ')' statement			{val=aswitch(#3,#5);}
	| CASE constant ':' statement				{val=acase(#2,#4);}
	| DEFAULT ':' statement					{val=adefault(#3);}
	| BREAK ';'						{val=abreak();}
	| CONTINUE ';'						{val=acontinue();}
	| RETURN ';'						{val=areturn(0);}
	| RETURN expression ';'					{val=areturn(#2);}
	| GOTO lexpression ';'					{val=agoto(#2);}
	| identifier ':' statement				{val=alabel(#1,#3);}
	| ENTRY identifier ':' statement			{val=aentry(#2,#4);}
	| ';' 							{val=anull();} 


	#     expressions     #

.expression:
	  expression
	|			{val=0;}

expression_list:
	  expression	\= '='
	| expression_list ',' expression 		{val=aelist(#1,#3);}

expression:
	  expression '*' expression		{val=node(n_times,#1,#3);}
	| expression '/' expression		{val=node(n_div,#1,#3);}
	| expression '%' expression		{val=node(n_mod,#1,#3);}
	| expression '+' expression		{val=node(n_plus,#1,#3);}
	| expression '-' expression		{val=node(n_minus,#1,#3);}
	| expression '<<' expression		{val=node(n_ls,#1,#3);}
	| expression '>>' expression		{val=node(n_rs,#1,#3);}
	| expression '<' expression		{val=node(n_lt,#1,#3);}
	| expression '>' expression		{val=node(n_gt,#1,#3);}
	| expression '<=' expression		{val=node(n_le,#1,#3);}
	| expression '>='  expression		{val=node(n_ge,#1,#3);}
	| expression '=='  expression		{val=node(n_eq,#1,#3);}
	| expression '!='  expression		{val=node(n_ne,#1,#3);}
	| expression '&' expression		{val=node(n_band,#1,#3);}
	| expression '^' expression		{val=node(n_bxor,#1,#3);}
	| expression '|' expression		{val=node(n_bior,#1,#3);}
	| expression '&&' expression		{val=node(n_tv_and,#1,#3);}
	| expression '||' expression		{val=node(n_tv_or,#1,#3);}
	| expression '?' expression ':' expression
				{val=node(n_qmark,#1,node(n_colon,#3,#5));}
	| expression '=' expression		{val=node(n_assign,#1,#3);}
	| expression '=op' expression		{val=node(n_ars+#2,#1,#3);}
	| expression ',' expression		{val=node(n_comma,#1,#3);}
	| term 

# the following productions are ordered very carefully so that the
  desired thing is done in the case of a R/R conflict #

lexpression:
	  expression
	| identifier			{val=aidn(alidn(#1));}

fterm:
	  term
	| identifier			{val=aidn(afidn(#1));}

type_identifier:
	  identifier			{val=atidn(#1);}

term:
	  term '++'			{val=node(n_inca,#1);}
	| term '--'			{val=node(n_deca,#1);}
	| '*' term			{val=node(n_star,#2);}
	| '&' term			{val=node(n_addr,#2);}
	| '-' term			{val=node(n_uminus,#2);}
	| '!' term			{val=node(n_tvnot,#2);}
	| '~' term			{val=node(n_bnot,#2);}
	| '++' term			{val=node(n_incb,#2);}
	| '--' term			{val=node(n_decb,#2);}
	| SIZEOF term			{val=node(n_sizeof,#2);}
	| SIZEOF '(' cast_type ')' \= SIZEOF
					{val=node(n_int,1);} # hack #
	| '(' cast_type ')' term \= '++'
					{val=#4;} # hack #
	| term '[' expression ']'	{val=asubscript(#1,#3);}
	| fterm '(' expression_list ')'	{val=acall(#1,#3);}
	| fterm '(' ')'			{val=acall(#1,0);}
	| term '.' identifier		{val=adot(#1,#3);}
	| term '->' identifier		{val=aptr(#1,#3);}
	| identifier			{val=aidn(aeidn(#1));}
	| integer			{val=node(n_int,#1);}
	| floatcon			{val=node(n_float,#1);}
	| string			{val=node(n_string,#1);}
	| '(' expression ')' 		{val=#2;}

cast_type:	   literal_type_specifier null_decl

null_decl:	   # empty #
		|  '(' ')'
		|  '(' null_decl ')' '(' ')'
		|  '*' null_decl
		|  null_decl '[' ']'
		|  null_decl '[' constant ']'
		|  '(' null_decl ')'

while:		  WHILE			{apshw();}
do:		  DO			{apshd();}
for:		  FOR			{apshf();}
switch:		  SWITCH		{apshs();}
struct:		  STRUCT		{strlev++;}
$identifier:	  identifier		{val=astridn(#1);}
begin:		  '{'			{abegin();}
end:		  '}'			{aend();}

constant:
	  constant '*' constant		{val=#1*#3;}
	| constant '/' constant		{val=#1/#3;}
	| constant '%' constant		{val=#1%#3;}
	| constant '+' constant		{val=#1+#3;}
	| constant '-' constant		{val=#1-#3;}
	| constant '<<' constant	{val=#1<<#3;}
	| constant '>>' constant	{val=#1>>#3;}
	| constant '<' constant		{val=#1<#3;}
	| constant '>' constant		{val=#1>#3;}
	| constant '<=' constant	{val=#1<=#3;}
	| constant '>='  constant	{val=#1>=#3;}
	| constant '=='  constant	{val=#1==#3;}
	| constant '!='  constant	{val=#1!=#3;}
	| constant '&' constant		{val=#1&#3;}
	| constant '^' constant		{val=#1^#3;}
	| constant '|' constant		{val=#1|#3;}
	| constant '&&' constant	{val=#1&&#3;}
	| constant '||' constant	{val=#1||#3;}
	| constant '?' constant ':' constant
					{val=(#1?#3:#5);}
	| c_term 

c_term:
	  '-' c_term		{val= -#2;}
	| '!' c_term		{val= !#2;}
	| '~' c_term		{val= ~#2;}
	| integer
	| '(' constant ')'	{val=#2;}



From aap at papnet.eu  Mon Oct 29 08:57:09 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Sun, 28 Oct 2018 23:57:09 +0100
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026194636.GA11870@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
Message-ID: <20181028225709.GA71292@indra.papnet.eu>

V2 is reconstructed now.

So I noticed that V1-V3 all really used roff. Previously I thought that
V2 and V3 used nroff. I fixed my pipeline a bit, also for troff.

All V2-V6 can be found here in new versions:
http://squoze.net/UNIX/v2man/	http://squoze.net/UNIX/v2man.tgz
http://squoze.net/UNIX/v3man/	http://squoze.net/UNIX/v3man.tgz
http://squoze.net/UNIX/v4man/	http://squoze.net/UNIX/v4man.tgz
http://squoze.net/UNIX/v5man/	http://squoze.net/UNIX/v5man.tgz
http://squoze.net/UNIX/v6man/	http://squoze.net/UNIX/v6man.tgz
V2 and V3 are html only but include the intro pages now,
they're also paginated.
V4-V6 are pretty much the same as before, maybe little changes due to
fixes in the pipeline.

Problems:
nroff(I) is missing
some teletype specific things, like overstruck characters, but see
github for a list.

aap


From clemc at ccc.com  Mon Oct 29 10:15:26 2018
From: clemc at ccc.com (Clem cole)
Date: Sun, 28 Oct 2018 20:15:26 -0400
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181028225709.GA71292@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
 <20181028225709.GA71292@indra.papnet.eu>
Message-ID: <1C6C82CF-5F61-4184-88C6-B15B70783CE3@ccc.com>

Angelo.  I can not thank you enough.  This is wonderful work.  

Clem

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Oct 28, 2018, at 6:57 PM, Angelo Papenhoff <aap at papnet.eu> wrote:
> 
> V2 is reconstructed now.
> 
> So I noticed that V1-V3 all really used roff. Previously I thought that
> V2 and V3 used nroff. I fixed my pipeline a bit, also for troff.
> 
> All V2-V6 can be found here in new versions:
> http://squoze.net/UNIX/v2man/    http://squoze.net/UNIX/v2man.tgz
> http://squoze.net/UNIX/v3man/    http://squoze.net/UNIX/v3man.tgz
> http://squoze.net/UNIX/v4man/    http://squoze.net/UNIX/v4man.tgz
> http://squoze.net/UNIX/v5man/    http://squoze.net/UNIX/v5man.tgz
> http://squoze.net/UNIX/v6man/    http://squoze.net/UNIX/v6man.tgz
> V2 and V3 are html only but include the intro pages now,
> they're also paginated.
> V4-V6 are pretty much the same as before, maybe little changes due to
> fixes in the pipeline.
> 
> Problems:
> nroff(I) is missing
> some teletype specific things, like overstruck characters, but see
> github for a list.
> 
> aap


From dave at horsfall.org  Mon Oct 29 11:05:06 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 29 Oct 2018 12:05:06 +1100 (EST)
Subject: [TUHS] First ARPAnet transmission
Message-ID: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>

Of interest to the old farts here...

At 22:30 (but which timezone?) on this day in 1969 the first packet got as 
far as "lo" (for "login") then crashed on the "g".

More details over on http://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET
(with thanks to Bill Cheswick for the link).

-- Dave


From dave at horsfall.org  Mon Oct 29 11:48:03 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 29 Oct 2018 12:48:03 +1100 (EST)
Subject: [TUHS] In memoriam: Jon Postel
In-Reply-To: <20181016111307.26DD318C08D@mercury.lcs.mit.edu>
References: <20181016111307.26DD318C08D@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1810291247230.58929@aneurin.horsfall.org>

On Tue, 16 Oct 2018, Noel Chiappa wrote:

>    > From: Dave Horsfall
>
>    > We lost Jon Postel, regarded as the Father of the Internet
>
> Vint and Bob Kahn might disagree with that that... :-)

[...]

Thanks for the correction.

-- Dave


From grog at lemis.com  Mon Oct 29 12:10:23 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 29 Oct 2018 13:10:23 +1100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
Message-ID: <20181029021023.GA27974@eureka.lemis.com>

On Monday, 29 October 2018 at 12:05:06 +1100, Dave Horsfall wrote:
> Of interest to the old farts here...
>
> At 22:30 (but which timezone?) on this day in 1969 the first packet got as
> far as "lo" (for "login") then crashed on the "g".

The time zone was Pacific Time.  For me it happened on the following
day, coincidentally the day I first interacted with a computer.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181029/f663f566/attachment.sig>

From dave at horsfall.org  Mon Oct 29 16:33:56 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 29 Oct 2018 17:33:56 +1100 (EST)
Subject: [TUHS] Another one (Was: In memoriam: Jon Postel)
In-Reply-To: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1810291733160.58929@aneurin.horsfall.org>

On Tue, 16 Oct 2018, Noel Chiappa wrote:

>    > From: Dave Horsfall
>
>    > We lost ... on this day
>
> An email from someone on a related topic has reminded me of someone else you
> should make sure is only your list (not sure if you already have him):
> J. C. R. Licklider; we lost him on June 26, 1990.

[...]

He is now :-)  Thanks.

-- Dave


From dave at horsfall.org  Mon Oct 29 16:42:58 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 29 Oct 2018 17:42:58 +1100 (EST)
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181029021023.GA27974@eureka.lemis.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
Message-ID: <alpine.BSF.2.21.9999.1810291739330.58929@aneurin.horsfall.org>

On Mon, 29 Oct 2018, Greg 'groggy' Lehey wrote:

> The time zone was Pacific Time.  For me it happened on the following 
> day, coincidentally the day I first interacted with a computer.

Thanks; I try and use local time whenever possible, to respect those who 
were there at the time.

-- Dave


From michael at kjorling.se  Mon Oct 29 17:16:52 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Mon, 29 Oct 2018 07:16:52 +0000
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181029021023.GA27974@eureka.lemis.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
Message-ID: <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>

On 29 Oct 2018 13:10 +1100, from grog at lemis.com (Greg 'groggy' Lehey):
> On Monday, 29 October 2018 at 12:05:06 +1100, Dave Horsfall wrote:
>> At 22:30 (but which timezone?) on this day in 1969 the first packet got as
>> far as "lo" (for "login") then crashed on the "g".
> 
> The time zone was Pacific Time.  For me it happened on the following
> day, coincidentally the day I first interacted with a computer.

So 1969-10-30 05:30 UTC?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From lars at nocrew.org  Mon Oct 29 17:31:24 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 29 Oct 2018 07:31:24 +0000
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <1dbc3d888e7be7a2c93e497eac14bcd9f43c72fc@webmail.yaccman.com>
 (Steve Johnson's message of "Sun, 28 Oct 2018 20:00:42 -0700")
References: <1dbc3d888e7be7a2c93e497eac14bcd9f43c72fc@webmail.yaccman.com>
Message-ID: <7wftwpi4z7.fsf@junk.nocrew.org>

Steve Johnson wrote:
> Looking at the reserved words, there is one, ENTRY, that I've never
> heard of (although FORTRAN had an ENTRY statement), and there is
> STRUCT but no UNION. Also, he uses val= instead of $$=. There don't
> seem to be any nontrivial assignment ops (neither += or =+).

This is for Snyder's C compiler.  There is something called =op which
is guess is for =+ etc.

> I'm guessing either Al wrote it from scratch or based it on some other
> similar program.

Looks like you're right.  I found this in another file, so it would seem
he wrote it back at MIT:

  "The original YACC was designed and implemented on a PDP-11/45 and a
  Honeywell 6000 by S. C. Johnson at Bell Laboratories.  The version
  described in this paper was implemented on the PDP-10 by Alan Snyder.


From scj at yaccman.com  Mon Oct 29 13:00:42 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 28 Oct 2018 20:00:42 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <7wsh0piwli.fsf@junk.nocrew.org>
Message-ID: <1dbc3d888e7be7a2c93e497eac14bcd9f43c72fc@webmail.yaccman.com>


I don't recognize this as any Yacc that my hands have touched.   
Looking at the reserved words,
there is one, ENTRY, that I've never heard of (although FORTRAN had an
ENTRY statement), 

and there is STRUCT but no UNION.  Also, he uses val= instead of
$$=.  There don't seem to be 

any nontrivial assignment ops (neither += or =+).

Al was at Bell Labs in 1973, and this is dated 5 years later.

The use of quotes for single character literals was in early Yaccs,
but it led to some strange-looking 

lexical analyzer code, and I quickly gave it up.

I'm guessing either Al wrote it from scratch or based it on some other
similar program.  LR parsing
made quite a stir in the 70's.

Can't help you though as far as how to generate a parser from this
input...

Steve

----- Original Message -----
From: "Lars Brinkhoff" <lars at nocrew.org>
To:<tuhs at tuhs.org>
Cc:
Sent:Sun, 28 Oct 2018 21:34:49 +0000
Subject:[TUHS] Archaic yacc C grammar

 Hello,

 This is Alan Snyder's C grammar. It's supposedly for yacc, but it's
 probably using some really ancient version. Maybe from when Alan did
a
 stint at Bell labs and converted yacc from B to C.

 Does anyone recognize this type of yacc input? I don't have the
 corresponding yacc version, and the one in V6 isn't happy about this
 file. What would it take to update the grammar for V6 yacc? Add in
 some %term, replace  with %%?

 # C GRAMMAR #
 # 28 May 1978 #
 # Alan Snyder #

 # 26 acceptable conflicts:

 2 S/R conflicts for (parsing) ambiguity between
 declarators and function_declarators
 1 S/R conflict for the C ELSE ambiguity
 4 R/R conflicts for the (parsing) problem with regard
 to integer constants as initial_values
 12 R/R conflicts for the (parsing) problem with regard
 to identifiers in function calls
 1 R/R conflict for the (parsing) problem with regard
 to identifiers in goto statements
 4 R/R conflicts and 1 S/R conflict for TYPEDEFs
 1 S/R conflict for ambiguous cast types
 (int ()) = (int x()) not (int (x))

 Approximate description:

 18 S/R ( shift 37 reduce 141
 50 S/R ( shift 37 reduce 71
 81 S/R ( shift 37 reduce 71
 113 R/R ( reduce 141 reduce 140
 113 R/R ( reduce 159 reduce 140
 113 R/R * reduce 159 reduce 141
 113 S/R : shift 199 reduce 141
 183 R/R , reduce 203 reduce 24
 183 R/R } reduce 203 reduce 24
 204 R/R ( reduce 159 reduce 140
 206 R/R ( reduce 148 reduce 139
 207 R/R ( reduce 147 reduce 139
 208 R/R ( reduce 145 reduce 139
 209 R/R ( reduce 144 reduce 139
 210 R/R ( reduce 146 reduce 139
 211 R/R ( reduce 149 reduce 139
 212 R/R ( reduce 150 reduce 139
 215 R/R ( reduce 159 reduce 140
 215 R/R ; reduce 159 reduce 138
 225 R/R ( reduce 151 reduce 139
 228 R/R ( reduce 159 reduce 140
 284 R/R , reduce 203 reduce 25
 284 R/R } reduce 203 reduce 25
 291 S/R ) shift 339 reduce 165
 343 R/R ( reduce 153 reduce 139
 360 S/R ELSE shift 369 reduce 94

 #

 # terminal symbols #

 ';' '}' '{' ']' '[' ')' '(' ':'
 ',' '.' '?' '~' '!' '&' '|' '^'
 '%' '/' '*' '-' '+' '=' '<' '>'
 '++' '--' '==' '!=' '<=' '>=' '<<' '>>'
 '->' '=op' '&&' '||' 'c'
 INT CHAR FLOAT DOUBLE STRUCT AUTO STATIC
 EXTERN RETURN GOTO IF ELSE SWITCH
 BREAK CONTINUE WHILE DO FOR DEFAULT CASE
 ENTRY REGISTER SIZEOF LONG SHORT UNSIGNED TYPEDEF 'l'
 'm' 'n' 'o' 'p' 'q' 'r' 's'
 identifier integer floatcon string

 # precedence information #

 < ','
 > '=' '=op'
 > '?' ':'
 < '||'
 < '&&'
 < '|'
 < '^'
 < '&'
 < '==' '!='
 < '<' '>' '<=' '>='
 < '<<' '>>'
 < '+' '-'
 < '*' '/' '%'
 > '!' '~'
 > '++' '--' SIZEOF
 < '[' '(' '.' '->'

 

 # external definitions #

 program:
 program external_definition
 |

 external_definition:
 declaration
 | function_definition

 function_definition:
 function_specification function_body {afdef(#1,#2);}

 function_specification:
 decl_specifiers function_declarator {val=afdcl(1);}
 | function_declarator {val=afdcl(0);}

 function_body:
 formal_declarations compound_statement {val=#2;}

 formal_declarations:
 formal_decl_list {afpdcl();}
 | {afpdcl();}

 compound_statement:
 begin declaration_list statement_list end {val=#3;}
 | begin statement_list end {val=#2;}

 init_declarator_list:
 init_declarator
 | init_declarator_list ',' init_declarator 

 init_declarator:
 $declarator initializer {aidecl();}
 | declarator {aidecl();}
 | function_declarator {adeclr(maktyp());}

 initializer:
 initial_value
 | '{' initial_value_expression_list '}'
 | '{' initial_value_expression_list ',' '}'

 initial_value_expression_list:
 initial_value_expression
 | initial_value_expression_list ',' initial_value_expression

 initial_value:
 integer {inz(i_int,#1);}
 | '-' integer {inz(i_int,-#2);}
 | floatcon {inz(i_float,#1);}
 | '-' floatcon {inz(i_negfloat,#2);}
 | identifier {inz(i_idn,#1);}
 | '&' identifier {inz(i_idn,#2);}
 | string {inz(i_string,#1);}

 initial_value_expression:
 constant {inz(i_int,#1);}
 | initial_value

 # declarations #

 declaration_list:
 declaration
 | declaration_list declaration

 declaration:
 decl_specifiers init_declarator_list ';'
 | literal_type_specifier ';'

 decl_specifiers:
 type_specifier {attrib(-1,#1);}
 | sc_specifier type_specifier {attrib(#1,#2);}
 | type_specifier sc_specifier {attrib(#2,#1);}

 type_specifier:
 type_identifier
 | literal_type_specifier

 literal_type_specifier:
 INT {val=TINT;}
 | CHAR {val=TCHAR;}
 | FLOAT {val=TFLOAT;}
 | DOUBLE {val=TDOUBLE;}
 | LONG {val=TINT;}
 | LONG INT {val=TINT;}
 | SHORT {val=TINT;}
 | SHORT INT {val=TINT;}
 | LONG FLOAT {val=TDOUBLE;}
 | UNSIGNED {val=TINT;}
 | UNSIGNED INT {val=TINT;}
 | struct '{' type_decl_list '}' {val=astruct(NULL,#3);}
 | struct $identifier '{' type_decl_list '}' {val=astruct(#2,#4);}
 | struct identifier {val=aostruct(#2);}

 sc_specifier:
 AUTO {val=c_auto;}
 | STATIC {val=c_static;}
 | EXTERN {val=c_extern;}
 | REGISTER {val=c_auto;}
 | TYPEDEF {val=c_typedef;}

 declarator_list:
 declarator
 | declarator_list ',' declarator 

 declarator:
 dclr {val=adeclr(maktyp());}
 | identifier ':' constant {val=adeclr(afield(#1,#3));}
 | ':' constant {val=adeclr(afield(-1,#2));}

 $declarator:
 dclr {aiinz(adeclr(maktyp()));}

 dclr:
 '*' dclr {val=adclr(#2,MPTR);}
 | dclr '(' ')' {val=adclr(#1,MFUNC);}
 | dclr '[' ']' {val=adclr(#1,MARRAY,1);}
 | dclr '[' constant ']' {val=adclr(#1,MARRAY,#3);}
 | identifier {val=adclr(0,0);}
 | '(' dclr ')' {val=#2;}

 function_declarator:
 '*' function_declarator {val=adclr(#2,MPTR);}
 | function_declarator '(' ')' {val=adclr(#1,MFUNC);}
 | function_declarator '[' ']' {val=adclr(#1,MARRAY,1);}
 | function_declarator '[' constant ']' {val=adclr(#1,MARRAY,#3);}
 | identifier '(' ')' {val=adclr(adclr(0,0),MFUNC);
 parml=0;}
 | identifier '(' parameter_list ')' {val=adclr(adclr(0,0),MFUNC);
 parml=#3;}
 | '(' function_declarator ')' {val=#2;}

 parameter_list:
 identifier {val=push(#1);}
 | parameter_list ',' identifier {push(#3);}

 formal_decl_list:
 formal_declaration
 | formal_decl_list formal_declaration

 formal_declaration:
 type_declaration
 | REGISTER type_declaration

 type_decl_list:
 type_declaration
 | type_decl_list type_declaration

 type_declaration:
 $type_specifier declarator_list ';' {in_type_def=0;
 val=#2;}

 $type_specifier:
 type_specifier {in_type_def=1;
 attrib(-1,#1);}

 # statements #

 statement_list:
 statement
 | statement_list statement {val=astmtl(#1,#2);}

 statement:
 expression ';' {val=aexprstmt(#1);}
 | compound_statement
 | IF '(' expression ')' statement {val=aif(#3,#5,0);}
 | IF '(' expression ')' statement ELSE statement {val=aif(#3,#5,#7);}
 | while '(' expression ')' statement {val=awhile(#3,#5);}
 | for '(' .expression ';' .expression ';' .expression ')' statement
 {val=afor(#3,#5,#7,#9);}
 | do statement WHILE '(' expression ')' ';' {val=ado(#2,#5);}
 | switch '(' expression ')' statement {val=aswitch(#3,#5);}
 | CASE constant ':' statement {val=acase(#2,#4);}
 | DEFAULT ':' statement {val=adefault(#3);}
 | BREAK ';' {val=abreak();}
 | CONTINUE ';' {val=acontinue();}
 | RETURN ';' {val=areturn(0);}
 | RETURN expression ';' {val=areturn(#2);}
 | GOTO lexpression ';' {val=agoto(#2);}
 | identifier ':' statement {val=alabel(#1,#3);}
 | ENTRY identifier ':' statement {val=aentry(#2,#4);}
 | ';' {val=anull();} 

 # expressions #

 .expression:
 expression
 | {val=0;}

 expression_list:
 expression = '='
 | expression_list ',' expression {val=aelist(#1,#3);}

 expression:
 expression '*' expression {val=node(n_times,#1,#3);}
 | expression '/' expression {val=node(n_div,#1,#3);}
 | expression '%' expression {val=node(n_mod,#1,#3);}
 | expression '+' expression {val=node(n_plus,#1,#3);}
 | expression '-' expression {val=node(n_minus,#1,#3);}
 | expression '<<' expression {val=node(n_ls,#1,#3);}
 | expression '>>' expression {val=node(n_rs,#1,#3);}
 | expression '<' expression {val=node(n_lt,#1,#3);}
 | expression '>' expression {val=node(n_gt,#1,#3);}
 | expression '<=' expression {val=node(n_le,#1,#3);}
 | expression '>=' expression {val=node(n_ge,#1,#3);}
 | expression '==' expression {val=node(n_eq,#1,#3);}
 | expression '!=' expression {val=node(n_ne,#1,#3);}
 | expression '&' expression {val=node(n_band,#1,#3);}
 | expression '^' expression {val=node(n_bxor,#1,#3);}
 | expression '|' expression {val=node(n_bior,#1,#3);}
 | expression '&&' expression {val=node(n_tv_and,#1,#3);}
 | expression '||' expression {val=node(n_tv_or,#1,#3);}
 | expression '?' expression ':' expression
 {val=node(n_qmark,#1,node(n_colon,#3,#5));}
 | expression '=' expression {val=node(n_assign,#1,#3);}
 | expression '=op' expression {val=node(n_ars+#2,#1,#3);}
 | expression ',' expression {val=node(n_comma,#1,#3);}
 | term 

 # the following productions are ordered very carefully so that the
 desired thing is done in the case of a R/R conflict #

 lexpression:
 expression
 | identifier {val=aidn(alidn(#1));}

 fterm:
 term
 | identifier {val=aidn(afidn(#1));}

 type_identifier:
 identifier {val=atidn(#1);}

 term:
 term '++' {val=node(n_inca,#1);}
 | term '--' {val=node(n_deca,#1);}
 | '*' term {val=node(n_star,#2);}
 | '&' term {val=node(n_addr,#2);}
 | '-' term {val=node(n_uminus,#2);}
 | '!' term {val=node(n_tvnot,#2);}
 | '~' term {val=node(n_bnot,#2);}
 | '++' term {val=node(n_incb,#2);}
 | '--' term {val=node(n_decb,#2);}
 | SIZEOF term {val=node(n_sizeof,#2);}
 | SIZEOF '(' cast_type ')' = SIZEOF
 {val=node(n_int,1);} # hack #
 | '(' cast_type ')' term = '++'
 {val=#4;} # hack #
 | term '[' expression ']' {val=asubscript(#1,#3);}
 | fterm '(' expression_list ')' {val=acall(#1,#3);}
 | fterm '(' ')' {val=acall(#1,0);}
 | term '.' identifier {val=adot(#1,#3);}
 | term '->' identifier {val=aptr(#1,#3);}
 | identifier {val=aidn(aeidn(#1));}
 | integer {val=node(n_int,#1);}
 | floatcon {val=node(n_float,#1);}
 | string {val=node(n_string,#1);}
 | '(' expression ')' {val=#2;}

 cast_type: literal_type_specifier null_decl

 null_decl: # empty #
 | '(' ')'
 | '(' null_decl ')' '(' ')'
 | '*' null_decl
 | null_decl '[' ']'
 | null_decl '[' constant ']'
 | '(' null_decl ')'

 while: WHILE {apshw();}
 do: DO {apshd();}
 for: FOR {apshf();}
 switch: SWITCH {apshs();}
 struct: STRUCT {strlev++;}
 $identifier: identifier {val=astridn(#1);}
 begin: '{' {abegin();}
 end: '}' {aend();}

 constant:
 constant '*' constant {val=#1*#3;}
 | constant '/' constant {val=#1/#3;}
 | constant '%' constant {val=#1%#3;}
 | constant '+' constant {val=#1+#3;}
 | constant '-' constant {val=#1-#3;}
 | constant '<<' constant {val=#1<<#3;}
 | constant '>>' constant {val=#1>>#3;}
 | constant '<' constant {val=#1<#3;}
 | constant '>' constant {val=#1>#3;}
 | constant '<=' constant {val=#1<=#3;}
 | constant '>=' constant {val=#1>=#3;}
 | constant '==' constant {val=#1==#3;}
 | constant '!=' constant {val=#1!=#3;}
 | constant '&' constant {val=#1}
 | constant '^' constant {val=#1^#3;}
 | constant '|' constant {val=#1|#3;}
 | constant '&&' constant {val=#1&}
 | constant '||' constant {val=#1||#3;}
 | constant '?' constant ':' constant
 {val=(#1?#3:#5);}
 | c_term 

 c_term:
 '-' c_term {val= -#2;}
 | '!' c_term {val= !#2;}
 | '~' c_term {val= ~#2;}
 | integer
 | '(' constant ')' {val=#2;}


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181028/8199abae/attachment.html>

From clemc at ccc.com  Tue Oct 30 00:19:43 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 29 Oct 2018 10:19:43 -0400
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
Message-ID: <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>

On Mon, Oct 29, 2018 at 4:01 AM Michael Kjörling <michael at kjorling.se>
wrote:

>
>
> So 1969-10-30 05:30 UTC?
>
I >>think<< it is more likely 06:30 UTC, as IIRC Daylight Saving Time
finished mid-month so I think it would have been UTC+8:00 [not +7:00 which
it would be now].   That said, Nixon [...shutter...] was in office and he
put the US went on DST in the winter at some point due to the oil crisis
(but I thought that was a year or so later).  I remember it all happening
at the time - but I can do not put precise dates on any of it.

If you want to be be 100% accurate and use UTC, then you would need to
check a precise calendar that had all those details to see how the US had
its clocks set on October 30, 1969.  The good news was the transmission
stayed with the same time zone, which as I said was Pacific (UCLA is in Los
Angeles area and SRI in the Bay Area - but both are California - which
follows US, DST rules).  The question is what were the rules that were in
effect that night.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181029/62a15f85/attachment.html>

From johnl at johnlabovitz.com  Tue Oct 30 01:34:50 2018
From: johnl at johnlabovitz.com (John Labovitz)
Date: Mon, 29 Oct 2018 11:34:50 -0400
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
Message-ID: <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>

On Oct 29, 2018, at 10:19 AM, Clem Cole <clemc at ccc.com> wrote:

> I >>think<< it is more likely 06:30 UTC, as IIRC Daylight Saving Time finished mid-month so I think it would have been UTC+8:00 [not +7:00 which it would be now].   That said, Nixon [...shutter...] was in office and he put the US went on DST in the winter at some point due to the oil crisis (but I thought that was a year or so later).  I remember it all happening at the time - but I can do not put precise dates on any of it.

According to tzdata...

% zdump -v America/Los_Angeles | grep 1969
America/Los_Angeles  Sun Apr 27 09:59:59 1969 UTC = Sun Apr 27 01:59:59 1969 PST isdst=0
America/Los_Angeles  Sun Apr 27 10:00:00 1969 UTC = Sun Apr 27 03:00:00 1969 PDT isdst=1
America/Los_Angeles  Sun Oct 26 08:59:59 1969 UTC = Sun Oct 26 01:59:59 1969 PDT isdst=1
America/Los_Angeles  Sun Oct 26 09:00:00 1969 UTC = Sun Oct 26 01:00:00 1969 PST isdst=0

...it appears that DST was *not* in effect on October 30, 1969.

A caveat: tzdata’s docs warn that dates before 1970 may not be accurate. But because I’m fascinated by the cultural history embedded within that database, I downloaded the latest tzdata files to check. The relevant rules are in the ‘northamerica’ file:

Rule	CA	1948	only	-	Mar	14	2:01	1:00	D
Rule	CA	1949	only	-	Jan	 1	2:00	0	S
Rule	CA	1950	1966	-	Apr	lastSun	1:00	1:00	D
Rule	CA	1950	1961	-	Sep	lastSun	2:00	0	S
Rule	CA	1962	1966	-	Oct	lastSun	2:00	0	S
Zone America/Los_Angeles -7:52:58 -	LMT	1883 Nov 18 12:07:02
			-8:00	US	P%sT	1946
			-8:00	CA	P%sT	1967
			-8:00	US	P%sT

I wouldn’t say that’s definitive, but usually tzdata is a pretty good source.

Best,
—John

From scj at yaccman.com  Tue Oct 30 03:52:55 2018
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 29 Oct 2018 10:52:55 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <7wftwpi4z7.fsf@junk.nocrew.org>
Message-ID: <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>


Yes.  If it was =op, this means the C program probably used =+
instead of +=.  That was the
dialect of C that was around when Al was at Bell Labs.  The
transition from =+ to += was a
pain, but decreased errors dramatically (a=-1 vs a= -1).

We actually had a pretty good system for making changes like that. 
First, we would change
the compiler to accept both the old and the new.   Then we would
produce a warning
that on a particular date the old would no longer work.  Then we made
the old an error
and printed a message about how to fix it.   Eventually, we just let
it be a syntax error.
This process was applied many times on the way from typeless B to
strongly typed C.

----- Original Message -----
From: "Lars Brinkhoff" <lars at nocrew.org>
To:"Steve Johnson" <scj at yaccman.com>
Cc:<tuhs at tuhs.org>
Sent:Mon, 29 Oct 2018 07:31:24 +0000
Subject:Re: [TUHS] Archaic yacc C grammar

 Steve Johnson wrote:
 > Looking at the reserved words, there is one, ENTRY, that I've never
 > heard of (although FORTRAN had an ENTRY statement), and there is
 > STRUCT but no UNION. Also, he uses val= instead of $$=. There don't
 > seem to be any nontrivial assignment ops (neither += or =+).

 This is for Snyder's C compiler. There is something called =op which
 is guess is for =+ etc.

 > I'm guessing either Al wrote it from scratch or based it on some
other
 > similar program.

 Looks like you're right. I found this in another file, so it would
seem
 he wrote it back at MIT:

 "The original YACC was designed and implemented on a PDP-11/45 and a
 Honeywell 6000 by S. C. Johnson at Bell Laboratories. The version
 described in this paper was implemented on the PDP-10 by Alan Snyder.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181029/cf518736/attachment.html>

From imp at bsdimp.com  Tue Oct 30 04:37:31 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 29 Oct 2018 12:37:31 -0600
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>
References: <7wftwpi4z7.fsf@junk.nocrew.org>
 <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>
Message-ID: <CANCZdfqKWS+PO1WUpRk-kAysrT6g4ApMUok5E6J+nAr-HHU3zw@mail.gmail.com>

On Mon, Oct 29, 2018 at 12:30 PM Steve Johnson <scj at yaccman.com> wrote:

> We actually had a pretty good system for making changes like that.  First,
> we would change
> the compiler to accept both the old and the new.   Then we would produce a
> warning
> that on a particular date the old would no longer work.  Then we made the
> old an error
> and printed a message about how to fix it.   Eventually, we just let it be
> a syntax error.
> This process was applied many times on the way from typeless B to strongly
> typed C.
>

How long a transition period did you typically have?

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181029/0b943ab3/attachment.html>

From david at kdbarto.org  Tue Oct 30 05:02:29 2018
From: david at kdbarto.org (David)
Date: Mon, 29 Oct 2018 12:02:29 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>
References: <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>
Message-ID: <5DB0D670-6B65-4558-9CCE-7F80FE5B62BA@kdbarto.org>


> On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> We actually had a pretty good system for making changes like that.  First, we would change
> the compiler to accept both the old and the new.   Then we would produce a warning
> that on a particular date the old would no longer work.  Then we made the old an error
> and printed a message about how to fix it.   Eventually, we just let it be a syntax error.
> This process was applied many times on the way from typeless B to strongly typed C.

Was there ever a time when a change was desired that you couldn’t accept both
the old and the new?

	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181029/cf534e0e/attachment.html>

From dave at horsfall.org  Tue Oct 30 07:13:09 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 30 Oct 2018 08:13:09 +1100 (EST)
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
Message-ID: <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>

On Mon, 29 Oct 2018, John Labovitz wrote:

[...]

> ...it appears that DST was *not* in effect on October 30, 1969.

Which is another reason why I don't use UTC; not only do I have to be 
familiar with every timezone in the world (how many does Russia have 
again?  At least China has just the one) but I also have to see whether 
DST applied at the time.

Did you know, for example, that in Australia, DST was changed to 
accommodate the Sydney 2000 Olympics, otherwise the foreign athletes 
would've been confused as hell?

Abolish DST, I say; it was introduced as a temporary measure during one of 
the World Wars to increase production or something.

-- Dave


From grog at lemis.com  Tue Oct 30 09:28:37 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 30 Oct 2018 10:28:37 +1100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
Message-ID: <20181029232837.GB27974@eureka.lemis.com>

On Monday, 29 October 2018 at 10:19:43 -0400, Clem Cole wrote:
> On Mon, Oct 29, 2018 at 4:01 AM Michael Kjörling <michael at kjorling.se>
> wrote:
>
>> So 1969-10-30 05:30 UTC?
>
> I >>think<< it is more likely 06:30 UTC, as IIRC Daylight Saving Time
> finished mid-month so I think it would have been UTC+8:00 [not +7:00 which
> it would be now].

Yes, correct:

  $ TZ=America/Los_Angeles date -j 196910292230 +%s
  5419800
  $ TZ=UTC date -r -5419800
  Thu 30 Oct 1969 06:30:00 UTC

> If you want to be be 100% accurate and use UTC, then you would need to
> check a precise calendar that had all those details to see how the US had
> its clocks set on October 30, 1969.  The good news was the transmission
> stayed with the same time zone, which as I said was Pacific (UCLA is in Los
> Angeles area and SRI in the Bay Area - but both are California - which
> follows US, DST rules).  The question is what were the rules that were in
> effect that night.

That's in the time zone sources:

  # Rule NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
  Rule	US	1967	2006	-	Oct	lastSun	2:00	0	S
  Rule	US	2007	max	-	Nov	Sun>=1	2:00	0	S

So in 1969, DST ended on 26 October.

Greg

Of course, this didn't happen at *exactly* 22:30/6:30, but presumably
nobody at the time thought that people would still be talking about it
50 years later.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181030/4897d0c6/attachment.sig>

From grog at lemis.com  Tue Oct 30 10:08:52 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 30 Oct 2018 11:08:52 +1100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
Message-ID: <20181030000852.GC27974@eureka.lemis.com>

On Monday, 29 October 2018 at 11:34:50 -0400, John Labovitz wrote:
> On Oct 29, 2018, at 10:19 AM, Clem Cole <clemc at ccc.com> wrote:

Ah, damn, you got there first.  Thanks for the zdump reference.

>> I >>think<< it is more likely 06:30 UTC, as IIRC Daylight Saving
>> Time finished mid-month so I think it would have been UTC+8:00 [not
>> +7:00 which it would be now].  That said, Nixon [...shutter...] was
>> in office and he put the US went on DST in the winter at some point
>> due to the oil crisis (but I thought that was a year or so later).
>> I remember it all happening at the time - but I can do not put
>> precise dates on any of it.
>
> According to tzdata...
>
> $ zdump -v America/Los_Angeles | grep 1969
> America/Los_Angeles  Sun Apr 27 09:59:59 1969 UTC = Sun Apr 27 01:59:59 1969 PST isdst=0
> America/Los_Angeles  Sun Apr 27 10:00:00 1969 UTC = Sun Apr 27 03:00:00 1969 PDT isdst=1
> America/Los_Angeles  Sun Oct 26 08:59:59 1969 UTC = Sun Oct 26 01:59:59 1969 PDT isdst=1
> America/Los_Angeles  Sun Oct 26 09:00:00 1969 UTC = Sun Oct 26 01:00:00 1969 PST isdst=0
>
> ...it appears that DST was *not* in effect on October 30, 1969.
>
>> A caveat: tzdata???s docs warn that dates before 1970 may not be
>> accurate. But because I???m fascinated by the cultural history
>> embedded within that database, I downloaded the latest tzdata files
>> to check. The relevant rules are in the ???northamerica??? file:
>
# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER
> Rule	CA	1948	only	-	Mar	14	2:01	1:00	D
> Rule	CA	1949	only	-	Jan	 1	2:00	0	S
> Rule	CA	1950	1966	-	Apr	lastSun	1:00	1:00	D
> Rule	CA	1950	1961	-	Sep	lastSun	2:00	0	S
> Rule	CA	1962	1966	-	Oct	lastSun	2:00	0	S
> Zone America/Los_Angeles -7:52:58 -	LMT	1883 Nov 18 12:07:02
> 			-8:00	US	P%sT	1946
> 			-8:00	CA	P%sT	1967
> 			-8:00	US	P%sT

Yes, but the key here is the US in the last line.  That refers to the
rules further up (US) that I referred to.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181030/de6a9431/attachment.sig>

From grog at lemis.com  Tue Oct 30 10:11:10 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 30 Oct 2018 11:11:10 +1100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
Message-ID: <20181030001110.GD27974@eureka.lemis.com>

On Tuesday, 30 October 2018 at  8:13:09 +1100, Dave Horsfall wrote:
> On Mon, 29 Oct 2018, John Labovitz wrote:
>
> [...]
>
>> ...it appears that DST was *not* in effect on October 30, 1969.
>
> Which is another reason why I don't use UTC; ...

UTC or DST?

Years ago I tried ignoring DST.  It ended badly.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181030/e5a1b5b9/attachment.sig>

From bakul at bitblocks.com  Tue Oct 30 11:09:23 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 29 Oct 2018 18:09:23 -0700
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: Your message of "Tue, 30 Oct 2018 08:13:09 +1100."
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
Message-ID: <20181030010931.731C8156E410@mail.bitblocks.com>

On Tue, 30 Oct 2018 08:13:09 +1100 Dave Horsfall <dave at horsfall.org> wrote:
>
> Abolish DST, I say; it was introduced as a temporary measure during one of 
> the World Wars to increase production or something.

Agree it should be abolished. 

\tangent{
 In California we will have a chance to do something about
 this on Nov 6. If proposition 7 passes it will *allow* the
 CA legislature to change the DST law by a 2/3 majority --
 either to repeal it or, more likely, to a year around DST.
 And even then we'd have to get Federal approval. Madness!
}


From lars at nocrew.org  Tue Oct 30 13:55:42 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 30 Oct 2018 03:55:42 +0000
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181030010931.731C8156E410@mail.bitblocks.com> (Bakul Shah's
 message of "Mon, 29 Oct 2018 18:09:23 -0700")
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030010931.731C8156E410@mail.bitblocks.com>
Message-ID: <7w7ei0gkap.fsf@junk.nocrew.org>

Bakul Shah wrote:
> Dave Horsfall wrote:
>> Abolish DST, I say; it was introduced as a temporary measure during one of 
>> the World Wars to increase production or something.
> Agree it should be abolished. 

Being done in EU.


From arno.griffioen at ieee.org  Tue Oct 30 16:07:08 2018
From: arno.griffioen at ieee.org (Arno Griffioen)
Date: Tue, 30 Oct 2018 07:07:08 +0100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <7w7ei0gkap.fsf@junk.nocrew.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030010931.731C8156E410@mail.bitblocks.com>
 <7w7ei0gkap.fsf@junk.nocrew.org>
Message-ID: <20181030060708.GO25437@ancienthardware.org>

On Tue, Oct 30, 2018 at 03:55:42AM +0000, Lars Brinkhoff wrote:
> Bakul Shah wrote:
> > Dave Horsfall wrote:
> >> Abolish DST, I say; it was introduced as a temporary measure during one of 
> >> the World Wars to increase production or something.
> > Agree it should be abolished. 
> 
> Being done in EU.

Going *really* off-topic here, but in true EU style it may well end
up a total mess with all different countries choosing to either stay in DST
or 'regular' time permanently.

So that could potentially lead to an 'interesting' patchwork of timezones 
across the region.

Slowly some noises in the EU halls of power starting to appear now that it's 
likely better to take some more time for this and try to reach a single 
agreed-on 'time selection' decision for the whole region.

So there may be some hope for a sane result..

Now back to your regular scheduled UN*X history channel programming!

								Bye, Arno.


From steve at quintile.net  Tue Oct 30 18:02:50 2018
From: steve at quintile.net (Steve Simon)
Date: Tue, 30 Oct 2018 08:02:50 +0000
Subject: [TUHS] C entry keyword
Message-ID: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>


“entry” was a reserved word in K&R Ed.1,
my personal favourite C trivia. I have never seen it used outside fortran on mainframes though.

-Steve




From lars at nocrew.org  Tue Oct 30 18:16:17 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 30 Oct 2018 08:16:17 +0000
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <CANCZdfqKWS+PO1WUpRk-kAysrT6g4ApMUok5E6J+nAr-HHU3zw@mail.gmail.com>
 (Warner Losh's message of "Mon, 29 Oct 2018 12:37:31 -0600")
References: <7wftwpi4z7.fsf@junk.nocrew.org>
 <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.com>
 <CANCZdfqKWS+PO1WUpRk-kAysrT6g4ApMUok5E6J+nAr-HHU3zw@mail.gmail.com>
Message-ID: <7w5zxjg88e.fsf@junk.nocrew.org>

Warner Losh wrote:
> Steve Johnson wrote:
>  We actually had a pretty good system for making changes like
>  that. First, we would change the compiler to accept both the old and
>  the new. Then we would produce a warning that on a particular date
>  the old would no longer work. Then we made the old an error and
>  printed a message about how to fix it.
>
> How long a transition period did you typically have?

I heard the V7 compiler still supports old B style initialization
"int x 42;".  So in some cases, a really long time.


From lars at nocrew.org  Tue Oct 30 18:51:59 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 30 Oct 2018 08:51:59 +0000
Subject: [TUHS] C entry keyword
In-Reply-To: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net> (Steve
 Simon's message of "Tue, 30 Oct 2018 08:02:50 +0000")
References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
Message-ID: <7wo9bbes0g.fsf@junk.nocrew.org>

Steve Simon wrote:
> “entry” was a reserved word in K&R Ed.1,
> my personal favourite C trivia. I have never seen it used outside
> fortran on mainframes though.

It's there in Snyder's C compiler, but not used.  From the grammar:

    statement:
    ...
        | ENTRY identifier ':' statement       {val=aentry(#2,#4);}

But the supporting code in the compiler:

    aentry (idn, stmt)
        {return (stmt);}    /* not implemented */


From aap at papnet.eu  Tue Oct 30 19:12:59 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 30 Oct 2018 10:12:59 +0100
Subject: [TUHS] C entry keyword
In-Reply-To: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
Message-ID: <20181030091259.GA44474@indra.papnet.eu>

On 30/10/18, Steve Simon wrote:
> 
> “entry” was a reserved word in K&R Ed.1,
> my personal favourite C trivia. I have never seen it used outside fortran on mainframes though.

I think PL/1 on Multics uses it, which is probably how it "got into" C.

aap


From arnold at skeeve.com  Tue Oct 30 22:50:12 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 30 Oct 2018 06:50:12 -0600
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181030001110.GD27974@eureka.lemis.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030001110.GD27974@eureka.lemis.com>
Message-ID: <201810301250.w9UCoCPM010039@freefriends.org>

"Greg 'groggy' Lehey" <grog at lemis.com> wrote:

> Years ago I tried ignoring DST.  It ended badly.

It couldn't have been as bad as for these guys:

	https://darwinawards.com/darwin/darwin1999-38.html

Not that I have any sympathy at all.

Arnold


From paul.winalski at gmail.com  Tue Oct 30 23:32:23 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 30 Oct 2018 09:32:23 -0400
Subject: [TUHS] C entry keyword
In-Reply-To: <20181030091259.GA44474@indra.papnet.eu>
References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
 <20181030091259.GA44474@indra.papnet.eu>
Message-ID: <CABH=_VS2QG35YUeCOsaz4+APZC7efb=T_Sr7GsZNVGKfF9Ud+w@mail.gmail.com>

On 10/30/18, Angelo Papenhoff <aap at papnet.eu> wrote:
> On 30/10/18, Steve Simon wrote:
>>
>> “entry” was a reserved word in K&R Ed.1,
>> my personal favourite C trivia. I have never seen it used outside fortran
>> on mainframes though.
>
> I think PL/1 on Multics uses it, which is probably how it "got into" C.
>
PL/1 inherited the concept of routines with multiple entry points from Fortran.

Did the early K&R C compilers actually implement multiple entry point
routines, or was the keyword simply reserved for future use?

-Paul W.


From imp at bsdimp.com  Tue Oct 30 23:56:54 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 30 Oct 2018 07:56:54 -0600
Subject: [TUHS] C entry keyword
In-Reply-To: <20181030091259.GA44474@indra.papnet.eu>
References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
 <20181030091259.GA44474@indra.papnet.eu>
Message-ID: <CANCZdfo+hXvkoGw1GnYoRAeBPHp-Ex6=PGhHLaDKu7AoKj3oew@mail.gmail.com>

I'd imagine you'd use it like so (in more modern C):

void *memcpy(void *src, void *dst, size_t len)
{
char *rv = dst;
top:
while (len--) *dst++ =*src; /* not always a trivial body */
return(rv);
entry bcopy:
rv = dst; /* Swap args and jump to memcpy */
dst = src;
src = rv;
goto top:
}

Variations on this theme are often done in assembler for these routines,
though the example is an attempt to cope with the diversity of interfaces
that grew up after v6 unix was released in the world, so it's not likely
this particular example inspired it...

Warner

On Tue, Oct 30, 2018 at 4:00 AM Angelo Papenhoff <aap at papnet.eu> wrote:

> On 30/10/18, Steve Simon wrote:
> >
> > “entry” was a reserved word in K&R Ed.1,
> > my personal favourite C trivia. I have never seen it used outside
> fortran on mainframes though.
>
> I think PL/1 on Multics uses it, which is probably how it "got into" C.
>
> aap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181030/f89da94b/attachment.html>

From paul.winalski at gmail.com  Wed Oct 31 03:53:26 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 30 Oct 2018 13:53:26 -0400
Subject: [TUHS] C entry keyword
In-Reply-To: <CANCZdfo+hXvkoGw1GnYoRAeBPHp-Ex6=PGhHLaDKu7AoKj3oew@mail.gmail.com>
References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net>
 <20181030091259.GA44474@indra.papnet.eu>
 <CANCZdfo+hXvkoGw1GnYoRAeBPHp-Ex6=PGhHLaDKu7AoKj3oew@mail.gmail.com>
Message-ID: <CABH=_VTyHe6cOUgR5ByPRq=kQOdH+EUrJgmo=nByLa_sA1XE_w@mail.gmail.com>

In Fortran secondary entry points served two main purposes.  It
allowed for sharing of code for similar routines (as in Angelo
Papenhoff's C example), which was important when your program had to
fit in only a few K of memory.  Secondly, it provided partial relief
for Fortran's very restrictive variable-scoping rules.

It's a pain in the butt for compiler optimizers, although certain
modern interprocedural optimizations emit code that is the moral
equivalent of a routine with multiple entry points.

-Paul W.


From dave at horsfall.org  Wed Oct 31 08:05:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 31 Oct 2018 09:05:02 +1100 (EST)
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <20181030001110.GD27974@eureka.lemis.com>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030001110.GD27974@eureka.lemis.com>
Message-ID: <alpine.BSF.2.21.9999.1810310857570.58929@aneurin.horsfall.org>

On Tue, 30 Oct 2018, Greg 'groggy' Lehey wrote:

>>> ...it appears that DST was *not* in effect on October 30, 1969.
>>
>> Which is another reason why I don't use UTC; ...
>
> UTC or DST?

Both; if I use UTC then I have to figure out whether DST was in effect at 
that time (apart from working out the UTC offset), and people can do that 
for themselves if they care enough (and assuming that I keep posting 
these).

And this thread is rapidly becoming off-topic...

-- Dave


From scj at yaccman.com  Wed Oct 31 08:01:55 2018
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 30 Oct 2018 15:01:55 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <5DB0D670-6B65-4558-9CCE-7F80FE5B62BA@kdbarto.org>
Message-ID: <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>

The closest I came was when we went from a single namespace for all
structure names to a namespace for each structure, and references that
were checked using the pointer type of the structure pointer.
My code was a nightmare, and some of the old Unix code was at least a
bad dream.   I had to start out pretending to have a single
namespace, but when I saw the use of an actual structure pointer I had


to do it the new way.  As I recall when I saw something that would
not have been legal with the old rules (for example, two different
structures with the same element name but different offsets) then I
threw
 the switch and demanded the new way.  

There were certainly system changes that were flash cut.  For
example, changing the file system format -- there was no attempt to
allow both, which meant that the conversion program got one shot to
get it right.  And it didn't always manage that...

Steve

----- Original Message -----
From:
 david at kdbarto.org

To:
"Steve Johnson" <scj at yaccman.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Mon, 29 Oct 2018 12:02:29 -0700
Subject:
Re: [TUHS] Archaic yacc C grammar

On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj at yaccman.com [1]>
wrote:

We actually had a pretty good system for making changes like that. 
First, we would change
the compiler to accept both the old and the new.   Then we would
produce a warning
that on a particular date the old would no longer work.  Then we made
the old an error
and printed a message about how to fix it.   Eventually, we just let
it be a syntax error.
This process was applied many times on the way from typeless B to
strongly typed C.

Was there ever a time when a change was desired that you couldn’t
accept both
the old and the new?

David

 

Links:
------
[1] mailto:scj at yaccman.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181030/3e5b1a39/attachment.html>

From grog at lemis.com  Wed Oct 31 08:12:09 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 31 Oct 2018 09:12:09 +1100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <201810301250.w9UCoCPM010039@freefriends.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030001110.GD27974@eureka.lemis.com>
 <201810301250.w9UCoCPM010039@freefriends.org>
Message-ID: <20181030221209.GF27974@eureka.lemis.com>

On Tuesday, 30 October 2018 at  6:50:12 -0600, arnold at skeeve.com wrote:
> "Greg 'groggy' Lehey" <grog at lemis.com> wrote:
>
>> Years ago I tried ignoring DST.  It ended badly.
>
> It couldn't have been as bad as for these guys:
>
> 	https://darwinawards.com/darwin/darwin1999-38.html

Indeed.  I'm still here to tell the tale.

But then, all my bombs are based on time_t.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181031/1bbf13bd/attachment.sig>

From lm at mcvoy.com  Wed Oct 31 10:58:00 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 30 Oct 2018 17:58:00 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>
References: <5DB0D670-6B65-4558-9CCE-7F80FE5B62BA@kdbarto.org>
 <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>
Message-ID: <20181031005800.GA5670@mcvoy.com>

I'm coming into this late (and tired, been working on my water system
and the carbs on my boat all day) but I *loved* the single namespace
for all structure fields.

Instead of 

	p->size

we have

	p->st_size

and I instantly know that p is a struct stat pointer.  

I get that it doesn't scale but man, oh man, do I love the early Unix
data structures that had one namespace.  I kinda wish you hadn't fixed
that Steve.

What was the push that made you fix it?

On Tue, Oct 30, 2018 at 03:01:55PM -0700, Steve Johnson wrote:
> The closest I came was when we went from a single namespace for all
> structure names to a namespace for each structure, and references that
> were checked using the pointer type of the structure pointer.
> My code was a nightmare, and some of the old Unix code was at least a
> bad dream.???? I had to start out pretending to have a single
> namespace, but when I saw the use of an actual structure pointer I had
> 
> 
> to do it the new way.?? As I recall when I saw something that would
> not have been legal with the old rules (for example, two different
> structures with the same element name but different offsets) then I
> threw
>  the switch and demanded the new way.?? 
> 
> There were certainly system changes that were flash cut.?? For
> example, changing the file system format -- there was no attempt to
> allow both, which meant that the conversion program got one shot to
> get it right.?? And it didn't always manage that...
> 
> Steve
> 
> ----- Original Message -----
> From:
>  david at kdbarto.org
> 
> To:
> "Steve Johnson" <scj at yaccman.com>
> Cc:
> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
> Sent:
> Mon, 29 Oct 2018 12:02:29 -0700
> Subject:
> Re: [TUHS] Archaic yacc C grammar
> 
> On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj at yaccman.com [1]>
> wrote:
> 
> We actually had a pretty good system for making changes like that.??
> First, we would change
> the compiler to accept both the old and the new.???? Then we would
> produce a warning
> that on a particular date the old would no longer work.?? Then we made
> the old an error
> and printed a message about how to fix it.???? Eventually, we just let
> it be a syntax error.
> This process was applied many times on the way from typeless B to
> strongly typed C.
> 
> Was there ever a time when a change was desired that you couldn???t
> accept both
> the old and the new?
> 
> David
> 
>  
> 
> Links:
> ------
> [1] mailto:scj at yaccman.com
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From wkt at tuhs.org  Wed Oct 31 14:38:10 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 31 Oct 2018 14:38:10 +1000
Subject: [TUHS] Unix APIs: elegant or not?
Message-ID: <20181031043810.GA10775@minnie.tuhs.org>

I was just reading this book review:
http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html
and came across these paragraphs:

    <book quote>
    The mechanism for file IO provided by the Unix operating system
    and its descendants, such as Linux, is a beautiful example of a
    deep interface. There are only five basic system calls for I/O,
    with simple signatures:

    int open(const char* path, int flags, mode_t permissions);
    ssize_t read(int fd, void* buffer, size_t count);
    ssize_t write(int fd, const void* buffer, size_t count);
    off_t lseek(int fd, off_t offset, int referencePosition);
    int close(int fd);
    </book quote>

  The POSIX file API is a great example, but not of a deep
  interface. Rather, it’s a great example of how code with a very
  complicated interface may look deceptively simple when reduced to C-style
  function signatures. It’s a stateful API with interesting orderings
  and interactions between calls. The flags and permissions parameters
  of open hide an enormous amount of complexity, with hidden requirements
  like “exactly one of these five bits should be specified.” open may
  return 20 different error codes, each with their own meaning, and many
  with references to specific implementations.

  The authors of SibylIFS tried to write down an exact description of the
  open interface. Their annotated version[1] of the POSIX standard is over
  3000 words. Not counting basic machinery, it took them over 200 lines[2]
  to write down the properties of open in higher-order logic, and another
  70 to give the interactions between open and close.
  [1]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce3887840d6a1812/fs_spec/src/posix/open.md
  [2]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce3887840d6a1812/fs_spec/src/t_fs_spec_fs_command_properties.lem_cppo#L460

I just thought it was a thought-provoking comment on the apparent elegance
of the Unix file API that actually has some subtle complexity.

Cheers, Warren


From lars at nocrew.org  Wed Oct 31 16:09:39 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 31 Oct 2018 06:09:39 +0000
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>
 (Steve Johnson's message of "Tue, 30 Oct 2018 15:01:55 -0700")
References: <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>
Message-ID: <7wy3aebqak.fsf@junk.nocrew.org>

Steve Johnson wrote:
> The closest I came was when we went from a single namespace for all
> structure names to a namespace for each structure, and references that
> were checked using the pointer type of the structure pointer.  My code
> was a nightmare, and some of the old Unix code was at least a bad
> dream.

How about this, pointer to int used as pointer to struct.

prlook( pp ) int *pp;{
        int j;
        pp = pp->lset;
....


From clemc at ccc.com  Wed Oct 31 23:49:29 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Oct 2018 09:49:29 -0400
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <20181031005800.GA5670@mcvoy.com>
References: <5DB0D670-6B65-4558-9CCE-7F80FE5B62BA@kdbarto.org>
 <c27ddaaf0161a10ff46759d5678ad5e317283fc9@webmail.yaccman.com>
 <20181031005800.GA5670@mcvoy.com>
Message-ID: <CAC20D2NQNS0piUqRO3sEn2ObcwDTVZBD4hnrfXHcamE3UexOcA@mail.gmail.com>

On Tue, Oct 30, 2018 at 9:46 PM Larry McVoy <lm at mcvoy.com> wrote:

> Instead of
>
>         p->size
>
> we have
>
>         p->st_size
>
> and I instantly know that p is a struct stat pointer.
>
+1
Amen Larry.   I understand why people had a desire for different
namespaces, but a single namespace sure made code a lot more readable and
understandable.
I still use that trick in new code, because I think it just makes it easier
to identify what is going on when I glance at it.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181031/a3f6b5c3/attachment.html>

