From krewat at kilonet.net Sun Mar 1 01:45:05 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 29 Feb 2020 10:45:05 -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 2/29/2020 8:12 AM, emanuel stiebler wrote: > 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 ... > ;-) > > You technically haven't lived until you use an acoustic coupler, a cassette tape recorder and a wire tap to record 300 baud modem tones as you type out files on a PDP-10 somewhere... And then play that tape back to your own computer and that same modem, and save it to floppy. It's how I saved LOGO.MAC from somewhere on the ARPANET back in the early-to-mid 80's. ;) art k. From clemc at ccc.com Sun Mar 1 01:49:11 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Feb 2020 10:49:11 -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 Sat, Feb 29, 2020 at 10:45 AM Arthur Krewat wrote: > > You technically haven't lived until you use an acoustic coupler, a > cassette tape recorder and a wire tap to record 300 baud modem tones as > you type out files on a PDP-10 somewhere... > > And then play that tape back to your own computer and that same modem, > and save it to floppy. > And we thought that was so cool and high tech in those days ..... particularly using 30 cps vs 10 cps of the ASR33. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Mar 1 02:52:58 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Feb 2020 11:52:58 -0500 Subject: [COFF] 52-pin D-Sub? In-Reply-To: <39399593-4023-4e44-9bb5-2139183cce84.maildroid@localhost> References: <905CE999-5601-4521-847B-B2146C60B564@serissa.com> <6a44c9e7-1e7b-bd0e-df1c-6e2208e8b780@kilonet.net> <6108e507-1dc2-4b09-9121-48c2727513cf.maildroid@localhost> <39399593-4023-4e44-9bb5-2139183cce84.maildroid@localhost> Message-ID: On Fri, Feb 28, 2020 at 6:40 PM William Pechter wrote: > 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? > I know some of the story having known some of the players and lived a little of it, but I do not claim to know all of it. So I might be able to fill in some holes, but there is still plenty missing from the complete story. First, remember RS-232 is an ECMA spec for connecting communication gear to data gear. It's not so much about sync/async as it dealing with the phone systems in the US and Europe and how to interface computer gear to it. The driver of the spec was building and connecting RJE-like systems for banks and financial institutions, airline terminals, *etc*. to connect to a central (mainframe) computer. This is why it uses terms like "Data Communications Equipment" and "Data Terminating Equipment" - as opposed to modems, computer terminals, hosts and the like. Different systems vendors had different ways of thinking about the computer they were selling and how people would interface with them. And you can see the differences in the choices they make in gear like the peripherals that they interface at the time. The AT&T Teletype Model 28 (https://en.wikipedia.org/wiki/Teletype_Model_28 circa 1953 intro, 5-bit BAUDOT code, current loop) was the standard terminal on DEC systems for many years. Gordon Bell invented (patented) the UART to talk to it for the PDP-1 (maybe it was the PDP-6) sometime in the early 1960s. What I do not know/understand is what was the work he did at DEC and what when he had left to be a CMU prof. I was >>under the impression<< the patent was granted during his CMU time; but I had thought DEC originally built them as FLIP-CHIPS for the PDP-6. Then in 1963, 7-bit ASCII was introduced. IBM and AT&T were to two biggest firms behind it (remember that the IBM System 360 was supposed to be an ASCII system and has a lot of support for ASCII in its ISA; but due to the OS SW being late that stayed with their earlier BCD – creating EBCDIC - read Fred Brook's "The Mythical Man-Month " for the details). However AT&T, GE and DEC did switch to 7-bit ASCII pretty much as soon as they could. The AT&T/Teletype Model-33 ( https://en.wikipedia.org/wiki/Teletype_Model_33 circa 1963 intro, 7 bit ASCII code/current loop, but lacked shift key on the keyboard) was introduced soon thereafter and that became the standard terminal (7-bit byte, plus parity and 3 bits worth of start/stop -- 11 serial bits per transmission). My memory is that AT&T did not make sell an ECMA RS-232 version, but the aftermarket had a ton of converters between the current loop interface at the ECMA standard. So at the time, you have IBM using primarily synchronous interfaces, while AT&T (Teletype) used asynchronous. IBM liked sync because of the fact that it needed no wasted start/stop bits. They liked 1/2 duplex because their devices were primarily going one way at a time. In the 60s, IBM's big business has them connecting RJE stations and they would only much later do 1/2 duplex synchronous* terminals*. DEC was more interactive much sooner, used Teletype's and thus was async and full-duplex. I was also under the impression (*i.e.* once was told) that Western Digital obtained a license to make the UART as chips but it was never completely clear to me who held the patent (CMU or DEC) *i.e.* who/how WD got the license from. But after the chips appeared, DEC would buy those chips from WD for things like the DL/KL-11's and DH-11 interfaces and I think they made something like the DL11 for the PDP-8. If you look at the schematics for the early serial ports for the PDP-11, they are all using the same WD chip. Soon after the UART, WD also starts making a USRT, which (the best I can tell) they seem to be selling to IBM and the com vendors for IBM gear. I personally never programmed them, but they are in an old WD book I once had (may still). I remember seeing them in some Gandalf gear in the mid-70s besides the IBM gear, but I don't known/remember much more. In the early 1970s, CMU used the same WD UART chips as DEC was using in the DL-11, but had designed their own serial board, which we called the ASLI (there were other differences but mostly the SW could not tell the difference). Nat Semi was a second source for WD at some point in the late 1960s, and by the early 1970s, they started to design there own UART (as was pointed out eventually they created 8250 and it's follow ons). I'm not sure when Intel and Moto started to make them, but I think both the 8080 and 6800 families had UARTs chips. MOS Tech did not originally, although later when Rockwell became their second source, a UART for that family appeared too. At some point in the early 1970s, the first USARTs start to appear. I was under the impression, WD was the origin of them, but I do not know. By the time of the 16-bit micros, however, many of the better serial interface chips could be either synchronous or asynchronous under program control. With the 16-bit chips, a Zilog USART chip was fairly popular at one point from Macs to UNIX boxes. As other pointed out, because of the PC/AT the Nat Semi 8250 stuck around as it had ended up are part of the 'PC support chip family', even though it was a bit of dog and notorious for dropping characters at high speeds. For completeness, the Unix folks at BTL used the Teletype Model 37 ( https://en.wikipedia.org/wiki/Teletype_Model_37 ß 1968 intro, 7 bit ASCII code, full U/L case ) as their native printing terminal. IIRC the ASR-37 had an RS-232C option as well as a current loop one from Teletype as the industry had pretty much dropped off of the current loop standard by then. Interesting side note, the AT&T/BTL programmers often did not have 'hardwired' lines in their offices, but used modem (there was the phone company of course). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mylists at posteo.de Mon Mar 2 02:42:56 2020 From: mylists at posteo.de (mylists at posteo.de) Date: Sun, 1 Mar 2020 17:42:56 +0100 Subject: [COFF] some PDP11 stuff Message-ID: <20200301164256.mqi5km4xes3lx5oo@solfire> Hi, while exploring the gopherspace (YES! Still existing, growing community) I found this gopher page: gopher://pdp11.tk/1 which can be reached with Lynx for example. Unfortunately I cannot evaluate the items there, but may be it is worth a look by someone knowledgeable. Cheers! mcc From pechter at gmail.com Mon Mar 2 13:19:43 2020 From: pechter at gmail.com (William Pechter) Date: Sun, 1 Mar 2020 22:19:43 -0500 Subject: [COFF] some PDP11 stuff In-Reply-To: <20200301164256.mqi5km4xes3lx5oo@solfire> References: <20200301164256.mqi5km4xes3lx5oo@solfire> Message-ID: Reachable and download able through Android Chrome. Raspberry Pi Gopher space. Amazing. Like HECnet... Some folks appreciate Retro computing. Bill Sent from pechter at gmail.com -----Original Message----- From: mylists at posteo.de To: coff at minnie.tuhs.org Sent: Sun, 01 Mar 2020 18:44 Subject: [COFF] some PDP11 stuff Hi, while exploring the gopherspace (YES! Still existing, growing community) I found this gopher page: gopher://pdp11.tk/1 which can be reached with Lynx for example. Unfortunately I cannot evaluate the items there, but may be it is worth a look by someone knowledgeable. Cheers! mcc _______________________________________________ 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 Mar 4 13:49:25 2020 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 4 Mar 2020 13:49:25 +1000 Subject: [COFF] 21st Century Equivalent to 'learn'? Message-ID: <20200304034925.GA18809@minnie.tuhs.org> Hi all, I'm looking for an interactive tool to help students learn the Unix/Linux command line. I still remember the "learn" tool. Is there an equivalent for current systems? I have tried to forward-port the old learn sources to current Linux but my patience ran out :-) Thanks in advance for any tips/pointers. Cheers, Warren From spedraja at gmail.com Wed Mar 4 16:23:27 2020 From: spedraja at gmail.com (Sergio Pedraja) Date: Wed, 4 Mar 2020 07:23:27 +0100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200304034925.GA18809@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: Hi/Morning from my location. Are the sources of 'learn' available? I doubt I could help but just in case... Have a Good Day. Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja El mié., 4 mar. 2020 4:49, Warren Toomey escribió: > Hi all, I'm looking for an interactive tool to help students learn the > Unix/Linux command line. I still remember the "learn" tool. Is there an > equivalent for current systems? > > I have tried to forward-port the old learn sources to current Linux but > my patience ran out :-) > > Thanks in advance for any tips/pointers. > > 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 thomas.paulsen at firemail.de Wed Mar 4 16:55:15 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 04 Mar 2020 07:55:15 +0100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: <37c0b233fddb7e745cf9bb2d7be3ed77@firemail.de> An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Mar 4 19:53:04 2020 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 4 Mar 2020 19:53:04 +1000 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: <20200304095304.GA30901@minnie.tuhs.org> On Wed, Mar 04, 2020 at 07:23:27AM +0100, Sergio Pedraja wrote: > Are the sources of 'learn' available? I doubt I could help but just in > case... Yes, online here: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/learn https://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenBSD-4.6/usr.bin/learn and also in several of the 4BSD versions. Cheers, Warren From dave at horsfall.org Thu Mar 5 05:31:24 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 5 Mar 2020 06:31:24 +1100 (EST) Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200304034925.GA18809@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: On Wed, 4 Mar 2020, Warren Toomey wrote: > Hi all, I'm looking for an interactive tool to help students learn the > Unix/Linux command line. I still remember the "learn" tool. Is there an > equivalent for current systems? Knowing Penguin/OS bloatware there's probably a multi-GB GUI that will do the same job as will a simple C program and a structured directory hierarchy... Or perhaps there's always "info" :-) -- Dave From wkt at tuhs.org Thu Mar 5 11:00:21 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 5 Mar 2020 11:00:21 +1000 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200304034925.GA18809@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: <20200305010021.GA23129@minnie.tuhs.org> On Wed, Mar 04, 2020 at 01:49:25PM +1000, Warren Toomey wrote: > Hi all, I'm looking for an interactive tool to help students learn the > Unix/Linux command line. I still remember the "learn" tool. Is there an > equivalent for current systems? > Thanks in advance for any tips/pointers. I've made a start with a new version of a "learn"ing tool. It uses tmux to have a pane of instructions and a pane where the user enters commands. Link to the repo is: https://github.com/DoctorWkt/tlearn/blob/master/tlearn This is all protoyping at present. I'd love any ideas & suggestions. Cheers, Warren From jpl.jpl at gmail.com Thu Mar 5 22:43:59 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 5 Mar 2020 07:43:59 -0500 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200305010021.GA23129@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> Message-ID: Marc Rochkind used to recommend reading the entire UNIX manual each year. That was good advice in the late 70's, but it would be hopelessly impractical now, quite beyond the lack of a manual to read. There are just too many commands and libraries. A valuable service would be to identify the most useful tools. Those in the old manuals would be an interesting starting point, but I can't remember when I last used "ar" command, which I mostly used to pack multiple files into a single one to save inodes and wasted file system space, neither of which matter any more. If there were a corpus of contemporary shell scripts, identifying the most used commands could be interesting. Perl's CPAN (comprehensive perl archive network) could be a corpus of scripts from which the most commonly used system calls could be extracted. On Wed, Mar 4, 2020 at 8:00 PM Warren Toomey wrote: > On Wed, Mar 04, 2020 at 01:49:25PM +1000, Warren Toomey wrote: > > Hi all, I'm looking for an interactive tool to help students learn the > > Unix/Linux command line. I still remember the "learn" tool. Is there an > > equivalent for current systems? > > Thanks in advance for any tips/pointers. > > I've made a start with a new version of a "learn"ing tool. It uses tmux > to have a pane of instructions and a pane where the user enters commands. > Link to the repo is: > https://github.com/DoctorWkt/tlearn/blob/master/tlearn > > This is all protoyping at present. I'd love any ideas & 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 arrigo at alchemistowl.org Fri Mar 6 07:23:31 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Thu, 5 Mar 2020 22:23:31 +0100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: Message-ID: Someone (sorry, lost the message by deleting it and discovered I don't archive COFF...) mentioned that "learn" is still around in BSDs but I didn't find it in either FreeBSD or OpenBSD (base or packages). Where should I look? Or was it a "compile it off 4.4BSD”? Cheers, Arrigo From grog at lemis.com Fri Mar 6 13:14:12 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 6 Mar 2020 14:14:12 +1100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: Message-ID: <20200306031412.GF85938@eureka.lemis.com> On Thursday, 5 March 2020 at 22:23:31 +0100, Arrigo Triulzi wrote: > Someone (sorry, lost the message by deleting it and discovered I > don't archive COFF...) mentioned that "learn" is still around in BSDs > but I didn't find it in either FreeBSD or OpenBSD (base or > packages). Where should I look? Or was it a "compile it off > 4.4BSD???? Interesting. I took a quick look around my (FreeBSD) machine and located a directory /home/src/OpenBSD/3.0-RELEASE/usr.bin/learn/, dating from October 2001. It no longer compiles with clang, but a quick attempt with gcc and without (clang) default flags at least produces object files. I've put a tarball at http://www.lemis.com/grog/src/learn.tar 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 Fri Mar 6 13:39:41 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 5 Mar 2020 19:39:41 -0800 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200305010021.GA23129@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> Message-ID: <1B8EF430-1CC5-4E49-9E98-BD0710BAA093@bitblocks.com> On Mar 4, 2020, at 5:00 PM, Warren Toomey wrote: > > On Wed, Mar 04, 2020 at 01:49:25PM +1000, Warren Toomey wrote: >> Hi all, I'm looking for an interactive tool to help students learn the >> Unix/Linux command line. I still remember the "learn" tool. Is there an >> equivalent for current systems? >> Thanks in advance for any tips/pointers. > > I've made a start with a new version of a "learn"ing tool. It uses tmux > to have a pane of instructions and a pane where the user enters commands. > Link to the repo is: https://github.com/DoctorWkt/tlearn/blob/master/tlearn > > This is all protoyping at present. I'd love any ideas & suggestions. I am tempted to suggest something like a Jupyter notebook, sort of a manpage where examples can be modified or run interactively. That is, even the learning instructions can become manpages that can be referenced later even. May be some of that can become new intro! From akosela at andykosela.com Fri Mar 6 19:10:36 2020 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 06 Mar 2020 10:10:36 +0100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> Message-ID: <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> "John P. Linderman" wrote: > Marc Rochkind used to recommend reading the entire UNIX manual each year. > That was good advice in the late 70's, but it would be hopelessly > impractical now, quite beyond the lack of a manual to read. There are just > too many commands and libraries. A valuable service would be to identify > the most useful tools. Those in the old manuals would be an interesting > starting point, but I can't remember when I last used "ar" command, which I > mostly used to pack multiple files into a single one to save inodes and > wasted file system space, neither of which matter any more. If there were a > corpus of contemporary shell scripts, identifying the most used commands > could be interesting. Perl's CPAN (comprehensive perl archive network) > could be a corpus of scripts from which the most commonly used system calls > could be extracted. I compiled such a list a couple of years ago. Most of those commands should be available on every major flavor of Unix and I consider them "the core Unix tools". This is not a final list, but commands I personally use most often. Certainly you can't call yourself a Unix user if you have never consulted their manuals. as, at, awk, basename, bc, cal, cat, cc, chmod, chown, cp, cut, date, dc, dd, df, diff, du, env, expr, false, find, fmt, free, gdb, grep, gzip, head, hexdump, id, iostat, join, ld, ldd, less, ln, ls, man, md5sum, mkdir, mkfifo, mv, nice, nl, nohup, od, patch, passwd, paste, pgrep, pkill, ps, pstree, rev, rm, rmdir, script, sed, seq, sh, sha256sum, shuf, shutdown, size, sleep, sort, split, stat, strip, strings, stty, su, sum, sysctl, tac, tar, tail, tee, top, touch, tr, tree, uname, uniq, uptime, vmstat, w, wc, whatis, whereis, which, who, whoami, xargs, yes I specifically excluded all shell builtin commands and core network related tools like ping(8). It is interesting to note that still most of them come from the earliest Unix versions. It shows the ingenuity and beauty of the original design. --Andy From dave at horsfall.org Sun Mar 8 07:50:01 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 8 Mar 2020 08:50:01 +1100 (EST) Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> Message-ID: On Fri, 6 Mar 2020, Andy Kosela wrote: [ List elided ] What do you have against "cpio"? Admittedly it's harder to use than "tar" but I still come across it from time to time; also, "tar" had a bug at one time whereby it did not handle an empty directory, and I think there was a problem with devices/sockets as well. Heck, I still have "cpio -adplumv" burned into my retinas. -- Dave From clemc at ccc.com Sun Mar 8 08:05:52 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 7 Mar 2020 17:05:52 -0500 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> Message-ID: Dave -- please, let's not re-live 'tar-wars' -- it's why the POSIX command is called 'pax' - God Bless USENIX for funding the original implementation and putting it in the public domain. - tar was research/BSD and worked best when you chdir to some directory and were working interactively and was the logic follow on to the earlier stp and tp. It was ASCII and after the binary issues of tp was a welcome relief. The format was also extensible (thanks to bug in the original implementation). - cpio was USG and worked best with a find(1) script/automation - which was good for controlled distributions but poor for interactive use. It was also binary originally (with PDP-11isms builtin) The real issue in the end was cpio being part of System III many/most universities did not have it originally, so the tp/stp was what we used, which was replaced by tar. pax has a user interface that work either ways, and the USENIX public implementation can read both tape formats.. Clem PS At Masscomp, I once wrote "car" but no one ever wrote "tpio". On Sat, Mar 7, 2020 at 4:50 PM Dave Horsfall wrote: > On Fri, 6 Mar 2020, Andy Kosela wrote: > > [ List elided ] > > What do you have against "cpio"? Admittedly it's harder to use than "tar" > but I still come across it from time to time; also, "tar" had a bug at one > time whereby it did not handle an empty directory, and I think there was a > problem with devices/sockets as well. > > Heck, I still have "cpio -adplumv" burned into my retinas. > > -- 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 dfawcus+lists-coff at employees.org Sun Mar 8 09:02:31 2020 From: dfawcus+lists-coff at employees.org (Derek Fawcus) Date: Sat, 7 Mar 2020 23:02:31 +0000 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> Message-ID: <20200307230231.GA37894@clarinet.employees.org> On Sat, Mar 07, 2020 at 05:05:52PM -0500, Clem Cole wrote: > Dave -- please, let's not re-live 'tar-wars' -- it's why the POSIX > command is called 'pax' - God Bless USENIX for funding the original > implementation and putting it in the public domain. [snip] > pax has a user interface that work either ways, and the USENIX public > implementation can read both tape formats.. > > Clem > > PS At Masscomp, I once wrote "car" but no one ever wrote "tpio". and now we have xar (https://en.wikipedia.org/wiki/Xar_%28archiver%29), since obviously everything can be improved by a dose of XML ! ;-) DF From clemc at ccc.com Sun Mar 8 10:02:10 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 7 Mar 2020 19:02:10 -0500 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200307230231.GA37894@clarinet.employees.org> References: <20200304034925.GA18809@minnie.tuhs.org> <20200305010021.GA23129@minnie.tuhs.org> <5e62138c.u8jVz6HNyEAN5KpZ%akosela@andykosela.com> <20200307230231.GA37894@clarinet.employees.org> Message-ID: It's worse than just being XML. The whole idea of tar and cpio was to fix the problem tp/stp had of putting the catalog at the front of the tape (archive) and thread the directory through out it. Sigh... if you don't learn from history, you are destined to repeat iot. On Sat, Mar 7, 2020 at 6:12 PM Derek Fawcus < dfawcus+lists-coff at employees.org> wrote: > On Sat, Mar 07, 2020 at 05:05:52PM -0500, Clem Cole wrote: > > Dave -- please, let's not re-live 'tar-wars' -- it's why the POSIX > > command is called 'pax' - God Bless USENIX for funding the original > > implementation and putting it in the public domain. > > [snip] > > > pax has a user interface that work either ways, and the USENIX public > > implementation can read both tape formats.. > > > > Clem > > > > PS At Masscomp, I once wrote "car" but no one ever wrote "tpio". > > and now we have xar (https://en.wikipedia.org/wiki/Xar_%28archiver%29), > since obviously everything can be improved by a dose of XML ! ;-) > > DF > _______________________________________________ > 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 rudi.j.blom at gmail.com Sun Mar 8 13:39:25 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 8 Mar 2020 10:39:25 +0700 Subject: [COFF] 21st Century Equivalent to 'learn'? Message-ID: I started using 'cpio' in the 80tish and still use it, especially transferring files and complete directories between various UNIX versions like SCOUNIX 3.2V4.2, Tru64, HP-UX 11i.. The main option I use with cpio is (of course) "-c" and only occasionally "-u" From peter at rulingia.com Mon Mar 9 06:22:30 2020 From: peter at rulingia.com (Peter Jeremy) Date: Mon, 9 Mar 2020 07:22:30 +1100 Subject: [COFF] Old non-Unix software and manuals. Message-ID: <20200308202230.GB3091@server.rulingia.com> As many of you may be aware, Bruce D. Evans died in mid-December. I am currently looking through his digital estate on behalf of his family and the FreeBSD Project. I have discovered that he kept an extensive collection of 5¼" floppy disks. I haven't looked through them but they appear to include things like OS-9 and Hitachi Peach files (and presumably Minix stuff, though I haven't found any of his Minix work). He also has a selection of newletters from an Australian Peach users group. Is there any interest in this material from a historicial perspective? -- 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 krewat at kilonet.net Mon Mar 9 06:30:06 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 8 Mar 2020 16:30:06 -0400 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308202230.GB3091@server.rulingia.com> References: <20200308202230.GB3091@server.rulingia.com> Message-ID: My take on it: It all needs to be preserved. Whether or not it's public, that's up to his estate. Yes, I am a data-horder. On 3/8/2020 4:22 PM, Peter Jeremy wrote: > As many of you may be aware, Bruce D. Evans died in > mid-December. I am currently looking through his digital estate on > behalf of his family and the FreeBSD Project. > > I have discovered that he kept an extensive collection of 5¼" floppy > disks. I haven't looked through them but they appear to include > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > though I haven't found any of his Minix work). He also has a > selection of newletters from an Australian Peach users group. Is > there any interest in this material from a historicial perspective? > > > _______________________________________________ > 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 imp at bsdimp.com Mon Mar 9 06:34:01 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 8 Mar 2020 14:34:01 -0600 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308202230.GB3091@server.rulingia.com> References: <20200308202230.GB3091@server.rulingia.com> Message-ID: On Sun, Mar 8, 2020, 2:22 PM Peter Jeremy wrote: > As many of you may be aware, Bruce D. Evans died in > mid-December. I am currently looking through his digital estate on > behalf of his family and the FreeBSD Project. > > I have discovered that he kept an extensive collection of 5¼" floppy > disks. I haven't looked through them but they appear to include > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > though I haven't found any of his Minix work). He also has a > selection of newletters from an Australian Peach users group. Is > there any interest in this material from a historicial perspective? > I can image just about any 5 1/4 disk. Warner -- > Peter Jeremy > _______________________________________________ > 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 michael at kjorling.se Mon Mar 9 07:16:40 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 8 Mar 2020 21:16:40 +0000 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308202230.GB3091@server.rulingia.com> References: <20200308202230.GB3091@server.rulingia.com> Message-ID: On 9 Mar 2020 07:22 +1100, from peter at rulingia.com (Peter Jeremy): > I have discovered that he kept an extensive collection of 5¼" floppy > disks. I haven't looked through them but they appear to include > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > though I haven't found any of his Minix work). He also has a > selection of newletters from an Australian Peach users group. Is > there any interest in this material from a historicial perspective? Suppose that we say no, there is no interest in the material. The upside is that it'll be less work in the short term; the downside seems to be the possible loss of actual interesting material. Suppose that we say yes, there is at least potential interest (now or later) in the material. The downside is that it'll take some work to process once; the upside is that _if_ it turns out to be of interest, even if we can't see that interest now, then the material will be available or at least preserved somewhere. _I would say YES, it should be preserved._ Far too many computer historical artefacts have been lost to various trash containers over the decades because people didn't envision at the time how they might be of interest later. Just consider: back in the 1970s, who'd have thought that a sales department printout of minicomputers and corresponding peripherals would be of any interest whatsoever upwards of half a century later? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From wobblygong at gmail.com Mon Mar 9 08:32:51 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 9 Mar 2020 11:32:51 +1300 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308202230.GB3091@server.rulingia.com> References: <20200308202230.GB3091@server.rulingia.com> Message-ID: I'm in favour of preserving both the software and the newsletters. History _is_ important, and knowledge of history doubly so when you have predatory IPR scavengers on the loose, as we saw in the infamous The SCO Group versus Linux and the World case. Wesley Parish On 3/9/20, Peter Jeremy wrote: > As many of you may be aware, Bruce D. Evans died in > mid-December. I am currently looking through his digital estate on > behalf of his family and the FreeBSD Project. > > I have discovered that he kept an extensive collection of 5¼" floppy > disks. I haven't looked through them but they appear to include > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > though I haven't found any of his Minix work). He also has a > selection of newletters from an Australian Peach users group. Is > there any interest in this material from a historicial perspective? > > -- > Peter Jeremy > From spedraja at gmail.com Mon Mar 9 09:07:35 2020 From: spedraja at gmail.com (Sergio Pedraja) Date: Mon, 9 Mar 2020 00:07:35 +0100 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: References: <20200308202230.GB3091@server.rulingia.com> Message-ID: I suggest to contact Al Kossow for this matter. As a Museum Curator and owner of bitsavers.org, he is keeping an impressive bunch of scanned manuals and software from years. I am absolutely sure that he will do the right thing about all this estate and legacy. On the other hand, it's Warren. Cordiales saludos / Kind Regards. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- *Sergio Pedraja* El dom., 8 mar. 2020 a las 23:33, Wesley Parish () escribió: > I'm in favour of preserving both the software and the newsletters. > History _is_ important, and knowledge of history doubly so when you > have predatory IPR scavengers on the loose, as we saw in the infamous > The SCO Group versus Linux and the World case. > > Wesley Parish > > On 3/9/20, Peter Jeremy wrote: > > As many of you may be aware, Bruce D. Evans died in > > mid-December. I am currently looking through his digital estate on > > behalf of his family and the FreeBSD Project. > > > > I have discovered that he kept an extensive collection of 5¼" floppy > > disks. I haven't looked through them but they appear to include > > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > > though I haven't found any of his Minix work). He also has a > > selection of newletters from an Australian Peach users group. Is > > there any interest in this material from a historicial perspective? > > > > -- > > Peter Jeremy > > > _______________________________________________ > 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 Mon Mar 9 09:48:12 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 9 Mar 2020 09:48:12 +1000 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308202230.GB3091@server.rulingia.com> References: <20200308202230.GB3091@server.rulingia.com> Message-ID: <20200308234812.GA20254@minnie.tuhs.org> On Mon, Mar 09, 2020 at 07:22:30AM +1100, Peter Jeremy wrote: > I have discovered that he kept an extensive collection of 5¼" floppy > disks. I haven't looked through them but they appear to include > things like OS-9 and Hitachi Peach files (and presumably Minix stuff, > though I haven't found any of his Minix work). He also has a > selection of newletters from an Australian Peach users group. Is > there any interest in this material from a historicial perspective? I still have a 5¼" floppy drive, not sure I have a PC to plug it in to. Give me a few days and I'll let you know. Cheers, Warren From dave at horsfall.org Mon Mar 9 13:18:38 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Mar 2020 14:18:38 +1100 (EST) Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: <20200308234812.GA20254@minnie.tuhs.org> References: <20200308202230.GB3091@server.rulingia.com> <20200308234812.GA20254@minnie.tuhs.org> Message-ID: On Mon, 9 Mar 2020, Warren Toomey wrote: > I still have a 5¼" floppy drive, not sure I have a PC to plug it in to. > Give me a few days and I'll let you know. Don't forget that there were many "standards" for those things; a popular utility was "Alien" for MS/DOS, which accessed the hardware. There was also a version for ye olde Microbee called "Bee-Alien"; I made heavy use of it :-) -- Dave From imp at bsdimp.com Mon Mar 9 13:39:11 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 8 Mar 2020 21:39:11 -0600 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: References: <20200308202230.GB3091@server.rulingia.com> <20200308234812.GA20254@minnie.tuhs.org> Message-ID: On Sun, Mar 8, 2020, 9:18 PM Dave Horsfall wrote: > On Mon, 9 Mar 2020, Warren Toomey wrote: > > > I still have a 5¼" floppy drive, not sure I have a PC to plug it in to. > > Give me a few days and I'll let you know. > > Don't forget that there were many "standards" for those things; a popular > utility was "Alien" for MS/DOS, which accessed the hardware. There was > also a version for ye olde Microbee called "Bee-Alien"; I made heavy use > of it :-) > That's why I got a kyroflux... too hard to find an old enough pc that the floppy controller supports the full range of crazy that once roamed the earth... Warner -- 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 dave at horsfall.org Mon Mar 9 14:18:30 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Mar 2020 15:18:30 +1100 (EST) Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: References: <20200308202230.GB3091@server.rulingia.com> <20200308234812.GA20254@minnie.tuhs.org> Message-ID: On Sun, 8 Mar 2020, Warner Losh wrote: > That's why I got a kyroflux...  too hard to find an old enough pc that > the floppy controller supports the full range of crazy that once roamed > the earth... There were also many devious copy protection schemes used for games etc. One common one was to punch a hole in a known sector (!) and if you didn't get a read error when accessing it then it was an illegal copy; another was to store data in an otherwise unreachable sector e.g. track 41 on a 40 track disk... In short, good luck :-) Hmmm... I just looked up the KryoFlux, and it's a fascinating device; it actually gets right down to the flux level! I've never seen a 3" disk before though. -- Dave From lars at nocrew.org Mon Mar 9 17:30:43 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 09 Mar 2020 07:30:43 +0000 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: (Arthur Krewat's message of "Sun, 8 Mar 2020 16:30:06 -0400") References: <20200308202230.GB3091@server.rulingia.com> Message-ID: <7w4kuykmsc.fsf@junk.nocrew.org> Arthur Krewat wrote: > Yes, I am a data-horder. Bless you! From gtaylor at tnetconsulting.net Tue Mar 10 07:18:48 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 9 Mar 2020 15:18:48 -0600 Subject: [COFF] Speaking of floppy controllers, Message-ID: On 3/8/20 9:39 PM, Warner Losh wrote: > floppy controller supports the full range of crazy that once roamed > the earth Does anyone have any knee jerk reaction to the idea of putting a 5¼" floppy drive on a USB-to-Floppy (nominally 3½") adapter? Do I want to avoid tilting at this windmill? Am I better off installing the 5¼" floppy inside the computer and connecting directly to the motherboard? I'm only wanting to pull files off of 5¼" disks. At most I'll want to dd the disks to an image. That being said, I wonder if I should also be collecting any different types of images. (This may mean mobo instead of USB.) Thank you for any pro-tips that you can provide. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Tue Mar 10 08:10:49 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 10 Mar 2020 09:10:49 +1100 (EST) Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: References: <20200308202230.GB3091@server.rulingia.com> Message-ID: On Mon, 9 Mar 2020, Wesley Parish wrote: > I'm in favour of preserving both the software and the newsletters. > History _is_ important, and knowledge of history doubly so when you have > predatory IPR scavengers on the loose, as we saw in the infamous The SCO > Group versus Linux and the World case. About a decade ago I read a story about someone discovering that a supplier had some CP/M boxes in stock, but still wanted full book-price for them... -- Dave From drb at msu.edu Tue Mar 10 08:06:33 2020 From: drb at msu.edu (Dennis Boone) Date: Mon, 09 Mar 2020 18:06:33 -0400 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: (Your message of Mon, 09 Mar 2020 15:18:48 -0600.) References: Message-ID: <20200309220633.52E62259C28@yagi.h-net.msu.edu> > Does anyone have any knee jerk reaction to the idea of putting a 5¼" > floppy drive on a USB-to-Floppy (nominally 3½") adapter? > Do I want to avoid tilting at this windmill? The gadgets of this general ilk that *I* have encountered only really work for accessing MS-DOS format floppies. If that's the scale of your problem, and you have a compatible floppy drive, you probably stand a chance. If not, you probably need something akin to a Kryoflux. De From krewat at kilonet.net Tue Mar 10 08:32:19 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 9 Mar 2020 18:32:19 -0400 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: References: Message-ID: <699cbc2d-31eb-dcc1-95e1-193df7463c83@kilonet.net> Off the top of my head, what floppies are you reading? Are they already normal "PC" format, or some other systems? And if so, are they compatible (read-wise) with what you have? There are adapters for the various connections of a edge-card floppy drive interface, and the 3.5" floppy interface (dual-inline?), it's directly electronically compatible I believe. But, as Dennis Boone says in another email about formats, the USB adapter might cause issues with non-MS/DOS or Windows floppies just because it might only deal with a limited number of configurations, track and sector wise. art k. On 3/9/2020 5:18 PM, Grant Taylor via COFF wrote: > On 3/8/20 9:39 PM, Warner Losh wrote: >> floppy controller supports the full range of crazy that once roamed >> the earth > > Does anyone have any knee jerk reaction to the idea of putting a 5¼" > floppy drive on a USB-to-Floppy (nominally 3½") adapter? > > Do I want to avoid tilting at this windmill? > > Am I better off installing the 5¼" floppy inside the computer and > connecting directly to the motherboard? > > I'm only wanting to pull files off of 5¼" disks.  At most I'll want to > dd the disks to an image. > > That being said, I wonder if I should also be collecting any different > types of images.  (This may mean mobo instead of USB.) > > Thank you for any pro-tips that you can provide. > > > > > _______________________________________________ > 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 gtaylor at tnetconsulting.net Tue Mar 10 08:49:32 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 9 Mar 2020 16:49:32 -0600 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: References: Message-ID: <5090ac34-4ba4-39d2-9bc1-70278432af4d@spamtrap.tnetconsulting.net> On 3/9/20 3:18 PM, Grant Taylor via COFF wrote: > I'm only wanting to pull files off of 5¼" disks.  At most I'll want to > dd the disks to an image. I have two sets of floppies that I want to read at this time. The first, and likely simpler, is an old Super Solvers game for MS-DOS. The second, and possibly more problematic, is Banyan Vines install media. I expect that at least some of the Vines disks are PC format, but I wouldn't be surprised if others were a Vines specific format that are read after Vines (a Unix) is booted. At this point I'm more concerned with saving the content of / files on the disks than I am in saving a disk image that others can consume. But I suspect this is biased in a non-trivial ignorance of what others might want or wish that I had done to preserve these disks. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Tue Mar 10 09:49:37 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 9 Mar 2020 17:49:37 -0600 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: References: Message-ID: On Mon, Mar 9, 2020 at 3:24 PM Grant Taylor via COFF wrote: > On 3/8/20 9:39 PM, Warner Losh wrote: > > floppy controller supports the full range of crazy that once roamed > > the earth > > Does anyone have any knee jerk reaction to the idea of putting a 5¼" > floppy drive on a USB-to-Floppy (nominally 3½") adapter? > Won't work. There's two reasons for this. First, the USB adapter talks to the 3.5" floppy directly in a rather hard-wired kind of way. Second, the USB standard makes drivers assume they are talking to a 3.5" drive with a 1.44MB in it only (though there's a common extension for the 720k floppies, IIRC). 5.25" is right out. Unless you have a specialized USB thing like kyroflux, but it doesn't present a nice, simple interface to the system (though the interface it does have/use works really well) > Do I want to avoid tilting at this windmill? > > Am I better off installing the 5¼" floppy inside the computer and > connecting directly to the motherboard? > > I'm only wanting to pull files off of 5¼" disks. At most I'll want to > dd the disks to an image. > I've not had good luck with that in over 15-20 years. I have used kyroflux to read ~500 DEC Rainbow disks and I have images now that I've been able to read and pull files off of. I'm more hampered by archive programs removing support for really old versions of the compression algorithms :(. > That being said, I wonder if I should also be collecting any different > types of images. (This may mean mobo instead of USB.) > > Thank you for any pro-tips that you can provide. > My pro tip is to get hardware that's geared to reading a variety of disks rather than hope your mobo has enough smarts to do it. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Mar 11 03:52:07 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Mar 2020 13:52:07 -0400 Subject: [COFF] Fwd: [ih] NCP and TCP implementations In-Reply-To: References: Message-ID: Given the recent discussion of pipes and networking ... I'm passing this along for those that might not have seen it. ---------- Forwarded message --------- From: Jack Haverty via Internet-history Date: Tue, Mar 10, 2020 at 1:30 PM Subject: Re: [ih] NCP and TCP implementations To: *Internet-History* The first TCP implementation for Unix was done in PDP-11 assembly language, running on a PDP-11/40 (with way too little memory or address space). It was built using code fragments excerpted from the LSI-11 TCP implementation provided by Jim Mathis, which ran under SRI's home-built OS. Jim's TCP was all written in PDP-11 assembler. The code was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded over a TTY line to the PDP-11/40. That was much easier and faster than doing all the implementation work on the PDP-11. The code architecture involved putting TCP itself at the user level, communicating with its "customers" using Unix InterProcess Communications facilities (Rand "Ports"). It would have been preferable to implement TCP within the Unix kernel, but there was simply not enough room due to the limited address space available on the 11/40 model. Later implementations of TCP, on larger machines with twice the address space, were done in the kernel. In addition to the Berkeley BSD work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP implementation for the PDP-11/70 and Vax. The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as was Jim's LSI-11 code. This 2.5 implementation was one of the players in the first "TCP Bakeoff" organized by Jon Postel and carried out on a weekend at ISI before the quarterly Internet meeting. The PDP-11/40 TCP was modified extensively over the next year or so as TCP advanced through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems we still have today, 40+ years later!) The Unix TCP implementation required a small addition to the Unix kernel code, to add the "await" and "capac" system calls. Those calls were necessary to enable the implementation of user-level code where the traditional Unix "pipeline" model of programming (input->process->process...->output) was inadequate for use in multi-computer programming (such as FTP, Telnet, etc., - anywhere where more than one computer was involved). The code to add those new system calls was written in C, as was almost all of the Unix OS itself. The new system calls added the functionality of "non-blocking I/O" which did not previously exist. It involved very few lines of code, since there wasn't room for very many more instructions, and even so it required finding more space by shortening many of the kernel error messages to save a few bytes here and there. Randy Rettberg and I did that work, struggling to understand how Unix kernel internals worked, since neither of us had ever worked with Unix before even as a user. We did not try to "get it right" by making significant changes to the basic Unix architecture. That came later with the Berkeley and Gurwitz efforts. The PDP-11/40 was simply too constrained to support such changes, and our mission was to get TCP support on the machine, rather than develop the OS. I think I speak authoritatively here, since I wrote and debugged that first Unix TCP code. I still have an old, yellowing listing of that first Unix TCP. FWIW, if there's interest in why certain languages were chosen, there's a very simple explanation of why the Unix implementation was done in assembler rather than C, the native language of Unix. First, Jim Mathis' code was in assembler, so it was easy to extract large chunks and paste them into the Unix assembler implementation. Second, and probably most important, was that I was very accustomed to writing assembler code and working at the processor instruction level. But I barely knew C existed, and was certainly not proficient in it, and we needed the TCP working fast for use in other projects. The choice was very pragmatic, not based at all on technical issues of languages or superiority of any architecture. /Jack Haverty On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote: > Steve Kirsch asks in what languages NCP and TCP were written. > > The Stanford first TCP implementation was done in BCPL by Richard Karp. > Another version was written for PDP-11/23 by Jim Mathis but not clear in > what language. Tenex was probably done in C at BBN. Was 360 done in PL/1?? > Dave Clark did one for IBM PC (assembly language/??) > > Other recollections much appreciated. > > vint -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Mar 11 04:23:41 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 10 Mar 2020 12:23:41 -0600 Subject: [COFF] Fwd: [ih] NCP and TCP implementations In-Reply-To: References: Message-ID: >>> In addition to the Berkeley BSD work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP implementation for the PDP-11/70 and Vax. This is new. I'd like more info The name Nemeth is interesting. Is that Evi? And does that body of code still exist? >>> I think I speak authoritatively here, since I wrote and debugged that first Unix TCP code. I still have an old, yellowing listing of that first Unix TCP. I wonder if you could write him and see if this listing can be scanned / preserved... Warner On Tue, Mar 10, 2020 at 11:52 AM Clem Cole wrote: > > Given the recent discussion of pipes and networking ... I'm passing this > along for those that might not have seen it. > > ---------- Forwarded message --------- > From: Jack Haverty via Internet-history > Date: Tue, Mar 10, 2020 at 1:30 PM > Subject: Re: [ih] NCP and TCP implementations > To: *Internet-History* > > > The first TCP implementation for Unix was done in PDP-11 assembly > language, running on a PDP-11/40 (with way too little memory or address > space). It was built using code fragments excerpted from the LSI-11 > TCP implementation provided by Jim Mathis, which ran under SRI's > home-built OS. Jim's TCP was all written in PDP-11 assembler. The code > was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded > over a TTY line to the PDP-11/40. That was much easier and faster than > doing all the implementation work on the PDP-11. > > The code architecture involved putting TCP itself at the user level, > communicating with its "customers" using Unix InterProcess > Communications facilities (Rand "Ports"). It would have been > preferable to implement TCP within the Unix kernel, but there was simply > not enough room due to the limited address space available on the 11/40 > model. Later implementations of TCP, on larger machines with twice the > address space, were done in the kernel. In addition to the Berkeley BSD > work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP > implementation for the PDP-11/70 and Vax. > > The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as > was Jim's LSI-11 code. This 2.5 implementation was one of the players > in the first "TCP Bakeoff" organized by Jon Postel and carried out on a > weekend at ISI before the quarterly Internet meeting. The PDP-11/40 TCP > was modified extensively over the next year or so as TCP advanced > through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems > we still have today, 40+ years later!) > > The Unix TCP implementation required a small addition to the Unix kernel > code, to add the "await" and "capac" system calls. Those calls were > necessary to enable the implementation of user-level code where the > traditional Unix "pipeline" model of programming > (input->process->process...->output) was inadequate for use in > multi-computer programming (such as FTP, Telnet, etc., - anywhere where > more than one computer was involved). > > The code to add those new system calls was written in C, as was almost > all of the Unix OS itself. The new system calls added the functionality > of "non-blocking I/O" which did not previously exist. It involved very > few lines of code, since there wasn't room for very many more > instructions, and even so it required finding more space by shortening > many of the kernel error messages to save a few bytes here and there. > > Randy Rettberg and I did that work, struggling to understand how Unix > kernel internals worked, since neither of us had ever worked with Unix > before even as a user. We did not try to "get it right" by making > significant changes to the basic Unix architecture. That came later > with the Berkeley and Gurwitz efforts. The PDP-11/40 was simply too > constrained to support such changes, and our mission was to get TCP > support on the machine, rather than develop the OS. > > I think I speak authoritatively here, since I wrote and debugged that > first Unix TCP code. I still have an old, yellowing listing of that > first Unix TCP. > > FWIW, if there's interest in why certain languages were chosen, there's > a very simple explanation of why the Unix implementation was done in > assembler rather than C, the native language of Unix. First, Jim > Mathis' code was in assembler, so it was easy to extract large chunks > and paste them into the Unix assembler implementation. Second, and > probably most important, was that I was very accustomed to writing > assembler code and working at the processor instruction level. But I > barely knew C existed, and was certainly not proficient in it, and we > needed the TCP working fast for use in other projects. The choice was > very pragmatic, not based at all on technical issues of languages or > superiority of any architecture. > > /Jack Haverty > > > On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote: > > Steve Kirsch asks in what languages NCP and TCP were written. > > > > The Stanford first TCP implementation was done in BCPL by Richard Karp. > > Another version was written for PDP-11/23 by Jim Mathis but not clear in > > what language. Tenex was probably done in C at BBN. Was 360 done in > PL/1?? > > Dave Clark did one for IBM PC (assembly language/??) > > > > Other recollections much appreciated. > > > > vint > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > _______________________________________________ > 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 Mar 11 04:30:16 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Mar 2020 14:30:16 -0400 Subject: [COFF] Fwd: [ih] NCP and TCP implementations In-Reply-To: References: Message-ID: On Tue, Mar 10, 2020 at 2:23 PM Warner Losh wrote: > >>> In addition to the Berkeley BSD work, I remember Gurwitz, Wingfield, > Nemeth, and others working on TCP implementation for the PDP-11/70 and Vax. > > This is new. I'd like more info The name Nemeth is interesting. Is that > Evi? And does that body of code still exist? > Alan Nemeth -- former BBN Fellow, later DEC CCE. Leah Architect of the C30/C70 and the Bufferfly. This is the 'official' IP/TCP implementation for UNIX. Joy would start with it. A version of the code is in Warren's archives and on Kirk's larger disk. > > >>> I think I speak authoritatively here, since I wrote and debugged that > first Unix TCP code. I still have an old, yellowing listing of that first > Unix TCP. > > I wonder if you could write him and see if this listing can be scanned / > preserved... > I have this AM in fact before I sent the message to you -- no response so far. > > Warner > > On Tue, Mar 10, 2020 at 11:52 AM Clem Cole wrote: > >> >> Given the recent discussion of pipes and networking ... I'm passing this >> along for those that might not have seen it. >> >> ---------- Forwarded message --------- >> From: Jack Haverty via Internet-history >> Date: Tue, Mar 10, 2020 at 1:30 PM >> Subject: Re: [ih] NCP and TCP implementations >> To: *Internet-History* >> >> >> The first TCP implementation for Unix was done in PDP-11 assembly >> language, running on a PDP-11/40 (with way too little memory or address >> space). It was built using code fragments excerpted from the LSI-11 >> TCP implementation provided by Jim Mathis, which ran under SRI's >> home-built OS. Jim's TCP was all written in PDP-11 assembler. The code >> was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded >> over a TTY line to the PDP-11/40. That was much easier and faster than >> doing all the implementation work on the PDP-11. >> >> The code architecture involved putting TCP itself at the user level, >> communicating with its "customers" using Unix InterProcess >> Communications facilities (Rand "Ports"). It would have been >> preferable to implement TCP within the Unix kernel, but there was simply >> not enough room due to the limited address space available on the 11/40 >> model. Later implementations of TCP, on larger machines with twice the >> address space, were done in the kernel. In addition to the Berkeley BSD >> work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP >> implementation for the PDP-11/70 and Vax. >> >> The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as >> was Jim's LSI-11 code. This 2.5 implementation was one of the players >> in the first "TCP Bakeoff" organized by Jon Postel and carried out on a >> weekend at ISI before the quarterly Internet meeting. The PDP-11/40 TCP >> was modified extensively over the next year or so as TCP advanced >> through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems >> we still have today, 40+ years later!) >> >> The Unix TCP implementation required a small addition to the Unix kernel >> code, to add the "await" and "capac" system calls. Those calls were >> necessary to enable the implementation of user-level code where the >> traditional Unix "pipeline" model of programming >> (input->process->process...->output) was inadequate for use in >> multi-computer programming (such as FTP, Telnet, etc., - anywhere where >> more than one computer was involved). >> >> The code to add those new system calls was written in C, as was almost >> all of the Unix OS itself. The new system calls added the functionality >> of "non-blocking I/O" which did not previously exist. It involved very >> few lines of code, since there wasn't room for very many more >> instructions, and even so it required finding more space by shortening >> many of the kernel error messages to save a few bytes here and there. >> >> Randy Rettberg and I did that work, struggling to understand how Unix >> kernel internals worked, since neither of us had ever worked with Unix >> before even as a user. We did not try to "get it right" by making >> significant changes to the basic Unix architecture. That came later >> with the Berkeley and Gurwitz efforts. The PDP-11/40 was simply too >> constrained to support such changes, and our mission was to get TCP >> support on the machine, rather than develop the OS. >> >> I think I speak authoritatively here, since I wrote and debugged that >> first Unix TCP code. I still have an old, yellowing listing of that >> first Unix TCP. >> >> FWIW, if there's interest in why certain languages were chosen, there's >> a very simple explanation of why the Unix implementation was done in >> assembler rather than C, the native language of Unix. First, Jim >> Mathis' code was in assembler, so it was easy to extract large chunks >> and paste them into the Unix assembler implementation. Second, and >> probably most important, was that I was very accustomed to writing >> assembler code and working at the processor instruction level. But I >> barely knew C existed, and was certainly not proficient in it, and we >> needed the TCP working fast for use in other projects. The choice was >> very pragmatic, not based at all on technical issues of languages or >> superiority of any architecture. >> >> /Jack Haverty >> >> >> On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote: >> > Steve Kirsch asks in what languages NCP and TCP were written. >> > >> > The Stanford first TCP implementation was done in BCPL by Richard Karp. >> > Another version was written for PDP-11/23 by Jim Mathis but not clear in >> > what language. Tenex was probably done in C at BBN. Was 360 done in >> PL/1?? >> > Dave Clark did one for IBM PC (assembly language/??) >> > >> > Other recollections much appreciated. >> > >> > vint >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> _______________________________________________ >> 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 Mar 11 04:31:29 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Mar 2020 14:31:29 -0400 Subject: [COFF] Fwd: [ih] NCP and TCP implementations In-Reply-To: References: Message-ID: s/Leah/Lead/ <-- finger fumble/ROM clash (my daughters first name) On Tue, Mar 10, 2020 at 2:30 PM Clem Cole wrote: > > On Tue, Mar 10, 2020 at 2:23 PM Warner Losh wrote: > >> >>> In addition to the Berkeley BSD work, I remember Gurwitz, Wingfield, >> Nemeth, and others working on TCP implementation for the PDP-11/70 and Vax. >> >> This is new. I'd like more info The name Nemeth is interesting. Is that >> Evi? And does that body of code still exist? >> > Alan Nemeth -- former BBN Fellow, later DEC CCE. Leah Architect of the > C30/C70 and the Bufferfly. > This is the 'official' IP/TCP implementation for UNIX. Joy would start > with it. A version of the code is in Warren's archives and on Kirk's > larger disk. > > >> >> >>> I think I speak authoritatively here, since I wrote and debugged that >> first Unix TCP code. I still have an old, yellowing listing of that first >> Unix TCP. >> >> I wonder if you could write him and see if this listing can be scanned / >> preserved... >> > I have this AM in fact before I sent the message to you -- no response so > far. > >> >> Warner >> >> On Tue, Mar 10, 2020 at 11:52 AM Clem Cole wrote: >> >>> >>> Given the recent discussion of pipes and networking ... I'm passing >>> this along for those that might not have seen it. >>> >>> ---------- Forwarded message --------- >>> From: Jack Haverty via Internet-history >>> Date: Tue, Mar 10, 2020 at 1:30 PM >>> Subject: Re: [ih] NCP and TCP implementations >>> To: *Internet-History* >>> >>> >>> The first TCP implementation for Unix was done in PDP-11 assembly >>> language, running on a PDP-11/40 (with way too little memory or address >>> space). It was built using code fragments excerpted from the LSI-11 >>> TCP implementation provided by Jim Mathis, which ran under SRI's >>> home-built OS. Jim's TCP was all written in PDP-11 assembler. The code >>> was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded >>> over a TTY line to the PDP-11/40. That was much easier and faster than >>> doing all the implementation work on the PDP-11. >>> >>> The code architecture involved putting TCP itself at the user level, >>> communicating with its "customers" using Unix InterProcess >>> Communications facilities (Rand "Ports"). It would have been >>> preferable to implement TCP within the Unix kernel, but there was simply >>> not enough room due to the limited address space available on the 11/40 >>> model. Later implementations of TCP, on larger machines with twice the >>> address space, were done in the kernel. In addition to the Berkeley BSD >>> work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP >>> implementation for the PDP-11/70 and Vax. >>> >>> The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as >>> was Jim's LSI-11 code. This 2.5 implementation was one of the players >>> in the first "TCP Bakeoff" organized by Jon Postel and carried out on a >>> weekend at ISI before the quarterly Internet meeting. The PDP-11/40 TCP >>> was modified extensively over the next year or so as TCP advanced >>> through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems >>> we still have today, 40+ years later!) >>> >>> The Unix TCP implementation required a small addition to the Unix kernel >>> code, to add the "await" and "capac" system calls. Those calls were >>> necessary to enable the implementation of user-level code where the >>> traditional Unix "pipeline" model of programming >>> (input->process->process...->output) was inadequate for use in >>> multi-computer programming (such as FTP, Telnet, etc., - anywhere where >>> more than one computer was involved). >>> >>> The code to add those new system calls was written in C, as was almost >>> all of the Unix OS itself. The new system calls added the functionality >>> of "non-blocking I/O" which did not previously exist. It involved very >>> few lines of code, since there wasn't room for very many more >>> instructions, and even so it required finding more space by shortening >>> many of the kernel error messages to save a few bytes here and there. >>> >>> Randy Rettberg and I did that work, struggling to understand how Unix >>> kernel internals worked, since neither of us had ever worked with Unix >>> before even as a user. We did not try to "get it right" by making >>> significant changes to the basic Unix architecture. That came later >>> with the Berkeley and Gurwitz efforts. The PDP-11/40 was simply too >>> constrained to support such changes, and our mission was to get TCP >>> support on the machine, rather than develop the OS. >>> >>> I think I speak authoritatively here, since I wrote and debugged that >>> first Unix TCP code. I still have an old, yellowing listing of that >>> first Unix TCP. >>> >>> FWIW, if there's interest in why certain languages were chosen, there's >>> a very simple explanation of why the Unix implementation was done in >>> assembler rather than C, the native language of Unix. First, Jim >>> Mathis' code was in assembler, so it was easy to extract large chunks >>> and paste them into the Unix assembler implementation. Second, and >>> probably most important, was that I was very accustomed to writing >>> assembler code and working at the processor instruction level. But I >>> barely knew C existed, and was certainly not proficient in it, and we >>> needed the TCP working fast for use in other projects. The choice was >>> very pragmatic, not based at all on technical issues of languages or >>> superiority of any architecture. >>> >>> /Jack Haverty >>> >>> >>> On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote: >>> > Steve Kirsch asks in what languages NCP and TCP were written. >>> > >>> > The Stanford first TCP implementation was done in BCPL by Richard Karp. >>> > Another version was written for PDP-11/23 by Jim Mathis but not clear >>> in >>> > what language. Tenex was probably done in C at BBN. Was 360 done in >>> PL/1?? >>> > Dave Clark did one for IBM PC (assembly language/??) >>> > >>> > Other recollections much appreciated. >>> > >>> > vint >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> https://elists.isoc.org/mailman/listinfo/internet-history >>> _______________________________________________ >>> 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 Mar 11 06:32:57 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Mar 2020 16:32:57 -0400 Subject: [COFF] Fwd: [ih] NCP and TCP implementations In-Reply-To: References: Message-ID: On Tue, Mar 10, 2020 at 2:30 PM Clem Cole wrote: > I have this AM in fact before I sent the message to you -- no response so > far. > Jack just replied to messaged that both Warren and I sent him independently and he's working it. It sounds very promising indeed. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Mar 13 05:30:57 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 12 Mar 2020 15:30:57 -0400 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: <5090ac34-4ba4-39d2-9bc1-70278432af4d@spamtrap.tnetconsulting.net> References: <5090ac34-4ba4-39d2-9bc1-70278432af4d@spamtrap.tnetconsulting.net> Message-ID: <64cb66ef-307d-f226-1c6e-b2f3529a3289@kilonet.net> I ordered a Kryoflux board from them two days ago. I have plenty of C64, MSDOS, and other floppies that I'd like to make images of. I will report back to the COFF list what I find after I receive it. It shipped today, but it's coming from Germany I believe, so we'll see how long that takes ;) I ordered this one, as it comes with a few extra cables and a power supply for the floppy drive: https://webstore.kryoflux.com/catalog/product_info.php?products_id=30 Cost me with shipping to the US: $144.41 , or €129.30 EUR according to the invoice. Very reasonable... art k. From rtomek at ceti.pl Fri Mar 13 06:53:01 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 12 Mar 2020 21:53:01 +0100 Subject: [COFF] 21st Century Equivalent to 'learn'? In-Reply-To: <20200304034925.GA18809@minnie.tuhs.org> References: <20200304034925.GA18809@minnie.tuhs.org> Message-ID: <20200312205301.GA32270@tau1.ceti.pl> On Wed, Mar 04, 2020 at 01:49:25PM +1000, Warren Toomey wrote: > Hi all, I'm looking for an interactive tool to help students learn the > Unix/Linux command line. I still remember the "learn" tool. Is there an > equivalent for current systems? > > I have tried to forward-port the old learn sources to current Linux but > my patience ran out :-) > > Thanks in advance for any tips/pointers. I am not sure what kind are your students, but back when I was one (and not in US, so my approach might not apply) there was some kind of minimum required from a student to pass as "knows Unix". Stuff like "show directory contents", "make directory", move around via cd and pwd, chmod, some editing, write a C program and compile (CS students were meant to program). It is possible that knowledge of /usr/bin/make was optional. /bin/tar was definitely optional. Majority (i.e. "all") would not give a hoot about some "yoo-neecs". DOS and Windows 3.1 ruled in businesses, where the majority expected to find themselves after graduation. Windows 3x was all the rage. It had multitasking! And Novell networks, for the more ambitious. I learned more than minimum, because I actually wanted to _use_ the facilities. Which means, solving a problem by writing some code (shell script, makefile, C-file, awk). No need to convince me or make it easy by some "pupil shell". I never expected this, I only expected good manual or Readme. BTW, I also perceived tools available on Unix as superior to anything I could lay my hands on, including AmigaOS (which had number of similar tools, but poor multitasking sometimes resulted in frozen computer). Maybe VMS could compete, but was not so easy to have account on it. So I falsely assumed one should choose the best tools and now I am on this God-forgotten mailing list. The list composed by Andy Kosela seems very plausible to my eyes, but I am afraid the majority of modern students likewise are not going to give a hoot. Perhaps you could make some of them care more if you gave them a kind of contest. Bare bones system install in virtual machine, no X, no compiler, no perl, but yes vim and yes emacs (and maybe some others, joe/jed?). Solve a problem? Small database a'la rolodex? For the rest, just demonstrate they can mkdir/ls/cd/chmod etc and let them go. Solving Project Euler tasks with shell scripts (or awk, when applicable). A bit harder - solve the tasks and make an uber-script which lists available solutions (say, it will find there are solutions for problem 3, 5 and 9 and list them) and can display an answer for problem by running a script. Student writes a solution-script and uber-script auto detects new file and can use it without need to be edited. If the solutions dir is empty, it will say no solutions found. Etc. I suppose some folks will be delighted by doing such things. Other will be kicking and screaming - no need to give them bad memories of Unix. Rather, let them see others who achieve. I am not sure, maybe I would be a very bad teacher. -- 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 clemc at ccc.com Wed Mar 18 01:41:20 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Mar 2020 11:41:20 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <20200317145723.GF26660@mcvoy.com> References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <20200317145723.GF26660@mcvoy.com> Message-ID: Moving to COFF .... On Tue, Mar 17, 2020 at 10:58 AM Larry McVoy wrote: > As much as I don't care for Forth, man do I wish it had become the standard > for boot proms, it might not be my cup of tea but I could make it do what > I needed it to do. Amen bro... Sun did a nice job on that. Although the Alpha Boot ROMs were pretty good too. At least they were UNIX like and were extensible like the Sun boot ROMs. HP's were better than a PC BIOS, but they were pretty awful. > Can't say the same for UEFI, I disable that crap. > Well, it beats the crap out of IBM's BIOS, but that bar is very low. UEFI was sort of a 'camel' (a horse designed by committee) and too many people peed on it. Intel created EFI to try to fix BIOS and then people went nuts. Apple's version is the best of them, but as you say, they all suck if you have seen anything better. A big problem IMO is that EFI tried to be somewhat compatible. In the end, they were not, so you got the worst of both (new interfaces and legacy functionality). Server systems that support IPMT have Minux under the covers in coprocessor, which using a coprocessor is also how Apple runs UEFI. With IMPT, it is sort of sad more of it is not really exposed, but you need the added cost of the coprocessor. Plus it adds a new security domain, which many people complain about. I try to know as little about it as possible to get my work done, but exposing more of that interface might help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Mar 18 08:48:17 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 18 Mar 2020 09:48:17 +1100 (EST) Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <20200317145723.GF26660@mcvoy.com> Message-ID: On Tue, 17 Mar 2020, Clem Cole wrote: > > Can't say the same for UEFI, I disable that crap. > > Well, it beats the crap out of IBM's BIOS, but that bar is very low.  >   UEFI was sort of a 'camel' (a horse designed by committee) and too > many people peed on it.  Intel created EFI to try to fix BIOS and then > people went nuts.   Apple's version is the best of them, but as you say, > they all suck if you have seen anything better.  A big problem IMO is > that EFI tried to be somewhat compatible.  In the end, they were not, so > you got the worst of both (new interfaces and legacy functionality). The first time I blundered into UEFI was when I tried to boot FreeBSD on a newish PC, and of course it was not an authorised CD, was it? Or something like that; anyway, I'm a great believer in allowing idiots to shoot themselves in the foot if they so desire. -- Dave From gtaylor at tnetconsulting.net Thu Mar 19 06:03:03 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 18 Mar 2020 14:03:03 -0600 Subject: [COFF] Speaking of floppy controllers, In-Reply-To: References: Message-ID: On 3/9/20 3:18 PM, Grant Taylor via COFF wrote: > Thank you for any pro-tips that you can provide. Thank you for all the replies, both on list and directly. I'm getting the impression that I might be bighting off more than I care to chew. So I may be looking for a service that I can send the disks to for them to be imaged. At least a reasonable take at it. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From david at kdbarto.org Thu Mar 19 08:41:22 2020 From: david at kdbarto.org (David Barto) Date: Wed, 18 Mar 2020 15:41:22 -0700 Subject: [COFF] Popular Programming languages over time Message-ID: https://www.youtube.com/watch?v=Og847HVwRSI It’s kind of amazing how long Pascal hangs on to #1. And you can watch the ascent of web programming. David From lm at mcvoy.com Thu Mar 19 12:34:23 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Mar 2020 19:34:23 -0700 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: Message-ID: <20200319023423.GZ26660@mcvoy.com> I'd like to know where the data came from. Ada that big? Says who? On Wed, Mar 18, 2020 at 03:41:22PM -0700, David Barto wrote: > https://www.youtube.com/watch?v=Og847HVwRSI > > It???s kind of amazing how long Pascal hangs on to #1. > And you can watch the ascent of web programming. > > David > _______________________________________________ > 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 Fri Mar 20 01:04:08 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 19 Mar 2020 11:04:08 -0400 Subject: [COFF] Popular Programming languages over time In-Reply-To: <20200319023423.GZ26660@mcvoy.com> References: <20200319023423.GZ26660@mcvoy.com> Message-ID: I saw that a while ago. I'd love to know more about the dataset behind it as Larry asked, FWIW: Pascal/Delphi being big did not surprise me as it was what was taught in the colleges in the 70s. Today they are teaching Python and Java so we see generations of new programmers going into the world with those skills (like my own daughter). Larry - I think the way to explain Ada, is that it was very big for a while when DoD, DoC and some of DoE when USG bids required it. But as fast as it rose, it fell pretty fast from favor. For me, I'm always amazed at things like Javascript and PHP, but their rise is directly mapped to people creating web sites. On Wed, Mar 18, 2020 at 10:34 PM Larry McVoy wrote: > I'd like to know where the data came from. Ada that big? Says who? > > On Wed, Mar 18, 2020 at 03:41:22PM -0700, David Barto wrote: > > https://www.youtube.com/watch?v=Og847HVwRSI > > > > It???s kind of amazing how long Pascal hangs on to #1. > > And you can watch the ascent of web programming. > > > > David > > _______________________________________________ > > 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 > _______________________________________________ > 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 pechter at gmail.com Fri Mar 20 01:31:42 2020 From: pechter at gmail.com (William Pechter) Date: Thu, 19 Mar 2020 11:31:42 -0400 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: <20200319023423.GZ26660@mcvoy.com> Message-ID: On 3/19/20 11:04 AM, Clem Cole wrote: > I saw that a while ago.  I'd love to know more about the dataset > behind it as Larry asked, > > FWIW: Pascal/Delphi being big did not surprise me as it was what was > taught in the colleges in the 70s.   Today they are teaching Python > and Java so we see generations of new programmers going into the world > with those skills (like my own daughter). > > Larry - I think the way to explain Ada, is that it was very big for a > while when DoD, DoC and some of DoE when USG bids required it.  But as > fast as it rose, it fell pretty fast from favor. > Actually, since the DOD's Ada Language System was being tested on the dual 11/780  Vaxes I supported at Fort Monmouth in New Jersey -- the language was just part of what was in the works. This was back in the 1983 timeframe.  Wikipedia shows that the DOD had a contract from 1977 to 1983 to come up with the OS which was supposedly targeted at embedded and real-time systems. At the time there were tons of different small C-compilers used on different parts of the same project -- with the ton of licenses required for each chip and RTOS supported. https://en.wikipedia.org/wiki/Ada_(programming_language)#Standardization Softech's Ada Language system had its hooks so far into VAX/VMS 3.x that shutting down the VAX/VMS system would crash the machine with a bugcheck.  I think somewhere there was a thought of a single Ada environment and programming tools across the various operating systems. I think the government wanted to standardize the military deveopment process... which at the time used a jumble of languages, embedded systems and RTOS's from various vendors with convoluted make files tied to the development environments for each part of a military intelligence/weapons system.  A bit of a bitch to maintain -- any change to one part could keep the rest from building. After Softech... NYU (IIRC) developed what is now known as GNAT -- the Gnu NYU Ada After my DEC job I did a couple of years as a system admin along with my wife.  We were building a new piece of software and she had the target system.  Fun when the embedded C compiler 100 lines in the build script suddenly goes out of license complience and stops building for no real reason... And the sysadmin has no docs as to how this builds. At the same time the government canceled a project to build a standard military computer family (chip)  which I think was the original idea and end target for all of this.  RCA, GE and others were trying to develop this but the release of the MicroVax2 kind of took the wind out of the sails -- and the Patriot missile (IIRC) used a Raytheon built box using the uVax chip set. (Don't know if this is the board used then but it's of a similar timeframe)... https://www.computerhistory.org/collections/catalog/102757133 It was the Reagan admin and it was very different times in software with more contractors working in different locations on pieces of projects and the integration was difficult. Bill > --- > Larry McVoy                  lm at mcvoy.com > http://www.mcvoy.com/lm > _______________________________________________ > 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 -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/ From clemc at ccc.com Fri Mar 20 01:57:02 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 19 Mar 2020 11:57:02 -0400 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: <20200319023423.GZ26660@mcvoy.com> Message-ID: On Thu, Mar 19, 2020 at 11:31 AM William Pechter wrote: > > At the time there were tons of different small C-compilers used on > different parts of the same project -- with the ton of licenses required > for each chip and RTOS supported. > Yep, in fact, I think that is really what killed Ada use. Because of the need for embedded support and most of the small processors did not have good Ada support, but did have C and assembler, a lot of USG contracts applied and got variances. But the start of the 90s, it was pretty clear, the idea behind Ada and a standard language for the USG was a lesson of theory vs. practical reality. Ada had a huge spike on the Mainframes and Minis because when it envisioned (in the mid-70s) that was the target processor. I used to be friends with the then chief SW guy at Raytheon who lead the Patriot missile SW development during those years (we lost him a few year ago due to massive heart attack). But he made me understand why Ada was created. At the time, Raytheon was doing support for the Polaris submarine missiles. They did not have the full source. It was all patches. DoD wanted a programming language that they could use for both specification and deployment. They wanted the specs to be able to last. And an interesting idea. But as you point out, as time went one, more and more of the code went from being in large systems into embedded micros and they were back to the same problem. The lacked tools to take Ada to deployment. So they specs might have been written in Ada 'pseudo-code', it was all done in C and Assembler. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Fri Mar 20 02:01:05 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 19 Mar 2020 12:01:05 -0400 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: <20200319023423.GZ26660@mcvoy.com> Message-ID: I proofread an Ada book by Narain Gehani, a colleague at the Labs. He had a nuclear reactor example with a sign error in the cooling control, so if it started to overheat, it would overheat faster. I *begged* him to leave the example untouched, as an example of why just because something compiled didn't mean it was correct. He just corrected the error, in my opinion, missing a valuable teaching moment. On Thu, Mar 19, 2020 at 11:31 AM William Pechter wrote: > > On 3/19/20 11:04 AM, Clem Cole wrote: > > I saw that a while ago. I'd love to know more about the dataset > > behind it as Larry asked, > > > > FWIW: Pascal/Delphi being big did not surprise me as it was what was > > taught in the colleges in the 70s. Today they are teaching Python > > and Java so we see generations of new programmers going into the world > > with those skills (like my own daughter). > > > > Larry - I think the way to explain Ada, is that it was very big for a > > while when DoD, DoC and some of DoE when USG bids required it. But as > > fast as it rose, it fell pretty fast from favor. > > > Actually, since the DOD's Ada Language System was being tested on the > dual 11/780 Vaxes I supported at Fort Monmouth in New Jersey -- the > language was just part of what was in the works. > > This was back in the 1983 timeframe. Wikipedia shows that the DOD had a > contract from 1977 to 1983 to come up with the OS which was supposedly > targeted at embedded and real-time systems. > > At the time there were tons of different small C-compilers used on > different parts of the same project -- with the ton of licenses required > for each chip and RTOS supported. > > https://en.wikipedia.org/wiki/Ada_(programming_language)#Standardization > > Softech's Ada Language system had its hooks so far into VAX/VMS 3.x that > shutting down the VAX/VMS system would crash the machine with a > bugcheck. I think somewhere there was a thought of a single Ada > environment and programming tools across the various operating systems. > > I think the government wanted to standardize the military deveopment > process... which at the time used a jumble of languages, embedded > systems and RTOS's from various vendors with convoluted make files tied > to the development environments for each part of a military > intelligence/weapons system. A bit of a bitch to maintain -- any change > to one part could keep the rest from building. > > After Softech... NYU (IIRC) developed what is now known as GNAT -- the > Gnu NYU Ada > > After my DEC job I did a couple of years as a system admin along with my > wife. We were building a new piece of software and she had the target > system. Fun when the embedded C compiler 100 lines in the build script > suddenly goes out of license complience and stops building for no real > reason... And the sysadmin has no docs as to how this builds. > > At the same time the government canceled a project to build a standard > military computer family (chip) which I think was the original idea and > end target for all of this. RCA, GE and others were trying to develop > this but the release of the MicroVax2 kind of took the wind out of the > sails -- and the Patriot missile (IIRC) used a Raytheon built box using > the uVax chip set. > > (Don't know if this is the board used then but it's of a similar > timeframe)... > > https://www.computerhistory.org/collections/catalog/102757133 > > It was the Reagan admin and it was very different times in software with > more contractors working in different locations on pieces of projects > and the integration was difficult. > > Bill > > > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > _______________________________________________ > > 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 > > -- > Digital had it then. Don't you wish you could buy it now! > pechter-at-gmail.com http://xkcd.com/705/ > > _______________________________________________ > 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 Mar 20 06:44:06 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 19 Mar 2020 13:44:06 -0700 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: <20200319023423.GZ26660@mcvoy.com> Message-ID: PHP was the BASIC of the late 90s and early 2000s; Javascript was (and is) the BASIC of the subsequent generation. I mean that, of course, in both good and bad ways, and as someone whose initial experience was BASIC in the ROMs of Apple IIs and C64s. Bad in that neither one is a well-(or even particularly-intentionally) designed language. Good in that it's easy to get the results you want with some iteration and very little theory or formal training; a novice can bootstrap/cargo-cult something into being pretty easily. Adam On Thu, Mar 19, 2020 at 8:04 AM Clem Cole wrote: > I saw that a while ago. I'd love to know more about the dataset behind it > as Larry asked, > > FWIW: Pascal/Delphi being big did not surprise me as it was what was > taught in the colleges in the 70s. Today they are teaching Python and > Java so we see generations of new programmers going into the world with > those skills (like my own daughter). > > Larry - I think the way to explain Ada, is that it was very big for a > while when DoD, DoC and some of DoE when USG bids required it. But as fast > as it rose, it fell pretty fast from favor. > > For me, I'm always amazed at things like Javascript and PHP, but their > rise is directly mapped to people creating web sites. > > On Wed, Mar 18, 2020 at 10:34 PM Larry McVoy wrote: > >> I'd like to know where the data came from. Ada that big? Says who? >> >> On Wed, Mar 18, 2020 at 03:41:22PM -0700, David Barto wrote: >> > https://www.youtube.com/watch?v=Og847HVwRSI >> > >> > It???s kind of amazing how long Pascal hangs on to #1. >> > And you can watch the ascent of web programming. >> > >> > David >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 Mar 20 07:31:57 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 20 Mar 2020 08:31:57 +1100 (EST) Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> Message-ID: On Thu, 19 Mar 2020, Mike Markowski wrote: >> I've been using my trusty HP-42S for so long that I can hardly remember >> how to use a "normal" calculator :-) > > When my classmate's calculator died during an engineering exam, he asked > if he could borrow my spare. I handed him my HP 32s and after a minute > he whispered, "Where's the equals key?" He gave my calculator back. > :-) I did that to a financial controller in a previous life; she was not amused... Hey, it was the only calculator that I had! I could see her helplessly looking for the "=" key, then I took pity on her. -- Dave From cym224 at gmail.com Fri Mar 20 07:30:51 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 19 Mar 2020 17:30:51 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> Message-ID: <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> On 03/19/20 17:31, Dave Horsfall wrote: > On Thu, 19 Mar 2020, Mike Markowski wrote: >>> I've been using my trusty HP-42S for so long that I can hardly >>> remember how to use a "normal" calculator :-) >> When my classmate's calculator died during an engineering exam, he >> asked if he could borrow my spare. I handed him my HP 32s and after >> a minute he whispered, "Where's the equals key?" He gave my >> calculator back. :-) > I did that to a financial controller in a previous life; she was not > amused... Hey, it was the only calculator that I had! I could see > her helplessly looking for the "=" key, then I took pity on her. Hhmm, back in my early days, the 12C was highly coveted by financial types. Our mileage differed. By the way, HP will sell you an Android app'n that looks just like their venerable (and much missed) calculators. N. > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From stewart at serissa.com Fri Mar 20 07:48:12 2020 From: stewart at serissa.com (Larry Stewart) Date: Thu, 19 Mar 2020 17:48:12 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> References: <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: > On Mar 19, 2020, at 5:39 PM, Nemo Nusquam wrote: > > On 03/19/20 17:31, Dave Horsfall wrote: >> On Thu, 19 Mar 2020, Mike Markowski wrote: >>>> I've been using my trusty HP-42S for so long that I can hardly remember how to use a "normal" calculator :-) >>> When my classmate's calculator died during an engineering exam, he asked if he could borrow my spare. I handed him my HP 32s and after a minute he whispered, "Where's the equals key?" He gave my calculator back. :-) >> I did that to a financial controller in a previous life; she was not amused... Hey, it was the only calculator that I had! I could see her helplessly looking for the "=" key, then I took pity on her. > > Hhmm, back in my early days, the 12C was highly coveted by financial types. Our mileage differed. > > By the way, HP will sell you an Android app'n that looks just like their venerable (and much missed) calculators. > > N. >> >> -- 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 The HP calculator apps run the original microcode... From wobblygong at gmail.com Fri Mar 20 10:29:14 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 20 Mar 2020 13:29:14 +1300 Subject: [COFF] Popular Programming languages over time In-Reply-To: References: <20200319023423.GZ26660@mcvoy.com> Message-ID: FWVLIW, I'm fooling around trying to learn PHP at this moment. Yes, web development is pretty big, and it is driving the usage of those languages. What gets me with PHP - and Javascript, which I'm going to have to learn if I want to really enter this web development career - is the lack of type-checking. A nephew, who is currently employed in Kubernetes and web development, uses Microsoft's Typescript in preference (Typescript may be one of Microsoft's redeeming developments - it's more typesafe than Javascript, though how much I don't know! :) Wesley Parish On 3/20/20, Adam Thornton wrote: > PHP was the BASIC of the late 90s and early 2000s; Javascript was (and is) > the BASIC of the subsequent generation. > > I mean that, of course, in both good and bad ways, and as someone whose > initial experience was BASIC in the ROMs of Apple IIs and C64s. Bad in > that neither one is a well-(or even particularly-intentionally) designed > language. Good in that it's easy to get the results you want with some > iteration and very little theory or formal training; a novice can > bootstrap/cargo-cult something into being pretty easily. > > Adam > > On Thu, Mar 19, 2020 at 8:04 AM Clem Cole wrote: > >> I saw that a while ago. I'd love to know more about the dataset behind >> it >> as Larry asked, >> >> FWIW: Pascal/Delphi being big did not surprise me as it was what was >> taught in the colleges in the 70s. Today they are teaching Python and >> Java so we see generations of new programmers going into the world with >> those skills (like my own daughter). >> >> Larry - I think the way to explain Ada, is that it was very big for a >> while when DoD, DoC and some of DoE when USG bids required it. But as >> fast >> as it rose, it fell pretty fast from favor. >> >> For me, I'm always amazed at things like Javascript and PHP, but their >> rise is directly mapped to people creating web sites. >> >> On Wed, Mar 18, 2020 at 10:34 PM Larry McVoy wrote: >> >>> I'd like to know where the data came from. Ada that big? Says who? >>> >>> On Wed, Mar 18, 2020 at 03:41:22PM -0700, David Barto wrote: >>> > https://www.youtube.com/watch?v=Og847HVwRSI >>> > >>> > It???s kind of amazing how long Pascal hangs on to #1. >>> > And you can watch the ascent of web programming. >>> > >>> > David >>> > _______________________________________________ >>> > 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 >>> _______________________________________________ >>> 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 >> > From tih at hamartun.priv.no Fri Mar 20 22:55:37 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 20 Mar 2020 13:55:37 +0100 Subject: [COFF] Old non-Unix software and manuals. In-Reply-To: (Warner Losh's message of "Sun, 8 Mar 2020 21:39:11 -0600") References: <20200308202230.GB3091@server.rulingia.com> <20200308234812.GA20254@minnie.tuhs.org> Message-ID: Warner Losh writes: > That's why I got a kyroflux... too hard to find an old enough pc that > the floppy controller supports the full range of crazy that once > roamed the earth... For the record: the Adaptec 1542B ISA bus SCSI controller includes a floppy controller that's compatible with the one in the original PC, and which can be programmed in minute detail for tracks, sectors, interleaving, inter-sector gaps, and so forth. I used one of those and a modified NetBSD floppy driver to create boot floppies for my Osborne 1, after downloading images off the net. :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From gtaylor at tnetconsulting.net Sat Mar 21 01:40:50 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 20 Mar 2020 09:40:50 -0600 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> Message-ID: <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> Aside: I'm sending this reply to TUHS where the message that I'm replying to came from. But i suspect that it should migrate to COFF, which I'm CCing. On 3/20/20 5:48 AM, paul at guertin.net wrote: > I teach math in college, and I use an RPN calculator as well (it's > just easier). Would you please elaborate on "it's just easier"? I'm asking from a point of genuine curiosity. I've heard many say that RPN is easier, or that it takes fewer keys, or otherwise superior to infix notation. But many of the conversations end up somewhat devolving into religious like comments about preferences, despite starting with honest open-minded intentions. (I hope this one doesn't similarly devolve.) I've heard that there are fewer keys to press for RPN, but the example equations presented have been effectively he same. I've heard that RPN is mentally easier. But I apparently don't know enough RPN to be able to think in RPN natively to evaluate myself. I dabble with RPN, including keeping my main calculator app on my smart phone in RPN mode. So I am genuinely interested in understanding why you say that RPN is just easier. > Sometimes, during an exam, a student who forgot to bring their > calculator will ask if they can borrow mine. I always say "sure, but > you'll regret it" and hand them the calculator. After wasting one or > two minutes, they give it back. ~chuckle~ > (Note that I always make sure no calculator is needed for my exams, > but it's department policy to authorise non programmable calculators, > and it seems to reassure students to have the calculator on the desk, > so I don't mind.) > ACK -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Sat Mar 21 02:07:39 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 20 Mar 2020 10:07:39 -0600 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> References: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> Message-ID: +COFF On 3/20/20 8:03 AM, Noel Chiappa wrote: > Maybe I'm being clueless/over-asking, but to me it's appalling that > any college student (at least all who have _any_ math requirement at > all; not sure how many that is) doesn't know how an RPN calculator > works. I'm sure that there are some people, maybe not the corpus you mention, that have zero clue how an RPN calculator works. But I would expect anybody with a little gumption to be able to poke a few buttons and probably figure out the basic operation, or, ask if they are genuinely confused. > It's not exactly rocket science, and any reasonably intelligent > high-schooler should get it extremely quickly; just tell them it's > just a representational thing, number number operator instead of > number operator number. I agree that RPN is not rocket science. And for basic single operation equations, I think that it's largely interchangeable with infix notation. However, my experience is, as the number of operations goes up, RPN can become more difficult to use. This is likely a mental shortcoming on my part. But it is something that does take tractable mental effort for me to do. For example, let's start with Pythagorean Theorem a² + b² = c² This is relatively easy to enter in infix notation on a typical scientific calculator. However, I have to stop and think about how to enter this on an RPN calculator. I'll take a swing at this, but I might get it wrong, and I don't have anything handy to test at the moment. [a] [enter] [a] [enter] [multiply] [b] [enter] [b] [enter] [multiply] [add] [square root] # to solve for c (12 keys) Conversely infix notation for comparison. [a] [square] [plus] [b] [square] [square root] (6 keys) As I type this, I realize that I'm using higher order operations (square) in infix than I am in RPN. But that probably speaks to my ignorance of RPN. I also realize that this equation does a poor job at demonstrating what I'm trying to convey. — Or perhaps what I'm trying to convey is incorrect. — I had to arrange sub-different parts of the equation so that their results ended up together on the stack for them to be the targets of the operation. I believe this (re)arrangement of the equation is where most of my mental load / objection comes from with RPN. I feel like I have to process the equation before I can tell the calculator to compute the result for me. I don't feel like I have this burden with infix notation. Aside: I firmly believe that computers are supposed to do our bidding, not the other way around. s/computers/calculators/ > I know it's not a key intellectual skill, but it does seem to me to > be part of comon intellectual heritage that everyone should know, > like musical scales or poetry rhyming. Have you ever considered > taking two minutes (literally!) to cover it briefly, just 'someone > tried to borrow my RPN calculator, here's the basic idea of how they > work'? I'm confident that 80% of people, more of the corpus you describe, could use an RPN calculator to do simple equations. But I would not be surprised if many found that the re-arrangement of equations to being RPN friendly would simply forego the RPN calculator for simpler arithmetic operations. I think some of it is a mental question: Which has more mental load, doing the annoying arithmetic or re-arranging to use RPN. I believe that for the simpler of the arithmetic operations, RPN is going to be more difficult. All of this being said, I'd love to have someone lay out points and / or counterpoints to my understanding. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Sat Mar 21 05:11:10 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Mar 2020 15:11:10 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: Moving to COFF ... On Fri, Mar 20, 2020 at 1:24 PM Grant Taylor via TUHS wrote: > Would you humor me with an example of what you mean by "thinking on the > fly"? Either I'm not understanding you or we think differently. > I'll take a stab at it in a minute. But first, I never cared either way. In college, I had an SR50 and my GF had an HP45. I would say, between my EE friends we were probably split 50/50 between TI and HP. Generally, it was the RPN centric crew were fiercely loyal as in the editor wars but would grab whichever was near me when we all were working a problem set; but I knew a couple of folks that hated RPN too. It's possible, because of my undiagnosed dyslexia at the time, but I would grab the closest calculator, pause to see which is was and then start entering things as needed. But like Jon -- if I had the TI in my hands, I found myself copying the equation. I was trying to pay attention to what button I was pressing to check for any keystroke entry errors. Both types had all of the same math functions so there was little difference in the number of strokes, other than not needing parentheses on HP and how you entered the calculation. With the HP, I was more aware of that equation I was calculating because I was having to make sure I entered it in the proper order so I could get the right answer. In my case, I was probably a tad more careful because I was being forced to thinking in terms of precedence - but I was thinking about the equation. Whereas with the TI I was just hitting the button per the equation on the paper. I typed a tad faster on the TI than the HP because I was not thinking as much but ... I probably made more typing errors there because I thought less about what I was doing. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Sat Mar 21 05:31:29 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 20 Mar 2020 20:31:29 +0100 Subject: [COFF] The most surprising Unix programs In-Reply-To: (Clem Cole's message of "Fri, 20 Mar 2020 15:11:10 -0400") References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: Clem Cole writes: > In my case, I was probably a tad more careful because I was being > forced to thinking in terms of precedence - but I was thinking about > the equation. Whereas with the TI I was just hitting the button per > the equation on the paper. I typed a tad faster on the TI than the HP > because I was not thinking as much but ... I probably made more typing > errors there because I thought less about what I was doing. That sounds like a good summary. I started out on TI programmable calculators (my first was a TI-57 that I still have, and that still works), but moved on to RPN with an HP41CV. Today, I find entering calculations into an RPN calculator simpler, because I naturally think in terms of the stack. With a traditional calculator, I have to look at the (possibly just mentally imaged) formula that I need to evaluate, and type it in character by character, whereas the RPN calculator lets me think about the calculation to be performed, and just enter that. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From gtaylor at tnetconsulting.net Sat Mar 21 05:43:41 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 20 Mar 2020 13:43:41 -0600 Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: On 3/20/20 1:31 PM, Tom Ivar Helbekkmo via COFF wrote: > That sounds like a good summary. I started out on TI programmable > calculators (my first was a TI-57 that I still have, and that still > works), but moved on to RPN with an HP41CV. Today, I find entering > calculations into an RPN calculator simpler, because I naturally > think in terms of the stack. With a traditional calculator, I have > to look at the (possibly just mentally imaged) formula that I need to > evaluate, and type it in character by character, whereas the RPN > calculator lets me think about the calculation to be performed, and > just enter that. Thank you for the comments gentlemen. What I think I'm hearing you say is that with RPN you were shouldering part of the computational load based on how you were entering things so that they aligned as necessary with the stack. Conversely, you were simply "plug and chug" (as I've heard elsewhere). Meaning you entered the equation / formula and were largely hands off from the calculation. Is that accurate? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Sat Mar 21 05:47:44 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 20 Mar 2020 13:47:44 -0600 Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: On 3/20/20 1:43 PM, Grant Taylor via COFF wrote: > What I think I'm hearing you say is that with RPN you were shouldering > part of the computational load based on how you were entering things so > that they aligned as necessary with the stack.  Conversely, you were > simply "plug and chug" (as I've heard elsewhere).  Meaning you entered > the equation / formula and were largely hands off from the calculation. I can see how this could be translated to RPN could cause someone to feel like they have a better understanding of what's being calculated. Conversely, infix notation leaving someone feeling separated from the calculation and having much less of an understanding of what's being calculated. This separation making it more likely that people will have problems estimating and having any idea if what they're doing makes any sense or not. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From terry at jon.es Sat Mar 21 06:10:41 2020 From: terry at jon.es (Terry Jones) Date: Fri, 20 Mar 2020 21:10:41 +0100 Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: I also love RPN, dc, & the HP calculators. I wrote an RPN calculator in Python recently (I call it via a shell alias called pc). It imports much of the math, operator, and builtins modules, so you can use it just like dc, but with much more stuff available: $ pc 200 pi \* log10 sqrt 1.6727760963016285 You can push arbitrary Python objects and functions onto the stack. Install with pip install rpnpy Source at https://github.com/terrycojones/rpnpy Terry On Fri, Mar 20, 2020 at 8:48 PM Grant Taylor via COFF wrote: > On 3/20/20 1:43 PM, Grant Taylor via COFF wrote: > > What I think I'm hearing you say is that with RPN you were shouldering > > part of the computational load based on how you were entering things so > > that they aligned as necessary with the stack. Conversely, you were > > simply "plug and chug" (as I've heard elsewhere). Meaning you entered > > the equation / formula and were largely hands off from the calculation. > > I can see how this could be translated to RPN could cause someone to > feel like they have a better understanding of what's being calculated. > Conversely, infix notation leaving someone feeling separated from the > calculation and having much less of an understanding of what's being > calculated. > > This separation making it more likely that people will have problems > estimating and having any idea if what they're doing makes any sense or > not. > > > > -- > Grant. . . . > unix || die > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Mar 21 06:31:54 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Mar 2020 16:31:54 -0400 Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: On Fri, Mar 20, 2020 at 3:43 PM Grant Taylor via COFF wrote: > Thank you for the comments gentlemen. > Most welcome. > > What I think I'm hearing you say is that with RPN you were shouldering > part of the computational load based on how you were entering things so > that they aligned as necessary with the stack. Conversely, you were > simply "plug and chug" (as I've heard elsewhere). Meaning you entered > the equation / formula and were largely hands off from the calculation. > > Is that accurate? > Fair enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Sat Mar 21 06:33:31 2020 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 20 Mar 2020 16:33:31 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> Message-ID: <15180a7d-fb65-4a1d-913f-4705e0139e70@gmail.com> Hi Grant, On 3/20/20 12:07 PM, Grant Taylor via COFF wrote: > [a] [enter] > [a] [enter] > [multiply] > [b] [enter] > [b] [enter] > [multiply] > [add] > [square root]   # to solve for c > > (12 keys) On an HP calc, it'd actually be: [a] [square] [b] [square] [add] [sqrt] but no win over infix. A noticeable win is that RPN uses no parentheses. Consider (1+2)*3 / ((4-5)/6)) + log(7/8). RPN: 1 2 + 3 * 4 5 - 6 / / 7 8 / log : 15 keystrokes Alg: counting chars above is 25 keystrokes, 26 with a final '='. I'm not so sure that minimized keystrokes are the real win, in any case. Using RPN trains me to quickly see the equation in its decomposed parts. In the end, it's really about what fits best in your head. The world seems to have spoken that infix is preferred - even if RPN users think they know better! :-) I worked with a now-retired engineer who believed everyone should learn first on a slide rule and that there is no better tool for learning sig figs and ballparking answers. He would lecture about it whenever someone put the decimal point in the wrong place and didn't realize it. As a result, next to my old calculators...yup, a few slide rules! Mike Markowski - correct order for Polish operator :-) From tih at hamartun.priv.no Sat Mar 21 06:30:19 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 20 Mar 2020 21:30:19 +0100 Subject: [COFF] The most surprising Unix programs In-Reply-To: (Grant Taylor via COFF's message of "Fri, 20 Mar 2020 13:43:41 -0600") References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: Grant Taylor via COFF writes: > Is that accurate? Yeah, your summary sounds about right. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From clemc at ccc.com Sat Mar 21 06:37:47 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Mar 2020 16:37:47 -0400 Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: On Fri, Mar 20, 2020 at 3:48 PM Grant Taylor via COFF wrote: > I can see how this could be translated to RPN could cause someone to > feel like they have a better understanding of what's being calculated. > Conversely, infix notation leaving someone feeling separated from the > calculation and having much less of an understanding of what's being > calculated. > Maybe. I never really saw it that way, but I can see how someone might think that. If you ever watched a skilled account with an adding machine such as in the old days in an H&R Block tax office -- you will notice they move off their eyes from the paper. Their hands are just typing away, entering digits and hitting the add/subtract/equal keys and they never look at the machine until the end. It can almost be mesmerizing. I could be similar that on a TI calculator, but I never could on an HP. > This separation making it more likely that people will have problems > estimating and having any idea if what they're doing makes any sense or > not. > For some people, that probably is true. But I'm not sure it generalizes. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Mar 21 08:51:07 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Mar 2020 09:51:07 +1100 (EST) Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <6D9CA6C2-BDF2-4BCA-9503-0F8415C594C9@guertin.net> <211b9d54-573c-05d3-2c60-e15a9fc0b86b@tnetconsulting.net> <202003201640.02KGerlG470796@darkstar.fourwinds.com> <0b0d0ba3-7eae-a844-cc9a-ae542edb302b@tnetconsulting.net> Message-ID: On Fri, 20 Mar 2020, Grant Taylor via COFF wrote: > What I think I'm hearing you say is that with RPN you were shouldering > part of the computational load based on how you were entering things so > that they aligned as necessary with the stack. Conversely, you were > simply "plug and chug" (as I've heard elsewhere). Meaning you entered > the equation / formula and were largely hands off from the calculation. > > Is that accurate? You may need parentheses, which not all algebraic calculators have (and the ones that do have limited nesting). Ironic really; either you have to do what RPN users do i.e. work "inside out" if you have a small stack or the calculator has to implement one :-) -- Dave From dave at horsfall.org Sat Mar 21 12:49:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Mar 2020 13:49:27 +1100 (EST) Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: On Thu, 19 Mar 2020, Nemo Nusquam wrote: > Hhmm, back in my early days, the 12C was highly coveted by financial > types. Our mileage differed. I've never seen one (but I've heard of them). Hmmm... The blue "g" key rings a bell from somewhere. > By the way, HP will sell you an Android app'n that looks just like their > venerable (and much missed) calculators. Sell? I downloaded "Free42" for the Mac for free :-) -- Dave From lm at mcvoy.com Sat Mar 21 12:55:22 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 20 Mar 2020 19:55:22 -0700 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: <20200321025522.GA30810@mcvoy.com> On Sat, Mar 21, 2020 at 01:49:27PM +1100, Dave Horsfall wrote: > On Thu, 19 Mar 2020, Nemo Nusquam wrote: > > >Hhmm, back in my early days, the 12C was highly coveted by financial > >types. Our mileage differed. > > I've never seen one (but I've heard of them). Hmmm... The blue "g" key > rings a bell from somewhere. > > >By the way, HP will sell you an Android app'n that looks just like their > >venerable (and much missed) calculators. > > Sell? I downloaded "Free42" for the Mac for free :-) An app will never give you that feelng of touching quality when you pushed the keys. Those were really well made tools. I'm a tool guy, I've got a full on wood working shop (with a ton of old and new hand planes, the new guys are making some good stuff), pretty decent metal working, Logan lathe, stick, mig, plasma, and a full on mechanic shop, up to 3/4" impacts, I do tractors and big trucks. I love tools and an app is not a replacement for putting your fingers on an old HP calc. From dave at horsfall.org Sat Mar 21 13:53:02 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Mar 2020 14:53:02 +1100 (EST) Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> Message-ID: On Fri, 20 Mar 2020, Grant Taylor via COFF wrote: > However, I have to stop and think about how to enter this on an RPN > calculator. I'll take a swing at this, but I might get it wrong, and I > don't have anything handy to test at the moment. > > [a] [enter] > [a] [enter] > [multiply] > [b] [enter] > [b] [enter] > [multiply] > [add] > [square root] # to solve for c [a] [square] [enter] [b] [square] [+] [sqrt] (You don't need those extra "enter" keys, as the display is implicitly the top of the stack.) > (12 keys) 7. Well, "square" also needs the orange "shift" key, so that's really 9, but the number of keystrokes ain't exactly the point; it's not a race, but a method of thinking. > Conversely infix notation for comparison. > > [a] > [square] > [plus] > [b] > [square] > [square root] > > (6 keys) [...] Well, it really comes down to the calculation that you are trying to perform. Trivial example: 1 + 1 = -> 4 keys. 1 enter 1 add -> 4 keys. I don't have an algebraic calculator right to hand, but I'd imagine that solving a second-order polynomial (without a built-in program!) would involve fewer keys when using RPN because of the stack for intermediate results; a quick estimate is around 30 keys (with single-digit numbers) to get one of the roots, and you could probably save the result of most of it on the stack for re-use to get the other root (and the 42S groks complex numbers as a bonus[*], but that's hardly as a result of RPN). The 42S also has a handy "swap x/y" if the operands are the wrong way around, another one to rotate the stack, etc. You don't do Computer Science without being exposed to RPN, and I had to wait for a salary-in-lieu payout (long story) before I could afford the 42S that I'd been drooling over (and forget the overpriced IR printer[#]). [*] 1 +/- SQRT => "0.00 i1.00" (I have the display precision set to 2 because I use it for monetary stuff a lot; the internal precision is 15 digits). [#] A dream of mine is to reverse-engineer the printer protocol, then grab it using a laptop camera. Here endeth today's HP-42S lesson... -- Dave From grog at lemis.com Sat Mar 21 14:01:49 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 21 Mar 2020 15:01:49 +1100 Subject: [COFF] HP calculator emulators (was: The most surprising Unix programs) In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: <20200321040149.GE48737@eureka.lemis.com> On Saturday, 21 March 2020 at 13:49:27 +1100, Dave Horsfall wrote: > On Thu, 19 Mar 2020, Nemo Nusquam wrote: >> By the way, HP will sell you an Android app'n that looks just like their >> venerable (and much missed) calculators. > > Sell? I downloaded "Free42" for the Mac for free :-) In fact, there are a surprising number. I've downloaded free42, 48sx hp67 calculator. All would do what I need, but I found that 48sx has the prettiest interface. It almost looks better than the original. 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 paul at guertin.net Sat Mar 21 14:11:04 2020 From: paul at guertin.net (Paul Guertin) Date: Sat, 21 Mar 2020 00:11:04 -0400 Subject: [COFF] [TUHS] The most surprising Unix programs In-Reply-To: References: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> Message-ID: Dixit Dave Horsfall (2020-03-20 11:53 p.m.): > A dream of mine is to reverse-engineer the printer protocol, then grab it > using a laptop camera. You might find this interesting: http://www.mh-aerotools.de/hp/red-eye/HP-IR%20Receiver%20with%20Arduino.pdf Paul Guertin From tih at hamartun.priv.no Sat Mar 21 17:21:49 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Sat, 21 Mar 2020 08:21:49 +0100 Subject: [COFF] The most surprising Unix programs In-Reply-To: (Dave Horsfall's message of "Sat, 21 Mar 2020 13:49:27 +1100") References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: Dave Horsfall writes: > Sell? I downloaded "Free42" for the Mac for free :-) Free42 works great on lots of platforms, including Android - and it also powers the HP-42S clone from these guys: https://www.swissmicros.com/ -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From mparson at bl.org Sun Mar 22 07:10:51 2020 From: mparson at bl.org (Michael Parson) Date: Sat, 21 Mar 2020 16:10:51 -0500 (CDT) Subject: [COFF] The most surprising Unix programs In-Reply-To: References: <202003132331.02DNVaxN061501@tahoe.cs.Dartmouth.EDU> <7ec47fd97b1a3d383ffed428f21f5287@firemail.cc> <15976a67-1666-9ae9-99c1-e0a09ffba360@gmail.com> Message-ID: On Sat, 21 Mar 2020, Tom Ivar Helbekkmo via COFF wrote: > Dave Horsfall writes: > >> Sell? I downloaded "Free42" for the Mac for free :-) > > Free42 works great on lots of platforms, including Android - and it also > powers the HP-42S clone from these guys: https://www.swissmicros.com/ I have 'go48g' on my android, mostly for nostalgia, I've forgotten how to use most of the features of it. The 48gx was my first HP calc long ago, still have it, though it is currently in pieces as I am (slowly) attempting to perform some repairs on it. My go-to calculator on my (android) phone is simply called 'RPN Calculator' and I use 'dc' when logged into *nix. I made fun of friends that used HP calculators for a long time, until I started using it. Once I wrapped my head around RPN, it just felt "better." But, like text editors, keyboard layouts, etc... to each his/her own, use what you know and can get work done with. -- Michael Parson Pflugerville, TX KF5LGQ From ama at ugr.es Mon Mar 23 00:13:07 2020 From: ama at ugr.es (Angel M Alganza) Date: Sun, 22 Mar 2020 15:13:07 +0100 Subject: [COFF] Discord channels for COFF/TUHS In-Reply-To: <20200209201709.GA23015@minnie.tuhs.org> References: <20200209003953.GA7353@minnie.tuhs.org> <20200209201709.GA23015@minnie.tuhs.org> Message-ID: <20200322141307.4mtoh7kan6ylwamr@morgan.ugr.es> Hello, On Mon, Feb 10, 2020 at 06:17:09AM +1000, Warren Toomey wrote: >On Sun, Feb 09, 2020 at 10:39:53AM +1000, Warren Toomey wrote: >COFF: https://discord.gg/qebJXw >TUHS: https://discord.gg/BdmzZP Are those channles still active? The links seem to be expired. Care to share new links, please? Regards, Ángel From krewat at kilonet.net Mon Mar 23 02:17:24 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 22 Mar 2020 12:17:24 -0400 Subject: [COFF] What sort of "hard drive" is this? Message-ID: <093be7e4-e2da-878d-86a1-aa6cef230b84@kilonet.net> Doesn't ring any bells for me, so probably not DEC up to a certain point. https://www.surplusshed.com/pages/item/R1111.html art k. From wkt at tuhs.org Mon Mar 23 06:22:13 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 23 Mar 2020 06:22:13 +1000 Subject: [COFF] Discord channels for COFF/TUHS In-Reply-To: <20200322141307.4mtoh7kan6ylwamr@morgan.ugr.es> References: <20200209003953.GA7353@minnie.tuhs.org> <20200209201709.GA23015@minnie.tuhs.org> <20200322141307.4mtoh7kan6ylwamr@morgan.ugr.es> Message-ID: <20200322202213.GB32609@minnie.tuhs.org> > On Mon, Feb 10, 2020 at 06:17:09AM +1000, Warren Toomey wrote: > > COFF: https://discord.gg/qebJXw > > TUHS: https://discord.gg/BdmzZP > On Sun, Mar 22, 2020 at 03:13:07PM +0100, Angel M Alganza wrote: > Are those channles still active? > The links seem to be expired. > Care to share new links, please? Sure thing, Ángel. Try these: COFF: https://discord.gg/sbb8jEX TUHS: https://discord.gg/BeepU4Y Cheers, Warren From crossd at gmail.com Tue Mar 31 09:23:27 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Mar 2020 19:23:27 -0400 Subject: [COFF] Vint Cerf tests positive for COVID-19. Message-ID: He announced it on Twitter. I'm sure we all wish him well and a speedy recovery. Note, his tweet says that he is recovering. https://twitter.com/vgcerf/status/1244636584508604417?s=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Mar 31 13:13:45 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 31 Mar 2020 14:13:45 +1100 (EST) Subject: [COFF] [TUHS] Vint Cerf tests positive for COVID-19. In-Reply-To: References: Message-ID: On Mon, 30 Mar 2020, Dan Cross wrote: > He announced it on Twitter. I'm sure we all wish him well and a speedy > recovery. Note, his tweet says that he is recovering. Indeed. On a whim I did a search for him, and got: Get Vint Cerf With Fast and Free Shipping on eBay. Looking For Vint Cerf? We Have Almost Everything on eBay. I'm sure that he'll be happy to hear that... -- Dave