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: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> 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: <20180831215636.-eCEx%ca6c@bitmessage.ch> <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> <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/ at whichever /export/// 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: Message-ID: 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: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <7aa1b665a2b5ef23@orthanc.ca> Message-ID: On 9/30/18, Lyndon Nerenberg 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: References: Message-ID: <20181001163524.wHEHy%steffen@sdaoden.eu> Steve Simon wrote in : |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: 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: References: Message-ID: On Sun, Oct 7, 2018 at 11:01 AM Nelson H. F. Beebe 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: References: , 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 wrote: > >> On Sun, Oct 7, 2018 at 11:01 AM Nelson H. F. Beebe 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: <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com> Message-ID: On Saturday, October 6, 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. > > 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: 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: References: 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 (Noel Chiappa) > Subject: Re: [TUHS] Unix source code archive in the news > Message-ID: <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 ) 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 — scan down for “Source code of the THE Operating System”. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: > 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: References: <201810070607.w9767Xrl014901@freefriends.org> <7w7eiuqdgu.fsf@junk.nocrew.org>, Message-ID: <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01> At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi : > 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> <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01> Message-ID: On 7 Oct 2018, at 14:33, Donald ODona wrote: > > At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi : >> 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>, <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01> Message-ID: On Sun, 7 Oct 2018, Donald ODona wrote: > At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi : >> 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 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 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 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 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: References: <201810070607.w9767Xrl014901@freefriends.org> <7w7eiuqdgu.fsf@junk.nocrew.org> Message-ID: 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: References: <201810070607.w9767Xrl014901@freefriends.org> <7w7eiuqdgu.fsf@junk.nocrew.org>, <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01> Message-ID: 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 : >> 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: 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: Message-ID: 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: 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: Message-ID: 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: 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: , <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com> Message-ID: 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: References: , <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com> Message-ID: 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: 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 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: References: <201810070607.w9767Xrl014901@freefriends.org> <7w7eiuqdgu.fsf@junk.nocrew.org> <429392344.28355.1538915610952.JavaMail.tomcat@india-live-be01> 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 wrote: > > > > At 7 Oct 2018 11:01:11 +0000 (+00:00) from Arrigo Triulzi : > >> 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: 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: 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 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: References: , <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com> Message-ID: >> 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: References: , <4936B4CF-62EA-4D98-8B82-200F7D8581B4@jctaylor.com> 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> <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: 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: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> <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: <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: 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: 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: On Wed, Oct 10, 2018 at 11:27 AM 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). > > 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: 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: References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu> Message-ID: <358EC61B-9C6B-4238-9DC6-DE7C9049F4B3@kdbarto.org> > On Oct 10, 2018, at 8:45 AM, Clem Cole wrote: > > > > On Wed, Oct 10, 2018 at 11:27 AM 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). > > 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: 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 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: 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: 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: References: <1539182625.28839.for-standards-violators@oclsc.org> <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net> 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/ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: 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 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: 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: 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: References: <20181010152649.73DEF18C08E@mercury.lcs.mit.edu> 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: 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 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: 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: References: <20181015195622.GB25749@minnie.tuhs.org> Message-ID: #$%^ - they >>weren't<< like DECtape from a reliability standpoint ... ᐧ On Mon, Oct 15, 2018 at 5:00 PM Clem Cole 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 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: 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: References: <20181015195622.GB25749@minnie.tuhs.org> Message-ID: 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 wrote: > #$%^ - they >>weren't<< like DECtape from a reliability standpoint ... > ᐧ > > On Mon, Oct 15, 2018 at 5:00 PM Clem Cole 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 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: 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: 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: 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: References: Message-ID: On Monday, October 15, 2018, Dan Cross 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: 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: References: Message-ID: A terrible loss IMHO, just considering StratoLaunch alone. On Mon, Oct 15, 2018 at 4:22 PM Andy Kosela wrote: > > > On Monday, October 15, 2018, Dan Cross 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: 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: 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: References: Message-ID: <71AE0424-34ED-4069-B4FE-3E233896FACD@yahoo.com> > On 16 Oct 2018, at 06:35, Dave Horsfall 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: +1 ᐧ On Tue, Oct 16, 2018 at 10:40 AM 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 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: 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: References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu> 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 wrote: > > +1 > ᐧ > > On Tue, Oct 16, 2018 at 10:40 AM 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 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: 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: On Tue, Oct 16, 2018 at 10:40 AM 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 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: 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: References: <20181016143911.6BDB618C08D@mercury.lcs.mit.edu> Message-ID: <20181016161017.iKPHz%steffen@sdaoden.eu> Clem Cole wrote in : |+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 --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: References: <20181015195622.GB25749@minnie.tuhs.org> Message-ID: On 10/15/18, Clem Cole 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: 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: References: <20181015195622.GB25749@minnie.tuhs.org> 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 To: Clem Cole Cc: The Eunuchs Hysterical Society , cctalk at classiccmp.org Sent: Tue, 16 Oct 2018 13:14 Subject: Re: [TUHS] Ultrix Tape: Block Size? On 10/15/18, Clem Cole 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: References: <20181015195622.GB25749@minnie.tuhs.org> Message-ID: On Tue, Oct 16, 2018 at 12:57 PM Paul Winalski 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: 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> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> Message-ID: 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 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 > To: Clem Cole > Cc: The Eunuchs Hysterical Society , cctalk at classiccmp.org > Sent: Tue, 16 Oct 2018 13:14 > Subject: Re: [TUHS] Ultrix Tape: Block Size? > > On 10/15/18, Clem Cole 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: 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> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> Message-ID: On 10/16/18, William Pechter 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> <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 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> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net> <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com> Message-ID: emanuel stiebler 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> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net> <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com> Message-ID: 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 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): <512 bytes of serial data [blk1]><512 bytes of serial data[blk2]>.....<512 bytes of serial data>[blkn] The key is that there are no inter-record gaps (IRG) between the and < 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): ...... [if the last last 'file' on the tape a second] Note: LRECL BYTES of BLK1 did not have to be the same as much less 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 is backed up over and data frame writing starts over writing the second after the last 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: 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: 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: (Tom Ivar Helbekkmo via TUHS's message of "Wed, 17 Oct 2018 14:57:38 +0200") References: <20181015195622.GB25749@minnie.tuhs.org> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net> <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com> Message-ID: 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: (Tom Ivar Helbekkmo via TUHS's message of "Wed, 17 Oct 2018 14:57:38 +0200") References: <20181015195622.GB25749@minnie.tuhs.org> <4f20854e-6269-47aa-aeaf-9e2b93aa1201.maildroid@localhost> <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net> <4e0053ba-94d0-e5b3-7f1a-21c1f5b70861@e-bbes.com> Message-ID: 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: References: 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: 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: 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: 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: 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: References: <20181015195622.GB25749@minnie.tuhs.org> Message-ID: 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: On Fri, Oct 19, 2018 at 10:57 AM 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: 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: <3dce7cd7-86f2-4030-ab8c-7a8b95278fb1@SG2APC01FT049.eop-APC01.prod.protection.outlook.com> Message-ID: On Thu, Oct 18, 2018 at 10:19 AM Jason Stevens 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: 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: 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: References: 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 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 > 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 > 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: 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: 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: 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: <34E96877-0DFF-4988-B07D-C0EFA42482C5@ccc.com> Message-ID: 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 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 > 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: 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: In addition to SINE, does anyone know what happened to EINE? On Fri, Oct 26, 2018 at 3:10 AM Lars Brinkhoff 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: 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: 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 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: 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" 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: 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: On Fri, Oct 26, 2018 at 3:55 PM Angelo Papenhoff 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: 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: References: <20181026194636.GA11870@indra.papnet.eu> 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 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> <20181026210502.GA86931@indra.papnet.eu> Message-ID: <20181026215847.4E549156E40C@mail.bitblocks.com> On Fri, 26 Oct 2018 23:05:02 +0200 Angelo Papenhoff wrote: > On 26/10/18, Clem Cole wrote: > > On Fri, Oct 26, 2018 at 3:55 PM Angelo Papenhoff 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: On Fri, Oct 26, 2018 at 4:57 PM Angelo Papenhoff 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: 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: References: <20181026194636.GA11870@indra.papnet.eu> <20181026214308.GA20796@minnie.tuhs.org> <20181026221153.GA19920@indra.papnet.eu> <20181026222909.GA24093@indra.papnet.eu> 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 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: > On Oct 27, 2018, at 7:28 AM, Angelo Papenhoff 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: References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU> <20181027122834.GA97675@indra.papnet.eu> 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 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: Angelo Papenhoff 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: References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU> <20181027122834.GA97675@indra.papnet.eu> 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: > 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 (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: 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: References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU> 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 (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: (Clem Cole's message of "Sat, 27 Oct 2018 11:53:20 -0400") References: <201810271159.w9RBxZaQ124546@tahoe.cs.Dartmouth.EDU> Message-ID: <7w5zxnkwbb.fsf@junk.nocrew.org> Clem Cole 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} | 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;} 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 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: 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: 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: References: 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: 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: 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: <20181029021023.GA27974@eureka.lemis.com> Message-ID: 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: <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" To: 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: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> Message-ID: On Mon, Oct 29, 2018 at 4:01 AM Michael Kjörling 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: 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: References: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> Message-ID: <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> On Oct 29, 2018, at 10:19 AM, Clem Cole 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" To:"Steve Johnson" Cc: 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: 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: On Mon, Oct 29, 2018 at 12:30 PM 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. 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: 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 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: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> Message-ID: 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: References: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> 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 > 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: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <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 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: 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: References: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> 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: 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." References: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> Message-ID: <20181030010931.731C8156E410@mail.bitblocks.com> On Tue, 30 Oct 2018 08:13:09 +1100 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. \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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <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: (Warner Losh's message of "Mon, 29 Oct 2018 12:37:31 -0600") References: <7wftwpi4z7.fsf@junk.nocrew.org> <068e3163f59e699e486287cf033dc226fbb59b87@webmail.yaccman.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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <20181030001110.GD27974@eureka.lemis.com> Message-ID: <201810301250.w9UCoCPM010039@freefriends.org> "Greg 'groggy' Lehey" 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: On 10/30/18, Angelo Papenhoff 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: 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 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: 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: References: <47BC5434-D668-48D1-AA45-361B6D1E2E3A@quintile.net> <20181030091259.GA44474@indra.papnet.eu> Message-ID: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <20181030001110.GD27974@eureka.lemis.com> Message-ID: 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: 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" Cc: "The Eunuchs Hysterical Society" 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 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: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <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" 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: 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: References: <5DB0D670-6B65-4558-9CCE-7F80FE5B62BA@kdbarto.org> 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" > Cc: > "The Eunuchs Hysterical Society" > 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 > 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: 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); 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: (Steve Johnson's message of "Tue, 30 Oct 2018 15:01:55 -0700") References: 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> <20181031005800.GA5670@mcvoy.com> Message-ID: On Tue, Oct 30, 2018 at 9:46 PM Larry McVoy 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: