From krewat at kilonet.net Mon Feb 3 11:38:43 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 2 Feb 2020 20:38:43 -0500 Subject: [COFF] How much Fortran? Message-ID: So, given the membership here, I wonder, does anyone have the inside scoop? How much Fortran was used ? https://science.slashdot.org/story/20/01/31/1837209/nasa-is-trying-to-save-voyager-2-after-a-power-glitch-shut-down-its-instruments From lm at mcvoy.com Mon Feb 3 13:47:29 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 2 Feb 2020 19:47:29 -0800 Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: <20200203034729.GN3216@mcvoy.com> When I was in school the calling convention had been sorted, just barely. You could call libc stuff from fortran but it didn't really work, the types didn't match up. But if you stuck to the basics, you could make it work. My Dad was a physics prof, theory guy, I coded some Fortran for him. It was definitely _the_ language for the physics guys. I'm close friends with Bill Long at Cray, he's been on the Fortran steering committee for decades. It is still a thing. Big in the physics world and it has evolved. It's much better than it was. How big was it 30 years ago? In my opinion, tiny compared to C. On Sun, Feb 02, 2020 at 08:38:43PM -0500, Arthur Krewat wrote: > So, given the membership here, I wonder, does anyone have the inside scoop? > How much Fortran was used ? > > https://science.slashdot.org/story/20/01/31/1837209/nasa-is-trying-to-save-voyager-2-after-a-power-glitch-shut-down-its-instruments > > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From drb at msu.edu Mon Feb 3 14:50:23 2020 From: drb at msu.edu (Dennis Boone) Date: Sun, 02 Feb 2020 23:50:23 -0500 Subject: [COFF] How much Fortran? In-Reply-To: (Your message of Sun, 02 Feb 2020 20:38:43 -0500.) References: Message-ID: <20200203045028.2C71F254F6@yagi.h-net.msu.edu> > So, given the membership here, I wonder, does anyone have the inside > scoop? How much Fortran was used ? Toward the bottom of the "Development and Management" section, there's a paragraph about programming languages. Hard to call it deeply authoritative, but... https://www.allaboutcircuits.com/news/voyager-mission-anniversary-computers-command-data-attitude-control/ De From clemc at ccc.com Tue Feb 4 01:53:22 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 3 Feb 2020 10:53:22 -0500 Subject: [COFF] How much Fortran? In-Reply-To: <20200203034729.GN3216@mcvoy.com> References: <20200203034729.GN3216@mcvoy.com> Message-ID: On Sun, Feb 2, 2020 at 10:47 PM Larry McVoy wrote: > How big was it 30 years ago? In my opinion, tiny compared to C. > Be careful, Fortran use is still not tiny (it has always paid my salary, and continues to do so). If you want to see some of the detail check out a fascinating web site: http://www.archer.ac.uk/status/codes/ then scroll the red bar and button, by programming language and take a look at the graphics, then scroll down and look at the applications. [Archer is a big Top-500 style supercomputer in the UK. They are one of my customers, so I'm aware of their work]. The sad truth is not a lot of 'new code' gets written for HPC (what I call the 'Fortran problem' - a discussion I have had with a number of the DPC++ folks here at Intel). Solutions like University of Illinois HPVM (Heterogeneous Parallel Systems Compiler), DPC++, and Cuda for that matter, all assume new code is being written (which is great for minting new Ph’Ds), but history has shown over and over, that does not happen in the HPC space [See: Clem Cole's Quora answer: Why is the Fortran language still in use and the most Importantly Relevant in HPC? Is it just because this Language has Tremendous Numerical Calculation Capability Which is an Important Part of HPC? and Clem Cole's Quora answer to: What is Fortran Useful For? ]. So back to the question. Given the timeframe when Voyager was being developed, the primary development languages were Assembler, and Fortran-66/IV in the NASA community (with some Jovial, most from the AF types as I understand it). Systems programming languages such as BCPL, C, BLISS, *et. al* were not yet in fashion in the wider world, although the system developers and research types certainly wanted something "better." Remember, only a 5-6 years earlier Margaret Hamilton wrote the AGC system SW at MIT/Draper in assembler. Ane when this SW was being written, Bill Wulf would not do the famous BLISS *vs.* PDP-11/PDP-10 assembler test study (~73) at CMU. Frankly, I would have expected the folks at this(these) NASA contractor(s) to have used assembler in those days under the guise of "efficiency;" but Fortran-IV would definitely have been popular at many contractors that would have been doing the work. The article mentions Fortran-V which I find interesting because I did not believe it was really much of a thing ( *i.e.* it was never standardized). Basically, as I understood it from my Fortran peeps at DEC/Intel, F-V was the Waterloo extensions (*a.k.a.* WatFor) that got picked up by most people and in particular, IBM added to the FORTRAN/G or H compiler for the S/360. DEC had gone in a different direction still with VMS FORTRAN, although I believe they had picked up the things like WRITE(*) from Waterloo. I could be misinformed, but I thought that it was not until the Stu Feldman led what be called the Fortran-77 standard (which IIRC was not completed until sometime in the early 1980s), that the ISO standard actually moved from Fortran-IV. [As, I have said elsewhere, the greatest bit of marketing DEC ever did was convince the world VMS FORTRAN was F77]. So it would not have been out of the question for the Nasa team to have used a flavor of post FORTRAN-66/IV as a development like the article Dennis points to suggests. But I wish I knew what the ISA of the processor was/is? That would likely tell us more. What were the HLL available for that processor? Did NASA invest in having something beyond the assembler written? Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Feb 4 02:06:43 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 3 Feb 2020 08:06:43 -0800 Subject: [COFF] How much Fortran? In-Reply-To: References: <20200203034729.GN3216@mcvoy.com> Message-ID: <20200203160643.GO3216@mcvoy.com> On Mon, Feb 03, 2020 at 10:53:22AM -0500, Clem Cole wrote: > On Sun, Feb 2, 2020 at 10:47 PM Larry McVoy wrote: > > How big was it 30 years ago? In my opinion, tiny compared to C. > > > Be careful, Fortran use is still not tiny (it has always paid my salary, > and continues to do so). Fair enough. I should have said "in my world...". I learned Fortran enough to do some work for my dad, learned about accumulated errors (that's actually pretty fascinating), learned the C/Fortran bindings because I wrote a user space threads library that could be used from Fortran, so I was aware of it. But in the CS department and then later at Sun, everything I came in contact with was in C. So in my world it wasn't a thing. I knew it had a pretty active user base, my buddy Bill Long is on the Fortran steering committee (or whatever it is called) and we'd talk about it. Modern Fortran is apparently a lot more pleasant than what I learned. From clemc at ccc.com Tue Feb 4 02:20:53 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 3 Feb 2020 11:20:53 -0500 Subject: [COFF] How much Fortran? In-Reply-To: <20200203160643.GO3216@mcvoy.com> References: <20200203034729.GN3216@mcvoy.com> <20200203160643.GO3216@mcvoy.com> Message-ID: On Mon, Feb 3, 2020 at 11:06 AM Larry McVoy wrote: > But in the CS department and then later at Sun, everything I came > in contact with was in C. So in my world it wasn't a thing. > Mine either mind you, but ... like me, Sun sold a >>lot<< of high-end systems to run Fortran codes. Like Masscomp, both firms compiler groups had to ensure that our Fortran compilers were not just F77, but VMS FORTRAN compliant - because when UNIX hit the scene, VMS FORTRAN was the *Lingua Franca* of the users (but just not us system folks). I always like to know what is paying the bills 😎 > > Modern Fortran is apparently a lot more pleasant than what I learned. Without a doubt, but I'd still rather not program in it.😂 I just want to make sure it works and runs really fast, so our customers want to use a large number of our high-end chips and keep that robot in AZ that is turning silicon into gold. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Feb 4 03:06:26 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Feb 2020 12:06:26 -0500 Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: On Sun, Feb 2, 2020 at 8:46 PM Arthur Krewat wrote: > So, given the membership here, I wonder, does anyone have the inside > scoop? How much Fortran was used ? > > > https://science.slashdot.org/story/20/01/31/1837209/nasa-is-trying-to-save-voyager-2-after-a-power-glitch-shut-down-its-instruments I have this memory, but I cannot verify it. When I first joined the ACM, I got to select what SIGs I wanted to (sub?)join. SIGPLAN seemed interesting because, hey, programming languages are kind of cool, so I joined it. At the time, they distributed a newsletter called, I think, the "Fortran Forum"; perhaps that was even a subgroup inside of SIGPLAN. I only remember getting one or two issues of the newsletter. But I believe one of them had an article about Voyager and the use of Fortran. The article stuck out to me because it mentioned that they thought the mission would only has for (however long), but of course it's been going on much longer than originally anticipated. However, I can find no reference to that now, and perhaps the article I'm recalling wasn't talking about either Fortran (forth as an alternative?) or a mission other than Voyager. Regardless, one DOES wonder in what capacity FORTRAN was used in the mission. Was it used on the onboard computers, or was it used on the downlink stations for e.g. data analysis? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Tue Feb 4 03:01:46 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 03 Feb 2020 18:01:46 +0100 Subject: [COFF] How much Fortran? In-Reply-To: <20200203034729.GN3216@mcvoy.com> References: <20200203034729.GN3216@mcvoy.com> Message-ID: <453b0e803fee51d23b7e4d3d40edd53e@firemail.de> >How big was it 30 years ago? In my opinion, tiny compared to C. 30 years ago OK, however history doesn't stop in 1990. When I visited University in the 70ths almost all academics used fortran, no matter if physics, mathematics, economics, or even social sciences. So I was forced to learn in fortran IV. Outside the academic biotope you had to learn cobol, because almost all development of business applications used this cruel language even in 1990. For me C was a redemption given me the chance to express myself. I'm now retired and can do whatever I want to do. Hence I left behind c++, java, still using C beside golang and lots of shell scripting. From michael at kjorling.se Tue Feb 4 04:36:25 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 3 Feb 2020 18:36:25 +0000 Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: On 3 Feb 2020 12:06 -0500, from crossd at gmail.com (Dan Cross): > Regardless, one DOES wonder in what capacity FORTRAN was used in the > mission. Was it used on the onboard computers, or was it used on the > downlink stations for e.g. data analysis? I would be _extremely_ surprised if the Voyager probes themselves run FORTRAN code. Maybe, possibly, just barely _might_, they run code that was compiled from FORTRAN code, but that seems unlikely. Somewhat less unrealistically, they might run software which was initially prototyped in FORTRAN, before being translated into something else. But even that seems a stretch. Adding up the numbers in [1], the memory capacity of each of the Voyager probes comes out to a total of 557,248 bits (not bytes), split between custom-built computers with 16 and 18 bit word lengths. Wikipedia summarizes it as "Total number of words among the six computers is about 32K." which seems about right; 557,248/17 ~ 32,779, and two out of the three computer pairs are said to use 18-bit words. For ground data processing systems to run code written in FORTRAN does however seem plausible to me. [1] https://en.wikipedia.org/wiki/Voyager_program#Computers_and_data_processing -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From cym224 at gmail.com Tue Feb 4 05:26:52 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Mon, 3 Feb 2020 14:26:52 -0500 Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: On 02/03/20 13:36, Michael Kjörling wrote (in part): > [1] https://en.wikipedia.org/wiki/Voyager_program#Computers_and_data_processing Ref. 32 of the Wikipedia entry points to a fascinating article: https://history.nasa.gov/computers/Ch6-2.html "Voyager - The flying computer center". N. From dave at horsfall.org Tue Feb 4 05:50:52 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Feb 2020 06:50:52 +1100 (EST) Subject: [COFF] How much Fortran? In-Reply-To: References: <20200203034729.GN3216@mcvoy.com> Message-ID: On Mon, 3 Feb 2020, Clem Cole wrote: > Frankly, I would have expected the folks at this(these) NASA > contractor(s) to have used assembler in those days under the guise of > "efficiency;" but Fortran-IV would definitely have been popular at many > contractors that would have been doing the work.  The article mentions > Fortran-V which I find interesting because I did not believe it was > really much of a thing (i.e. it was never standardized).  Basically, as > I understood it from my Fortran peeps at DEC/Intel, F-V was the Waterloo > extensions (a.k.a. WatFor) that got picked up by most people and in > particular, IBM added to the FORTRAN/G or H compiler for the S/360.  DEC > had gone in a different direction still with VMS FORTRAN, although I > believe they had picked up the things like WRITE(*) from Waterloo.   And WATFIV as well, as I recall from my student days; it was closer to FORTRAN than WATFOR was (both were "student" compilers e.g. better error messages but not the best of generated code). -- Dave From wobblygong at gmail.com Tue Feb 4 11:25:25 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Tue, 4 Feb 2020 14:25:25 +1300 Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: My thoughts exactly. I was once lucky enough to visit the NASA's Tidbinbilla Tracking Station in the ACT just a few miles out of Canberra c. 1976 or 77, and they had some sizeable minicomputers in their computer room. (How many I don't know.) I imagine they would've been used to record the transmissions on tape and do some preliminary processing, before sending the tapes to NASA HQ in the States for storage and further analysis. I think what NASA did with their early probes would've made Real Programmers (TM) sit up and gasp. :) Does anyone on this list know anyone who worked at a tracking station during the 60s and 70s? They might be able to help fill in the details. Wesley Parish On 2/4/20, Michael Kjörling wrote: > On 3 Feb 2020 12:06 -0500, from crossd at gmail.com (Dan Cross): >> Regardless, one DOES wonder in what capacity FORTRAN was used in the >> mission. Was it used on the onboard computers, or was it used on the >> downlink stations for e.g. data analysis? > > I would be _extremely_ surprised if the Voyager probes themselves run > FORTRAN code. > > Maybe, possibly, just barely _might_, they run code that was compiled > from FORTRAN code, but that seems unlikely. > > Somewhat less unrealistically, they might run software which was > initially prototyped in FORTRAN, before being translated into > something else. But even that seems a stretch. > > Adding up the numbers in [1], the memory capacity of each of the > Voyager probes comes out to a total of 557,248 bits (not bytes), split > between custom-built computers with 16 and 18 bit word lengths. > Wikipedia summarizes it as "Total number of words among the six > computers is about 32K." which seems about right; 557,248/17 ~ 32,779, > and two out of the three computer pairs are said to use 18-bit words. > > For ground data processing systems to run code written in FORTRAN does > however seem plausible to me. > > [1] > https://en.wikipedia.org/wiki/Voyager_program#Computers_and_data_processing > > -- > Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > From rudi.j.blom at gmail.com Thu Feb 6 14:59:11 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 6 Feb 2020 11:59:11 +0700 Subject: [COFF] How much Fortran? Message-ID: Regarding Nasa's Tidbinbilla Tracking station, someone suggested to me they might have had MODCOMPs https://en.wikipedia.org/wiki/MODCOMP Cheers, uncle rubl =========== From: Wesley Parish To: Computer Old Farts Followers Cc: Bcc: Date: Tue, 4 Feb 2020 14:25:25 +1300 Subject: Re: [COFF] How much Fortran? My thoughts exactly. I was once lucky enough to visit the NASA's Tidbinbilla Tracking Station in the ACT just a few miles out of Canberra c. 1976 or 77, and they had some sizeable minicomputers in their computer room. (How many I don't know.) I imagine they would've been used to record the transmissions on tape and do some preliminary processing, before sending the tapes to NASA HQ in the States for storage and further analysis. I think what NASA did with their early probes would've made Real Programmers (TM) sit up and gasp. :) Does anyone on this list know anyone who worked at a tracking station during the 60s and 70s? They might be able to help fill in the details. Wesley Parish From dave at horsfall.org Fri Feb 7 06:04:43 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 7 Feb 2020 07:04:43 +1100 (EST) Subject: [COFF] How much Fortran? In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020, Rudi Blom wrote: > Regarding Nasa's Tidbinbilla Tracking station, someone suggested to me > they might have had MODCOMPs Dunno about Tidbinbilla, but Parkes ("The Dish") has a roomful of Linux boxen; I didn't have time to enquire further. -- Dave From rudi.j.blom at gmail.com Fri Feb 7 15:07:46 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Fri, 7 Feb 2020 12:07:46 +0700 Subject: [COFF] =?utf-8?q?=28no_subject=29?= Message-ID: >From: Dave Horsfall >To: Computer Old Farts Followers >Cc: >Bcc: >Date: Fri, 7 Feb 2020 07:04:43 +1100 (EST) >Subject: Re: [COFF] How much Fortran? >On Thu, 6 Feb 2020, Rudi Blom wrote: > >>Regarding Nasa's Tidbinbilla Tracking station, someone suggested to me they might >>have had MODCOMPs > >Dunno about Tidbinbilla, but Parkes ("The Dish") has a roomful of Linux boxen; I didn't >have time to enquire further. >-- Dave The questions was "Does anyone on this list know anyone who worked at a tracking station during the 60s and 70s? They might be able to help fill in the details." Maybe MODCOMP, but at THAT time for sure no Linux. Cheers From dave at horsfall.org Sat Feb 8 07:09:20 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Feb 2020 08:09:20 +1100 (EST) Subject: [COFF] How much Fortran? Message-ID: On Fri, 7 Feb 2020, Rudi Blom wrote: >>> Regarding Nasa's Tidbinbilla Tracking station, someone suggested to me >>> they might >>have had MODCOMPs >> >> Dunno about Tidbinbilla, but Parkes ("The Dish") has a roomful of Linux >> boxen; I didn't >have time to enquire further. > > The questions was > > "Does anyone on this list know anyone who worked at a tracking station > during the 60s and 70s? They might be able to help fill in the details." > > Maybe MODCOMP, but at THAT time for sure no Linux. I didn't say there was.... Where did you get that idea? -- Dave From grog at lemis.com Sat Feb 8 09:15:07 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 8 Feb 2020 10:15:07 +1100 Subject: [COFF] Confused managers (was finger usage (was: pronouncing *nix formulas (was: screen editors))) In-Reply-To: References: <20200207002114.GA6005@eureka.lemis.com> <20200207050700.GD6005@eureka.lemis.com> Message-ID: <20200207231507.GA75158@eureka.lemis.com> On Saturday, 8 February 2020 at 9:37:22 +1100, Dave Horsfall wrote: > On Fri, 7 Feb 2020, Greg 'groggy' Lehey wrote: > >> But over the years I've been surprised how many people have been fooled. > > I'm sure that we've all pulled pranks like that. My favourite was piping > the output of "man" (a shell script on that system) through "Valley Girl" > (where each "!" was followed e.g. by "Gag me with a spoon!" etc). > > Well, $BOSS came into the office after a "heavy" night, and did something > like "man uucp", not quite figuring out what was wrong; I was summoned > shortly afterwards, as I was the only possible culprit... That brings back another recollection, not Unix-related. In about 1978 I was getting fed up with the lack of clear text error messages from Tandem's Guardian operating system. A typical message might be FILE SYSTEM ERROR 011 Yes, Tandem didn't use leading 0 to indicate octal. This basically meant ENOENT, but it was all that the end user saw. By chance I had been hacking in the binaries and found ways to catch such messages and put them through a function which converted them into clear text messages. For reasons that no longer make sense to me, I stored the texts in an external file, which required a program to update it. Early one morning I was playing around with this, and for the fun of it I changed the text for error 11 from "File not found" to "Please enter FUP PURGE ! *" (effectively rm -f *). I was still giggling about this when the project manager came to me and said "Mr. Lehey, I think I've done something silly". Thank God for backups! We were in a big IBM shop, and the operators religiously ran a backup every night. Nothing lost. 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 Sat Feb 8 10:32:28 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 8 Feb 2020 11:32:28 +1100 Subject: [COFF] BDS C (was: Screen editors) In-Reply-To: References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: <20200208003228.GB75158@eureka.lemis.com> Moving to COFF to avoid the wrath of wkt. On Friday, 7 February 2020 at 18:54:33 -0500, Richard Salz wrote: > BDS C stood for Brain-Damaged Software, it was the work of one guy (Leor > Zolman). I think it was used to build the Mark of the Unicorn stuff > (MINCE, Mince is not complete emacs, and Scribble, a scribe clone). Correct. That's how I came in contact with it (and Emacs, for that matter). 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 Sat Feb 8 11:10:18 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 7 Feb 2020 17:10:18 -0800 Subject: [COFF] BDS C (was: Screen editors) In-Reply-To: <20200208003228.GB75158@eureka.lemis.com> References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> <20200208003228.GB75158@eureka.lemis.com> Message-ID: <20200208011018.GX21264@mcvoy.com> On Sat, Feb 08, 2020 at 11:32:28AM +1100, Greg 'groggy' Lehey wrote: > Moving to COFF to avoid the wrath of wkt. > > On Friday, 7 February 2020 at 18:54:33 -0500, Richard Salz wrote: > > BDS C stood for Brain-Damaged Software, it was the work of one guy (Leor > > Zolman). I think it was used to build the Mark of the Unicorn stuff > > (MINCE, Mince is not complete emacs, and Scribble, a scribe clone). > > Correct. That's how I came in contact with it (and Emacs, for that > matter). It may have been brain damaged but it compiled pretty tight code. I spent at least 2 years writing code with BDS C, maybe more. Then moved to a Unix PC and never looked back (rotating disk is a lot nicer than floppies). From clemc at ccc.com Sat Feb 8 12:37:46 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 7 Feb 2020 18:37:46 -0800 Subject: [COFF] BDS C (was: Screen editors) In-Reply-To: <20200208011018.GX21264@mcvoy.com> References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> <20200208003228.GB75158@eureka.lemis.com> <20200208011018.GX21264@mcvoy.com> Message-ID: As I mentioned before, I remember showing Dennis Leor's Unix clone he built with it running on a Z80 / S100 box at an early Usenix and dmr commenting he was impressed and that it reminded him of early Unix versions. On Fri, Feb 7, 2020 at 5:10 PM Larry McVoy wrote: > On Sat, Feb 08, 2020 at 11:32:28AM +1100, Greg 'groggy' Lehey wrote: > > Moving to COFF to avoid the wrath of wkt. > > > > On Friday, 7 February 2020 at 18:54:33 -0500, Richard Salz wrote: > > > BDS C stood for Brain-Damaged Software, it was the work of one guy > (Leor > > > Zolman). I think it was used to build the Mark of the Unicorn stuff > > > (MINCE, Mince is not complete emacs, and Scribble, a scribe clone). > > > > Correct. That's how I came in contact with it (and Emacs, for that > > matter). > > It may have been brain damaged but it compiled pretty tight code. > I spent at least 2 years writing code with BDS C, maybe more. Then moved > to a Unix PC and never looked back (rotating disk is a lot nicer than > floppies). > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Feb 8 17:36:19 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 8 Feb 2020 17:36:19 +1000 Subject: [COFF] Idea: a regular video chat Message-ID: <20200208073619.GC23759@minnie.tuhs.org> [x-posting to COFF] Idea: anybody interested in a regular video chat? I was thinking of one that progresses(*) through three different timezones (Asia/Aus/NZ, then the Americas, then Europe/Africa) so that everybody should be able to get to two of the three timezones. (* like a progressive dinner) 30-60 minutes each one, general old computing. Perhaps a guest speaker now and then with a short presentation. Perhaps a theme now and then. Perhaps just chew the fat, shoot the breeze as well. Platform: Zoom or I'd be happy to set up a private Jitsi instance. Something else? How often: perhaps weekly or fortnightly through the three timezones, so it would cycle back every three or six weeks. Comments, suggestions?! Cheers, Warren From clemc at ccc.com Sun Feb 9 01:41:03 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 8 Feb 2020 07:41:03 -0800 Subject: [COFF] Idea: a regular video chat In-Reply-To: <20200208073619.GC23759@minnie.tuhs.org> References: <20200208073619.GC23759@minnie.tuhs.org> Message-ID: Possibly - signal works really well and has few if any issues security/privacy/ownership issues. Clem On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey wrote: > [x-posting to COFF] > > Idea: anybody interested in a regular video chat? I was thinking of > one that progresses(*) through three different timezones (Asia/Aus/NZ, > then the Americas, then Europe/Africa) so that everybody should be > able to get to two of the three timezones. > > (* like a progressive dinner) > > 30-60 minutes each one, general old computing. Perhaps a guest speaker > now and then with a short presentation. Perhaps a theme now and then. > Perhaps just chew the fat, shoot the breeze as well. > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > Something else? > > How often: perhaps weekly or fortnightly through the three timezones, > so it would cycle back every three or six weeks. > > Comments, suggestions?! > > Cheers, Warren > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Sun Feb 9 02:06:49 2020 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sat, 8 Feb 2020 16:06:49 +0000 Subject: [COFF] [TUHS] Idea: a regular video chat In-Reply-To: References: <20200208073619.GC23759@minnie.tuhs.org> Message-ID: <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> On 08/02/2020 15:41, Clem Cole wrote: > Possibly -  signal works really well and has few if any issues > security/privacy/ownership issues. I think it's a WONDERFUL idea!! I don't mind what multimedia and video converencing technology we use. (Obviously it must meet fundmental technical requirements.) The point that Clem makes about "security/privacy/ownership issues" is important. Now could be a good time for one to open the discussion about their expectations. Andrew > On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey > wrote: > > [x-posting to COFF] > > Idea: anybody interested in a regular video chat? I was thinking of > one that progresses(*) through three different timezones (Asia/Aus/NZ, > then the Americas, then Europe/Africa) so that everybody should be > able to get to two of the three timezones. > >  (* like a progressive dinner) > > 30-60 minutes each one, general old computing. Perhaps a guest speaker > now and then with a short presentation. Perhaps a theme now and then. > Perhaps just chew the fat, shoot the breeze as well. > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > Something else? > > How often: perhaps weekly or fortnightly through the three timezones, > so it would cycle back every three or six weeks. > > Comments, suggestions?! > > Cheers, Warren > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > From pechter at gmail.com Sun Feb 9 09:48:33 2020 From: pechter at gmail.com (William Pechter) Date: Sat, 8 Feb 2020 18:48:33 -0500 Subject: [COFF] [TUHS] UNIBUS issues (Was: Spacewar at Bell Labs) In-Reply-To: <20200208185942.AD27118C0EB@mercury.lcs.mit.edu> References: <20200208185942.AD27118C0EB@mercury.lcs.mit.edu> Message-ID: Took this to coff since it's really hardware and non-Unix... On 2/8/20 1:59 PM, Noel Chiappa wrote: > > From: Dave Horsfall > > > [ Getting into COFF territory, I think ] > > > > > In all fairness, the entire field didn't really appreciate the metastability > issue until the LINC guys at WUSTL did a big investigation of it, and then > started a big campaign to educate everyone about it - it wasn't DEC being > particularly clueless. > > > > Hey, if the DEC marketoids didn't want 3rd-party UNIBUS implementations > > then why was it published? > > Well, exactly - but it's useful to remember the differening situation for DEC > from 1970 (first PDP-11's) and later. > > In 1970 DEC was mostly selling to scientists/engineers, who wanted to hook up > to some lab equipment they'd built, and OEM's, who often wanted to use a mini > to control some value-added gear of their own devising. An open bus was really > necessary for those markets. Which is why the 1970 PDP-11/20 manual goes into > a lot of detail on how to interface to the PDP-11's UNIBUS. > > Later, of course, they were in a different business model. > > Noel My old Field Service memory is DEC never really went after Unibus interfaces and the spec was open.  It was connections to the big old Massbus for things like tapes and disks that they kept closed and used patent protection on along with the SBI and the later Vax BI bus.  DEC was the only maker of the BIIC chip from the VAXBI and the wouldn't sell it to competitors... Braegan (may be a spelling error) made interfaces to connect Calcomp hard disks to the PDP11's on a Massbus.  IIRC they were shut down hard with legal action.  I had a customer with a Unisys (formerly RCA) Spectra 70 system that had Braegan Calcomp drives with an Eatontown, NJ based  Diva Disk controller.  My tech school instructor pre-DEC career worked for Diva Disk as an engineer. Systems Industries, later (EMC), cloned the Massbus Adapter on the SBI Bus and didn't directly share the bus or controller with DEC sold disk drives so the SI-9400 showed up on DEC 11/780's (and I think they had an 11/70 controller as well.  DEC, IIRC went after them about them using the SBI backplane interconnect. A Google search showed up this note about EMC Memory boards in Vaxes but also mentions DEC patent suits against people who used the Massbus.  I don't remember that on Unibus devices like the controllers from Emulex and others. (Until they tried to deal with the Vax BI bus -- a DEC chip only or the MSCP disk subsystems.) Like you say, different time, different business model.  Many inside DEC wanted them to OEM Sell Vax chips like they did PDP11 LSI/F11/J11 chips.  There are a number of DECcies who feel that attitude came over with the influx of IBM'ers and others who came to DEC in the Vax period to sell into the Data Centers. They were really protecting the "family-er-crown jewels" back then to the company's detriment. Old Computerworld and Datamation adverts along with PR releases are what I find when searching, unfortunately.  Here's a suit against EMC --  which cloned DEC memory products and interfaced to the SBI 11/78x  bus. https://books.google.com/books?id=0sNDKMzgG8gC&pg=RA1-PA70&dq=DEC%2BMassbus%2BPatent&hl=en&sa=X&ved=2ahUKEwje5YDE1sLnAhXqmOAKHdXLCOwQ6AEwAXoECAIQAg#v=onepage&q=DEC%2BMassbus%2BPatent&f=false Along with the DIVA Computroller V there's another picture at the left of the page with a different emulating controller. Here's a Legal CDC9766 (I think) on a Plessey controller that plugged into an RH70 but didn't use the actual DEC Massbus (probably the CDC A and B SMD cables... (Storage Module Device? IIRC) https://books.google.com/books?id=-Nentjp6qSMC&pg=RA1-PA66&dq=eatontown,+nj+disk+controller+microprocessor&hl=en&sa=X&ved=2ahUKEwj5r76f2MLnAhXCrFkKHeRCD_cQ6AEwAXoECAMQAg#v=onepage&q=eatontown%2C%20nj%20disk%20controller%20microprocessor&f=false DEC even took the Emulex controllers on service contract in the late 80's. Bill From coppero1237 at gmail.com Sun Feb 9 03:50:40 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Sat, 8 Feb 2020 19:50:40 +0200 Subject: [COFF] [TUHS] Idea: a regular video chat In-Reply-To: <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> References: <20200208073619.GC23759@minnie.tuhs.org> <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> Message-ID: Very cool, would love it! Tyler On Sat, Feb 8, 2020 at 6:07 PM U'll Be King of the Stars < ullbeking at andrewnesbit.org> wrote: > On 08/02/2020 15:41, Clem Cole wrote: > > Possibly - signal works really well and has few if any issues > > security/privacy/ownership issues. > > I think it's a WONDERFUL idea!! > > I don't mind what multimedia and video converencing technology we use. > (Obviously it must meet fundmental technical requirements.) > > The point that Clem makes about "security/privacy/ownership issues" is > important. Now could be a good time for one to open the discussion > about their expectations. > > Andrew > > > > On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey > > wrote: > > > > [x-posting to COFF] > > > > Idea: anybody interested in a regular video chat? I was thinking of > > one that progresses(*) through three different timezones > (Asia/Aus/NZ, > > then the Americas, then Europe/Africa) so that everybody should be > > able to get to two of the three timezones. > > > > (* like a progressive dinner) > > > > 30-60 minutes each one, general old computing. Perhaps a guest > speaker > > now and then with a short presentation. Perhaps a theme now and then. > > Perhaps just chew the fat, shoot the breeze as well. > > > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > > Something else? > > > > How often: perhaps weekly or fortnightly through the three timezones, > > so it would cycle back every three or six weeks. > > > > Comments, suggestions?! > > > > Cheers, Warren > > _______________________________________________ > > COFF mailing list > > COFF at minnie.tuhs.org > > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sun Feb 9 10:39:53 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 10:39:53 +1000 Subject: [COFF] Discord channels for COFF/TUHS Message-ID: <20200209003953.GA7353@minnie.tuhs.org> All, Silent700 has graciously set up channels underneath the ClassicCMP Discord server for COFF and TUHS: COFF: https://discordapp.com/channels/642419539946110997/675860587355308049 TUHS: https://discordapp.com/channels/642419539946110997/675860622738718775 I thought it made sense to have the channels on a server where there was already old computer people (old for either or both :-). Cheers, Warren From wkt at tuhs.org Sun Feb 9 10:48:54 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 10:48:54 +1000 Subject: [COFF] Also, a video service Message-ID: <20200209004854.GB7353@minnie.tuhs.org> All, I've also set this up to try out for the video chats: https://meet.tuhs.org/COFF Password to join is "unix" at the moment. I just want to test it to confirm that it works; I'll be heading out the door to go to the shops soon. Cheers, Warren From wkt at tuhs.org Sun Feb 9 12:02:46 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 12:02:46 +1000 Subject: [COFF] [TUHS] Also, a video service In-Reply-To: <20200209004854.GB7353@minnie.tuhs.org> References: <20200209004854.GB7353@minnie.tuhs.org> Message-ID: <20200209020246.GA19979@minnie.tuhs.org> On Sun, Feb 09, 2020 at 10:48:54AM +1000, Warren Toomey wrote: > All, I've also set this up to try out for the video chats: > https://meet.tuhs.org/COFF > I just want to test it to confirm that it works. It works, thanks to the four or five who popped in to test it. I'm thinking of a weekly rotation through these timezones: UTC Brisbane New Jersey Week 1: 8am 6pm 3am Week 2: 1pm 11pm 8am Week 3: 10pm 8am 5pm We'd need a volunteer from each timezone to start up the channel and to (try to) keep some order. Any takers? Cheers, Warren From wkt at tuhs.org Mon Feb 10 06:17:09 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 10 Feb 2020 06:17:09 +1000 Subject: [COFF] Discord channels for COFF/TUHS In-Reply-To: <20200209003953.GA7353@minnie.tuhs.org> References: <20200209003953.GA7353@minnie.tuhs.org> Message-ID: <20200209201709.GA23015@minnie.tuhs.org> On Sun, Feb 09, 2020 at 10:39:53AM +1000, Warren Toomey wrote: > All, Silent700 has graciously set up channels underneath the ClassicCMP > Discord server for COFF and TUHS: I got the invites wrong. Try these ones: COFF: https://discord.gg/qebJXw TUHS: https://discord.gg/BdmzZP Thanks to those who pointed this out. Cheers, Warren From grog at lemis.com Mon Feb 10 08:56:38 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 10 Feb 2020 09:56:38 +1100 Subject: [COFF] Also, a video service In-Reply-To: <20200209004854.GB7353@minnie.tuhs.org> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> Message-ID: <20200209225638.GG75158@eureka.lemis.com> On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: > All, I've also set this up to try out for the video chats: > https://meet.tuhs.org/COFF > Password to join is "unix" at the moment. > I just want to test it to confirm that it works; I'll be heading > out the door to go to the shops soon. Just tried it out. On FreeBSD I get a blank grey screen. I could only get something more on a Microsoft box, not quite what I'd want to do. Is there some trick? 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 Mon Feb 10 09:21:32 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 09 Feb 2020 15:21:32 -0800 Subject: [COFF] [TUHS] Also, a video service In-Reply-To: Your message of "Mon, 10 Feb 2020 09:56:38 +1100." <20200209225638.GG75158@eureka.lemis.com> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> Message-ID: <20200209232139.B85D0156E40E@mail.bitblocks.com> On Mon, 10 Feb 2020 09:56:38 +1100 Greg 'groggy' Lehey wrote: > On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: > > All, I've also set this up to try out for the video chats: > > https://meet.tuhs.org/COFF > > Password to join is "unix" at the moment. > > I just want to test it to confirm that it works; I'll be heading > > out the door to go to the shops soon. > > Just tried it out. On FreeBSD I get a blank grey screen. I could > only get something more on a Microsoft box, not quite what I'd want to > do. Is there some trick? I was able to connect from a MacBookPro. This seems to be Jitsi. There is a jitsi package for FreeBSD-11. Unfortunately /usr/ports/net-im/jitsi is broken (unfetchable). No idea if any of the linux downloads from jitsi.org would work. From wobblygong at gmail.com Mon Feb 10 13:35:44 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 10 Feb 2020 16:35:44 +1300 Subject: [COFF] [TUHS] Also, a video service In-Reply-To: <20200209232139.B85D0156E40E@mail.bitblocks.com> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> <20200209232139.B85D0156E40E@mail.bitblocks.com> Message-ID: Thanks, Bakul. I'm just now installing jitsi on one of my Linux boxen. Speaking of FreeBSD and MacOS, I'm sure the source code at https://download.jitsi.org/jitsi/src/ will compile on FreeBSD with a simple ./configure and make. Wesley Parish On 2/10/20, Bakul Shah wrote: > On Mon, 10 Feb 2020 09:56:38 +1100 Greg 'groggy' Lehey > wrote: >> On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: >> > All, I've also set this up to try out for the video chats: >> > https://meet.tuhs.org/COFF >> > Password to join is "unix" at the moment. >> > I just want to test it to confirm that it works; I'll be heading >> > out the door to go to the shops soon. >> >> Just tried it out. On FreeBSD I get a blank grey screen. I could >> only get something more on a Microsoft box, not quite what I'd want to >> do. Is there some trick? > > I was able to connect from a MacBookPro. This seems to be > Jitsi. There is a jitsi package for FreeBSD-11. Unfortunately > /usr/ports/net-im/jitsi is broken (unfetchable). No idea if > any of the linux downloads from jitsi.org would work. > From clemc at ccc.com Wed Feb 12 04:41:01 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Feb 2020 13:41:01 -0500 Subject: [COFF] Old and Tradition was [TUHS] V9 shell Message-ID: moving to COFF On Tue, Feb 11, 2020 at 5:00 AM Rob Pike wrote: > My general mood about the current standard way of nerd working is how > unimaginative and old-fashioned it feels. > ... > > But I'm a grumpy old man and getting far off topic. Warren should cry, > "enough!". > > -rob > @Rob - I hear you and I'm sure there is a solid amount of wisdom in your words. But I caution that just, because something is old-fashioned, does not necessarily make it wrong (much less bad). I ask you to take a look at the Archer statistics of code running in production (Archer large HPC site in Europe): http://archer.ac.uk/status/codes/ I think there are similar stats available for places like CERN, LRZ, and of the US labs, but I know of these so I point to them. Please note that Fortran is #1 (about 80%) followed by C @ about 10%, C++ @ 8%, Python @ 1% and all the others at 1%. Why is that? The math has not changed ... and open up any of those codes and what do you see: solving systems of differential equations with linear algebra. It's the same math my did by hand as a 'computer' in the 1950s. There is not 'tensor flows' or ML searches running SPARK in there. Sorry, Google/AWS et al. Nothing 'modern' and fresh -- just solid simple science being done by scientists who don't care about the computer or sexy new computer languages. IIRC, you trained as a physicist, I think you understand their thinking. *They care about getting their science done.* By the way, a related thought comes from a good friend of mine from college who used to be the Chief Metallurgist for the US Gov (NIST in Colorado). He's back in the private sector now (because he could not stomach current American politics), but he made an important observation/comment to me a couple of years ago. They have 60+ years of metallurgical data that has and his peeps have been using with known Fortran codes. If we gave him new versions of those analytical programs now in your favorite new HLL - pick one - your Go (which I love), C++ (which I loath), DPC++, Rust, Python - whatever, the scientists would have to reconfirm previous results. They are not going to do that. It's not economical. They 'know' how the data works, the types of errors they have, how the programs behave* etc*. So to me, the bottom line is just because it's old fashioned does not make it bad. I don't want to write an OS in Fortran-2018, but I can wrote a system that supports code compiled with my sexy new Fortran-2018 compiler. That is to say, the challenge for >>me<< is to build him a new supercomputer that can run those codes for him and not change what they are doing and have them scale to 1M nodes *etc*.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Feb 12 10:57:04 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 11 Feb 2020 17:57:04 -0700 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Adam Thornton Date: Tue, Feb 11, 2020 at 5:56 PM Subject: Re: [COFF] Old and Tradition was [TUHS] V9 shell To: Clem Cole As someone working in this area right now....yeah, and that’s why traditional HPC centers do not deliver the services we want for projects like the Vera Rubin Observatory’s Legacy Survey Of Space and Time. Almost all of our scientist-facing code is Python though a lot of the performance critical stuff is implemented in C++ with Python bindings. The incumbents are great at running data centers like they did in 1993. That’s not the best fit for our current workload. It’s not generally the compute that needs to be super-fast: it’s access to arbitrary slices through really large data sets that is the interesting problem for us. That’s not to say that that lfortran isn’t cool. It really really is, and Ondrej Cestik has done amazing work in making modern FORTRAN run in a Jupyter notebook, and the implications (LLVM becomes the Imagemagick of compiled languages) are astounding. But...HPC is no longer the cutting edge. We are seeing a Kuhnian paradigm shift in action, and, sure, the old guys (and they are overwhelmingly guys) who have tenure and get the big grants will never give up FORTRAN which after all was good enough for their grandpappy and therefore good enough for them. But they will retire. Scaling out is way way cheaper than scaling up. On Tue, Feb 11, 2020 at 11:41 AM Clem Cole wrote: > moving to COFF > > On Tue, Feb 11, 2020 at 5:00 AM Rob Pike wrote: > >> My general mood about the current standard way of nerd working is how >> unimaginative and old-fashioned it feels. >> > ... >> >> But I'm a grumpy old man and getting far off topic. Warren should cry, >> "enough!". >> >> -rob >> > > @Rob - I hear you and I'm sure there is a solid amount of wisdom in your > words. But I caution that just, because something is old-fashioned, does > not necessarily make it wrong (much less bad). > > I ask you to take a look at the Archer statistics of code running in > production (Archer large HPC site in Europe): > http://archer.ac.uk/status/codes/ > > I think there are similar stats available for places like CERN, LRZ, and > of the US labs, but I know of these so I point to them. > > Please note that Fortran is #1 (about 80%) followed by C @ about 10%, > C++ @ 8%, Python @ 1% and all the others at 1%. > > Why is that? The math has not changed ... and open up any of those codes > and what do you see: solving systems of differential equations with linear > algebra. It's the same math my did by hand as a 'computer' in the 1950s. > > There is not 'tensor flows' or ML searches running SPARK in there. Sorry, > Google/AWS et al. Nothing 'modern' and fresh -- just solid simple science > being done by scientists who don't care about the computer or sexy new > computer languages. > > IIRC, you trained as a physicist, I think you understand their thinking. *They > care about getting their science done.* > > By the way, a related thought comes from a good friend of mine from > college who used to be the Chief Metallurgist for the US Gov (NIST in > Colorado). He's back in the private sector now (because he could not > stomach current American politics), but he made an important > observation/comment to me a couple of years ago. They have 60+ years of > metallurgical data that has and his peeps have been using with known > Fortran codes. If we gave him new versions of those analytical programs > now in your favorite new HLL - pick one - your Go (which I love), C++ > (which I loath), DPC++, Rust, Python - whatever, the scientists would have > to reconfirm previous results. They are not going to do that. It's not > economical. They 'know' how the data works, the types of errors they > have, how the programs behave* etc*. > > So to me, the bottom line is just because it's old fashioned does not make > it bad. I don't want to write an OS in Fortran-2018, but I can wrote a > system that supports code compiled with my sexy new Fortran-2018 compiler. > > That is to say, the challenge for >>me<< is to build him a new > supercomputer that can run those codes for him and not change what they are > doing and have them scale to 1M nodes *etc*.. > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 12 11:58:50 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Feb 2020 20:58:50 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: Message-ID: Fwiw. I'm sure your observations are solid and do make some good sense for you. But I ask you to consider the words you used defending your choices are almostly exactly what was said by my CS profs at CMU and UCB on the 1970s but it was Pascal not C++ and Snobol not Python as the scripting front end. 40 yrs later Fortran has matured but as Stu Feldman famously said in 1977 - he did not what it would look like but in the future (year 2000) we will still call it Fortran. He was right and we still do. Hey I'm a die hard systems person and as I said C is my primary tool to do my own job (I don't write in Fortran) but I do understand what pays my salary (and has my entire career). My experience has always been that Scientists (of both sexs) don't care about the computer language nearly as much as they do about getting their science done and trusting the data sets that describe it. Don't take my word for it. Look at the URL I gave you. Check out the same data from the other big sites around the world - USA, UK, EU, JP, CN, RU, and IN. I think you'll discover similar graphics. Fortran has been pretty much constant at #1. What has changed over the years is the languages used to prep the scientific data before running it throught the primary HPC tool. We can take this off line if you like but imo the reason has been/continue s to be - is economics of the existing code base is extremely difficult to displace. It's not an old guy / new guy thing. It's when you get money to do your science it's not cost effective to replace something you trust just because you don't like the computer language. More over i know of only one case we're a production code originally written in Fortran was successfully replaced - in grad school years ago, my old housemate Tom Quarles wrote SPICE3 in C to replace the original SPICE2. but note Tom had to do a huge amount of work to maintain the performance. I also know of a couple of other commercial Mech E CAD and one Oil and Gas code that tried to go to C++ but fell back to the original Fortran. Anyway best wishes but be careful. Noel's email has much wisdom. New is not necessarily better and old fashioned is not always a bad thing. Clem On Tue, Feb 11, 2020 at 7:57 PM Adam Thornton wrote: > > > ---------- Forwarded message --------- > From: Adam Thornton > Date: Tue, Feb 11, 2020 at 5:56 PM > Subject: Re: [COFF] Old and Tradition was [TUHS] V9 shell > To: Clem Cole > > > As someone working in this area right now....yeah, and that’s why > traditional HPC centers do not deliver the services we want for projects > like the Vera Rubin Observatory’s Legacy Survey Of Space and Time. > > Almost all of our scientist-facing code is Python though a lot of the > performance critical stuff is implemented in C++ with Python bindings. > > The incumbents are great at running data centers like they did in 1993. > That’s not the best fit for our current workload. It’s not generally the > compute that needs to be super-fast: it’s access to arbitrary slices > through really large data sets that is the interesting problem for us. > > That’s not to say that that lfortran isn’t cool. It really really is, and > Ondrej Cestik has done amazing work in making modern FORTRAN run in a > Jupyter notebook, and the implications (LLVM becomes the Imagemagick of > compiled languages) are astounding. > > But...HPC is no longer the cutting edge. We are seeing a Kuhnian paradigm > shift in action, and, sure, the old guys (and they are overwhelmingly guys) > who have tenure and get the big grants will never give up FORTRAN which > after all was good enough for their grandpappy and therefore good enough > for them. But they will retire. Scaling out is way way cheaper than > scaling up. > > On Tue, Feb 11, 2020 at 11:41 AM Clem Cole wrote: > >> moving to COFF >> >> On Tue, Feb 11, 2020 at 5:00 AM Rob Pike wrote: >> >>> My general mood about the current standard way of nerd working is how >>> unimaginative and old-fashioned it feels. >>> >> ... >>> >>> But I'm a grumpy old man and getting far off topic. Warren should cry, >>> "enough!". >>> >>> -rob >>> >> >> @Rob - I hear you and I'm sure there is a solid amount of wisdom in your >> words. But I caution that just, because something is old-fashioned, does >> not necessarily make it wrong (much less bad). >> >> I ask you to take a look at the Archer statistics of code running in >> production (Archer large HPC site in Europe): >> http://archer.ac.uk/status/codes/ >> >> I think there are similar stats available for places like CERN, LRZ, and >> of the US labs, but I know of these so I point to them. >> >> Please note that Fortran is #1 (about 80%) followed by C @ about 10%, >> C++ @ 8%, Python @ 1% and all the others at 1%. >> >> Why is that? The math has not changed ... and open up any of those >> codes and what do you see: solving systems of differential equations with >> linear algebra. It's the same math my did by hand as a 'computer' in the >> 1950s. >> >> There is not 'tensor flows' or ML searches running SPARK in there. >> Sorry, Google/AWS et al. Nothing 'modern' and fresh -- just solid simple >> science being done by scientists who don't care about the computer or sexy >> new computer languages. >> >> IIRC, you trained as a physicist, I think you understand their thinking. *They >> care about getting their science done.* >> >> By the way, a related thought comes from a good friend of mine from >> college who used to be the Chief Metallurgist for the US Gov (NIST in >> Colorado). He's back in the private sector now (because he could not >> stomach current American politics), but he made an important >> observation/comment to me a couple of years ago. They have 60+ years of >> metallurgical data that has and his peeps have been using with known >> Fortran codes. If we gave him new versions of those analytical programs >> now in your favorite new HLL - pick one - your Go (which I love), C++ >> (which I loath), DPC++, Rust, Python - whatever, the scientists would have >> to reconfirm previous results. They are not going to do that. It's not >> economical. They 'know' how the data works, the types of errors they >> have, how the programs behave* etc*. >> >> So to me, the bottom line is just because it's old fashioned does not >> make it bad. I don't want to write an OS in Fortran-2018, but I can wrote >> a system that supports code compiled with my sexy new Fortran-2018 compiler. >> >> That is to say, the challenge for >>me<< is to build him a new >> supercomputer that can run those codes for him and not change what they are >> doing and have them scale to 1M nodes *etc*.. >> >> _______________________________________________ >> COFF mailing list >> COFF at minnie.tuhs.org >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff >> > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 12 13:01:52 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Feb 2020 19:01:52 -0800 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: Message-ID: <20200212030152.GJ852@mcvoy.com> I'm following this with some interest, though I don't have a horse in this race, hell, I'm not even at the race track. But still, interesting. What little Fortran background I have suggests that the difference might be mind set. Fortran programmers are formally trained (at least I was, there was a whole semester devoted to this) in accumulated errors. You did a deep dive into how to code stuff so that the error was reduced each time instead of increased. It has a lot to do with how floating point works, it's not exact like integers are. For the record, I *hate* floating point, for numerical work in C I have always tried to have "domains", these 32 bits cover the domain from 0..2^32-1, these 32 bits cover the domain from 0..2^32-1 * 2^32, etc. It's more work because you have to translate across domains but it is exact. Floating point lets you cheat but the price of cheating is the accumulated error. Maybe I'm just going off of my 35 year old training, but it seems to me that Fortran people pretty much live in floating point, and get what you have to do to make that work. C / python / systems people "understand" floating point but don't understand what you have to do to make that work. They think they do, but they mostly don't, they just haven't hit the accumulated error problem and wouldn't recognize it if they did. What do you guys think? On Tue, Feb 11, 2020 at 08:58:50PM -0500, Clem Cole wrote: > Fwiw. I'm sure your observations are solid and do make some good sense for > you. > > But I ask you to consider the words you used defending your choices are > almostly exactly what was said by my CS profs at CMU and UCB on the 1970s > but it was Pascal not C++ and Snobol not Python as the scripting front end. > 40 yrs later Fortran has matured but as Stu Feldman famously said in 1977 > - he did not what it would look like but in the future (year 2000) we will > still call it Fortran. He was right and we still do. > > Hey I'm a die hard systems person and as I said C is my primary tool to do > my own job (I don't write in Fortran) but I do understand what pays my > salary (and has my entire career). My experience has always been that > Scientists (of both sexs) don't care about the computer language nearly as > much as they do about getting their science done and trusting the data sets > that describe it. > > Don't take my word for it. Look at the URL I gave you. Check out the same > data from the other big sites around the world - USA, UK, EU, JP, CN, RU, > and IN. I think you'll discover similar graphics. Fortran has been pretty > much constant at #1. What has changed over the years is the languages > used to prep the scientific data before running it throught the primary HPC > tool. > > We can take this off line if you like but imo the reason has been/continue > s to be - is economics of the existing code base is extremely difficult to > displace. It's not an old guy / new guy thing. It's when you get money > to do your science it's not cost effective to replace something you trust > just because you don't like the computer language. > > More over i know of only one case we're a production code originally > written in Fortran was successfully replaced - in grad school years ago, my > old housemate Tom Quarles wrote SPICE3 in C to replace the original SPICE2. > but note Tom had to do a huge amount of work to maintain the performance. > I also know of a couple of other commercial Mech E CAD and one Oil and Gas > code that tried to go to C++ but fell back to the original Fortran. > > Anyway best wishes but be careful. Noel's email has much wisdom. New is > not necessarily better and old fashioned is not always a bad thing. > > Clem > > On Tue, Feb 11, 2020 at 7:57 PM Adam Thornton wrote: > > > > > > > ---------- Forwarded message --------- > > From: Adam Thornton > > Date: Tue, Feb 11, 2020 at 5:56 PM > > Subject: Re: [COFF] Old and Tradition was [TUHS] V9 shell > > To: Clem Cole > > > > > > As someone working in this area right now....yeah, and that???s why > > traditional HPC centers do not deliver the services we want for projects > > like the Vera Rubin Observatory???s Legacy Survey Of Space and Time. > > > > Almost all of our scientist-facing code is Python though a lot of the > > performance critical stuff is implemented in C++ with Python bindings. > > > > The incumbents are great at running data centers like they did in 1993. > > That???s not the best fit for our current workload. It???s not generally the > > compute that needs to be super-fast: it???s access to arbitrary slices > > through really large data sets that is the interesting problem for us. > > > > That???s not to say that that lfortran isn???t cool. It really really is, and > > Ondrej Cestik has done amazing work in making modern FORTRAN run in a > > Jupyter notebook, and the implications (LLVM becomes the Imagemagick of > > compiled languages) are astounding. > > > > But...HPC is no longer the cutting edge. We are seeing a Kuhnian paradigm > > shift in action, and, sure, the old guys (and they are overwhelmingly guys) > > who have tenure and get the big grants will never give up FORTRAN which > > after all was good enough for their grandpappy and therefore good enough > > for them. But they will retire. Scaling out is way way cheaper than > > scaling up. > > > > On Tue, Feb 11, 2020 at 11:41 AM Clem Cole wrote: > > > >> moving to COFF > >> > >> On Tue, Feb 11, 2020 at 5:00 AM Rob Pike wrote: > >> > >>> My general mood about the current standard way of nerd working is how > >>> unimaginative and old-fashioned it feels. > >>> > >> ... > >>> > >>> But I'm a grumpy old man and getting far off topic. Warren should cry, > >>> "enough!". > >>> > >>> -rob > >>> > >> > >> @Rob - I hear you and I'm sure there is a solid amount of wisdom in your > >> words. But I caution that just, because something is old-fashioned, does > >> not necessarily make it wrong (much less bad). > >> > >> I ask you to take a look at the Archer statistics of code running in > >> production (Archer large HPC site in Europe): > >> http://archer.ac.uk/status/codes/ > >> > >> I think there are similar stats available for places like CERN, LRZ, and > >> of the US labs, but I know of these so I point to them. > >> > >> Please note that Fortran is #1 (about 80%) followed by C @ about 10%, > >> C++ @ 8%, Python @ 1% and all the others at 1%. > >> > >> Why is that? The math has not changed ... and open up any of those > >> codes and what do you see: solving systems of differential equations with > >> linear algebra. It's the same math my did by hand as a 'computer' in the > >> 1950s. > >> > >> There is not 'tensor flows' or ML searches running SPARK in there. > >> Sorry, Google/AWS et al. Nothing 'modern' and fresh -- just solid simple > >> science being done by scientists who don't care about the computer or sexy > >> new computer languages. > >> > >> IIRC, you trained as a physicist, I think you understand their thinking. *They > >> care about getting their science done.* > >> > >> By the way, a related thought comes from a good friend of mine from > >> college who used to be the Chief Metallurgist for the US Gov (NIST in > >> Colorado). He's back in the private sector now (because he could not > >> stomach current American politics), but he made an important > >> observation/comment to me a couple of years ago. They have 60+ years of > >> metallurgical data that has and his peeps have been using with known > >> Fortran codes. If we gave him new versions of those analytical programs > >> now in your favorite new HLL - pick one - your Go (which I love), C++ > >> (which I loath), DPC++, Rust, Python - whatever, the scientists would have > >> to reconfirm previous results. They are not going to do that. It's not > >> economical. They 'know' how the data works, the types of errors they > >> have, how the programs behave* etc*. > >> > >> So to me, the bottom line is just because it's old fashioned does not > >> make it bad. I don't want to write an OS in Fortran-2018, but I can wrote > >> a system that supports code compiled with my sexy new Fortran-2018 compiler. > >> > >> That is to say, the challenge for >>me<< is to build him a new > >> supercomputer that can run those codes for him and not change what they are > >> doing and have them scale to 1M nodes *etc*.. > >> > >> _______________________________________________ > >> COFF mailing list > >> COFF at minnie.tuhs.org > >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > >> > > _______________________________________________ > > COFF mailing list > > COFF at minnie.tuhs.org > > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > > > -- > Sent from a handheld expect more typos than usual > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Thu Feb 13 02:28:20 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 12 Feb 2020 11:28:20 -0500 (EST) Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell Message-ID: <20200212162820.3A3BC18C0B6@mercury.lcs.mit.edu> > From: Clem Cole > Noel's email has much wisdom. New is not necessarily better and old > fashioned is not always a bad thing. For those confused by the reference, it's to an email that didn't go to the whole list (I was not sure if people would be interested): >> One of my favourite sayings (original source unknown; I saw it in >> "Shockwave Rider"): "There are two kinds of fool. One says 'This is >> old, and therefore good'; the other says 'This is new, and therefore >> better'." Noel From clemc at ccc.com Thu Feb 13 04:12:21 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Feb 2020 13:12:21 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200212030152.GJ852@mcvoy.com> References: <20200212030152.GJ852@mcvoy.com> Message-ID: On Tue, Feb 11, 2020 at 10:01 PM Larry McVoy wrote: > What little Fortran background I have suggests that the difference > might be mind set. Fortran programmers are formally trained (at least I > was, there was a whole semester devoted to this) in accumulated errors. > You did a deep dive into how to code stuff so that the error was reduced > each time instead of increased. It has a lot to do with how floating > point works, it's not exact like integers are. Just a thought, but it might also be the training. My Dad (a mathematician and 'computer') passed a few years ago, I'd love to have asked him. But I suspect when he and his peeps were doing this with a slide rule or at best an Friden mechanical adding machine, they were acutely aware of how errors accumulated or not. When they started to convert their processes/techniques to Fortran in the early 1960s, I agree with you that I think they were conscious of what they were doing. I'm not sure modern CS types are taught the same things as what might be taught in a course being run by a pure scientist who cares in the same way folks like our mothers and fathers did in the 1950s and 60s. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 13 04:13:03 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Feb 2020 13:13:03 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200212162820.3A3BC18C0B6@mercury.lcs.mit.edu> References: <20200212162820.3A3BC18C0B6@mercury.lcs.mit.edu> Message-ID: Sorry about that. On Wed, Feb 12, 2020 at 11:45 AM Noel Chiappa wrote: > > From: Clem Cole > > > Noel's email has much wisdom. New is not necessarily better and old > > fashioned is not always a bad thing. > > For those confused by the reference, it's to an email that didn't go to the > whole list (I was not sure if people would be interested): > > >> One of my favourite sayings (original source unknown; I saw it in > >> "Shockwave Rider"): "There are two kinds of fool. One says 'This is > >> old, and therefore good'; the other says 'This is new, and therefore > >> better'." > > Noel > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Feb 13 05:15:06 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 12 Feb 2020 20:15:06 +0100 Subject: [COFF] [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> <20200211235647.TB2C9%steffen@sdaoden.eu> <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> Message-ID: <20200212191506.TKgF7%steffen@sdaoden.eu> Jon Steinhart wrote in <202002120012.01C0CpEC3910426 at darkstar.fourwinds.com>: |Steffen Nurpmeso writes: |> Of course you are right, you will likely need to focus your mind, |> and that requires an intellectual context, knowledge, to base upon. | |Interesting that you mention this as I'm about to leave for a multi-day |advanced yoga workshop. One of the things that I like about yoga is that Then i wish you a good time, and deep breath! |you do have to learn to focus your mind, and it's amazingly difficult to |be focused on something as seemingly simple as standing up straight. I |don't think that it's reasonable to expect people to be able to focus |without training. Can you imagine if a computer tried to follow all of |your fleeting thoughts? I feel clearly overrated. The last time i had such fleeting was i know when, no good, i "collapsed with overflow" like John Falkens computer in Wargames. But i have the impression that "the only winning move is not to play" is not very hip. |In some respects, this takes me back to the early days of speech recogni\ |tion. |I remember people enthusiastically telling me how it would solve the \ |problem |of repetitive stress injuries. They were surprised when I pointed out that |most people who use their voice in their work actually take vocal training; |RSIs are not uncommon among performers. | |So really, what problem are we trying to solve here? I would claim \ |that the |problem is signal-to-noise ratio degradation that's a result of too many |people "learning to code" who have never learned to think. Much like \ |I feel |that it became harder to find good music when MIDI was invented because \ |there |was all of a sudden a lot more noise masquerading as music. I am chewing on that one. You can be lucky to have lived in times with great classical music artists as well as a tremendous flurry of styles, ideas etc. otherwise. In the 60s and 70s and even the first half of the 80s so much has happened. Not only in music. Just take psychological treatment, before there was lobotomy and electrical shocks, and studied persons stood on these ground solid as rocks, but then it exploded. Today the situation is really bad. And that "everyone is an artist" was surely as naive as "everyone shall learn coding". But i have spend long hours in MIDI piano rolls and i think you are right. Unfortunately. |I'm reminded of a Usenix panel session that I moderated on the future \ |of window |systems a long time ago. Rob was on the panel as was some guy whose name I |can't remember from Silicon Graphics. The highlight of the presentation \ |was |when Robin asked the question "So, if I understand what the SGI person \ |is saying, |it doesn't matter how ugly your shirt is, you can always cover it up \ |with a nice |jacket...." While she was asking the question Rob anticipated the \ |rest of the |question and started unbuttoning his shirt. | |So maybe I'm just an old-school minimalist, but I think that the biggest \ |problem |that needs solving is good low-level abstractions that are simple and \ |work and |don't have to be papered over with layer upon layer on top of them. \ | I just find |myself without the patience to learn all of the magic incantations \ |of the package |of the week. I like that. --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 cym224 at gmail.com Thu Feb 13 07:55:57 2020 From: cym224 at gmail.com (Nemo) Date: Wed, 12 Feb 2020 16:55:57 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: On 12/02/2020, Clem Cole wrote (in part): > But I suspect when he and his peeps were doing this with a > slide rule or at best an Friden mechanical adding machine, they were > acutely aware of how errors accumulated or not. This being COFF, I feel justified in chiming in with a story from my grad student days. A fellow student was working on something -- I have forgotten the actual problem but studying some behaviour near a singularity -- and he wanted some numerical values. So he obtained Fortran code from a grad student in physics. The result blew up in his region of interest. The person who gave him the code had no interest in investigating because he was happy with the results in his region. (After months of toil, he found serious approximation errors.) N. From imp at bsdimp.com Thu Feb 13 08:11:27 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 12 Feb 2020 15:11:27 -0700 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: On Wed, Feb 12, 2020, 11:13 AM Clem Cole wrote: > > > On Tue, Feb 11, 2020 at 10:01 PM Larry McVoy wrote: > >> What little Fortran background I have suggests that the difference >> might be mind set. Fortran programmers are formally trained (at least I >> was, there was a whole semester devoted to this) in accumulated errors. >> You did a deep dive into how to code stuff so that the error was reduced >> each time instead of increased. It has a lot to do with how floating >> point works, it's not exact like integers are. > > Just a thought, but it might also be the training. My Dad (a > mathematician and 'computer') passed a few years ago, I'd love to have > asked him. But I suspect when he and his peeps were doing this with a > slide rule or at best an Friden mechanical adding machine, they were > acutely aware of how errors accumulated or not. When they started to > convert their processes/techniques to Fortran in the early 1960s, I agree > with you that I think they were conscious of what they were doing. I'm > not sure modern CS types are taught the same things as what might be taught > in a course being run by a pure scientist who cares in the same way folks > like our mothers and fathers did in the 1950s and 60s. > Most cs types barely know that 2.234 might not be an exact number when converted to binary... A few, however can do sophisticated analysis on the average ULP for complex functions over the expected range.. Warner _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Thu Feb 13 08:45:54 2020 From: sauer at technologists.com (Charles H Sauer) Date: Wed, 12 Feb 2020 16:45:54 -0600 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> On 2/12/2020 4:11 PM, Warner Losh wrote: > > > On Wed, Feb 12, 2020, 11:13 AM Clem Cole > wrote: > > > > On Tue, Feb 11, 2020 at 10:01 PM Larry McVoy > wrote: > > What little Fortran background I have suggests that the difference > might be mind set.  Fortran programmers are formally trained (at > least I > was, there was a whole semester devoted to this) in accumulated > errors. > You did a deep dive into how to code stuff so that the error was > reduced > each time instead of increased.  It has a lot to do with how > floating > point works, it's not exact like integers are. > > Just a thought, but it might also be the training.   My Dad (a > mathematician and 'computer') passed a few years ago, I'd love to > have asked him.   But I suspect when he and his peeps were doing > this with a slide rule or at best an Friden mechanical adding > machine, they were acutely aware of how errors accumulated or not. > When they started to convert their processes/techniques to Fortran > in the early 1960s, I agree with you that I think they were > conscious of what they were doing.   I'm not sure modern CS types > are taught the same things as what might be taught in a course being > run by a pure scientist who cares in the same way folks like our > mothers and fathers did in the 1950s and 60s. > > > Most cs types barely know that 2.234 might not be an exact number when > converted to binary... A few, however can do sophisticated analysis on > the average ULP for complex functions over the expected range.. If that is true of some today, that is sad and disappointing. I think I was taught otherwise in my beginning C.S. course at UT-Austin in 1971. If I recall correctly: - all doctoral candidates ended up taking two semesters of numerical analysis. I still have two volume n.a. text in the attic (orange, but not "burnt orange", IIRC). - numerical analysis was covered on the doctoral qualifying exam. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From lm at mcvoy.com Thu Feb 13 09:05:42 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Feb 2020 15:05:42 -0800 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> References: <20200212030152.GJ852@mcvoy.com> <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> Message-ID: <20200212230542.GR852@mcvoy.com> On Wed, Feb 12, 2020 at 04:45:54PM -0600, Charles H Sauer wrote: > If I recall correctly: > - all doctoral candidates ended up taking two semesters of numerical > analysis. I still have two volume n.a. text in the attic (orange, but not > "burnt orange", IIRC). > - numerical analysis was covered on the doctoral qualifying exam. Pretty sure Madison required that stuff for Masters degrees. Or maybe undergrad, I feel like I took that stuff pretty early on. I'm very systems oriented so I can't imagine I would have taking that willingly. I hate the whole idea of floating point, just seems so error prone. From bakul at bitblocks.com Thu Feb 13 09:54:32 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 12 Feb 2020 15:54:32 -0800 Subject: [COFF] floating point (Re: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200212230542.GR852@mcvoy.com> References: <20200212030152.GJ852@mcvoy.com> <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> <20200212230542.GR852@mcvoy.com> Message-ID: <96B92BC1-F4AF-448E-8453-E77C27E7B545@bitblocks.com> On Feb 12, 2020, at 3:05 PM, Larry McVoy wrote: > > On Wed, Feb 12, 2020 at 04:45:54PM -0600, Charles H Sauer wrote: >> If I recall correctly: >> - all doctoral candidates ended up taking two semesters of numerical >> analysis. I still have two volume n.a. text in the attic (orange, but not >> "burnt orange", IIRC). >> - numerical analysis was covered on the doctoral qualifying exam. > > Pretty sure Madison required that stuff for Masters degrees. Or maybe > undergrad, I feel like I took that stuff pretty early on. > > I'm very systems oriented so I can't imagine I would have taking that > willingly. I hate the whole idea of floating point, just seems so > error prone. David Goldberg's article "What every computer scientist should know about floating-point arithmetic" is a good one to read: https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf I still have Bill Press's Numerical Recipes book though not opened recently (as in not since '80s)! It is interesting that older languages such as Lisp & APL have a builtin concept of tolerance. Here 0.3 < 0.1 + 0.2 is false. But in most modern languages it is true! This is so since 0.1 + 0.2 is 0.30000000000000004. In Fortran you'd write something like abs(0.3 - (0.1 + 0.2)) > tolerance. You can do the same in C etc.but for some reason it seems to be uncommon :-) From bakul at bitblocks.com Thu Feb 13 09:56:20 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 12 Feb 2020 15:56:20 -0800 Subject: [COFF] floating point (Re: Old and Tradition was [TUHS] V9 shell In-Reply-To: <96B92BC1-F4AF-448E-8453-E77C27E7B545@bitblocks.com> References: <20200212030152.GJ852@mcvoy.com> <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> <20200212230542.GR852@mcvoy.com> <96B92BC1-F4AF-448E-8453-E77C27E7B545@bitblocks.com> Message-ID: > On Feb 12, 2020, at 3:54 PM, Bakul Shah wrote: > > On Feb 12, 2020, at 3:05 PM, Larry McVoy wrote: >> >> On Wed, Feb 12, 2020 at 04:45:54PM -0600, Charles H Sauer wrote: >>> If I recall correctly: >>> - all doctoral candidates ended up taking two semesters of numerical >>> analysis. I still have two volume n.a. text in the attic (orange, but not >>> "burnt orange", IIRC). >>> - numerical analysis was covered on the doctoral qualifying exam. >> >> Pretty sure Madison required that stuff for Masters degrees. Or maybe >> undergrad, I feel like I took that stuff pretty early on. >> >> I'm very systems oriented so I can't imagine I would have taking that >> willingly. I hate the whole idea of floating point, just seems so >> error prone. > > David Goldberg's article "What every computer scientist should know > about floating-point arithmetic" is a good one to read: > https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf > > I still have Bill Press's Numerical Recipes book though not opened > recently (as in not since '80s)! > > It is interesting that older languages such as Lisp & APL have a > builtin concept of tolerance. Here 0.3 < 0.1 + 0.2 is false. But > in most modern languages it is true! This is so since 0.1 + 0.2 is > 0.30000000000000004. In Fortran you'd write something like > abs(0.3 - (0.1 + 0.2)) > tolerance. You can do the same in C > etc.but for some reason it seems to be uncommon :-) Er... not right. Fl. pt. arithmetic is hard! From toby at telegraphics.com.au Thu Feb 13 11:21:50 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 12 Feb 2020 20:21:50 -0500 Subject: [COFF] floating point (Re: Old and Tradition was [TUHS] V9 shell In-Reply-To: <96B92BC1-F4AF-448E-8453-E77C27E7B545@bitblocks.com> References: <20200212030152.GJ852@mcvoy.com> <9f1f6e0a-13ee-0846-e290-ec9871a3f542@technologists.com> <20200212230542.GR852@mcvoy.com> <96B92BC1-F4AF-448E-8453-E77C27E7B545@bitblocks.com> Message-ID: <7b51c60d-6506-19aa-977a-97d2528f2554@telegraphics.com.au> On 2020-02-12 6:54 PM, Bakul Shah wrote: > On Feb 12, 2020, at 3:05 PM, Larry McVoy wrote: >> >> On Wed, Feb 12, 2020 at 04:45:54PM -0600, Charles H Sauer wrote: >>> If I recall correctly: >>> - all doctoral candidates ended up taking two semesters of numerical >>> analysis. I still have two volume n.a. text in the attic (orange, but not >>> "burnt orange", IIRC). >>> - numerical analysis was covered on the doctoral qualifying exam. >> >> Pretty sure Madison required that stuff for Masters degrees. Or maybe >> undergrad, I feel like I took that stuff pretty early on. >> >> I'm very systems oriented so I can't imagine I would have taking that >> willingly. I hate the whole idea of floating point, just seems so >> error prone. > > David Goldberg's article "What every computer scientist should know > about floating-point arithmetic" is a good one to read: > https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf > > I still have Bill Press's Numerical Recipes book though not opened > recently (as in not since '80s)! > > It is interesting that older languages such as Lisp & APL have a > builtin concept of tolerance. Here 0.3 < 0.1 + 0.2 is false. But Mathematica also does significance tracking. It is probably the single most egregious omission from IEEE FP and unfortunately not corrected in the new standard. Check Steve Richfield's old posts on Usenet for more. --Toby > in most modern languages it is true! This is so since 0.1 + 0.2 is > 0.30000000000000004. In Fortran you'd write something like > abs(0.3 - (0.1 + 0.2)) > tolerance. You can do the same in C > etc.but for some reason it seems to be uncommon :-) > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > From peter at rulingia.com Thu Feb 13 16:57:20 2020 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 13 Feb 2020 17:57:20 +1100 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: <20200213065720.GA79914@server.rulingia.com> On 2020-Feb-12 15:11:27 -0700, Warner Losh wrote: >Most cs types barely know that 2.234 might not be an exact number when >converted to binary... My favourite example (based on a real bug that I was involved in investigating) is: int(0.29 * 100) = 28 (using IEEE doubles). That result is very counter-intuitive. (Detailed explanation available on request). In some ways IEEE-754 has made things worse - before that standard, almost every computer system implemented something different. Floating point was well known to be "here be dragons" territory and people who ventured there were either foolhardy or had enough numerical analysis training to be able to understand (and cope with) what the computer was doing. IEEE-754 offered a seeming nirvana - where the same inputs would result in the same outputs (down to the bit) irrespective of what computer you ran your code on. The underlying problems were still present but, at least in simple cases, were masked. Why employ an experienced numerical analyst to develop the code when a high-school student can translate the mathematical equations into running code in the language-du-jour? (And some languages, like Java, make a virtue out of hiding all the information needed to properly handle exceptional conditions). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From clemc at ccc.com Fri Feb 14 04:37:26 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Feb 2020 13:37:26 -0500 Subject: [COFF] [Simh] Of DEC and cards In-Reply-To: References: <6167693c-1608-47c2-b7cf-790dd0f6da49@snobol4.com> <20200213102754.0000119d@sky-visions.com> Message-ID: One last reply here, but CCing COFF where this thread really belongs... On Thu, Feb 13, 2020 at 12:34 PM Timothe Litt wrote: > OTOH, and probably more consistent with your experience, card equipment was > > almost unheard of when the DEC HW ran Unix... > You're probably right about that Tim, but DEC world was mostly TOPS/TENEX/ITS and UNIX. But you would think that since a huge usage of UNIX systems were as RJE for IBM gear at AT&T. In fact, that was one of the 'justifications' if PWB. I'm thinking of the machine rooms I saw in MH, WH and IH, much less DEC, Tektronix or my university time. It's funny, I do remember a lot of work to emulate card images and arguments between the proper character set conversions, but I just don't remember seeing actual card readers or punches on the PDP-11s, only on the IBM, Univac and CDC systems. As other people have pointed out, I'm sure they must have been around, but my world did not have them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 14 05:57:15 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 13 Feb 2020 14:57:15 -0500 (EST) Subject: [COFF] [Simh] Of DEC and cards Message-ID: <20200213195715.8D05F18C0AA@mercury.lcs.mit.edu> > From: Clem Cole > I just don't remember seeing actual card readers or punches on the > PDP-11s I'm not sure DEC _had_ a card punch for the PDP11's. Readers, yes, the CR11: https://gunkies.org/wiki/CR11_Card_Readers but I don't think they had a punch (although there was one for the PDP-10 family, the CP10). I think the CR11 must have been _relatively_ common, based on how many readers and CR11 controller cards survive. Maybe not in computer science installations, though... :-) Noel From litt at ieee.org Fri Feb 14 06:33:46 2020 From: litt at ieee.org (Timothe Litt) Date: Thu, 13 Feb 2020 15:33:46 -0500 Subject: [COFF] [Simh] Of DEC and cards In-Reply-To: References: <6167693c-1608-47c2-b7cf-790dd0f6da49@snobol4.com> <20200213102754.0000119d@sky-visions.com> Message-ID: <3da7cae0-879c-d171-fe8d-465ef4baa484@ieee.org> In the TOPS-10 world, ANF-10 RJE stations could have card readers and printers.  The TOPS-10/20 DN200 also. But most "RJE" station software on the DEC side made the foreign mainframe look like a batch queue, and you would submit a file to that queue.  The software (typically DEC 2780/3780 emulation for {TOPS-10,TOPS-20, VMS, ...}) would send the file to the mainframe from an imaginary card reader; results similarly to an imaginary printer (ending up in a .log or other file).  I suppose "virtual" would be the modern word for "imaginary", but it comes to the same thing :-) On the KL based systems, the software was a combination of PDP-11 front end code (a dedicated DN20) and code running on the KL.  The KS used a KDP, though there was also a "DN22" remote station. I don't know exactly what UNIX did - wasn't in that world much then.  But I wouldn't be surprised if the strategy was similar - user prepares a file, software does the code conversions to/from EBCDIC, and the usual lies told (er, device emulation performed) in both directions...  That would certainly have led to the emulation work you recall - especially given the fluid definitions of character sets at the time.  I don't recall the same efforts to offload development to UNIX as to the DEC proprietary systems - IIRC, compilers for legacy languages (COBOL, RPG, PL/I) came to UNIX rather later, and with less rich/performant implementations.  In my experience, physical card equipment, as previously noted, was either a legacy/migration requirement, or simply a bureaucratic legacy "requirement".  The DEC value proposition was that cards were expensive, awkward, slow, and painful to create, modify/debug with.  Interactive TS solved those problems; the emulations were a medium of exchange between the legacy/enterprise systems and the more productive DEC systems.  Readers: quite common.  Punches, much less so. On 13-Feb-20 13:37, Clem Cole wrote: > One last reply here, but CCing COFF where this thread really belongs... > > On Thu, Feb 13, 2020 at 12:34 PM Timothe Litt > wrote: > > OTOH, and probably more consistent with your experience, card > equipment was > > almost unheard of when the DEC HW ran Unix... > > You're probably right about that Tim, but DEC world was mostly > TOPS/TENEX/ITS and UNIX.  But you would think that since a huge usage > of UNIX systems were as RJE for IBM gear at AT&T.  In fact, that was > one of the 'justifications' if PWB.  I'm thinking of the machine rooms > I saw in MH, WH and IH, much less DEC, Tektronix or my > universitytime.  It's funny, I do remember a lot of work to emulate > card images and arguments between the proper character set > conversions, but  I just don't remember seeing actual card readers or > punches on the PDP-11s, only on the IBM, Univac and CDC systems.  > > As other people have pointed out, I'm sure they must have been around, > but my world did not have them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From litt at ieee.org Fri Feb 14 06:09:44 2020 From: litt at ieee.org (Timothe Litt) Date: Thu, 13 Feb 2020 15:09:44 -0500 Subject: [COFF] [Simh] Of DEC and cards In-Reply-To: <20200213195715.8D05F18C0AA@mercury.lcs.mit.edu> References: <20200213195715.8D05F18C0AA@mercury.lcs.mit.edu> Message-ID: On 13-Feb-20 14:57, Noel Chiappa wrote: > > From: Clem Cole > > > I just don't remember seeing actual card readers or punches on the > > PDP-11s > > I'm not sure DEC _had_ a card punch for the PDP11's. Readers, yes, the CR11: > > https://gunkies.org/wiki/CR11_Card_Readers > > but I don't think they had a punch (although there was one for the PDP-10 > family, the CP10). > > I think the CR11 must have been _relatively_ common, based on how many > readers and CR11 controller cards survive. Maybe not in computer science > installations, though... :-) > > Noel Not common, but yes: CP11-UP Punch interface for Univac 1710 Card RDR/PUNCH Before anyone asks, there were also: CP08-(N,P) (CSS) Data Products Speedpuch 120 100 CPM Punch and controller CP10-(A,B) MD6011 300 CPM CARD PUNCH & Controller (60,50 Hz) CP15-(A,B) Ditto for the -15 and CP20-E (The CP10 for orange boxes) There were a few other part numbers, especially for the 10/20, which included various mechanical options - e.g. racks for the controllers vs. just the controller, colors, etc.  What's listed are the main models for each family. The CP01-(A,B) "Documation LC15 Model 2 Card Puhcn, 80 Col, 100CPM, RS322 interfaces, ASCII or Imaged mode 100-9600 BAUD Not sure what platforms used the CP01... -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Feb 14 09:41:21 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 14 Feb 2020 10:41:21 +1100 Subject: [COFF] jitsi on FreeBSD (was: Also, a video service) In-Reply-To: References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> <20200209232139.B85D0156E40E@mail.bitblocks.com> Message-ID: <20200213234121.GC64389@eureka.lemis.com> On Monday, 10 February 2020 at 16:35:44 +1300, Wesley Parish wrote: > Thanks, Bakul. I'm just now installing jitsi on one of my Linux boxen. > > Speaking of FreeBSD and MacOS, I'm sure the source code at > https://download.jitsi.org/jitsi/src/ will compile on FreeBSD with a > simple ./configure and make. Thanks for that. I was wondering where the sources had gone. I've now updated the port net-im/jitsi, so you should be able to build directly from there, or install the package once it has been built (a few days, I think). 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 Fri Feb 14 09:43:58 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 14 Feb 2020 10:43:58 +1100 Subject: [COFF] Video service on FreeBSD (was: Also, a video service) In-Reply-To: References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> Message-ID: <20200213234358.GD64389@eureka.lemis.com> On Sunday, 9 February 2020 at 22:09:47 -0800, jason-tuhs at shalott.net wrote: > >>> All, I've also set this up to try out for the video chats: >>> https://meet.tuhs.org/COFF >>> Password to join is "unix" at the moment. > >> Just tried it out. On FreeBSD I get a blank grey screen. I could >> only get something more on a Microsoft box, not quite what I'd want to >> do. Is there some trick? > > * Install /usr/ports/net-im/jitsi. (Comment out the BROKEN line from the > Makefile and "make install" should work as usual; the source can actually > be fetched just fine...) In fact, the package was indeed unfetchable, but the ports collection had a cached version, which is what you got. But now I've brought it up to date (only 2 years old rather than 4). > * kldload cuse > > * Run firefox and surf to that URL. I haven't found that necessary. In fact, installing jitsi doesn't seem to be necessary. All you need is a more recent browser than the antiques I was running. 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 brad at anduin.eldar.org Fri Feb 14 10:08:33 2020 From: brad at anduin.eldar.org (Brad Spencer) Date: Thu, 13 Feb 2020 19:08:33 -0500 Subject: [COFF] [Simh] Of DEC and cards In-Reply-To: <20200213195715.8D05F18C0AA@mercury.lcs.mit.edu> (jnc@mercury.lcs.mit.edu) Message-ID: jnc at mercury.lcs.mit.edu (Noel Chiappa) writes: > > From: Clem Cole > > > I just don't remember seeing actual card readers or punches on the > > PDP-11s > > I'm not sure DEC _had_ a card punch for the PDP11's. Readers, yes, the CR11: > > https://gunkies.org/wiki/CR11_Card_Readers > > but I don't think they had a punch (although there was one for the PDP-10 > family, the CP10). > > I think the CR11 must have been _relatively_ common, based on how many > readers and CR11 controller cards survive. Maybe not in computer science > installations, though... :-) > > Noel > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff So... in the early 1990s I was at a particular small university in Ohio that had one of the last PDP11/70 running, I believe, RSTS/E in the state of Ohio (or at least that is what the rumors were and what the hardware support guy said once). While I honestly don't remember what it was used for that PDP11 had a card reader for sure, and something or other had to be doing the punching (I think I remember watching cards get run though it once or twice). I very much suspect that it was the PDP11 doing the punching, as nothing else at the university could have done it, unless someone was punching them by hand. Along with the PDP11 the computer room had a Data General MV10000 and a DG MV4000 neither of which dealt with cards. The PDP11/70 was used for the university administration systems and activities. I could probably find out how it was used (assuming my memory is not faulty) if anyone was really interested. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From dave at horsfall.org Sat Feb 15 15:10:53 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 15 Feb 2020 16:10:53 +1100 (EST) Subject: [COFF] [Simh] Of DEC and cards In-Reply-To: References: <6167693c-1608-47c2-b7cf-790dd0f6da49@snobol4.com> <20200213102754.0000119d@sky-visions.com> Message-ID: On Thu, 13 Feb 2020, Clem Cole wrote: > [...] but  I just don't remember seeing actual card readers or punches > on the PDP-11s, only on the IBM, Univac and CDC systems.  We had a small CDC card reader on our 11/40 for some reason; I wrote the driver, and it ran in two modes: straight binary i.e. all holes returned "as is", or NL-terminated ASCII. I think the source of the cards was a Cyber 72, but can't be sure. -- Dave From wobblygong at gmail.com Mon Feb 17 07:47:36 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 17 Feb 2020 10:47:36 +1300 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: I think it's implicit with fooling around with slide rules. Everything is logarithmic, therefore imprecise beyond a certain level (floating point number or iteration, it's the same problem). You learn to approximate, within a certain level of confidence (or diffidence :). (FWVLIW - I bought a Dover book on slide rule in the late 70s while at high school, and shortly after, a real slide rule, and it's stuck with me.) Wesley Parish On 2/13/20, Clem Cole wrote: > On Tue, Feb 11, 2020 at 10:01 PM Larry McVoy wrote: > >> What little Fortran background I have suggests that the difference >> might be mind set. Fortran programmers are formally trained (at least I >> was, there was a whole semester devoted to this) in accumulated errors. >> You did a deep dive into how to code stuff so that the error was reduced >> each time instead of increased. It has a lot to do with how floating >> point works, it's not exact like integers are. > > Just a thought, but it might also be the training. My Dad (a > mathematician and 'computer') passed a few years ago, I'd love to have > asked him. But I suspect when he and his peeps were doing this with a > slide rule or at best an Friden mechanical adding machine, they were > acutely aware of how errors accumulated or not. When they started to > convert their processes/techniques to Fortran in the early 1960s, I agree > with you that I think they were conscious of what they were doing. I'm > not sure modern CS types are taught the same things as what might be taught > in a course being run by a pure scientist who cares in the same way folks > like our mothers and fathers did in the 1950s and 60s. > From clemc at ccc.com Mon Feb 17 08:10:03 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 16 Feb 2020 17:10:03 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: On Sun, Feb 16, 2020 at 4:47 PM Wesley Parish wrote: > FWVLIW - I bought a Dover book on slide rule in the late 70s while at > high school, and shortly after, a real slide rule, and it's stuck with > me. > My dad taught me with a plastic slide rule he put in our stocking in the early/mid 1960s. This was how I (and many others) learn about interpolation. I also learned to make log/log paper with it. A few years later, my grandfather died when I was in engineering school. My grandmother sent me his slide rule to remember him by (which I still have). Although she did not know that at the time, I already owned the then hot item, a TI SR50 scientific calculator - which I paid the $150 in 1972 dollars (about $900 in today's money). I also got his drafting table, but I no longer have that. The slide rule is made of ivory on top of metal (I think bronze but I never had it checked). It was probably made in the 1920s. It stays in a box in desk ;-) A slightly, sad part is I don't think either of my kids knows how to use it, and while both have degrees in science, I don't think either wants it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Mon Feb 17 08:45:58 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 16 Feb 2020 17:45:58 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> Message-ID: On 2/16/2020 5:10 PM, Clem Cole wrote: > This was how I (and many others) learn about interpolation I learned about interpolation in either middle school or high school math. And used it many times in video games I had my hands in. I was a year or two ahead (depending on which year) in math. Create an array (or a cache at startup) with all the logs I needed, and then interpolate on the fly. And do the reverse for the alog(). Quite handy. As for slide-rules, I remember my father had one, and used it regularly. I never even looked at it. He died when I was 16. A few years later, I took it out of it's case, looked at it, and thought "ah! logs". I had never known what a slide-rule was. And I was born in 1965 ;) They certainly didn't teach us about slide rules in school. ak PS: Take the log of a number, divide by two, take the alog() and get the sqrt(). Divide by 3, cube root, etc. I was impressed, to say the least. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Mon Feb 17 09:50:50 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 16 Feb 2020 15:50:50 -0800 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: Your message of "Sun, 16 Feb 2020 17:10:03 -0500." References: <20200212030152.GJ852@mcvoy.com> Message-ID: <20200216235057.B905D156E411@mail.bitblocks.com> On Sun, 16 Feb 2020 17:10:03 -0500 Clem Cole wrote: > > On Sun, Feb 16, 2020 at 4:47 PM Wesley Parish wrote: > > > FWVLIW - I bought a Dover book on slide rule in the late 70s while at > > high school, and shortly after, a real slide rule, and it's stuck with > > me. > > > My dad taught me with a plastic slide rule he put in our stocking in the > early/mid 1960s. This was how I (and many others) learn about > interpolation. I also learned to make log/log paper with it. A few years > later, my grandfather died when I was in engineering school. My grandmother > sent me his slide rule to remember him by (which I still have). Although > she did not know that at the time, I already owned the then hot item, a TI > SR50 scientific calculator - which I paid the $150 in 1972 dollars (about > $900 in today's money). I also got his drafting table, but I no longer > have that. The slide rule is made of ivory on top of metal (I think > bronze but I never had it checked). It was probably made in the 1920s. It > stays in a box in desk ;-) What brand was your grandfather's sliderule? I had a yellow Pickett sliderule in my undergrad days. IIRC it had some sort of aluminum alloy slide and didn't work as smoothly as an Aristo or a Faber-Castell. A friend had TI scinetific calculator with RED LED digits -- may have been the SR50. Aesthetically it didn't hold a candle to the beautfiul sliderules! Some sliderule simulators here: https://www.sliderules.org/ (mine looked exactly like the N600) Online Museum here: https://sliderulemuseum.com/SRM_Home.htm > A slightly, sad part is I don't think either of my kids knows how to use > it, and while both have degrees in science, I don't think either wants it. So it goes! From dave at horsfall.org Tue Feb 18 10:17:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 18 Feb 2020 11:17:27 +1100 (EST) Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200216235057.B905D156E411@mail.bitblocks.com> References: <20200212030152.GJ852@mcvoy.com> <20200216235057.B905D156E411@mail.bitblocks.com> Message-ID: On Sun, 16 Feb 2020, Bakul Shah wrote: > What brand was your grandfather's sliderule? Mine was an Arista, and had it right through school; have no idea where it is now. I also had a circular slide rule, which was fascinating. Trivia: slide rules were banned for exams (and no calculators in those days), but log tables were OK; come some important exam, some idiot of a teacher forgot to specify that log tables were allowed so they were forbidden. I merely worked the problems through right down to the long division, and left them there with a note saying that we were supposed to use log tables; I passed... -- Dave From jpl.jpl at gmail.com Tue Feb 18 22:48:53 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 18 Feb 2020 07:48:53 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> <20200216235057.B905D156E411@mail.bitblocks.com> Message-ID: My uncle had a cylindrical sliderule. It had about a dozen "rules" that rotated around the central cylinder, with different gratings on the opposite side of each rule. And the central cylinder had at least a dozen, probably 20 or more, gratings. That yielded hundreds of combinations. I wish he had bequeathed it to me. I have no idea what became of it. On Mon, Feb 17, 2020 at 7:18 PM Dave Horsfall wrote: > On Sun, 16 Feb 2020, Bakul Shah wrote: > > > What brand was your grandfather's sliderule? > > Mine was an Arista, and had it right through school; have no idea where it > is now. I also had a circular slide rule, which was fascinating. > > Trivia: slide rules were banned for exams (and no calculators in those > days), but log tables were OK; come some important exam, some idiot of a > teacher forgot to specify that log tables were allowed so they were > forbidden. I merely worked the problems through right down to the long > division, and left them there with a note saying that we were supposed to > use log tables; I passed... > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 07:17:51 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 16:17:51 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not Message-ID: Moving to COFF where this belongs… Here is my basic issue. I'm not 'blind' as Larry says. I lived it and I try to awknowledge who did what and why if I can. I try to remember we got here by a path and that path was hardly straight, but you don't get to join the convoy late and they say -- hey the journey began someplace else. @FLAME(on) Open/Free/Available/Access – whatever you want to call it, did not just pop up in the late 1980’ with the Free Software Foundation or in the 90s with the Linux Foundation *et al*. The facts are that in the early years, a computer customer got everything including schematics from the cpu manufacturer. The ‘culture’ described in Levi’s circa 1980 book “Hackers” that took off at MIT, Stanford, CMU, *et al.* because everything *was available* and people *shared things because it saved us all time and trouble*. In fact, the name of the IBM user group was just that, SHARE. IBM published patched to the OS or their compilers, in the source as 'PTFs' - program temporary fix'. Each site might have modified things a little (or a lot), so got the PTF and tape and looked at how the patch affected you. That was my first job support York APL/360 on TSS. (CMU had TSS working before IBM did, so a lot of PTFs from IBM would be things we already had dealt). Certainly, when I started programming in the late 1960s, the idea of proprietary SW had been around, but it was still somewhat constrained to the commercial side (Banking/Insurance *etc*… parts – where the real money was). The research and university community (which of course DEC was heavily part) was very much, we are all in together. Still everyone had sources and we moved things back and forth via mag tape at DECUS conferences or eventually the ARPAnet. At some point that started to change. Doug, Ken and others older than I can probably tell you more than I can about that transition. But the vendors started to lock up more and more of their IP. A user no longer got a mag tape with the sources and you did not do a full system generation. The end users/customers only got parts of the system, the rest was binaries. Unless you paid huge fees, the source at best was available on microfiche, and often you lacked important things needed to recreate the binaries. Thus the concept of the closed or proprietary systems started to become the norm, not as it has been previously. I remember, since CMU had VAX Serial #1, and a 'special' relationship with DEC, we have VMS sources. One spring/summer we were doing a consulting job (moving ISPS to the Vax for the Israel Government), and that was were I realized they only had the code on fiche, and CMU was 'different.' But here is the interesting thing, as the vendors started becoming less and less 'open', *AT&T was required by the 1956 consent decree to be 'open' and license its IP *for ‘fair and reasonable terms’ to all interested parties. (Which, they did, and the world got the transistor and UNIX as two of the best examples). So AT&T UNIX behavior is the opposite of what the hardware manufacturers were doing at the time!!! The argument comes back to a few basic issues. What is ‘fair and reasonable’ and ‘who gets to decide’ what is made available. As the creators of some content, started to close access to ‘secret sauce’ a tension can and did start to build between the creators and some users. BTW, the other important thing to remember is that you needed a $100K-$250K hunk of HW from DEC to use that ‘open’ IP from AT&T and *the hardware acquisition was the barrier to entry*, not the cost the SW. Folks, those of us that lived it. UNIX was 100% open. Anyone could get a license for it. The technologies that AT&T developed was also published in the open literature detailing how it was made/how it worked. They did this originally because they were bound by the US Gov due to a case that started in 1949 and settled witht that 1956 decree! The folks at AT&T were extremely free to talk about and they did give away what they had. The ‘sauce’ was never secret (and thus AT&T would famously lose its case when they later tried to put the cat back in the bag in AT&T *vs*. UCB/BSDi case) . The key is that during the PDP-11 and Vaxen times, the UNIX community all had licenses, commercial or university. But soon the microprocessor appears, we start to form new firms and with those sources, we created a new industry, the *Open Systems Industry* with an organization called /usr/group. This is all in the early 1980s (before FSF, much less Linux). What was different here, was *we** could all share* between other licensees (and anyone could get a license if they >>wanted<< it). But something interesting happens. These new commercial Open Systems folk won the war with the proprietary vendors. They were still competing with the old guard and they competed against each other (surprise/surprise – some were the same folks who had been competing against each other previously, now they just was using somewhat standard ammunition – UNIX and a cheap processor). Moreover, the new people with the UNIX technology (Sun, DEC, HP, Masscomp, IBM *et al*) start to handle their own version of UNIX just like they handled their previous codes. They want to protect it. And this is where the famous fair and reasonable comes in. Who gets to set what is fair? Certainly, $150 fee to recover the cost of writing the magtape (the IP was really free) seemed fair at the time – particularly since you had to ‘cons up’ another $150K for that PDP-11. Stallman, in particular, wants to go back to old days, where he got access toeverything and he had his playground. To add insult to all, he currently fighting the same war with some of MIT's ideas and the LISP machine world. So his answer was to try to rewrite everything from scratch and then try to give it away/get people to use it but add a funny clause that said you have to give to anyone else that asked for it. He still has a license, he just has different rules (I’ll not open if this is fair or reasonable – but it was the rules FSF made). BTW: that only works if you have something valuable (more in a minute). Moore’s law starts driving the cost of the hardware down and at some point, the computer to run UNIX costs $50K, then $10K, $5K, and even $1K. So now the fees that AT&T is charging the commercial side can be argued (as Larry and other have so well) are no longer ‘reasonable.’ At some point, FSF’s movement (IMO – after they got a compiler that was ‘good enough’ and that worked on ‘enough’ target ISA’s) starts to take off. I think this is the real 'Christensen Disruption'. GCC was not as good as Masscomp or Sun's compilers for the 68k or DEC's for the Vax, but it was free. As I recall, Sun was charging for its compiler at the time (we did manage to beat back the ex-DEC marketing types at Masscomp and the C compiler was free, Fortran and Pascal cost $s). Even though gcc is not as good, its good enough and people love it, so it builds a new market (and gets better and better as more people invest in it -- see Christensen's theory for why). But this at least 5 years *after* the Open Systems Community has been birthed. Sorry guys -- the term has been in use for a while to mean the >>UNIX<< community with its open interfaces and sharing of code. BTW: Linux itself would happen for another 5 years after that and couple of more years before the Linux Foundation, much less the community that has grown around it. But that’s my point… Please at least here in the historic mailing lists, start to admit and be proud that we are standing on people's shoulders and >>stop<< trying to stepping on people’s toes. The current FOSS movement is just that – Free and Open. That’s cool – that’s great. But recognize it started long before FSF or Linux or any of that. For a different time, the person I think who should really be credited as the start of the FOSS movement as we know it, is the late Prof. Don Pederson. In the late 1960s, he famously gave away his first ECAD program from UCB (which I believe was called MOTIS – and would later begat SPICE). As ‘dop’ used to tell his students (like me) back in the day – ‘*I always give away my sources. Because that way I go in the back door and get to see everything* at IBM/HP/Tektronix/AT&T/DEC etc..*. If I license and sell *our code*, I *have to *go in the front door like any other salesman.’* For the record a few years later, my other alma mater (CMU) was notorious for licensing it's work -- hence the SCRIBE debacle of the late 1970s and much of the CMU SPICE project/Andrew results of the early 1980s - while MIT gave everything away in Athena and more everything from the NU projects. I notice that the things that lived the longest from CMU were things that were given away without any restrictions... but I digress. So... coming back to the UNIX side of the world. Pederson’s work would create UCB’s ‘industrial liaison office’ which was the group that released the original ‘Berkeley Software Distribution’ for UNIX (*a.k.a.* BSD). They had a 10 year history of ‘giving away’ free software before UNIX came along. They gave their UNIX code anyone that asked for it. You just had to prove you had a license from AT&T, but again anyone could get that. i.e. it was 'open source.' -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 07:51:05 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 16:51:05 -0500 Subject: [COFF] [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: moved to coff On Tue, Feb 18, 2020 at 4:29 PM Wesley Parish wrote: > I don't recall ever seeing "open source" used as a description of the > Unix "ecosystem" during the 90s. > Yes, that's my point. The term 'open' meant was published, open available anyone could use .. i.e. UNIX remember the SPEC 1170 work on the 1990s -- the define the 1170 interfaces and >>publish<< them so anyone could write code to it. > It was in the air with the (minimal) charges Prentice-Hall charged for > the Minix 0.x and 1.x disks and source; not dissimilar in that sense > to the charges the FSF were charging for their tapes at the time. > Right... there were fees to write magtapes (or floppies) Which comes back to my point... 'open source' was not picking. The whole community is standing on the shoulders of the UNIX ecosystem that really started to take off in the 1970s and 1980s. But the 'free' part was even before UNIX. We stood on the shoulders of things before us. There just was not (yet) a name for what we were doing. As Ted saids, I'll give the Debian folks credit for naming it, but the idea really, really goes back to the early manufacturers and the early community. FSF was a reaction to the manufacturers taking away something that some people thought was their 'birth right.' -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Feb 19 08:58:24 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 18 Feb 2020 17:58:24 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: Message-ID: <20200218225824.GB152025@mit.edu> It seems that you are primarily arguing that the idea of "Open Systems" predates that of the Free Software and Open Source movements. That's no doubt true, chronologically speaking. However, for those of us who came up a bit after you, from our perspective, the "Open Systems" movement *failed*. Source code for Solaris, Ultrix, AIX, was very hard to get, and when we could get it, we were not able to make changes and share them with others. I've told the story before about how MIT managed to obtain a Unix license without the infamous "methods and concepts" clause. It was able to continue to renew it because, quite frankly, AT&T needed access to MIT researchers more than the other way around, so it was a matter of sheer power politics. But AT&T refused to *acknowledge* that MIT had a Unix license to Digital, so the only way MIT Project Athena got access to Ultrix and OSF/1 sources was through back channels where MIT alumni working at DEC passed unofficial source tapes complete with editor backup and coredumps. But officially, once AT&T refused to acknowledge that MIT had a valid Unix license (even though we did), MIT wasn't able to get *legal* source snapshots from Digital. So this is why I don't view the Open Systems movement with quite the same rose colored classes as others. It's also why I like the GPL license, because it forces people to give the code back. Essentially I have *zero* trust that corporate entities will do anything other than maximize shareholder value, and if that means taking BSD licensed code, and adding their own secret sauce, and not returning it back to the commons --- which is part what led to the mess which was Solaris, HPUX, AIX, etc., that's exactly what companies will do. Companies may have mission statements saying things like "don't be evil", but sooner or later, that phrase will quietly disappear and companies will start making more and more compromises in pursuit of the almighty dollar. So if it helps, consider thinking of the GPL license as a commitment device[1] for the philosophy of Open Systems. :-) [1] http://freakonomics.com/podcast/save-me-from-myself-a-new-freakonomics-radio-podcast/ - Ted From bakul at bitblocks.com Wed Feb 19 09:04:30 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 18 Feb 2020 15:04:30 -0800 Subject: [COFF] [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: <01DD0405-D65B-4557-AD0E-4A128334DE2E@bitblocks.com> On Feb 18, 2020, at 1:51 PM, Clem Cole wrote: > > As Ted saids, I'll give the Debian folks credit for naming it, but the idea really, really goes back to the early manufacturers and the early community. > > FSF was a reaction to the manufacturers taking away something that some people thought was their 'birth right.' Used to be that you would get schematics with your electrical or electronic appliance. I used these to repair a few things, some times by improvising. IIRC even the original IBM PC came with schematics. Given that experience, I felt that paid for software should come with sources so that when something goes wrong you can figure out what happened and may be find a way around it. I had no problem trying to "use the source" but first they had to provide it; the real documentation! If in the original vendor goes out of business or decides to stop supporting a product you bought, you're not stuck. Just as the original Tektronix oscilloscopes continue being useful. I do believe this should be a 'birth right'. If this was always provided, RMS might not have come up with the copyleft! This is a separate issue from giving away your own software with sources or controlling what others can do with the sources you gave away, or paying or being paid to produce such s/w. From clemc at ccc.com Wed Feb 19 11:18:52 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 20:18:52 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200218225824.GB152025@mit.edu> References: <20200218225824.GB152025@mit.edu> Message-ID: On Tue, Feb 18, 2020 at 5:58 PM Theodore Y. Ts'o wrote: > It seems that you are primarily arguing that the idea of "Open > Systems" predates that of the Free Software and Open Source movements. > That's no doubt true, chronologically speaking. However, for those of > us who came up a bit after you, from our perspective, the "Open > Systems" movement *failed*. If your measurement of success was getting access to sources, yes it failed. But if you measurement was making UNIX the standard for all computers in the future -- it was wildly successful. It's a bit of perception I suspect. We were tired of having to deal with VMS et al. That said, you were tired of the UNIX wars -- which is a reasonable view. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 11:40:52 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 20:40:52 -0500 Subject: [COFF] [TUHS] man Macro Package and pdfmark In-Reply-To: <01DD0405-D65B-4557-AD0E-4A128334DE2E@bitblocks.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> <01DD0405-D65B-4557-AD0E-4A128334DE2E@bitblocks.com> Message-ID: On Tue, Feb 18, 2020 at 6:04 PM Bakul Shah wrote: > Given that experience, I felt that paid for software should > come with sources so that when something goes wrong you can > figure out what happened and may be find a way around it. I > had no problem trying to "use the source" but first they had > to provide it; the real documentation! If in the original > vendor goes out of business or decides to stop supporting a > product you bought, you're not stuck. Just as the original > Tektronix oscilloscopes continue being useful. > Ah herein is an issue. Tektronix (when I worked for them) was suing the US Gov because they had taken the schematics of one of their scopes (the 465 IIRC), and had someone else make a clone (Keithley IIRC). Tek eventually won the case, because the new instance was a duplicate that you touch and feel. Software gets tricky. Franklin, of course, copied Apple's ROM and Arthur Kahn (lead lawyer for Franklin) that they had published the sources in their manuals and processor so designed to run it as it. They had not copied Apple's chip, they used different devices but they had used the same functions, entries etc. They had changed some things, but they had used the sources that Apple had published as the place to start. He almost won, because the SW did not have a physical instance. In the end, he was able to set the precedent for the idea of the 'clean room' BIOS of the PC. One group writing a specification, but the new code being implemented by a group of people that had no knowledge of the original - only the new specification. BTW: I understand where you are coming and I too miss those days. Hey, my own first learning in electronics was getting the schematics for a TV or a Radio and troubleshooting them. I also spent a number of hours, staring at Wozinacks Apple-II sources trying to understand what he did. The problem is that in the world were the replica is no different from the original, it makes IP protection extremely difficult. As I said, the issue end the end is who gets to say? The originator of the IP or the customer/user of it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 19 11:54:46 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 18 Feb 2020 17:54:46 -0800 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200218225824.GB152025@mit.edu> References: <20200218225824.GB152025@mit.edu> Message-ID: <20200219015446.GC30841@mcvoy.com> +1 to everything Ted said, that's the world I lived in. I have a love hate relationship to the GPL, I'm ok with GPLv2, not so much with v3. I just think that Clem has led a somewhat blessed life where people knew he was someone that should not have roadblocks, the roadblocks just limit how much goodness Clem is gonna give you. So he had source access without thinking about it, he had whatever he wanted, that was "normal" for him. For a lot of the rest of us, we were not seen as good as Clem so we had to deal with all the asinine roadblocks so we could give you some goodness. It wasn't easy. On Tue, Feb 18, 2020 at 05:58:24PM -0500, Theodore Y. Ts'o wrote: > It seems that you are primarily arguing that the idea of "Open > Systems" predates that of the Free Software and Open Source movements. > That's no doubt true, chronologically speaking. However, for those of > us who came up a bit after you, from our perspective, the "Open > Systems" movement *failed*. Source code for Solaris, Ultrix, AIX, was > very hard to get, and when we could get it, we were not able to make > changes and share them with others. > > I've told the story before about how MIT managed to obtain a Unix > license without the infamous "methods and concepts" clause. It was > able to continue to renew it because, quite frankly, AT&T needed > access to MIT researchers more than the other way around, so it was a > matter of sheer power politics. But AT&T refused to *acknowledge* > that MIT had a Unix license to Digital, so the only way MIT Project > Athena got access to Ultrix and OSF/1 sources was through back > channels where MIT alumni working at DEC passed unofficial source > tapes complete with editor backup and coredumps. But officially, once > AT&T refused to acknowledge that MIT had a valid Unix license (even > though we did), MIT wasn't able to get *legal* source snapshots from > Digital. > > So this is why I don't view the Open Systems movement with quite the > same rose colored classes as others. > > It's also why I like the GPL license, because it forces people to give > the code back. Essentially I have *zero* trust that corporate > entities will do anything other than maximize shareholder value, and > if that means taking BSD licensed code, and adding their own secret > sauce, and not returning it back to the commons --- which is part what > led to the mess which was Solaris, HPUX, AIX, etc., that's exactly > what companies will do. > > Companies may have mission statements saying things like "don't be > evil", but sooner or later, that phrase will quietly disappear and > companies will start making more and more compromises in pursuit of > the almighty dollar. So if it helps, consider thinking of the GPL > license as a commitment device[1] for the philosophy of Open Systems. :-) > > [1] http://freakonomics.com/podcast/save-me-from-myself-a-new-freakonomics-radio-podcast/ > > - Ted > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Wed Feb 19 12:27:47 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 21:27:47 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200219015446.GC30841@mcvoy.com> References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: I'm not 100% sure why I'm arguing other than I feel this is so wrong and so disingenuous to those that came before. But, you have to decide that having access to all your sources for your system is your measure of 'success.' My value of success is no more VMS, Kronos, or VM/CMS or the like. I will accept Larry's position that he had many roadblocks that were often silly. But I really don't think my world was as 'charmed' as he claims and his was quite as bad as his might think you look at it. That said, we have deviated from what it means to be "open." What I'm hearing from Ted and Larry that they think open can only mean stallman's definition. I have said, that is not, was not the original definition, nor is it the only case and that the UNIX technology itself was really not as tied up as he claims. I think Larry did have access to sources (maybe not at his University), but like so many of us, once he got to a place that had them (like SGI or Sun). My point is that besides being to read about it in books and papers, getting access to the source from AT&T or UCB was really the norm and stating otherwise is disingenuous and trying to rewrite history a bit. A point Ted has made and I accept is by the time of the UNIX Wars, the old proprietary folks were trying to keep their own versions of UNIX 'secret' and to use Larry terms those roadblocks to >>there<< code was real. But the truth is that the AT&T codebase (while getting more and more expensive as the HW dropped in cost), was always available, and people both commercial and research had it. The problem was that as hardware cost dropped, more and more people wanted the sources too and that were the I think the difference in the success metrics come. Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge success. It did what we wanted -- it displaced the proprietary systems. And in the end, the UNIX ideas and UNIX technologies live today - because they were open and available to everyone. It does not matter if it was GPL'ed or otherwise. In the end, what matters to me is the ideas, the real intellectual property NOT the source that implements it. This has been proven within the UNIX community too many times. It has been re-engineered so many times over. Just like Fortran lives today, although it's different from what I learned in the 1960s. It's still Fortran. Unix is different from what I saw in the early 1970s, but its still Unix. And that is because the *ideas that makeup what we call UNIX ARE open* and the people looked at the sources, looked at the papers, talked to each other and the community built on it. It looks like a duck. It quacks like a duck and even tastes like duck (mostly) when you inside. It's a duck. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 19 12:41:59 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 19 Feb 2020 13:41:59 +1100 (EST) Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200218225824.GB152025@mit.edu> References: <20200218225824.GB152025@mit.edu> Message-ID: On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote: > It's also why I like the GPL license, because it forces people to give > the code back. [...] Which is one reason why I don't like the GPL; it compels me to do something that for reasons of my own I may not wish to do (spread it like a virus). The other reason is that if I use any GPL code, my own work ends up under the GPL (like a virus) and again I may not like that. Here's the terms that I personally use; it's sort of a modified BSD licence: ----- +---------------------------------------+ |Simplified BSD Licence (patent pending)| +---------------------------------------+ Do what the hell you like with this stuff, but don't pretend that you wrote it or remove this notice, OK? Otherwise I *will* hunt you down and deal with you (and I have done that before). If you modify anything then have the guts to put your name to it so I know who to blame and can deflect complaints accordingly, or email me so I can incorporate your ideas (with due credit) in the next version of this fine suite of software; fame could be yours :-) Continued use of this software may or may not result in the agonising death of all small furry animals within a 100ft radius, so use at own risk; I cannot accept any responsibility for any animal-welfare group kicking down the door in the middle of the night and dragging you off to be vivisected with a rusty razor blade. Copyright (C) 2018, David Ian Horsfall DTM (VK2KFU) dave at horsfall.org Don't email me without first reading http:/www.horsfall.org/spam.html ----- -- Dave From lm at mcvoy.com Wed Feb 19 12:56:16 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 18 Feb 2020 18:56:16 -0800 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: <20200219025616.GE30841@mcvoy.com> On Tue, Feb 18, 2020 at 09:27:47PM -0500, Clem Cole wrote: > That said, we have deviated from what it means to be "open." What I'm > hearing from Ted and Larry that they think open can only mean stallman's > definition. No open means access to it in my mind. GPL is open, BSD is open, $$$ for roff and $5/machine is not at all open, that's a for pay thing. Your world was "shrug", my world was "we're not paying for that because we don't understand what it is". > My point is that besides being to read about it in > books and papers, getting access to the source from AT&T or UCB was really > the norm and stating otherwise is disingenuous and trying to rewrite > history a bit. Umm, couldn't disagree more. My experience was the source was locked up and you had to be "someone" to have access to it. It was like that at UW Madison, it was like that at Lachman, it was like that even at Sun for the non SunOS stuff. They eventually loosened up but you had to know where v7, 32v, etc were located and that was not public knowledge. For whatever reason, there was hesitation about giving you access to the AT&T Bell Labs source. BSD was what we ran at Madison and that was locked up. > A point Ted has made and I accept is by the time of the UNIX Wars, the old > proprietary folks were trying to keep their own versions of UNIX 'secret' > and to use Larry terms those roadblocks to >>there<< code was real. But > the truth is that the AT&T codebase (while getting more and more expensive > as the HW dropped in cost), was always available, and people both > commercial and research had it. Not at all true in my experience. > Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge > success. It did what we wanted -- it displaced the proprietary systems. > And in the end, the UNIX ideas and UNIX technologies live today - because > they were open and available to everyone. It does not matter if it was > GPL'ed or otherwise. I agree with that. > And that is because the *ideas that makeup what we call UNIX ARE open* and > the people looked at the sources, looked at the papers, talked to each > other and the community built on it. Ideas sort of, but the source was not was not at all open. You had access, I had to fight like hell to get access and I'm sort of somebody, people knew me. Think of all the people who were not as brash as I am and didn't get access. The default, this is what you don't get Clem, the default was no access for you. Ideas, sure, but there is nothing like the mind explosion that happened for me reading the popen() source. I had read all the Bell Labs papers and a bunch more but seeing that fork() in libc's popen() changed how I thought about things. I never would have gotten that from a paper, maybe I'm just dumb, but that was a mind twist. I think there are lot more in the source, swtch() is a good one. Interrupts are a good one. Page faults are a good one. There is a lot that you can talk about but it doesn't come into focus until you walk the call stack and think about each one. The majority of people did not have access to the source. You keep saying that they did, that's just not true. And it is a shame, you can learn so much by just reading those early Unix versions. Ask yourself why the Lions book was so popular, I've seen photocopies of photocopies of photocopies to the point you can barely read it. If people could easily look at the source, why all the photocopies? I know you've seen them too. From davida at pobox.com Wed Feb 19 14:38:37 2020 From: davida at pobox.com (David Arnold) Date: Wed, 19 Feb 2020 15:38:37 +1100 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200219025616.GE30841@mcvoy.com> References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> <20200219025616.GE30841@mcvoy.com> Message-ID: > On 19 Feb 2020, at 13:56, Larry McVoy wrote: > On Tue, Feb 18, 2020 at 09:27:47PM -0500, Clem Cole wrote: <…> >> Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge >> success. It did what we wanted -- it displaced the proprietary systems. >> And in the end, the UNIX ideas and UNIX technologies live today - because >> they were open and available to everyone. It does not matter if it was >> GPL'ed or otherwise. > > I agree with that. This “displacement” has really only been widely true in the last 5-10 years. “Open Systems” seemed to peak (from my recollection) around the early 90’s. The Unix model and POSIX APIs became dominant, and VMS, NonStop, MVS, VM, etc, etc, died away, often together with their hardware. The exception to this was Windows NT (and descendants) which killed the Open System era, and dominated the small to mid-size markets, leaving Open Systems and the remnants of proprietary OSes to large and/or specialised niches. One factor behind the success of Windows Server was that the PC hardware market’s brutal competition led to decent quality hardware at a fraction of the price of competing platforms. This overwhelmed the advantages of Open Systems, and the movement stalled — people were willing to buy into a proprietary OS again, because it was *cheap*, despite just recently having escaped OS lock-in with Open Systems. Concurrent with the rise of Windows was the emergence of Linux (and early on, the *BSDs). The PC Unices (including Linux) leveraged the PC platform like Windows did. But it was the dotcom era, and the availability of dirt cheap virtual hosts that had to run Linux because the licensing cost of Windows Server was an order of magnitude more than the virtual hardware, which has resulted in Linux (and thus POSIX APIs and a Unix model) being almost ubiquitous today. I think it’s a mistake to conflate Open Systems with Free/Open Source Software. Despite eg. POSIX being the root of both, Open Systems was dead in the market well before FOSS operating systems took off outside academic environments. d From tytso at mit.edu Wed Feb 19 15:04:41 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 19 Feb 2020 00:04:41 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: <20200219050441.GF330201@mit.edu> On Tue, Feb 18, 2020 at 09:27:47PM -0500, Clem Cole wrote: > That said, we have deviated from what it means to be "open." What I'm > hearing from Ted and Larry that they think open can only mean stallman's > definition. I have said, that is not, was not the original definition, nor > is it the only case and that the UNIX technology itself was really not as > tied up as he claims. I think "Open Systems" failed *because* it failed to stop the Unix Wars. Or in other words, because we had proprietary system vendors who all were implementing extensions to Unix in incompatible ways, was a sign that the original definition of Open was hopelessly idealistic in that it assumed the suits would allow companies to operate the same way it did when everything was funded by things like DARPA grants at the engineering work was done in Universities. So I accept that the original definition was different, and to the extent that most of the Legacy Unix systems no longer have much commericial impact, and have now been replaced by Linux, is a strong hint that while the *goals* of the original "Open Systems" mantra may have worked, and while it may have allowed VMS to be displaced, in the end, as everyone implemented their own versions of various enhancements to Unix, and over time, as people even stopped publishing them at Usenix conferences (with Sun being the last holdout; I was at IBM when IBM stopped incentivizing engineers to publish at conferences, and then given the amount of work engineers were asked to do, it effectively meant very few papers were getting published from industry --- especially as Usenix cranked up the work factor for academic-quality papers), I think you may be viewing the "Unix community" with rose-colored glasses. > A point Ted has made and I accept is by the time of the UNIX Wars, the old > proprietary folks were trying to keep their own versions of UNIX 'secret' > and to use Larry terms those roadblocks to >>there<< code was real. But > the truth is that the AT&T codebase (while getting more and more expensive > as the HW dropped in cost), was always available, and people both > commercial and research had it. The AT&T codebase by itself wasn't particularly interesting if the hardware you had was a Ultrasparc 5; or an SGI pizza box; or DS 5100. For that, you needed the proprietary Unix sources. Maybe you don't consider that to be part of "Open Systems", but I consider it all of a piece. And I don't see any solution to head off the Unix Wars and "secret, proprietary sauce" strategy, *other* than the GPL. Even if people were talking and publishing at Usenix, so all of the ideas were out there (even if the source wasn't) consider the sheer *waste* of having N different engineering teams all reimplementing the exact same feature --- except it wasn't exactly the same, because each company was trying to claim its own proprietary enhancement. And one solution to that was this like the POSIX standard, but that took a huge amount of effort as well. I consider all of that to also be a legacy of that original "Open Systems" definition, in terms of how it was actually implemented in the real world. > In the end, what matters to me is the ideas, the real intellectual property > NOT the source that implements it. This has been proven within the UNIX > community too many times. It has been re-engineered so many times over. In the Silicon Valley, one of the things they tell people who try to make people sign NDA's before they tell people about their great idea for a startup is, "don't stress over it"; ideas are a dime a dozen. What matters is the execution, and the product/market fit. While certain ideas maybe very simple, such as for example "the setuid bit", past a certain point, things have gotten complex enough that it's not just about the idea. Consider how many person years was required to create ZFS at Sun. My research into production quality file systems was that it requires between 50-200 person years to create a true enterprise quality file system, which is trusted as such. This was confirmed from my talking to many industry contacts about how many years were required for a number of file systems, including advfs at Digital, GPFS at IBM, etc. Any idiot can make a random file system prototype that mostly works; that doesn't take long. Creating an enterprise-ready, quality file system, is a very different thing altogether. I've seen the source code for projects that were written so that a paper could get published. I've tried to turn some them into something that could be used in production --- and that's one of the best places where you can see the huge gap between "the idea" and "something which can be used in production". > And that is because the *ideas that makeup what we call UNIX ARE open* and > the people looked at the sources, looked at the papers, talked to each > other and the community built on it. Did the people who worked at SGI get to take a lot at the sources for Digital's advfs? How much of advfs was published? And how much community was there between the different file system teams for xfs, advfs, ZFS, etc.? Is GPL licensing perfect? Heck no. I'll admit it has more than a few shortcomings. But consider an alternate world were at the point where AT&T was constrained by monopoly ruling, that someone had decided to release the Unix sources under a GPL-like license? How might have changed how (or whether) the Unix wars would have played out? Perhaps the community of OS developers would have been even stronger compared to the height of the Unix Wars? How might that have eased application programmers who had to struggle with configure scripts to make code that could run on N different Unix systems, which were almost, but not quite, identical? How might have that changed the availability of desktop applications like Quicken and Turbo Tax and Photoshop on Unix-like systems? I'm not GPL extremist; there are many positions where I'm sure Stallman and the Software Freedom Conservacy disagree very strongly. But the licensing terms of Unix(tm) were by no means perfect --- both the AT&T proprietary license for which you had to pay $$$ and sign licenses containing methods and concepts clauses, and the BSD license that came later --- and if you're going to criticize the GPL, perhaps it's also worth considering how other licensing regimes for Unix systems have worked out. - Ted P.S. And remember, Linux is *not* Unix(tm). It neither has the source code lineage, nor have people paid the $$$ to the conformance testing labs so that it can be called Unix(tm). And people can debate whether or not it walks sufficiently enough like a duck that we should consider it a duck, but while I certainly will acknowledge where Linux owes an intellectual debt to those systems which came before, it's also perfectly fair to point out its shortcomings. From imp at bsdimp.com Wed Feb 19 16:11:29 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 18 Feb 2020 23:11:29 -0700 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: On Tue, Feb 18, 2020, 7:28 PM Clem Cole wrote: > I'm not 100% sure why I'm arguing other than I feel this is so wrong and > so disingenuous to those that came before. > I think the difference is whether you were in the club or not. If you were inside and read in, there was a vibe that was very much like open source is today. If you read the old Australian Unix User Group newsletters, you have window into this time... but with a weird "papers please" to prove you were in the club. People passed things around in many of the same ways. It was cool and different than before. And people recall this fondly. Network Unix, for example, dominated the ARPANET from 75 to 78... and it was pure sharing... with a catch. Now, if you weren't in the club, or recall a time when you were excluded, you'd have a very different remembrance. The model was better than what came before, but not yet to where it needed to be. The Unix Wars, imho, shot that all to shit. It set the stage for the revolutions that happened. I disagree the GPL was all that. It didn't force people to really do the right thing... I have had dozens of boards that run Linux but no source. The manufacturer doesn't care or has gone out of business. People only comply because they think it is in their best interest. But they do it for BSD too... and just because it is free doesn't make it good.. linux has a dozen Wifi stacks... It's no wonder people have divergent interpretations of how we got here. What myth do you but into? That will determine if you look at things one way or another... Warner But, you have to decide that having access to all your sources for your > system is your measure of 'success.' My value of success is no more VMS, > Kronos, or VM/CMS or the like. I will accept Larry's position that he had > many roadblocks that were often silly. But I really don't think my world > was as 'charmed' as he claims and his was quite as bad as his might think > you look at it. > > That said, we have deviated from what it means to be "open." What I'm > hearing from Ted and Larry that they think open can only mean stallman's > definition. I have said, that is not, was not the original definition, nor > is it the only case and that the UNIX technology itself was really not as > tied up as he claims. I think Larry did have access to sources (maybe not > at his University), but like so many of us, once he got to a place that had > them (like SGI or Sun). My point is that besides being to read about it in > books and papers, getting access to the source from AT&T or UCB was really > the norm and stating otherwise is disingenuous and trying to rewrite > history a bit. > > A point Ted has made and I accept is by the time of the UNIX Wars, the old > proprietary folks were trying to keep their own versions of UNIX 'secret' > and to use Larry terms those roadblocks to >>there<< code was real. But > the truth is that the AT&T codebase (while getting more and more expensive > as the HW dropped in cost), was always available, and people both > commercial and research had it. > > The problem was that as hardware cost dropped, more and more people wanted > the sources too and that were the I think the difference in the success > metrics come. > > Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge > success. It did what we wanted -- it displaced the proprietary systems. > And in the end, the UNIX ideas and UNIX technologies live today - because > they were open and available to everyone. It does not matter if it was > GPL'ed or otherwise. > > In the end, what matters to me is the ideas, the real intellectual > property NOT the source that implements it. This has been proven within > the UNIX community too many times. It has been re-engineered so many times > over. Just like Fortran lives today, although it's different from what I > learned in the 1960s. It's still Fortran. Unix is different from what I > saw in the early 1970s, but its still Unix. > > And that is because the *ideas that makeup what we call UNIX ARE open* > and the people looked at the sources, looked at the papers, talked to each > other and the community built on it. > > It looks like a duck. It quacks like a duck and even tastes like duck > (mostly) when you inside. It's a duck. > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Feb 19 17:56:09 2020 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 19 Feb 2020 17:56:09 +1000 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: <20200219075609.GA16943@minnie.tuhs.org> I'll put in my own $0.05 with my story about why TUHS was created. I fell in love with Unix in the late 80s, first on a Pyramid 90x running OSx (dual AT&T/BSD userland), followed by a sysadmin stint on the Pyramid and a Sun 2 box running SunOS. No access to source code, except for what I could download from the Usenet comp.sources.* newsgroups. Then the university I worked for purchased Minix 1.1 and I was a pig in mud: I could look at the source, apply the patches from the Minix newsgroup and rebuild the entire system. Still no access to Unix source code. I took a new job (early 90s on Sun 3s) and started to pester people to try and get a copy of V7 Unix, as I knew I wouldn't be able to get the SunOS source. Luckily, someone sent me an RL02 disk image with (modified) V7 on it. Then I found out that my new employer (UNSW) actually had a Unix source license. It was at that point that I began the quest to get the "ancient" Unix sources put under a free/cheap licence. Cheers, Warren From thomas.paulsen at firemail.de Wed Feb 19 18:27:31 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 19 Feb 2020 09:27:31 +0100 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: Message-ID: <48d85da02f9b0e4efe3c2dde750fa2b6@firemail.de> An HTML attachment was scrubbed... URL: From michael at kjorling.se Thu Feb 20 00:54:37 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 19 Feb 2020 14:54:37 +0000 Subject: [COFF] man Macro Package and pdfmark In-Reply-To: <01DD0405-D65B-4557-AD0E-4A128334DE2E@bitblocks.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> <01DD0405-D65B-4557-AD0E-4A128334DE2E@bitblocks.com> Message-ID: On 18 Feb 2020 15:04 -0800, from bakul at bitblocks.com (Bakul Shah): > IIRC even the original IBM PC came with schematics. I'm not completely sure about the schematics, but the full, commented, BIOS source code listing definitely was available in IBM's own Technical Reference. http://www.bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf (the BIOS source code listing begins at page 192 of the PDF). -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From lm at mcvoy.com Thu Feb 20 01:19:16 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 19 Feb 2020 07:19:16 -0800 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> Message-ID: <20200219151916.GA12990@mcvoy.com> Warner is spot on. I was a little late to the party so I didn't even realize there was a club at the time, I just knew that it was hard to get to the source. Looking back, I can see there was a club and I was not in it, I was a little late, I sort of clawed my way in a bit but I was definitely not part of the club. I'm annoyed by that because not being part of it held me back a bit. So yeah, very different memories depending on where you were. Warner nailed it. On Tue, Feb 18, 2020 at 11:11:29PM -0700, Warner Losh wrote: > On Tue, Feb 18, 2020, 7:28 PM Clem Cole wrote: > > > I'm not 100% sure why I'm arguing other than I feel this is so wrong and > > so disingenuous to those that came before. > > > > I think the difference is whether you were in the club or not. If you were > inside and read in, there was a vibe that was very much like open source is > today. If you read the old Australian Unix User Group newsletters, you have > window into this time... but with a weird "papers please" to prove you were > in the club. People passed things around in many of the same ways. It was > cool and different than before. And people recall this fondly. Network > Unix, for example, dominated the ARPANET from 75 to 78... and it was pure > sharing... with a catch. > > Now, if you weren't in the club, or recall a time when you were excluded, > you'd have a very different remembrance. The model was better than what > came before, but not yet to where it needed to be. > > The Unix Wars, imho, shot that all to shit. It set the stage for the > revolutions that happened. > > I disagree the GPL was all that. It didn't force people to really do the > right thing... I have had dozens of boards that run Linux but no source. > The manufacturer doesn't care or has gone out of business. People only > comply because they think it is in their best interest. But they do it for > BSD too... and just because it is free doesn't make it good.. linux has a > dozen Wifi stacks... > > It's no wonder people have divergent interpretations of how we got here. > What myth do you but into? That will determine if you look at things one > way or another... > > Warner > > But, you have to decide that having access to all your sources for your > > system is your measure of 'success.' My value of success is no more VMS, > > Kronos, or VM/CMS or the like. I will accept Larry's position that he had > > many roadblocks that were often silly. But I really don't think my world > > was as 'charmed' as he claims and his was quite as bad as his might think > > you look at it. > > > > That said, we have deviated from what it means to be "open." What I'm > > hearing from Ted and Larry that they think open can only mean stallman's > > definition. I have said, that is not, was not the original definition, nor > > is it the only case and that the UNIX technology itself was really not as > > tied up as he claims. I think Larry did have access to sources (maybe not > > at his University), but like so many of us, once he got to a place that had > > them (like SGI or Sun). My point is that besides being to read about it in > > books and papers, getting access to the source from AT&T or UCB was really > > the norm and stating otherwise is disingenuous and trying to rewrite > > history a bit. > > > > A point Ted has made and I accept is by the time of the UNIX Wars, the old > > proprietary folks were trying to keep their own versions of UNIX 'secret' > > and to use Larry terms those roadblocks to >>there<< code was real. But > > the truth is that the AT&T codebase (while getting more and more expensive > > as the HW dropped in cost), was always available, and people both > > commercial and research had it. > > > > The problem was that as hardware cost dropped, more and more people wanted > > the sources too and that were the I think the difference in the success > > metrics come. > > > > Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge > > success. It did what we wanted -- it displaced the proprietary systems. > > And in the end, the UNIX ideas and UNIX technologies live today - because > > they were open and available to everyone. It does not matter if it was > > GPL'ed or otherwise. > > > > In the end, what matters to me is the ideas, the real intellectual > > property NOT the source that implements it. This has been proven within > > the UNIX community too many times. It has been re-engineered so many times > > over. Just like Fortran lives today, although it's different from what I > > learned in the 1960s. It's still Fortran. Unix is different from what I > > saw in the early 1970s, but its still Unix. > > > > And that is because the *ideas that makeup what we call UNIX ARE open* > > and the people looked at the sources, looked at the papers, talked to each > > other and the community built on it. > > > > It looks like a duck. It quacks like a duck and even tastes like duck > > (mostly) when you inside. It's a duck. > > _______________________________________________ > > COFF mailing list > > COFF at minnie.tuhs.org > > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Thu Feb 20 07:13:38 2020 From: clemc at ccc.com (Clem cole) Date: Wed, 19 Feb 2020 16:13:38 -0500 Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200219151916.GA12990@mcvoy.com> References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> <20200219151916.GA12990@mcvoy.com> Message-ID: <7CD8352D-A571-4DC5-8934-786E5402BC14@ccc.com> I’m traveling so I can not really reply. But I too think Warren is correct and it probably does come from where you started / your core experiences will taint your view. Clem Sent from my Handheld - expect things to be almost but not quite. > On Feb 19, 2020, at 10:19 AM, Larry McVoy wrote: > > Warner is spot on. I was a little late to the party so I didn't even > realize there was a club at the time, I just knew that it was hard to > get to the source. Looking back, I can see there was a club and I was > not in it, I was a little late, I sort of clawed my way in a bit but > I was definitely not part of the club. I'm annoyed by that because > not being part of it held me back a bit. > > So yeah, very different memories depending on where you were. Warner > nailed it. > >> On Tue, Feb 18, 2020 at 11:11:29PM -0700, Warner Losh wrote: >>> On Tue, Feb 18, 2020, 7:28 PM Clem Cole wrote: >>> >>> I'm not 100% sure why I'm arguing other than I feel this is so wrong and >>> so disingenuous to those that came before. >>> >> >> I think the difference is whether you were in the club or not. If you were >> inside and read in, there was a vibe that was very much like open source is >> today. If you read the old Australian Unix User Group newsletters, you have >> window into this time... but with a weird "papers please" to prove you were >> in the club. People passed things around in many of the same ways. It was >> cool and different than before. And people recall this fondly. Network >> Unix, for example, dominated the ARPANET from 75 to 78... and it was pure >> sharing... with a catch. >> >> Now, if you weren't in the club, or recall a time when you were excluded, >> you'd have a very different remembrance. The model was better than what >> came before, but not yet to where it needed to be. >> >> The Unix Wars, imho, shot that all to shit. It set the stage for the >> revolutions that happened. >> >> I disagree the GPL was all that. It didn't force people to really do the >> right thing... I have had dozens of boards that run Linux but no source. >> The manufacturer doesn't care or has gone out of business. People only >> comply because they think it is in their best interest. But they do it for >> BSD too... and just because it is free doesn't make it good.. linux has a >> dozen Wifi stacks... >> >> It's no wonder people have divergent interpretations of how we got here. >> What myth do you but into? That will determine if you look at things one >> way or another... >> >> Warner >> >> But, you have to decide that having access to all your sources for your >>> system is your measure of 'success.' My value of success is no more VMS, >>> Kronos, or VM/CMS or the like. I will accept Larry's position that he had >>> many roadblocks that were often silly. But I really don't think my world >>> was as 'charmed' as he claims and his was quite as bad as his might think >>> you look at it. >>> >>> That said, we have deviated from what it means to be "open." What I'm >>> hearing from Ted and Larry that they think open can only mean stallman's >>> definition. I have said, that is not, was not the original definition, nor >>> is it the only case and that the UNIX technology itself was really not as >>> tied up as he claims. I think Larry did have access to sources (maybe not >>> at his University), but like so many of us, once he got to a place that had >>> them (like SGI or Sun). My point is that besides being to read about it in >>> books and papers, getting access to the source from AT&T or UCB was really >>> the norm and stating otherwise is disingenuous and trying to rewrite >>> history a bit. >>> >>> A point Ted has made and I accept is by the time of the UNIX Wars, the old >>> proprietary folks were trying to keep their own versions of UNIX 'secret' >>> and to use Larry terms those roadblocks to >>there<< code was real. But >>> the truth is that the AT&T codebase (while getting more and more expensive >>> as the HW dropped in cost), was always available, and people both >>> commercial and research had it. >>> >>> The problem was that as hardware cost dropped, more and more people wanted >>> the sources too and that were the I think the difference in the success >>> metrics come. >>> >>> Certainly, for us that lived in a 'pre-UNIX' world, UNIX was a huge >>> success. It did what we wanted -- it displaced the proprietary systems. >>> And in the end, the UNIX ideas and UNIX technologies live today - because >>> they were open and available to everyone. It does not matter if it was >>> GPL'ed or otherwise. >>> >>> In the end, what matters to me is the ideas, the real intellectual >>> property NOT the source that implements it. This has been proven within >>> the UNIX community too many times. It has been re-engineered so many times >>> over. Just like Fortran lives today, although it's different from what I >>> learned in the 1960s. It's still Fortran. Unix is different from what I >>> saw in the early 1970s, but its still Unix. >>> >>> And that is because the *ideas that makeup what we call UNIX ARE open* >>> and the people looked at the sources, looked at the papers, talked to each >>> other and the community built on it. >>> >>> It looks like a duck. It quacks like a duck and even tastes like duck >>> (mostly) when you inside. It's a duck. >>> _______________________________________________ >>> COFF mailing list >>> COFF at minnie.tuhs.org >>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff >>> > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dave at horsfall.org Thu Feb 20 07:21:31 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 20 Feb 2020 08:21:31 +1100 (EST) Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200219075609.GA16943@minnie.tuhs.org> References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> <20200219075609.GA16943@minnie.tuhs.org> Message-ID: On Wed, 19 Feb 2020, Warren Toomey wrote: [...] > It was at that point that I began the quest to get the "ancient" Unix > sources put under a free/cheap licence. And somewhere, I still have my Ancient Unix Licence; paid good money for it, too :-) Oh, and don't forget that TUHS was born of PUPS, and I think that I suggested the name of COFF. -- Dave From dave at horsfall.org Thu Feb 20 07:37:53 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 20 Feb 2020 08:37:53 +1100 (EST) Subject: [COFF] Standing on the shoulders of giants, free or not In-Reply-To: <20200219151916.GA12990@mcvoy.com> References: <20200218225824.GB152025@mit.edu> <20200219015446.GC30841@mcvoy.com> <20200219151916.GA12990@mcvoy.com> Message-ID: On Wed, 19 Feb 2020, Larry McVoy wrote: [...] > So yeah, very different memories depending on where you were. Warner > nailed it. Working at UNSW at the time (which had a source licence) it never occurred to me that some people may not have the source; it wasn't until I ventured into the commercial sector (starting with the Lionel Singer Group) that I realised the awful truth :-( -- Dave From dave at horsfall.org Thu Feb 20 15:05:00 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 20 Feb 2020 16:05:00 +1100 (EST) Subject: [COFF] [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: [ Moved to COFF ] On Wed, 19 Feb 2020, Richard Salz wrote: > He's a loon.  Search for the techdirt.com articles. > > > On Wed, Feb 19, 2020, 7:07 PM Ed Carp wrote: > > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > > Twitter, claiming that he is the inventor of email. He doesn't > > look like he's nearly old enough. I thought it was Ray > > Tomlinson. Looks like he's trying to create some press for his > > Senate run. > > > > Anyone older that me here that can either confirm or deny? > > Thanks! Back when I was posting "On this day" events, I had this for Ray Tomlinson for 23rd April: Ray Tomlinson, computer pioneer, was born on this day in 1941. He is credited with inventing this weird thing called "email" on the ARPAnet, in particular the "@" sign to designate a remote host (although some jerk -- his name is not important -- is claiming that he was first). -- Dave From gdmr at inf.ed.ac.uk Thu Feb 20 21:54:12 2020 From: gdmr at inf.ed.ac.uk (George Ross) Date: Thu, 20 Feb 2020 11:54:12 +0000 Subject: [COFF] non-volatile main memory (NVMM) Message-ID: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> Seen on one of our local "seminars" lists recently... > Emerging hardware, such as non-volatile main memory (NVMM) [...] > changes the way system software should be designed and implemented, > because they are not just an enhanced version of existing devices, > but provide new qualitative features and software interfaces. Core store, mutter, mutter. We used to regularly restart machines which had been turned off for a while, and they would happily pick up where they left off. One PDP-8 was happy to resume after several years of idleness. Sorry, had to send that, mutter... -- George D M Ross MSc PhD CEng MBCS CITP University of Edinburgh, School of Informatics, Appleton Tower, 11 Crichton Street, Edinburgh, Scotland, EH8 9LE Mail: gdmr at inf.ed.ac.uk Voice: 0131 650 5147 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From david at kdbarto.org Thu Feb 20 23:31:19 2020 From: david at kdbarto.org (David Barto) Date: Thu, 20 Feb 2020 05:31:19 -0800 Subject: [COFF] non-volatile main memory (NVMM) In-Reply-To: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> References: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> Message-ID: <85992711-B741-4320-A645-D4AD5964E1A4@kdbarto.org> > On Feb 20, 2020, at 3:54 AM, George Ross wrote: > > Core store, mutter, mutter. > > We used to regularly restart machines which had been turned off for a > while, and they would happily pick up where they left off. One PDP-8 was > happy to resume after several years of idleness. > > Sorry, had to send that, mutter… So a story about core memory. I was working with a group and had just finished bring up of a new system. It was running the diagnostics when someone in shipping turned off the hardware. No disk so no risk of breaking something like that (ah those were the days). Anyway they pack the machine and deliver it to the customer (name lost to the mists of time) who gets it set up and then powered on. It resumes the diagnostic. The customer was amazed that the machine would perform a diagnostic on power up. Though that was the most wonderful idea. David From dave at horsfall.org Fri Feb 21 06:39:31 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 21 Feb 2020 07:39:31 +1100 (EST) Subject: [COFF] non-volatile main memory (NVMM) In-Reply-To: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> References: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> Message-ID: On Thu, 20 Feb 2020, George Ross wrote: > We used to regularly restart machines which had been turned off for a > while, and they would happily pick up where they left off. One PDP-8 > was happy to resume after several years of idleness. There was a story posted to Usenet yonks ago about a minicomputer (PDP-8?) being used for nuclear testing. The last test involved the box inside a truck, parked on top of the hole. Truck flies up into the air, but the core memory survived intact, was retrieved, and plugged into another box and all the data read out. Try doing *that* with solid-state memory :-) -- Dave From rtomek at ceti.pl Fri Feb 21 07:50:02 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 20 Feb 2020 22:50:02 +0100 Subject: [COFF] [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: <20200220215002.GC1470@tau1.ceti.pl> On Thu, Feb 20, 2020 at 04:05:00PM +1100, Dave Horsfall wrote: > [ Moved to COFF ] > [...] > Back when I was posting "On this day" events, I had this for Ray > Tomlinson for 23rd April: > > Ray Tomlinson, computer pioneer, was born on this day in 1941. He is > credited with inventing this weird thing called "email" on the > ARPAnet, in particular the "@" sign to designate a remote host > (although some jerk -- his name is not important -- is claiming that > he was first). I am afraid of jerks even if only a judge will listen to them. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From stewart at serissa.com Fri Feb 21 09:14:08 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 20 Feb 2020 18:14:08 -0500 Subject: [COFF] non-volatile main memory (NVMM) In-Reply-To: References: <202002201154.01KBsCSb013194@maysl7.inf.ed.ac.uk> Message-ID: <460C6BAE-85E4-4040-A538-3C995EC4DB10@serissa.com> So at the old MIT Architecture Machine (predecessor of the Media lab) circa 1975/6 we had Interdata 7/32 minicomputers running the home-grown Magic 6 OS. These machines had core memory, and there was a microcode bug that under certain circumstances (happily rare) you could get into an infinite loop taking interrupts or faults of some sort. Due to the core, this condition could not be cleared by the reset switch or even turning off the power. IIRC the only way to clear it was to unplug the core memory board while the power was on. -Larry > On 2020, Feb 20, at 3:39 PM, Dave Horsfall wrote: > > On Thu, 20 Feb 2020, George Ross wrote: > >> We used to regularly restart machines which had been turned off for a while, and they would happily pick up where they left off. One PDP-8 was happy to resume after several years of idleness. > > There was a story posted to Usenet yonks ago about a minicomputer (PDP-8?) being used for nuclear testing. The last test involved the box inside a truck, parked on top of the hole. Truck flies up into the air, but the core memory survived intact, was retrieved, and plugged into another box and all the data read out. Try doing *that* with solid-state memory :-) > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From michael at kjorling.se Sat Feb 22 19:26:02 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 22 Feb 2020 09:26:02 +0000 Subject: [COFF] On the rise and fall of Gopher Message-ID: The EFF just published an article on the rise and fall of Gopher on their Deeplinks blog. "Gopher: When Adversarial Interoperability Burrowed Under the Gatekeepers' Fortresses" https://www.eff.org/deeplinks/2020/02/gopher-when-adversarial-interoperability-burrowed-under-gatekeepers-fortresses I thought it might be of interest to people here. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From anders at adamsgaard.dk Sat Feb 22 20:03:18 2020 From: anders at adamsgaard.dk (Anders Damsgaard) Date: Sat, 22 Feb 2020 11:03:18 +0100 Subject: [COFF] On the rise and fall of Gopher In-Reply-To: References: Message-ID: <20200222100318.GJ77254@idkfa.home> Relevant to the EFF post; gopher is not dead! gopher://gopherproject.org/ http://gopherproject.org/ curl and lynx natively support the gopher protocol, and sacc is a nice client: gopher://bitreich.org/1/scm/sacc Anders -- Anders Damsgaard https://adamsgaard.dk From ik at sjmulder.nl Mon Feb 24 19:40:10 2020 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Mon, 24 Feb 2020 10:40:10 +0100 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200212030152.GJ852@mcvoy.com> References: <20200212030152.GJ852@mcvoy.com> Message-ID: <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> Larry McVoy wrote: > Fortran programmers are formally trained (at least I > was, there was a whole semester devoted to this) in accumulated errors. > You did a deep dive into how to code stuff so that the error was reduced > each time instead of increased. It has a lot to do with how floating > point works, it's not exact like integers are. I was unaware that there's formal training to be had around this but it's something I'd like to learn more about. Any recommendations on materials? I don't mind diving into Fortran itself either. Background: I've been playing around with actuarial calculations (pensions, life insurance, etc) which involve lots of accumulation over time and I'm finding that, unsurprisingly, different implementations of the same rules yield fairly different outcomes due to accumulated errors. Sijmen From lm at mcvoy.com Tue Feb 25 01:19:29 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 24 Feb 2020 07:19:29 -0800 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> Message-ID: <20200224151929.GJ30841@mcvoy.com> On Mon, Feb 24, 2020 at 10:40:10AM +0100, Sijmen J. Mulder wrote: > Larry McVoy wrote: > > Fortran programmers are formally trained (at least I > > was, there was a whole semester devoted to this) in accumulated errors. > > You did a deep dive into how to code stuff so that the error was reduced > > each time instead of increased. It has a lot to do with how floating > > point works, it's not exact like integers are. > > I was unaware that there's formal training to be had around this but > it's something I'd like to learn more about. Any recommendations on > materials? I don't mind diving into Fortran itself either. My training was 35 years ago, I have no idea where to go look for this stuff now. I googled and didn't find much. I'd go to the local University that teaches Fortran and ask around. From clemc at ccc.com Tue Feb 25 02:15:46 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Feb 2020 11:15:46 -0500 Subject: [COFF] [TUHS] Fwd: Old and Tradition was V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: First please continue this discussion on COFF (which has been CC'ed). While Fortran is interesting to many, it not a UNIX topic per say. Also, as I have noted in other places, I work for Intel - these comments are my own and I'm not trying to sell you anything. Just passing on 45+ years of programming experience. On Mon, Feb 24, 2020 at 10:34 AM Adam Thornton wrote: > I would think that FORTRAN is likelier to be passed around as folk wisdom > and ancient PIs (uh, Primary Investigators, not the detective kind) > thrusting a dog-eared FORTRAN IV manual at their new grad students and > snarling "RTFM!" than as actual college courses. > FWIW: I was at CMU last week recruiting. Fortran, even at a leading CS place like CMU, is hardly "folk wisdom". All the science PhD's (Chem, Mat Sci, Bio, Physics) that I interviewed all knew and used Fortran (nad listed on their CV's) as their primary language for their science. As I've quipped before, Fortran pays my own (and a lot of other people's salaries in the industry). Check out: https://www.archer.ac.uk/status/codes/ Fortran is about 90% of the codes running (FWIW: I have seen similar statistics from other large HPC sites - you'll need to poke). While I do not write in it, I believe there are three reasons why these statistics are true and* going to be true for a very long time*: 1. The math being used has not changed. Just open up the codes and look at what they are doing. You will find that they all are all solving systems of partial differential equations using linear algebra (-- see the movie: "Hidden Figures"). 2. 50-75 years of data sets with know qualities and programs to work with them. If you were able to replace the codes magically with something 'better' - (from MathLab to Julia or Python to Java) all their data would have to be requalified (it is like the QWERTY keyboard - that shipped sailed years ago). 3. The *scientists want to do their science* for their work to get their degree or prize. The computer and its programs *are a tool* for them look at data *to do their science*. They don't care as long as they get their work done. Besides Adam's mention of flang, there is, of course, gfortran; but there are also commerical compilers available for use: Qualify for Free Software | Intel® Software I believe PGI offers something similar, but I have not checked in a while. Most 'production' codes use a real compiler like Intel, PGI or Cray's. FWIW: the largest number of LLVM developers are at Intel now. IMO, while flang is cute, it will be a toy for a while, as the LLVM IL really can not handle Fortran easily. There is a huge project to put a number of the learnings from the DEC Gem compilers into LLVM and one piece is gutting the internal IL and making work for parallel architectures. The >>hope<< by many of my peeps, (still unproven) is that at some point the FOSS world will produce a compiler as good a Gem or the current Intel icc/ifort set. (Hence, Intel is forced to support 3 different compiler technologies internally in the technical languages group). -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Feb 25 02:19:33 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Feb 2020 11:19:33 -0500 Subject: [COFF] [TUHS] Fwd: Old and Tradition was V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: I probably should have added, it's not just the learnings from DEC Gem folks, but also the old "Kuck and Associates" team formerly in Champaign (Intel moved them all to Austin). On Mon, Feb 24, 2020 at 11:15 AM Clem Cole wrote: > > First please continue this discussion on COFF (which has been CC'ed). > While Fortran is interesting to many, it not a UNIX topic per say. > > Also, as I have noted in other places, I work for Intel - these comments > are my own and I'm not trying to sell you anything. Just passing on 45+ > years of programming experience. > > On Mon, Feb 24, 2020 at 10:34 AM Adam Thornton > wrote: > >> I would think that FORTRAN is likelier to be passed around as folk wisdom >> and ancient PIs (uh, Primary Investigators, not the detective kind) >> thrusting a dog-eared FORTRAN IV manual at their new grad students and >> snarling "RTFM!" than as actual college courses. >> > FWIW: I was at CMU last week recruiting. Fortran, even at a leading CS > place like CMU, is hardly "folk wisdom". All the science PhD's (Chem, Mat > Sci, Bio, Physics) that I interviewed all knew and used Fortran (nad listed > on their CV's) as their primary language for their science. > > As I've quipped before, Fortran pays my own (and a lot of other people's > salaries in the industry). Check out: > https://www.archer.ac.uk/status/codes/ Fortran is about 90% of the codes > running (FWIW: I have seen similar statistics from other large HPC sites > - you'll need to poke). > > While I do not write in it, I believe there are three reasons why these > statistics are true and* going to be true for a very long time*: > > 1. The math being used has not changed. Just open up the codes and > look at what they are doing. You will find that they all are all solving > systems of partial differential equations using linear algebra (-- see the > movie: "Hidden Figures"). > 2. 50-75 years of data sets with know qualities and programs to work > with them. If you were able to replace the codes magically with something > 'better' - (from MathLab to Julia or Python to Java) all their data would > have to be requalified (it is like the QWERTY keyboard - that shipped > sailed years ago). > 3. The *scientists want to do their science* for their work to get > their degree or prize. The computer and its programs *are a tool* > for them look at data *to do their science*. They don't care as long > as they get their work done. > > > Besides Adam's mention of flang, there is, of course, gfortran; but there > are also commerical compilers available for use: Qualify for Free > Software | Intel® Software > I > believe PGI offers something similar, but I have not checked in a while. > Most 'production' codes use a real compiler like Intel, PGI or Cray's. > > FWIW: the largest number of LLVM developers are at Intel now. IMO, > while flang is cute, it will be a toy for a while, as the LLVM IL really > can not handle Fortran easily. There is a huge project to put a number of > the learnings from the DEC Gem compilers into LLVM and one piece is gutting > the internal IL and making work for parallel architectures. The >>hope<< > by many of my peeps, (still unproven) is that at some point the FOSS world > will produce a compiler as good a Gem or the current Intel icc/ifort set. > (Hence, Intel is forced to support 3 different compiler technologies > internally in the technical languages group). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Feb 25 02:27:38 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Feb 2020 11:27:38 -0500 Subject: [COFF] Fwd: Old and Tradition was [TUHS] V9 shell In-Reply-To: <20200224151929.GJ30841@mcvoy.com> References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: On Mon, Feb 24, 2020 at 10:19 AM Larry McVoy wrote: > On Mon, Feb 24, 2020 at 10:40:10AM +0100, Sijmen J. Mulder wrote: > > Larry McVoy wrote: > > > Fortran programmers are formally trained (at least I > > > was, there was a whole semester devoted to this) in accumulated errors. > > > You did a deep dive into how to code stuff so that the error was > reduced > > > each time instead of increased. It has a lot to do with how floating > > > point works, it's not exact like integers are. > > > > I was unaware that there's formal training to be had around this but > > it's something I'd like to learn more about. Any recommendations on > > materials? I don't mind diving into Fortran itself either. > > My training was 35 years ago, I have no idea where to go look for this > stuff now. I googled and didn't find much. I'd go to the local > University that teaches Fortran and ask around. > 1. Download the Intel Fortran compiler for your Mac, Linux or Windows box. This will also give you a number of tuning tools. This compiler can understand syntax back to FORTRAN-66 through Fortran2018 (and often without any switches - it can usually figure it out and do the right thing). 2. Get a copy of https://www.amazon.com/Explained-Numerical-Mathematics-Scientific-Computation/dp/0199601429 3. Go to the physics and chem depts a place start as Larry said 4. Or head to a supercomputer center in the US or EU -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Feb 28 09:37:00 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 27 Feb 2020 16:37:00 -0700 Subject: [COFF] 52-pin D-Sub? Message-ID: I work at an astronomy facility. I get to do some fun dumpster diving. I recently have pulled out of the trash a plugboard with a male and a female D-Sub 52 connector. 3 rows of pins, 17-18-17. I took the connectors off the board: there's nothing back there, so this thing only ever existed so you could plug the random cable you found into it and its friends to see what the cable fit. I can't find much evidence that a 52-pin D-Sub ever existed. Is this just Yet Another Physics Experiment thing where, hey, if your instrument already costs three million dollars, what's a couple of grand for machining custom connectors? Or was it once a thing? (also posting to cc-talk) Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Feb 28 10:04:19 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Feb 2020 11:04:19 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: Message-ID: On Thu, 27 Feb 2020, Adam Thornton wrote: > I recently have pulled out of the trash a plugboard with a male and a > female D-Sub 52 connector.  3 rows of pins, 17-18-17.  I took the > connectors off the board: there's nothing back there, so this thing only > ever existed so you could plug the random cable you found into it and > its friends to see what the cable fit. That would be something like a DD-52P (certainly not a DB-52P!). > I can't find much evidence that a 52-pin D-Sub ever existed. Well, Digikey seem to have them: http://www.digikey.com/product-detail/en/itt-cannon-llc/2DB-52P/2DB-52P-ND/4734668 No photo, though... -- Dave From stewart at serissa.com Fri Feb 28 11:37:00 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 27 Feb 2020 20:37:00 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: Message-ID: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Huh. New to me too, but Digikey links to the datasheets, and they really do mean DB. They go up to DD100. They are called “double density”. This reminds me of the circa 1990 “HIPPI” interface, or high performance parallel interface. They typically ran at 50 MB/sec. The connectors were two-row 100-pin D style. See http://www.elpeus.com/scsi-cables/100pin-scsi-cable-hippi/3m-100pin-male-to-100pin-male-scsi-cable-hippi/ for example. We used these cables and connectors on the first Alpha machines at Digital to connect the 3Max front end processor to the ECL based Alpha Demonstration Units, although the protocol was different. The connector was about the biggest that would fit on a TurboChannel I/O card. > On 2020, Feb 27, at 7:04 PM, Dave Horsfall wrote: > > On Thu, 27 Feb 2020, Adam Thornton wrote: > >> I recently have pulled out of the trash a plugboard with a male and a female D-Sub 52 connector. 3 rows of pins, 17-18-17. I took the connectors off the board: there's nothing back there, so this thing only ever existed so you could plug the random cable you found into it and its friends to see what the cable fit. > > That would be something like a DD-52P (certainly not a DB-52P!). > >> I can't find much evidence that a 52-pin D-Sub ever existed. > > Well, Digikey seem to have them: > > http://www.digikey.com/product-detail/en/itt-cannon-llc/2DB-52P/2DB-52P-ND/4734668 > > No photo, though... > > -- Dave_______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Feb 28 12:12:30 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 27 Feb 2020 19:12:30 -0700 Subject: [COFF] 52-pin D-Sub? In-Reply-To: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: Yeah, 0.075" pin centers, does appear to be the ITT Cannon part. Now what experiment used them, and _why_ (I mean, surely 68-pin SCSI would have done the trick as well and been muuuuuuch cheaper), I don't know. Adam On Thu, Feb 27, 2020 at 6:37 PM Lawrence Stewart wrote: > Huh. New to me too, but Digikey links to the datasheets, and they really > do mean DB. > They go up to DD100. They are called “double density”. > > This reminds me of the circa 1990 “HIPPI” interface, or high performance > parallel interface. They typically ran at 50 MB/sec. The connectors were > two-row 100-pin D style. See > http://www.elpeus.com/scsi-cables/100pin-scsi-cable-hippi/3m-100pin-male-to-100pin-male-scsi-cable-hippi/ for > example. > > We used these cables and connectors on the first Alpha machines at Digital > to connect the 3Max front end processor to the ECL based Alpha > Demonstration Units, although the protocol was different. The connector > was about the biggest that would fit on a TurboChannel I/O card. > > > On 2020, Feb 27, at 7:04 PM, Dave Horsfall wrote: > > On Thu, 27 Feb 2020, Adam Thornton wrote: > > I recently have pulled out of the trash a plugboard with a male and a > female D-Sub 52 connector. 3 rows of pins, 17-18-17. I took the > connectors off the board: there's nothing back there, so this thing only > ever existed so you could plug the random cable you found into it and its > friends to see what the cable fit. > > > That would be something like a DD-52P (certainly not a DB-52P!). > > I can't find much evidence that a 52-pin D-Sub ever existed. > > > Well, Digikey seem to have them: > > > http://www.digikey.com/product-detail/en/itt-cannon-llc/2DB-52P/2DB-52P-ND/4734668 > > No photo, though... > > -- Dave_______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Feb 28 14:12:25 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Feb 2020 15:12:25 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: On Thu, 27 Feb 2020, Lawrence Stewart wrote: > Huh.  New to me too, but Digikey links to the datasheets, and they > really do mean DB.They go up to DD100.  They are called “double > density”. No; the "B" in "DB" means B-sized e.g. the size of a DB-25 connector. This is a common mistake e.g. a "DB-9" (sic) would be a 25-pin sized connector holding just 9 pins (it's really a "DE-9") with godnoze-what spacing. Believe it or not there is a convention for it: http://en.wikipedia.org/wiki/D-subminiature Yes, it's one of my gripes... -- Dave From dave at horsfall.org Fri Feb 28 14:18:30 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Feb 2020 15:18:30 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: On Fri, 28 Feb 2020, Dave Horsfall wrote: >> Huh.  New to me too, but Digikey links to the datasheets, and they >> really do mean DB.They go up to DD100.  They are called “double >> density”. > > No; the "B" in "DB" means B-sized e.g. the size of a DB-25 connector. > This is a common mistake e.g. a "DB-9" (sic) would be a 25-pin sized > connector holding just 9 pins (it's really a "DE-9") with godnoze-what > spacing. Oops - I misread what you wrote; apologies... -- Dave From clemc at ccc.com Sat Feb 29 00:11:26 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2020 09:11:26 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: Adam/Dave, For whatever's it's worth, in PC/AT ISA bus times, at least one of the serial port vendors (RocketPort was the vendor IIRC), used a DB-52P connector, that connected to an interesting 'tail' which had 8 DB25P connected to the DB25-S at the other end. This allowed 6 data conductors (RCV/XMT/RTS/CTS/CD/DTR) * 8 ports, plus 6 grounds which again IIRC they interspersed among the remaining 6 ground pins. What I remember is that it was this specific board that was one of only a handful serial boards[1] that could run UNIX properly and hang Trailblazer modems off of it because they not only fully pinned, but they had single-chip custom USART with a good bit of buffering and hardware-based RTS/CTS flow control. I think I may still have one somewhere, as I saw the cable for it when I was looking for something else over the Christmas holidays. [1] The original PC/AT used the NS8250 UART with no input buffering, which went through a couple of generations, eventually begat the *550 version and had I think an 8 character input buffer. But IIRC none of them had hardware flow control. I forget the # now, Moto made a nice dual UART with 16 chars of input buffering, that many of us on Unix workstation business used, but when we moved to BSD 386 and Linux, we were stuck with PC hardware, which had a particularly hard time with things like the Trailblazer (which was the modem of choice for UUCP). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Feb 29 00:34:50 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 28 Feb 2020 07:34:50 -0700 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: A RocketPort multi-serial sounds really, really likely for an astrophysics data collection instrument. Thank you! Mystery probably solved! The 8250 was unbuffered or maybe had a 1 byte buffer, the 16450 had a 1-byte buffer, the 16550 had a 16-byte buffer. I remember vividly how much better my life got when I got 16550 serial ports for my '386. Adam On Fri, Feb 28, 2020 at 7:12 AM Clem Cole wrote: > Adam/Dave, > > For whatever's it's worth, in PC/AT ISA bus times, at least one of the > serial port vendors (RocketPort was the vendor IIRC), used a DB-52P > connector, that connected to an interesting 'tail' which had 8 DB25P > connected to the DB25-S at the other end. This allowed 6 data conductors > (RCV/XMT/RTS/CTS/CD/DTR) * 8 ports, plus 6 grounds which again IIRC they > interspersed among the remaining 6 ground pins. > > What I remember is that it was this specific board that was one of only a > handful serial boards[1] that could run UNIX properly and hang Trailblazer > modems off of it because they not only fully pinned, but they had > single-chip custom USART with a good bit of buffering and hardware-based > RTS/CTS flow control. I think I may still have one somewhere, as I saw the > cable for it when I was looking for something else over the Christmas > holidays. > > [1] The original PC/AT used the NS8250 UART with no input buffering, which > went through a couple of generations, eventually begat the *550 version and > had I think an 8 character input buffer. But IIRC none of them had > hardware flow control. I forget the # now, Moto made a nice dual UART > with 16 chars of input buffering, that many of us on Unix workstation > business used, but when we moved to BSD 386 and Linux, we were stuck with > PC hardware, which had a particularly hard time with things like the > Trailblazer (which was the modem of choice for UUCP). > > Clem > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Feb 29 02:35:04 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 28 Feb 2020 11:35:04 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> On 2/28/2020 9:11 AM, Clem Cole wrote: > > [1] The original PC/AT used the NS8250 UART with no input buffering, > which went through a couple of generations, eventually begat the *550 > version and had I think an 8 character input buffer.  But IIRC none of > them had hardware flow control.   I forget the # now, Moto made a nice > dual UART with 16 chars of input buffering, that many of us on Unix > workstation business used, but when we moved to BSD 386 and Linux, we > were stuck with PC hardware, which had a particularly hard time with > things like the Trailblazer  (which was the modem of choice for UUCP). > I ran a BBS for a few years back in the early 90's, and used a 486DX2-66 as my "front-end" to a Sun SPARC-IPC USENET setup. Using two V.34 and one Worldblazer, running them at 38,400 baud, and taking advantage of compression, it ran 100% download, 100% upload, or a combination across three modems without even showing much load at all. It could have easily taken more if I had the physical space (and the IRQs) on the ISA bus to add more serial ports. Of course, the interrupt coalescing of the 16550's helped a lot. And I don't know what the saturation point was... That was on x86 SVR4.2 (Consensys), using a shareware 16550 driver of the time. The Worldblazer talked to a Trailblazer at Motorola for my USENET feed and used G protocol, acceleration built into the Telebits. 8250's and 16540's were horrible. Much like DZ11's, eh? ;) art k. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 29 07:23:50 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 29 Feb 2020 08:23:50 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> Message-ID: On Fri, 28 Feb 2020, Adam Thornton wrote: > A RocketPort multi-serial sounds really, really likely for an > astrophysics data collection instrument.  Thank you!  Mystery probably > solved! I remember the RocketPort; we used to call it the OctopusPort... > The 8250 was unbuffered or maybe had a 1 byte buffer, the 16450 had a > 1-byte buffer, the 16550 had a 16-byte buffer.  I remember vividly how > much better my life got when I got 16550 serial ports for my '386. The 16550 series was an utter balls-up, with broken silos etc. This is from http://en.wikipedia.org/wiki/16550_UART : The original 16550 had a bug that prevented this FIFO from being used. National Semiconductor later released the 16550A which corrected this issue. Not all manufacturers adopted this nomenclature, however, continuing to refer to the fixed chip as a 16550. According to another source, the FIFO issue was corrected only in the 16550AF model, with the A model still being buggy. (The C and CF models are okay too, according to this source.) The 16550AFN model added DMA transfers. You had to pay careful attention to the manufacturer and the suffix. -- Dave From dave at horsfall.org Sat Feb 29 07:28:07 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 29 Feb 2020 08:28:07 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: On Fri, 28 Feb 2020, Arthur Krewat wrote: > 8250's and 16540's were horrible. Much like DZ11's, eh? ;) Hey, don't knock the DZ-11; if you used the right driver they worked just fine :-) The trick was to disable interrupts and empty the silos every so often. -- Dave From clemc at ccc.com Sat Feb 29 07:44:08 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2020 16:44:08 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: On Fri, Feb 28, 2020 at 4:28 PM Dave Horsfall wrote: > Hey, don't knock the DZ-11; if you used the right driver they worked just > fine :-) The trick was to disable interrupts and empty the silos every so > often. > DZ-11 sucked... for a number of reasons, the SW issue being just part of them, but they were short pinned and really did not do modems well, particularly high-speed ones like the Trailblazer. As you said, you could make them work, but why bother? Unix folks figure out the best idea was to use the Able DH/DM - cheaper, only one unibus slot for 16 ports (as opposed to 2 for the DZ), fully wired on the DB25 end, hardware flow control and just worked better in that is will DMA. What was not to love... On my long 'todo' list has been to work with Mark to get SIMH to properly support the DH in his emulation. He has some stuff in there, but last time I checked (about a year ago) it still was not right, which is a sort of a shame. FWIW: One of the guys behind DZ (who I will leave nameless) also screwed up the first serial port on the Masscomp MC/500 after he left DEC. I got there too late to fix it in the first version of the CPU board. So it was not fixed until I tore him a new one and educated him on how RS-232 actually worked (I was the first lead for the data com group as well as 1/2 the OS team). I never quite understood why HW folks often though of the serial port as '3-wires' -- sigh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 29 07:58:40 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 29 Feb 2020 08:58:40 +1100 (EST) Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: On Fri, 28 Feb 2020, Clem Cole wrote: > DZ-11 sucked... for a number of reasons, the SW issue being just part of > them, but they were short pinned and really did not do modems well, > particularly high-speed ones like the Trailblazer.  As you said, you > could make them work, but why bother? We used ours for local terminals only; 8 DZ-11s on the 11/70 worked fine (I don't recall how fast, but probably around 2400/4800). As I said, it came down to the driver. > Unix folks figure out the best idea was to use the Able DH/DM -  > cheaper, only one unibus slot for 16 ports (as opposed to 2 for the DZ), > fully wired on the DB25 end, hardware flow control and just worked > better in that is will DMA.  What was not to love... Sure, but then DEC Field Circus won't touch the box. > FWIW:  One of the guys behind DZ (who I will leave nameless) also > screwed up the first serial port on the Masscomp MC/500 after he left > DEC. I got there too late to fix it in the first version of the CPU > board.  So it was not fixed until I tore him a new one and educated him > on how RS-232 actually worked (I was the first lead for the data com > group as well as 1/2 the OS team).  I never quite understood why HW > folks often though of the serial port as '3-wires' -- sigh. Heh heh :-) I don't think I've ever seen RS-232 used "properly" i.e. implementing DSR/DTR or RTS/CTS for other than flow control etc, and using the secondary pins as well. -- Dave From drb at msu.edu Sat Feb 29 08:05:31 2020 From: drb at msu.edu (Dennis Boone) Date: Fri, 28 Feb 2020 17:05:31 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: (Your message of Sat, 29 Feb 2020 08:58:40 +1100.) References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: <20200228220532.17F741ADFAF@yagi.h-net.msu.edu> > using the secondary pins as well. Best I could tell, the major intended purpose of the secondary circuits was to implement autodialer, especially when those handshaking signals on the primary were down because there was no connection, so you couldn't do anything through them yet. Was there anything else in mind during the spec process? De From clemc at ccc.com Sat Feb 29 08:20:36 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2020 17:20:36 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: On Fri, Feb 28, 2020 at 4:58 PM Dave Horsfall wrote: > > Sure, but then DEC Field Circus won't touch the box. > That's not true. All our UNIX systems at UCB and CMU had DEC field service on them and we had lots of non-DEC HW, including memory, disk and disk controllers. Funny, the DEC knew we could swap memory chips on the National Semiconductor memory board for the Vax. Which we could not do with the DEC boards, they had to be swapped. The same was true at BTL, in fact and at Bell, there were DEC folks on-site. They might occasionally gripe, but we used to joke about it. It probably helped in all these places we had more than multiple systems and the field offices knew better. If we called, it was busted. > > Heh heh :-) I don't think I've ever seen RS-232 used "properly" i.e. > implementing DSR/DTR or RTS/CTS for other than flow control etc, and using > the secondary pins as well. Maybe you never saw a serial RJE station or I suspect a serial line that was fully synchronous running one of the IBM protocols. That was sort of where I started to learn in the late 1960s. I saw IBM systems before I saw the DEC ones and IBM used all the wires. Eventually, I got a copy of the wonderful DEC press book from John McNamara, called "Technical Aspects of Data Communications." Then I learned about UNIX, which came from AT&T which used all that stuff in their modems and data communications gear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Feb 29 08:26:51 2020 From: pechter at gmail.com (William Pechter) Date: Fri, 28 Feb 2020 17:26:51 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> Could it be because they all started with current loop tty interfaces? Most of the old DEC guys started with teletypes. Having struggled with a breakout box and different mini and micro vendors implementations of serial ports... Ugh. And in three-wire the use of Xon-Xoff varied big time. No standard was the standard. IIRC the IBM Series/1 had a different 9pin layout than the PC/AR. Why? At least DEC was reasonably consistent until they moved too the Vax modified RJ design. I am still amazed at the number of current loop DZ11s interfaced via 4 pin square phone jacks on a wall at the back of the machine room. Seemed like 100 lines of VTs and Dec writers at one hospital in 1985. As far as the DZ... One thing I saw at Dec to improve things was the Comm-iop DZ which managed the DZ from a KMC11 (IIRC). I think it was a CSS option on PDP11s.... Bill Sent from pechter at gmail.com -----Original Message----- From: Clem Cole To: Dave Horsfall Cc: Computer Old Farts Followers Sent: Fri, 28 Feb 2020 16:44 Subject: Re: [COFF] 52-pin D-Sub? On Fri, Feb 28, 2020 at 4:28 PM Dave Horsfall wrote: > Hey, don't knock the DZ-11; if you used the right driver they worked just > fine :-) The trick was to disable interrupts and empty the silos every so > often. > DZ-11 sucked... for a number of reasons, the SW issue being just part of them, but they were short pinned and really did not do modems well, particularly high-speed ones like the Trailblazer. As you said, you could make them work, but why bother? Unix folks figure out the best idea was to use the Able DH/DM - cheaper, only one unibus slot for 16 ports (as opposed to 2 for the DZ), fully wired on the DB25 end, hardware flow control and just worked better in that is will DMA. What was not to love... On my long 'todo' list has been to work with Mark to get SIMH to properly support the DH in his emulation. He has some stuff in there, but last time I checked (about a year ago) it still was not right, which is a sort of a shame. FWIW: One of the guys behind DZ (who I will leave nameless) also screwed up the first serial port on the Masscomp MC/500 after he left DEC. I got there too late to fix it in the first version of the CPU board. So it was not fixed until I tore him a new one and educated him on how RS-232 actually worked (I was the first lead for the data com group as well as 1/2 the OS team). I never quite understood why HW folks often though of the serial port as '3-wires' -- sigh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 29 08:28:14 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2020 17:28:14 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: <20200228220532.17F741ADFAF@yagi.h-net.msu.edu> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> <20200228220532.17F741ADFAF@yagi.h-net.msu.edu> Message-ID: On Fri, Feb 28, 2020 at 5:12 PM Dennis Boone wrote: > > using the secondary pins as well. > > Best I could tell, the major intended purpose of the secondary circuits > was to implement autodialer, especially when those handshaking signals > on the primary were down because there was no connection, so you > couldn't do anything through them yet. > The autodialer is a separate spec. It's ECMA RS-4xx something IIRC, I forget the number and I'm not near my books. That was the DN-11 from DEC which talked to an AT&T 801 dialer. It used RS-232C electrical signals, but it's actually different than RS-232C (IIRC, Able called them a 'QuadraCall'). The way auto-dialing is spec'ed, is that a single dialer supports N modems. The Out-Band dialing stuff was an invention of Hayes who clearly had not read the AT&T (later ECMA) spec. > > Was there anything else in mind during the spec process? > RJE stations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 29 08:36:20 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2020 17:36:20 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> Message-ID: below... On Fri, Feb 28, 2020 at 5:26 PM William Pechter wrote: > Could it be because they all started with current loop tty interfaces? > Most of the old DEC guys started with teletypes. > Very possible... > > Having struggled with a breakout box and different mini and micro vendors > implementations of serial ports... Ugh. And in three-wire the use of > Xon-Xoff varied big time. No standard was the standard. IIRC the IBM > Series/1 had a different 9pin layout than the PC/AR. Why? > RS-232A/B/C was DB-25 P for the DTE (terminating equiment - a.k.a. terminal) and S for DCE (communications equipment - a.k.a. modem). It was standardized. At one time, I (sadly) could quote the paragraph number.... Then in 1978 #$%^& Lear Seglier put a DB-25S on a DTE (terminal). They were the cheap terminal vendor and all hell broke loose. The PC/AT used 9 pin because the back of the unit was small and -- well there could because IBM said so .... But at least the IBM engineers kept to Plug and Sockets from the standard. I did not know the Series/1 used 9 pin. Learn something new. > At least DEC was reasonably consistent until they moved too the Vax > modified RJ design. > Indeed - that was a huge issue - the modified RJ block -- sigh... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Feb 29 08:38:03 2020 From: pechter at gmail.com (William Pechter) Date: Fri, 28 Feb 2020 17:38:03 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: Actually Dec would take the stuff on contract in the mid to late 80s. They went hard on customer service retention and came up with a third party mauntenance plan on stuff like Emulex controllers, CDC976x drives... etc. Not sure if the Able was in the plan. Had to do with diags and parts availability. I have some personal experience in the area, but I don't know if I can post it... Too many war stories before Dec lost the war for survival. The view from field service was fascinating including non-mergers with AT&T around 1984 and almost an outsource of the Bell Labs data centers to DEC in. 1984. Bill Sent from pechter at gmail.com -----Original Message----- From: Dave Horsfall To: Computer Old Farts Followers Sent: Fri, 28 Feb 2020 16:58 Subject: Re: [COFF] 52-pin D-Sub? On Fri, 28 Feb 2020, Clem Cole wrote: > DZ-11 sucked... for a number of reasons, the SW issue being just part of > them, but they were short pinned and really did not do modems well, > particularly high-speed ones like the Trailblazer. As you said, you > could make them work, but why bother? We used ours for local terminals only; 8 DZ-11s on the 11/70 worked fine (I don't recall how fast, but probably around 2400/4800). As I said, it came down to the driver. > Unix folks figure out the best idea was to use the Able DH/DM - > cheaper, only one unibus slot for 16 ports (as opposed to 2 for the DZ), > fully wired on the DB25 end, hardware flow control and just worked > better in that is will DMA. What was not to love... Sure, but then DEC Field Circus won't touch the box. > FWIW: One of the guys behind DZ (who I will leave nameless) also > screwed up the first serial port on the Masscomp MC/500 after he left > DEC. I got there too late to fix it in the first version of the CPU > board. So it was not fixed until I tore him a new one and educated him > on how RS-232 actually worked (I was the first lead for the data com > group as well as 1/2 the OS team). I never quite understood why HW > folks often though of the serial port as '3-wires' -- sigh. Heh heh :-) I don't think I've ever seen RS-232 used "properly" i.e. implementing DSR/DTR or RTS/CTS for other than flow control etc, and using the secondary pins as well. -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Feb 29 09:22:58 2020 From: pechter at gmail.com (William Pechter) Date: Fri, 28 Feb 2020 18:22:58 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: The John McNamara book still seems to be around. Great reading. I worked for DEC in Monmouth and Mercer counties and one night stole all the Vax 11/780 kits from DEC Holmdel. Boy were they pissed. However, I had a critical outage at the FBI at Fort Monmouth with two hour response so I didn't drive an hour to my Princeton office. 8-) I had Holmel's keys and alarm codes so I left them an IOU and headed to the site. Holmdel was 15 minutes from the site but their techs were dedicated to telco only... So their parts took a trip. The DEC folks at the labs and AT&T sites were treated like royalty compared with us regular commercial business groups. They had the best training... newest machines... If they found a pdp8 or 11/23 and had repair issues - - they had us called. We saw more wierd like the Vax 11/782 that couldn't back up because it was sold without enough memory in the main (or attached cpu) to run standalone backup. I had to go in on Saturday to move a memory board between CPUs. I think Field Service donated a board to RCA Semi finally. That was a dumb machine design. I spent years with a lot of computer companies and RS232 interfaces were easy as long as there was only one vendor. If you see how Pr1me or Hewlett Packard dealt with the serial ports... I used to be the guy who at the most desperate would get Kermit over a 3 wire interface to allow data transfer between different systems. Or UUCP on ms-dos... Something about jack of all trades. Bill Sent from pechter at gmail.com -----Original Message----- From: Clem Cole To: Dave Horsfall Cc: Computer Old Farts Followers Sent: Fri, 28 Feb 2020 17:21 Subject: Re: [COFF] 52-pin D-Sub? On Fri, Feb 28, 2020 at 4:58 PM Dave Horsfall wrote: > > Sure, but then DEC Field Circus won't touch the box. > That's not true. All our UNIX systems at UCB and CMU had DEC field service on them and we had lots of non-DEC HW, including memory, disk and disk controllers. Funny, the DEC knew we could swap memory chips on the National Semiconductor memory board for the Vax. Which we could not do with the DEC boards, they had to be swapped. The same was true at BTL, in fact and at Bell, there were DEC folks on-site. They might occasionally gripe, but we used to joke about it. It probably helped in all these places we had more than multiple systems and the field offices knew better. If we called, it was busted. > > Heh heh :-) I don't think I've ever seen RS-232 used "properly" i.e. > implementing DSR/DTR or RTS/CTS for other than flow control etc, and using > the secondary pins as well. Maybe you never saw a serial RJE station or I suspect a serial line that was fully synchronous running one of the IBM protocols. That was sort of where I started to learn in the late 1960s. I saw IBM systems before I saw the DEC ones and IBM used all the wires. Eventually, I got a copy of the wonderful DEC press book from John McNamara, called "Technical Aspects of Data Communications." Then I learned about UNIX, which came from AT&T which used all that stuff in their modems and data communications gear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Feb 29 09:40:21 2020 From: pechter at gmail.com (William Pechter) Date: Fri, 28 Feb 2020 18:40:21 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> Message-ID: <39399593-4023-4e44-9bb5-2139183cce84.maildroid@localhost> Most of the RS232 spec seemed to be designed for Sync modems and their management. Most machines of the mini generation seemed to use either Async or Sync interfaces. Stuff like the VT180 had a comm port that was a 8251 USART for serial comm that could be either sync or async. I don't believe Dec had anything like that in that PDP11 or early Vax days. Anyone care to enlighten me? Bill Sent from pechter at gmail.com -----Original Message----- From: Clem Cole To: William Pechter Cc: Computer Old Farts Followers Sent: Fri, 28 Feb 2020 17:36 Subject: Re: [COFF] 52-pin D-Sub? below... On Fri, Feb 28, 2020 at 5:26 PM William Pechter wrote: > Could it be because they all started with current loop tty interfaces? > Most of the old DEC guys started with teletypes. > Very possible... > > Having struggled with a breakout box and different mini and micro vendors > implementations of serial ports... Ugh. And in three-wire the use of > Xon-Xoff varied big time. No standard was the standard. IIRC the IBM > Series/1 had a different 9pin layout than the PC/AR. Why? > RS-232A/B/C was DB-25 P for the DTE (terminating equiment - a.k.a. terminal) and S for DCE (communications equipment - a.k.a. modem). It was standardized. At one time, I (sadly) could quote the paragraph number.... Then in 1978 #$%^& Lear Seglier put a DB-25S on a DTE (terminal). They were the cheap terminal vendor and all hell broke loose. The PC/AT used 9 pin because the back of the unit was small and -- well there could because IBM said so .... But at least the IBM engineers kept to Plug and Sockets from the standard. I did not know the Series/1 used 9 pin. Learn something new. > At least DEC was reasonably consistent until they moved too the Vax > modified RJ design. > Indeed - that was a huge issue - the modified RJ block -- sigh... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Feb 29 09:54:07 2020 From: pechter at gmail.com (William Pechter) Date: Fri, 28 Feb 2020 18:54:07 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> Message-ID: <1659761b-de63-4eca-a4f0-fc36159a65c7.maildroid@localhost> One thought I had for the 52 pin D-sub were the two 50 pin Pertec tape interface cables in some "cabinet kit" packaging for under floor. Saw this at Fort Monmouth Cecom on an 11/750 from a military project for early office automation on System V Unix based off of 2.x Unix work at Hanscom AFB called Lonex (if I remember the acronym). Bill Sent from pechter at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Sat Feb 29 19:59:29 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sat, 29 Feb 2020 16:59:29 +0700 Subject: [COFF] 52-pin D-Sub? Message-ID: Not UNIX, not 52-pin, but old, old and serial Your mission, should you choose to accept it, is to save data from a computer that should have died aeons ago ... Tap into the serial line – what could be simpler? Alas, the TI was smart enough to spot the absence of the rattly old beast ("the software wouldn't print without some of the seldom-used serial control lines functioning," explained Aaron) so the customer was asked to bring in the printer as well. https://www.theregister.co.uk/2020/02/24/who_me/ From emu at e-bbes.com Sat Feb 29 23:12:58 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Sat, 29 Feb 2020 08:12:58 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> Message-ID: On 2020-02-28 18:22, William Pechter wrote: > I used to be the guy who > at the most desperate would get Kermit over a 3 wire interface to allow > data transfer between different systems.  Or UUCP on ms-dos... > > Something about jack of all trades. Kermit seems to be or was(?) the Swiss army knife of communications. Or the 9-track tape ... ;-)