From txomsy at yahoo.es Sat Feb 1 04:21:36 2020 From: txomsy at yahoo.es (Jose R. Valverde) Date: Fri, 31 Jan 2020 19:21:36 +0100 Subject: [TUHS] Screen editors In-Reply-To: <20200120162008.GE28686@mcvoy.com> References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200120162008.GE28686@mcvoy.com> Message-ID: <20200131192136.6f3b1bb6@sagittariusA.cnb.csic.es> I may have a digitized copy of the book, but don't bet on it. Some years ago I decided I wanted to have an electronic copy of some of my books so I could peruse them more easily, In the end I think I only got around digitizing a couple of them. This was also after I had lent a great book on Logo with plenty of algorithms on (old-style) AI and never got it back. Didn't know Miller had come into Bioinformatics as well (or if I did, I didn't connect him to the book). I've been on Bioinformatics since '84. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es From dbrock at computerhistory.org Tue Feb 4 07:01:34 2020 From: dbrock at computerhistory.org (David C. Brock) Date: Mon, 3 Feb 2020 21:01:34 +0000 Subject: [TUHS] Oral history interview with Doug McIlroy Message-ID: <4B4A388452D2A7418879B110A352A8F401888068A7@EX-MB1.hq.computerhistory.org> With Doug’s permission, I’d like to bring the group’s attention to a recent oral history with him by the Computer History Museum. You can find the records for the two interviews here, and in them the links to the PDF transcripts: https://www.computerhistory.org/collections/oralhistories/?s=mcilroy As I am sure you can imagine, it was a great pleasure to interview Doug. I learned a tremendous amount. Best wishes, David .............. David C. Brock Director and Curator Software History Center Computer History Museum computerhistory.org/softwarehistory Email: dbrock at computerhistory.org Twitter: @dcbrock Skype: dcbrock 1401 N. Shoreline Blvd. Mountain View, CA 94943 (650) 810-1010 main (650) 810-1886 direct Pronouns: he, him, his From ik at sjmulder.nl Tue Feb 4 18:40:18 2020 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Tue, 4 Feb 2020 09:40:18 +0100 Subject: [TUHS] screen editors In-Reply-To: <1iqMuL-1zK-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> Message-ID: <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> markus schnalke wrote: > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > ``vee-eye''), is that what you english speakers do? To me (a > native German speaker) it naturally was ``ed'' (like ``sam''). > As reference some Computerphile video is given, which is now > deleted. Is there a better source? Dutch speaker. ed: Hi Ed vi: C'est la vie Bonus: chroot: shroot These may not be the proper pronunciations but I like the names best this way. Sijmen From g.branden.robinson at gmail.com Wed Feb 5 06:14:56 2020 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 5 Feb 2020 07:14:56 +1100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> Message-ID: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > markus schnalke wrote: > > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > > ``vee-eye''), is that what you english speakers do? Certainly not. When one sees a command name that duplicates a frequently-used diminituve of a common name, the brain is going to select that preferentially. Naming your Unix command "mike" and expecting people to pronounce it "em-eye-kay-ee" is hopeless. > Dutch speaker. > > ed: Hi Ed > vi: C'est la vie In English, thanks to the Great Vowel Shift and other developments that differentiated vowel pronunciation from the continent a few hundred years ago, trailing "I"s tend to be pronounced long (as in "eye")--but they also tend to be rare. They occur in proper names like Lodi, California and Bondi, Australia (which Americans sometimes mis-pronounce anyway, perhaps influenced by Spanish). A word that looks borrowed from Latin, Greek, or Spanish will often get back its "-ee" sound for a trailing "i", but the two-letter command names beloved of the Unix pioneers offer no etymological hints. > Bonus: > > chroot: shroot > > These may not be the proper pronunciations but I like the names best > this way. I had to teach myself Unix in the early days and so I wound up with some idiolectal variants that people consider amusing or objectionable: chroot: cheroot (like the cigar) chown: rhymes with "clown" chmod: rhymes with "god" or "scrod" (a kind of fish), and resists the introduction of a vowel into the leading consonant cluster as much as possible--it's an ugly one! creat: Crete (hic Rhodus, hic salta!) fuser: fuser (like the component of a laser printer--not "eff-user"; eff that) groff: Groff (like the surname, not "jee-roff") troff: trough (but nroff I pronounce the accepted way) (And did people really say "dee-eye-tee-roff" for "ditroff"?) There are a couple of others that I started out pronouncing in a nonstandard way, but once I started attending conferences, I assimilated: Linux: originally "lye-nucks", now "linn-ucks" Debian: originally "Dee-bee-un", now "Deb-ee-un" I've heard many other newcomers make the same inferences I did in these last two cases. I would editorialize on the fetishization of terseness in textual interface design[1], but I have to locate my APL typeball. Regards, Branden [1] A terseness that is hurled away with great enthusiasm by the maintainers of many libraries written in C, who, facing an unanticipated need, pile yet another damn parameter onto their hapless function calls. Six, seven parameters? Keep 'em coming. Consistency of ordering between commonly-used arguments in the same library? Hell no! Structs and pointers to structs are only for getting yourself into trouble with. Remember: always mistrust your compiler and copy a struct element by element, and only use structure pointers for dangling reference mischief, never to simplify your function calls. Always prematurely optimize except when spilling registers between stack frames on IA-32. But be sure and -fomit-frame-pointer so your mess is even harder to clean up! Every register is precious except the ones you wasted on your yard-long parameter list. Guess I got an editorial in after all. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dave at horsfall.org Wed Feb 5 06:26:04 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Feb 2020 07:26:04 +1100 (EST) Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: References: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu> Message-ID: [ Getting into COFF territory, I think ] On Thu, 30 Jan 2020, Clem Cole wrote: > BTW: Dave story is fun, but I think a tad apocryphal.  He's right that > DEC marketing was not happy about people using it, but it was well > spec'ed if you had CPU schematics.  They way they tried to control it > was to license the bus interface chips (made privately by Western > Digital for them IIRC but were not available on the open market).  IIRC > if you did not use DEC's chips, you could have issues if you >>similar<< > function chips from National Semi.  I remember Ken O'Munhundro giving a > talk at a USENIX (while he was CEO of Able) talking about 'be careful > with foreign UNIBUS implementations.'  If I recall it was the analog > characteristics that were tricky with something like the BUS acquisition > for DMA and Memory timing, but I admit I've forgotten the details. Ah; the chips could explain it. I can't remember where I heard the story, but it was likely in ";login:" or some place. Hey, if the DEC marketoids didn't want 3rd-party UNIBUS implementations then why was it published? > I think you are confusing VAX's SBI with UNIBUS.   With the Vax, unlike > PDP-11, the systems did not come with complete schematics for all > boards.   So to design for the SBI you had to reverse engineer the CPU > and Memory boards.   DEC having successfully won the CalData suit, went > after Systems Industries who was the first to build SBI controllers.  >  DEC lost, but the truth was that because they had work had been reverse > engineering, SI was close but not 100% right and they had a number of > issues when the boards first hit the street, particularly with UNIX > which did a better job of overlapped I/O than VMS did.   At UCB we had a > logic analyzer in one of the 780s at all times, and the phone number of > the SI engineers.   We eventually helped them put out a couple ECO's > that make the original boards work in practice much better. No; it was definitely UNIBUS (I wasn't aware of the SBI at the time). As for overlapped seeks, when they were implemented in Unix it broke the RK-11 controller, and DEC pointed the finger at Unix (of course) since their own gear worked. To cut a long story short, they were forced to use some fancy diagnostic (DECEX?) which hammered everything at the same time, and the problem showed up. Turned out that their simpler diagnostics did not test for overlapped seeks, because they knew that it didn't work; out same the FE to modify the controller... > BTW: My friend Dave Cane lead the BI at DEC after finishing up the > VAX/750 project (he had designed the SBI for 780 before that).   In > fact, the BI was >>supposed<< to be 'open' like Multibus and VME and all > chips were supposed to be from the merchant market.  But at the last > minute, DEC marketing refused and locked down the specs/stopped shipping > schematics with the new systems destined to use BI.  Dave was so pissed, > he left DEC to found Masscomp and design the MC500 (using the > Multibus).    Yet another reason why DEC went under, I guess... -- Dave From dave at horsfall.org Wed Feb 5 07:05:55 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Feb 2020 08:05:55 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> Message-ID: On Wed, 5 Feb 2020, G. Branden Robinson wrote: >>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >>> ``vee-eye''), is that what you english speakers do? > > Certainly not. When one sees a command name that duplicates a > frequently-used diminituve of a common name, the brain is going to > select that preferentially. Being British/Australian, I say "ee-dee" and "vee-eye", as they are not really English words. Similarly, I say "ee-max" etc. > Naming your Unix command "mike" and expecting people to pronounce it > "em-eye-kay-ee" is hopeless. In that case I would pronounce it as "myke". > In English, thanks to the Great Vowel Shift and other developments that > differentiated vowel pronunciation from the continent a few hundred > years ago, trailing "I"s tend to be pronounced long (as in "eye")--but > they also tend to be rare. They occur in proper names like Lodi, > California and Bondi, Australia (which Americans sometimes mis-pronounce > anyway, perhaps influenced by Spanish). A word that looks borrowed from > Latin, Greek, or Spanish will often get back its "-ee" sound for a > trailing "i", but the two-letter command names beloved of the Unix > pioneers offer no etymological hints. You should hear Americans pronounce the Australian cities of Brisbane and Melbourne. Also, Wagga Wagga totally throws them (it's pronounced simly as "Wogguh" here). > I had to teach myself Unix in the early days and so I wound up with some > idiolectal variants that people consider amusing or objectionable: OK... > chroot: cheroot (like the cigar) > chown: rhymes with "clown" > chmod: rhymes with "god" or "scrod" (a kind of fish), and resists the > introduction of a vowel into the leading consonant cluster as > much as possible--it's an ugly one! OK so far... > creat: Crete (hic Rhodus, hic salta!) cree-AT. > fuser: fuser (like the component of a laser printer--not "eff-user"; eff > that) eff-user, so take that :-) > groff: Groff (like the surname, not "jee-roff") jee-roff. > troff: trough (but nroff I pronounce the accepted way) tee-roff. And, err, how would you pronounce "nroff"? > (And did people really say "dee-eye-tee-roff" for "ditroff"?) Likely "dee-eye-troff". > There are a couple of others that I started out pronouncing in a > nonstandard way, but once I started attending conferences, I > assimilated: > > Linux: originally "lye-nucks", now "linn-ucks" Lee-nux. > Debian: originally "Dee-bee-un", now "Deb-ee-un" du-BEE-un. -- Dave From dfawcus+lists-tuhs at employees.org Wed Feb 5 07:52:52 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 4 Feb 2020 21:52:52 +0000 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> Message-ID: <20200204215252.GA99776@clarinet.employees.org> On Wed, Feb 05, 2020 at 08:05:55AM +1100, Dave Horsfall wrote: > > troff: trough (but nroff I pronounce the accepted way) > > tee-roff. And, err, how would you pronounce "nroff"? > > > (And did people really say "dee-eye-tee-roff" for "ditroff"?) > > Likely "dee-eye-troff". tee-roff, en-roff, dit-roff DF From robpike at gmail.com Wed Feb 5 09:27:29 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 5 Feb 2020 10:27:29 +1100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200204215252.GA99776@clarinet.employees.org> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> Message-ID: Unix room pronunciation: ed: Ed or E.D.; both were common chroot: cheroot chgrp: ch-group chown: rhymes with "clone" chmod: rhymes with "god" creat: cree-at nroff: enn-roff (because it was the descendant of roff) troff: tee-roff vi: (for those few who used it) V.I. I pronounced it V.I. but often thought of Roman numerals. Also a side note about vi: Plan 9 had another program with that name. http://man.cat-v.org/plan_9/1/vi. The 'v' meant mips for obscure but consistent reasons. Yet another reason the command was pronounced V.I. regardless of its function. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Feb 5 13:34:56 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Feb 2020 04:34:56 +0100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> Message-ID: On Tue, Feb 4, 2020, 4:28 PM Rob Pike wrote: > Unix room pronunciation: > > ed: Ed or E.D.; both were common > chroot: cheroot > chgrp: ch-group > chown: rhymes with "clone" > chmod: rhymes with "god" > creat: cree-at > nroff: enn-roff (because it was the descendant of roff) > troff: tee-roff > vi: (for those few who used it) V.I. I pronounced it V.I. but often > thought of Roman numerals. > Those match the way I heard them at school in the 80s... Warner Also a side note about vi: Plan 9 had another program with that name. > http://man.cat-v.org/plan_9/1/vi. The 'v' meant mips for obscure but > consistent reasons. Yet another reason the command was pronounced V.I. > regardless of its function. > > -rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Feb 5 18:45:13 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 05 Feb 2020 01:45:13 -0700 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> Message-ID: <202002050845.0158jDOu024559@freefriends.org> "G. Branden Robinson" wrote: > At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > > markus schnalke wrote: > > > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > > > ``vee-eye''), is that what you english speakers do? > > Certainly not. When one sees a command name that duplicates a > frequently-used diminituve of a common name, the brain is going to > select that preferentially. ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and the other two-letter commands. > (And did people really say "dee-eye-tee-roff" for "ditroff"?) I did ... Although it's "groff" and not "g-roff". :-) FWIW, Arnold From aap at papnet.eu Wed Feb 5 19:49:44 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 5 Feb 2020 10:49:44 +0100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> Message-ID: <20200205094944.GA68360@indra.papnet.eu> On 05/02/20, Rob Pike wrote: > Also a side note about vi: Plan 9 had another program with that name. > http://man.cat-v.org/plan_9/1/vi. The 'v' meant mips for obscure but > consistent reasons. Yet another reason the command was pronounced V.I. > regardless of its function. Actually now i wonder, was there a system behind those characters? These are all i could find (roughly in order of appearance): 2 68020 8 i386 v mips k sparc z hobbit 6 i960 x AT&T 3210 1 68000 9 AMD 29000 q ppc 7 alpha 5 ARM (7500) 6 amd64 9 ppc64 0 mips little endian There's a '2' in '68020' and an '8' in '386' and maybe i can understand 'k' as sparK, but why is v mips or q powerpc? aap From ralph at inputplus.co.uk Wed Feb 5 20:58:13 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 05 Feb 2020 10:58:13 +0000 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> Message-ID: <20200205105813.5FF71207F5@orac.inputplus.co.uk> Hi Rob, > nroff: enn-roff (because it was the descendant of roff) > troff: tee-roff One I've wondered about for a long time is ditroff. What was that? 1. die-tee-roff 2. dee-eye-tee-roff 3. ditt-roff 4. die-troff 5. Something else... -- Cheers, Ralph. From robpike at gmail.com Wed Feb 5 21:40:51 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 5 Feb 2020 22:40:51 +1100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200205094944.GA68360@indra.papnet.eu> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> <20200205094944.GA68360@indra.papnet.eu> Message-ID: Pretty sure q came first and was resurrected later. The system, applied rigorously, was to pick something that worked without conflict each time. Ken usually picked. -rob On Wed, Feb 5, 2020 at 8:50 PM Angelo Papenhoff wrote: > On 05/02/20, Rob Pike wrote: > > Also a side note about vi: Plan 9 had another program with that name. > > http://man.cat-v.org/plan_9/1/vi. The 'v' meant mips for obscure but > > consistent reasons. Yet another reason the command was pronounced V.I. > > regardless of its function. > > Actually now i wonder, was there a system behind those characters? > These are all i could find (roughly in order of appearance): > 2 68020 > 8 i386 > v mips > k sparc > z hobbit > 6 i960 > x AT&T 3210 > 1 68000 > 9 AMD 29000 > q ppc > 7 alpha > 5 ARM (7500) > 6 amd64 > 9 ppc64 > 0 mips little endian > > There's a '2' in '68020' and an '8' in '386' and maybe i can understand > 'k' as sparK, but why is v mips or q powerpc? > > aap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Wed Feb 5 21:43:02 2020 From: brantley at coraid.com (Brantley Coile) Date: Wed, 5 Feb 2020 11:43:02 +0000 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> <20200205094944.GA68360@indra.papnet.eu> Message-ID: Did the NS32032 have a character? If so, what was it? Brantley > On Feb 5, 2020, at 6:40 AM, Rob Pike wrote: > > Pretty sure q came first and was resurrected later. The system, applied rigorously, was to pick something that worked without conflict each time. Ken usually picked. > > -rob > > > On Wed, Feb 5, 2020 at 8:50 PM Angelo Papenhoff wrote: > On 05/02/20, Rob Pike wrote: > > Also a side note about vi: Plan 9 had another program with that name. > > http://man.cat-v.org/plan_9/1/vi. The 'v' meant mips for obscure but > > consistent reasons. Yet another reason the command was pronounced V.I. > > regardless of its function. > > Actually now i wonder, was there a system behind those characters? > These are all i could find (roughly in order of appearance): > 2 68020 > 8 i386 > v mips > k sparc > z hobbit > 6 i960 > x AT&T 3210 > 1 68000 > 9 AMD 29000 > q ppc > 7 alpha > 5 ARM (7500) > 6 amd64 > 9 ppc64 > 0 mips little endian > > There's a '2' in '68020' and an '8' in '386' and maybe i can understand > 'k' as sparK, but why is v mips or q powerpc? > > aap From robpike at gmail.com Wed Feb 5 21:45:09 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 5 Feb 2020 22:45:09 +1100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200205105813.5FF71207F5@orac.inputplus.co.uk> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <20200204215252.GA99776@clarinet.employees.org> <20200205105813.5FF71207F5@orac.inputplus.co.uk> Message-ID: I think we called it troff, because that's what it was. Brian might remember if it was ever used widely with the prefix. I don't think it was, within 1127. That spelling doesn't appear anywhere in the Research Unix manuals for v8, v9, or v10. -rob On Wed, Feb 5, 2020 at 10:06 PM Ralph Corderoy wrote: > Hi Rob, > > > nroff: enn-roff (because it was the descendant of roff) > > troff: tee-roff > > One I've wondered about for a long time is ditroff. > What was that? > > 1. die-tee-roff > 2. dee-eye-tee-roff > 3. ditt-roff > 4. die-troff > 5. Something else... > > -- > Cheers, Ralph. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 5 23:35:07 2020 From: clemc at ccc.com (Clem cole) Date: Wed, 5 Feb 2020 08:35:07 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <202002050845.0158jDOu024559@freefriends.org> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I smiled one time when I heard some one call it “f-sick” but that was not considered the proper pronunciation. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: > > "G. Branden Robinson" wrote: > >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: >>> markus schnalke wrote: >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >>>> ``vee-eye''), is that what you english speakers do? >> >> Certainly not. When one sees a command name that duplicates a >> frequently-used diminituve of a common name, the brain is going to >> select that preferentially. > > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > the other two-letter commands. > >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) > > I did ... Although it's "groff" and not "g-roff". :-) > > FWIW, > > Arnold From rdm at cfcl.com Thu Feb 6 01:05:24 2020 From: rdm at cfcl.com (Rich Morin) Date: Wed, 5 Feb 2020 07:05:24 -0800 Subject: [TUHS] keyboards and command names Message-ID: I have always suspected that the brevity of the Unix command names was strongly influenced by the clunky keyboards on the teletypes that were being used. Can anyone confirm, deny, and/or comment on this? -r From jaapna at xs4all.nl Thu Feb 6 01:30:24 2020 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Wed, 5 Feb 2020 16:30:24 +0100 Subject: [TUHS] keyboards and command names In-Reply-To: References: Message-ID: <1FE9FA5C-9802-4DAB-9814-3D15BBA2D10E@xs4all.nl> > I have always suspected that the brevity of the Unix command names was strongly > influenced by the clunky keyboards on the teletypes that were being used. Can > anyone confirm, deny, and/or comment on this? Peter Collinson made the same observation at the 25th year celebration of UNIX (USENIX, Washington) and it was confirmed by dmr. jaap From jpl.jpl at gmail.com Thu Feb 6 01:47:21 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 5 Feb 2020 10:47:21 -0500 Subject: [TUHS] keyboards and command names In-Reply-To: <1FE9FA5C-9802-4DAB-9814-3D15BBA2D10E@xs4all.nl> References: <1FE9FA5C-9802-4DAB-9814-3D15BBA2D10E@xs4all.nl> Message-ID: I of course defer to dmr about the major influence, but I very much appreciated the brevity when printing programs and shell scripts and lines in ed at 110 baud, even with a terminal having a respectable keyboard. I printed much more than I entered. On Wed, Feb 5, 2020 at 10:38 AM Jaap Akkerhuis wrote: > > > > I have always suspected that the brevity of the Unix command names was > strongly > > influenced by the clunky keyboards on the teletypes that were being > used. Can > > anyone confirm, deny, and/or comment on this? > > Peter Collinson made the same observation at the 25th year celebration > of UNIX (USENIX, Washington) and it was confirmed by dmr. > > jaap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Feb 6 02:11:15 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 5 Feb 2020 11:11:15 -0500 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: Bunch of guys at Computer Graphics Lab (at New York Institute of Technology) back in the 80's used to call it "f-suck". On 2/5/2020 8:35 AM, Clem cole wrote: > FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I smiled one time when I heard some one call it “f-sick” but that was not considered the proper pronunciation. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: >> >> "G. Branden Robinson" wrote: >> >>> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: >>>> markus schnalke wrote: >>>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >>>>> ``vee-eye''), is that what you english speakers do? >>> Certainly not. When one sees a command name that duplicates a >>> frequently-used diminituve of a common name, the brain is going to >>> select that preferentially. >> ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and >> the other two-letter commands. >> >>> (And did people really say "dee-eye-tee-roff" for "ditroff"?) >> I did ... Although it's "groff" and not "g-roff". :-) >> >> FWIW, >> >> Arnold > From clemc at ccc.com Thu Feb 6 02:16:30 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 11:16:30 -0500 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: definitely a diminutive term. On Wed, Feb 5, 2020 at 11:11 AM Arthur Krewat wrote: > Bunch of guys at Computer Graphics Lab (at New York Institute of > Technology) back in the 80's used to call it "f-suck". > > > > On 2/5/2020 8:35 AM, Clem cole wrote: > > FWIW. When it was written, Ted and I used pronounced it as “fisk” > (rhymes with “disk”), but F. S. C. K. was always acceptable to my ears. I > admit I smiled one time when I heard some one call it “f-sick” but that was > not considered the proper pronunciation. > > > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite. > > > >> On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: > >> > >> "G. Branden Robinson" wrote: > >> > >>> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > >>>> markus schnalke wrote: > >>>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > >>>>> ``vee-eye''), is that what you english speakers do? > >>> Certainly not. When one sees a command name that duplicates a > >>> frequently-used diminituve of a common name, the brain is going to > >>> select that preferentially. > >> ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > >> the other two-letter commands. > >> > >>> (And did people really say "dee-eye-tee-roff" for "ditroff"?) > >> I did ... Although it's "groff" and not "g-roff". :-) > >> > >> FWIW, > >> > >> Arnold > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 6 02:18:59 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 11:18:59 -0500 Subject: [TUHS] keyboards and command names In-Reply-To: References: <1FE9FA5C-9802-4DAB-9814-3D15BBA2D10E@xs4all.nl> Message-ID: even at 120 cps, i agree. On Wed, Feb 5, 2020 at 10:47 AM John P. Linderman wrote: > I of course defer to dmr about the major influence, but I very much > appreciated the brevity when printing programs and shell scripts and lines > in ed at 110 baud, even with a terminal having a respectable keyboard. I > printed much more than I entered. > > On Wed, Feb 5, 2020 at 10:38 AM Jaap Akkerhuis wrote: > >> >> >> > I have always suspected that the brevity of the Unix command names was >> strongly >> > influenced by the clunky keyboards on the teletypes that were being >> used. Can >> > anyone confirm, deny, and/or comment on this? >> >> Peter Collinson made the same observation at the 25th year celebration >> of UNIX (USENIX, Washington) and it was confirmed by dmr. >> >> jaap >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Feb 6 03:05:35 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 05 Feb 2020 09:05:35 -0800 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> Clem Cole writes: > definitely a diminutive term.    > > On Wed, Feb 5, 2020 at 11:11 AM Arthur Krewat wrote: > > Bunch of guys at Computer Graphics Lab (at New York Institute of > Technology) back in the 80's used to call it "f-suck". > > On 2/5/2020 8:35 AM, Clem cole wrote: > > FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes > with “disk”), but F. S. C. K. was always acceptable to my ears.  I admit I > smiled one time when I heard some one call it “f-sick” but that was not > considered the proper pronunciation. I always pronounced it "fisk" and am happy that newer filesystems have minimized the need for a stop-and-fisk policy. Jon From clemc at ccc.com Thu Feb 6 03:09:34 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 12:09:34 -0500 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> Message-ID: indeed. On Wed, Feb 5, 2020 at 12:06 PM Jon Steinhart wrote: > Clem Cole writes: > > definitely a diminutive term. > > > > On Wed, Feb 5, 2020 at 11:11 AM Arthur Krewat > wrote: > > > > Bunch of guys at Computer Graphics Lab (at New York Institute of > > Technology) back in the 80's used to call it "f-suck". > > > > On 2/5/2020 8:35 AM, Clem cole wrote: > > > FWIW. When it was written, Ted and I used pronounced it as “fisk” > (rhymes > > with “disk”), but F. S. C. K. was always acceptable to my ears. I > admit I > > smiled one time when I heard some one call it “f-sick” but that was > not > > considered the proper pronunciation. > > I always pronounced it "fisk" and am happy that newer > filesystems have minimized the need for a stop-and-fisk policy. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 6 05:08:00 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Feb 2020 06:08:00 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <202002050845.0158jDOu024559@freefriends.org> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: [ Did not see the OP's post ] > "G. Branden Robinson" wrote: > >> Certainly not. When one sees a command name that duplicates a >> frequently-used diminituve of a common name, the brain is going to >> select that preferentially. Yours might but mine doesn't so please don't generalise. At my age (67) and computer experience (nearly 50 years) I take things like context into account and don't anthropomorphise things. [ Arnold ] > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > the other two-letter commands. Which is what I call them. -- Dave From jon at fourwinds.com Thu Feb 6 05:16:46 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 05 Feb 2020 11:16:46 -0800 Subject: [TUHS] System Call History Message-ID: <202002051916.015JGldn3233910@darkstar.fourwinds.com> Does anybody have or know of a list of system calls that describes when and what version of UNIX (and descendents) they were added? Thanks, Jon From dave at horsfall.org Thu Feb 6 05:37:55 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Feb 2020 06:37:55 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, 5 Feb 2020, Clem cole wrote: > FWIW. When it was written, Ted and I used pronounced it as “fisk” > (rhymes with “disk”), but F. S. C. K. was always acceptable to my ears. > I admit I smiled one time when I heard some one call it “f-sick” but > that was not considered the proper pronunciation. I've heard it pronounced as "fuzz-chuck" (!). Me, it's eff-ess-see-kay. -- Dave From clemc at ccc.com Thu Feb 6 05:57:07 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 14:57:07 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, Feb 5, 2020 at 2:38 PM Dave Horsfall wrote: > On Wed, 5 Feb 2020, Clem cole wrote: > > > FWIW. When it was written, Ted and I used pronounced it as “fisk” > > (rhymes with “disk”), but F. S. C. K. was always acceptable to my ears. > > I admit I smiled one time when I heard some one call it “f-sick” but > > that was not considered the proper pronunciation. > > I've heard it pronounced as "fuzz-chuck" (!). sigh... > Me, it's eff-ess-see-kay. Yeah, that's one's acceptable and as I said above, doesn't bother me. However, fisk is the 'one true' way ;-) I can see where people came from often by what they call things. That said, the program long left the barn and has its own history. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Thu Feb 6 06:26:13 2020 From: davida at pobox.com (David Arnold) Date: Thu, 6 Feb 2020 07:26:13 +1100 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> References: <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> Message-ID: <18D9E847-C36E-40FA-8AC9-BA13EA3E3066@pobox.com> The group I Unix with pronounce it fiss-ick, falling back to f-s-c-k if that provokes a blank stare. d > On 6 Feb 2020, at 04:07, Jon Steinhart wrote: > > Clem Cole writes: >> definitely a diminutive term. >> >> On Wed, Feb 5, 2020 at 11:11 AM Arthur Krewat wrote: >> >> Bunch of guys at Computer Graphics Lab (at New York Institute of >> Technology) back in the 80's used to call it "f-suck". >> >>> On 2/5/2020 8:35 AM, Clem cole wrote: >>> FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes >> with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I >> smiled one time when I heard some one call it “f-sick” but that was not >> considered the proper pronunciation. > > I always pronounced it "fisk" and am happy that newer > filesystems have minimized the need for a stop-and-fisk policy. > > Jon From robpike at gmail.com Thu Feb 6 06:50:58 2020 From: robpike at gmail.com (Rob Pike) Date: Thu, 6 Feb 2020 07:50:58 +1100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, fuck, for good reason, but he soon realized it was going to be used by others and changed one letter. It was just letters after that. -rob On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes > with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I > smiled one time when I heard some one call it “f-sick” but that was not > considered the proper pronunciation. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite. > > > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: > > > > "G. Branden Robinson" wrote: > > > >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > >>> markus schnalke wrote: > >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > >>>> ``vee-eye''), is that what you english speakers do? > >> > >> Certainly not. When one sees a command name that duplicates a > >> frequently-used diminituve of a common name, the brain is going to > >> select that preferentially. > > > > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > > the other two-letter commands. > > > >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) > > > > I did ... Although it's "groff" and not "g-roff". :-) > > > > FWIW, > > > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Feb 6 07:01:54 2020 From: cym224 at gmail.com (Nemo) Date: Wed, 5 Feb 2020 16:01:54 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On 05/02/2020, Dave Horsfall wrote (in part): >> ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and >> the other two-letter commands. > > Which is what I call them. Well, I am clearly the odd-ball here. I spoke them "long-hand" (as in remove, link, move, change-mode, ...). Others copied but only once did a young 'un start typing c-h-a-n ... N. From atrn at optusnet.com.au Thu Feb 6 07:03:49 2020 From: atrn at optusnet.com.au (Andrew Newman) Date: Thu, 6 Feb 2020 08:03:49 +1100 Subject: [TUHS] keyboards and command names In-Reply-To: References: Message-ID: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> > On 6 Feb 2020, at 2:05 am, Rich Morin wrote: > > I have always suspected that the brevity of the Unix command names was strongly > influenced by the clunky keyboards on the teletypes that were being used. Can > anyone confirm, deny, and/or comment on this? (other replies seen, nice to hear dmr’s confirmation) Somewhat related. My first “real” job after university, and introduction to UNIX et al, was using IBM machines running VM/370 and the CMS single-user OS for user accounts. CMS used long command names but, like some other OSes of its ilk, allowed you to define what it called “abbreviations" via a count of the minimum number of unique, leading, characters from which it could determine the actual command name. The CMS file copy program was “copyfile” but the abbreviation length, at least at our “shop", was 2 and everyone used “co”. Similarly the editor “xedit” was “x”. I always found that amusing considering complaints about cryptic UNIX names. (apologies if this appears twice, first attempt used the wrong From: address). -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 6 07:43:38 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 13:43:38 -0800 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: Yup. On Wed, Feb 5, 2020 at 12:51 PM Rob Pike wrote: > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > fuck, for good reason, but he soon realized it was going to be used by > others and changed one letter. It was just letters after that. > > -rob > > > On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > >> FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes >> with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I >> smiled one time when I heard some one call it “f-sick” but that was not >> considered the proper pronunciation. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not >> quite. >> >> > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: >> > >> > "G. Branden Robinson" wrote: >> > >> >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: >> >>> markus schnalke wrote: >> >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >> >>>> ``vee-eye''), is that what you english speakers do? >> >> >> >> Certainly not. When one sees a command name that duplicates a >> >> frequently-used diminituve of a common name, the brain is going to >> >> select that preferentially. >> > >> > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and >> > the other two-letter commands. >> > >> >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) >> > >> > I did ... Although it's "groff" and not "g-roff". :-) >> > >> > FWIW, >> > >> > Arnold >> > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Feb 6 07:52:44 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 6 Feb 2020 07:52:44 +1000 Subject: [TUHS] System Call History In-Reply-To: <202002051916.015JGldn3233910@darkstar.fourwinds.com> References: <202002051916.015JGldn3233910@darkstar.fourwinds.com> Message-ID: <20200205215244.GA27612@minnie.tuhs.org> On Wed, Feb 05, 2020 at 11:16:46AM -0800, Jon Steinhart wrote: > Does anybody have or know of a list of system calls that describes > when and what version of UNIX (and descendents) they were added? Diomidis Spinellis has done a great job here: https://dspinellis.github.io/unix-history-man/man2.html which is part of this: https://dspinellis.github.io/unix-history-man/ Cheers, Warren From skogtun at gmail.com Thu Feb 6 07:59:08 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Wed, 5 Feb 2020 22:59:08 +0100 Subject: [TUHS] keyboards and command names In-Reply-To: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> References: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> Message-ID: <73524e91-0b05-e4b7-524b-1c7247d48846@gmail.com> Andrew Newman [05/02/2020 22.03]: > Somewhat related.  My first “real” job after university, and > introduction to UNIX > et al, was using IBM machines running VM/370 and the CMS single-user OS > for user > accounts.  CMS used long command names but, like some other OSes of its > ilk, allowed > you to define what it called “abbreviations" via a count of the minimum > number of > unique, leading, characters from which it could determine the actual > command name. > The CMS file copy program was “copyfile” but the abbreviation length, at > least at > our “shop", was 2 and everyone used “co”.  Similarly the editor “xedit” > was “x”. > I always found that amusing considering complaints about cryptic UNIX names. Norsk Data's OS Sintran was the same, except that "COLD-START" (reboot the OS) was defined twice, so you had to spell it out in full. -- Hilsen Harald From usotsuki at buric.co Thu Feb 6 07:59:52 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 5 Feb 2020 16:59:52 -0500 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Thu, 6 Feb 2020, Rob Pike wrote: > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > fuck, for good reason, but he soon realized it was going to be used by > others and changed one letter. It was just letters after that. And now in some circles it's a euphemism for "fuck" ;) -uso. From dave at horsfall.org Thu Feb 6 08:06:31 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Feb 2020 09:06:31 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, 5 Feb 2020, Nemo wrote: > Well, I am clearly the odd-ball here. I spoke them "long-hand" (as in > remove, link, move, change-mode, ...). Others copied but only once did > a young 'un start typing c-h-a-n ... Hey, this is Unix; we're all odd-balls here :-) -- Dave From dave at horsfall.org Thu Feb 6 08:20:54 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Feb 2020 09:20:54 +1100 (EST) Subject: [TUHS] keyboards and command names In-Reply-To: <73524e91-0b05-e4b7-524b-1c7247d48846@gmail.com> References: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> <73524e91-0b05-e4b7-524b-1c7247d48846@gmail.com> Message-ID: On Wed, 5 Feb 2020, Harald Arnesen wrote: > Norsk Data's OS Sintran was the same, except that "COLD-START" (reboot > the OS) was defined twice, so you had to spell it out in full. CDC's KRONOS also allowed abbreviated commands; I grew quite fond of typing "COMMO" for "COMMON" (attach to the system's common area) and "POO" for "POOL" (can't remember what that does, and my books are long gone). Cough cough... The above sequence was how you broke into KRONOS: COMMON SYSTEM POOL SYSTEM (quickly interrupt it) Get the timing right, and you were in supervisor mode (or whatever it was called). I remember when I was in the terminal room happily hacking away, when the shift supervisor and the centre manager happened to walk in, exclaiming "Security is pffft!". Terrified, I casually leaned over the Duckwriter pretending to look for something, to obscure just what I'd been typing... I dimly recall that you could log off other users by (somehow) sending a ^D to their terminal, but I could be confusing that with something else (this was decades ago). -- Dave From erc at pobox.com Thu Feb 6 08:22:32 2020 From: erc at pobox.com (Ed Carp) Date: Wed, 5 Feb 2020 16:22:32 -0600 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: Sex the UNIX way # unzip # strip # touch # finger # mount # fsck # more # yes # umount # sleep On 2/5/20, Rob Pike wrote: > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > fuck, for good reason, but he soon realized it was going to be used by > others and changed one letter. It was just letters after that. > > -rob > > > On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > >> FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes >> with “disk”), but F. S. C. K. was always acceptable to my ears. I admit >> I >> smiled one time when I heard some one call it “f-sick” but that was not >> considered the proper pronunciation. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not >> quite. >> >> > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: >> > >> > "G. Branden Robinson" wrote: >> > >> >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: >> >>> markus schnalke wrote: >> >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >> >>>> ``vee-eye''), is that what you english speakers do? >> >> >> >> Certainly not. When one sees a command name that duplicates a >> >> frequently-used diminituve of a common name, the brain is going to >> >> select that preferentially. >> > >> > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and >> > the other two-letter commands. >> > >> >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) >> > >> > I did ... Although it's "groff" and not "g-roff". :-) >> > >> > FWIW, >> > >> > Arnold >> > From cmhanson at eschatologist.net Thu Feb 6 09:29:17 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 5 Feb 2020 15:29:17 -0800 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: Message-ID: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> On Jan 18, 2020, at 3:19 PM, Michael Parson wrote: > > Speaking of old versions of Motif, are the sources for the pre-OpenMotif > bits available anywhere? Even if under lock and key for now, I'd be > happy knowing they'd been preserved for potential future availability. There are Motif 1.1 sources on Bitsavers (or your favorite mirror) at >. -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Feb 6 09:40:43 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 5 Feb 2020 18:40:43 -0500 Subject: [TUHS] keyboards and command names In-Reply-To: References: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> <73524e91-0b05-e4b7-524b-1c7247d48846@gmail.com> Message-ID: <8b706ef6-dbf0-27ba-c343-b693f4c5c8f3@kilonet.net> Have't seen mention of TOPS-10, or TOPS-20 for that matter... shortening commands was a great time saver. Problem was, next time they added a command, muscle memory had to relearn. On 2/5/2020 5:20 PM, Dave Horsfall wrote: > On Wed, 5 Feb 2020, Harald Arnesen wrote: > >> Norsk Data's OS Sintran was the same, except that "COLD-START" >> (reboot the OS) was defined twice, so you had to spell it out in full. > > CDC's KRONOS also allowed abbreviated commands; I grew quite fond of > typing "COMMO" for "COMMON" (attach to the system's common area) and > "POO" for "POOL" (can't remember what that does, and my books are long > gone). > > Cough cough...  The above sequence was how you broke into KRONOS: > >     COMMON SYSTEM >     POOL SYSTEM >     (quickly interrupt it) > > Get the timing right, and you were in supervisor mode (or whatever it > was called).  I remember when I was in the terminal room happily > hacking away, > when the shift supervisor and the centre manager happened to walk in, > exclaiming "Security is pffft!".  Terrified, I casually leaned over the > Duckwriter pretending to look for something, to obscure just what I'd > been typing... > > I dimly recall that you could log off other users by (somehow) sending > a ^D to their terminal, but I could be confusing that with something > else (this was decades ago). > > -- Dave > From crossd at gmail.com Thu Feb 6 12:23:17 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Feb 2020 21:23:17 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, Feb 5, 2020 at 3:52 PM Rob Pike wrote: > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > fuck, for good reason, but he soon realized it was going to be used by > others and changed one letter. It was just letters after that. > Very often the novice Unix users learns how `rm -rf` works the hard way. I've always preferred the spelling, `rm -fr` where I tell people that the `fr` bit means, "fuck recursively." - Dan C. On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > >> FWIW. When it was written, Ted and I used pronounced it as “fisk” (rhymes >> with “disk”), but F. S. C. K. was always acceptable to my ears. I admit I >> smiled one time when I heard some one call it “f-sick” but that was not >> considered the proper pronunciation. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not >> quite. >> >> > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: >> > >> > "G. Branden Robinson" wrote: >> > >> >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: >> >>> markus schnalke wrote: >> >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like >> >>>> ``vee-eye''), is that what you english speakers do? >> >> >> >> Certainly not. When one sees a command name that duplicates a >> >> frequently-used diminituve of a common name, the brain is going to >> >> select that preferentially. >> > >> > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and >> > the other two-letter commands. >> > >> >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) >> > >> > I did ... Although it's "groff" and not "g-roff". :-) >> > >> > FWIW, >> > >> > Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 6 12:31:24 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Feb 2020 13:31:24 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, 5 Feb 2020, Dan Cross wrote: > Very often the novice Unix users learns how `rm -rf` works the hard way. > I've always preferred the spelling, `rm -fr` where I tell people that > the `fr` bit means, "fuck recursively." Yep, that's the thing everyone has to do once; just like: % rm * .o rm: .o: No such file or directory % ls % -- Dave From crossd at gmail.com Thu Feb 6 12:43:33 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Feb 2020 21:43:33 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, Feb 5, 2020 at 5:23 PM Ed Carp wrote: > Sex the UNIX way > [...] > # finger > [...] > Perhaps I've sent this story to TUHS before, but I can't resist. "finger: the most inappropriately named command in computerdom" (no, that's not a challenge...). When I was in high school I was stealing, er, I mean, borrowing computer time from the local university. It wasn't quite as criminal as I make it sound; I was decently well known around campus, folks tolerated my presence admirably and as informal payment for the computer time, I did a lot of unpaid sysadmin work. Anyway, this was the early 90s and the university was starting to give email accounts to pretty much everyone. What this meant was that there was a server somewhere running sendmail that accepted incoming mail, and a POP3 server that you could connect to to download that mail. There were self-service computer labs around campus connected to the university network, and the `finger` service on the main campus machine was backed by a database that responded to a crude, limited query syntax. Notably, you could finger your own first and last name (in quotes) and get some data about your account, including your login name (most of which were of the form abc123 because ... university bureaucracy). However, the university wasn't all that great about telling people any of this stuff...word had gotten out that everyone had an email account, but not how to go about getting your login information, etc. They certainly never mentioned the "finger" command. Of course, among the computer types, using 'finger' was par for the course. "Hey, you going to be online later?" "Yeah, just finger me over at the math department." Etc. One day I was hanging around near the helpdesk when a young woman, a graduate student, came in to ask about her account details. The student on duty at the time, in a very helpful, cheerful voice said, "oh, that's easy! Just finger yourself!" (Oh context, you are everything...). Jaws dropped. Stunned silence ensued. The student working the helpdesk, suddenly looking approximately like he might die, managed to awkwardly stammer out something about "the the the finger command" and "I mean, uh, I'm not saying that YOU should, like, you know... I mean, I don't mean THAT...and, uh...I'm just making it worse, aren't I? Here, this will all make so much more sense if I just show you what I mean. On the computer! I mean...just let me type this thing...er, what's your name?" The graduate student left a few minutes later with her login details. So far as I know, no one got fired. In the end I think everyone had a good laugh, grad student included. - Dan C. On 2/5/20, Rob Pike wrote: > > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > > fuck, for good reason, but he soon realized it was going to be used by > > others and changed one letter. It was just letters after that. > > > > -rob > > > > > > On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > > > >> FWIW. When it was written, Ted and I used pronounced it as “fisk” > (rhymes > >> with “disk”), but F. S. C. K. was always acceptable to my ears. I admit > >> I > >> smiled one time when I heard some one call it “f-sick” but that was not > >> considered the proper pronunciation. > >> > >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > >> quite. > >> > >> > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: > >> > > >> > "G. Branden Robinson" wrote: > >> > > >> >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > >> >>> markus schnalke wrote: > >> >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > >> >>>> ``vee-eye''), is that what you english speakers do? > >> >> > >> >> Certainly not. When one sees a command name that duplicates a > >> >> frequently-used diminituve of a common name, the brain is going to > >> >> select that preferentially. > >> > > >> > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > >> > the other two-letter commands. > >> > > >> >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) > >> > > >> > I did ... Although it's "groff" and not "g-roff". :-) > >> > > >> > FWIW, > >> > > >> > Arnold > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 6 13:00:44 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 5 Feb 2020 19:00:44 -0800 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: <20200206030044.GD21264@mcvoy.com> That's awesome. And finger, back in the days of innocence before scammers and viruses and black hat hackers, was super useful. I hacked my finger server to do all sorts of stuff, it was sort of ftp/ps/who and who knows what else in one. I miss the days when finger was a thing. Perhaps poorly named (perhaps not), whatever, it was simpler time. On Wed, Feb 05, 2020 at 09:43:33PM -0500, Dan Cross wrote: > On Wed, Feb 5, 2020 at 5:23 PM Ed Carp wrote: > > > Sex the UNIX way > > [...] > > # finger > > [...] > > > > Perhaps I've sent this story to TUHS before, but I can't resist. "finger: > the most inappropriately named command in computerdom" (no, that's not a > challenge...). > > When I was in high school I was stealing, er, I mean, borrowing computer > time from the local university. It wasn't quite as criminal as I make it > sound; I was decently well known around campus, folks tolerated my presence > admirably and as informal payment for the computer time, I did a lot of > unpaid sysadmin work. > > Anyway, this was the early 90s and the university was starting to give > email accounts to pretty much everyone. What this meant was that there was > a server somewhere running sendmail that accepted incoming mail, and a POP3 > server that you could connect to to download that mail. There were > self-service computer labs around campus connected to the university > network, and the `finger` service on the main campus machine was backed by > a database that responded to a crude, limited query syntax. Notably, you > could finger your own first and last name (in quotes) and get some data > about your account, including your login name (most of which were of the > form abc123 because ... university bureaucracy). However, the university > wasn't all that great about telling people any of this stuff...word had > gotten out that everyone had an email account, but not how to go about > getting your login information, etc. They certainly never mentioned the > "finger" command. > > Of course, among the computer types, using 'finger' was par for the course. > "Hey, you going to be online later?" "Yeah, just finger me over at the math > department." Etc. > > One day I was hanging around near the helpdesk when a young woman, a > graduate student, came in to ask about her account details. The student on > duty at the time, in a very helpful, cheerful voice said, "oh, that's easy! > Just finger yourself!" (Oh context, you are everything...). > > Jaws dropped. Stunned silence ensued. The student working the helpdesk, > suddenly looking approximately like he might die, managed to awkwardly > stammer out something about "the the the finger command" and "I mean, uh, > I'm not saying that YOU should, like, you know... I mean, I don't mean > THAT...and, uh...I'm just making it worse, aren't I? Here, this will all > make so much more sense if I just show you what I mean. On the computer! I > mean...just let me type this thing...er, what's your name?" > > The graduate student left a few minutes later with her login details. So > far as I know, no one got fired. In the end I think everyone had a good > laugh, grad student included. > > - Dan C. > > On 2/5/20, Rob Pike wrote: > > > Frodo (Ted Kowalski) told me it was originally spelled, and pronounced, > > > fuck, for good reason, but he soon realized it was going to be used by > > > others and changed one letter. It was just letters after that. > > > > > > -rob > > > > > > > > > On Thu, Feb 6, 2020 at 1:34 AM Clem cole wrote: > > > > > >> FWIW. When it was written, Ted and I used pronounced it as ???fisk??? > > (rhymes > > >> with ???disk???), but F. S. C. K. was always acceptable to my ears. I admit > > >> I > > >> smiled one time when I heard some one call it ???f-sick??? but that was not > > >> considered the proper pronunciation. > > >> > > >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > > >> quite. > > >> > > >> > On Feb 5, 2020, at 3:45 AM, arnold at skeeve.com wrote: > > >> > > > >> > "G. Branden Robinson" wrote: > > >> > > > >> >> At 2020-02-04T09:40:18+0100, Sijmen J. Mulder wrote: > > >> >>> markus schnalke wrote: > > >> >>>> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > > >> >>>> ``vee-eye''), is that what you english speakers do? > > >> >> > > >> >> Certainly not. When one sees a command name that duplicates a > > >> >> frequently-used diminituve of a common name, the brain is going to > > >> >> select that preferentially. > > >> > > > >> > ISTR thinking of it and calling it e-d, along with r-m, l-n, m-v and > > >> > the other two-letter commands. > > >> > > > >> >> (And did people really say "dee-eye-tee-roff" for "ditroff"?) > > >> > > > >> > I did ... Although it's "groff" and not "g-roff". :-) > > >> > > > >> > FWIW, > > >> > > > >> > Arnold > > >> > > > > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From mparson at bl.org Thu Feb 6 13:44:02 2020 From: mparson at bl.org (Michael Parson) Date: Wed, 5 Feb 2020 21:44:02 -0600 (CST) Subject: [TUHS] Atari System V media and books? In-Reply-To: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> Message-ID: On Wed, 5 Feb 2020, Chris Hanson wrote: > On Jan 18, 2020, at 3:19 PM, Michael Parson wrote: > >> Speaking of old versions of Motif, are the sources for the >> pre-OpenMotif bits available anywhere? Even if under lock and key >> for now, I'd be happy knowing they'd been preserved for potential >> future availability. > > There are Motif 1.1 sources on Bitsavers (or your favorite mirror) > at >. Thank you! -- Michael Parson Pflugerville, TX KF5LGQ From lm at mcvoy.com Thu Feb 6 13:54:57 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 5 Feb 2020 19:54:57 -0800 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> Message-ID: <20200206035457.GF21264@mcvoy.com> On Wed, Feb 05, 2020 at 09:44:02PM -0600, Michael Parson wrote: > On Wed, 5 Feb 2020, Chris Hanson wrote: > >On Jan 18, 2020, at 3:19 PM, Michael Parson wrote: > > > >>Speaking of old versions of Motif, are the sources for the > >>pre-OpenMotif bits available anywhere? Even if under lock and key > >>for now, I'd be happy knowing they'd been preserved for potential > >>future availability. > > > >There are Motif 1.1 sources on Bitsavers (or your favorite mirror) > >at >>. > > Thank you! Part of me is wondering why anyone cares about Motif. My memory of that is that Xview was better and the Athena widgets were better. Athena was ugly but it worked, Xview, the X11 version of Sunview, was fantastic to program in, the argv was a set of 2 tuples, thing and value. And it looked better. I've written Xview apps and other than the Tk part of Tcl/Tk, it was the most pleasant GUI API I have used. For the record, the Tk part of Tcl/Tk is still, decades later, the best GUI interface I've ever seen. John got that right. So no offense intended, what about Motif is likeable? From henry.r.bent at gmail.com Thu Feb 6 14:02:15 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 5 Feb 2020 23:02:15 -0500 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: Message-ID: On Sat, 18 Jan 2020 at 18:20, Michael Parson wrote: > On Sat, 18 Jan 2020, Chris Hanson wrote: > > > I’ve seen the archives of Atari System V Release 4 for the TT030, > > and the scanned user and developer manuals. Has anything else been > > preserved, e.g. the installation tapes and any other manuals? > > > > Is there even a full accounting of what was in the box and what > > shipped afterwards (patches etc.)? > > Most of I've seen is the stuff I found while playing with Amiga UNIX, > which is the stuff hosted at atariunix.com. I was able to pull the > Motif (v 1.1.1) bits out of the Atari UNIX disk images and get them > running on Amiga UNIX. > > Speaking of old versions of Motif, are the sources for the pre-OpenMotif > bits available anywhere? Even if under lock and key for now, I'd be > happy knowing they'd been preserved for potential future availability. > I have a QIC-150 cartridge of Motif 1.2.1 (labeled "patch release", so perhaps not a complete source tree?) but do not have a working drive that will read it. I attempted to contact Al Kossow about reading it but was unsuccessful. If you would be able to read it I would be happy to send it to you. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 6 15:05:24 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Feb 2020 21:05:24 -0800 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: Message-ID: I have two qic-150 drives. Contact me off list. Clem On Wed, Feb 5, 2020 at 8:03 PM Henry Bent wrote: > On Sat, 18 Jan 2020 at 18:20, Michael Parson wrote: > >> On Sat, 18 Jan 2020, Chris Hanson wrote: >> >> > I’ve seen the archives of Atari System V Release 4 for the TT030, >> > and the scanned user and developer manuals. Has anything else been >> > preserved, e.g. the installation tapes and any other manuals? >> > >> > Is there even a full accounting of what was in the box and what >> > shipped afterwards (patches etc.)? >> >> Most of I've seen is the stuff I found while playing with Amiga UNIX, >> which is the stuff hosted at atariunix.com. I was able to pull the >> Motif (v 1.1.1) bits out of the Atari UNIX disk images and get them >> running on Amiga UNIX. >> >> Speaking of old versions of Motif, are the sources for the pre-OpenMotif >> bits available anywhere? Even if under lock and key for now, I'd be >> happy knowing they'd been preserved for potential future availability. >> > > I have a QIC-150 cartridge of Motif 1.2.1 (labeled "patch release", so > perhaps not a complete source tree?) but do not have a working drive that > will read it. I attempted to contact Al Kossow about reading it but was > unsuccessful. If you would be able to read it I would be happy to send it > to you. > > -Henry > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From katolaz at freaknet.org Thu Feb 6 15:20:37 2020 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Thu, 6 Feb 2020 06:20:37 +0100 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200206030044.GD21264@mcvoy.com> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200206030044.GD21264@mcvoy.com> Message-ID: <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> On Wed, Feb 05, 2020 at 07:00:44PM -0800, Larry McVoy wrote: > That's awesome. And finger, back in the days of innocence before scammers > and viruses and black hat hackers, was super useful. I hacked my finger > server to do all sorts of stuff, it was sort of ftp/ps/who and who knows > what else in one. > > I miss the days when finger was a thing. Perhaps poorly named (perhaps > not), whatever, it was simpler time. > Just to mention that finger is *still* a thing in many modern pubnix systems, such as circumlunar.space or tildeverse. My2Cents From doug at cs.dartmouth.edu Fri Feb 7 00:33:13 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 06 Feb 2020 09:33:13 -0500 Subject: [TUHS] System Call History Message-ID: <202002061433.016EXDYs949202@coolidge.cs.dartmouth.edu> > Does anybody have or know of a list of system calls that describes > when and what version of UNIX (and descendents) they were added? Hardly a week goes by in which I don't refer to the attached condensed listing of all the man pages in v1-v9, taken from my "Research Unix Reader". It casts a much narrower net than Diomedes Spinelli's repository. but it takes no clicking to look thing up--just a quick grep. Doug -------------- next part -------------- Combined Table of Contents The following table lists every page ever printed in a research edition. In general the presence of a page in an edition is signaled by +; a number instead of + indicates that the page appeared in a different chapter of that edi@@\ @ tion. An appended name in brackets [ ] means that a manual page was later incorporated into or obsoleted by the named page. Research software that was not included in distribution tapes was generally omitted from the v6 and v7 manuals. For v7 an addendum about unexported software was printed for local use; items from it are flagged L. Thus one can infer from the table that apl existed from v5 through v7, but was never distributed. In v5 it lived in chapter 6, @@@@@@User maintained commands.@\ @@@@@ It disappeared with v8, a casualty of the conversion from PDP@@@11s to V\ AXes. Many trivial name changes are quietly ignored, e.g. a change from cons(4) in v8 to console(4) in v9 and from file system(V) in v1@@@v3 to fs(V) in v4@@@6 to fil\ sys(5) in v7@@@v9. The short descriptions also changed from time to time; those given here are from v7 or else from the edition where the page first appeared. 1. Commands In v1@@@v6, commands were classified as standard or as @\ @@@@@user maintained,@@@@@@ the latter being relegated t\ o chapter 6. In this list both categories appear in chapter 1. Games, though, are listed with chapter 6 as always. Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + + + intro introduction to commands . + + . . . . . . : place label [goto] . . . . . . . + + = redo previous shell command + . + . . . . . . acct get connect@@@time accountin\ g . . . . . . + . + adb debugger . . . . . . . + . altran language for algebraic computation [l\ angs] . . . . 6 . L . . apl APL interpreter . . . . . . . + + apply apply a command to a set of arguments . . . . . . . + + apsend send troff output to aps@@@5 + + + + + + + + + ar archive and library maintainer . . . . . . + . . arcv convert archives to new format + + + + + + + + + as assembler . . . . . . . + . asa interpret ASA control characters . . . . . . . + + ascii interpret ASCII characters Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + + + at execute commands at a later time . . . . . . + + + awk pattern scanning and processing langu\ age . . . 6 6 6 . . . azel obtain satellite predictions + + + . . . . . . b compile b program . . . . . . . . + backup backup and recover files . . . . . . + . . badblk dispose of unusable disk + + + + 6 + + . . bas basic [hoc] 6 6 . . . . . . . basic DEC supplied basic [langs] . . . . . . + + + basename strip filename affixes . . . . . + + + + bc arbitrary@@@precision arithm\ etic language + . . . . . . . . boot reboot system [20boot(8)] . . . . . . L . . bs a compiler/interpreter for modest@\ @@sized programs . . . . . . . + + bundle collect files for distribution 6 6 . 6 6 6 + + 7 cal print calendar . . . . . . + + + calendar reminder service . . . . . . L . . call ring a telephone . . . . . . . + + can interface to Cannon laser@@@\ printer spooler + + + + + + + + + cat catenate and print . . . + 6 . . . . catsim phototypesetter simulator . . . . . . + + + cb C program beautifier . . . . . . . + + cbt btree utilities . + + + + + + + + cc C compiler . . . . . . + . . cd change working directory [sh] . . + + + + . . . cdb C debugger [adb] . . . . . . L + . cflow generate C flow graph + + + + + + . . . chdir change working directory [cd] + + + + + + + + + chmod change mode + + + + + 8 + 8 8 chown change owner or group . . . . . . . . + cin C interpreter . . . . . . . + + cite process citations in a document . . . . . . . + . clear clear terminal screen + + + + + + + + + cmp compare two files . . . . 6 6 + . . col filter reverse line feeds [column] . . . . . . . + + column column alignment . . . . + + + + + comm select or reject lines common to two \ sorted files . . . . . . + . . con connect to another UNIX [dcon] . . . . . . . + + coreid identify source of a core image + + + + + + + + + cp copy file . . . . . . L + + cpio copy file archives in and out . 6 + + + + L . . cref cross@@@reference table . . + . . . + + 6 crypt encode/decode . . . . . . . + + ct call terminal (and start a session) . . . . . . + + + cu call Unix . . . . . . . + + cut rearrange columns of text . . . . . . . + + cyntax C syntax checker . . . . . . . + + d202 phototypesetter filters 6 6 . . . . . . . das disassembler [adb] + + + + + + + + + date print and set the date + + + + + + . . . db symbolic debugger [adb] + . . . . . . . . dbppt write binary paper tape [dump] + + + + + + + + + dc desk calculator . . . . . . . + + dcon remote login and execution Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . + + + + + dd convert and copy a file . . . . . . + + + deroff remove nroff, troff, tbl and eqn cons\ tructs + + + 8 8 8 + + + df disk free . . . . + + + + + diff differential file comparator . . . . . . + + . diff3 3@@@way differential file co\ mparison . . . . . . . + + dired directory editor . . . . . . . + + docgen generate a document from a script . . . . . . . + + doctype guess command line for formatting a d\ ocument 6 6 8 . . . . . . dli load DEC binary paper tapes 6 6 . . . . . . . dpt read DEC ASCII paper tapes . . . . . . L . . draw edit a circuit diagram . + . . . . . . . ds verify directory hierarchy + + + + + + . . . dsw delete files interactively [rm] + . . . . . . . . dtf format DECtape + + + + + + + + + du summarize disk usage . . . . . . + . . dumpdir print the names of files on a dump ta\ pe . + + + + + + + + echo echo arguments + + + + + + + + + ed text editor . . . . . . . + . efl extended Fortran language preprocesso\ r . . . . + + + + + eqn typeset mathematics . . . . . . + + + expr evaluate arguments as an expression . + + + + + . . . exit end command sequence [sh] . . . . . . + + + f77 Fortran 77 compiler . . + + 6 6 + + + factor factor a number, generate large prime\ s . + + + + + . . . fc compile Fortran program [f77] . + + + + 6 . . . fed form@@@letter editor [form] . . . . . . L . . fget retrieve files from HIS 6000 . . . + . + + + + file determine file type + + . . . . . . . find find file with a given name . . . . + + + + + find find files . . . . . . . . + fmt ultra@@@simple text formatte\ r + . . . . . . . . for compile fortran program [fc] + + + + + 6 L . . form generate form letter . . + . . . . . . forml generate form letters . . . . . . L . . fsend send files to HIS 6000 . . . . . . L . . gcat send phototypesetter output to HIS 60\ 00 [apsend] . . . . . . . + + getuid get user identity . . . . . . L . . gex graphics exerciser for Tektronix 4014 . + + + + + . . . goto command transfer [sh] . . . . . . . . + gone.fishingautomatic reply to mail . . . . 6 . . . . graf draw graph on GSI terminal . . . . . . . + + grap pic preprocessor for drawing graphs . . . . . 6 + + + graph draw a graph . . . . . . L . . greek interpret extended character set . . . + + + + + + grep search a file for a pattern . . . . 6 6 . . . gsi interpret funny characters on GSI ter\ minal . . . . . . . + + hang start a process in stopped state . . . . . . . + + hoc interactive floating point language . . . . . . L . . huff Huffman code file compression [pack] + . . . . . . . . hup hang up typewrite . . + 6 6 . . . . hyphen find hyphenated words . . . . 6 . L . . ibm submit off@@@line job to HO \ IBM 370 Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + . icont Icon language translator and compiler . . . . . . . + + ideal troff preprocessor for drawing pictur\ es . . . . . . . + + idiff interactive file comparison . + + + + + . . . if conditional command [sh] . . . . . . L . . iget get files from Holmdel IBM 370 . . . . . . + + . iostat report I/O statistics [load] . . . . . . L . . isend send files to Holmdel IBM 370 . . . . . . + + + join relational database operator . . 8 + + + + + + kill terminate a process with extreme prej\ udice . . . . . . L . . labmake print address labels on GCOS [lab] . . . . . . . + + lab label maker . . . . . . . . + langs altran, basic, ... languages . . . . . . . + . last report recent logins [who] . . . . . . . . + latex tex macro packages and bibliographies . . . . . . . + + lcomp line@@@by@@@line pr\ ofiler + . . . . . . . . lbppt read binary paper tape [restor] + + + + + + + + + ld loader . . . . . . L . . lde logic design equation language . . . . . . + + + learn computer aided instruction about UNIX . . . . . . + + + lex generator of lexical analysis program\ s . . . . . . . + . lisp lisp interpreter and compiler [langs] . . . . . . + + + lint a C program verifier + + + + + + + + + ln make a link . . . . . . . . + load load and input@@@output stat\ istics . + + + + + + 8 8 login sign on . . . . . . + + + look find lines in a sorted list . . . . . . + . . lookall look through all text files on UNIX . . . . . . + . + lorder find ordering relation for an object \ library . . . . + . + + + lpr line printer spooler + + + + + + + + + ls list contents of directory . . . . . . + + + m4 macro processor . + + 6 6 6 . . . m6 macroprocessor [m4] . . . . . . . + + Mail send and receive mail + + + + + + + + + mail send or receive mail among users . . . . . . + + + make maintain program groups . + + + + + + + + man print sections of this manual . . . . . . . + . matlab interactive matrix desk calculator [l\ angs] . . . + . . . . . merge merge several files [sort] + + + + + + + + + mesg permit or deny messages . . . . . . . . + mk maintain (make) related files + + + + + + + + + mkdir make a directory . . . . . . . . + mkpkg make and install packages . . . . . . . . + monk typeset documents and letters . + + . . . . . . mt save/restore files on magtape [tar] + + + + + + + + + mv move or rename files and directories . . . . + + . . . neqn typeset mathematics on a terminal [eq\ n] . . . . . . . + + netnews send or receive news articles . . . . . . . + + newer test file modification dates . . . . . + + + + newgrp log in to a new group . . . . . . . + + news print news items . . . . . . L . . nfs communicate with Spider File System . . . . . . L 1 6 number convert Arabic numerals to English Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . + + + + + + nice run a command at low priority + + + + + + + + + nm print name list . . . . 6 . . . . npr print file on Spider line@@@\ printer . . . + + + . . . nohup run a command at low priority [nice] . + + + + + . . . nroff format text for printing [troff] + + + + + + + + + od octal dump . + + + + + L . . opr print file off@@@line . + + 6 . . . . . ov page overlay file print . . . . . . . + + p paginate . . . . . . . + + pack compress and expand files . . . . . . . + . paper list input on HP2621P printer . . . . . . . + + pascal language interpreter . . . . . . . + + pc pascal language compiler . . + + + + + + + passwd install new password or user . . . + + + . . . pfe print floating exception . . . . . . . + + pic troff preprocessor for drawing pictur\ es . . . . . . . + . pick pick arguments [apply] . . . . . . L . . place design physical layout of a circuit . . . . 6 . . . . plog make a graph on the gsi terminal . . . + 6 6 + + + plot graphics filter . . . . . . . + . post send mail to users by name . . . . . . . + + postnews submit netnews articles + + + + + + + + + pr print file . . . . . . . . + prefer maintain and use bibliographic refere\ nces . . . . . . + . . prep prepare text for statistical processi\ ng . . . . . 6 . . . primes print all primes larger than somewhat\ [factor] . . . . . . L . . prom read and write proms through the PROL\ OG promwriter . . + + . . . . . proof compare text files [diff] . . . . + + + + + prof display profile data . . 8 + + + + + + ps process status . 6 6 6 6 . + + + ptx permuted index . . . . . . + . . pubindex make inverted bibliographic index [re\ fer] . . . . . . . + + push datakit remote file copy . . . . + + + + + pwd working directory name . . . . . . . + . pxp pascal printer, profiler, and cross@\ @@reference lister . . . . . . . + + random sample lines from a file or provide r\ andom exit code . . . . . . . + . ranlib convert archives to random libraries \ [ar] . . . . . + . + . rc Ratfor compiler [langs] . . . . . . . + + readnews read news articles . . . . . . + + + refer find and insert literature references\ in documents . . . . . + + + + rev reverse lines of a file + + + + + . . . . rew rewind DECtape + . . . . . . . . rkd dump disk to tape + . . . . . . . . rkf format RK disk + . . . . . . . . rkl load disk from tape + + + + + + + + + rm remove (unlink) files + + + + + + . . . rmdir remove (delete) directory [rm] + + + + + + + . . roff format text . . . . . . . + + ropy remote file copy for arpa internet . . . . . . . . + rscan scan pages on ricoh scanner and displ\ ay on 5620 + . . . . . . . . sdate adjust date and time . . . . . . . + + sdb symbolic debugger Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . L . . sdiff side@@@by@@@side di\ fference program . . . . . . . . + seal mailable data file . . . . . . + + + sed stream editor . . . . . . . . + sendcover send cover sheet to the library . . . . . . . + + seq print sequences of numbers . . . . . . . + + server run anonymous command on another mach\ ine . . . . 6 . . . . sfs structured file scanner + + + + + + + + + sh command language . . + + + + . . . shift adjust shell arguments [sh] . . . . . . . + + ship automatic software distribution . . + + + + + + + size size of an object file . . . 6 6 6 L 7 7 sky obtain ephemerides . . . + + + + + + sleep suspend execution for an interval . . + + 6 6 L + . sno compile Snobol programs [langs] . . . . . . . + + snocone snobol with syntactic sugar 6 + + + + + + + + sort sort or merge files . . + + 6 6 L . . speak send words to voice synthesizer . . . . + + + + + spell find spelling errors . . . . . . . + . spitbol Snobol language compiler [langs] . . . 6 6 6 + . . spline interpolate smooth curve . . + + + + + + + split split a file into pieces + + + . . . . . . stat get file status + + + + + + + + + strip remove symbols and relocation bits . . . . . . + + . struct structure Fortran programs . + + + + + + + + stty set terminal options . . . . . . . . + submit install document in database + + + + + . + + + sum sum and count blocks in a file . . . . . . + + + tabs set terminal tabs . + . . . . . . . tacct connect@@@time accounting . . . . . . + + + tail deliver the last part of a file + + + . . . . . . tap manipulate DECtape . . . . . . . + + tape identify and manipulate magnetic tape . . . . . . + + + tar tape archiver . . . . . 6 + + + tbl format tables for nroff or troff . . . . . . + . . tc troff output interpreter . . . . . . L . . tekstare convert tektronix picture to hard cop\ y graphics [can] . . . . + + + + + tee pipe fitting . . . . . . . + . telnet user interface to the telnet protocol . . . . . . + + + test condition command . . . . . . . . + tex text formatting and typesetting . . + + + + + + + time time a command . . . . . . + + . tk paginator for the Tektronix 4014 . 6 + 6 6 6 L . . tmg compile tmgl program . . . . . . + + + touch update date last modified of a file . . . + + + + . . tp manipulate tape archive [tar] . . . . + + + + + tr translate characters . . . . . . . + + trace protocol compiler and analyzer . . . . . . . + . track selective remote file copy . . . + + + + + + troff text formatting and typesetting . . . . . . + + + true provide truth values . . . . . . . + . tset set terminal modes . + + + + . L . . tss communicate with MH@@@TSS (G\ COS) Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + + + tsort topological sort + + + + + + + + + tty get terminal name + + + + . . . . . type print file on IBM 2741 . . + + + + L . . typo find typographic errors . . . . . . L . . ufs Spider Network Communication . . . . . . . + + ul print underlines on screen terminals + + + . . . . . . un fine undefined symbols . . + + + + + + + uniq report repeated lines in a file . . . . . 6 + 7 7 units conversion program . . . . . + . . . usort sort and merge files, discarding dupl\ icate lines [sort] . . . . . . + + + uucp unix to unix copy . . . . . . L . . uudiff directory comparison between machines . . . . . . . + + uustat uucp status inquiry and job control . . . . . . + + + uux unix to unix command execution . . . . . . L . . vc verification of tests for C programs \ [lcomp] . . . . . . + + + vi screen oriented (visual) display edit\ or based on ex . . . . . . . + + view2d movie of a function f(x,y,t) . . . . . . . + + vis show invisible characters . . . . . . . + . visi mathematical spreadsheet . . + . . . . . . vs generate voice synthesizer phonemes . . . + + + + . . wait await completion of process [sh] + + + + + + + + + wc word count . . . . . . L . . wcheck look for inconsistencies in a circuit\ description + + + + + + + + + who who is on the system . . . . . . L . . wrap generate control information for wiri\ ng a circuit board + + + + + + + + + write write to another user . . . . . . . + + wwb writers workbench . . . . . . . + + wwv print and set the date from accurate \ clock . . . . . . L . . xref cross reference for C programs . . . . . . + + . xsend secret mail . . 6 6 6 + + + + yacc yet another compiler@@@compi\ ler 2. System calls Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . + + + + + intro introduction to system calls and erro\ r numbers . . . . . . + + + access determine accessibility of file . . . . . . + + + acct turn accounting on or off . . . . . . + + + alarm schedule signal after specified time . . + . . . . + . boot reboot the system + + + + + + . . . break set program break [brk] . . . . . . + + + brk change core allocation + + + . . . . . . cemt catch EMT traps [signal] + + + + + + + + + chdir change default directory + + + + + + + + + chmod change mode of file + + + + + + + + + chown change owner and group of a file + + + + + + + + + close close a file + + + + + + + + + creat create a new file . . + + + + . . . csw read the console switches . . . . . . . . + deprecated system calls to be avoided . . + + + + + + + dup duplicate an open file descriptor Edition Title Purpose 1 2 3 4 5 6 7 8 9 + + + + + + + + + exec execute a file + + + + + + + + + exit terminate process . . . . . . . . + fmount mount or remove file system + + + + + + + + + fork spawn new process . . + . . . . . . fpe catch floating exception errors [sign\ al] + + + + + + . . . fstat status of open file [stat] . . . + + + . . . getgid get group identification [getuid] . . . . . + + . . getpid get process identification [getuid] + + + + + + + + + getuid get user and group identity . . . . . . . + . gmount mount or remove non@@@standa\ rd file system [fmount] + + + + + + . . . gtty get typewrite mode [ioctl] . + . . . . . . . hog set low@@@priority status [n\ ice] + + + . . . . . . ilgins catch illegal instruction trap [signa\ l] . . . + + + + . . indir indirect system call [syscall] + + + . . . . . . intr catch or inhib interrupts [signal] . . . . . . + + + ioctl control device . + + + + + + + + kill send signal to a process + + + + + + + + + link link to a file . . . . . . + . . lock lock a process in primary memory . . . . . . + + + lseek move read/write pointer + + + . . . . . + mkdir create directory . . . + + + + + + mknod make a directory or a special file + + + + + + + + . mount mount or remove file system [fmount] . . . . . . + . . mpx create and manipulate multiplexed fil\ es . . + + + + + + + nice set program priority + + + + + + + + + open open for reading or writing . . . + . . + + + pause stop until signal . . . . . . + . . phys allow a process to access physical ad\ dresses . . + + + + + + . pipe create an interprocess channel . . . . . . + . . pkon establish packet protocol . . . . + + + + + profil execution time profile . . . . . + + + . ptrace process trace [proc(4)] + + + . . . . . . quit catch or inhibit quits [signal] + + + + + + + + + read read from file + + + . . . . . . rele release processor + + + + + + . . . seek move read or write pointer [lseek] . . . . . . . + + select synchronous I/O multiplexing . . . + + + . . . setgid set process group ID [setuid] + + + + + + + + + setuid set user and group ID + + + . . . . . . smdate set date modified of file [utime] . . . + + + + + + signal catch or ignore signals . + + + + + . . . sleep delay execution [alarm] + + + + + + + + + stat get file status + + + + + + + + + stime set time + + + + + + . . . stty set mode of typewriter [ioctl] . + + + + + + + + sync update super@@@block . . . . . . . + + syscall indirect system call + + . . . . . . . tell find read or write pointer [seek] + + + + + + + + + time get date and time . . + + + + + + + times get process times . . . . . . + + + umask set file creation mode mask + + + + + + . . . umount dismount file system [mount] Edition Title Purpose 1 2 3 4 5 6 7 8 9 + + + + + + + + + unlink remove directory entry . . . . . . + + + utime set file times + + + + + + + + + wait wait for process to terminate + + + + + + + + + write write on a file 3. Subroutines Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + + + intro introduction to library functions . . . . . + + + + abort generate IOT fault . . . . . + + . . abs integer absolute value, sign function\ [arith] . . . . . . . + + arith integer arithmetic functions . . . . + + . . . alloc core allocator [malloc] . . . . . . + + + assert program verification . + + + + + . . . atan arctangent [sin] + + + + + + + + + atof convert ASCII to numbers + + + . . + . . . atoi convert ASCII to integer [atof] . . . . . . . + + cbt compressed B@@@tree subrouti\ nes . . . . . . . + + chrtab simple character bitmaps . . + + . . . . . compar string compare for sort . + . . . . . . . const floating point constants . . . . . 7 L . . cr coroutine scheme . . + + + + + + + crypt DES encryption + + + + + + + + + ctime convert date and time to ASCII . . . . . . + + + ctype character classification . . . . . . . + + curses screen functions with @@@opt\ imal@@@ cursor motion . . . . . . . + . db database subroutines . . . . . . + + + dbm data base subroutines . . . . . . . + + dialout place call on ACU . . . . . . . + + directory directory operations . . . . . . . + + dkmgr establish datakit server . . + . . . . . . ddsput display characters on Picturephone . . + + + + + + + ecvt output conversion . . . . . + + + + end last locations in program . . . . . . L + + erf error function + + + + + + + + + exp exponential, logarithm, power, square\ root . . . . . . + + + fclose close or flush a stream . . . . . . + + + ferror stream status inquiries . . . . . . . . + fio fast buffered I/O . . . . + + + + + floor absolute value, floor, ceiling functi\ ons . . . . . + . . . fmod floating modulus function [floor] . . . . . . + + + fopen open a stream + + + + + + . . . fptrap floating@@@point simulator . . . . . . + + + fread buffered binary input/output . . . . . . + + + frexp split into mantissa and exponent . . . . . . + + + fseek reposition a stream + + + . . . . . . ftoa convert floating to ASCII [ecvt] . . + . . . . . . ftoo convert floating to octal . . . . . . . + + ftw file tree walk . . . . . . L + + galloc storage allocation with garbage colle\ ction . . . . + + L + + gamma log gamma function Edition Title Purpose 1 2 3 4 5 6 7 8 9 . + + + . . . . . gerts communicate with GCOS . . . . + + . + + getarg get command arguments from Fortran + + + + + + + + + getc get character or word from stream . . . + + + . . . getchar read character [getc] . . . . . . + + + getenv value for environment name . . . . . . . . + getfields break a string into fields . . . . . . . + + getfsent get file system descriptor file entry . . . . . . + + + getgrent get group file entry . . . . . . + + + getlogin get login name . . . . . . . + + getopt get option letter from argv . . . . . . + + + getpass read a password . . . + + + + . . getpw get name from UID . . . . . . + + + getpwent get password file entry . . . . . . + + + gets get a string from a stream . . . . . . . + + getwd get current directory . . . + + + . . . hmul high@@@order product . + + + + . + + + hypot euclidean distance . . . + + + . . . ierror catch Fortran errors . . . . . . . . + internet internet networking functions . . . . . . . . + ipc set up communications between unrelat\ ed processes . . . . . . + . . iread insistent read + + + . . . . . . itoa convert integer to ASCII . . . . . . + + + j0 bessel functions . . . . . . + + + l3tol convert between 3@@@byte int\ egers and long integers . . . + + + . . . ldiv long division 7 . . . . . . . . liba standard assembly@@@language\ library 7 . . . . . . . . libb standard B library 7 . . . . . . . . libf standard Fortran library . . . . . . + . . libr remote file access . . . . + + . . . locv long output conversion [printf] + + + + + + . . . log logarithm base e [exp] . . . . . . + + + malloc main memory allocator . . . . . . L + + map map projections . . . . . . . + + memory memory operations + + + + . . . . . mesg print string on typewriter [printf] . . . . . . + + + mktemp make a unique file name . . . . + + + + + monitor prepare execution profile . . . . . . + + + mp multiple precision integer arithmetic . . . + + + . . . nargs argument count . + + + + + + + + nlist get entries from name list . . . + + + + + + perror system error messages . . . . . . + . . pkopen packet driver simulator . . . . . . + + + plot graphics interface . . . . . . + + + popen initiate I/O to/from a process . . . . . . . + + port mathematical library for Fortran . . + + + + . . . pow take powers of numbers [exp] . . . . . . . . + print print formatted output . . . + + + + + . printf output formatters + + + . . . . . . ptime print time . . . . . . . + + ptopen find and open a pseudo@@@ter\ minal file + + + + + + + + + putc put character or word on a stream . . . + + + . . . putchar write character [putc] Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + + + puts put a string on a stream . + + + + + + + + qsort quicker sort . . + + + + + + + rand random number generator . . . . . . . + . regex regular expression handler [regexp] . . . . . . . + + regexp regular expression handler . . . + + + . . . reset execute non@@@local goto [se\ tjmp] . + + . . 7 L . . salloc string allocation and manipulation . . . . . . + + + scanf formatted input conversion . . . . . . + + + setbuf assign buffering to a stream . . . + + + . . . setfil specify Fortran file name . . . . . . + + + setjmp non@@@local goto + + + + + + + + + sin trigonometric functions . . . . . . + + + sinh hyperbolic functions . . . . . . + + + sleep suspend execution for interval . + + + + + . . . sqrt square root [exp] . . . . . . + + + stdio standard buffered input/output packag\ e . . . . . . + + + string string operations . . . . . . + + + swab swap bytes + + + + . . . . . switch transfer depending on value . . . . . . + + + system issue a shell command . . . . . . . . + tcp tcp networking functions . . . . . . . + + tdkdial open a datakit connection to a remote\ server . . . . . . . + + termcap terminal independent operation routin\ es . . . . . . . + + tolower force upper or lower case . . + + + + + + + ttyname find name of a terminal . . . . . . . . + udp udp networking functions . . . . . . . . + uname get password file entry . . . . . . + + + ungetc push character back into input stream . . . . . . . + + varargs variable argument list . . . . . . . + + view2d movie of a function f(x,y,t) . . . + + . . . . vt display (vt01) interface 4. Special files Terminology changed often in this section. In v3 mnemonic names were replaced by pallid hardware part designations, For example tty became kl and ppt became pc. Lately the trend has reversed, with the appearance of drum and cons. Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + + bufld buffering line discipline . . . . . . . . + connld connection line discipline . . . . . . . + + cons console interface . . . + + + + . . cat phototypesetter interface . . . + . . . . . da voice response unit . . . + + + . . . dc remote typewriter . . . . + + . . . dh DH@@@11 communications multi\ plexor . . . . . . L + + dk Datakit interface . + + + + + + . . dn DN@@@11 ACU interface . . . . . . . + + drum paging device . + + + + + . . . dp 201 dataphone Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . + . . du DU@@@11 201 data@@@\ phone interface . . . . . . . + + fd file descriptor file . . . . . + + . . hp RH@@@11/RP04, RP05, RP06 mov\ ing@@@head disk . . . . . + + . . hs RH11/RS03@@@RS04 fixed@@\ @head disk file . . . . . + + . . ht RH@@@11/TU@@@16 mag\ tape interface . . + + + + . . . kl console typewriter [cons] . + . . + + . . . lpr line printer . . . . . . . + + mesgld message line discipline + + + + + + + + . mem core memory . . . . . . . + + mt magtape interface . . . . . + + + + null data sink [under mem in v5] . . + + + + . . . pc punched paper tape . . . . . . + . . pk packet driver + + . . . . . . . ppt punched paper tape [pc] . . . . . . . + + proc process file system . . . . . . . + + pt interprocess I/O junctor files . . . . . . . + + ra DEC MSCP disks (RA60, RA80, RA81) + + + + + + + . . rf RF11/RS11 fixed@@@head disk \ file + + + + + + + + . rk RK@@@11/RK03 or RK05 disk . + + + + + + . . rp RP@@@11/RP03 moving@@@\ head disk . . . . . . . + + stream stream I/O control calls + + + . . . . . . tap DECtape file . . . + + + + . . tc TC@@@11/TU56 DECtape . . . + + . L . . tiu Spider interface . + + + + + + . . tm TM@@@11/TU@@@10 mag\ tape interface [mt] + + . . . . . . . tty console typewriter [kl] . . . . + + + . + tty general terminal interface [ttyld] + + . . . . . . . tty0... remote typewrite [dc] . . . . . . . + + ttyld terminal processing . . . . . . + . . vp Versatec printer@@@plotter . . . + + . L . . vs voice synthesizer interface . . + + + . . . . vt storage@@@tube display 5. File formats and conventions In v1@@@v5, section 5 was restricted to @@@@@\ @File formats@@@@@@ Edition Title Purpose 1 2 3 4 5 6 7 8 9 + + + + + + + + + a.out assembler and link editor output . . . . . . + + + acct execution accounting file + + + + + + + + + ar archive (library) file format . . . . . . . . + backup incremental backup file + . . . . . . . . bppt binary paper tape format + + + + + + + + + core format of core image file . . . . . . L . + cpio format of cpio archive + + + + + + + + + dir format of directories . . . . + + + . . dump incremental dump format . . . . . . + + + environ user environment . . . . . . + . . file.g drawing editor file format + + + + + + + + + filsys format of file system volume . . . . . . . + + fstab static information about the file sys\ tem Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . + + + + group group file . + . . . . . . . ident GCOD ident cards . . . . . . + + + map digitized map formats . . . . . . + . . mpxio multiplexed i/o . . . . + + + + + mtab mounted file system table . . . . . . . + . news USENET network news article, utility \ files . . . . . . . + . newsrc information file for readnews + + + + + + + + + passwd password file . . . . . 7 + + + plot graphics interface . . . . . . . . + polyhedra database format . . . . + . . . . speak.m voice synthesizer vocabulary . . . . . . . + + stab symbol table types . . . . . . L . . tar format of tar archive . . . . . . . + + termcap terminal capability database . + + + + + + . . tp DEC/mag tape formats . . . . + + + + + ttys terminal initialization data . . . . . . . + + types primitive system types + + . . . . . . . uids map names to user ID@@@s [pa\ sswd] + + + + + + + + + utmp login records . . . . . . . + + view2d movie of a function f(x,y,t) . . . . . . . + + whoami computer name . + + + + + . . . wtmp accounting files [utmp] 6. Games In v1 through v6 chapter 6 was called @@@@@@\ User maintained maintained programs.@@@@@@ Only the games fro\ m those editions are listed here; other pages from those chapters 6 are listed with chapter 1 or chapter 7. Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . L + + adventure dungeon@@@exploration game . . . . . . + + + arithmetic provide drill in number facts . . . . . . . + + atc air traffic controller . . . . . . + + + backgammon the game . . . . . . + + + banner make long posters 1 . . . . . + + + bcd convert to antique media + + + + + + + . . bj the game of black jack . . . . . . . + + boggle word games . . . . . . . + + bridge card game . . . . . . . + + card card games . . . . . . + . . checkers game + . . + + + + . . chess the game of chess . . . . . . + + . ching the book of changes and other cookies . . . + + + . . . cubic three dimensional tic@@@tac@\ @@toe . . . . . . . + + doctor psychiatric consultation . . . . . . . . + festoon memo writer . . . . . . . + . fortune cookies . . . + + . + . . maze generate a maze problem + + . + + + + . . moo guessing game . . . . . . L . . morse convert letters to morse code Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . L . . psych pattern generators . . . . . + + + + quiz test your knowledge . . . . . . + . . reversi a game of dramatic reversals . . . . . . . + + snake display chase game . . . . . . L + + trek war games . . . . . . . + + worms silly demos + + . + + 6 + . . ttt tic@@@tac@@@toe . . . . . . + . . words word games [boggle] . . . . + + + . . wump the game of hunt@@@the@@\ @wumpus 7. Data bases and language conventions Chapter 7 has had many names: v1@@@v5 Miscellaneous v6 User maintained subroutines v7 Macro packages and language conventions v8@@@v9 Databases and language conventions Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + + apnews present ap wire stories + + + + + 5 + + + ascii map of ASCII character set . . . . . . . + . candest canon laser printers [can(1)] . . . . . . L . . cdl circuit description language . . . . . . . + + dict look up words in English dictionaries . . . . . . + + + eqnchar special character definitions for eqn . . . . . . . + + font typesetter fonts . . + + + 5 + . . greek graphics for extended HdY@@@\ 37 type@@@box . . . . . . + . . hier file system hierarchy + + . . . . . . . kbd map of HdY 37 keyboard . . . . . . . + + library bell labs library service + + . . . . . . . login logging on and logging off the system . . . . . . . + + mail address conventions and rewrite rules . . . . . . + + + man macros to typeset manual . . . . . . L + + map draw maps on various projections . . . . . . . . + mbits macros for typesetting bitmaps . . . . . . . + + mcs macros for formatting cover sheets . . . . . + + + + ms macros for formatting manuscripts . . . . . . . . + papers browse database of locally authored p\ apers . . . . . . . . + netnews recent articles, utility files . . . . . . . . + poly database of polyhedra + . . . . . . . . suftab roff@@@s suffix table + + + + + 5 . . . tabs set tab stops on typewrite [tabs(1)] . . . . . . . + + tel local and private telephone books . . . . . . . + . telno retrieve from bell labs phone book [t\ el] . . . . . . + + . term conventional names . . . + + . . . . tmheader TM cover sheet . . . . . . . + + town gazetteer of US places . . . . . . . + + troff addenda to troff manual . . + + + . L . . vsp voice synthesizer phonemes . . . . . . . + + weather conditions and forecast by town Edition Title Purpose 1 2 3 4 5 6 7 8 9 8. Maintenance commands and procedures Pages from chapter 1 of v1, v2, and v7 that appeared in chapter 8 of other editions are included here. In v1 and v2 there was no chapter 8 and in v7 many system maintenance commands were placed in chapter 1, with the identification @@@@@@1M@@@@@@. Chapter 8 is the most turbulent part of the manual: mainte@@\ @ nance procedures, being known only to a few, and often being embedded in just one or two shell scripts may be more lightly changed than mainstream facilities. Moreover, much of chapter 8 is concerned with hidden procedures that are usually invoked automatically. It has alway been problematic just how much to say about such changeable things that so few people need to know about. Maintenance programs may remain @@@@@@u\ nofficial@@@@@@ for years. For example, one or another version of findo, for scouring trash out of full file systems, had existed since the earliest days, yet it was not documented until v8. Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + + 11 pdp11 support . . + + + . . . . 20boot rebooot 11/20 system . . . . . + 1 + + ac login accounting . . . . . . . . + arff read RT11 files + . . . . . . . . as2 assembler@@@s pass 2 . . . . . . . + + asd automatic software distribution + . . . . . . . . ba B assembler . . . . . . . . + backup backup administration + . . . . . . . . bc B compiler + . . . . . . . . bilib B interpreter + + + + + + + . . boot startup procedures [reboot] + . . . . . . . . brt1,brt2 B start and finish . 6 . . . . . . . chash prepare symbol table lem 1 1 + + + . . . . check check consistency of file system [ich\ eck] . . . . . + . . . chgrp change group [chown] . . 1 + + + 1 + + clri clear i@@@node . . . . . . . . + config configure a Unix kernel . . . . . . . + + cpp C language preprocessor . . . . . + + . . crash what to do when the system crashes . . . . . + + + + cron clock daemon . . + . . + 1 . . dcheck file system directory consistency che\ ck [icheck] . . . . . . . + + dmesg system diagnostic messages . 1 7 7 + + L . . dpd dataphone daemons . . . . + + 1 . . dump incremental file system dump + . . . . . . . . f1,f2,f3,f4Fortran compiler passes . . . . . . L . . fget.demon fget daemons . . . . . . . + + finddev find process using a device Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + + findo find objectionable files . . . . . . . + + fsck file system consistency check and int\ eractive repair . + + 7 + + + + + getty set typewriter mode + + + 7 + + . . . glob argument expander . . . . . + 1 + + icheck file system storage consistency check . + + + + + + + + init process control initialization . . . + . . . . . ino get the i@@@number of a file . 1 + . . . . . . istat file status by i@@@number . . . . . . . . + ldpcs load correct microcode . . . . + + L + + lpd line printer daemon . . . . . . + + + makekey generate encryption key . . . . . . . . + mgrproc service remote computing requests . . . . . . + . . mkconf generate configuration tables [config\ ] 1 . . + + + 1 + + mkfs construct a file system . . . + + + 1 + + mknod build special file 1 1 + + + + 1 + + mount mount and dismount file system + + + + + . . . . msh mini Shell . . . . . + 1 . . ncheck generate names from i@@@numb\ ers [icheck] . . . . . . . + + netfs network file system . . . . . . . + + netstat show network status for ARPA internet . . . . . . . + + oops process status . . . . . . 1 + + pstat print system facts . . . . . . 1 + + quot summarize file system ownership . . . . . . . + + rarepl replace bad blocks on MSCP drive . . . . . . . + + rc boot script . . . . . . . + + reboot bootstrapping procedures . . 1 + + . . . . reloc relocate object files . . . . . . . + + renice alter priority of running process by \ changing nice . . . . + + 1 . . restor incremental file system restore . . . . . . . + . rmdir unlink directory . . . . + + 1 + + sa system accounting . 1 + . . . . . . salv repair damaged file system . . . . . . . + + savecore save a core dump of the operating sys\ tem . . . . . . . + + showq state of stream I/O system . . . . . . . . + smash rewrite bad disk sectors 1 1 + + + + 1 + + su substitute user id temporarily . . . . . . . + + swapon specify paging/swapping device . . . + + + + + + sync update the super block . . + . . . . . . swtmp truncate accounting file 1 1 + . . . . . . tm get time information 1 1 + + + + . . . umount dismount removable file system [mount\ ] . . . . . . . + + upas address driven mailer . . . + + + + + + update periodically update the super block . . . . . . . + + uucheck check uucp directories and permission\ s file . . . . . . . + + uucico file transport program for the uucp s\ ystem . . . . . . L + + uuclean uucp spool directory cleanup . . . . . . . + . uusched uucp file transport scheduler [uucico\ ] . . . . . . . + + uuxqt create remote command requests . . . . . . . + + vmstat report virtual memory statistics . . . . . + 1 + + wall write to all users . . . . . . . + . xstr preprocessor for sharing strings in C\ programs 9. Teletype 5620@@@related software Edition Title Purpose 1 2 3 4 5 6 7 8 9 . . . . . . . + + intro introduction to jerq@@@relat\ ed software 9.1 Commands . . . . . . . + + 32ld bootstrap loader for the 5620 . . . . . . . + + 3cc MAC@@@32 compiler for the 56\ 20 . . . . . . . + + blitblt make hard copy image . . . . . . . . + brush painting program . . . . . . . + + cip picture drawing program . . . . . . . + + face show faces on a jerq . . . . . . . . + flicks movie graphics for 5620 . . . . . . . . + getfont replace terminal@@@s default\ font . . . . . . . + + icon icon editor . . . . . . . + + jf font editor . . . . . . . + . jim text editor [sam] . . . . . . . + + jx jerq execution and stdio interpreter . . . . . . . + + graphdraw edit (combinatoric) graph . . . . . . . + + lens bitmap magnifier . . . . . . . . + menudrop leave a menu lying around . . . . . . . + + mugs convert gray@@@scale images \ into icons . . . . . . . + + mux layer multiplexor for the jerq . . . . . . . + + paint draw pictures in a layer . . . . . . . + + ped picture editor . . . . . . . + + pi process inspector . . . . . . . + + pico graphics editor . . . . . . . + + proof troff output interpreter for jerq . . . . . . . . + pvmon gray@@@scale picture preview\ window for 5620 . . . . . . . . + reader examine typeset documents . . . . . . . + + rebecca graphics touch@@@up editor . . . . . . . + + ruler measure things on the screen . . . . . . . + . sysmon display system statistics [vismon] . . . . . . . . + sam screen editor with structural regular\ expressions . . . . . . . + + term nonstandard mux terminals . . . . . . . + + thinkblt print on ThinkJet . . . . . . . . + vismon system statistics and mail notificati\ on . . . . . . . + + windows create and initialize windows 9.2 System calls . . . . . . . + + button mouse control . . . . . . . + + newlayer layer control and graphics . . . . . . . + + newproc jerq process control . . . . . . . + + request jerq I/O requests 9.3 Subroutines . . . . . . . + + add arithmetic on points and rectangles . . . . . . . + + alloc allocate memory . . . . . . . + + bitblt basic jerq graphics functions . . . . . . . + + circle circle drawing functions for jerq . . . . . . . + + cos integer math functions . . . . . . . + + menuhit present user with menu and get select\ ion . . . . . . . + + string jerq text and font operations . . . . . . . . + thinkclientThinkJet routines 9.4 Devices . . . . . . . + + jioctl jerq ioctl requests . . . . . . . + + mouse jerq mouse interface Edition Title Purpose 1 2 3 4 5 6 7 8 9 9.5 File formats and conventions . . . . . . . + + bitfile format of bitmap file . . . . . . . + + faced network face server . . . . . . . + + font jerq font layouts . . . . . . . . + movies graphics movie file formats . . . . . . . + + pads user interface package . . . . . . . + + types basic jerq graphics data types 9.6 Games . . . . . . . + + crabs graphical marine adventure game . . . . . . . + + demo graphic demonstration and games . . . . . . . . + gebaca get back at corporate america . . . . . . . + + pen doodle anywhere on the screen . . . . . . . . + pengo squash the sno@@@bees . . . . . . . + + twid dabble in oils 9.7 Data bases . . . . . . . + + blitmap map plots and path finding on a jerq From rich.salz at gmail.com Fri Feb 7 00:54:08 2020 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 6 Feb 2020 09:54:08 -0500 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200206030044.GD21264@mcvoy.com> <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> Message-ID: The name comes from ITS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Feb 7 01:10:41 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 06 Feb 2020 15:10:41 +0000 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: (Richard Salz's message of "Thu, 6 Feb 2020 09:54:08 -0500") References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200206030044.GD21264@mcvoy.com> <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> Message-ID: <7w1rr7oioe.fsf@junk.nocrew.org> Richard Salz wrote: > The name comes from ITS. It was first invented by Les Earnest at SAIL. https://web.stanford.edu/~learnest/les/ "1972 Social networking and blogging service (FINGER) was initially just for SAIL but became a network service in 1975, " From chet.ramey at case.edu Fri Feb 7 01:35:24 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 6 Feb 2020 10:35:24 -0500 Subject: [TUHS] Atari System V media and books? In-Reply-To: <20200206035457.GF21264@mcvoy.com> References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> <20200206035457.GF21264@mcvoy.com> Message-ID: On 2/5/20 10:54 PM, Larry McVoy wrote: > Part of me is wondering why anyone cares about Motif. My memory of that > is that Xview was better and the Athena widgets were better. https://www.youtube.com/watch?v=cj02_UeUnGQ "A Political History of X" - Keith Packard (LCA 2020) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From mparson at bl.org Fri Feb 7 01:50:39 2020 From: mparson at bl.org (Michael Parson) Date: Thu, 06 Feb 2020 09:50:39 -0600 Subject: [TUHS] Atari System V media and books? In-Reply-To: <20200206035457.GF21264@mcvoy.com> References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> <20200206035457.GF21264@mcvoy.com> Message-ID: <9d8ccfd6e3b34a4a586e4947e861551f@bl.org> On 2020-02-05 21:54, Larry McVoy wrote: > On Wed, Feb 05, 2020 at 09:44:02PM -0600, Michael Parson wrote: >> On Wed, 5 Feb 2020, Chris Hanson wrote: >> >On Jan 18, 2020, at 3:19 PM, Michael Parson wrote: >> > >> >>Speaking of old versions of Motif, are the sources for the >> >>pre-OpenMotif bits available anywhere? Even if under lock and key >> >>for now, I'd be happy knowing they'd been preserved for potential >> >>future availability. >> > >> >There are Motif 1.1 sources on Bitsavers (or your favorite mirror) >> >at > >>. >> >> Thank you! > > Part of me is wondering why anyone cares about Motif. My memory of > that > is that Xview was better and the Athena widgets were better. Athena > was > ugly but it worked, Xview, the X11 version of Sunview, was fantastic to > program in, the argv was a set of 2 tuples, thing and value. And it > looked better. I've written Xview apps and other than the Tk part of > Tcl/Tk, it was the most pleasant GUI API I have used. For the record, > the Tk part of Tcl/Tk is still, decades later, the best GUI interface > I've ever seen. John got that right. > > So no offense intended, what about Motif is likeable? No offense taken. It's not so much that it's "likeable", at least, any more than playing with any old software is "likeable". It only crossed my radar because someone mentioned that it was available for Atari UNIX (ASV), would those bits be able to be used on Amiga UNIX (AMIX)? I was able to pull the bits off the ASV images and get them running on AMIX, but it requires setting LD_LIBRARY_PATH to load the ASV X11 libs, so, I thought, if I could get my hands on the source, I could compile it against the AMIX supplied libs, then maybe try and get Mosaic compiled as well. -- Michael Parson Pflugerville, TX KF5LGQ From arno.griffioen at ieee.org Fri Feb 7 03:58:40 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Thu, 6 Feb 2020 18:58:40 +0100 Subject: [TUHS] Atari System V media and books? In-Reply-To: <9d8ccfd6e3b34a4a586e4947e861551f@bl.org> References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> <20200206035457.GF21264@mcvoy.com> <9d8ccfd6e3b34a4a586e4947e861551f@bl.org> Message-ID: <20200206175840.GH15253@ancienthardware.org> On Thu, Feb 06, 2020 at 09:50:39AM -0600, Michael Parson wrote: > No offense taken. It's not so much that it's "likeable", at least, any > more than playing with any old software is "likeable". It only crossed > my radar because someone mentioned that it was available for Atari UNIX > (ASV), would those bits be able to be used on Amiga UNIX (AMIX)? I was Just nitpicking a little :) I know Amiga UNIX is often referred to as AMIX, but 'in the day' there was an actual 'AMIX' which was an CBM in-house only port of SVR3.2 to 'A2500UX' labeled machines. (basically 68020+MMU equipped boxes) These ran the internal email and file distribution network, but was never publicly released. Quite noticeable as it boots into an ASCII console with a bright orange background. Same background that some of the 68020/030 cards boot ROMs show when choosing the 'boot UNIX' option. Worked on that old platform for some time.. Part of my projects was to migrate some of the tools to the 'next version' which was.. The actual product sold as 'Amiga UNIX'. (not 'AMIX' ;) ) This was the SVR4 port in a V1 and V2 version with the latter getting a bunch of updates to streamline it on the platform. V1 was really only sold/used to launch-customers while V2 was more publicly available. (V1 was trivial to hack around the '1 user' base license with a little 'od' and binary patching ;) ) Interesting issue at the time was that, according to the internal grapevine at CBM at the time, the Amiga UNIX SVR4 was not m68k ABI compliant, so it could not run pre-packaged m68k-svr4 software that did use this interface. Reason was rumoured to be that CBM (in ther never-ending efforts to do things 'cheap') got the cheapest source license they could get for SVR4 which AFAIK was for the 3B2 or similar AT&T platform and they did not get an actual m68k source and license. Never got that really verified, but I do know that at the time the lack of support for the m68k ABI was a big hurdle for acceptance. > but it requires setting LD_LIBRARY_PATH to load the ASV X11 libs, so, I > thought, if I could get my hands on the source, I could compile it against > the AMIX supplied libs, then maybe try and get Mosaic compiled as well. The SVR4 Amiga UNIX used CDE and all bits for the X11 environment, so the binaries should all be there. No sources were available to people outside the CBM UNIX group at the headquarters at the time, but perhaps they got out onto the net when it all went down. The UNIX group inside CBM got disbanded way before they went totally out of business, so it may have well gone into the shredder at some point. Quitting the CBM-UNIX group was done very crudely I might add with some of the guys from the US being over in europe when they got told that they were fired and their company creditcards got blocked at the same time.. classy... Bye, Arno. From dave at horsfall.org Fri Feb 7 05:55:28 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 7 Feb 2020 06:55:28 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Wed, 5 Feb 2020, Dan Cross wrote: > Perhaps I've sent this story to TUHS before, but I can't resist.  > "finger: the most inappropriately named command in computerdom" (no, > that's not a challenge...). [ Hilarious story ] Back in ye olde Usenet days, someone had an animated .plan which was all about the "Andalusian snail" (the "@" character was the snail). It used ANSI escape sequences, showing it in the 25th line (the "status" line), and was quite funny. Of course, you had to have the right speed; too fast, and it just zipped past, and too slow, well, it, just crawled along :-) ISTR that 9600 was about right. Anyone remember that? Oh, my .plan in those days said "To rid the world of Intel chips" (sorry Clem, but this was back in the days of Intel vs. Moto). It now reads "To rid the world of M$ software" but these days the finger service is generally blocked. -- Dave From dave at horsfall.org Fri Feb 7 06:14:18 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 7 Feb 2020 07:14:18 +1100 (EST) Subject: [TUHS] pronouncing *nix formulas In-Reply-To: <7w1rr7oioe.fsf@junk.nocrew.org> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200206030044.GD21264@mcvoy.com> <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> <7w1rr7oioe.fsf@junk.nocrew.org> Message-ID: On Thu, 6 Feb 2020, Lars Brinkhoff wrote: > "1972 Social networking and blogging service (FINGER) was initially just > for SAIL but became a network service in 1975, " Blogs were in use in 1972? -- Dave From imp at bsdimp.com Fri Feb 7 06:20:10 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 6 Feb 2020 13:20:10 -0700 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200206030044.GD21264@mcvoy.com> <20200206052037.lkd7gyxv3b45zo2f@unixfarts.net> <7w1rr7oioe.fsf@junk.nocrew.org> Message-ID: On Thu, Feb 6, 2020 at 1:14 PM Dave Horsfall wrote: > On Thu, 6 Feb 2020, Lars Brinkhoff wrote: > > > "1972 Social networking and blogging service (FINGER) was initially just > > for SAIL but became a network service in 1975, " > > Blogs were in use in 1972? > Finger would tell you what people had just done, and what they planned to do... So in a sense that's true, but it's a big stretch based on today's meaning... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Fri Feb 7 07:48:37 2020 From: mparson at bl.org (Michael Parson) Date: Thu, 6 Feb 2020 15:48:37 -0600 (CST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Fri, 7 Feb 2020, Dave Horsfall wrote: > On Wed, 5 Feb 2020, Dan Cross wrote: > >> Perhaps I've sent this story to TUHS before, but I can't resist.  >> "finger: the most inappropriately named command in computerdom" (no, >> that's not a challenge...). > > [ Hilarious story ] > > Back in ye olde Usenet days, someone had an animated .plan which was > all about the "Andalusian snail" (the "@" character was the snail). > It used ANSI escape sequences, showing it in the 25th line (the > "status" line), and was quite funny. > > Of course, you had to have the right speed; too fast, and it just > zipped past, and too slow, well, it, just crawled along :-) ISTR that > 9600 was about right. > > Anyone remember that? I loved ascii animations back the day, collected a bunch of them, including the one about the Andalusion Video Snail @/ http://bl.org/~mparson/ascii-anim/ There's a perl script in there for 'slowcat' to print them out slower. -- Michael Parson Pflugerville, TX KF5LGQ From clemc at ccc.com Fri Feb 7 08:17:27 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 6 Feb 2020 14:17:27 -0800 Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: No worries Dave. I was a die hard moto fan. And I’m the first to tell you the Intel ISA is wretched. But what I have learned is that it does not matter. They are all dataflow systems internally at this point. On Thu, Feb 6, 2020 at 11:56 AM Dave Horsfall wrote: > On Wed, 5 Feb 2020, Dan Cross wrote: > > > Perhaps I've sent this story to TUHS before, but I can't resist. > > "finger: the most inappropriately named command in computerdom" (no, > > that's not a challenge...). > > [ Hilarious story ] > > Back in ye olde Usenet days, someone had an animated .plan which was all > about the "Andalusian snail" (the "@" character was the snail). It used > ANSI escape sequences, showing it in the 25th line (the "status" line), > and was quite funny. > > Of course, you had to have the right speed; too fast, and it just zipped > past, and too slow, well, it, just crawled along :-) ISTR that 9600 was > about right. > > Anyone remember that? > > Oh, my .plan in those days said "To rid the world of Intel chips" (sorry > Clem, but this was back in the days of Intel vs. Moto). It now reads "To > rid the world of M$ software" but these days the finger service is > generally blocked. > > -- Dave -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Fri Feb 7 09:15:23 2020 From: mparson at bl.org (Michael Parson) Date: Thu, 6 Feb 2020 17:15:23 -0600 (CST) Subject: [TUHS] Atari System V media and books? In-Reply-To: <20200206175840.GH15253@ancienthardware.org> References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> <20200206035457.GF21264@mcvoy.com> <9d8ccfd6e3b34a4a586e4947e861551f@bl.org> <20200206175840.GH15253@ancienthardware.org> Message-ID: On Thu, 6 Feb 2020, Arno Griffioen wrote: > On Thu, Feb 06, 2020 at 09:50:39AM -0600, Michael Parson wrote: >> No offense taken. It's not so much that it's "likeable", at least, any >> more than playing with any old software is "likeable". It only crossed >> my radar because someone mentioned that it was available for Atari UNIX >> (ASV), would those bits be able to be used on Amiga UNIX (AMIX)? I was > > Just nitpicking a little :) > > I know Amiga UNIX is often referred to as AMIX, but 'in the day' there > was an actual 'AMIX' which was an CBM in-house only port of SVR3.2 to > 'A2500UX' labeled machines. (basically 68020+MMU equipped boxes) > > These ran the internal email and file distribution network, but was > never publicly released. Quite noticeable as it boots into an ASCII > console with a bright orange background. > > Same background that some of the 68020/030 cards boot ROMs show when > choosing the 'boot UNIX' option. Neat. This is the first time I've heard of this UNIX from Commodore. I'd heard of Amiga UNIX, which ran on the A3000 and A2000s with the appropriate 68020(+MMU) or 030 upgrades, and their failed CBM 900 project, which was based on the Z8001, which was reported to be a port of MWC Coherent rather than based on the AT&T code. > Worked on that old platform for some time.. Part of my projects was to > migrate some of the tools to the 'next version' which was.. > > The actual product sold as 'Amiga UNIX'. (not 'AMIX' ;) ) $ uname -a UNIX_System_V amy 4.0 2.1c 0800430 Amiga (Unlimited) m68k > This was the SVR4 port in a V1 and V2 version with the latter getting > a bunch of updates to streamline it on the platform. > > V1 was really only sold/used to launch-customers while V2 was more > publicly available. (V1 was trivial to hack around the '1 user' base > license with a little 'od' and binary patching ;) ) > > Interesting issue at the time was that, according to the internal > grapevine at CBM at the time, the Amiga UNIX SVR4 was not m68k ABI > compliant, so it could not run pre-packaged m68k-svr4 software that > did use this interface. The docs claim that there was an attempt to make it ABI compliant, but the ABI wasn't "finalized" or something, so, future compatibility was not guaranteed. > Reason was rumoured to be that CBM (in ther never-ending efforts to > do things 'cheap') got the cheapest source license they could get for > SVR4 which AFAIK was for the 3B2 or similar AT&T platform and they did > not get an actual m68k source and license. > > Never got that really verified, but I do know that at the time the > lack of support for the m68k ABI was a big hurdle for acceptance. *shrug* Atari UNIX and Amiga UNIX seem close enough that some stuff compiled on Atari works on the Amiga. Out of curiosity, how much m68k SysV software was out there? >> but it requires setting LD_LIBRARY_PATH to load the ASV X11 libs, so, >> I thought, if I could get my hands on the source, I could compile >> it against the AMIX supplied libs, then maybe try and get Mosaic >> compiled as well. > > The SVR4 Amiga UNIX used CDE and all bits for the X11 environment, so > the binaries should all be there. The install bits that have survived and escaped onto the Internet have X11R4 with XView/OpenLook, no Motif/CDE. There was a port of X11R5 to it that supported some of the newer graphics cards, but still no Motif. > No sources were available to people outside the CBM UNIX group at the > headquarters at the time, but perhaps they got out onto the net when > it all went down. Would be cool if someone found a tape and got it in the right hands. > The UNIX group inside CBM got disbanded way before they went totally > out of business, so it may have well gone into the shredder at some > point. Rumors were that *the* box that had the source on it crashed. Sounded like a ridiculous reason to me, but that's what I'd heard. > Quitting the CBM-UNIX group was done very crudely I might add with > some of the guys from the US being over in europe when they got told > that they were fired and their company creditcards got blocked at the > same time.. classy... >From what I've heard about the last days of Commodore under Mehdi Ali, this doesn't surprise me. -- Michael Parson Pflugerville, TX KF5LGQ From mparson at bl.org Fri Feb 7 09:56:34 2020 From: mparson at bl.org (Michael Parson) Date: Thu, 6 Feb 2020 17:56:34 -0600 (CST) Subject: [TUHS] pronouncing *nix formulas (was: screen editors) In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: On Thu, 6 Feb 2020, Michael Parson wrote: > I loved ascii animations back the day, collected a bunch of them, > including the one about the Andalusion Video Snail @/ > > http://bl.org/~mparson/ascii-anim/ > > There's a perl script in there for 'slowcat' to print them out slower. I've fixed the perms. Sorry 'bout that. -- Michael Parson Pflugerville, TX KF5LGQ From grog at lemis.com Fri Feb 7 10:21:14 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 7 Feb 2020 11:21:14 +1100 Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> Message-ID: <20200207002114.GA6005@eureka.lemis.com> On Friday, 7 February 2020 at 6:55:28 +1100, Dave Horsfall wrote: > > Oh, my .plan in those days said "To rid the world of Intel chips" > (sorry Clem, but this was back in the days of Intel vs. Moto). It > now reads "To rid the world of M$ software" but these days the > finger service is generally blocked. It is? My .sig (not modified for this answer) includes a finger reference, and "it works for me". Do some services block incoming fingers? 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 usotsuki at buric.co Fri Feb 7 10:27:57 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 6 Feb 2020 19:27:57 -0500 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: <20200207002114.GA6005@eureka.lemis.com> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> Message-ID: On Fri, 7 Feb 2020, Greg 'groggy' Lehey wrote: > On Friday, 7 February 2020 at 6:55:28 +1100, Dave Horsfall wrote: >> >> Oh, my .plan in those days said "To rid the world of Intel chips" >> (sorry Clem, but this was back in the days of Intel vs. Moto). It >> now reads "To rid the world of M$ software" but these days the >> finger service is generally blocked. > > It is? My .sig (not modified for this answer) includes a finger > reference, and "it works for me". Do some services block incoming > fingers? > > 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 > I have Debian installed in the Linux emulation environment on my main computer (as well as on my other desktop), so I decided to try running the finger command from your .sig ;p Works fine on my end. (It's supposed to end in "20Segmentation fault (core dumped)", right?) I have never tried to install a finger daemon on any of my boxen so as to permit being able to receive incoming finger requests. Just hasn't been important enough to me. -uso. From krewat at kilonet.net Fri Feb 7 10:54:13 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 6 Feb 2020 19:54:13 -0500 Subject: [TUHS] finger usage (was: pronouncing *nix formulas In-Reply-To: References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> Message-ID: <9f0a620b-c766-a05a-d9a9-b15e2acb84bf@kilonet.net> On 2/6/2020 7:27 PM, Steve Nickolas wrote: > > I have Debian installed in the Linux emulation environment on my main > computer (as well as on my other desktop), so I decided to try running > the finger command from your .sig ;p > > Works fine on my end.  (It's supposed to end in "20Segmentation fault > (core dumped)", right?) > > I have never tried to install a finger daemon on any of my boxen so as > to permit being able to receive incoming finger requests. Just hasn't > been important enough to me. Same here, using Solaris 11.3 medusa<@:1>% finger grog at lemis.com [lemis.com] Login: grog                             Name: Greg 'groggy' Lehey Directory: /home/grog                   Shell: /usr/local/bin/bash Office:  Dereel VIC,  +61-3-5346-1370 Mail last read Sat Nov  9 05:06 2019 (UTC) Project: Home page:  http://www.lemis.com/grog/ PGP public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org -----END PGP PUBLIC KEY BLOCK----- Plan: 2020: Dereel 2021: Goldfields 2022: Victoria 2023: Australia 2024: The world 20Segmentation fault (core dumped) medusa<@:1>% uname -a SunOS medusa 5.11 11.3 i86pc i386 i86pc medusa<@:1>% pkg info entire              Name: entire           Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.9.4.0).       Description: This package constrains system package versions to the same                    build.  WARNING: Proper system update and correct package                    selection depend on the presence of this incorporation.                    Removing this package will result in an unsupported system.                    For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1          Category: Meta Packages/Incorporations             State: Installed         Publisher: solaris           Version: 0.5.11 (Oracle Solaris 11.3.9.4.0)     Build Release: 5.11            Branch: 0.175.3.9.0.4.0    Packaging Date: June 10, 2016 12:51:48 AM              Size: 5.46 kB              FMRI: pkg://solaris/entire at 0.5.11,5.11-0.175.3.9.0.4.0:20160610T005148Z From rich.salz at gmail.com Fri Feb 7 11:00:52 2020 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 6 Feb 2020 20:00:52 -0500 Subject: [TUHS] finger usage (was: pronouncing *nix formulas In-Reply-To: <9f0a620b-c766-a05a-d9a9-b15e2acb84bf@kilonet.net> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <9f0a620b-c766-a05a-d9a9-b15e2acb84bf@kilonet.net> Message-ID: Almost anyone behind a corporate firewall will not allow incoming port 29 (finger) connections. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Feb 7 14:23:09 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 7 Feb 2020 15:23:09 +1100 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: <20200207002114.GA6005@eureka.lemis.com> References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> Message-ID: On Fri, 7 Feb 2020, Greg 'groggy' Lehey wrote: >> Oh, my .plan in those days said "To rid the world of Intel chips" >> (sorry Clem, but this was back in the days of Intel vs. Moto). It >> now reads "To rid the world of M$ software" but these days the >> finger service is generally blocked. > > It is? My .sig (not modified for this answer) includes a finger > reference, and "it works for me". Do some services block incoming > fingers? Depends on the firewall, of course; I block it here (or rather, I don't allow it). You'll find my PGP stuff in the headers, for example. -- Dave From dave at horsfall.org Fri Feb 7 14:31:28 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 7 Feb 2020 15:31:28 +1100 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: References: <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> Message-ID: On Thu, 6 Feb 2020, Steve Nickolas wrote: > Works fine on my end. (It's supposed to end in "20Segmentation fault > (core dumped)", right?) I suspect that Greg is having a little fun :-) Did you get a core dump? Now I'm wondering what timebomb is in the year 2025... -- Dave From grog at lemis.com Fri Feb 7 15:07:00 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 7 Feb 2020 16:07:00 +1100 Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> Message-ID: <20200207050700.GD6005@eureka.lemis.com> On Friday, 7 February 2020 at 15:31:28 +1100, Dave Horsfall wrote: > On Thu, 6 Feb 2020, Steve Nickolas wrote: > >> Works fine on my end. (It's supposed to end in "20Segmentation fault >> (core dumped)", right?) Funny, I didn't get Steve's message. Clearly the obvious check is $ echo $? But over the years I've been surprised how many people have been fooled. 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 usotsuki at buric.co Fri Feb 7 15:39:16 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 7 Feb 2020 00:39:16 -0500 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: <20200207050700.GD6005@eureka.lemis.com> References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <20200207050700.GD6005@eureka.lemis.com> Message-ID: On Fri, 7 Feb 2020, Greg 'groggy' Lehey wrote: > On Friday, 7 February 2020 at 15:31:28 +1100, Dave Horsfall wrote: >> On Thu, 6 Feb 2020, Steve Nickolas wrote: >> >>> Works fine on my end. (It's supposed to end in "20Segmentation fault >>> (core dumped)", right?) > > Funny, I didn't get Steve's message. Remangled the header so it only goes to the list, so the list should handle passing it on. ;p Your mailserver rejected the message from my server (frieza.hoshinet.org). > Clearly the obvious check is > > $ echo $? I did "ls -tr" to check for a coredump. ;p > But over the years I've been surprised how many people have been fooled. > > Greg -uso. From peter at rulingia.com Fri Feb 7 15:26:52 2020 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 7 Feb 2020 16:26:52 +1100 Subject: [TUHS] finger usage (was: pronouncing *nix formulas In-Reply-To: <9f0a620b-c766-a05a-d9a9-b15e2acb84bf@kilonet.net> References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <9f0a620b-c766-a05a-d9a9-b15e2acb84bf@kilonet.net> Message-ID: <20200207052652.GD58591@server.rulingia.com> On 2020-Feb-06 19:54:13 -0500, Arthur Krewat wrote: >medusa<@:1>% finger grog at lemis.com ... > >PGP public key: My mutt fed the section marked as being a public key (which actually just contained into gpg, which got rather confused. A danger of hand- edited data inside "magic" headers that flag it as a type of content. -- 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 arno.griffioen at ieee.org Fri Feb 7 21:53:17 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Fri, 7 Feb 2020 12:53:17 +0100 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: <3C26A155-81B4-4341-A422-3AD0346DEC09@eschatologist.net> <20200206035457.GF21264@mcvoy.com> <9d8ccfd6e3b34a4a586e4947e861551f@bl.org> <20200206175840.GH15253@ancienthardware.org> Message-ID: <20200207115317.GI15253@ancienthardware.org> On Thu, Feb 06, 2020 at 05:15:23PM -0600, Michael Parson wrote: > > Never got that really verified, but I do know that at the time the > > lack of support for the m68k ABI was a big hurdle for acceptance. > > *shrug* Atari UNIX and Amiga UNIX seem close enough that some stuff > compiled on Atari works on the Amiga. > > Out of curiosity, how much m68k SysV software was out there? A decent amount, at least for basic productivity software (accounting, etc.) and compilers and such. Nothing spectacular, but would have given at least an initial library of basic tools. > > The SVR4 Amiga UNIX used CDE and all bits for the X11 environment, so > > the binaries should all be there. > > The install bits that have survived and escaped onto the Internet have > X11R4 with XView/OpenLook, no Motif/CDE. There was a port of X11R5 to > it that supported some of the newer graphics cards, but still no Motif. Ah.. Yes you are right.. De distribution tape only has XView. CDE I probably only saw on an in-house demo of. I remember it was terribly slow though, especially with the limited RAM capacity at the time of max 16MB and a 25Mhz '030, which was already showing it's age by now and should really have been an '040 with the option of (much) more RAM. Bye, Arno. From krewat at kilonet.net Sat Feb 8 02:14:09 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 7 Feb 2020 11:14:09 -0500 Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: <20200207050700.GD6005@eureka.lemis.com> References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <20200207050700.GD6005@eureka.lemis.com> Message-ID: <0f016107-e690-7a01-e86f-f5f3ca55eb81@kilonet.net> Sorry, I forgot to add a ;) to the end of that ;) On 2/7/2020 12:07 AM, Greg 'groggy' Lehey wrote: > On Friday, 7 February 2020 at 15:31:28 +1100, Dave Horsfall wrote: >> On Thu, 6 Feb 2020, Steve Nickolas wrote: >> >>> Works fine on my end. (It's supposed to end in "20Segmentation fault >>> (core dumped)", right?) > Funny, I didn't get Steve's message. > > Clearly the obvious check is > > $ echo $? > > But over the years I've been surprised how many people have been fooled. > > 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 From dave at horsfall.org Sat Feb 8 07:39:49 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Feb 2020 08:39:49 +1100 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <20200207050700.GD6005@eureka.lemis.com> Message-ID: On Fri, 7 Feb 2020, Steve Nickolas wrote: > I did "ls -tr" to check for a coredump. ;p Core files aren't always found in the current directory. In fact, they've been evolving over the years; first, it was "core", then "core.PID" (and I think I saw "PID.core" once, or was that process.core"?), and now they seem to be in /cores. Of course, YMMV... -- Dave From wkt at tuhs.org Sat Feb 8 08:25:27 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 08 Feb 2020 08:25:27 +1000 Subject: [TUHS] Warner's Early Unix Presentation Message-ID: https://fosdem.org/2020/schedule/event/early_unix/ The video of Warner Losh's FOSDEM presentation "The Hidden Early History of Unix" is now available. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 8 08:37:22 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Feb 2020 09:37:22 +1100 (EST) Subject: [TUHS] finger usage (was: pronouncing *nix formulas (was: screen editors)) In-Reply-To: <20200207050700.GD6005@eureka.lemis.com> References: <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <20200207002114.GA6005@eureka.lemis.com> <20200207050700.GD6005@eureka.lemis.com> Message-ID: On Fri, 7 Feb 2020, Greg 'groggy' Lehey wrote: > But over the years I've been surprised how many people have been fooled. I'm sure that we've all pulled pranks like that. My favourite was piping the output of "man" (a shell script on that system) through "Valley Girl" (where each "!" was followed e.g. by "Gag me with a spoon!" etc). Well, $BOSS came into the office after a "heavy" night, and did something like "man uucp", not quite figuring out what was wrong; I was summoned shortly afterwards, as I was the only possible culprit... -- Dave From dave at horsfall.org Sat Feb 8 09:05:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Feb 2020 10:05:27 +1100 (EST) Subject: [TUHS] Screen editors In-Reply-To: <20200129223322.GK6410@mcvoy.com> References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: On Wed, 29 Jan 2020, Larry McVoy wrote: >> Getting a full ANSI C compiler for CP/M was great; I could use some >> Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was >> ANSI (function prototypes and the works) whereas the other wouldn't >> even recognise things like "int i = 1;". > > BDS was pretty good about C, I used it a *lot*, but it had a really > funky not compatible libc/stdio. I got used to it but had to retrain my > brain when I was on Unix. I remember now; it was Hi-Tech C (an Aussie company) that was full ANSI; BDS C could barely compile C... I think it was Henry Spencer who said something like "Somehow, to be called a C compiler it ought to at least compile C" (I don't think he was referring to BDS C, though). -- Dave From rich.salz at gmail.com Sat Feb 8 09:54:33 2020 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 7 Feb 2020 18:54:33 -0500 Subject: [TUHS] Screen editors In-Reply-To: References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: BDS C stood for Brain-Damaged Software, it was the work of one guy (Leor Zolman). I think it was used to build the Mark of the Unicorn stuff (MINCE, Mince is not complete emacs, and Scribble, a scribe clone). -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Feb 8 09:57:41 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 8 Feb 2020 10:57:41 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: Very nice talk with lots of good background. It made me think of the boxes of DECTapes we had under the Unix room floor, and what we might have lost. (Volunteers did manage to recover a couple of them, but time was short). PWB inaccuracy: The talk said that tools like grep and sed came from PWB, but that's not true. They were original, as I'm sure Warner knows; he just misspoke. Slightly more important: PWB also did not introduce the idea of the shell (neither did Unix, for that matter), although there was a distinct shell for that system that included the legendary pump operator, later superseded by here documents. The flow from PWB back to the main research line was a trickle at best. We had bad NIH in 1127. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Sat Feb 8 10:05:50 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 07 Feb 2020 16:05:50 -0800 Subject: [TUHS] Screen editors In-Reply-To: Your message of "Sat, 08 Feb 2020 10:05:27 +1100." References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: <20200208000557.BBBA5156E40E@mail.bitblocks.com> On Sat, 08 Feb 2020 10:05:27 +1100 Dave Horsfall wrote: > On Wed, 29 Jan 2020, Larry McVoy wrote: > > >> Getting a full ANSI C compiler for CP/M was great; I could use some > >> Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was > >> ANSI (function prototypes and the works) whereas the other wouldn't > >> even recognise things like "int i = 1;". > > > > BDS was pretty good about C, I used it a *lot*, but it had a really > > funky not compatible libc/stdio. I got used to it but had to retrain my > > brain when I was on Unix. > > I remember now; it was Hi-Tech C (an Aussie company) that was full ANSI; > BDS C could barely compile C... > > I think it was Henry Spencer who said something like "Somehow, to be > called a C compiler it ought to at least compile C" (I don't think he was > referring to BDS C, though). You can see for yourself! The compiler is written in assembler! https://github.com/k0gaMSX/legacy/tree/master/PROG/C/BDS https://github.com/pbetti/ZDS/tree/master/software/bdsc There is lots of other stuff including other C compilers, Pascal, Basic, games etc. From wkt at tuhs.org Sat Feb 8 10:43:52 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 8 Feb 2020 10:43:52 +1000 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: <20200208004352.GA4931@minnie.tuhs.org> On Sat, Feb 08, 2020 at 10:57:41AM +1100, Rob Pike wrote: > Slightly more important: PWB also did not introduce > the idea of the shell (neither did Unix, for that matter) ... Yes, we should ask Warner what he meant here. I thought perhaps he meant a shell which allowed scripts. Also, another nitpick not just for Warner but for a few talks I've seen over the past 12 months. TUHS is the Unix _Heritage_ Society not the Unix Historical Society :-) I don't mind either way, happy for us to get some attention! Cheers all, Warren From pnr at planet.nl Sat Feb 8 11:34:12 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 8 Feb 2020 02:34:12 +0100 Subject: [TUHS] Presotto paper Message-ID: On the Nokia / Bell labs site I came across this publication: https://www.bell-labs.com/our-research/publications/234131/ Presotto D.: TCP/IP and Datakit - Two Views of Networking I’m not having much luck with finding out more about it. Does anybody recall this paper and where/when it might have been published? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 8 13:11:07 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Feb 2020 14:11:07 +1100 (EST) Subject: [TUHS] Screen editors In-Reply-To: References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: On Fri, 7 Feb 2020, Richard Salz wrote: > BDS C stood for Brain-Damaged Software [...] Yes, I've heard it called that :-) It sure was... -- Dave From ron at ronnatalie.com Sat Feb 8 13:31:55 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 8 Feb 2020 16:31:55 +1300 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> Message-ID: <2AA1D51F-A135-442F-A6FE-F5000452A648@ronnatalie.com> It has been F-Suck since we first got a copy. My favorite UNIX quote was Ken Thompson (I hope I’m getting this right Ken), when asked if he could do it over again, if he’d change anything. He said he’d put an “e” on the end of creat. I’ve always pronounced it CREE-AT. From imp at bsdimp.com Sat Feb 8 13:37:20 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Feb 2020 20:37:20 -0700 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: <20200208004352.GA4931@minnie.tuhs.org> References: <20200208004352.GA4931@minnie.tuhs.org> Message-ID: On Fri, Feb 7, 2020, 5:44 PM Warren Toomey wrote: > On Sat, Feb 08, 2020 at 10:57:41AM +1100, Rob Pike wrote: > > Slightly more important: PWB also did not introduce > > the idea of the shell (neither did Unix, for that matter) ... > > Yes, we should ask Warner what he meant here. I thought perhaps he meant > a shell which allowed script > Yes. I meant the first shell that allowed real scripting. Also, another nitpick not just for Warner but for a few talks I've seen > over the past 12 months. TUHS is the Unix _Heritage_ Society not the > Unix Historical Society :-) > Doh! I don't mind either way, happy for us to get some attention! > > Cheers all, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Feb 8 13:38:49 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 8 Feb 2020 16:38:49 +1300 Subject: [TUHS] Screen editors In-Reply-To: References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> <20200129223322.GK6410@mcvoy.com> Message-ID: <74292D02-8B74-4EA1-8AFE-66C78B511572@ronnatalie.com> Amusingly, I was a co-owner of a company called BDS (not the C complier people). I knew the BDS-C people existed having been a customer for a while. I got the BDS.COM domain early on. We promptly changed our name after an acquisition, and I let the Bds people have our old domain for nothing when they inquired if we were done with it. > On Feb 8, 2020, at 4:11 PM, Dave Horsfall wrote: > > On Fri, 7 Feb 2020, Richard Salz wrote: > >> BDS C stood for Brain-Damaged Software [...] > > Yes, I've heard it called that :-) It sure was... > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Feb 8 14:19:25 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 8 Feb 2020 15:19:25 +1100 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: <2AA1D51F-A135-442F-A6FE-F5000452A648@ronnatalie.com> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> <2AA1D51F-A135-442F-A6FE-F5000452A648@ronnatalie.com> Message-ID: Not quite. It was a question I asked him, while Brian Kernighan and I were writing the Unix Programming Environment. His actual response was pithier (as one would expect): "I'd spell creat with an 'e'". -rob On Sat, Feb 8, 2020 at 2:33 PM Ronald Natalie wrote: > It has been F-Suck since we first got a copy. > > > My favorite UNIX quote was Ken Thompson (I hope I’m getting this right > Ken), when asked if he could do it over again, if he’d change anything. > He said he’d put an “e” on the end of creat. > > I’ve always pronounced it CREE-AT. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Feb 8 17:36:19 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 8 Feb 2020 17:36:19 +1000 Subject: [TUHS] Idea: a regular video chat Message-ID: <20200208073619.GC23759@minnie.tuhs.org> [x-posting to COFF] Idea: anybody interested in a regular video chat? I was thinking of one that progresses(*) through three different timezones (Asia/Aus/NZ, then the Americas, then Europe/Africa) so that everybody should be able to get to two of the three timezones. (* like a progressive dinner) 30-60 minutes each one, general old computing. Perhaps a guest speaker now and then with a short presentation. Perhaps a theme now and then. Perhaps just chew the fat, shoot the breeze as well. Platform: Zoom or I'd be happy to set up a private Jitsi instance. Something else? How often: perhaps weekly or fortnightly through the three timezones, so it would cycle back every three or six weeks. Comments, suggestions?! Cheers, Warren From imp at bsdimp.com Sun Feb 9 01:15:34 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 8 Feb 2020 08:15:34 -0700 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: On Fri, Feb 7, 2020 at 4:58 PM Rob Pike wrote: > Very nice talk with lots of good background. It made me think of the boxes > of DECTapes we had under the Unix room floor, and what we might have lost. > (Volunteers did manage to recover a couple of them, but time was short). > That makes me sad... :( It seems weird: in the Unix room were also all the binders of PDP-7 code that we've retyped in. I wonder if that was considered the archive for early unix, and that may be why we don't have enough early unix artifacts before the 5th edition? I know it was a bit of a rolling release, but I would have thought that ken or dmr would have made archival copies of the system around 'manual edition day' given all the other artifacts they saved. > PWB inaccuracy: The talk said that tools like grep and sed came from PWB, > but that's not true. They were original, as I'm sure Warner knows; he just > misspoke. > Yes. I got confused. In the talk the organizers flashed the time signs too early so I got nervous and rushed through some bits (it didn't help that this was the largest room I've spoken to and it was in the 'lunch coma' spot so some people fell asleep). I also never have a script for the talks, just a good understanding of the material and a rough list of points I'd like to make... And at the last minute I thought it would be better to characterize all the v4-based systems as the early forks and de-emphasize that SCCS Unix -> CB Unix was the first fork, so I thought I made that point a little more awkwardly than I would have liked. > Slightly more important: PWB also did not introduce the idea of the shell > (neither did Unix, for that matter), although there was a distinct shell > for that system that included the legendary pump operator, later superseded > by here documents. > Yes. I'd only mean that pwb enabled people to start writing real, non-trivial shell scripts. There's other scripts in the tree prior to Bourne Shell... There's several 'runit' scripts that look to build things pre-make. There's also sources to 'goto.c' which implemented 'goto label' by rewinding stdin until it finds the label then exiting (I presume the older shell would then start reading again from stdin). Or maybe I've totally missed the point of s1/goto.c... there's no comments in it. It is a bit of a stretch, though, you're right. > The flow from PWB back to the main research line was a trickle at best. We > had bad NIH in 1127. > That matches other sources I've seen: bug fixes flowed into research relatively easily. Performance fixes sometimes (though often not). Some drivers did. And only the occasional program. It's my belief that this slow level of flow is why AT&T shifted from the Research line to the Unix/TS line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and roped other internal lines into Unix/TS 4.0 and/or System V. I also now wonder if we got the Bourne Shell because of NIH or because there was some clear technical defect in pwbsh that Steve Bourne was correcting... There were no env vars before V7, and I haven't looked at the pwb sh to see how that issue was handled. I'll have to also include the 'pump' operator in future talks. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 9 01:41:03 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 8 Feb 2020 07:41:03 -0800 Subject: [TUHS] [COFF] Idea: a regular video chat In-Reply-To: <20200208073619.GC23759@minnie.tuhs.org> References: <20200208073619.GC23759@minnie.tuhs.org> Message-ID: Possibly - signal works really well and has few if any issues security/privacy/ownership issues. Clem On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey wrote: > [x-posting to COFF] > > Idea: anybody interested in a regular video chat? I was thinking of > one that progresses(*) through three different timezones (Asia/Aus/NZ, > then the Americas, then Europe/Africa) so that everybody should be > able to get to two of the three timezones. > > (* like a progressive dinner) > > 30-60 minutes each one, general old computing. Perhaps a guest speaker > now and then with a short presentation. Perhaps a theme now and then. > Perhaps just chew the fat, shoot the breeze as well. > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > Something else? > > How often: perhaps weekly or fortnightly through the three timezones, > so it would cycle back every three or six weeks. > > Comments, suggestions?! > > Cheers, Warren > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Sun Feb 9 02:06:49 2020 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sat, 8 Feb 2020 16:06:49 +0000 Subject: [TUHS] [COFF] Idea: a regular video chat In-Reply-To: References: <20200208073619.GC23759@minnie.tuhs.org> Message-ID: <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> On 08/02/2020 15:41, Clem Cole wrote: > Possibly -  signal works really well and has few if any issues > security/privacy/ownership issues. I think it's a WONDERFUL idea!! I don't mind what multimedia and video converencing technology we use. (Obviously it must meet fundmental technical requirements.) The point that Clem makes about "security/privacy/ownership issues" is important. Now could be a good time for one to open the discussion about their expectations. Andrew > On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey > wrote: > > [x-posting to COFF] > > Idea: anybody interested in a regular video chat? I was thinking of > one that progresses(*) through three different timezones (Asia/Aus/NZ, > then the Americas, then Europe/Africa) so that everybody should be > able to get to two of the three timezones. > >  (* like a progressive dinner) > > 30-60 minutes each one, general old computing. Perhaps a guest speaker > now and then with a short presentation. Perhaps a theme now and then. > Perhaps just chew the fat, shoot the breeze as well. > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > Something else? > > How often: perhaps weekly or fortnightly through the three timezones, > so it would cycle back every three or six weeks. > > Comments, suggestions?! > > Cheers, Warren > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > From ralph at inputplus.co.uk Sun Feb 9 03:18:37 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 08 Feb 2020 17:18:37 +0000 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <20200208171837.15CA62215C@orac.inputplus.co.uk> Hi, Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run > very differently, with fewer or at least lesser problems, if they were > treated as a single system rather than as a bunch of single-user > computers ssh'ed together. This reminds me of Western Digital's recent OmniXtend. It takes a programmable Ethernet switch and changes the protocol: Ethernet becomes OmniXtend. It's a cache-coherency protocol the allows CPUs, custom ASICs, FPGAs, GPUS, ML accelerators, ... to each hang off an 802.3 PHY and share one memory pool. https://blog.westerndigital.com/omnixtend-fabric-innovation-with-risc-v/ It might be a step towards a room of racks being marshalled as a single computer. -- Cheers, Ralph. From coppero1237 at gmail.com Sun Feb 9 03:50:40 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Sat, 8 Feb 2020 19:50:40 +0200 Subject: [TUHS] [COFF] Idea: a regular video chat In-Reply-To: <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> References: <20200208073619.GC23759@minnie.tuhs.org> <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> Message-ID: Very cool, would love it! Tyler On Sat, Feb 8, 2020 at 6:07 PM U'll Be King of the Stars < ullbeking at andrewnesbit.org> wrote: > On 08/02/2020 15:41, Clem Cole wrote: > > Possibly - signal works really well and has few if any issues > > security/privacy/ownership issues. > > I think it's a WONDERFUL idea!! > > I don't mind what multimedia and video converencing technology we use. > (Obviously it must meet fundmental technical requirements.) > > The point that Clem makes about "security/privacy/ownership issues" is > important. Now could be a good time for one to open the discussion > about their expectations. > > Andrew > > > > On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey > > wrote: > > > > [x-posting to COFF] > > > > Idea: anybody interested in a regular video chat? I was thinking of > > one that progresses(*) through three different timezones > (Asia/Aus/NZ, > > then the Americas, then Europe/Africa) so that everybody should be > > able to get to two of the three timezones. > > > > (* like a progressive dinner) > > > > 30-60 minutes each one, general old computing. Perhaps a guest > speaker > > now and then with a short presentation. Perhaps a theme now and then. > > Perhaps just chew the fat, shoot the breeze as well. > > > > Platform: Zoom or I'd be happy to set up a private Jitsi instance. > > Something else? > > > > How often: perhaps weekly or fortnightly through the three timezones, > > so it would cycle back every three or six weeks. > > > > Comments, suggestions?! > > > > Cheers, Warren > > _______________________________________________ > > COFF mailing list > > COFF at minnie.tuhs.org > > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Feb 9 04:59:42 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 8 Feb 2020 13:59:42 -0500 (EST) Subject: [TUHS] UNIBUS issues (Was: Spacewar at Bell Labs) Message-ID: <20200208185942.AD27118C0EB@mercury.lcs.mit.edu> > From: Dave Horsfall > [ Getting into COFF territory, I think ] I'm sending this reply to TUHS since the message I'm replying to has some errors, and I'd like for the corrections to be in the record close by. > On Thu, 30 Jan 2020, Clem Cole wrote: >> They way they tried to control it was to license the bus interface chips >> (made privately by Western Digital for them IIRC but were not available >> on the open market). Although DEC did have some custom chips for QBUS interfacing, they didn't always use them (below). And for the UNIBUS, the chips were always, AFAIK, open market (and the earliest ones may have predated the UNIBUS). E.g. the M105 Address Selector, a single-width FLIP CHIP, used in the earliest PDP-11's when devices such as the RK11-C, RP11 and TM11 were made out of a mass of small FLIP CHIPS, used SP380A's for its bus receivers and 8881's for transmitters. On the QBUS, the KDF11-A and KDJ11-A CPU cards used AMD 2908's as bus transceivers, even though DEC had its own custom chips. The KDF11-A also used DS8640's and DS8641's (transmitters and receivers), and also an 8881! (The UNIBUS and QBUS were effectively identical at the analog level, which is why a chip that historical was still in use.) >> If I recall it was the analog characteristics that were tricky with >> something like the BUS acquisition for DMA and Memory timing, but I >> admit I've forgotten the details. One _possibility_ for what he was talking about was that it took DEC a while to get a race/metastability issue with daisy-chained bus grant lines under control. (The issue is explained in some detail here: https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS and linked pages.) This can been seen in the myriad of etch revisions for the M782 and related 'bus grant' FLIP CHIPs: https://gunkies.org/wiki/M782_Interrupt_Control By comparison, the M105 only had 3 through it's whole life! It wasn't until the M7821 etch D revision, which came out in 1977, almost a decade after the first PDP-11's appeared, that they seemed to have absorbed that the only 'solution' to the race/metastability issue involved adding delays. In all fairness, the entire field didn't really appreciate the metastability issue until the LINC guys at WUSTL did a big investigation of it, and then started a big campaign to educate everyone about it - it wasn't DEC being particularly clueless. > Hey, if the DEC marketoids didn't want 3rd-party UNIBUS implementations > then why was it published? Well, exactly - but it's useful to remember the differening situation for DEC from 1970 (first PDP-11's) and later. In 1970 DEC was mostly selling to scientists/engineers, who wanted to hook up to some lab equipment they'd built, and OEM's, who often wanted to use a mini to control some value-added gear of their own devising. An open bus was really necessary for those markets. Which is why the 1970 PDP-11/20 manual goes into a lot of detail on how to interface to the PDP-11's UNIBUS. Later, of course, they were in a different business model. Noel From robpike at gmail.com Sun Feb 9 07:50:47 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 08:50:47 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: > > > Yes. I'd only mean that pwb enabled people to start writing real, > non-trivial shell scripts. There's other scripts in the tree prior to > Bourne Shell... There's several 'runit' scripts that look to build things > pre-make. There's also sources to 'goto.c' which implemented 'goto label' > by rewinding stdin until it finds the label then exiting (I presume the > older shell would then start reading again from stdin). Or maybe I've > totally missed the point of s1/goto.c... there's no comments in it. It is a > bit of a stretch, though, you're right. > That's how goto worked, yes. The flow from PWB back to the main research line was a trickle at best. We >> had bad NIH in 1127. >> > > That matches other sources I've seen: bug fixes flowed into research > relatively easily. Performance fixes sometimes (though often not). Some > drivers did. And only the occasional program. It's my belief that this slow > level of flow is why AT&T shifted from the Research line to the Unix/TS > line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and > roped other internal lines into Unix/TS 4.0 and/or System V. > I think the SysV/Research split is just another variant of NIH and separate organizations. The development folks did what they did because it helped them (or perhaps just to have fun?). Features in CB Unix bothered us (like the way init worked) and although we were pressured to take them, we resisted. USG was more accommodating. They (USG, Unix Support Group) were just that: a support group, and they were under immense pressure from their users in the Bell System to add features. There was outright mockery from us at how complex stty became, and then the ultimate insult arrived, ioctl. So System V was theirs, managed by them, owned by them. Occasionally we'd go to meetings there to try to convince them to do something differently. I remember a meeting where I tried to talk them out of some truly awful shared memory or IPC thing, but the details are hazy. I'm sure they ignored me anyway; in general they didn't listen to us unless their users were asking for something we had. > I also now wonder if we got the Bourne Shell because of NIH or because > there was some clear technical defect in pwbsh that Steve Bourne was > correcting... There were no env vars before V7, and I haven't looked at the > pwb sh to see how that issue was handled. I'll have to also include the > 'pump' operator in future talks. > Mashey's shell was better than the v6 shell, no question, but it was still pretty clunky and undisciplined. If I remember right, it was a hacked up v6 shell, but I'm not sure. Steve Bourne, who understands formal languages and was (clearly!) a fan of Algol 68, decided a more structured approach was necessary. People malign the look of the code, but his research shell was lovely. For v8 I ripped the IF ELIF macros out; they were just sugar I could scrape off. I put in shell functions, which Steve had wanted to do anyway, made them exportable (fought for that hard at a POSIX meeting, with Ken) and did some cleanups to the printing etc. so it worked well when you cut and paste from the terminal. All that was easy to do because the code was so clean. I learned a lot working on that program. The parser is a jewel. I still think it's a great piece of code, and I miss the v8 shell every day. The GNU "Bourne again" shell is missing all that stuff I did. Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't portable, and I suspect the code will never run on a modern OS. Tom Duff's rc was done as a reaction to the shell being, despite its other glories, still a macro language. But that's another story. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Feb 9 08:29:26 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 17:29:26 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> On 2/8/20 4:50 PM, Rob Pike wrote: > The GNU "Bourne > again" shell is missing all that stuff I did. Like what, for instance? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From rich.salz at gmail.com Sun Feb 9 08:31:39 2020 From: rich.salz at gmail.com (Richard Salz) Date: Sat, 8 Feb 2020 17:31:39 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: > > Tom Duff's rc was done as a reaction to the shell being, despite its > other glories, still a macro language. But that's another story. > As a user of Byron's clone (it's been my login for ever), I would like to hear that story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 9 08:54:44 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 09:54:44 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: Like exportable functions and output that's valid input, so it works well with an editable typescript. -rob On Sun, Feb 9, 2020 at 9:29 AM Chet Ramey wrote: > On 2/8/20 4:50 PM, Rob Pike wrote: > > The GNU "Bourne > > again" shell is missing all that stuff I did. > > Like what, for instance? > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Feb 9 09:02:28 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 18:02:28 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: On 2/8/20 5:54 PM, Rob Pike wrote: > Like exportable functions and output that's valid input, so it works well > with an editable typescript. Bash has both of those things. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From robpike at gmail.com Sun Feb 9 09:11:06 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 10:11:06 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: Not for me it doesn't. % bash bash-3.2$ function f() { echo hi } bash-3.2$ export f bash-3.2$ bash bash-3.2$ f bash-3.2$ I added the 'builtin' command, which did leave the labs. But I added it as a way for the "whatis" command to show a builtin, as well as allowing a way to guarantee you get the builtin on execution. How do I get bash to print the function as (shell) source code, so I could edit it and play with it again? It was the synergy of all this stuff connected seamlessly that made it so compelling. -rob On Sun, Feb 9, 2020 at 10:02 AM Chet Ramey wrote: > On 2/8/20 5:54 PM, Rob Pike wrote: > > Like exportable functions and output that's valid input, so it works well > > with an editable typescript. > > Bash has both of those things. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 9 09:13:27 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 10:13:27 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: Here is rc, which absorbed most of that behavior from the v8 shell: % rc % fn f { echo hi } % whatis f fn f {echo hi} % whatis path path=(. /Users/r/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/go/bin /Applications/Keybase.app/Contents/SharedSupport/bin /usr/local/plan9/bin) % rc % # subshell % f hi % On Sun, Feb 9, 2020 at 10:11 AM Rob Pike wrote: > Not for me it doesn't. > > % bash > > bash-3.2$ function f() { > > echo hi > > } > > bash-3.2$ export f > > bash-3.2$ bash > > bash-3.2$ f > > bash-3.2$ > > > I added the 'builtin' command, which did leave the labs. But I added it as > a way for the "whatis" command to show a builtin, as well as allowing a way > to guarantee you get the builtin on execution. > > > How do I get bash to print the function as (shell) source code, so I could > edit it and play with it again? It was the synergy of all this stuff > connected seamlessly that made it so compelling. > > > -rob > > > > On Sun, Feb 9, 2020 at 10:02 AM Chet Ramey wrote: > >> On 2/8/20 5:54 PM, Rob Pike wrote: >> > Like exportable functions and output that's valid input, so it works >> well >> > with an editable typescript. >> >> Bash has both of those things. >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khm at sciops.net Sun Feb 9 09:21:36 2020 From: khm at sciops.net (Kurt H Maier) Date: Sat, 8 Feb 2020 15:21:36 -0800 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: <20200208232136.GA21706@wopr> On Sun, Feb 09, 2020 at 10:11:06AM +1100, Rob Pike wrote: > > bash-3.2$ export f > You need export -f f here. > > How do I get bash to print the function as (shell) source code, so I > could edit it and play with it again? $ type f f is a function f () { echo hi } I don't like bash, but it has every feature ever thought of. Maybe I could better phrase that: I don't like bash, because it has every feature ever thought of. khm From chet.ramey at case.edu Sun Feb 9 09:26:51 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 18:26:51 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> Message-ID: <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> On 2/8/20 6:11 PM, Rob Pike wrote: > Not for me it doesn't. > > % bash > > bash-3.2$ function f() { > >     echo hi > >     } > > bash-3.2$ export f > bash-3.2$ bash > bash-3.2$ f > bash-3.2$ jenna(1)$ echo $BASH_VERSION 5.0.11(6)-release jenna(1)$ f() { echo f; } jenna(1)$ export -f f jenna(1)$ bash jenna(2)$ f f jenna(2)$ It works the same in Mac OS X's bash-3.2. > I added the 'builtin' command, which did leave the labs. But I added it as > a way for the "whatis" command to show a builtin, as well as allowing a way > to guarantee you get the builtin on execution. Bash uses `type' to tell whether something is a builtin. How does `builtin' say whether or not a command is builtin? The output with no arguments? > How do I get bash to print the function as (shell) source code, so I could > edit it and play with it again? It was the synergy of all this stuff > connected seamlessly that made it so compelling. > jenna(2)$ declare -pf f f () { echo f } declare -fx f If it weren't exported, you wouldn't get the `declare' command appended there. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From robpike at gmail.com Sun Feb 9 09:26:45 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 10:26:45 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: <20200208232136.GA21706@wopr> References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <20200208232136.GA21706@wopr> Message-ID: That 'f is a function' header weakens the idea substantially. Anyway, it's good to see these ideas picked up, if late and imperfectly. My work on the v8 shell was a long time ago. -rob On Sun, Feb 9, 2020 at 10:21 AM Kurt H Maier wrote: > On Sun, Feb 09, 2020 at 10:11:06AM +1100, Rob Pike wrote: > > > > bash-3.2$ export f > > > > You need export -f f here. > > > > > How do I get bash to print the function as (shell) source code, so I > > could edit it and play with it again? > > $ type f > f is a function > f () > { > echo hi > } > > > I don't like bash, but it has every feature ever thought of. Maybe I > could better phrase that: I don't like bash, because it has every > feature ever thought of. > > khm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Feb 9 09:28:28 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 18:28:28 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <20200208232136.GA21706@wopr> Message-ID: <8b299456-5807-f7f3-0d20-7900cb32f64a@case.edu> On 2/8/20 6:26 PM, Rob Pike wrote: > That 'f is a function' header weakens the idea substantially. Use `declare -fp f' to get what you want. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From robpike at gmail.com Sun Feb 9 09:29:02 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 10:29:02 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> Message-ID: % rc % whatis cd builtin cd % It's much simpler this way. The output is the executable input, free of decoration and ready to use. In today's Unix (I use the term loosely) world, the phrase "free of decoration" is apostasy. -rob On Sun, Feb 9, 2020 at 10:26 AM Chet Ramey wrote: > On 2/8/20 6:11 PM, Rob Pike wrote: > > Not for me it doesn't. > > > > % bash > > > > bash-3.2$ function f() { > > > > echo hi > > > > } > > > > bash-3.2$ export f > > bash-3.2$ bash > > bash-3.2$ f > > bash-3.2$ > > jenna(1)$ echo $BASH_VERSION > 5.0.11(6)-release > jenna(1)$ f() { echo f; } > jenna(1)$ export -f f > jenna(1)$ bash > jenna(2)$ f > f > jenna(2)$ > > It works the same in Mac OS X's bash-3.2. > > > I added the 'builtin' command, which did leave the labs. But I added it > as > > a way for the "whatis" command to show a builtin, as well as allowing a > way > > to guarantee you get the builtin on execution. > > Bash uses `type' to tell whether something is a builtin. How does `builtin' > say whether or not a command is builtin? The output with no arguments? > > > How do I get bash to print the function as (shell) source code, so I > could > > edit it and play with it again? It was the synergy of all this stuff > > connected seamlessly that made it so compelling. > > > > jenna(2)$ declare -pf f > f () > { > echo f > } > declare -fx f > > If it weren't exported, you wouldn't get the `declare' command appended > there. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Feb 9 09:35:18 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 8 Feb 2020 16:35:18 -0700 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> Message-ID: On Sat, Feb 8, 2020, 4:29 PM Rob Pike wrote: > % rc > > % whatis cd > > builtin cd > > % > > > It's much simpler this way. The output is the executable input, free of > decoration and ready to use. > > > In today's Unix (I use the term loosely) world, the phrase "free of > decoration" is apostasy. > A number of utilities have a special flag to use in shell scripts to remove the decorations. I both like and loath this design pattern. Warner -rob > > > > On Sun, Feb 9, 2020 at 10:26 AM Chet Ramey wrote: > >> On 2/8/20 6:11 PM, Rob Pike wrote: >> > Not for me it doesn't. >> > >> > % bash >> > >> > bash-3.2$ function f() { >> > >> > echo hi >> > >> > } >> > >> > bash-3.2$ export f >> > bash-3.2$ bash >> > bash-3.2$ f >> > bash-3.2$ >> >> jenna(1)$ echo $BASH_VERSION >> 5.0.11(6)-release >> jenna(1)$ f() { echo f; } >> jenna(1)$ export -f f >> jenna(1)$ bash >> jenna(2)$ f >> f >> jenna(2)$ >> >> It works the same in Mac OS X's bash-3.2. >> >> > I added the 'builtin' command, which did leave the labs. But I added it >> as >> > a way for the "whatis" command to show a builtin, as well as allowing a >> way >> > to guarantee you get the builtin on execution. >> >> Bash uses `type' to tell whether something is a builtin. How does >> `builtin' >> say whether or not a command is builtin? The output with no arguments? >> >> > How do I get bash to print the function as (shell) source code, so I >> could >> > edit it and play with it again? It was the synergy of all this stuff >> > connected seamlessly that made it so compelling. >> > >> >> jenna(2)$ declare -pf f >> f () >> { >> echo f >> } >> declare -fx f >> >> If it weren't exported, you wouldn't get the `declare' command appended >> there. >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Feb 9 09:36:50 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 18:36:50 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> Message-ID: <20da6a39-c07b-fe42-c9fb-43bf3c54d179@case.edu> On 2/8/20 6:29 PM, Rob Pike wrote: > % rc > > % whatis cd > > builtin cd > > %  > > > It's much simpler this way. The output is the executable input, free of > decoration and ready to use. OK. `whatis' is a non-starter as a builtin, but bash ships with an example `whatis' shell function that does this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From robpike at gmail.com Sun Feb 9 09:54:16 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 9 Feb 2020 10:54:16 +1100 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: <20da6a39-c07b-fe42-c9fb-43bf3c54d179@case.edu> References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> <20da6a39-c07b-fe42-c9fb-43bf3c54d179@case.edu> Message-ID: Well, "whatis" was a fine starter in 1983. I'm not saying anything should change. This is a history list. -rob On Sun, Feb 9, 2020 at 10:36 AM Chet Ramey wrote: > On 2/8/20 6:29 PM, Rob Pike wrote: > > % rc > > > > % whatis cd > > > > builtin cd > > > > % > > > > > > It's much simpler this way. The output is the executable input, free of > > decoration and ready to use. > > OK. `whatis' is a non-starter as a builtin, but bash ships with an example > `whatis' shell function that does this. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Feb 9 10:11:40 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 8 Feb 2020 19:11:40 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> <20da6a39-c07b-fe42-c9fb-43bf3c54d179@case.edu> Message-ID: On 2/8/20 6:54 PM, Rob Pike wrote: > Well, "whatis" was a fine starter in 1983. At which point the name had been in use for something else for four years. The name is the problem, not the function. > > I'm not saying anything should change. This is a history list. Sure. The question is whether you can get what you want today. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From lm at mcvoy.com Sun Feb 9 10:19:30 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 8 Feb 2020 16:19:30 -0800 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: <46c41c18-5b44-14e5-1f0a-9272866993da@case.edu> <62548c3e-4692-c2d3-f06f-745353490b95@case.edu> Message-ID: <20200209001930.GF21264@mcvoy.com> > In today's Unix (I use the term loosely) world, the phrase "free of > decoration" is apostasy. Yeah, it's annoying. When I was building my last big system (BitKeeper) I "solved" the problem by having -s (silent) as an option to pretty much every command that produced output. In terms of controlling output, we took the SCCS keywords on steriods, we evolved it to sort of a little programming language. I was told that "bk changes" (think git log sort of) couldn't be taught to produce JSON output. Oh, it can't huh. Below is the input that tells it to do just that. It's sort of awk like, control words are $word, "quoted stuff is printed, :THING: means print whatever THING is, variables are $0 .. $9 and eval to "" or 0 in numerical context. The main body script, much like awk calls it on each line, the script is called on each commit (and it optionally recurses into files as well). I'm pretty proud of it, it works really, really well. $ cat `bk bin`/dspec-changes-json # dspec-v2 # The default dspec used by 'bk changes -json' $begin { "[\n" } $if (:CHANGESET: && !:COMPONENT_V:) { $if($0 -eq 1) { "\},\n" } "\{\n" " \"key\": \":MD5KEY:\",\n" " \"user\": \":USER:\",\n" " \"host\": \":HOST:\",\n" " \"date\": \":Dy:-:Dm:-:Dd:T:T::TZ:\",\n" " \"serial\": :DS:,\n" " \"comments\": \"" $each(:C:){$json{(:C:)}\\n} "\",\n" $if (:TAGS:) { " \"tags\": [ " $each(:TAGS:){:JOIN:"\""(:TAGS:)"\""} " ],\n" } " \"parents\": [ " $if(:PARENT:){"\"" :MD5KEY|PARENT: "\""} $if(:PARENT: && :MPARENT:){," "} $if(:MPARENT:){"\"" :MD5KEY|MPARENT: "\""} " ]\n" ${0=1} # we need to close off the changeset } $end { $if($0 -eq 1) { "\}\n" } "]\n" } From wkt at tuhs.org Sun Feb 9 10:39:53 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 10:39:53 +1000 Subject: [TUHS] Discord channels for COFF/TUHS Message-ID: <20200209003953.GA7353@minnie.tuhs.org> All, Silent700 has graciously set up channels underneath the ClassicCMP Discord server for COFF and TUHS: COFF: https://discordapp.com/channels/642419539946110997/675860587355308049 TUHS: https://discordapp.com/channels/642419539946110997/675860622738718775 I thought it made sense to have the channels on a server where there was already old computer people (old for either or both :-). Cheers, Warren From david at kdbarto.org Sun Feb 9 10:35:01 2020 From: david at kdbarto.org (David Barto) Date: Sat, 8 Feb 2020 16:35:01 -0800 Subject: [TUHS] Oral history interview with Doug McIlroy In-Reply-To: <4B4A388452D2A7418879B110A352A8F401888068A7@EX-MB1.hq.computerhistory.org> References: <4B4A388452D2A7418879B110A352A8F401888068A7@EX-MB1.hq.computerhistory.org> Message-ID: <448EAB58-BA80-4600-A150-23E5DD1E8FAE@kdbarto.org> David, thanks for the link to this 2 part oral history (transcribed). It was a wonderful read through Doug’s history as well as the history of how Unix got started and some of the interesting points where Doug and others all made changes that lead to what became that thing called Unix that all of us know a love. David > On Feb 3, 2020, at 1:01 PM, David C. Brock wrote: > > With Doug’s permission, I’d like to bring the group’s attention to a recent oral history with him by the Computer History Museum. > > You can find the records for the two interviews here, and in them the links to the PDF transcripts: > > https://www.computerhistory.org/collections/oralhistories/?s=mcilroy > > As I am sure you can imagine, it was a great pleasure to interview Doug. I learned a tremendous amount. > > Best wishes, > > David > > .............. > David C. Brock > Director and Curator > Software History Center > Computer History Museum > computerhistory.org/softwarehistory > Email: dbrock at computerhistory.org > Twitter: @dcbrock > Skype: dcbrock > 1401 N. Shoreline Blvd. > Mountain View, CA 94943 > (650) 810-1010 main > (650) 810-1886 direct > Pronouns: he, him, his > > From wkt at tuhs.org Sun Feb 9 10:48:54 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 10:48:54 +1000 Subject: [TUHS] Also, a video service Message-ID: <20200209004854.GB7353@minnie.tuhs.org> All, I've also set this up to try out for the video chats: https://meet.tuhs.org/COFF Password to join is "unix" at the moment. I just want to test it to confirm that it works; I'll be heading out the door to go to the shops soon. Cheers, Warren From wkt at tuhs.org Sun Feb 9 12:02:46 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 9 Feb 2020 12:02:46 +1000 Subject: [TUHS] Also, a video service In-Reply-To: <20200209004854.GB7353@minnie.tuhs.org> References: <20200209004854.GB7353@minnie.tuhs.org> Message-ID: <20200209020246.GA19979@minnie.tuhs.org> On Sun, Feb 09, 2020 at 10:48:54AM +1000, Warren Toomey wrote: > All, I've also set this up to try out for the video chats: > https://meet.tuhs.org/COFF > I just want to test it to confirm that it works. It works, thanks to the four or five who popped in to test it. I'm thinking of a weekly rotation through these timezones: UTC Brisbane New Jersey Week 1: 8am 6pm 3am Week 2: 1pm 11pm 8am Week 3: 10pm 8am 5pm We'd need a volunteer from each timezone to start up the channel and to (try to) keep some order. Any takers? Cheers, Warren From jack.adams at ieee.org Sun Feb 9 23:24:41 2020 From: jack.adams at ieee.org (John Adams) Date: Sun, 9 Feb 2020 08:24:41 -0500 Subject: [TUHS] [COFF] Idea: a regular video chat In-Reply-To: References: <20200208073619.GC23759@minnie.tuhs.org> <2d62a168-fb58-aae3-7641-082d26c16ece@andrewnesbit.org> Message-ID: Excellent idea, can't wait for the first session! *John "Jack" Lossin Adams* *LinkedIn CV * *We live in a society exquisitely dependent on science and technology, in which hardly * *anyone knows anything about science and technology. - Carl Sagan* *Only two things are infinite, the universe and human stupidity, * *and I'm not sure about the former. - Albert Einstein* On Sat, Feb 8, 2020 at 12:51 PM Tyler Adams wrote: > Very cool, would love it! > Tyler > > > On Sat, Feb 8, 2020 at 6:07 PM U'll Be King of the Stars < > ullbeking at andrewnesbit.org> wrote: > >> On 08/02/2020 15:41, Clem Cole wrote: >> > Possibly - signal works really well and has few if any issues >> > security/privacy/ownership issues. >> >> I think it's a WONDERFUL idea!! >> >> I don't mind what multimedia and video converencing technology we use. >> (Obviously it must meet fundmental technical requirements.) >> >> The point that Clem makes about "security/privacy/ownership issues" is >> important. Now could be a good time for one to open the discussion >> about their expectations. >> >> Andrew >> >> >> > On Fri, Feb 7, 2020 at 11:36 PM Warren Toomey > > > wrote: >> > >> > [x-posting to COFF] >> > >> > Idea: anybody interested in a regular video chat? I was thinking of >> > one that progresses(*) through three different timezones >> (Asia/Aus/NZ, >> > then the Americas, then Europe/Africa) so that everybody should be >> > able to get to two of the three timezones. >> > >> > (* like a progressive dinner) >> > >> > 30-60 minutes each one, general old computing. Perhaps a guest >> speaker >> > now and then with a short presentation. Perhaps a theme now and >> then. >> > Perhaps just chew the fat, shoot the breeze as well. >> > >> > Platform: Zoom or I'd be happy to set up a private Jitsi instance. >> > Something else? >> > >> > How often: perhaps weekly or fortnightly through the three >> timezones, >> > so it would cycle back every three or six weeks. >> > >> > Comments, suggestions?! >> > >> > Cheers, Warren >> > _______________________________________________ >> > COFF mailing list >> > COFF at minnie.tuhs.org >> > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Feb 10 04:42:56 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 9 Feb 2020 10:42:56 -0800 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: <20200208171837.15CA62215C@orac.inputplus.co.uk> References: <20200208171837.15CA62215C@orac.inputplus.co.uk> Message-ID: <20200209184256.GD21264@mcvoy.com> On Sat, Feb 08, 2020 at 05:18:37PM +0000, Ralph Corderoy wrote: > Hi, > > Rob Pike wrote: > > I am convinced that large-scale modern compute centers would be run > > very differently, with fewer or at least lesser problems, if they were > > treated as a single system rather than as a bunch of single-user > > computers ssh'ed together. > > This reminds me of Western Digital's recent OmniXtend. It takes a > programmable Ethernet switch and changes the protocol: Ethernet becomes > OmniXtend. It's a cache-coherency protocol the allows CPUs, custom > ASICs, FPGAs, GPUS, ML accelerators, ... to each hang off an 802.3 PHY > and share one memory pool. > https://blog.westerndigital.com/omnixtend-fabric-innovation-with-risc-v/ > > It might be a step towards a room of racks being marshalled as a single > computer. Or it might be a giant step backwards in terms of memory latency. From wkt at tuhs.org Mon Feb 10 06:17:09 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 10 Feb 2020 06:17:09 +1000 Subject: [TUHS] [COFF] Discord channels for COFF/TUHS In-Reply-To: <20200209003953.GA7353@minnie.tuhs.org> References: <20200209003953.GA7353@minnie.tuhs.org> Message-ID: <20200209201709.GA23015@minnie.tuhs.org> On Sun, Feb 09, 2020 at 10:39:53AM +1000, Warren Toomey wrote: > All, Silent700 has graciously set up channels underneath the ClassicCMP > Discord server for COFF and TUHS: I got the invites wrong. Try these ones: COFF: https://discord.gg/qebJXw TUHS: https://discord.gg/BdmzZP Thanks to those who pointed this out. Cheers, Warren From grog at lemis.com Mon Feb 10 08:56:38 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 10 Feb 2020 09:56:38 +1100 Subject: [TUHS] [COFF] Also, a video service In-Reply-To: <20200209004854.GB7353@minnie.tuhs.org> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> Message-ID: <20200209225638.GG75158@eureka.lemis.com> On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: > All, I've also set this up to try out for the video chats: > https://meet.tuhs.org/COFF > Password to join is "unix" at the moment. > I just want to test it to confirm that it works; I'll be heading > out the door to go to the shops soon. Just tried it out. On FreeBSD I get a blank grey screen. I could only get something more on a Microsoft box, not quite what I'd want to do. Is there some trick? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From bakul at bitblocks.com Mon Feb 10 09:21:32 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 09 Feb 2020 15:21:32 -0800 Subject: [TUHS] [COFF] Also, a video service In-Reply-To: Your message of "Mon, 10 Feb 2020 09:56:38 +1100." <20200209225638.GG75158@eureka.lemis.com> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> Message-ID: <20200209232139.B85D0156E40E@mail.bitblocks.com> On Mon, 10 Feb 2020 09:56:38 +1100 Greg 'groggy' Lehey wrote: > On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: > > All, I've also set this up to try out for the video chats: > > https://meet.tuhs.org/COFF > > Password to join is "unix" at the moment. > > I just want to test it to confirm that it works; I'll be heading > > out the door to go to the shops soon. > > Just tried it out. On FreeBSD I get a blank grey screen. I could > only get something more on a Microsoft box, not quite what I'd want to > do. Is there some trick? I was able to connect from a MacBookPro. This seems to be Jitsi. There is a jitsi package for FreeBSD-11. Unfortunately /usr/ports/net-im/jitsi is broken (unfetchable). No idea if any of the linux downloads from jitsi.org would work. From wobblygong at gmail.com Mon Feb 10 13:35:44 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 10 Feb 2020 16:35:44 +1300 Subject: [TUHS] [COFF] Also, a video service In-Reply-To: <20200209232139.B85D0156E40E@mail.bitblocks.com> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> <20200209232139.B85D0156E40E@mail.bitblocks.com> Message-ID: Thanks, Bakul. I'm just now installing jitsi on one of my Linux boxen. Speaking of FreeBSD and MacOS, I'm sure the source code at https://download.jitsi.org/jitsi/src/ will compile on FreeBSD with a simple ./configure and make. Wesley Parish On 2/10/20, Bakul Shah wrote: > On Mon, 10 Feb 2020 09:56:38 +1100 Greg 'groggy' Lehey > wrote: >> On Sunday, 9 February 2020 at 10:48:54 +1000, Warren Toomey wrote: >> > All, I've also set this up to try out for the video chats: >> > https://meet.tuhs.org/COFF >> > Password to join is "unix" at the moment. >> > I just want to test it to confirm that it works; I'll be heading >> > out the door to go to the shops soon. >> >> Just tried it out. On FreeBSD I get a blank grey screen. I could >> only get something more on a Microsoft box, not quite what I'd want to >> do. Is there some trick? > > I was able to connect from a MacBookPro. This seems to be > Jitsi. There is a jitsi package for FreeBSD-11. Unfortunately > /usr/ports/net-im/jitsi is broken (unfetchable). No idea if > any of the linux downloads from jitsi.org would work. > From jason-tuhs at shalott.net Mon Feb 10 16:09:47 2020 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Sun, 9 Feb 2020 22:09:47 -0800 (PST) Subject: [TUHS] [COFF] Also, a video service In-Reply-To: <20200209225638.GG75158@eureka.lemis.com> References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> Message-ID: >> All, I've also set this up to try out for the video chats: >> https://meet.tuhs.org/COFF >> Password to join is "unix" at the moment. > Just tried it out. On FreeBSD I get a blank grey screen. I could > only get something more on a Microsoft box, not quite what I'd want to > do. Is there some trick? * Install /usr/ports/net-im/jitsi. (Comment out the BROKEN line from the Makefile and "make install" should work as usual; the source can actually be fetched just fine...) * kldload cuse * Run firefox and surf to that URL. After doing this, I surfed to that URL and was connected, with the video from my webcam displaying in the browser. hashbrown/home/jason-124575: uname -a FreeBSD hashbrown 12.1-STABLE FreeBSD 12.1-STABLE r357056 JKERN12 amd64 For what it's worth, the webcam identifies itself as vendor:product 0x046d:0x0825, which, according to https://wiki.freebsd.org/WebcamCompat is a Logitech C270 HD. I think I paid about $20 USD for it, five or so years ago. The quality is quite sufficient for video conferencing, and it works with webcamd, vlc, and all the other software that I typically run on my FreeBSD desktop. As always, YMMV... -Jason From dot at dotat.at Mon Feb 10 23:18:45 2020 From: dot at dotat.at (Tony Finch) Date: Mon, 10 Feb 2020 13:18:45 +0000 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: Rob Pike wrote: > > Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't > portable, and I suspect the code will never run on a modern OS. I heard that one of the first things that each of the various 68000 ports had to do was patch the shell to make its memory allocation less adventurous. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet: West 7 to severe gale 9, occasionally storm 10 at first. High or very high. Squally showers, thundery for a time. Moderate, occasionally poor. From crossd at gmail.com Tue Feb 11 01:05:55 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 10 Feb 2020 10:05:55 -0500 Subject: [TUHS] Warner's Early Unix Presentation In-Reply-To: References: Message-ID: On Sat, Feb 8, 2020 at 4:52 PM Rob Pike wrote: > [snip] I still think it's a great piece of code, and I miss the v8 shell > every day. [snip] > Unfortunately, Steve's memory allocation trick, mallocking on faults, > isn't portable, and I suspect the code will never run on a modern OS. Tom > Duff's rc was done as a reaction to the shell being, despite its other > glories, still a macro language. But that's another story. > Geoff Collyer wrote a nice paper about experiences porting the 9th Edition shell to SunOS 3 on the 68k some years ago. http://www.collyer.net/who/geoff/sh.tour.pdf There is a copy of source code on his personal web page: http://www.collyer.net/who/geoff/ I wonder if any of the 8th edition shell changes you mentioned survived in that code? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Feb 11 01:46:24 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 10 Feb 2020 08:46:24 -0700 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: Message-ID: <202002101546.01AFkOSc001266@freefriends.org> Dan Cross wrote: > Geoff Collyer wrote a nice paper about experiences porting the 9th Edition > shell to SunOS 3 on the 68k some years ago. > http://www.collyer.net/who/geoff/sh.tour.pdf > > There is a copy of source code on his personal web page: > http://www.collyer.net/who/geoff/ > > I wonder if any of the 8th edition shell changes you mentioned survived in > that code? It took less than 10 minutes to get it to compile under Linux. 'whatis' is there, although the pretty printing of function code leaves much to be desired. Lacking is both readline and job control. Arnold From paul.winalski at gmail.com Tue Feb 11 03:11:55 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 10 Feb 2020 12:11:55 -0500 Subject: [TUHS] keyboards and command names In-Reply-To: <8b706ef6-dbf0-27ba-c343-b693f4c5c8f3@kilonet.net> References: <4425E818-B9C3-4BFA-BD69-EA4A35D9772E@optusnet.com.au> <73524e91-0b05-e4b7-524b-1c7247d48846@gmail.com> <8b706ef6-dbf0-27ba-c343-b693f4c5c8f3@kilonet.net> Message-ID: On 2/5/20, Arthur Krewat wrote: > Have't seen mention of TOPS-10, or TOPS-20 for that matter... shortening > commands was a great time saver. Problem was, next time they added a > command, muscle memory had to relearn. > DEC's DCL (Digital Command Language) was used on TOPS-20 and VMS. It required that all commands be unique in the first three characters, and allowed abbreviation. -Paul W. From robpike at gmail.com Tue Feb 11 04:39:26 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 05:39:26 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002101546.01AFkOSc001266@freefriends.org> References: <202002101546.01AFkOSc001266@freefriends.org> Message-ID: Readline and job control were less compelling when you had multiple command windows of editable typescript, which we all had with the Blit. -rob On Tue, Feb 11, 2020 at 2:46 AM wrote: > Dan Cross wrote: > > > Geoff Collyer wrote a nice paper about experiences porting the 9th > Edition > > shell to SunOS 3 on the 68k some years ago. > > http://www.collyer.net/who/geoff/sh.tour.pdf > > > > There is a copy of source code on his personal web page: > > http://www.collyer.net/who/geoff/ > > > > I wonder if any of the 8th edition shell changes you mentioned survived > in > > that code? > > It took less than 10 minutes to get it to compile under Linux. 'whatis' > is there, although the pretty printing of function code leaves > much to be desired. > > Lacking is both readline and job control. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Feb 11 04:59:14 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 10 Feb 2020 10:59:14 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: Your message of "Tue, 11 Feb 2020 05:39:26 +1100." References: <202002101546.01AFkOSc001266@freefriends.org> Message-ID: <20200210185921.E6328156E40E@mail.bitblocks.com> On Tue, 11 Feb 2020 05:39:26 +1100 Rob Pike wrote: > > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. ^Z is still useful, to stop forward progress temporarily. Analogous to what ^S/^Q does for output stream. As for editable typescript, I like how Dyalog's APL console app works. You can edit any previous expression but when you run it, the original expression is restored and the edited expression appears on a new line. This way you can see the real history of what you did, as opposed to in acme or rio, for example, where the original content of edited lines in an rc shell window is lost. From aap at papnet.eu Tue Feb 11 05:58:49 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 10 Feb 2020 20:58:49 +0100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> Message-ID: <20200210195849.GA82734@indra.papnet.eu> On 11/02/20, Rob Pike wrote: > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. What i like is the autocorrect feature in v8: $ cd /usr/blot /usr/blit $ pwd /usr/blit aap From chet.ramey at case.edu Tue Feb 11 06:11:01 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 10 Feb 2020 15:11:01 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200210195849.GA82734@indra.papnet.eu> References: <202002101546.01AFkOSc001266@freefriends.org> <20200210195849.GA82734@indra.papnet.eu> Message-ID: <676c63a7-c382-54fe-472c-9538d00b1e7e@case.edu> On 2/10/20 2:58 PM, Angelo Papenhoff wrote: > On 11/02/20, Rob Pike wrote: >> Readline and job control were less compelling when you had multiple command >> windows of editable typescript, which we all had with the Blit. > > What i like is the autocorrect feature in v8: > > $ cd /usr/blot > /usr/blit > $ pwd > /usr/blit Maybe unsurprisingly, bash has that as well (the `cdspell' option). I picked up a fair amount from the v8/v9 shells. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From ggm at algebras.org Tue Feb 11 11:16:18 2020 From: ggm at algebras.org (George Michaelson) Date: Tue, 11 Feb 2020 11:16:18 +1000 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> <2AA1D51F-A135-442F-A6FE-F5000452A648@ronnatalie.com> Message-ID: I thought this was a Denis story not a Ken story. Its still a good story. Since you're one of the two people in the conversation, I think I can take it I'm wrong btw. (it used to get repeated at UUG, it was always good for a laugh) -G On Sat, Feb 8, 2020 at 2:19 PM Rob Pike wrote: > > Not quite. It was a question I asked him, while Brian Kernighan and I were writing the Unix Programming Environment. His actual response was pithier (as one would expect): "I'd spell creat with an 'e'". > > -rob > > > On Sat, Feb 8, 2020 at 2:33 PM Ronald Natalie wrote: >> >> It has been F-Suck since we first got a copy. >> >> >> My favorite UNIX quote was Ken Thompson (I hope I’m getting this right Ken), when asked if he could do it over again, if he’d change anything. >> He said he’d put an “e” on the end of creat. >> >> I’ve always pronounced it CREE-AT. >> >> >> From doug at cs.dartmouth.edu Tue Feb 11 13:32:58 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 10 Feb 2020 22:32:58 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Message-ID: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> > What i like is the autocorrect feature in v8: > > $ cd /usr/blot > /usr/blit > $ pwd > /usr/blit Here I am, editor of the v8 manual and unaware of the feature. We now know that silent correction is a terrible idea. Postel's principle: "be conservative in what you do, be liberal in what you accept from others" was doctrine in early HTML specs, and led to disastrous disagreement among browsers' interpretation of web pages. Sadly, the "principle" lives on despite its having been expunged from the HTML spec. Today's "langsec" movement grew out of bitter experience with malicious inputs exploiting "liberal" interpretation of nonconforming data. Today's NYT has an article about fake knockoffs of George Orwell for sale on Amazon. It cites an edition of "Animal Farm" apparently pirated by lowgrade OCR autocorrected and never proofread. One of the many gaffes is that every instance of "iv" beame ChapterIV, as in "prChapterIVacy". I didn't like some Lisp systems' DWIM (do what I mean) when I first heard about the feature, and I like it even less 40-some years on. I would probably have remonstrated with Rob had I realized the shell was doing it. Doug From lm at mcvoy.com Tue Feb 11 13:53:40 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 10 Feb 2020 19:53:40 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: <20200211035340.GA852@mcvoy.com> On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. I had the same thought, cd /some/place/I/want/to/remove $PWD is /some/place/I/want/dont/remove rm -rf ./* oops. > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. I think Jon had the right intentions. HTML is different than a command prompt. > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. Yep, agreed. There are places where that works and there are most definitely places where they do not. The shell should not guess. From wkt at tuhs.org Tue Feb 11 14:46:02 2020 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 11 Feb 2020 14:46:02 +1000 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: <20200211044602.GA13522@minnie.tuhs.org> On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > Doug I misread that as "what the shell was going on", which seems appropriate. Warren From usotsuki at buric.co Tue Feb 11 15:12:16 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 11 Feb 2020 00:12:16 -0500 (EST) Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211044602.GA13522@minnie.tuhs.org> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> <20200211044602.GA13522@minnie.tuhs.org> Message-ID: On Tue, 11 Feb 2020, Warren Toomey wrote: > On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote: >> years on. I would probably have remonstrated with Rob had I >> realized the shell was doing it. >> Doug > > I misread that as "what the shell was going on", which seems appropriate. > > Warren > Too much Ninja Turtles '03? -uso. From robpike at gmail.com Tue Feb 11 16:33:09 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 17:33:09 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: On Tue, Feb 11, 2020 at 2:34 PM Doug McIlroy wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > It was td, and there is an implementation of sorts in The Unix Programming Environment. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Feb 11 16:38:52 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 17:38:52 +1100 Subject: [TUHS] pronouncing *nix formulas In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> <20200204094018.661e76717f7f475e6cb53e75@sjmulder.nl> <20200204201453.ebeaabon26vbgfle@localhost.localdomain> <202002050845.0158jDOu024559@freefriends.org> <202002051705.015H5ZxY3211810@darkstar.fourwinds.com> <2AA1D51F-A135-442F-A6FE-F5000452A648@ronnatalie.com> Message-ID: See the bottom of page 204 of UPE. -rob On Tue, Feb 11, 2020 at 12:17 PM George Michaelson wrote: > I thought this was a Denis story not a Ken story. Its still a good > story. Since you're one of the two people in the conversation, I > think I can take it I'm wrong btw. > > (it used to get repeated at UUG, it was always good for a laugh) > > -G > > On Sat, Feb 8, 2020 at 2:19 PM Rob Pike wrote: > > > > Not quite. It was a question I asked him, while Brian Kernighan and I > were writing the Unix Programming Environment. His actual response was > pithier (as one would expect): "I'd spell creat with an 'e'". > > > > -rob > > > > > > On Sat, Feb 8, 2020 at 2:33 PM Ronald Natalie > wrote: > >> > >> It has been F-Suck since we first got a copy. > >> > >> > >> My favorite UNIX quote was Ken Thompson (I hope I’m getting this right > Ken), when asked if he could do it over again, if he’d change anything. > >> He said he’d put an “e” on the end of creat. > >> > >> I’ve always pronounced it CREE-AT. > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Feb 11 17:46:29 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Feb 2020 00:46:29 -0700 Subject: [TUHS] compiling v9sh Message-ID: <202002110746.01B7kTrT032157@freefriends.org> For anyone who's interested, here is what it took to compile Geoff Collyer's v9sh on Ubuntu 18.04. Arnold ---------------------------------- diff -ur v9sh/error.c v9sh-new/error.c --- v9sh/error.c 2017-07-29 11:45:07.000000000 +0300 +++ v9sh-new/error.c 2020-02-10 17:31:33.275920947 +0200 @@ -24,7 +24,7 @@ } if (per) { prs(colon); - prs(errno < 0 || errno >= sys_nerr? "Bad errno": sys_errlist[errno]); + prs(strerror(errno)); } newline(); exitsh(ERROR); diff -ur v9sh/pathserv.c v9sh-new/pathserv.c --- v9sh/pathserv.c 2017-07-29 12:06:25.000000000 +0300 +++ v9sh-new/pathserv.c 2020-02-10 17:29:43.666971083 +0200 @@ -30,7 +30,7 @@ { struct stat buf; - if (stat(name, &buf) == 0 && (buf.st_mode&S_IFMT) == S_IFREG && + if (stat(name, &buf) == 0 && S_ISREG(buf.st_mode) && access(name, EXECUTE) == 0) return 0; else diff -ur v9sh/xec.c v9sh-new/xec.c --- v9sh/xec.c 2017-07-29 12:27:02.000000000 +0300 +++ v9sh-new/xec.c 2020-02-10 17:29:50.607030967 +0200 @@ -612,7 +612,7 @@ if (flags&ttyflg && (dir1 = spname(tempdir, &score)) && stat(dir1, &sb) == 0 && - (sb.st_mode&S_IFMT) == S_IFDIR && + S_ISDIR(sb.st_mode) && access(dir1, EXECUTE) == 0) { /* dir1 is a searchable directory. */ if (score < bestscore) { From arnold at skeeve.com Tue Feb 11 19:33:52 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Feb 2020 02:33:52 -0700 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> Message-ID: <202002110933.01B9XqQX004159@freefriends.org> Rob Pike wrote: > Readline and job control were less compelling when you had multiple command > windows of editable typescript, which we all had with the Blit. Understandable. But the 99.9999% of us not in 1127 only had glass ttys. I did have a DMD 5620 for a while (which I loved), but I don't recall that it had editiable typescripts. I thought that that came in with 8-1/2 in Plan 9? Thanks, Arnold From arnold at skeeve.com Tue Feb 11 19:40:40 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Feb 2020 02:40:40 -0700 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: <202002110940.01B9eeHS004641@freefriends.org> Doug McIlroy wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. But this isn't *silent* correction. The shell tells you where it's putting you when it does this, same as in a 'cd' that happens via $CDPATH. Admittedly, you have to be paying attention, but Unix has always demanded that of its users. Note that I am not arguing with the idea that silent correction is bad; I'm merely pointing out that this is not an instance of that. Thanks, Arnold From noel.hunt at gmail.com Tue Feb 11 19:47:33 2020 From: noel.hunt at gmail.com (Noel Hunt) Date: Tue, 11 Feb 2020 18:47:33 +0900 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110933.01B9XqQX004159@freefriends.org> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: 2020年2月11日(火) 18:34 : > I did have a DMD 5620 for a while (which I loved), but I don't recall > that it had editiable typescripts. I thought that that came in > with 8-1/2 in Plan 9? > Muxterm, the default user-interface window under mux, was most definitely editable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Feb 11 19:47:58 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 20:47:58 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110933.01B9XqQX004159@freefriends.org> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: There were three window systems that I know of that ran on the various incarnations of that machine. The first, mpx, was very basic. The second, mux, allowed editing of text on the screen and had some interesting properties, such as "hold mode", which stopped all reads to the host until hold mode was cancelled. This allowed one to use the terminal window as a general text editor for any application, and was obviously an influence on various followons. It also didn't satisfy any read to the host until you hit return, so all hold mode did was make its basic one-line operation multiline, but it felt liberating and was used constantly for writing mail messages and so on. Both these systems depended (eventually) on new v8 stuff like streams and select, so they didn't work on System 3 etc. USG did a thing for themselves called layers, which was more like mpx than mux. -rob On Tue, Feb 11, 2020 at 8:33 PM wrote: > Rob Pike wrote: > > > Readline and job control were less compelling when you had multiple > command > > windows of editable typescript, which we all had with the Blit. > > Understandable. But the 99.9999% of us not in 1127 only had glass ttys. > > I did have a DMD 5620 for a while (which I loved), but I don't recall > that it had editiable typescripts. I thought that that came in > with 8-1/2 in Plan 9? > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Feb 11 19:59:24 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 20:59:24 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: My general mood about the current standard way of nerd working is how unimaginative and old-fashioned it feels. There are countless ways we could be interacting with our terminals, editors, and shells while we program, but for various sociological and historical reasons we're pretty much using one from decades ago. I'm sure it's productive for almost everyone, but it seems dull to me. We could be doing something much more dynamic. I mean, xterm is hardly more sophisticated than the lame terminal code that ran in mpx (ca. 1982), other than colors and cursor addressing, which date from the 1960s via early PCs. IDEs don't sing to me, although they are powerful, because they don't integrate well with the environment, only with the language. And they are just lots of features, not a coherent vision. No model to speak of. Compare what happened with our shell windows with what happened with our "smart" phones in the last 20 years and you'll get some inkling of what I think we're missing. It's not that we should program the way we use iPhones, but that there are fields where user interface work has made a real different recently. Not so in programming, though. We're missing out. But I'm a grumpy old man and getting far off topic. Warren should cry, "enough!". -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Feb 11 20:03:08 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 11 Feb 2020 21:03:08 +1100 Subject: [TUHS] compiling v9sh In-Reply-To: <202002110746.01B7kTrT032157@freefriends.org> References: <202002110746.01B7kTrT032157@freefriends.org> Message-ID: Is that version still using the interrupt trick? I can't remember if I ripped that out for (sad) portability reasons. -rob On Tue, Feb 11, 2020 at 6:47 PM wrote: > For anyone who's interested, here is what it took to compile Geoff > Collyer's v9sh on Ubuntu 18.04. > > Arnold > ---------------------------------- > diff -ur v9sh/error.c v9sh-new/error.c > --- v9sh/error.c 2017-07-29 11:45:07.000000000 +0300 > +++ v9sh-new/error.c 2020-02-10 17:31:33.275920947 +0200 > @@ -24,7 +24,7 @@ > } > if (per) { > prs(colon); > - prs(errno < 0 || errno >= sys_nerr? "Bad errno": > sys_errlist[errno]); > + prs(strerror(errno)); > } > newline(); > exitsh(ERROR); > diff -ur v9sh/pathserv.c v9sh-new/pathserv.c > --- v9sh/pathserv.c 2017-07-29 12:06:25.000000000 +0300 > +++ v9sh-new/pathserv.c 2020-02-10 17:29:43.666971083 +0200 > @@ -30,7 +30,7 @@ > { > struct stat buf; > > - if (stat(name, &buf) == 0 && (buf.st_mode&S_IFMT) == S_IFREG && > + if (stat(name, &buf) == 0 && S_ISREG(buf.st_mode) && > access(name, EXECUTE) == 0) > return 0; > else > diff -ur v9sh/xec.c v9sh-new/xec.c > --- v9sh/xec.c 2017-07-29 12:27:02.000000000 +0300 > +++ v9sh-new/xec.c 2020-02-10 17:29:50.607030967 +0200 > @@ -612,7 +612,7 @@ > > if (flags&ttyflg && (dir1 = spname(tempdir, > &score)) && > stat(dir1, &sb) == 0 && > - (sb.st_mode&S_IFMT) == S_IFDIR && > + S_ISDIR(sb.st_mode) && > access(dir1, EXECUTE) == 0) { > /* dir1 is a searchable directory. */ > if (score < bestscore) { > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Feb 11 20:09:31 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Feb 2020 03:09:31 -0700 Subject: [TUHS] compiling v9sh In-Reply-To: References: <202002110746.01B7kTrT032157@freefriends.org> Message-ID: <202002111009.01BA9VJo005701@freefriends.org> No, it's based on his work to make the shell use malloc. The paper describing the work is included in the tarball. Arnold Rob Pike wrote: > Is that version still using the interrupt trick? I can't remember if I > ripped that out for (sad) portability reasons. > > -rob > > > On Tue, Feb 11, 2020 at 6:47 PM wrote: > > > For anyone who's interested, here is what it took to compile Geoff > > Collyer's v9sh on Ubuntu 18.04. > > > > Arnold > > ---------------------------------- > > diff -ur v9sh/error.c v9sh-new/error.c > > --- v9sh/error.c 2017-07-29 11:45:07.000000000 +0300 > > +++ v9sh-new/error.c 2020-02-10 17:31:33.275920947 +0200 > > @@ -24,7 +24,7 @@ > > } > > if (per) { > > prs(colon); > > - prs(errno < 0 || errno >= sys_nerr? "Bad errno": > > sys_errlist[errno]); > > + prs(strerror(errno)); > > } > > newline(); > > exitsh(ERROR); > > diff -ur v9sh/pathserv.c v9sh-new/pathserv.c > > --- v9sh/pathserv.c 2017-07-29 12:06:25.000000000 +0300 > > +++ v9sh-new/pathserv.c 2020-02-10 17:29:43.666971083 +0200 > > @@ -30,7 +30,7 @@ > > { > > struct stat buf; > > > > - if (stat(name, &buf) == 0 && (buf.st_mode&S_IFMT) == S_IFREG && > > + if (stat(name, &buf) == 0 && S_ISREG(buf.st_mode) && > > access(name, EXECUTE) == 0) > > return 0; > > else > > diff -ur v9sh/xec.c v9sh-new/xec.c > > --- v9sh/xec.c 2017-07-29 12:27:02.000000000 +0300 > > +++ v9sh-new/xec.c 2020-02-10 17:29:50.607030967 +0200 > > @@ -612,7 +612,7 @@ > > > > if (flags&ttyflg && (dir1 = spname(tempdir, > > &score)) && > > stat(dir1, &sb) == 0 && > > - (sb.st_mode&S_IFMT) == S_IFDIR && > > + S_ISDIR(sb.st_mode) && > > access(dir1, EXECUTE) == 0) { > > /* dir1 is a searchable directory. */ > > if (score < bestscore) { > > From ralph at inputplus.co.uk Tue Feb 11 21:24:25 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 11 Feb 2020 11:24:25 +0000 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211035340.GA852@mcvoy.com> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> <20200211035340.GA852@mcvoy.com> Message-ID: <20200211112425.CA23522170@orac.inputplus.co.uk> Hi Larry, > Doug McIlroy wrote: > > We now know that silent correction is a terrible idea. > > I had the same thought, > > cd /some/place/I/want/to/remove > $PWD is /some/place/I/want/dont/remove > rm -rf ./* An extract from the Jargon File's DWIM entry echoes that. http://www.catb.org/~esr/jargon/html/D/DWIM.html In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost. The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type delete *$ twice. > > Postel's principle: "be conservative in what you do, be liberal in > > what you accept from others" was doctrine in early HTML specs, and > > led to disastrous disagreement among browsers' interpretation of web > > pages. Sadly, the "principle" lives on despite its having been > > expunged from the HTML spec. I often point to this Internet Draft when Postel's Law is brought up in modern discussions about letting standards slip. The Harmful Consequences of Postel's Maxim M. Thomson, Mozilla, 2015-03-09 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 After looking at divergence over time, and long-term costs, it suggests instead ‘Protocol designs and implementations should be maximally strict’. A shame it never became an RFC. Arguing Postel's Law for accepting to deviate is easy as those arguing for strictness have to work out how the laxness could cause a problem. (I'm sad to see Golang accepting deviations from standards. It has been a big enough language to take a stand for ages. https://github.com/golang/go/issues/34540 is one example of a CVE from allowing white-space where there shouldn't be any in the HTTP protocol. Just white-space, what could be harmful about accepting that? https://github.com/golang/go/issues/19989 was another HTTP white-space deviation from the spec. All to help one particular unnamed GPS system.) -- Cheers, Ralph. From clemc at ccc.com Wed Feb 12 00:36:38 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Feb 2020 09:36:38 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: Amen. As a dyslexic (which most often shows when I'm typing as you folks have experienced) autocorrect generally is a PITA. FWIW: Grammerly works well for me. It underlines in dotted red and lets me look at what it thinks it should be - where I can accept it or not. Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also and let's just say it failed as I explain in a comment /answer on quora ( https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead ). Clem On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy wrote: > > What i like is the autocorrect feature in v8: > > > > $ cd /usr/blot > > /usr/blit > > $ pwd > > /usr/blit > > Here I am, editor of the v8 manual and unaware of the feature. > We now know that silent correction is a terrible idea. > > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. > > Today's "langsec" movement grew out of bitter experience > with malicious inputs exploiting "liberal" interpretation of > nonconforming data. > > Today's NYT has an article about fake knockoffs of George Orwell > for sale on Amazon. It cites an edition of "Animal Farm" > apparently pirated by lowgrade OCR autocorrected and never > proofread. One of the many gaffes is that every instance of > "iv" beame ChapterIV, as in "prChapterIVacy". > > I didn't like some Lisp systems' DWIM (do what I mean) when I > first heard about the feature, and I like it even less 40-some > years on. I would probably have remonstrated with Rob had I > realized the shell was doing it. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Feb 12 01:06:48 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 11 Feb 2020 10:06:48 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110940.01B9eeHS004641@freefriends.org> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> <202002110940.01B9eeHS004641@freefriends.org> Message-ID: <0d0ee009-56b9-2bb9-fa08-3c386eee1536@case.edu> On 2/11/20 4:40 AM, arnold at skeeve.com wrote: > Doug McIlroy wrote: > >>> What i like is the autocorrect feature in v8: >>> >>> $ cd /usr/blot >>> /usr/blit >>> $ pwd >>> /usr/blit >> >> Here I am, editor of the v8 manual and unaware of the feature. >> We now know that silent correction is a terrible idea. > > But this isn't *silent* correction. The shell tells you where > it's putting you when it does this, same as in a 'cd' that > happens via $CDPATH. > > Admittedly, you have to be paying attention, but Unix has always > demanded that of its users. The one change I might consider is to disable this feature if the shell is executing a command list, so something like cd /usr/bon && rm -f sh* doesn't do something unexpected before a user has a chance to react. Does the v9 shell do that? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From mike.ab3ap at gmail.com Wed Feb 12 01:29:53 2020 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Tue, 11 Feb 2020 10:29:53 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: My favorite example is a business trip my wife took. Her surname is Hsi which was "corrected" to His at the site she visited. Upon arrival it took her several *hours* to work out with the security folks that Ms Hsi was not impersonating Ms His. (That says as much about the security group as it does about autocorrect, I suppose.) Mike Markowski On Tue, Feb 11, 2020 at 9:38 AM Clem Cole wrote: > Amen. As a dyslexic (which most often shows when I'm typing as you folks > have experienced) autocorrect generally is a PITA. FWIW: Grammerly > works well for me. It underlines in dotted red and lets me look at what it > thinks it should be - where I can accept it or not. > > Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried > it also and let's just say it failed as I explain in a comment /answer on > quora ( > https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead > ). > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 12 01:51:17 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Feb 2020 07:51:17 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211112425.CA23522170@orac.inputplus.co.uk> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> <20200211035340.GA852@mcvoy.com> <20200211112425.CA23522170@orac.inputplus.co.uk> Message-ID: <20200211155117.GD852@mcvoy.com> On Tue, Feb 11, 2020 at 11:24:25AM +0000, Ralph Corderoy wrote: > > > Postel's principle: "be conservative in what you do, be liberal in > > > what you accept from others" was doctrine in early HTML specs, and > > > led to disastrous disagreement among browsers' interpretation of web > > > pages. Sadly, the "principle" lives on despite its having been > > > expunged from the HTML spec. > > I often point to this Internet Draft when Postel's Law is brought up in > modern discussions about letting standards slip. > > The Harmful Consequences of Postel's Maxim > M. Thomson, Mozilla, 2015-03-09 > https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > > After looking at divergence over time, and long-term costs, it suggests > instead ???Protocol designs and implementations should be maximally > strict???. A shame it never became an RFC. > > Arguing Postel's Law for accepting to deviate is easy as those arguing > for strictness have to work out how the laxness could cause a problem. Perhaps I'm being too kind, but I think people are being a little hard on Jon. I believe what he was pushing for was "it just works". Anyone who has been involved with a long lived software base knows that as you roll out new versions you can break backwards compat. Nobody likes it when you do that. From bakul at bitblocks.com Wed Feb 12 02:03:06 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 11 Feb 2020 08:03:06 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: Message-ID: <9F0C266C-4311-4984-A2FA-85DAEF1207E1@bitblocks.com> I call it automiscorrect. First, it is very easy to mistype on these touch based interfaces and then they miscorrect using too large a vocabulary. At USC, back when I was a student, they started us off with PL/C, a subset of PL/I. The PL/C compiler tried its level best to make sense of the student programs it was given, with error messages such as “PL/C uses ....”. This was confusing to many students as they would do exactly what PL/C said it used and yet their program didn’t work. > On Feb 11, 2020, at 6:38 AM, Clem Cole wrote: > >  > Amen. As a dyslexic (which most often shows when I'm typing as you folks have experienced) autocorrect generally is a PITA. FWIW: Grammerly works well for me. It underlines in dotted red and lets me look at what it thinks it should be - where I can accept it or not. > > Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also and let's just say it failed as I explain in a comment /answer on quora (https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead). > > Clem > > > >> On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy wrote: >> > What i like is the autocorrect feature in v8: >> > >> > $ cd /usr/blot >> > /usr/blit >> > $ pwd >> > /usr/blit >> >> Here I am, editor of the v8 manual and unaware of the feature. >> We now know that silent correction is a terrible idea. >> >> Postel's principle: "be conservative in what you do, be liberal >> in what you accept from others" was doctrine in early HTML >> specs, and led to disastrous disagreement among browsers' >> interpretation of web pages. Sadly, the "principle" lives on >> despite its having been expunged from the HTML spec. >> >> Today's "langsec" movement grew out of bitter experience >> with malicious inputs exploiting "liberal" interpretation of >> nonconforming data. >> >> Today's NYT has an article about fake knockoffs of George Orwell >> for sale on Amazon. It cites an edition of "Animal Farm" >> apparently pirated by lowgrade OCR autocorrected and never >> proofread. One of the many gaffes is that every instance of >> "iv" beame ChapterIV, as in "prChapterIVacy". >> >> I didn't like some Lisp systems' DWIM (do what I mean) when I >> first heard about the feature, and I like it even less 40-some >> years on. I would probably have remonstrated with Rob had I >> realized the shell was doing it. >> >> Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Feb 12 03:05:01 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 11 Feb 2020 18:05:01 +0100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: <20200211170501.0N1Pu%steffen@sdaoden.eu> Rob Pike wrote in : |My general mood about the current standard way of nerd working is how \ |unimaginative and old-fashioned it feels. There are countless ways \ |we could be interacting with our terminals, editors, and shells |while we program, but for various sociological and historical reasons \ |we're pretty much using one from decades ago. I'm sure it's productive \ |for almost everyone, but it seems dull to me. We could be |doing something much more dynamic. I mean, xterm is hardly more sophisti\ |cated than the lame terminal code that ran in mpx (ca. 1982), other \ |than colors and cursor addressing, which date from the 1960s |via early PCs. IDEs don't sing to me, although they are powerful, because \ |they don't integrate well with the environment, only with the language. \ |And they are just lots of features, not a coherent |vision. No model to speak of. | |Compare what happened with our shell windows with what happened with \ |our "smart" phones in the last 20 years and you'll get some inkling \ |of what I think we're missing. It's not that we should program the |way we use iPhones, but that there are fields where user interface \ |work has made a real different recently. Not so in programming, though. \ |We're missing out. I cannot imagine any other real step forward but control-by- thought, aka brain computer interfaces. (I personally am even convinced we will get the brain implant -- ever since i got all those B and C Hollywood movies from the 50s wrong, back when i was a kid. It is convincing still, automatic emergency calls, health record and cases of incompatibility at hand when needed, and not to talk about the hints it will give the law enforcement side of the road.) Just last year i have seen a report on the current stage of affairs, Carnegie-Mellon and Minnesota Universities seem to have build a non-invasively controlled robotic arm, pretty high precision. "Wir haben erhebliche Fortschritte im Bereich Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate gemacht. We have made substantial progress in the region of thought-controlled robotic devices via implants. Das ist hervorragende Forschungsarbeit", sagt He. "That is superb research work", says He [Professor Bin He, Carnegie-Mellon]. "Nichtinvasiv ist jedoch unser ultimatives Ziel. Fortschritte in der neuronalen Dekodierung und der praktischen Auswirkungen auf die mögliche Entwicklung nichtinvasiver Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche Neurorobotik haben." "Albeit non-invasive is our ultimate goal. Progress in neuronal decoding, and the practical usability of non-invasive control of robotic arms will have substantial effect on the possible development of non-invasive neuro-robotics." |But I'm a grumpy old man and getting far off topic. Warren should cry, \ |"enough!". I personally would love it, if it where only in the hands of empathic beings, capable of reflection. Yet it is us. ^_^ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From clemc at ccc.com Wed Feb 12 03:12:10 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Feb 2020 12:12:10 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <9F0C266C-4311-4984-A2FA-85DAEF1207E1@bitblocks.com> References: <9F0C266C-4311-4984-A2FA-85DAEF1207E1@bitblocks.com> Message-ID: On Tue, Feb 11, 2020 at 11:03 AM Bakul Shah wrote: > I call it automiscorrect. > I've been known to same something similar. Usually with a #$%^& before it. > First, it is very easy to mistype on these touch based interfaces and then > they miscorrect using too large a vocabulary. > +1, amen brother Shah, amen, > > At USC, back when I was a student, they started us off with PL/C, a subset > of PL/I. The PL/C compiler tried its level best to make sense of the > student programs it was given, with error messages such as “PL/C uses > ....”. This was confusing to many students as they would do exactly what > PL/C said it used and yet their program didn’t work. > FWIW: I referenced both PL/C and IBM PL/1 compiler in my quora answer. In an interactive world, offering a note like Grammerly's underline, seems reasonable to me - because it forces me to accept it. The automatic doing it for me, is what I dislike - as you said, on touch interfaces it's twice as bad. I remember having a conversation with Doug Cooper when we all were teaching the intro to CS course and I we were getting students turning in 'auto-corrected' code for assignments and wondering why the TAs were not amused. I had thought that having the compiler tell you what was in error and then maybe offering a suggestion, might make sense, but there needed to be some action on the student's part to accept >>and<< repair to code before the compiler would produce something that 'ran.' Anyway, I still think "*Damn Warren's Infernal Machine*" was always well named. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Wed Feb 12 03:17:24 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 11 Feb 2020 12:17:24 -0500 (EST) Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <9F0C266C-4311-4984-A2FA-85DAEF1207E1@bitblocks.com> References: <9F0C266C-4311-4984-A2FA-85DAEF1207E1@bitblocks.com> Message-ID: On Tue, 11 Feb 2020, Bakul Shah wrote: > I call it automiscorrect. First, it is very easy to mistype on these > touch based interfaces and then they miscorrect using too large a > vocabulary. "AutocoWRECKED" -uso. From krewat at kilonet.net Wed Feb 12 03:18:55 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 11 Feb 2020 12:18:55 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211170501.0N1Pu%steffen@sdaoden.eu> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> Message-ID: <9c056bdf-0813-8df6-20b9-03b5fa1686d9@kilonet.net> Sorry to top-post... To me, the biggest handicap to getting anything done, code-wise, command-line-wise, basically anything, is the keyboard/mouse. I use keyboard shortcuts as much as possible, being an old LA36 kind guy, but I would love to have something that just by looking at text, be able to highlight, copy/cut/paste, etc. Even action buttons. It would be great to look at the "Send" button in Thunderbird and press a key on the mouse or keyboard (or some other eye-contact type signal) and "do" it. Was anything ever done in terms of sub-vocalization? Lots of stories in Sci-Fi about that, nothing ever came out of it, I don't think. On 2/11/2020 12:05 PM, Steffen Nurpmeso wrote: > Rob Pike wrote in > : > |My general mood about the current standard way of nerd working is how \ > |unimaginative and old-fashioned it feels. There are countless ways \ > |we could be interacting with our terminals, editors, and shells > |while we program, but for various sociological and historical reasons \ > |we're pretty much using one from decades ago. I'm sure it's productive \ > |for almost everyone, but it seems dull to me. We could be > |doing something much more dynamic. I mean, xterm is hardly more sophisti\ > |cated than the lame terminal code that ran in mpx (ca. 1982), other \ > |than colors and cursor addressing, which date from the 1960s > |via early PCs. IDEs don't sing to me, although they are powerful, because \ > |they don't integrate well with the environment, only with the language. \ > |And they are just lots of features, not a coherent > |vision. No model to speak of. > | > |Compare what happened with our shell windows with what happened with \ > |our "smart" phones in the last 20 years and you'll get some inkling \ > |of what I think we're missing. It's not that we should program the > |way we use iPhones, but that there are fields where user interface \ > |work has made a real different recently. Not so in programming, though. \ > |We're missing out. > > I cannot imagine any other real step forward but control-by- > thought, aka brain computer interfaces. (I personally am even > convinced we will get the brain implant -- ever since i got all > those B and C Hollywood movies from the 50s wrong, back when i was > a kid. It is convincing still, automatic emergency calls, health > record and cases of incompatibility at hand when needed, and not > to talk about the hints it will give the law enforcement side of > the road.) > > Just last year i have seen a report on the current stage of > affairs, Carnegie-Mellon and Minnesota Universities seem to have > build a non-invasively controlled robotic arm, pretty high > precision. > > "Wir haben erhebliche Fortschritte im Bereich > Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate > gemacht. > We have made substantial progress in the region of > thought-controlled robotic devices via implants. > > Das ist hervorragende Forschungsarbeit", sagt He. > "That is superb research work", says He [Professor Bin He, > Carnegie-Mellon]. > > "Nichtinvasiv ist jedoch unser ultimatives Ziel. > Fortschritte in der neuronalen Dekodierung und der praktischen > Auswirkungen auf die mögliche Entwicklung nichtinvasiver > Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche > Neurorobotik haben." > > "Albeit non-invasive is our ultimate goal. > Progress in neuronal decoding, and the practical usability of > non-invasive control of robotic arms will have substantial > effect on the possible development of non-invasive > neuro-robotics." > > |But I'm a grumpy old man and getting far off topic. Warren should cry, \ > |"enough!". > > I personally would love it, if it where only in the hands of > empathic beings, capable of reflection. Yet it is us. ^_^ > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > > From crossd at gmail.com Wed Feb 12 03:21:44 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Feb 2020 12:21:44 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, Feb 10, 2020 at 10:34 PM Doug McIlroy wrote: > Postel's principle: "be conservative in what you do, be liberal > in what you accept from others" was doctrine in early HTML > specs, and led to disastrous disagreement among browsers' > interpretation of web pages. Sadly, the "principle" lives on > despite its having been expunged from the HTML spec. > I think this is a bit unfair. Postel was working in an environment where he was fighting an uphill battle to get the Internet going and, perhaps more importantly, taken seriously: I still vividly remember the derision that was heaped on it as a "research toy" and how the "real" implementation was going to sweep it away, usually in the form of ISO/OSI. An argument can be made that the Internet's installed base and the fact that it largely worked despite imperfect implementations headed off that particular trainwreck. Indeed, one wonders if it would have even been viable as a research project had the early ARPAnet and Internet implementors taken a hard stance on correctness. That said, the HTML thing has always felt like a debacle to me, right from the beginning. It was an anaemic language delivered over a ridiculously bad protocol (HTTP 0.9 or whatever).I fully confess that I completely missed the World Wide Web thing when it first arrived on the scene. To my TeX and troff trained eyes used to interactive protocols, I couldn't see the point. Boy was I wrong! - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Feb 12 03:36:03 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Feb 2020 12:36:03 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: On Tue, Feb 11, 2020 at 4:59 AM Rob Pike wrote: > My general mood about the current standard way of nerd working is how > unimaginative and old-fashioned it feels. There are countless ways we could > be interacting with our terminals, editors, and shells while we program, > but for various sociological and historical reasons we're pretty much using > one from decades ago. I'm sure it's productive for almost everyone, but it > seems dull to me. We could be doing something much more dynamic. I mean, > xterm is hardly more sophisticated than the lame terminal code that ran in > mpx (ca. 1982), other than colors and cursor addressing, which date from > the 1960s via early PCs. IDEs don't sing to me, although they are powerful, > because they don't integrate well with the environment, only with the > language. And they are just lots of features, not a coherent vision. No > model to speak of. > > Compare what happened with our shell windows with what happened with our > "smart" phones in the last 20 years and you'll get some inkling of what I > think we're missing. It's not that we should program the way we use > iPhones, but that there are fields where user interface work has made a > real different recently. Not so in programming, though. We're missing out. > What do you think of thinks like Jupyter or Lighttable? The early demos for the latter, I thought, were particularly compelling (though sadly the current implementation seems like much more of a traditional text editor and far removed from the original vision). Compare https://www.youtube.com/watch?v=H58-n7uldoU to www.youtube.com/watch?v=52SVAMM3V78 But I'm a grumpy old man and getting far off topic. Warren should cry, > "enough!". > One of the reasons we study history is to understand the present and inform our decisions for the future. Personally, I enjoy these sorts of explorations of where we might have done things differently. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khm at sciops.net Wed Feb 12 04:22:38 2020 From: khm at sciops.net (Kurt H Maier) Date: Tue, 11 Feb 2020 10:22:38 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211170501.0N1Pu%steffen@sdaoden.eu> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> Message-ID: <20200211182238.GA5008@wopr> On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote: > > I cannot imagine any other real step forward but control-by- > thought, aka brain computer interfaces. I can't even trust computers to do the right thing with input specially crafted for the program I'm using. There is no way in hell I'm turning it loose on a direct neural interface. Software engineering, as a discipline, is going to require a lot more actual discipline before neural interfaces become anything but fuel for a dystopian hellscape. I'm not saying we can't get there. I'm saying we're not headed in that direction so far. khm From jon at fourwinds.com Wed Feb 12 04:26:51 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Feb 2020 10:26:51 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211170501.0N1Pu%steffen@sdaoden.eu> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> Message-ID: <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> Steffen Nurpmeso writes: > Rob Pike wrote in > : > |My general mood about the current standard way of nerd working is how \ > |unimaginative and old-fashioned it feels. There are countless ways \ > |we could be interacting with our terminals, editors, and shells > |while we program, but for various sociological and historical reasons \ > |we're pretty much using one from decades ago. I'm sure it's productive \ > |for almost everyone, but it seems dull to me. We could be > |doing something much more dynamic. I mean, xterm is hardly more sophisti\ > |cated than the lame terminal code that ran in mpx (ca. 1982), other \ > |than colors and cursor addressing, which date from the 1960s > |via early PCs. IDEs don't sing to me, although they are powerful, because \ > |they don't integrate well with the environment, only with the language. \ > |And they are just lots of features, not a coherent > |vision. No model to speak of. > | > |Compare what happened with our shell windows with what happened with \ > |our "smart" phones in the last 20 years and you'll get some inkling \ > |of what I think we're missing. It's not that we should program the > |way we use iPhones, but that there are fields where user interface \ > |work has made a real different recently. Not so in programming, though. \ > |We're missing out. > > I cannot imagine any other real step forward but control-by- > thought, aka brain computer interfaces. (I personally am even > convinced we will get the brain implant -- ever since i got all > those B and C Hollywood movies from the 50s wrong, back when i was > a kid. It is convincing still, automatic emergency calls, health > record and cases of incompatibility at hand when needed, and not > to talk about the hints it will give the law enforcement side of > the road.) > > Just last year i have seen a report on the current stage of > affairs, Carnegie-Mellon and Minnesota Universities seem to have > build a non-invasively controlled robotic arm, pretty high > precision. > > "Wir haben erhebliche Fortschritte im Bereich > Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate > gemacht. > We have made substantial progress in the region of > thought-controlled robotic devices via implants. > > Das ist hervorragende Forschungsarbeit", sagt He. > "That is superb research work", says He [Professor Bin He, > Carnegie-Mellon]. > > "Nichtinvasiv ist jedoch unser ultimatives Ziel. > Fortschritte in der neuronalen Dekodierung und der praktischen > Auswirkungen auf die mögliche Entwicklung nichtinvasiver > Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche > Neurorobotik haben." > > "Albeit non-invasive is our ultimate goal. > Progress in neuronal decoding, and the practical usability of > non-invasive control of robotic arms will have substantial > effect on the possible development of non-invasive > neuro-robotics." > > |But I'm a grumpy old man and getting far off topic. Warren should cry, \ > |"enough!". > > I personally would love it, if it where only in the hands of > empathic beings, capable of reflection. Yet it is us. ^_^ > > --steffen Well, I'm gonna give my two cents on this before Warren tells us that it's off-topic :-) One way to look at it is that there are two stages to programming or any other problem-solving discipline. First, clearly express the problem. Second, implement a solution. There's been a lot of improvement in both of these areas during my lifetime. Especially when I look at the "everybody must learn to code" movement I see people looking for a magic bullet; they just want to think of something and have it magically appear. Problem is that the thinking of something isn't that easy. People want DWIT (do what I think), a step beyond DWIM :-) I'm reminded of the awful virtual reality panel at SIGGRAPH some decades ago now where people stood up and said "with virtual reality there will be no misunderstanding and people will be able to know exactly what you're thinking." My response was "wow, if people knew exactly what you were thinking they'd kill you." The fuzziness of our brains is an asset here, not a liability. So I'm not thinking that translating thoughts directly into programs is a good thing. All that said, there is an area that I think needs some work, which reminds me that I wrote Tamara Munzner at UBC about this and need to ping her again. My current troublemaking project is to make an unfortunately necessary change to linux to accomplish something that I want to do. Because I haven't mucked around in the kernel before I've been keeping notes as I try to figure it out; sort of a travelogue. One of the things that's important to me is writing code for the reader, not the writer. Being old, I remember working for companies where there was warranty support for products, and that maintenance and support cost way more than development. So I've always written code for the maintainers because I never wanted to become one because nobody could figure out my code. Oh, Jon's rambling here, how is this relevant? Something that I never gave much thought about until I was a reviewer for Tamara's book is that my coding style tries to maximize the brain's pre-attentive mode. A lot of hunting around in code involves visually scanning for patterns (vgrep), and one would like to be able to do that in fixed time as opposed to linear time. In my opinion, the linux code sucks at this. The coding style of breaking up functions to keep the number of indent levels low has what I'm calling poor "meatspace locality of reference." People have caches too, and we'd never write code for a computer that thrashes as badly as code written for people. Anyway, what I've been wondering about is whether anybody has examined the UIs of different IDEs from a pre-attentive standpoint. One of the weird things about how our brains manage pre-attentive mode is that there are only a handful of things that we can do in that mode before popping out, and that those things have weird interactions. So, for example, does coloring things work? Does bracket matching work? Do they still work if you do both? A good thesis topic for someone younger than me. Jon From cbbrowne at gmail.com Wed Feb 12 04:35:07 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Tue, 11 Feb 2020 13:35:07 -0500 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: On Tue, 11 Feb 2020 at 05:00, Rob Pike wrote: > My general mood about the current standard way of nerd working is how > unimaginative and old-fashioned it feels. There are countless ways we could > be interacting with our terminals, editors, and shells while we program, > but for various sociological and historical reasons we're pretty much using > one from decades ago. I'm sure it's productive for almost everyone, but it > seems dull to me. We could be doing something much more dynamic. I mean, > xterm is hardly more sophisticated than the lame terminal code that ran in > mpx (ca. 1982), other than colors and cursor addressing, which date from > the 1960s via early PCs. IDEs don't sing to me, although they are powerful, > because they don't integrate well with the environment, only with the > language. And they are just lots of features, not a coherent vision. No > model to speak of. > > Compare what happened with our shell windows with what happened with our > "smart" phones in the last 20 years and you'll get some inkling of what I > think we're missing. It's not that we should program the way we use > iPhones, but that there are fields where user interface work has made a > real different recently. Not so in programming, though. We're missing out. > > But I'm a grumpy old man and getting far off topic. Warren should cry, > "enough!". > I recently saw indication that the UI for Sam and Acme were inspired by Oberon. (And per url [1] below, Rob Pike is quoted, sort of...) I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some elaboration on that. All that is said is that "Rob was blown away" and that this "influenced" Sam/Acme; is there some further explanation of that worth pointing at? (Or are some Oberon fans putting words in mouths? ;-) ) [1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Feb 12 04:54:57 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 12 Feb 2020 05:54:57 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: Acme was definitely inspired by Oberon the system. I visited ETH a number of times in the '80s and there were some properties of Oberon I found attractive. Acme definitely grew out of thinking I did there, but of course it was not tied to any language (unlike Oberon or an IDE), but rather integrated the Plan 9 command environment. Also, the button 3 context-getting thing was completely new, and when I spoke at ETH later about Acme, Wirth singled out that feature as something of interest. Sam predates all that. -rob On Wed, Feb 12, 2020 at 5:35 AM Christopher Browne wrote: > On Tue, 11 Feb 2020 at 05:00, Rob Pike wrote: > >> My general mood about the current standard way of nerd working is how >> unimaginative and old-fashioned it feels. There are countless ways we could >> be interacting with our terminals, editors, and shells while we program, >> but for various sociological and historical reasons we're pretty much using >> one from decades ago. I'm sure it's productive for almost everyone, but it >> seems dull to me. We could be doing something much more dynamic. I mean, >> xterm is hardly more sophisticated than the lame terminal code that ran in >> mpx (ca. 1982), other than colors and cursor addressing, which date from >> the 1960s via early PCs. IDEs don't sing to me, although they are powerful, >> because they don't integrate well with the environment, only with the >> language. And they are just lots of features, not a coherent vision. No >> model to speak of. >> >> Compare what happened with our shell windows with what happened with our >> "smart" phones in the last 20 years and you'll get some inkling of what I >> think we're missing. It's not that we should program the way we use >> iPhones, but that there are fields where user interface work has made a >> real different recently. Not so in programming, though. We're missing out. >> >> But I'm a grumpy old man and getting far off topic. Warren should cry, >> "enough!". >> > > I recently saw indication that the UI for Sam and Acme were inspired by > Oberon. (And per url [1] below, Rob Pike is quoted, sort of...) > > I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some > elaboration on that. All that is said is that "Rob was blown away" and > that this "influenced" Sam/Acme; is there some further explanation of that > worth pointing at? (Or are some Oberon fans putting words in mouths? ;-) ) > > [1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skogtun at gmail.com Wed Feb 12 07:36:53 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Tue, 11 Feb 2020 22:36:53 +0100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> Message-ID: <8c64181d-1723-e14c-e2b3-85354a9de5f7@gmail.com> Christopher Browne [11/02/2020 19.35]: > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" I wqould ask: "How would MacGyver handle this?". -- Hilsen Harald From steffen at sdaoden.eu Wed Feb 12 09:56:47 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 12 Feb 2020 00:56:47 +0100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> Message-ID: <20200211235647.TB2C9%steffen@sdaoden.eu> Jon Steinhart wrote in <202002111826.01BIQp2A1764361 at darkstar.fourwinds.com>: |Steffen Nurpmeso writes: |> Rob Pike wrote in |> : |>|My general mood about the current standard way of nerd working is how \ |>|unimaginative and old-fashioned it feels. There are countless ways \ |>|we could be interacting with our terminals, editors, and shells |>|while we program, but for various sociological and historical reasons \ |>|we're pretty much using one from decades ago. I'm sure it's productive \ |>|for almost everyone, but it seems dull to me. We could be |>|doing something much more dynamic. I mean, xterm is hardly more sophisti\ |>|cated than the lame terminal code that ran in mpx (ca. 1982), other \ |>|than colors and cursor addressing, which date from the 1960s |>|via early PCs. IDEs don't sing to me, although they are powerful, \ |>|because \ |>|they don't integrate well with the environment, only with the language. \ |>|And they are just lots of features, not a coherent |>|vision. No model to speak of. ... |> I cannot imagine any other real step forward but control-by- |> thought, aka brain computer interfaces. (I personally am even ... |> Just last year i have seen a report on the current stage of |> affairs, Carnegie-Mellon and Minnesota Universities seem to have |> build a non-invasively controlled robotic arm, pretty high |> precision. ... |One way to look at it is that there are two stages to programming or any |other problem-solving discipline. First, clearly express the problem. |Second, implement a solution. I was impressed what Steve Johnson said at the Unix 50 celebration, about that AI program which learned a game from scratch in a few hours, just by interpreting "the pixels" that the game produces on the screen ... and became better than every human being. |There's been a lot of improvement in both of these areas during my \ |lifetime. | |Especially when I look at the "everybody must learn to code" movement I see |people looking for a magic bullet; they just want to think of something and |have it magically appear. Problem is that the thinking of something isn't |that easy. People want DWIT (do what I think), a step beyond DWIM :-) Maybe visualized impressions will be interpretable at one time. If i approach an "Oracle of Delphi" mind state with a "clear" picture of where i want to go to, where i want the entire thing to end up with, then i write good code. I had this not seldom when i was younger .. but maybe i just should take long walks more often again. Freud did one every day. Of course you are right, you will likely need to focus your mind, and that requires an intellectual context, knowledge, to base upon. That requires many small learning steps, that surely will not change. In fact in the western world times to learn are much too short in my opinion, the normal way of other cultures is a flatter learning curve, which gives humans more time for personal development. The latter in theory, of course. But an imbalance of technical knowledge and development of a personal state of mind results in things like "have it magically appear". This is not what i mean. I would rather like it like those magnet paint tablets from the 70s, where you paint something and then, swoosh, everything is clean and you start from scratch. This is nothing new, we had this in many Science-Fictions, but mostly with speech interaction, like "no, stop, not that; back two steps" or something like this. But by thought. I think it must be fun, today you see all the people looking into their smartphone, then you are surrounded by truly autistic persons! |I'm reminded of the awful virtual reality panel at SIGGRAPH some decades \ |ago |now where people stood up and said "with virtual reality there will be no |misunderstanding and people will be able to know exactly what you're \ |thinking." |My response was "wow, if people knew exactly what you were thinking \ |they'd kill |you." The fuzziness of our brains is an asset here, not a liability. \ | So I'm |not thinking that translating thoughts directly into programs is a \ |good thing. Killing is a trigger for the human brain for sure. Given the substantial amount of thoughts which are put into first person shooters, for the military and (other) young teenagers. One must face that many, many brains not only have a deficit in possible targets for thinking, but also lack the motivation or overall interest in developing them. Our educational system does not seem to be interested in addressing this issue either. |All that said, there is an area that I think needs some work, which \ |reminds me |that I wrote Tamara Munzner at UBC about this and need to ping her \ |again. My |current troublemaking project is to make an unfortunately necessary \ |change to |linux to accomplish something that I want to do. Because I haven't mucked |around in the kernel before I've been keeping notes as I try to figure \ |it out; |sort of a travelogue. Linux kernel, horrific. I currently write an audio-CD access tool for Linux (since cdparanoia and its successor cd-paranoia seem to be broken, and whereas cd-info seems to be ok its tarball is about 30 MB, and i thought i can fit this in about 10 KB, and i do rely on the kernel to drive /dev/cdrom for me, anyway, we are not in the 90s or so), and i had to look into the kernel source to figure out the actual limit, and why there is one, of the number of audio frames i can read at once. The good news: it is open source! (One may not read more than a second at once.) |One of the things that's important to me is writing code for the reader, \ |not |the writer. Being old, I remember working for companies where there was |warranty support for products, and that maintenance and support cost \ |way more |than development. So I've always written code for the maintainers \ |because I |never wanted to become one because nobody could figure out my code. That is fantastic. I absolutely agree, and how often have i trapped myself because of missing comments, or non-talking variable names. It is all so logical and clear when you actually write the thing down, you cannot imagine that you will be lost in a forest in just a few months from now. That is human brain pure. |Oh, Jon's rambling here, how is this relevant? Something that I never gave |much thought about until I was a reviewer for Tamara's book is that \ |my coding |style tries to maximize the brain's pre-attentive mode. A lot of hunting |around in code involves visually scanning for patterns (vgrep), and \ |one would |like to be able to do that in fixed time as opposed to linear time. | |In my opinion, the linux code sucks at this. The coding style of breaking \ |up |functions to keep the number of indent levels low has what I'm calling poor |"meatspace locality of reference." People have caches too, and we'd never |write code for a computer that thrashes as badly as code written for \ |people. With the exception of some overall comment blocks at the beginning of files, and from a very superficial point of view, i do agree. It seems to be expected that you carefully grasp the entire code context, so that the necessity for the rest has vanished by itself. I am not a kernel person, however. But mind you, that is just how it is with Linux. You do not even get an acknowledgement if you report dramatical kernel bugs. I think i reported four or five real in the ~9-10 months i now use Linux on bare metal, iof which two/three would have been deadly in earlier times (Linux kernel survives crashes of a thread). I did not get feedback for anything. But two were fixed as time went by, that is the good news. |Anyway, what I've been wondering about is whether anybody has examined the |UIs of different IDEs from a pre-attentive standpoint. One of the weird |things about how our brains manage pre-attentive mode is that there \ |are only |a handful of things that we can do in that mode before popping out, \ |and that |those things have weird interactions. So, for example, does coloring \ |things |work? Does bracket matching work? Do they still work if you do both? A |good thesis topic for someone younger than me. Interesting. I have bookmarked a presentation of her to look at when i have free time/download again. I would think substantial amount of money has been pumped in this area, but i never cared. I work best when i take a long walk in nature, and hope that i get kissed by the muse. ^_^ Then come back with a "mind map" of what there shall be. And implement it pretty naked vim(1). ^_^ It seems i do not do all that good enough today. What i think is that having those new possibilities could possibly attract more people. There are so many techniques to train your brain, to strengthen memory, for example, to memorize tremendous amount of data somehow, for example by "placing the data on a virtual walk through the flat", and similar techniques. If people had the option to use their very own imagination, and having computers map that, i think that would be interesting. So i think, whereas the actual diversity in between people is pretty minor, all that software now offers are colour themes and possibly 3-d effects and whatever, but that is all optics and has nothing much to do with touching peoples individual "brain needs", aka it does not reach into their inner world in order to, i just read that nice american term last week, "milk the shit out of it". ^_^ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jon at fourwinds.com Wed Feb 12 10:12:51 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Feb 2020 16:12:51 -0800 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211235647.TB2C9%steffen@sdaoden.eu> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> <20200211235647.TB2C9%steffen@sdaoden.eu> Message-ID: <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> Steffen Nurpmeso writes: > > Of course you are right, you will likely need to focus your mind, > and that requires an intellectual context, knowledge, to base upon. Interesting that you mention this as I'm about to leave for a multi-day advanced yoga workshop. One of the things that I like about yoga is that you do have to learn to focus your mind, and it's amazingly difficult to be focused on something as seemingly simple as standing up straight. I don't think that it's reasonable to expect people to be able to focus without training. Can you imagine if a computer tried to follow all of your fleeting thoughts? In some respects, this takes me back to the early days of speech recognition. I remember people enthusiastically telling me how it would solve the problem of repetitive stress injuries. They were surprised when I pointed out that most people who use their voice in their work actually take vocal training; RSIs are not uncommon among performers. So really, what problem are we trying to solve here? I would claim that the problem is signal-to-noise ratio degradation that's a result of too many people "learning to code" who have never learned to think. Much like I feel that it became harder to find good music when MIDI was invented because there was all of a sudden a lot more noise masquerading as music. I'm reminded of a Usenix panel session that I moderated on the future of window systems a long time ago. Rob was on the panel as was some guy whose name I can't remember from Silicon Graphics. The highlight of the presentation was when Robin asked the question "So, if I understand what the SGI person is saying, it doesn't matter how ugly your shirt is, you can always cover it up with a nice jacket...." While she was asking the question Rob anticipated the rest of the question and started unbuttoning his shirt. So maybe I'm just an old-school minimalist, but I think that the biggest problem that needs solving is good low-level abstractions that are simple and work and don't have to be papered over with layer upon layer on top of them. I just find myself without the patience to learn all of the magic incantations of the package of the week. Jon From wkt at tuhs.org Wed Feb 12 11:03:00 2020 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 12 Feb 2020 11:03:00 +1000 Subject: [TUHS] V9 shell In-Reply-To: <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> <20200211235647.TB2C9%steffen@sdaoden.eu> <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> Message-ID: <20200212010300.GA17986@minnie.tuhs.org> On Tue, Feb 11, 2020 at 04:12:51PM -0800, Jon Steinhart wrote: > > Of course you are right, you will likely need to focus your mind, > > and that requires an intellectual context, knowledge, to base upon. > > Interesting that you mention this as I'm about to leave for a multi-day > advanced yoga workshop. And at this point I'd recommend that we move some of this out to COFF as it's not Unix related. Don't forget that the mailing list archive is itself a living archive of Unix past and present: https://minnie.tuhs.org/pipermail/tuhs/ It now spans 25 years of postings. I really want it to have a high signal to noise level so that future archive readers can find good information. That's why COFF exists, so you can shoot the breeze and go off on tangents. I've noticed some of you are self regulating & moving over to COFFS. Excellent! Cheers, Warren From robpike at gmail.com Wed Feb 12 15:54:41 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 12 Feb 2020 16:54:41 +1100 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <202002111826.01BIQp2A1764361@darkstar.fourwinds.com> <20200211235647.TB2C9%steffen@sdaoden.eu> <202002120012.01C0CpEC3910426@darkstar.fourwinds.com> Message-ID: Actually, I just took off a dull sweatshirt to reveal a bright shirt. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Feb 13 01:57:13 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 12 Feb 2020 16:57:13 +0100 Subject: [TUHS] Unix50.org Message-ID: <37DFE296-5233-47E8-AB41-C06E6B322016@planet.nl> I rather enjoyed having the “unix50.org” website around: very handy to test out bits and pieces of Unix history. It seems to have been taken down. Would it make sense to have this resource available permanently? From thomas.paulsen at firemail.de Thu Feb 13 04:31:34 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 12 Feb 2020 19:31:34 +0100 Subject: [TUHS] Unix50.org In-Reply-To: <37DFE296-5233-47E8-AB41-C06E6B322016@planet.nl> References: <37DFE296-5233-47E8-AB41-C06E6B322016@planet.nl> Message-ID: <153190d1a7f521d9c117ffa4f0b63223@firemail.de> >It seems to have been taken down. Would it make sense to have this resource available permanently? yes! From grog at lemis.com Fri Feb 14 09:41:21 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 14 Feb 2020 10:41:21 +1100 Subject: [TUHS] jitsi on FreeBSD (was: Also, a video service) In-Reply-To: References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> <20200209232139.B85D0156E40E@mail.bitblocks.com> Message-ID: <20200213234121.GC64389@eureka.lemis.com> On Monday, 10 February 2020 at 16:35:44 +1300, Wesley Parish wrote: > Thanks, Bakul. I'm just now installing jitsi on one of my Linux boxen. > > Speaking of FreeBSD and MacOS, I'm sure the source code at > https://download.jitsi.org/jitsi/src/ will compile on FreeBSD with a > simple ./configure and make. Thanks for that. I was wondering where the sources had gone. I've now updated the port net-im/jitsi, so you should be able to build directly from there, or install the package once it has been built (a few days, I think). Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Fri Feb 14 09:43:58 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 14 Feb 2020 10:43:58 +1100 Subject: [TUHS] Video service on FreeBSD (was: Also, a video service) In-Reply-To: References: <20200209020246.GA19979@minnie.tuhs.org> <20200209004854.GB7353@minnie.tuhs.org> <20200209225638.GG75158@eureka.lemis.com> Message-ID: <20200213234358.GD64389@eureka.lemis.com> On Sunday, 9 February 2020 at 22:09:47 -0800, jason-tuhs at shalott.net wrote: > >>> All, I've also set this up to try out for the video chats: >>> https://meet.tuhs.org/COFF >>> Password to join is "unix" at the moment. > >> Just tried it out. On FreeBSD I get a blank grey screen. I could >> only get something more on a Microsoft box, not quite what I'd want to >> do. Is there some trick? > > * Install /usr/ports/net-im/jitsi. (Comment out the BROKEN line from the > Makefile and "make install" should work as usual; the source can actually > be fetched just fine...) In fact, the package was indeed unfetchable, but the ports collection had a cached version, which is what you got. But now I've brought it up to date (only 2 years old rather than 4). > * kldload cuse > > * Run firefox and surf to that URL. I haven't found that necessary. In fact, installing jitsi doesn't seem to be necessary. All you need is a more recent browser than the antiques I was running. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From pnr at planet.nl Sat Feb 15 02:22:37 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 14 Feb 2020 17:22:37 +0100 Subject: [TUHS] Datakit early end-to-end protocol(s) Message-ID: <7128AB08-C99E-490E-BD81-7D62503FF676@planet.nl> I’m looking for the end-to-end datakit network protocol as it existed in 7th Edition. Context is as follows: - The Spider network guaranteed reliable, in-order delivery of packets at the TIU interface. There does not seem to have been a standard host end-to-end protocol, although applications did of course contain sanity checks (see for instance the ‘nfs’ source here: http://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip) - Datakit dropped the reliable delivery part (although it did retain the in-order guarantee) and moved this responsibility to the host. It is the (early) evolution of the related protocol that I’m trying to dig up. - 7th Edition appears to have had a (serial line based) Datakit connection. Datakit drivers are not in the distributed files, but its tty.h file has defines for several Datakit related constants. Also, as the first Datakit switches became operational at Murray Hill in ’78 or ’79, it seems a reasonable assumption that the Research code base included drivers & protocols for it around that time. - After that the trail continues with the 8th edition which has a stream filter (dkp.c) for the “New Datakit Protocol”: http://chiselapp.com/user/pnr/repository/v8unix/artifact/01b4f6f05733aba5 This suggests that there was an “Old Datakit Protocol” as well - if so, this may have been the protocol in use at the time of 7th Edition. The “New Datakit Protocol” appears to be (more or less) the same as what was later called URP (Universal Receiver Protocol). At the time of Plan9 its IL/IP protocol appears to have been designed as an equivalent for URP/Datakit. The early protocols where apparently (co-)designed by Greg Chesson and maybe also stood at the base of his later XTP protocol work. Any recollections about the early history and evolution of this Datakit protocol are much appreciated. Also, if the source to the 7th Edition Datakit network stack survived I’d love to hear. Paul From steve at quintile.net Sun Feb 16 20:28:36 2020 From: steve at quintile.net (Steve Simon) Date: Sun, 16 Feb 2020 10:28:36 +0000 Subject: [TUHS] TUHS Digest, Vol 51, Issue 18 In-Reply-To: References: Message-ID: maybe if interest, i have a copy of an article by sandy fraser, “early experiments with time division networks” from ieee networks, jan 1993, pp12-26. this is a high level paper and describes spider, datakit, incon. it may have little new but i felt it had a lot of good background and a useful references list. i am wary of scanning it as its the ieee... -Steve > On 15 Feb 2020, at 2:00 am, tuhs-request at minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs at minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request at minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner at minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. Datakit early end-to-end protocol(s) (Paul Ruizendaal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Feb 2020 17:22:37 +0100 > From: Paul Ruizendaal > To: TUHS main list > Subject: [TUHS] Datakit early end-to-end protocol(s) > Message-ID: <7128AB08-C99E-490E-BD81-7D62503FF676 at planet.nl> > Content-Type: text/plain; charset=utf-8 > > > I’m looking for the end-to-end datakit network protocol as it existed in 7th Edition. > > Context is as follows: > > - The Spider network guaranteed reliable, in-order delivery of packets at the TIU interface. There does not seem to have been a standard host end-to-end protocol, although applications did of course contain sanity checks (see for instance the ‘nfs’ source here: http://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip) > > - Datakit dropped the reliable delivery part (although it did retain the in-order guarantee) and moved this responsibility to the host. It is the (early) evolution of the related protocol that I’m trying to dig up. > > - 7th Edition appears to have had a (serial line based) Datakit connection. Datakit drivers are not in the distributed files, but its tty.h file has defines for several Datakit related constants. Also, as the first Datakit switches became operational at Murray Hill in ’78 or ’79, it seems a reasonable assumption that the Research code base included drivers & protocols for it around that time. > > - After that the trail continues with the 8th edition which has a stream filter (dkp.c) for the “New Datakit Protocol”: http://chiselapp.com/user/pnr/repository/v8unix/artifact/01b4f6f05733aba5 This suggests that there was an “Old Datakit Protocol” as well - if so, this may have been the protocol in use at the time of 7th Edition. > > The “New Datakit Protocol” appears to be (more or less) the same as what was later called URP (Universal Receiver Protocol). At the time of Plan9 its IL/IP protocol appears to have been designed as an equivalent for URP/Datakit. The early protocols where apparently (co-)designed by Greg Chesson and maybe also stood at the base of his later XTP protocol work. > > Any recollections about the early history and evolution of this Datakit protocol are much appreciated. Also, if the source to the 7th Edition Datakit network stack survived I’d love to hear. > > Paul > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > > ------------------------------ > > End of TUHS Digest, Vol 51, Issue 18 > ************************************ From dot at dotat.at Mon Feb 17 03:30:57 2020 From: dot at dotat.at (Tony Finch) Date: Sun, 16 Feb 2020 17:30:57 +0000 Subject: [TUHS] TUHS Digest, Vol 51, Issue 18 In-Reply-To: References: Message-ID: Steve Simon wrote: > > maybe if interest, i have a copy of an article by sandy fraser, “early > experiments with time division networks” from ieee networks, jan 1993, > pp12-26. On-line link: https://ieeexplore.ieee.org/document/193084 Tony. -- f.anthony.n.finch http://dotat.at/ The Minch: West or southwest 7 to severe gale 9. Rough or very rough. Showers, wintry and thundery at times. Moderate or poor, occasionally good. From wobblygong at gmail.com Mon Feb 17 07:34:33 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 17 Feb 2020 10:34:33 +1300 Subject: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] In-Reply-To: <20200211182238.GA5008@wopr> References: <202002101546.01AFkOSc001266@freefriends.org> <202002110933.01B9XqQX004159@freefriends.org> <20200211170501.0N1Pu%steffen@sdaoden.eu> <20200211182238.GA5008@wopr> Message-ID: It's the stuff of SF - hopefully a lot better than the glorified "one-man shooter action" DooM fictionalizations we've seen (or not) so many of ... COFF's Harbour ... Wesley Parish On 2/12/20, Kurt H Maier wrote: > On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote: >> >> I cannot imagine any other real step forward but control-by- >> thought, aka brain computer interfaces. > > I can't even trust computers to do the right thing with input specially > crafted for the program I'm using. There is no way in hell I'm turning > it loose on a direct neural interface. Software engineering, as a > discipline, is going to require a lot more actual discipline before > neural interfaces become anything but fuel for a dystopian hellscape. > > I'm not saying we can't get there. I'm saying we're not headed in that > direction so far. > > khm > From pnr at planet.nl Mon Feb 17 09:16:49 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 17 Feb 2020 00:16:49 +0100 Subject: [TUHS] TUHS Digest, Vol 51, Issue 18 Message-ID: > maybe if interest, i have a copy of an article by sandy fraser, “early experiments with time division networks” from ieee networks, jan 1993, pp12-26. > > this is a high level paper and describes spider, datakit, incon. > > it may have little new but i felt it had a lot of good background and a useful references list. > > i am wary of scanning it as its the ieee... > > -Steve Many thanks for the suggestion! Just the other day I bought another Fraser paper on IEEE, "Towards a Universal Data Transport System” from 1983, which is also a high level descriptive overview. A few people have responded off list and will be looking through their archives for relevant papers. From jsteve at superglobalmegacorp.com Mon Feb 17 14:35:05 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 17 Feb 2020 04:35:05 +0000 (UTC) Subject: [TUHS] SUN-2 emulator Message-ID: <25E62EB5E090E7CB.db8c5763-f6cf-4a4b-aa7c-fc75726eeb7f@mail.outlook.com> While messing around with the '87 release of GCC, I was going through the steps of setting up TME, and I stumbled across this derived emulator that is incredibly simple to setup and run, unlike TME: https://github.com/lisper/emulator-sun-2 Additional patches adding a BPF backend Ethernet adapter is here: https://github.com/sigurbjornl The program itself is only slightly C++ with a few variables being declared inline which was trivial to move to section starting to get it to compile with a picky C compiler (Microsoft C). The IO is SDL based, so making an x86/ARM win32 was really trivial.  Anyway for all the SunOS enthusiasts I figured that you would love to give this one a shot!  For Windows users, or anyone wanting to just run it on some unsuspecting normies I put Win32 x86 binaries here: https://sourceforge.net/projects/bsd42/files/4BSD%20under%20Windows/v0.4/SUN2.zip/download I have to wonder how impossible it would be to integrate it into SIMH...  -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Feb 18 01:20:52 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 17 Feb 2020 10:20:52 -0500 Subject: [TUHS] man Macro Package and pdfmark Message-ID: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> > one of the things I wanted to do in my retirement was convert > all the stuff that is in debian back from info to man(7) *all* the stuff? Please don't do that literally. The garrulity quotient of info pages dwarfs even that of the most excessive modern man pages. But I appplaud the intent to assure man pages are complete. Doug From clemc at ccc.com Tue Feb 18 02:47:48 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 17 Feb 2020 11:47:48 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, Feb 17, 2020 at 10:22 AM Doug McIlroy wrote: > > *all* the stuff? Please don't do that literally. The garrulity > quotient of info pages dwarfs even that of the most excessive > modern man pages. 😂 But I appplaud the intent to assure man pages are complete. > The problem is that too many of the gnu style man pages are just written in the key of -> "see figure one " as documents telling you to go to info (which I find maddening). [I find it similar to ITS not accepting a BS as the correction character, but instead picking it up and then telling you to use DEL -- the designers know what you want, sigh]. I'd like simple man pages that are reasonable references. And then get the rest of the needed documentation out info and the weird hyper texting stuff into a paper (so you can read it linearly - the way we were taught as children). I loved the simple prose in the papers that usually accompanied the traditional UNIX programs/tools. I read them and reread them as I learned to use the features and concepts provided by the more complicated tools. After that, the simple man pages were more than sufficient to remind me of the specifics I needed to use some features I did not use every day. Clem One of my complaints with info is that as a format, it leads to documents that does neither well. They tend not to be reference documents like man pages as you point out, but they are moisty often than not, particularly good explanations either. Sigh... -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Tue Feb 18 04:09:57 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 17 Feb 2020 19:09:57 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> Message-ID: <4d252035b323b7583c5760c952d1982c@firemail.de> >*all* the stuff? Please don't do that literally. The garrulity >quotient of info pages dwarfs even that of the most excessive ;-) >modern man pages. But I appplaud the intent to assure man >pages are complete. info pages clearly are redundant. Even worser under linux most of them visualizing man pages, whereas hardly any man page is missing. They are emacs style help pages in the tradition of twenex/its, and I tell you that a few years ago one guy (not me) recommended in the emacs developer list to replace tekinfo by something modern like .html. Thus the question isn't man or tekinfo for linux documentation but html/markup or or tekinfo for emacs build-in self documentation. From jon at fourwinds.com Tue Feb 18 04:39:08 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 17 Feb 2020 10:39:08 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <4d252035b323b7583c5760c952d1982c@firemail.de> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> Message-ID: <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Thomas Paulsen writes: > >*all* the stuff? Please don't do that literally. The garrulity > >quotient of info pages dwarfs even that of the most excessive > ;-) > >modern man pages. But I appplaud the intent to assure man > >pages are complete. > info pages clearly are redundant. Even worser under linux most of them > visualizing man pages, whereas hardly any man page is missing. > They are emacs style help pages in the tradition of twenex/its, and I tell > you that a few years ago one guy (not me) recommended in the emacs developer > list to replace tekinfo by something modern like .html. > > Thus the question isn't man or tekinfo for linux documentation but html/markup > or or tekinfo for emacs build-in self documentation. I think that this discussion is like bell-bottoms, it comes around every few years. Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense. I consider man pages to be quick references. But my real issue with texinfo wouldn't get solved with html pages many of which already exist. The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? Jon From jnc at mercury.lcs.mit.edu Tue Feb 18 04:55:37 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Feb 2020 13:55:37 -0500 (EST) Subject: [TUHS] man Macro Package and pdfmark Message-ID: <20200217185537.6F75718C101@mercury.lcs.mit.edu> > From: Jon Steinhart > When you're looking for the documentation for pdf2svg, for example, and > there is no man page, how long does it take to figure out that there is > no documentation at all? I am _sooo_ tempted to say 'What do you think source is for?' :-) Noel From clemc at ccc.com Tue Feb 18 06:13:40 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 17 Feb 2020 15:13:40 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200217185537.6F75718C101@mercury.lcs.mit.edu> References: <20200217185537.6F75718C101@mercury.lcs.mit.edu> Message-ID: On Mon, Feb 17, 2020 at 1:56 PM Noel Chiappa wrote: > > From: Jon Steinhart > > > When you're looking for the documentation for pdf2svg, for example, > and > > there is no man page, how long does it take to figure out that there > is > > no documentation at all? > > I am _sooo_ tempted to say 'What do you think source is for?' :-) > > Noel > Ah, the old 'trust (read) the source Luke' defense .... -------------- next part -------------- An HTML attachment was scrubbed... URL: From corky1951 at comcast.net Tue Feb 18 07:06:27 2020 From: corky1951 at comcast.net (CHARLES KESTER) Date: Mon, 17 Feb 2020 13:06:27 -0800 (PST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <20200217185537.6F75718C101@mercury.lcs.mit.edu> Message-ID: <972892045.493027.1581973588504@connect.xfinity.com> > On February 17, 2020 at 12:13 PM Clem Cole wrote: > > > On Mon, Feb 17, 2020 at 1:56 PM Noel Chiappa > wrote: > > > > From: Jon Steinhart > > > > > When you're looking for the documentation for pdf2svg, for example, > > and > > > there is no man page, how long does it take to figure out that there > > is > > > no documentation at all? > > > > I am _sooo_ tempted to say 'What do you think source is for?' :-) > > > > Noel > > > Ah, the old 'trust (read) the source Luke' defense .... ... which, unfortunately, is all too often invoked by people who fail to honor the obligation it imposes to write clear, understandable code. From thomas.paulsen at firemail.de Tue Feb 18 07:16:26 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 17 Feb 2020 22:16:26 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002171839.01HId8FT1358073@darkstar.fourwinds.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: <09e237edcd28706e59b089e13866caec@firemail.de> >Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense. I consider man pages to be quick references. reasonable. I write all my quick references in plain nroff since many years. There are gui editors, gui viewers, and lots of cgi search engines && web viewers even with hyperlinks. Even under good ole emacs techinfo is redundant, as 'woman' can do hyperlinks, which were the only advantage of techinfo in a remote past, however time goes on. Today we have help2man, hence the lazy ones can do man pages too. >The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) >format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for >pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? that's true. In the early 90ths they forced us writing quick references with .html. Big confusion. Soon later I found myself converting .html back into nroff because thats the UNIX style. I know some of us don't like to hear that, but with regards to the gnu tool chain, Richard did a lot of good things, however the politics of replacing man by techinfo definitely wasn't. From sauer at technologists.com Tue Feb 18 07:50:09 2020 From: sauer at technologists.com (Charles H Sauer) Date: Mon, 17 Feb 2020 15:50:09 -0600 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions Message-ID: <27a3d023-17c2-3e61-5ba7-677365fbcae7@technologists.com> The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things that I should have known (or knew and forgot?) while I was at IBM. http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From thomas.paulsen at firemail.de Tue Feb 18 08:50:17 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 17 Feb 2020 23:50:17 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002171839.01HId8FT1358073@darkstar.fourwinds.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: >Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense. I consider man pages to be quick references. reasonable. I write all my quick references in plain nroff since many years. There are gui editors, gui viewers, and lots of cgi search engines && web viewers even with hyperlinks. Even under good ole emacs techinfo is redundant, as 'woman' can do hyperlinks, which were the only advantage of techinfo in a remote past, however time goes on. Today we have help2man, hence the lazy ones can do man pages too. 'The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? ' that's true. In the early 90ths they forced us writing quick references with .html. Big confusion. Soon later I found myself converting .html back into nroff because that's the UNIX style. I know some of us don't like to hear that, but with regards to the gnu tool chain, Richard did a lot of good things, however the politics of replacing man by techinfo definitely wasn't. From imp at bsdimp.com Tue Feb 18 09:22:32 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 17 Feb 2020 16:22:32 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: On Mon, Feb 17, 2020 at 3:51 PM Thomas Paulsen wrote: > >Like Clem, I prefer concise man pages and longer, separate documents for > those programs where it makes sense. I consider man pages to be quick > references. > reasonable. > I write all my quick references in plain nroff since many years. There are > gui editors, gui viewers, and lots of cgi search engines && web viewers > even with hyperlinks. Even under good ole emacs techinfo is redundant, as > 'woman' can do hyperlinks, which were the only advantage of techinfo in a > remote past, however time goes on. Today we have help2man, hence the lazy > ones can do man pages too. > > > 'The problem is that the ecosystem has been fragmented by people doing > their "documentation" in their preferred formats instead of in a common > (man) format. This makes the experience one of "is there any > documentation?" followed by "what's the incantation to get it?" When you're > looking for the documentation for pdf2svg, for example, and there is no man > page, how long does it take to figure out that there is no documentation at > all? ' > > that's true. In the early 90ths they forced us writing quick references > with .html. Big confusion. Soon later I found myself converting .html back > into nroff because that's the UNIX style. > I know some of us don't like to hear that, but with regards to the gnu > tool chain, Richard did a lot of good things, however the politics of > replacing man by techinfo definitely wasn't. > I think this showed the wisdom of deleting binaries from /usr/bin when there was no man page for them... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Feb 18 10:03:08 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 17 Feb 2020 19:03:08 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: > 'The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. Damn those unauthorized developers. How dare they write code that doesn't meet standards. Get off my lawn. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Feb 18 10:17:18 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 17 Feb 2020 16:17:18 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Richard Salz writes: > > > 'The problem is that the ecosystem has been fragmented by people doing > their "documentation" in their preferred formats instead of in a common > (man) format. > > Damn those unauthorized developers. How dare they write code that doesn't > meet standards. > > Get off my lawn. The relevant TUHS part of it that maybe some folks here can speak to is how did UNIX remain so cohesive for so long? How were decisions made? Of course, this started to fall apart with System III and such as things got more clunky. I've probably said this before, but today I see way too much "string theory programming". What I mean by that is the "I have an idea so I'll just start my own universe that doesn't play well with others rather than extending the existing ecosystem" model. That's my beef with texinfo; there was already an existing functional system and rather than making some improvements a new incompatible universe was created. Noel Chiappa writes: > I am _sooo_ tempted to say 'What do you think source is for?' :-) I think that this is part of the problem, have you looked at the source for any modern package? It's pretty impenetrable. I see a lot of overly complex, poorly written code with no documentation. That makes it really difficult for someone to extend or otherwise modify it. It's probably easier to create a new universe than understand an existing one. Jon From dave at horsfall.org Tue Feb 18 10:36:55 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 18 Feb 2020 11:36:55 +1100 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200217185537.6F75718C101@mercury.lcs.mit.edu> References: <20200217185537.6F75718C101@mercury.lcs.mit.edu> Message-ID: On Mon, 17 Feb 2020, Noel Chiappa wrote: > I am _sooo_ tempted to say 'What do you think source is for?' :-) "Use the source, Luke" :-) -- Dave From lm at mcvoy.com Tue Feb 18 10:54:09 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 17 Feb 2020 16:54:09 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <20200218005409.GD4767@mcvoy.com> On Mon, Feb 17, 2020 at 04:17:18PM -0800, Jon Steinhart wrote: > Richard Salz writes: > > > > > 'The problem is that the ecosystem has been fragmented by people doing > > their "documentation" in their preferred formats instead of in a common > > (man) format. > > > > Damn those unauthorized developers. How dare they write code that doesn't > > meet standards. > > > > Get off my lawn. > > The relevant TUHS part of it that maybe some folks here can speak to is how > did UNIX remain so cohesive for so long? How were decisions made? Of course, > this started to fall apart with System III and such as things got more clunky. I think that part of it was that machines were small, both in memory and in disk. I did a huge programming project because I wanted to compress the pathalias output; I had 20 users on a 40MB disk. So big == evil. The other thing, if we're talking about kernels, uniprocessor kernels were pretty simple to understand compared to SMP, and NUMA, and the PCI devices tree and a million other things that modern computers had. v6 was documented in the lion book, you could read it all and understand it in maybe a week or two? That's not a thing any more. > I've probably said this before, but today I see way too much "string theory > programming". What I mean by that is the "I have an idea so I'll just start > my own universe that doesn't play well with others rather than extending the > existing ecosystem" model. That's my beef with texinfo; there was already > an existing functional system and rather than making some improvements a new > incompatible universe was created. Yeah, you need a dictator that says that's not OK. From bakul at bitblocks.com Tue Feb 18 10:56:34 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 17 Feb 2020 16:56:34 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: Your message of "Mon, 17 Feb 2020 16:22:32 -0700." References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: <20200218005641.672CF156E411@mail.bitblocks.com> On Mon, 17 Feb 2020 16:22:32 -0700 Warner Losh wrote: > > I think this showed the wisdom of deleting binaries from /usr/bin when > there was no man page for them... If some of us undertake to write a few man pages and review a few written by others, over time we can make a sizable dent in the problem. Something worth considering for FreeBSD ports? Of course, not as much fun as complaining and a lot more work :-) From bakul at bitblocks.com Tue Feb 18 11:05:50 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 17 Feb 2020 17:05:50 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: Your message of "Mon, 17 Feb 2020 16:17:18 -0800." <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <20200218010557.7AA48156E411@mail.bitblocks.com> On Mon, 17 Feb 2020 16:17:18 -0800 Jon Steinhart wrote: > Richard Salz writes: > > > > > 'The problem is that the ecosystem has been fragmented by people doing > > their "documentation" in their preferred formats instead of in a common > > (man) format. > > > > Damn those unauthorized developers. How dare they write code that doesn't > > meet standards. > > > > Get off my lawn. > > The relevant TUHS part of it that maybe some folks here can speak to is how > did UNIX remain so cohesive for so long? How were decisions made? Of course, > this started to fall apart with System III and such as things got more clunky. Agree. I don't mind additional documentation but a man page is strongly preferred. > Noel Chiappa writes: > > I am _sooo_ tempted to say 'What do you think source is for?' :-) > > I think that this is part of the problem, have you looked at the source for > any modern package? It's pretty impenetrable. I see a lot of overly complex, > poorly written code with no documentation. That makes it really difficult for > someone to extend or otherwise modify it. It's probably easier to create a > new universe than understand an existing one. There is just so much more code now and the S/N ratio is definitely worse but there is more good stuff as well. My problems with using the source as documentation: a) there is usually no or insufficient documentation about even what it is implementing let alone *how* it should be used, b) you don't know if some behavior is an accident of the way the code behaves or actually part of some required (but unwritten) specification. c) even if there some function header comments often there is no top level comment tying together eveyrthing. d) harder to see missing functionality. e) impossible to grok large programs. From aek at bitsavers.org Tue Feb 18 11:30:12 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 17 Feb 2020 17:30:12 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <27a3d023-17c2-3e61-5ba7-677365fbcae7@technologists.com> References: <27a3d023-17c2-3e61-5ba7-677365fbcae7@technologists.com> Message-ID: <603eee49-26a1-c2ab-61ae-aa9d75896744@bitsavers.org> I'm in the process of restoring/documenting the machine, and also helping a member of the MAME team to emulate the system. On 2/17/20 1:50 PM, Charles H Sauer wrote: > The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by > RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things > that I should have known (or knew and forgot?) while I was at IBM. > > http://www.bitsavers.org/pdf/ibm/pc/rt/ > From aek at bitsavers.org Tue Feb 18 11:32:36 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 17 Feb 2020 17:32:36 -0800 Subject: [TUHS] SUN-2 emulator In-Reply-To: <25E62EB5E090E7CB.db8c5763-f6cf-4a4b-aa7c-fc75726eeb7f@mail.outlook.com> References: <25E62EB5E090E7CB.db8c5763-f6cf-4a4b-aa7c-fc75726eeb7f@mail.outlook.com> Message-ID: <3462e9cc-f969-cbc7-133e-fd911dc360fb@bitsavers.org> On 2/16/20 8:35 PM, Jason Stevens wrote: > Anyway for all the SunOS enthusiasts I figured that you would love to give this one a shot!  I reorganized the SunOS dumps on bitsavers.org/bits/Sun this weekend and added a few more dumps of other copies of release 1.0 and 1.1 From dave at horsfall.org Tue Feb 18 13:33:12 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 18 Feb 2020 14:33:12 +1100 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: On Mon, 17 Feb 2020, Warner Losh wrote: > I think this showed the wisdom of deleting binaries from /usr/bin when > there was no man page for them... Was it Ken or Dennis who used to do that? People quickly learned to write up a man page :-) -- Dave From jsteve at superglobalmegacorp.com Tue Feb 18 14:41:32 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 Feb 2020 04:41:32 +0000 (UTC) Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions Message-ID: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> Interesting stuff!  And another version of Mach is buried in there.  So the 4 csrg cd set may have updates to the romp support as it's an older version of the 5.1 kernel from 89...  Not that think there is any Mach romp users.  Get Outlook for Android From: TUHS on behalf of Charles H Sauer Sent: Tuesday, February 18, 2020, 5:51 a.m. To: TUHS Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things that I should have known (or knew and forgot?) while I was at IBM. http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Tue Feb 18 14:53:54 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 17 Feb 2020 21:53:54 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> Message-ID: Can you clarify what is Mach in this archive if I have a gap in my knowledge? I didn’t know the VRM had any direct relationship to Mach Regards, Kevin On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > Interesting stuff! And another version of Mach is buried in there. > > So the 4 csrg cd set may have updates to the romp support as it's an older > version of the 5.1 kernel from 89... Not that think there is any Mach romp > users. > > Get Outlook for Android > > ------------------------------ > *From:* TUHS on behalf of Charles H Sauer < > sauer at technologists.com> > *Sent:* Tuesday, February 18, 2020, 5:51 a.m. > *To:* TUHS > *Subject:* [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions > > The Bitsavers' RSS feed ( > http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to > me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last > week or so. I've only sampled a few items, but discovered a few things that > I should have known (or knew and forgot?) while I was at IBM. > http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: > sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter > : > CharlesHSauer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Tue Feb 18 17:27:43 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 18 Feb 2020 08:27:43 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> Message-ID: <68a83fe8e7b5b8866819977d11730433@firemail.de> >> I think this showed the wisdom of deleting binaries from /usr/bin when there was no man page for them... >Was it Ken or Dennis who used to do that? People quickly learned to write Brian? From woods at robohack.ca Tue Feb 18 17:40:03 2020 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 17 Feb 2020 23:40:03 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart wrote: Subject: Re: [TUHS] man Macro Package and pdfmark > > That's my beef with texinfo; there was already > an existing functional system and rather than making some improvements a new > incompatible universe was created. Actually there wasn't a truly functional documentation system at the time -- or at least it didn't reach far enough. I.e. there was no open-source [nt]roff compatible program at the time, and the mainly available proprietary one produced (for quality printing purposes) only very convoluted hard-coded output for a quite esoteric and rare piece of equipment. AT&T's public attempt to solve this (ditroff) just added more cost and arguably less availability. Groff didn't arrive until 1990, and as remarkable as it was, it was unfortunately written in C++ (which dissuaded many for a long time). (Henry Spencer's "awf" (nroff in Awk) also came out in 1990, but besides being also too late it was more of a toy; and Chris Lewis' PSroff, also from just before 1990, only solved part of the problem.) Texinfo was a legitimate attempt to solve the problem of missing tools, and at the same time and tried (whether in vain or not) to improve on what were rather widely believed to be major technical and cultural and availability deficiencies in existing tools. Personally I still mostly use Lout these days. :-) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From arnold at skeeve.com Tue Feb 18 17:45:11 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 18 Feb 2020 00:45:11 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <202002180745.01I7jBeJ007975@freefriends.org> "Greg A. Woods" wrote: > Texinfo was a legitimate attempt to solve the problem of missing tools, > and at the same time and tried (whether in vain or not) to improve on > what were rather widely believed to be major technical and cultural and > availability deficiencies in existing tools. Well said. The markup language was clearly inspired by Scribe, which was quite popular in Academia (at least) at the time. As a *markup language*, I personally find it superior to anything else currently in use, but that's a whole different discussion that on TUHS inevitably degenerates into the current spate of ranting, so I won't start on it. > Personally I still mostly use Lout these days. :-) Wow. Is that still maintained? Arnold From jsteve at superglobalmegacorp.com Tue Feb 18 18:01:56 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 Feb 2020 08:01:56 +0000 (UTC) Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> Message-ID: <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> It's the CMU micro kernel.  The hybrid "2.6" lived on in NeXTSTEP, and OPENSTEP, with various upgrades to bring it up to OS X.  The RT as I understand it was a research machine, hence the BSD ports, and Mach port.  What is interesting the more I dig around is that there was ROMP coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD on the card.  Peripheral IO was done on the x86 side.  If RT's are rare, I can't imagine how impossible it would be to get one of those cards!  The BSD assembler and linker source is in the archives too, no doubt it'll help someone make a RT emulator.  Get Outlook for Android On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" wrote: Can you clarify what is Mach in this archive if I have a gap in my knowledge? I didn’t know the VRM had any direct relationship to Mach Regards,Kevin On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens wrote: Interesting stuff!  And another version of Mach is buried in there.  So the 4 csrg cd set may have updates to the romp support as it's an older version of the 5.1 kernel from 89...  Not that think there is any Mach romp users.  Get Outlook for Android From: TUHS on behalf of Charles H Sauer Sent: Tuesday, February 18, 2020, 5:51 a.m. To: TUHS Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things that I should have known (or knew and forgot?) while I was at IBM. http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Tue Feb 18 18:04:45 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 18 Feb 2020 01:04:45 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> Message-ID: I’m asking exactly where the Mach is in the linked archive. VRM, AIX or AOS? Can you support this with a reference for my own documentation On Tue, Feb 18, 2020 at 1:02 AM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > It's the CMU micro kernel. The hybrid "2.6" lived on in NeXTSTEP, and > OPENSTEP, with various upgrades to bring it up to OS X. > > The RT as I understand it was a research machine, hence the BSD ports, and > Mach port. > > What is interesting the more I dig around is that there was ROMP > coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD > on the card. Peripheral IO was done on the x86 side. > > If RT's are rare, I can't imagine how impossible it would be to get one of > those cards! > > The BSD assembler and linker source is in the archives too, no doubt it'll > help someone make a RT emulator. > > Get Outlook for Android > > > > On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" < > kevin.bowling at kev009.com> wrote: > > Can you clarify what is Mach in this archive if I have a gap in my >> knowledge? I didn’t know the VRM had any direct relationship to Mach >> >> Regards, >> Kevin >> >> On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens < >> jsteve at superglobalmegacorp.com> wrote: >> >>> Interesting stuff! And another version of Mach is buried in there. >>> >>> So the 4 csrg cd set may have updates to the romp support as it's an >>> older version of the 5.1 kernel from 89... Not that think there is any >>> Mach romp users. >>> >>> Get Outlook for Android >>> >>> ------------------------------ >>> *From:* TUHS on behalf of Charles H >>> Sauer >>> *Sent:* Tuesday, February 18, 2020, 5:51 a.m. >>> *To:* TUHS >>> *Subject:* [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions >>> >>> The Bitsavers' RSS feed ( >>> http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed >>> to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last >>> week or so. I've only sampled a few items, but discovered a few things that >>> I should have known (or knew and forgot?) while I was at IBM. >>> http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 >>> e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ >>> Facebook/Google/Skype/Twitter >>> : >>> CharlesHSauer >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Tue Feb 18 21:22:25 2020 From: rdm at cfcl.com (Rich Morin) Date: Tue, 18 Feb 2020 03:22:25 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: Ahem. Back in the 80's, I used both nroff and troff a fair amount. For example, Vicki Brown and I used nroff, in combination with an IBM I/O Selectric (Datel 30) to print most of her master's thesis. I also used troff to typeset several books for Prime Time Freeware. Mostly, I used pre-existing macro packages, but sometimes I had to dive down to the bare metal. It all worked, and was quite flexible, but I really don't miss it for adding docs to software projects. Lately, I've been using the built-in documentation tools for Elixir, a functional programming language based on the Erlang VM and a lot of Ruby syntax. I'm pleased to say that it's really quite pleasant. I create multi-line "attributes" using macros such as @doc. These are encoded using Markdown, which isn't perfect but seems adequate. The results are converted into both HTML pages and interactive help text, with automagical indexing. I'm able to create "doctests" by embedding IEx (Interactive Elixir) examples, eg: iex> 2 + 2 4 These get tested automagically, providing a modicum of reliability to the documentation. Amusingly, I did something similar years ago, extracting C code from the SYNOPSIS sections of Apple's man pages. This let me find and report a few docubugs... -r From aek at bitsavers.org Tue Feb 18 21:31:32 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 18 Feb 2020 03:31:32 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> Message-ID: <2d78c2c3-e99e-9a80-83a3-169112d9db9e@bitsavers.org> On 2/18/20 12:01 AM, Jason Stevens wrote: > If RT's are rare, I can't imagine how impossible it would be to get one of those cards! A complete 6152 Crossbow just sold on ebay for $500. Someone got a great deal. I just couldn't afford it or another project right now. I did pick up two EACPUs and FPA boards to put in my 6150 and 6151 https://www.ebay.com/itm/IBM-6152-6152-022-ACADEMIC-SYSTEM-RT-PC-80286-CROSSBOW-MICROCHANNEL-MCA-PS-2/143528500087 From arnold at skeeve.com Tue Feb 18 22:28:01 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 18 Feb 2020 05:28:01 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <202002181228.01ICS1pj020951@freefriends.org> Rich Morin wrote: > Lately, I've been using the built-in documentation tools for Elixir, > a functional programming language based on the Erlang VM and a lot > of Ruby syntax. I'm pleased to say that it's really quite pleasant. > > I create multi-line "attributes" using macros such as @doc. These > are encoded using Markdown, which isn't perfect but seems adequate. > The results are converted into both HTML pages and interactive help > text, with automagical indexing. This sounds something like a poor man's version of Literate Programming, invented by Donald Knuth for TeX et al. That's another technology that I happen to like personally, but which never became mainstream. More's the pity (IMHO). (I do know about Doug's review of DEK's program in the Programming Pearls column. I think the problems there were not with Lit Prog itself, but with how Knuth programs. My own take on Literate Programming can be seen at https://github.com/arnoldrobbins/texiwebjr.) Yes, probably getting off topic, too. Arnold From jsteve at superglobalmegacorp.com Tue Feb 18 22:29:37 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 Feb 2020 12:29:37 +0000 (UTC) Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> Message-ID: <25E62EB5E090E7CB.36bb1263-cdbe-4b01-9db9-3fed23e83b02@mail.outlook.com> Oh sure!  I'm having to use my phone...   It's the combined sources here:http://bitsavers.trailing-edge.com/bits/IBM/RT/rt_bsd44/ doc  mk jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4$ pwd /home/jsteve/rt_bsd4/src/sys/.local/mach2.4 jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk/conf$ cat vers*6951X So 5.1x edit 69 jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk$ more CHANGELOGHISTORY 17-May-88 David Golub (dbg) at Carnegie-Mellon University XM21:        David Black completely rewrote the accurate timing code        (which is now implemented on all machines) and the priority        and scheduling algorithms. The system now correctly reports        cpu_usage per thread. The all file has this before i386 was added.  So it's an older v2 than what is on the CSRG CD, but not as old as the VAX '86 stuff.  It seems to be March 11 1989, although that could be when this was either archived or ported..  I guess they didn't exactly sync to a public kernel tree all that often.  On Tue, Feb 18, 2020 at 4:05 PM +0800, "Kevin Bowling" wrote: I’m asking exactly where the Mach is in the linked archive. VRM, AIX or AOS? Can you support this with a reference for my own documentation On Tue, Feb 18, 2020 at 1:02 AM Jason Stevens wrote: It's the CMU micro kernel.  The hybrid "2.6" lived on in NeXTSTEP, and OPENSTEP, with various upgrades to bring it up to OS X.  The RT as I understand it was a research machine, hence the BSD ports, and Mach port.  What is interesting the more I dig around is that there was ROMP coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD on the card.  Peripheral IO was done on the x86 side.  If RT's are rare, I can't imagine how impossible it would be to get one of those cards!  The BSD assembler and linker source is in the archives too, no doubt it'll help someone make a RT emulator.  Get Outlook for Android On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" wrote: Can you clarify what is Mach in this archive if I have a gap in my knowledge? I didn’t know the VRM had any direct relationship to Mach Regards,Kevin On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens wrote: Interesting stuff!  And another version of Mach is buried in there.  So the 4 csrg cd set may have updates to the romp support as it's an older version of the 5.1 kernel from 89...  Not that think there is any Mach romp users.  Get Outlook for Android From: TUHS on behalf of Charles H Sauer Sent: Tuesday, February 18, 2020, 5:51 a.m. To: TUHS Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things that I should have known (or knew and forgot?) while I was at IBM. http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Tue Feb 18 22:49:25 2020 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Tue, 18 Feb 2020 12:49:25 +0000 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002181228.01ICS1pj020951@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181228.01ICS1pj020951@freefriends.org> Message-ID: <45c6e7a7-70de-a69e-9635-b3c51229dc49@andrewnesbit.org> On 18/02/2020 12:28, arnold at skeeve.com wrote: > (I do know about Doug's review of DEK's program in the Programming > Pearls column. I think the problems there were not with Lit Prog > itself, but with how Knuth programs. What are the issues with how Knuth programs? Honestly I've never heard any criticisms before. > My own take on Literate Programming > can be seen at https://github.com/arnoldrobbins/texiwebjr.) This looks _really_ cool. I am looking forward to reading this in detail and hopefully experimenting with it. > Yes, probably getting off topic, too. Really? But then how about this? David R. Hanson, "C Interfaces and Implementations: Techniques for Creating Reusable Software", Addison-Wesley Professional, 1996. Online at https://www.informit.com/store/c-interfaces-and-implementations-techniques-for-creating-9780201498417 . It is not only one of the best books about programming I've ever read. It's also one of the finest examples of literate programming I've seen. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From kevin.bowling at kev009.com Tue Feb 18 23:01:49 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 18 Feb 2020 06:01:49 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.36bb1263-cdbe-4b01-9db9-3fed23e83b02@mail.outlook.com> References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> <25E62EB5E090E7CB.b51df4ee-f07b-4926-bf33-ba7bfcd485d9@mail.outlook.com> <25E62EB5E090E7CB.36bb1263-cdbe-4b01-9db9-3fed23e83b02@mail.outlook.com> Message-ID: Thanks for clarifying. I will reassert that the three pieces of systems software I mentioned (VRM, AIX2, AOS) are not Mach in any way I know about. AOS may have some generic cross pollination, it’d be whatever was going on at CSRG also for non-RT (4.2-4.3?) BSD platforms at the time of checkout. Kirk or Warner may be able to elucidate if provided the date and some reference material from AOS or I can do some original research. Most distinctly and important: VRM is not in any way Mach, it was its own bespoke microkernel. The microkernel would have been the most “Mach” part of Mach research, so this makes the VRM concept even more unique and enjoyable to me being so different and ambitious. Therefore I don’t think it is particularly correct to say any of VRM, AIX, AOS software is Mach without its ukernel. What you linked is a very late port (late 1990s) of a hybrid of 4.3 and 4.4 BSD (late meaning in the time when Net, Free, and Open had long taken over from CSRG BSD). I will quote a Twitter communication I had with Miod Vallat in the past: “Also it's not really 4.4. It's a mix of 4.3BSD-Reno plus the 4.4 VFS layer and new system calls. It still uses the 4.3, pre-Mach, VM system, hence no mmap(2).” What Miod means by “pre-Mach” above: 4.4 BSD adopted the kernel memory subsystem of Mach into the existing BSD monolithic kernel. Not any of the ukernel or things like Mach IPC. Not trying to be overly pedantic with you just trying to keep the records straight since these machines are one of my keen interests and I welcome new information on them. Regards, Kevin On Tue, Feb 18, 2020 at 5:30 AM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > Oh sure! > > I'm having to use my phone... > > It's the combined sources here: > http://bitsavers.trailing-edge.com/bits/IBM/RT/rt_bsd44/ > > doc mk > jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4$ pwd > /home/jsteve/rt_bsd4/src/sys/.local/mach2.4 > > jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk/conf$ cat vers* > 69 > 5 > 1 > X > > So 5.1x edit 69 > > jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk$ more CHANGELOG > HISTORY > 17-May-88 David Golub (dbg) at Carnegie-Mellon University > XM21: > David Black completely rewrote the accurate timing code > (which is now implemented on all machines) and the priority > and scheduling algorithms. The system now correctly reports > cpu_usage per thread. > > > > The all file has this before i386 was added. > > So it's an older v2 than what is on the CSRG CD, but not as old as the VAX > '86 stuff. > > It seems to be March 11 1989, although that could be when this was either > archived or ported.. I guess they didn't exactly sync to a public kernel > tree all that often. > > > > On Tue, Feb 18, 2020 at 4:05 PM +0800, "Kevin Bowling" < > kevin.bowling at kev009.com> wrote: > > I’m asking exactly where the Mach is in the linked archive. VRM, AIX or >> AOS? Can you support this with a reference for my own documentation >> >> On Tue, Feb 18, 2020 at 1:02 AM Jason Stevens < >> jsteve at superglobalmegacorp.com> wrote: >> >>> It's the CMU micro kernel. The hybrid "2.6" lived on in NeXTSTEP, and >>> OPENSTEP, with various upgrades to bring it up to OS X. >>> >>> The RT as I understand it was a research machine, hence the BSD ports, >>> and Mach port. >>> >>> What is interesting the more I dig around is that there was ROMP >>> coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD >>> on the card. Peripheral IO was done on the x86 side. >>> >>> If RT's are rare, I can't imagine how impossible it would be to get one >>> of those cards! >>> >>> The BSD assembler and linker source is in the archives too, no doubt >>> it'll help someone make a RT emulator. >>> >>> Get Outlook for Android >>> >>> >>> >>> On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" < >>> kevin.bowling at kev009.com> wrote: >>> >>> Can you clarify what is Mach in this archive if I have a gap in my >>>> knowledge? I didn’t know the VRM had any direct relationship to Mach >>>> >>>> Regards, >>>> Kevin >>>> >>>> On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens < >>>> jsteve at superglobalmegacorp.com> wrote: >>>> >>>>> Interesting stuff! And another version of Mach is buried in there. >>>>> >>>>> So the 4 csrg cd set may have updates to the romp support as it's an >>>>> older version of the 5.1 kernel from 89... Not that think there is any >>>>> Mach romp users. >>>>> >>>>> Get Outlook for Android >>>>> >>>>> ------------------------------ >>>>> *From:* TUHS on behalf of Charles H >>>>> Sauer >>>>> *Sent:* Tuesday, February 18, 2020, 5:51 a.m. >>>>> *To:* TUHS >>>>> *Subject:* [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions >>>>> >>>>> The Bitsavers' RSS feed ( >>>>> http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed >>>>> to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last >>>>> week or so. I've only sampled a few items, but discovered a few things that >>>>> I should have known (or knew and forgot?) while I was at IBM. >>>>> http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 >>>>> e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ >>>>> Facebook/Google/Skype/Twitter >>>>> : >>>>> CharlesHSauer >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at DonHopkins.com Tue Feb 18 23:13:10 2020 From: don at DonHopkins.com (Don Hopkins) Date: Tue, 18 Feb 2020 14:13:10 +0100 Subject: [TUHS] man Macro Package and pdfmark Message-ID: <71ADA7B8-E2C6-4838-A77F-5AFEC8021EB9@gmail.com> Arnold wrote: > Well said. The markup language was clearly inspired by Scribe, which > was quite popular in Academia (at least) at the time. > > As a *markup language*, I personally find it superior to anything > else currently in use, but that's a whole different discussion that > on TUHS inevitably degenerates into the current spate of ranting, > so I won't start on it. So in other words, you mean: @Flame(Off) -Don From arnold at skeeve.com Tue Feb 18 23:23:46 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 18 Feb 2020 06:23:46 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <45c6e7a7-70de-a69e-9635-b3c51229dc49@andrewnesbit.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181228.01ICS1pj020951@freefriends.org> <45c6e7a7-70de-a69e-9635-b3c51229dc49@andrewnesbit.org> Message-ID: <202002181323.01IDNkRO022729@freefriends.org> "U'll Be King of the Stars" wrote: > On 18/02/2020 12:28, arnold at skeeve.com wrote: > > (I do know about Doug's review of DEK's program in the Programming > > Pearls column. I think the problems there were not with Lit Prog > > itself, but with how Knuth programs. > > What are the issues with how Knuth programs? > > Honestly I've never heard any criticisms before. This all dates from the mid-1980s. It's reproduced in Knuth's book "Literate Progrmming", which you can find on Amazon and is well worth owning. That book has some other gems, including his famous paper "Structure Programming With goto Statements". The original Programming Pearls column was published in CACM. Google helps find it: https://dl.acm.org/doi/10.1145/5948.315654 > > My own take on Literate Programming > > can be seen at https://github.com/arnoldrobbins/texiwebjr.) > > This looks _really_ cool. I am looking forward to reading this in > detail and hopefully experimenting with it. Thanks! > David R. Hanson, "C Interfaces and Implementations: Techniques for > Creating Reusable Software", Addison-Wesley Professional, 1996. Online > at > https://www.informit.com/store/c-interfaces-and-implementations-techniques-for-creating-9780201498417 > . I have that book. There's also the LCC C compiler book which was done in a literate style. Arnold From jsteve at superglobalmegacorp.com Tue Feb 18 23:28:54 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 Feb 2020 13:28:54 +0000 (UTC) Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions Message-ID: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> I was more interested in the "Mach" kernel itself as I've only recently been able to get it to boot up from sources for the i386.  I hadn't looked into the other aos/vrm stuff.  But that is interesting, a 4.3 with the vfs.  In hind sight maybe Mach wasn't so bad with its messaging and threads, along with multiprocessor support.. Its what we all were eventually desiring anyway.  One thing is for sure, multiple GHz machines sure make it a lot easier to use, these days.  I'd gotten lucky with Mach as the platform code is really modular and even a monkey like me banging on a keyboard of an existing Mach 386 machine was able to get the latter source running under the older platform code.  Shame Mach 3 seems to have broken all the fun stuff or requires real effort and understanding... Things I lack.  But I was really surprised about the coprocessor cards..  I wonder what other interesting things are in there.  Or how hard it is to hammer 386 BSD into aos "sort of a 4.3 Tahoe ++"  From: Kevin Bowling Sent: Tuesday, February 18, 2020, 9:02 p.m. To: Jason Stevens Cc: Charles H Sauer; TUHS Subject: Re: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions Thanks for clarifying.  I will reassert that the three pieces of systems software I mentioned (VRM, AIX2, AOS) are not Mach in any way I know about.  AOS may have some generic cross pollination, it’d be whatever was going on at CSRG also for non-RT (4.2-4.3?) BSD platforms at the time of checkout. Kirk or Warner may be able to elucidate if provided the date and some reference material from AOS or I can do some original research. Most distinctly and important:  VRM is not in any way Mach, it was its own bespoke microkernel.  The microkernel would have been the most “Mach” part of Mach research, so this makes the VRM concept even more unique and enjoyable to me being so different and ambitious.  Therefore I don’t think it is particularly correct to say any of VRM, AIX, AOS software is Mach without its ukernel. What you linked is a very late port (late 1990s) of a hybrid of 4.3 and 4.4 BSD (late meaning in the time when Net, Free, and Open had long taken over from CSRG BSD).  I will quote a Twitter communication I had with Miod Vallat in the past:“Also it's not really 4.4. It's a mix of 4.3BSD-Reno plus the 4.4 VFS layer and new system calls. It still uses the 4.3, pre-Mach, VM system, hence no mmap(2).” What Miod means by “pre-Mach” above: 4.4 BSD adopted the kernel memory subsystem of Mach into the existing BSD monolithic kernel. Not any of the ukernel or things like Mach IPC. Not trying to be overly pedantic with you just trying to keep the records straight since these machines are one of my keen interests and I welcome new information on them.  Regards,Kevin On Tue, Feb 18, 2020 at 5:30 AM Jason Stevens wrote: Oh sure!  I'm having to use my phone...   It's the combined sources here:http://bitsavers.trailing-edge.com/bits/IBM/RT/rt_bsd44/ doc  mk jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4$ pwd /home/jsteve/rt_bsd4/src/sys/.local/mach2.4 jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk/conf$ cat vers*6951X So 5.1x edit 69 jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk$ more CHANGELOGHISTORY 17-May-88 David Golub (dbg) at Carnegie-Mellon University XM21:        David Black completely rewrote the accurate timing code        (which is now implemented on all machines) and the priority        and scheduling algorithms. The system now correctly reports        cpu_usage per thread. The all file has this before i386 was added.  So it's an older v2 than what is on the CSRG CD, but not as old as the VAX '86 stuff.  It seems to be March 11 1989, although that could be when this was either archived or ported..  I guess they didn't exactly sync to a public kernel tree all that often.  On Tue, Feb 18, 2020 at 4:05 PM +0800, "Kevin Bowling" wrote: I’m asking exactly where the Mach is in the linked archive. VRM, AIX or AOS? Can you support this with a reference for my own documentation On Tue, Feb 18, 2020 at 1:02 AM Jason Stevens wrote: It's the CMU micro kernel.  The hybrid "2.6" lived on in NeXTSTEP, and OPENSTEP, with various upgrades to bring it up to OS X.  The RT as I understand it was a research machine, hence the BSD ports, and Mach port.  What is interesting the more I dig around is that there was ROMP coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD on the card.  Peripheral IO was done on the x86 side.  If RT's are rare, I can't imagine how impossible it would be to get one of those cards!  The BSD assembler and linker source is in the archives too, no doubt it'll help someone make a RT emulator.  Get Outlook for Android On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" wrote: Can you clarify what is Mach in this archive if I have a gap in my knowledge? I didn’t know the VRM had any direct relationship to Mach Regards,Kevin On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens wrote: Interesting stuff!  And another version of Mach is buried in there.  So the 4 csrg cd set may have updates to the romp support as it's an older version of the 5.1 kernel from 89...  Not that think there is any Mach romp users.  Get Outlook for Android From: TUHS on behalf of Charles H Sauer Sent: Tuesday, February 18, 2020, 5:51 a.m. To: TUHS Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions The Bitsavers' RSS feed (http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in the last week or so. I've only sampled a few items, but discovered a few things that I should have known (or knew and forgot?) while I was at IBM. http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Tue Feb 18 23:39:59 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 18 Feb 2020 05:39:59 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> Message-ID: <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> On 2/18/20 5:28 AM, Jason Stevens wrote: > But I was really surprised about the coprocessor cards.. I wonder what other interesting things are in there. Or how hard it is to hammer > 386 BSD into aos "sort of a 4.3 Tahoe ++" I haven't dug into finding this yet, but wasn't there an RT netBSD? I've been interested in Mach since messing with MacMach on a IIfx in the early 90's Has there been any collective effort trying to recover RIG/Mach code? It all seems very fragmented. From kevin.bowling at kev009.com Tue Feb 18 23:41:18 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 18 Feb 2020 06:41:18 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> Message-ID: Well, it’s not particularly hard to find a Mach system today. The fruit company makes computers and mobile phones with it. Steve Jobs enamor for Avie Tevanian is well chronicled in the common biographies. The problem with Mach is their ukernel implementation was pretty shit while the ideas were sound. MacOS runs like an old dog to this day on anything remotely system% intensive (like say a network server). IBM abandoned the idea of any ukernel with AIX3 for RISC/6000.. Charlie may be able to add commentary on that but it was almost certainly for performance which was paramount in the workstation wars and RS6K had an front runner opening. The idea of small TCBs and IPC has really been perfected in L4 kernels; seL4 in particular is one of the most interesting pieces of systems software today. Fruit company uses a different older L4 for their security coprocessors and had a Darwin port for L4 at one point called Darbat. Regards, Kevin On Tue, Feb 18, 2020 at 6:29 AM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > I was more interested in the "Mach" kernel itself as I've only recently > been able to get it to boot up from sources for the i386. > > I hadn't looked into the other aos/vrm stuff. But that is interesting, a > 4.3 with the vfs. > > In hind sight maybe Mach wasn't so bad with its messaging and threads, > along with multiprocessor support.. Its what we all were eventually > desiring anyway. > > One thing is for sure, multiple GHz machines sure make it a lot easier to > use, these days. > > I'd gotten lucky with Mach as the platform code is really modular and even > a monkey like me banging on a keyboard of an existing Mach 386 machine was > able to get the latter source running under the older platform code. Shame > Mach 3 seems to have broken all the fun stuff or requires real effort and > understanding... Things I lack. > > But I was really surprised about the coprocessor cards.. I wonder what > other interesting things are in there. Or how hard it is to hammer 386 BSD > into aos "sort of a 4.3 Tahoe ++" > > ------------------------------ > *From:* Kevin Bowling > *Sent:* Tuesday, February 18, 2020, 9:02 p.m. > *To:* Jason Stevens > *Cc:* Charles H Sauer; TUHS > *Subject:* Re: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions > > Thanks for clarifying. I will reassert that the three pieces of systems > software I mentioned (VRM, AIX2, AOS) are not Mach in any way I know > about. AOS may have some generic cross pollination, it’d be whatever was > going on at CSRG also for non-RT (4.2-4.3?) BSD platforms at the time of > checkout. Kirk or Warner may be able to elucidate if provided the date and > some reference material from AOS or I can do some original research. > > Most distinctly and important: VRM is not in any way Mach, it was its own > bespoke microkernel. The microkernel would have been the most “Mach” part > of Mach research, so this makes the VRM concept even more unique and > enjoyable to me being so different and ambitious. Therefore I don’t think > it is particularly correct to say any of VRM, AIX, AOS software is Mach > without its ukernel. > > What you linked is a very late port (late 1990s) of a hybrid of 4.3 and > 4.4 BSD (late meaning in the time when Net, Free, and Open had long taken > over from CSRG BSD). I will quote a Twitter communication I had with Miod > Vallat in the past: > “Also it's not really 4.4. It's a mix of 4.3BSD-Reno plus the 4.4 VFS > layer and new system calls. It still uses the 4.3, pre-Mach, VM system, > hence no mmap(2).” > > What Miod means by “pre-Mach” above: 4.4 BSD adopted the kernel memory > subsystem of Mach into the existing BSD monolithic kernel. Not any of the > ukernel or things like Mach IPC. > > Not trying to be overly pedantic with you just trying to keep the records > straight since these machines are one of my keen interests and I welcome > new information on them. > > Regards, > Kevin > > On Tue, Feb 18, 2020 at 5:30 AM Jason Stevens < > jsteve at superglobalmegacorp.com> wrote: > >> Oh sure! >> >> I'm having to use my phone... >> >> It's the combined sources here: >> http://bitsavers.trailing-edge.com/bits/IBM/RT/rt_bsd44/ >> >> doc mk >> jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4$ pwd >> /home/jsteve/rt_bsd4/src/sys/.local/mach2.4 >> >> jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk/conf$ cat vers* >> 69 >> 5 >> 1 >> X >> >> So 5.1x edit 69 >> >> jsteve at localhost:~/rt_bsd4/src/sys/.local/mach2.4/mk$ more CHANGELOG >> HISTORY >> 17-May-88 David Golub (dbg) at Carnegie-Mellon University >> XM21: >> David Black completely rewrote the accurate timing code >> (which is now implemented on all machines) and the priority >> and scheduling algorithms. The system now correctly reports >> cpu_usage per thread. >> >> >> >> The all file has this before i386 was added. >> >> So it's an older v2 than what is on the CSRG CD, but not as old as the >> VAX '86 stuff. >> >> It seems to be March 11 1989, although that could be when this was either >> archived or ported.. I guess they didn't exactly sync to a public kernel >> tree all that often. >> >> >> >> On Tue, Feb 18, 2020 at 4:05 PM +0800, "Kevin Bowling" < >> kevin.bowling at kev009.com> wrote: >> >> I’m asking exactly where the Mach is in the linked archive. VRM, AIX or >>> AOS? Can you support this with a reference for my own documentation >>> >>> On Tue, Feb 18, 2020 at 1:02 AM Jason Stevens < >>> jsteve at superglobalmegacorp.com> wrote: >>> >>>> It's the CMU micro kernel. The hybrid "2.6" lived on in NeXTSTEP, and >>>> OPENSTEP, with various upgrades to bring it up to OS X. >>>> >>>> The RT as I understand it was a research machine, hence the BSD ports, >>>> and Mach port. >>>> >>>> What is interesting the more I dig around is that there was ROMP >>>> coprocoessor cards, and an OS/2 and DOS monitor program to let you boot BSD >>>> on the card. Peripheral IO was done on the x86 side. >>>> >>>> If RT's are rare, I can't imagine how impossible it would be to get one >>>> of those cards! >>>> >>>> The BSD assembler and linker source is in the archives too, no doubt >>>> it'll help someone make a RT emulator. >>>> >>>> Get Outlook for Android >>>> >>>> >>>> >>>> On Tue, Feb 18, 2020 at 12:54 PM +0800, "Kevin Bowling" < >>>> kevin.bowling at kev009.com> wrote: >>>> >>>> Can you clarify what is Mach in this archive if I have a gap in my >>>>> knowledge? I didn’t know the VRM had any direct relationship to Mach >>>>> >>>>> Regards, >>>>> Kevin >>>>> >>>>> On Mon, Feb 17, 2020 at 9:43 PM Jason Stevens < >>>>> jsteve at superglobalmegacorp.com> wrote: >>>>> >>>>>> Interesting stuff! And another version of Mach is buried in there. >>>>>> >>>>>> So the 4 csrg cd set may have updates to the romp support as it's an >>>>>> older version of the 5.1 kernel from 89... Not that think there is any >>>>>> Mach romp users. >>>>>> >>>>>> Get Outlook for Android >>>>>> >>>>>> ------------------------------ >>>>>> *From:* TUHS on behalf of Charles H >>>>>> Sauer >>>>>> *Sent:* Tuesday, February 18, 2020, 5:51 a.m. >>>>>> *To:* TUHS >>>>>> *Subject:* [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions >>>>>> >>>>>> The Bitsavers' RSS feed ( >>>>>> http://user.xmission.com/~legalize/vintage/bitsavers-bits.xml) >>>>>> seemed to me to be dominated by RT, AIX, AOS (BSD for RT), etc. stuff in >>>>>> the last week or so. I've only sampled a few items, but discovered a few >>>>>> things that I should have known (or knew and forgot?) while I was at IBM. >>>>>> http://www.bitsavers.org/pdf/ibm/pc/rt/ -- voice: +1.512.784.7526 >>>>>> e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ >>>>>> Facebook/Google/Skype/Twitter >>>>>> : >>>>>> CharlesHSauer >>>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 01:11:45 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 10:11:45 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: hrrmpt... On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods wrote: > At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart > wrote: > Subject: Re: [TUHS] man Macro Package and pdfmark > > > > That's my beef with texinfo; there was already > > an existing functional system and rather than making some improvements a > new > > incompatible universe was created. > > Actually there wasn't a truly functional documentation system at the > time -- or at least it didn't reach far enough. > > I.e. there was no open-source [nt]roff compatible program at the time, > and the mainly available proprietary one produced (for quality printing > purposes) only very convoluted hard-coded output for a quite esoteric > and rare piece of equipment. AT&T's public attempt to solve this > (ditroff) just added more cost and arguably less availability. > ditroff was always >>open source<< and any licensee could get it and see it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. AT&T licensed it with a small set of fees. IIRC $1K for the first CPU, an $50 for each and redistribution license was $10K and $5/system. The other issue is you really needed Adobe's transcript package to effectively use it on your Apple Laserwriter and other later PS based printers, as most people lacked actual typesetters. Please remember that >>all<< the Universities with $150 AT&T licensed and a BSD license, had basic troff on their Vaxen with any BSD systems they had. So they all had it for 'free' (and open). I'll accept Larry's previous notes that not all people in those places had access to the sources, but everyone should have had access to the binaries that came with the system. For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the like, it is possible it was different. The fact is I know Masscomp supplied ditroff on all systems and just ate the $5 license fee. We also license transcript from Adobe and included that. My memory is that was just a one-time charge and no redistribution. I'm not sure what Sun did, but I think they supplied the BSD troff, vcat and the like (Larry may know for sure). I'm pretty sure HP supplied at least the BSD/vcat family; but they have updated to ditroff. I've forgotten what DEC settled on. By the time of Tru64 it was ditroff on the system, but with Ultrix it may have been you got the troff/vcat off the BSD tape had their was a fee for the ditroff/transcript package. So the basic facts are is that in the Unix ecosystem, the nroff/troff ecosystem was very much around before 1990's groff. Frankly, the biggest thing it did was enabled Linux to have a version of ditroff. I know in my own case, I would (horrors) carry the sources with me for the AT&T package and Transcript for early PC based BSD's. The truth is both packages were (and are) easily findable in dark corners of the Internet. I also request, that we refrain from the seemingly yearly Tex vs. troff war. It's about as productive as the C vs Pascal or C++ vs Java discussions. This thread started as Doug's observation about wanting man pages and issues with Gnu's texinfo scheme. It turns out man was based on the [nr]roff family. The reality is that any document compiler >>could<< have been used. If something other than the roff family was used to create man pages, that would be a different discussion. ... and I like my lawn as it is ... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Feb 19 01:28:50 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 18 Feb 2020 08:28:50 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <202002181528.01IFSogM030831@freefriends.org> Clem Cole wrote: > ditroff was always >>open source<< and any licensee could get it and see > it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. I don't like your use of "open source"; it is way out of skew with how it's used today. > AT&T licensed it with a small set of fees. IIRC $1K for the first CPU, an > $50 for each and redistribution license was $10K and $5/system. That was very painful for universities and/or small businesses. Sure Sun and Masscomp could afford that. Your average computing center / computer science department / startup would have to think twice or thrice. Per CPU licensing was particularly painful if you had a bunch of workstations. Arnold From lm at mcvoy.com Wed Feb 19 01:36:38 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 18 Feb 2020 07:36:38 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002181528.01IFSogM030831@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: <20200218153638.GB19116@mcvoy.com> On Tue, Feb 18, 2020 at 08:28:50AM -0700, arnold at skeeve.com wrote: > Clem Cole wrote: > > > ditroff was always >>open source<< and any licensee could get it and see > > it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. > > I don't like your use of "open source"; it is way out of skew with > how it's used today. > > > AT&T licensed it with a small set of fees. IIRC $1K for the first CPU, an > > $50 for each and redistribution license was $10K and $5/system. > > That was very painful for universities and/or small businesses. Sure > Sun and Masscomp could afford that. Your average computing center / > computer science department / startup would have to think twice or thrice. > > Per CPU licensing was particularly painful if you had a bunch > of workstations. Yeah, Clem sort of has a blind spot on licensing. It's weird because I agree with him on almost everything, it's sort of spooky how much we agree. My guess is that Clem was always at a University or a job where the fees were mouse nuts and so it appeared to him that things just worked. If you were a grad student like me, who wanted roff on a PC, it was very different. And I suspect Clem has always been seen as one of the chosen few who get logins on the machines with source. I was a nobody and had to fight hard to get a login, I got it, but not until I was a junior. From usotsuki at buric.co Wed Feb 19 01:43:06 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 18 Feb 2020 10:43:06 -0500 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002181528.01IFSogM030831@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: On Tue, 18 Feb 2020, arnold at skeeve.com wrote: > I don't like your use of "open source"; it is way out of skew with > how it's used today. Wasn't it always *intended* to mean the same thing as "Free Software" ? (I use the phrase "freedom-compliant software" to be unambiguous, but it's a bit unwieldy.) -uso. From clemc at ccc.com Wed Feb 19 01:48:28 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 10:48:28 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002181528.01IFSogM030831@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: The term OSS to mean free as in beer is just not correct. The sources were always free a as in available to be read but just like today they are licensed. Ad for Universities. The point is if you had a vax you had troff as a miniimun an $50 for ditroff was not a hardship. If you had a binary workstation from DEC or Sun you got troff on the system and if you got a masscomp you got ditroff. The point is people had access to a working binary without spending any we real extra money - which was Jons point. The ecosystem under Unix was fine until the real a FOSS world which was when groff appears. On Tue, Feb 18, 2020 at 10:28 AM wrote: > Clem Cole wrote: > > > ditroff was always >>open source<< and any licensee could get it and see > > it. The problem you are suggesting is that it was not >>free<< i.e. > FOSS. > > I don't like your use of "open source"; it is way out of skew with > how it's used today. > > > AT&T licensed it with a small set of fees. IIRC $1K for the first CPU, > an > > $50 for each and redistribution license was $10K and $5/system. > > That was very painful for universities and/or small businesses. Sure > Sun and Masscomp could afford that. Your average computing center / > computer science department / startup would have to think twice or thrice. > > Per CPU licensing was particularly painful if you had a bunch > of workstations. > > Arnold > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 01:52:45 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 10:52:45 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: Yes and the term "open" was coined by the marketing folks in uniforum to describe the open interfaces and ability to see the sources (you might have pay a license fee). Or it was not free. Other people came later and missinterpreded the term. Clem On Tue, Feb 18, 2020 at 10:43 AM Steve Nickolas wrote: > On Tue, 18 Feb 2020, arnold at skeeve.com wrote: > > > I don't like your use of "open source"; it is way out of skew with > > how it's used today. > > Wasn't it always *intended* to mean the same thing as "Free Software" ? > > (I use the phrase "freedom-compliant software" to be unambiguous, but it's > a bit unwieldy.) > > -uso. > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Feb 19 02:02:32 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 18 Feb 2020 11:02:32 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: <846fcc9f-bd78-b990-cecd-21f8b6570231@case.edu> On 2/18/20 10:48 AM, Clem Cole wrote: > The term OSS to mean free as in beer is just not correct.   The sources > were always free a as in available to be read but just like today they are > licensed. I'm not sure that "open source" as a synonym for "source code available for purchase" is valid. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tytso at mit.edu Wed Feb 19 02:40:31 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 18 Feb 2020 11:40:31 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: <20200218164031.GA147128@mit.edu> On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote: > On Tue, 18 Feb 2020, arnold at skeeve.com wrote: > > > I don't like your use of "open source"; it is way out of skew with > > how it's used today. > > Wasn't it always *intended* to mean the same thing as "Free Software" ? No, although the differences in practice are small. "Free Software" was defined by Stallman as meeting his "Four Freedoms". Open Source(tm) was derived from the Debian Free Software Guidelines, and while the set of licenses which meet the "Free Software" definition and those that meet the "Open Source(tm) definition mostly identical, there are a few exceptions. I refer folks to the Wikipedia entry for more details: https://en.wikipedia.org/wiki/The_Free_Software_Definition It is true that the most of the people who use Open Source instead of Free Software are doing so mostly for branding reasons (e.g., Open Source is considered less likely to scare the suits), but technically they aren't the same. And it is certainly true that way AT&T distributed ditroff certainly isn't compliant with the Open Source Definition (OSD). Whether or not it meets Clem's "open source" (small o, small s), depends on his definition, which appears to be, "functionally, since everyone back then had an AT&T source license, we're all good". - Ted From henry.r.bent at gmail.com Wed Feb 19 02:47:56 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 18 Feb 2020 11:47:56 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: On Tue, Feb 18, 2020, 10:13 Clem Cole wrote: > > > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the > like, it is possible it was different. The fact is I know Masscomp > supplied ditroff on all systems and just ate the $5 license fee. We > also license transcript from Adobe and included that. My memory is that > was just a one-time charge and no redistribution. I'm not sure what Sun > did, but I think they supplied the BSD troff, vcat and the like (Larry may > know for sure). I'm pretty sure HP supplied at least the BSD/vcat family; > but they have updated to ditroff. I've forgotten what DEC settled on. By > the time of Tru64 it was ditroff on the system, but with Ultrix it may have > been you got the troff/vcat off the BSD tape had their was a fee for the > ditroff/transcript package. > Off the top of my head, SGI also did this. Man pages in the standard IRIX distribution were provided pre-formatted ("catman") and any sort of roff was a separately available, for extra $, product called Documenter's Workbench. I know that this was the case in IRIX 4 and 5 (early-mid '90s), not sure about earlier, and I believe that IRIX 6 finally rolled it into the standard distribution. The trouble was that if you had a package that provided standard man pages, you had no way to format them unless you were able to get a hold of groff or the like. Not an ideal situation. -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 19 02:28:59 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 18 Feb 2020 11:28:59 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <846fcc9f-bd78-b990-cecd-21f8b6570231@case.edu> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <846fcc9f-bd78-b990-cecd-21f8b6570231@case.edu> Message-ID: But that is how it was formed by the original commercial unix folks (which I was one). We talked about the open systems community. Look at some of the uniforum docs in the archives from the mid 1980s if you don't believe me. That is what was meant because we could not say Unix and at the term in the commercial community it was Unix vs proprietary systems aka VMS, MPE, Kronos et al. The context of the day that was exactly what we meant. That said, I'll grant you you words change meaning over time, but I was and do use the term in context of the original open systems community - which I was a founder. If you mean FOSS then say that, if you mean an open system with published interfaces and available sources, that by definition open source software. So please don't try tell me what we meant. Eric Raymond is probably the person where I started to see the warp of its meaning. That's why I always say FOSS when I mean free in the context of RMS. Also remember most of the current FOSS movement the code is very restrictioned in it's license. The difference is if you have to pay a fee for it and what you can do with the derivative works Fyi if you want to discuss free or not that discussion needs to move to COFF. This is certain a discussion from an old f*RTS perspective. On Tue, Feb 18, 2020 at 11:02 AM Chet Ramey wrote: > On 2/18/20 10:48 AM, Clem Cole wrote: > > The term OSS to mean free as in beer is just not correct. The sources > > were always free a as in available to be read but just like today they > are > > licensed. > > I'm not sure that "open source" as a synonym for "source code available > for purchase" is valid. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Wed Feb 19 03:49:23 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 18 Feb 2020 18:49:23 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: <88e4230a73cfa71c5afb33245cfa6f21@firemail.de> An HTML attachment was scrubbed... URL: From usotsuki at buric.co Wed Feb 19 04:39:22 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 18 Feb 2020 13:39:22 -0500 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200218164031.GA147128@mit.edu> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote: > On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote: >> On Tue, 18 Feb 2020, arnold at skeeve.com wrote: >> >>> I don't like your use of "open source"; it is way out of skew with >>> how it's used today. >> >> Wasn't it always *intended* to mean the same thing as "Free Software" ? > > No, although the differences in practice are small. "Free Software" > was defined by Stallman as meeting his "Four Freedoms". Open > Source(tm) was derived from the Debian Free Software Guidelines, and > while the set of licenses which meet the "Free Software" definition > and those that meet the "Open Source(tm) definition mostly identical, > there are a few exceptions. > > I refer folks to the Wikipedia entry for more details: > > https://en.wikipedia.org/wiki/The_Free_Software_Definition > > It is true that the most of the people who use Open Source instead of > Free Software are doing so mostly for branding reasons (e.g., Open > Source is considered less likely to scare the suits), but technically > they aren't the same. And it is certainly true that way AT&T > distributed ditroff certainly isn't compliant with the Open Source > Definition (OSD). > > Whether or not it meets Clem's "open source" (small o, small s), > depends on his definition, which appears to be, "functionally, since > everyone back then had an AT&T source license, we're all good". > > - Ted > I always understood "open source" to mean this: you have access to the code, you can share it, you can modify it, and any combination of the above (including commercial exploitation; basically a restatement of Stallman's freedoms in simpler words). As any phrase gets skewed to mean something other than it was intended, when most people say "open source", they seem to only mean what I call "source-available" - i.e., that there is *some* means by which a mere mortal can gain access to the source, but there is no guarantee that they can actually DO anything with the source without getting sued into oblivion. I usually say if the code doesn't offer the necessary freedom to make use of it. it's not "open source", it's just source. (For the record: I shifted from the GNU side to the BSD side of the debate about 20 years ago. But I hold no ill will toward people on the GNU side.) -uso. From woods at robohack.ca Wed Feb 19 06:22:56 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 18 Feb 2020 12:22:56 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: At Tue, 18 Feb 2020 10:11:45 -0500, Clem Cole wrote: Subject: Re: [TUHS] man Macro Package and pdfmark > > On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods wrote: > > > > I.e. there was no open-source [nt]roff compatible program at the time, > > and the mainly available proprietary one produced (for quality printing > > purposes) only very convoluted hard-coded output for a quite esoteric > > and rare piece of equipment. AT&T's public attempt to solve this > > (ditroff) just added more cost and arguably less availability. > > > ditroff was always >>open source<< and any licensee could get it and see > it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. Indeed. I was going to use the word "freeware", but it seems to have gone out of common use in favour of the now more common "open-source", as in https://opensource.org/ At the times I referred to the lack of freely available AT&T source code was extremely limiting in how people viewed the availability of such "add-on" tools for Unix -- including the C compiler! AT&T's break-up of the "Unix" distribution into separately licensed chunks was, from my perspective, one of the main driving forces behind the creation and adoption of so many clones and alternatives -- no matter how far they strayed from the original Unix philosophy. > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the > like, it is possible it was different. It was _very_ different. If you weren't out in the trenches of end-user Unix-based systems at the time it may not have been as obvious as to just how restrictive it was to have proprietary fee-based licensing of such add-on software. Most end-users couldn't even pay their vendors for ditroff -- their vendors didn't want to have to license it from AT&T, even when they had advocates inside the companies (e.g. I did some work supporting software for a couple such vendors and was never able to convince them). Some, as you mention, were all-in, but it wasn't until UNIX System V Release 4 became more widely available that systems based on it were more likely to have ditroff, and sometimes (though much more rarely) the "new" dpost post-processor was also included. I don't know if there were different licensing terms for SysVr4 or not. Don't get me started on how hard it also was to get some end users to buy a C compiler too. For the entire decade of the 1990s I was still one of the only people I knew (outside of those I knew in AT&T Canada and their customers) who owned a system that included ditroff and dpost and could print directly to a PostScript laser printer -- and that's despite living in the same city where SoftQuad was re-licensing ditroff and their variant of dpost to quite a wide variety of users. This was my situation because I had chosen to buy a used AT&T 3B2. Without that I'd have been without ditroff -- I would have been very lucky if I had v7 troff binaries so that I could use Chris' PSroff. These days of course there's the full ditroff source release in the Heirloom Documentation Tools collection. I'd like to see it used to replace Groff in some places, but so far I've been less than successful -- that cart seems to have rolled off the road into the ditch, hopefully without losing the horse though. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Wed Feb 19 06:24:02 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 18 Feb 2020 12:24:02 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002180745.01I7jBeJ007975@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002180745.01I7jBeJ007975@freefriends.org> Message-ID: At Tue, 18 Feb 2020 00:45:11 -0700, arnold at skeeve.com wrote: Subject: Re: [TUHS] man Macro Package and pdfmark > > "Greg A. Woods" wrote: > > > > Personally I still mostly use Lout these days. :-) > > Wow. Is that still maintained? Oh yeah, though it's kind of like TeX in that it has been very stable and relatively bug-free for years now. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From dave at horsfall.org Wed Feb 19 07:26:22 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 19 Feb 2020 08:26:22 +1100 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: On Tue, 18 Feb 2020, Steve Nickolas wrote: > (For the record: I shifted from the GNU side to the BSD side of the > debate about 20 years ago. But I hold no ill will toward people on the > GNU side.) I've always stayed with BSD :-) I regard the GPL as a virus and too restrictive, as it compels me to do certain things; if the only choice is to make use of a GPL library then I will write my own rather than have my work owned by Stallman et al. -- Dave From wobblygong at gmail.com Wed Feb 19 07:29:15 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 19 Feb 2020 10:29:15 +1300 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: IIRC, there was a meeting of various (FOSS) luminaries in the early or mid-90s discussing rebranding Free Software (as in the FSF definition) as it was far too easily misinterpreted as meaning non-/anti-commercial. "Open Systems" had been around forever as a description of how the Unix "ecosystem" worked - you had a common set of APIs based on an originally common source base, and a common set of communication protocols, that worked on a wide array of computer systems, from real-time to supercomputers to mainframes and beyond. With all due respect to Clem Cole, I don't recall ever seeing "open source" used as a description of the Unix "ecosystem" during the 90s. It was in the air with the (minimal) charges Prentice-Hall charged for the Minix 0.x and 1.x disks and source; not dissimilar in that sense to the charges the FSF were charging for their tapes at the time. But all the Unix-y ads I can recall from the 90s talked about Open Systems, and never Open Source. That came in following Linux and *BSD radiation. But this is probably COFF's Harbour stuff ... Wesley Parish On 2/19/20, Steve Nickolas wrote: > On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote: > >> On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote: >>> On Tue, 18 Feb 2020, arnold at skeeve.com wrote: >>> >>>> I don't like your use of "open source"; it is way out of skew with >>>> how it's used today. >>> >>> Wasn't it always *intended* to mean the same thing as "Free Software" ? >> >> No, although the differences in practice are small. "Free Software" >> was defined by Stallman as meeting his "Four Freedoms". Open >> Source(tm) was derived from the Debian Free Software Guidelines, and >> while the set of licenses which meet the "Free Software" definition >> and those that meet the "Open Source(tm) definition mostly identical, >> there are a few exceptions. >> >> I refer folks to the Wikipedia entry for more details: >> >> https://en.wikipedia.org/wiki/The_Free_Software_Definition >> >> It is true that the most of the people who use Open Source instead of >> Free Software are doing so mostly for branding reasons (e.g., Open >> Source is considered less likely to scare the suits), but technically >> they aren't the same. And it is certainly true that way AT&T >> distributed ditroff certainly isn't compliant with the Open Source >> Definition (OSD). >> >> Whether or not it meets Clem's "open source" (small o, small s), >> depends on his definition, which appears to be, "functionally, since >> everyone back then had an AT&T source license, we're all good". >> >> - Ted >> > > I always understood "open source" to mean this: you have access to the > code, you can share it, you can modify it, and any combination of the > above (including commercial exploitation; basically a restatement of > Stallman's freedoms in simpler words). > > As any phrase gets skewed to mean something other than it was intended, > when most people say "open source", they seem to only mean what I call > "source-available" - i.e., that there is *some* means by which a mere > mortal can gain access to the source, but there is no guarantee that they > can actually DO anything with the source without getting sued into > oblivion. I usually say if the code doesn't offer the necessary freedom > to make use of it. it's not "open source", it's just source. > > (For the record: I shifted from the GNU side to the BSD side of the debate > about 20 years ago. But I hold no ill will toward people on the GNU > side.) > > -uso. > From rdm at cfcl.com Wed Feb 19 07:46:29 2020 From: rdm at cfcl.com (Rich Morin) Date: Tue, 18 Feb 2020 13:46:29 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002181528.01IFSogM030831@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> Message-ID: > On Feb 18, 2020, at 07:28, arnold at skeeve.com wrote: > > Clem Cole wrote: > >> ditroff was always >>open source<< and any licensee could get it and see >> it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. > > I don't like your use of "open source"; it is way out of skew with > how it's used today. "How I coined the term 'open source'", by Christine Peterson https://opensource.com/article/18/2/coining-term-open-source-software -r From doug at cs.dartmouth.edu Wed Feb 19 10:55:21 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 18 Feb 2020 19:55:21 -0500 Subject: [TUHS] Literate programmin Message-ID: <202002190055.01J0tLSN145361@tahoe.cs.Dartmouth.EDU> Apropos of Knuth and me, may I immodestly point to https://comic.browserling.com/tag/knuth The second likeness of Don is quite good. And the screen almost justifies posting to tuhs. Doug From jpl.jpl at gmail.com Wed Feb 19 12:18:18 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 18 Feb 2020 21:18:18 -0500 Subject: [TUHS] Literate programmin In-Reply-To: <202002190055.01J0tLSN145361@tahoe.cs.Dartmouth.EDU> References: <202002190055.01J0tLSN145361@tahoe.cs.Dartmouth.EDU> Message-ID: To paraphrase some recent testimony, "If that screen doesn't justify posting to tuhs, nothing does." On Tue, Feb 18, 2020 at 7:56 PM Doug McIlroy wrote: > Apropos of Knuth and me, may I immodestly point to > https://comic.browserling.com/tag/knuth > The second likeness of Don is quite good. And > the screen almost justifies posting to tuhs. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 19 12:46:14 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 19 Feb 2020 13:46:14 +1100 (EST) Subject: [TUHS] Literate programmin In-Reply-To: <202002190055.01J0tLSN145361@tahoe.cs.Dartmouth.EDU> References: <202002190055.01J0tLSN145361@tahoe.cs.Dartmouth.EDU> Message-ID: On Tue, 18 Feb 2020, Doug McIlroy wrote: > Apropos of Knuth and me, may I immodestly point to > https://comic.browserling.com/tag/knuth The second likeness of Don is > quite good. And the screen almost justifies posting to tuhs. The screen on the right looks remarkably like an early version of "spell" i.e. words that occur the least are likely to be misspelled. -- Dave From lm at mcvoy.com Wed Feb 19 14:44:44 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 18 Feb 2020 20:44:44 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> Message-ID: <20200219044444.GO30841@mcvoy.com> On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote: > At the times I referred to the lack of freely available AT&T source code > was extremely limiting in how people viewed the availability of such > "add-on" tools for Unix -- including the C compiler! This wasn't just an AT&T thing, Sun and SGI and everyone charged for their C compiler. I sort of get it, writing a good compiler is up there with writing a good kernel in effort, not quite the same, but probably the 2nd hardest thing to do. So the compiler people cost a lot, companies wanted to get that cost back. It was stupid. Having a free compiler meant that more people would write apps for your platform. It should have been a loss leader. > > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the > > like, it is possible it was different. > > It was _very_ different. > > If you weren't out in the trenches of end-user Unix-based systems at the > time it may not have been as obvious as to just how restrictive it was > to have proprietary fee-based licensing of such add-on software. Most > end-users couldn't even pay their vendors for ditroff -- their vendors > didn't want to have to license it from AT&T, even when they had > advocates inside the companies (e.g. I did some work supporting software > for a couple such vendors and was never able to convince them). Some, > as you mention, were all-in, but it wasn't until UNIX System V Release 4 > became more widely available that systems based on it were more likely > to have ditroff, and sometimes (though much more rarely) the "new" dpost > post-processor was also included. I don't know if there were different > licensing terms for SysVr4 or not. Don't get me started on how hard it > also was to get some end users to buy a C compiler too. Yep, lived through this as well. I fought with Sun to make more stuff free for developers, it just didn't make sense to not do that but the powers that were didn't get it. One thing that Sun did do, probably in spite of itself, was fund Michael Tiemann's work on C++. He worked out some deal that that work would be open source and he pretty much made GNU C++ work for some definition of work (C++ is a mess). From grog at lemis.com Wed Feb 19 14:52:21 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 19 Feb 2020 15:52:21 +1100 Subject: [TUHS] Open source or free software? (was: man Macro Package and pdfmark) In-Reply-To: References: <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <202002181528.01IFSogM030831@freefriends.org> <20200218164031.GA147128@mit.edu> Message-ID: <20200219045221.GF2324@eureka.lemis.com> On Tuesday, 18 February 2020 at 13:39:22 -0500, Steve Nickolas wrote: > > I always understood "open source" to mean this: you have access to the > code, you can share it, you can modify it, and any combination of the > above (including commercial exploitation; basically a restatement of > Stallman's freedoms in simpler words). I don't see those words as simpler. Ask any (wo)man in the street what free software is, and they'll come up with a reasonable approximation. As them what open source is and far fewer will know. At the very best it's only intelligible in a limited environment. And of course here in Australia, Open Sauce is a completely different homonym. rms won't touch it either: https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20100916/small/rms-meets-open-sauce-detail.jpeg 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 earl.baugh at gmail.com Thu Feb 20 04:01:54 2020 From: earl.baugh at gmail.com (Earl Baugh) Date: Wed, 19 Feb 2020 13:01:54 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200219044444.GO30841@mcvoy.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> Message-ID: What was more frustrating to Sun users was that there WAS a compiler included in Sun OS, but it went away with Solaris. I saw a noticeable change in code available in binary form only after that. At least until the GNU stuff got stable enough to use... (I was a customer of MIke's when he first start Cygnus for support of the GNU compilers... I was working in a secured facility and multiple times I spoke with him on the phone typing in patches by hand -- as he relayed them -- because of the time and hassle it took to get a tape in with the patch...) Earl On Tue, Feb 18, 2020 at 11:45 PM Larry McVoy wrote: > On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote: > > At the times I referred to the lack of freely available AT&T source code > > was extremely limiting in how people viewed the availability of such > > "add-on" tools for Unix -- including the C compiler! > > This wasn't just an AT&T thing, Sun and SGI and everyone charged for their > C compiler. I sort of get it, writing a good compiler is up there with > writing a good kernel in effort, not quite the same, but probably the > 2nd hardest thing to do. So the compiler people cost a lot, companies > wanted to get that cost back. > > It was stupid. Having a free compiler meant that more people would > write apps for your platform. It should have been a loss leader. > > > > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and > the > > > like, it is possible it was different. > > > > It was _very_ different. > > > > If you weren't out in the trenches of end-user Unix-based systems at the > > time it may not have been as obvious as to just how restrictive it was > > to have proprietary fee-based licensing of such add-on software. Most > > end-users couldn't even pay their vendors for ditroff -- their vendors > > didn't want to have to license it from AT&T, even when they had > > advocates inside the companies (e.g. I did some work supporting software > > for a couple such vendors and was never able to convince them). Some, > > as you mention, were all-in, but it wasn't until UNIX System V Release 4 > > became more widely available that systems based on it were more likely > > to have ditroff, and sometimes (though much more rarely) the "new" dpost > > post-processor was also included. I don't know if there were different > > licensing terms for SysVr4 or not. Don't get me started on how hard it > > also was to get some end users to buy a C compiler too. > > Yep, lived through this as well. I fought with Sun to make more stuff > free for developers, it just didn't make sense to not do that but the > powers that were didn't get it. > > One thing that Sun did do, probably in spite of itself, was fund > Michael Tiemann's work on C++. He worked out some deal that that > work would be open source and he pretty much made GNU C++ work > for some definition of work (C++ is a mess). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at emilebye.com Thu Feb 20 04:12:52 2020 From: me at emilebye.com (Emile Bye) Date: Wed, 19 Feb 2020 18:12:52 +0000 (GMT) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> Message-ID: <615399517.295857.1582135972871@email.ionos.co.uk> An HTML attachment was scrubbed... URL: From mphuff at gmail.com Thu Feb 20 06:18:53 2020 From: mphuff at gmail.com (Michael Huff) Date: Wed, 19 Feb 2020 11:18:53 -0900 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <615399517.295857.1582135972871@email.ionos.co.uk> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> Message-ID: I've only tried it in virtual machines. It feels slower and more sluggish than OpenIndiana (which is based on Illumos, which is the post-Oracle open solaris) -but I don't use OI a whole lot either. Since there's an opening I'm curious about something mentioned earlier in the thread, so I'll ask. It was said earlier that SunOS included a compiler, but it was dropped in Solaris. Was it possible for people to carry over the old SunOS compiler and use it on Solaris? Did people do that, or did they just have their companies spring for the actual Solaris compiler? On 2/19/2020 9:12 AM, Emile Bye wrote: > Hello all, > > > I'm a new member of the list and have been reading quietly in the > background. > > > Changing the subject slightly (it's kind of relevant)... Has anyone > had a look at the new Solaris?  Apart from it using the Gnome 3 DE > which is very sluggish, it's awful! > > 11.3 is the last version I'm going to install on anything I've got!  > (My Sun Blade 2500 will have Solaris 10 though... much better...) > > Rant over... > > Apologies for being a little off-topic, > > > > Emile >> On 19 February 2020 at 18:01 Earl Baugh wrote: >> >> What was more frustrating to Sun users was that there WAS a compiler >> included in Sun OS, >> but it went away with Solaris.  I saw a noticeable change in code >> available in binary form only after that. >> At least until the GNU stuff got stable enough to use... >> >> (I was a customer of MIke's when he first start Cygnus for support of >> the GNU compilers... >> I was working in a secured facility and multiple times I spoke with >> him on the phone typing in patches >> by hand -- as he relayed them -- because of the time and hassle it >> took to get a tape in with the patch...) >> >> Earl >> >> >> On Tue, Feb 18, 2020 at 11:45 PM Larry McVoy < lm at mcvoy.com >> > wrote: >> >> On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote: >> > At the times I referred to the lack of freely available AT&T >> source code >> > was extremely limiting in how people viewed the availability of >> such >> > "add-on" tools for Unix -- including the C compiler! >> >> This wasn't just an AT&T thing, Sun and SGI and everyone charged >> for their >> C compiler.  I sort of get it, writing a good compiler is up >> there with >> writing a good kernel in effort, not quite the same, but probably >> the >> 2nd hardest thing to do.  So the compiler people cost a lot, >> companies >> wanted to get that cost back. >> >> It was stupid.  Having a free compiler meant that more people would >> write apps for your platform.   It should have been a loss leader. >> >> > > For folks running binary only systems from >> Masscomp/Sun/DEC/HP/IBM and the >> > > like, it is possible it was different. >> > >> > It was _very_ different. >> > >> > If you weren't out in the trenches of end-user Unix-based >> systems at the >> > time it may not have been as obvious as to just how restrictive >> it was >> > to have proprietary fee-based licensing of such add-on >> software.  Most >> > end-users couldn't even pay their vendors for ditroff -- their >> vendors >> > didn't want to have to license it from AT&T, even when they had >> > advocates inside the companies (e.g. I did some work supporting >> software >> > for a couple such vendors and was never able to convince >> them).  Some, >> > as you mention, were all-in, but it wasn't until UNIX System V >> Release 4 >> > became more widely available that systems based on it were more >> likely >> > to have ditroff, and sometimes (though much more rarely) the >> "new" dpost >> > post-processor was also included.  I don't know if there were >> different >> > licensing terms for SysVr4 or not.  Don't get me started on how >> hard it >> > also was to get some end users to buy a C compiler too. >> >> Yep, lived through this as well.  I fought with Sun to make more >> stuff >> free for developers, it just didn't make sense to not do that but >> the >> powers that were didn't get it. >> >> One thing that Sun did do, probably in spite of itself, was fund >> Michael Tiemann's work on C++.  He worked out some deal that that >> work would be open source and he pretty much made GNU C++ work >> for some definition of work (C++ is a mess). >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Feb 20 06:34:49 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 19 Feb 2020 12:34:49 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> Message-ID: <202002192034.01JKYnkh1855850@darkstar.fourwinds.com> Michael Huff writes: > It was said earlier that SunOS included a compiler, but it was dropped > in Solaris. Was it possible for people to carry over the old SunOS > compiler and use it on Solaris? Did people do that, or did they just > have their companies spring for the actual Solaris compiler? I don't think so. I ended up springing for the compiler when I purchased my Ultra-60. But, it was extraordinarily clunky and unreliable because of their licensing scheme. It commonly refused to work thinking that there were too many instances runnining or something like that. It was a big relief when the GNU compiler because available and I never touched the Sun compiler again. Jon From henry.r.bent at gmail.com Thu Feb 20 07:09:49 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 19 Feb 2020 16:09:49 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> Message-ID: On Wed, 19 Feb 2020 at 15:20, Michael Huff wrote: > I've only tried it in virtual machines. It feels slower and more sluggish > than OpenIndiana (which is based on Illumos, which is the post-Oracle open > solaris) -but I don't use OI a whole lot either. > > Since there's an opening I'm curious about something mentioned earlier in > the thread, so I'll ask. > > It was said earlier that SunOS included a compiler, but it was dropped in > Solaris. Was it possible for people to carry over the old SunOS compiler > and use it on Solaris? Did people do that, or did they just have their > companies spring for the actual Solaris compiler? > In short: no. SunOS binaries would usually run on Solaris if you had all of the right libraries, etc. but the compilers created totally different code. SunOS was a.out and Solaris was ELF; SunOS was BSD and Solaris was SYSV. Solaris was a huge shift away from SunOS; they were effectively entirely different operating systems for the same hardware. I don't know if there was some sort of trade-in discount for the old compiler when you upgraded to Solaris, there might have been. SunOS continued to be patched and supported long after Solaris was released. There were many reasons for this, but the short summary is that many people didn't want to have to move to an entirely new OS, or for some reason couldn't. The analogy that comes to mind is the shift from the classic Mac OS to OS X: your old programs would probably run if they weren't too concerned about the internals of the OS, but it was a big upheaval and most everything had to be rewritten to some degree. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Thu Feb 20 10:06:26 2020 From: erc at pobox.com (Ed Carp) Date: Wed, 19 Feb 2020 18:06:26 -0600 Subject: [TUHS] Who is the inventor of email? Message-ID: I've noticed that some guy named Dr. Shiva Ayyadurai is all over Twitter, claiming that he is the inventor of email. He doesn't look like he's nearly old enough. I thought it was Ray Tomlinson. Looks like he's trying to create some press for his Senate run. Anyone older that me here that can either confirm or deny? Thanks! From ken at google.com Thu Feb 20 10:18:39 2020 From: ken at google.com (Ken Thompson) Date: Wed, 19 Feb 2020 16:18:39 -0800 Subject: [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: i first saw email (between users on a single cpu) in 64/65. a leap to bigger things was natural as soon as cpus talked to each other. i first saw this in 78/79 with uucp. On Wed, Feb 19, 2020 at 4:07 PM Ed Carp wrote: > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > Twitter, claiming that he is the inventor of email. He doesn't look > like he's nearly old enough. I thought it was Ray Tomlinson. Looks > like he's trying to create some press for his Senate run. > > Anyone older that me here that can either confirm or deny? Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Thu Feb 20 10:11:30 2020 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 19 Feb 2020 16:11:30 -0800 Subject: [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: <23e6d5ca-c9c6-694d-0613-c66626579be8@solar.stanford.edu> A version of email was included in the original DARPA version of the internet. This was early 1970s. In fact, when we played with and evaluated it at Lawrence Berkeley Lab, our report noted that the internet would probably not be very useful for exchanging scientific files (as had been the original purpose). However, we did note that email might become very useful. ;-) Deborah On 2/19/20 4:06 PM, Ed Carp wrote: > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > Twitter, claiming that he is the inventor of email. He doesn't look > like he's nearly old enough. I thought it was Ray Tomlinson. Looks > like he's trying to create some press for his Senate run. > > Anyone older that me here that can either confirm or deny? Thanks! From jason-tuhs at shalott.net Thu Feb 20 10:26:27 2020 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Wed, 19 Feb 2020 16:26:27 -0800 (PST) Subject: [TUHS] Oral history interview with Doug McIlroy In-Reply-To: <448EAB58-BA80-4600-A150-23E5DD1E8FAE@kdbarto.org> References: <4B4A388452D2A7418879B110A352A8F401888068A7@EX-MB1.hq.computerhistory.org> <448EAB58-BA80-4600-A150-23E5DD1E8FAE@kdbarto.org> Message-ID: >> With Doug’s permission, I’d like to bring the group’s attention to a >> recent oral history with him by the Computer History Museum. >> >> You can find the records for the two interviews here, and in them the >> links to the PDF transcripts: >> >> https://www.computerhistory.org/collections/oralhistories/?s=mcilroy > David, thanks for the link to this 2 part oral history (transcribed). It > was a wonderful read through Doug’s history as well as the history of > how Unix got started and some of the interesting points where Doug and > others all made changes that lead to what became that thing called Unix > that all of us know a love. Apologies if I'm missing the obvious, but is the actual audio from this interview not available? I would love to be able to actually listen to this rather than just read it. That said, even just the transcript is an excellent artifact. Thanks! -Jason From ggm at algebras.org Thu Feb 20 10:39:51 2020 From: ggm at algebras.org (George Michaelson) Date: Thu, 20 Feb 2020 11:39:51 +1100 Subject: [TUHS] Who is the inventor of email? In-Reply-To: <23e6d5ca-c9c6-694d-0613-c66626579be8@solar.stanford.edu> References: <23e6d5ca-c9c6-694d-0613-c66626579be8@solar.stanford.edu> Message-ID: Email was in the EMAS system in Edinburgh university very soon after full multiaccess services were released, Certainly by the early 1970s. By the time VMS was released, email between nodes was a fact of life. JANET had email in the coloured book series. It was ubiquitous by the late 1970s. It is important not to mistake the formal syntactic mechanism of saying who you are mailing, with where they are, as a definition of user at host, the actual mechanism of saying "send this to " can be completely decoupled from having names, host names, domain names or any analogous construct. Mail existed long before we had to do "shebang" paths, and I mean mail between discrete, independent computers. -George On Thu, Feb 20, 2020 at 11:33 AM Deborah Scherrer wrote: > > A version of email was included in the original DARPA version of the > internet. This was early 1970s. In fact, when we played with and > evaluated it at Lawrence Berkeley Lab, our report noted that the > internet would probably not be very useful for exchanging scientific > files (as had been the original purpose). However, we did note that > email might become very useful. ;-) > > Deborah > > On 2/19/20 4:06 PM, Ed Carp wrote: > > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > > Twitter, claiming that he is the inventor of email. He doesn't look > > like he's nearly old enough. I thought it was Ray Tomlinson. Looks > > like he's trying to create some press for his Senate run. > > > > Anyone older that me here that can either confirm or deny? Thanks! > From rich.salz at gmail.com Thu Feb 20 10:40:43 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 19 Feb 2020 19:40:43 -0500 Subject: [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: He's a loon. Search for the techdirt.com articles. On Wed, Feb 19, 2020, 7:07 PM Ed Carp wrote: > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > Twitter, claiming that he is the inventor of email. He doesn't look > like he's nearly old enough. I thought it was Ray Tomlinson. Looks > like he's trying to create some press for his Senate run. > > Anyone older that me here that can either confirm or deny? Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 20 10:46:19 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 20 Feb 2020 11:46:19 +1100 (EST) Subject: [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: On Wed, 19 Feb 2020, Ed Carp wrote: > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > Twitter, claiming that he is the inventor of email. He doesn't look like > he's nearly old enough. I thought it was Ray Tomlinson. Looks like he's > trying to create some press for his Senate run. > > Anyone older that me here that can either confirm or deny? Thanks! Ray Tomlinson is said to have first used the "@" symbol, but email as such certainly existed before then; I first used it in the 70s on an IBM 360, but it was definitely already in use at the time. -- Dave From cmhanson at eschatologist.net Thu Feb 20 11:17:32 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 19 Feb 2020 17:17:32 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> Message-ID: <226AD6CE-1B73-43FA-9156-114AAAB4EB80@eschatologist.net> On Feb 17, 2020, at 8:53 PM, Kevin Bowling wrote: > > Can you clarify what is Mach in this archive if I have a gap in my knowledge? I didn’t know the VRM had any direct relationship to Mach It didn’t, but CMU used Mach on the RT, including in public clusters[1]. CMU also deployed MacMach on the Macintosh II in public clusters, which ran System 6 side-by-side with BSD 4.3. -- Chris [1] A “public [computer] cluster” was CMU terminology for computer labs accessible to the entire CMU community instead of just being accessible to one department or program. From kevin.bowling at kev009.com Thu Feb 20 11:24:01 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 19 Feb 2020 18:24:01 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <226AD6CE-1B73-43FA-9156-114AAAB4EB80@eschatologist.net> References: <25E62EB5E090E7CB.88de76ea-9cec-4c1e-a00f-b15eb755ab0a@mail.outlook.com> <226AD6CE-1B73-43FA-9156-114AAAB4EB80@eschatologist.net> Message-ID: Neat! Do you think we will ever be able to recover those bits or is it too obscure and unobtanium like the rs6000 Mach port? As an aside I’ve near complete technical references for both of these platforms (RT, rs6000) and they were quite comprehensive for doing OS ports. I wondered why there was no free open source OS for them but I now suspect people just had fear of IBM, some real and some imagined. On Wed, Feb 19, 2020 at 6:17 PM Chris Hanson wrote: > On Feb 17, 2020, at 8:53 PM, Kevin Bowling > wrote: > > > > Can you clarify what is Mach in this archive if I have a gap in my > knowledge? I didn’t know the VRM had any direct relationship to Mach > > It didn’t, but CMU used Mach on the RT, including in public clusters[1]. > > CMU also deployed MacMach on the Macintosh II in public clusters, which > ran System 6 side-by-side with BSD 4.3. > > -- Chris > > [1] A “public [computer] cluster” was CMU terminology for computer labs > accessible to the entire CMU community instead of just being accessible to > one department or program. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Thu Feb 20 11:29:01 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 19 Feb 2020 17:29:01 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <603eee49-26a1-c2ab-61ae-aa9d75896744@bitsavers.org> References: <27a3d023-17c2-3e61-5ba7-677365fbcae7@technologists.com> <603eee49-26a1-c2ab-61ae-aa9d75896744@bitsavers.org> Message-ID: <4AC9BD85-6D98-4AC2-BDA6-9B75F1F0EF87@eschatologist.net> On Feb 17, 2020, at 5:30 PM, Al Kossow wrote: > > I'm in the process of restoring/documenting the machine, and also helping a member of the MAME team to emulate the system. Thanks! I started on a ROMP emulator in Swift using only the docs and 6150 IPL ROM on Bitsavers many months ago, then got sidetracked with work. Maybe I’ll pick that back up again, especially if there’s more/better documentation available now. One thing I found was that among the first few instructions in the IPL ROM, you immediately hit undocumented bits. I’m pretty sure they’re for resetting the two different floating-point accelerators. -- Chris From davida at pobox.com Thu Feb 20 11:44:28 2020 From: davida at pobox.com (David Arnold) Date: Thu, 20 Feb 2020 12:44:28 +1100 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> Message-ID: > On 19 Feb 2020, at 00:39, Al Kossow wrote: <…> > I've been interested in Mach since messing with MacMach on a IIfx in the early 90's > Has there been any collective effort trying to recover RIG/Mach code? > It all seems very fragmented. I went looking for some of this a few months ago, but it seemed like it wasn’t going to be a simple search. At one time I’d played with CMU Mach, Utah Mach, OSF Mach, and Apple’s MkLinux, but it all seemed to have drifted into broken links and missing FTP servers. Sprite, Accent, Spring, Amoeba, VSTa … a lot of the OS projects I remember from that era seem to have disappeared. Only Plan9 seems to have really survived (not counting the Mach bits of Darwin). d From aek at bitsavers.org Thu Feb 20 12:03:50 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 19 Feb 2020 18:03:50 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> Message-ID: On 2/19/20 5:44 PM, David Arnold wrote: > Sprite, Accent, Spring, Amoeba, VSTa … a lot of the OS projects I remember from that era seem to have disappeared. There was a Sprite CD that I should have somewhere. I don't know if I ever pulled down all of Amoeba I keep hoping someone has Accent (or any of the CMU tape archive) I did put up my copy of the Stanford V Kernel on bitsavers a while back. From bakul at bitblocks.com Thu Feb 20 12:09:14 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 19 Feb 2020 18:09:14 -0800 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> Message-ID: <8047F596-A3AF-425C-AA70-9BFED20FA42D@bitblocks.com> https://web.archive.org/web/20000901081815/http://www.cs.vu.nl/pub/amoeba/amoeba5.3/ > On Feb 19, 2020, at 6:03 PM, Al Kossow wrote: > > > > On 2/19/20 5:44 PM, David Arnold wrote: > >> Sprite, Accent, Spring, Amoeba, VSTa … a lot of the OS projects I remember from that era seem to have disappeared. > > There was a Sprite CD that I should have somewhere. > I don't know if I ever pulled down all of Amoeba > I keep hoping someone has Accent (or any of the CMU tape archive) > > I did put up my copy of the Stanford V Kernel on bitsavers a while back. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Feb 20 12:12:24 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 20 Feb 2020 12:12:24 +1000 Subject: [TUHS] Who is the inventor of email? In-Reply-To: References: Message-ID: <20200220021224.GA7250@minnie.tuhs.org> On Wed, Feb 19, 2020 at 06:06:26PM -0600, Ed Carp wrote: > I've noticed that some guy named Dr. Shiva Ayyadurai is all over > Twitter, claiming that he is the inventor of email. He doesn't look > like he's nearly old enough. I thought it was Ray Tomlinson. Looks > like he's trying to create some press for his Senate run. > > Anyone older that me here that can either confirm or deny? Thanks! Over to COFF for this :-) Thanks all, Warren From sauer at technologists.com Thu Feb 20 16:44:27 2020 From: sauer at technologists.com (Charles H. Sauer) Date: Thu, 20 Feb 2020 00:44:27 -0600 Subject: [TUHS] anedotes: RT/PC VRM, (early) AIX compilers, IBM (Research) software release/pricing [was Re: Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> Message-ID: <899AF90D-22DB-431F-929A-8BD3F144F610@technologists.com> > On Feb 18, 2020, at 7:41 AM, Kevin Bowling wrote: > > ... > > IBM abandoned the idea of any ukernel with AIX3 for RISC/6000.. Charlie may be able to add commentary on that but it was almost certainly for performance which was paramount in the workstation wars and RS6K had an front runner opening. > I initially missed Kevin's ping after my spam filter put several TUHS messages in /var/mail/devnull. (I eventually skim subject lines of messages that go there.) I could write more than I want to/should about how the VRM came to be and not to be, but will try to add a little to what I've said before (https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/). I'm trusting 30+ year-old memories here and not looking at the various papers and manuals that might inform. I joined Glenn's AFWS project July 5, 1982. There was no well defined software plan yet. Glenn wanted to do something useful and significant, and proposed that we do the VRM. We had several distinct user environments in mind. I took the lead in writing a specification of the VMI (virtual machine interface) while others started prototyping. We were way overly ambitious with abstractions along the lines of the single level store of (Glenn's) System 38, trying to take advantage of the 40 bit addressing of the Rosetta virtual memory chip, yet still heavily influenced by CP/CMS. After a few months, Al Chang, primary person behind CP.R, came to Austin for a design review of what we'd done. He told Glenn he'd grade our work "C+". That might have been generous. We scaled back our ambitions dramatically, started working with ISC. About the time (1983) of the transition from "ad tech" to "product" organization, it became clear that our virtual memory manager needed to be scrapped and we lifted what Al had done for CP.R and put it in the VRM. In hindsight, the VRM turned out better than it might have. Besides AIX there was a version of Pick for VRM that sold about 4000 copies according to https://en.wikipedia.org/wiki/IBM_RT_PC. Though the VMI cost us some in performance, we were surprisingly successful in minimizing the penalties. But with AIX 3 and RS/6000 we wanted to take dramatic steps forward, and it made no sense to preserve the VMI. Anecdotal comments on other TUHS/COFF discussions: If I recall correctly, pcc, eventually including the HCR optimizing phase, was bundled with base AIX. Initially, the C compiler based on the PL.8 compiler would only run on CMS, so it was not generally available outside of IBM, but app vendors, especially CAD vendors, were enabled and encouraged to come to Austin to use it to get the best performance. The native C compiler based on PL.8 compiler concepts ended up being a complete rewrite, outside of Yorktown, and sold as a separate product. Producing software products, getting them released, priced, etc. was very confusing to me most of the time I was at IBM. Part of it was the history that Clem has cited. Part of it was confusion about the antitrust suits against IBM. Part of it was confusion about whether and what software was patentable. Academics and others wanted access to the modeling & simulation software, RESQ, my team developed at Yorktown. Eventually, the concept of "Research Distributed Program" was agreed upon and RESQ was the first instance: https://technologists.com/sauer/RA144.pdf. However, we were forced to price RESQ much higher than I thought reasonable. I had already transferred to Austin by the time the release was official -- I don't know how many copies were sold. But source code was necessary to take full advantage of RESQ so the PL/I source was included on the tapes. When OSF was announced, with the intention of making AIX source available to the other OSF companies, I was stunned because it was so uncharacteristic of the IBM I thought I knew. It would be interesting to know how that would have worked out if OSF had stuck with AIX and IBM had delivered the source on the schedule everyone hoped for, but that's on a different timeline than this one. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From arnold at skeeve.com Thu Feb 20 17:18:47 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 20 Feb 2020 00:18:47 -0700 Subject: [TUHS] Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> <6899aee0-6324-7b7e-513d-498a3cae6cd4@bitsavers.org> Message-ID: <202002200718.01K7IlGH014128@freefriends.org> David Arnold wrote: > Sprite, Accent, Spring, Amoeba, VSTa … a lot of the OS projects I > remember from that era seem to have disappeared. Only Plan9 seems to > have really survived (not counting the Mach bits of Darwin). At some point there was a Sprite CD being sold, which I think I have somewhere.... Accent only ran on the PERQ; I once described Mach as "Accent on the VAX". :-) So, unless you have PERQ hardware or an emulator, it wouldn't do you much good even if you had the source. Arnold From arnold at skeeve.com Thu Feb 20 17:27:15 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 20 Feb 2020 00:27:15 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> Message-ID: <202002200727.01K7RFwj014313@freefriends.org> Michael Huff wrote: > It was said earlier that SunOS included a compiler, but it was dropped > in Solaris. Was it possible for people to carry over the old SunOS > compiler and use it on Solaris? Did people do that, or did they just > have their companies spring for the actual Solaris compiler? Early Solaris would not run SunOS binaries; that was fixed later on. People could then move the SunOS compiler over to Solaris. That was less helpful that it might seem, as it was a K&R compiler. But it could be used to bootstrap GCC and then one could go on from there. As Larry and others have pointed out, the unbundling of various components was a big mistake by the vendors. It just made users angry and motivated them to switch to other Unix systems. Also, early Solaris was a dog. Performance was poor. It improved over time, but it wasn't until around Solaris 2.4 or 2.5 that running it wasn't painful. Arnold From rdm at cfcl.com Thu Feb 20 17:43:50 2020 From: rdm at cfcl.com (Rich Morin) Date: Wed, 19 Feb 2020 23:43:50 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002200727.01K7RFwj014313@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> Message-ID: <26D76662-B9A6-4BBB-9D23-6D1E4EE27782@cfcl.com> I looked at Solaris very briefly and decided that it wasn't my idea of a proper (read, BSD) Unix system. So, I kept my Sun running SunOS until I finally replaced it with a FreeBSD box. -r > On Feb 19, 2020, at 23:27, arnold at skeeve.com wrote: > > Also, early Solaris was a dog. Performance was poor. It improved over > time, but it wasn't until around Solaris 2.4 or 2.5 that running it > wasn't painful. From kevin.bowling at kev009.com Thu Feb 20 18:27:16 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 20 Feb 2020 01:27:16 -0700 Subject: [TUHS] anedotes: RT/PC VRM, (early) AIX compilers, IBM (Research) software release/pricing [was Re: Bitsavers' RT/PC, AIX, AOS, etc. recent additions In-Reply-To: <899AF90D-22DB-431F-929A-8BD3F144F610@technologists.com> References: <25E62EB5E090E7CB.c5cb28db-f209-4d75-8ad6-a165cb810b47@mail.outlook.com> <899AF90D-22DB-431F-929A-8BD3F144F610@technologists.com> Message-ID: Thanks for sharing, very interesting history to me. You guys were pros.. particularly amazing to me how far ahead the machine abstractions were on the various IBM machines (CP, S/38, VRM) compared to most of the industry. On Wed, Feb 19, 2020 at 11:44 PM Charles H. Sauer wrote: > > > On Feb 18, 2020, at 7:41 AM, Kevin Bowling > wrote: > > > > ... > > > > IBM abandoned the idea of any ukernel with AIX3 for RISC/6000.. Charlie > may be able to add commentary on that but it was almost certainly for > performance which was paramount in the workstation wars and RS6K had an > front runner opening. > > > > I initially missed Kevin's ping after my spam filter put several TUHS > messages in /var/mail/devnull. (I eventually skim subject lines of messages > that go there.) > > I could write more than I want to/should about how the VRM came to be and > not to be, but will try to add a little to what I've said before ( > https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/). > I'm trusting 30+ year-old memories here and not looking at the various > papers and manuals that might inform. > > I joined Glenn's AFWS project July 5, 1982. There was no well defined > software plan yet. Glenn wanted to do something useful and significant, and > proposed that we do the VRM. We had several distinct user environments in > mind. I took the lead in writing a specification of the VMI (virtual > machine interface) while others started prototyping. We were way overly > ambitious with abstractions along the lines of the single level store of > (Glenn's) System 38, trying to take advantage of the 40 bit addressing of > the Rosetta virtual memory chip, yet still heavily influenced by CP/CMS. > After a few months, Al Chang, primary person behind CP.R, came to Austin > for a design review of what we'd done. He told Glenn he'd grade our work > "C+". That might have been generous. > > We scaled back our ambitions dramatically, started working with ISC. About > the time (1983) of the transition from "ad tech" to "product" organization, > it became clear that our virtual memory manager needed to be scrapped and > we lifted what Al had done for CP.R and put it in the VRM. > > In hindsight, the VRM turned out better than it might have. Besides AIX > there was a version of Pick for VRM that sold about 4000 copies according > to https://en.wikipedia.org/wiki/IBM_RT_PC. Though the VMI cost us some > in performance, we were surprisingly successful in minimizing the > penalties. But with AIX 3 and RS/6000 we wanted to take dramatic steps > forward, and it made no sense to preserve the VMI. > > Anecdotal comments on other TUHS/COFF discussions: > > If I recall correctly, pcc, eventually including the HCR optimizing phase, > was bundled with base AIX. Initially, the C compiler based on the PL.8 > compiler would only run on CMS, so it was not generally available outside > of IBM, but app vendors, especially CAD vendors, were enabled and > encouraged to come to Austin to use it to get the best performance. The > native C compiler based on PL.8 compiler concepts ended up being a complete > rewrite, outside of Yorktown, and sold as a separate product. > > Producing software products, getting them released, priced, etc. was very > confusing to me most of the time I was at IBM. Part of it was the history > that Clem has cited. Part of it was confusion about the antitrust suits > against IBM. Part of it was confusion about whether and what software was > patentable. Academics and others wanted access to the modeling & simulation > software, RESQ, my team developed at Yorktown. Eventually, the concept of > "Research Distributed Program" was agreed upon and RESQ was the first > instance: https://technologists.com/sauer/RA144.pdf. However, we were > forced to price RESQ much higher than I thought reasonable. I had already > transferred to Austin by the time the release was official -- I don't know > how many copies were sold. But source code was necessary to take full > advantage of RESQ so the PL/I source was included on the tapes. > > When OSF was announced, with the intention of making AIX source available > to the other OSF companies, I was stunned because it was so > uncharacteristic of the IBM I thought I knew. It would be interesting to > know how that would have worked out if OSF had stuck with AIX and IBM had > delivered the source on the schedule everyone hoped for, but that's on a > different timeline than this one. > > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter > : > CharlesHSauer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Feb 20 23:15:07 2020 From: crossd at gmail.com (Dan Cross) Date: Thu, 20 Feb 2020 08:15:07 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <26D76662-B9A6-4BBB-9D23-6D1E4EE27782@cfcl.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <26D76662-B9A6-4BBB-9D23-6D1E4EE27782@cfcl.com> Message-ID: On Thu, Feb 20, 2020 at 2:44 AM Rich Morin wrote: > I looked at Solaris very briefly and decided that it wasn't my idea > of a proper (read, BSD) Unix system. So, I kept my Sun running SunOS > until I finally replaced it with a FreeBSD box. > I got the Unix-on-PCs religion sometime in the mid-'90s after Sun's shift to Solaris and SVR4 and FreeBSD was my ecclesiastic weapon of choice after a brief flirtation with Linux. I will admit, with a small amount of shame, that I still carry around a bit of that chauvinism, though now driven primarily by nostalgia instead of belief in technical superiority. When I was in high school, the folks I looked up to told me, "BSD is the stuff; SysV is garbage" and not knowing anything, I adopted that as a sort of "four legs good, two legs bad" kinda mantra. I liked Sun machines because they were what the cool people were using, but the move to Solaris felt like a betrayal and I started looking for alternatives. The Alpha was promising, but didn't make a lot of local headway. SGIs were neat but felt like high-end toys for graphics weenies and Irix was too weird for my taste. PCs were getting fast, though, and within a couple of years we went from my 486DX/33 to 200 MHz Pentiums and FreeBSD was real, so that seemed like the way forward. It amazed me how everyone around me kind of rolled over, threw their hands up and said, "Oh well, I guess we all have to run Solaris now...." Wait, what? Why? I remember being dismayed that no one else saw the potential for running essentially gratis software on cheap, fast hardware, and that the same people who gladly put down multiple hundreds of thousands of dollars for a VAX a decade prior, but then threw away the vendor-supplied OS and installed 4.3BSD now were so concerned about things like, "vendor support" that they couldn't see to doing essentially the same thing, but at much lower overall cost. What a time.... - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 21 02:23:08 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 20 Feb 2020 08:23:08 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002200727.01K7RFwj014313@freefriends.org> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> Message-ID: <20200220162308.GK30841@mcvoy.com> On Thu, Feb 20, 2020 at 12:27:15AM -0700, arnold at skeeve.com wrote: > Michael Huff wrote: > As Larry and others have pointed out, the unbundling of various components > was a big mistake by the vendors. It just made users angry and motivated > them to switch to other Unix systems. I really fault Sun for that one. There was a time when every open source package "just worked (TM)" if you built it on a Sun. All the other platforms were fiddly (leading to that monstrosity called autoconf), Sun just worked. So developers fought hard to get a Sun over the other platforms. When you have that lead and you screw over the people who gave you that lead, yeah, shame on you, Sun. > Also, early Solaris was a dog. Performance was poor. It improved over > time, but it wasn't until around Solaris 2.4 or 2.5 that running it > wasn't painful. Early Solaris was awful, just awful. They pulled out sockets and replaced them with Lachman's STREAMS based TCP/IP stack (really convergent's stack, I believe Lachman bought it from them). Performance was horrible, they brought in Mentat's stack and had to work on that, and eventually they brought back sockets. I dunno if there is any STREAMS stuff left, that was a horrible idea. Another idea, not sure if this shipped or not, was to use a thread for each 8K block headed to disk. The kernel stack was 24K (which is nuts but that's another story). So think about what a dd if=/dev/zero of=XXX does to your system. Each I/O costs you 8K (data) + 24K (stack) not to mention the other overhead for a thread. It means you only get to use 25% of ram for dirty pages. Bat shit crazy, right? I pointed all that out to the VM / FS people and they did it anyway, they were in love with threads. It was just as awful as I predicted and they ripped it all out and started over. To this day, I'm baffled that I could see that that was a horrible idea and really smart people did not. Lots of those people were smarter than me. It speaks to why you shouldn't push your shiny new feature too hard. And it lead to these in http://www.mcvoy.com/lm/quotes.html Think of it this way: threads are like salt, not like pasta. You like salt, I like salt, we all like salt. But we eat more pasta. --me A computer is a state machine. Threads are for people who can't program state machines. --Alan Cox Both very on point for the Sun people. From krewat at kilonet.net Fri Feb 21 02:34:36 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 20 Feb 2020 11:34:36 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220162308.GK30841@mcvoy.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> Message-ID: <39d767c7-3882-6219-c42d-d0178bd0d43a@kilonet.net> On 2/20/2020 11:23 AM, Larry McVoy wrote: > > Early Solaris was awful, just awful. They pulled out sockets and replaced > them with Lachman's STREAMS based TCP/IP stack (really convergent's stack, > I believe Lachman bought it from them). Performance was horrible, they > brought in Mentat's stack and had to work on that, and eventually they > brought back sockets. I dunno if there is any STREAMS stuff left, that > was a horrible idea. > It's still there. Not sure if it's used for more than a console keyboard driver anymore, but from a Solaris 11.3 machine: more /usr/include/sys/stream.h /*  * Copyright (c) 1988, 2016, Oracle and/or its affiliates. All rights reserved.  */ #ifndef _SYS_STREAM_H #define _SYS_STREAM_H /*  * For source compatibility  */ #include #ifdef _KERNEL #include #endif #include #include #include #include #include #ifdef  __cplusplus extern "C" { #endif ... From cym224 at gmail.com Fri Feb 21 02:48:03 2020 From: cym224 at gmail.com (Nemo) Date: Thu, 20 Feb 2020 11:48:03 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002200727.01K7RFwj014313@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> Message-ID: On 20/02/2020, arnold at skeeve.com wrote (in part): > Also, early Solaris was a dog. Performance was poor. It improved over > time, but it wasn't until around Solaris 2.4 or 2.5 that running it wasn't painful. I recall that Sun salesfolk came in to sell us something-or-other and freely admitted that Slowlaris did not improve until dtrace came along, at which point Sun dived into system calls. N. From lm at mcvoy.com Fri Feb 21 03:00:06 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 20 Feb 2020 09:00:06 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> Message-ID: <20200220170006.GM30841@mcvoy.com> On Thu, Feb 20, 2020 at 11:48:03AM -0500, Nemo wrote: > On 20/02/2020, arnold at skeeve.com wrote (in part): > > Also, early Solaris was a dog. Performance was poor. It improved over > > time, but it wasn't until around Solaris 2.4 or 2.5 that running it wasn't painful. > > I recall that Sun salesfolk came in to sell us something-or-other and > freely admitted that Slowlaris did not improve until dtrace came > along, at which point Sun dived into system calls. I was the lead guy on Sun's first cluster product, I developed it on SunOS 4.x but Scott wouldn't let me ship that, it had to be Solaris. Which screwed performance, it was an NFS server so all that traffic was going through STREAMS, it was awful. I gave a pitch for that product at the Moscone center and had to endure heckle after heckle about 5.x vs 4.x. I toed the party line for as long as I could and finally I had enough and said something like "I know. 5.x sucks, it just does, but that's what I have to ship with." It was taped. Ken Okin, my boss and senior VP of all server hardware, heard the tape, came to me and said "Find and destroy all copies of that tape. Now!" It was not a fun time. From aek at bitsavers.org Fri Feb 21 03:06:02 2020 From: aek at bitsavers.org (Al Kossow) Date: Thu, 20 Feb 2020 09:06:02 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220162308.GK30841@mcvoy.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> Message-ID: <254d5b01-00ba-a388-4357-68d0dc047e46@bitsavers.org> On 2/20/20 8:23 AM, Larry McVoy wrote: > A computer is a state machine. Threads are for people who can't > program state machines. And now the world runs on threads and (current fashonable OOPL) It makes my brain hurt. From bakul at bitblocks.com Fri Feb 21 03:24:50 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 20 Feb 2020 09:24:50 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: Your message of "Thu, 20 Feb 2020 08:23:08 -0800." <20200220162308.GK30841@mcvoy.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> Message-ID: <20200220172457.80063156E411@mail.bitblocks.com> On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy wrote: > > Think of it this way: threads are like salt, not like pasta. You > like salt, I like salt, we all like salt. But we eat more pasta. Go is quite salty! Erlang even more so. > A computer is a state machine. Threads are for people who can't > program state machines. I have written both event based (state machine) and thread based programs. Each style has its pros and cons. Control flow is cleaner in threads but managing shared state is trickier. In state machines managing state is easier but control flow is a pain. Not to mention state machine don't benefit from multiple h/w threads. From rdm at cfcl.com Fri Feb 21 03:48:58 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 20 Feb 2020 09:48:58 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220172457.80063156E411@mail.bitblocks.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> <20200220172457.80063156E411@mail.bitblocks.com> Message-ID: <0FB634BD-F939-425B-AD22-90291268990C@cfcl.com> FWIW, I've been enjoying Elixir a lot for the past few years. It's an Actor-based, dynamically typed, FP language that runs on the Erlang VM. It has Rubyish syntax, pattern matching, syntactic macros, lightweight processes, a message-passing framework, supervision trees, and other cool stuff. I will note, however, that Elixir programming tends to be rather different from the stuff I've been doing for the past 50 years. For example, processing pipelines tend to replace sets of nested loops... -r > On Feb 20, 2020, at 09:24, Bakul Shah wrote: > > On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy wrote: >> >> Think of it this way: threads are like salt, not like pasta. You >> like salt, I like salt, we all like salt. But we eat more pasta. > > Go is quite salty! Erlang even more so. > >> A computer is a state machine. Threads are for people who can't >> program state machines. > > I have written both event based (state machine) and thread > based programs. Each style has its pros and cons. Control > flow is cleaner in threads but managing shared state is > trickier. In state machines managing state is easier but > control flow is a pain. Not to mention state machine don't > benefit from multiple h/w threads. From dave at horsfall.org Fri Feb 21 05:16:14 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 21 Feb 2020 06:16:14 +1100 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002200727.01K7RFwj014313@freefriends.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <4d252035b323b7583c5760c952d1982c@firemail.de> <202002171839.01HId8FT1358073@darkstar.fourwinds.com> <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> Message-ID: On Thu, 20 Feb 2020, arnold at skeeve.com wrote: [ ... ] > Also, early Solaris was a dog. Performance was poor. It improved over > time, but it wasn't until around Solaris 2.4 or 2.5 that running it > wasn't painful. That's why we called it Slowaris... -- Dave From bakul at bitblocks.com Fri Feb 21 06:10:00 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 20 Feb 2020 12:10:00 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: Your message of "Thu, 20 Feb 2020 09:48:58 -0800." <0FB634BD-F939-425B-AD22-90291268990C@cfcl.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> <20200220172457.80063156E411@mail.bitblocks.com> <0FB634BD-F939-425B-AD22-90291268990C@cfcl.com> Message-ID: <20200220201007.6C323156E413@mail.bitblocks.com> On Thu, 20 Feb 2020 09:48:58 -0800 Rich Morin wrote: > FWIW, I've been enjoying Elixir a lot for the past few years. It's an > Actor-based, dynamically typed, FP language that runs on the Erlang VM. > It has Rubyish syntax, pattern matching, syntactic macros, lightweight > processes, a message-passing framework, supervision trees, and other > cool stuff. I haven't gotten around to playing with Elixir yet.... Nit: I thought Erlang designers weren't aware of Hewitt's Actor model before they designed the language; it just happened to map to the Actor model very well. > I will note, however, that Elixir programming tends to be rather > different from the stuff I've been doing for the past 50 years. For > example, processing pipelines tend to replace sets of nested loops... No Stinking Loops! I am familiar with that from the perspective of array programming languages. Arrays and streams have quite a bit in common. [At times I have wanted a more powerful APL like shell, where things like wc, grep, sort, group, join etc. are builtins.] From rdm at cfcl.com Fri Feb 21 06:18:52 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 20 Feb 2020 12:18:52 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220201007.6C323156E413@mail.bitblocks.com> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <202002200727.01K7RFwj014313@freefriends.org> <20200220162308.GK30841@mcvoy.com> <20200220172457.80063156E411@mail.bitblocks.com> <0FB634BD-F939-425B-AD22-90291268990C@cfcl.com> <20200220201007.6C323156E413@mail.bitblocks.com> Message-ID: > On Feb 20, 2020, at 12:10, Bakul Shah wrote: > > Nit: I thought Erlang designers weren't aware of Hewitt's > Actor model before they designed the language; it just > happened to map to the Actor model very well. True, but after the fact everyone decided that Erlang was really doing Actors. FWIW, here's an interesting session on that sort of thing: https://www.youtube.com/watch?v=37wFVVVZlVU Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt with host Francesco Cesarini. When considering the panel to discuss concurrency, you’d be pushed to find a higher calibre than Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. All greats within the industry and beyond, they give an amazing insight into the lifeline of concurrency and actor models over the past few decades, their bountiful experiences within the concurrency field, and where they see concurrency heading in the future. -r From merlyn at geeks.org Fri Feb 21 09:45:01 2020 From: merlyn at geeks.org (Doug McIntyre) Date: Thu, 20 Feb 2020 17:45:01 -0600 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> Message-ID: <20200220234501.GB85208@geeks.org> On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff wrote: > It was said earlier that SunOS included a compiler, but it was dropped > in Solaris. Was it possible for people to carry over the old SunOS > compiler and use it on Solaris? Did people do that, or did they just > have their companies spring for the actual Solaris compiler? SunOS's compiler that shipped with it wasn't that usable. It didn't fully support the C standards at the time. It was used primarily for two things. *) To compile the few kernel objects that were shipped as source & to link in all the binary objects into one new kernel for patching/tuning. *) To bootstrap GCC so one had a usable compiler to build packages. GCC had special code used for the bootstrap process specificly at the time on SunOS, written in a level that the SunOS compiler could deal with. Otherwise, it could only be used for simple projects. As others stated, the output of the compiler would have been a.out, and not ELF like Solaris 2.x would have needed. Some people equate SunOS from a time when all Unices still had (usable) compilers, but that was actually an earlier time frame. Sun was selling its standards compliant compilers for SunOS before Solaris 2.x was around. From imp at bsdimp.com Fri Feb 21 10:18:55 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 20 Feb 2020 17:18:55 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220234501.GB85208@geeks.org> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <20200220234501.GB85208@geeks.org> Message-ID: On Thu, Feb 20, 2020, 4:51 PM Doug McIntyre wrote: > On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff wrote: > > It was said earlier that SunOS included a compiler, but it was dropped > > in Solaris. Was it possible for people to carry over the old SunOS > > compiler and use it on Solaris? Did people do that, or did they just > > have their companies spring for the actual Solaris compiler? > > SunOS's compiler that shipped with it wasn't that usable. It didn't fully > support > the C standards at the time. > > It was used primarily for two things. > > *) To compile the few kernel objects that were shipped as source & to > link in all the binary objects into one new kernel for patching/tuning. > > *) To bootstrap GCC so one had a usable compiler to build packages. GCC > had special code used for the bootstrap process specificly at the time > on SunOS, written in a level that the SunOS compiler could deal with. > > Otherwise, it could only be used for simple projects. > > As others stated, the output of the compiler would have been a.out, and > not ELF like Solaris 2.x would have needed. > > Some people equate SunOS from a time when all Unices still had (usable) > compilers, > but that was actually an earlier time frame. Sun was selling its > standards compliant compilers for SunOS before Solaris 2.x was around. > IIRC, The K&R compiler was free. The ANSI 89 one cost $$$. It was this change in policy that caused much consternation in the Sun users community. It happened around 91 or 92. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Fri Feb 21 11:14:20 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 20 Feb 2020 20:14:20 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <20200220234501.GB85208@geeks.org> Message-ID: On 02/20/20 19:18, Warner Losh wrote: > IIRC, The K&R compiler was free. The ANSI 89 one cost $$$. It was this > change in policy that caused much consternation in the Sun users > community. It happened around 91 or 92. For what it's worth, HP-UX (for PA-RISC, at least) shipped with a free K&R compiler that compiled a kernel specific to the box. However, I seem to recall that it could not compile GCC so no bootstrapping there. N. > > Warner > From thomas.paulsen at firemail.de Fri Feb 21 18:17:21 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 21 Feb 2020 09:17:21 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <20200220234501.GB85208@geeks.org> References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <20200220234501.GB85208@geeks.org> Message-ID: >SunOS's compiler that shipped with it wasn't that usable. It didn't fully support the C standards at the time. >It was used primarily for two things.... >*) To bootstrap GCC so one had a usable compiler to build packages. so this can only be true for later not to say final days of sun-o2, as gcc wasn't available before. Was it Stephen's pcc or Dennis CC? From thomas.paulsen at firemail.de Fri Feb 21 18:19:00 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 21 Feb 2020 09:19:00 +0100 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <20200220234501.GB85208@geeks.org> Message-ID: <2451b170cd221c4fdd066227571985a3@firemail.de> An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Feb 21 20:17:51 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 21 Feb 2020 03:17:51 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002180017.01I0HI0I1415945@darkstar.fourwinds.com> <20200219044444.GO30841@mcvoy.com> <615399517.295857.1582135972871@email.ionos.co.uk> <20200220234501.GB85208@geeks.org> Message-ID: <202002211017.01LAHpfN032125@freefriends.org> "Thomas Paulsen" wrote: > >SunOS's compiler that shipped with it wasn't that usable. It didn't > >fully support the C standards at the time. > >It was used primarily for two things.... > >*) To bootstrap GCC so one had a usable compiler to build packages. > > so this can only be true for later not to say final days of sun-o2, > as gcc wasn't available before. > > Was it Stephen's pcc or Dennis CC? It was PCC based. Once PCC became available with V7, it was used for porting pretty universally. The 'P' stood for "portable" after all; it was explicitly designed for retargeting. Arnold From egbegb2 at gmail.com Fri Feb 21 20:37:01 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Fri, 21 Feb 2020 04:37:01 -0600 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> Message-ID: I also worked with LSX - a stripped down version of Unix that required no MMU. It worked on a PDP 11/03 and we delivered an LSX product to the telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is that true? Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC? Ed Bradford, BTL 1976-1983 Columbus and Whippany On Mon, Feb 17, 2020 at 9:22 AM Doug McIlroy wrote: > > > one of the things I wanted to do in my retirement was convert > > all the stuff that is in debian back from info to man(7) > > *all* the stuff? Please don't do that literally. The garrulity > quotient of info pages dwarfs even that of the most excessive > modern man pages. But I appplaud the intent to assure man > pages are complete. > > Doug > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Sat Feb 22 04:34:31 2020 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 21 Feb 2020 10:34:31 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> Message-ID: <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Not true. LSX was developed by yours truly during the mid-70's while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978, page 2087-2101. It was developed to support some real-time features like contiguous files and asynchronous I/O. A number of groups in Bell Labs used LSX and added device drivers to support their dedicated applications. Western Electric (WE) was responsible for licensing the UNIX system at the time and only provided source code for the UNIX system for the PDP11 computer with an MMU for $20K. LSX source code was not included in this. I also developed (actually modified and wrote device drivers for) a version of the UNIX system that ran on the PDP11/10 computer, which also did not have an MMU. It could support up to four users. I believe that the source code for this system (Mini-UNIX) was provided to some universities by the UNIX Support group at Bell Labs. WE did not license this. I do not believe that WE ever considered licensing a binary version of LSX or the UNIX System to run on the IBM PC or any other microcomputer. WE only offered binary licenses later on, and then only for the PDP11 with an MMU first. In hindsight, a missed opportunity, but that's another story. Doug may be able to offer some insight into this as well. Thanks for asking, Heinz Lycklama On 2/21/2020 2:37 AM, Ed Bradford wrote: > I also worked with LSX - a stripped down version of Unix that required > no MMU. It worked on a PDP 11/03 and we delivered an LSX product to > the telco's based on LSX. My faulty memory tells me Mike Lesk created > LSX. Is that true? > > Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC? > > Ed Bradford, BTL 1976-1983 > Columbus and Whippany -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Feb 22 04:59:14 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 21 Feb 2020 11:59:14 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Message-ID: On Fri, Feb 21, 2020, 11:35 AM Heinz Lycklama wrote: > Not true. LSX was developed by yours truly during the mid-70's > while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978, > page 2087-2101. It was developed to support some real-time > features like contiguous files and asynchronous I/O. A number > of groups in Bell Labs used LSX and added device drivers to > support their dedicated applications. > > Western Electric (WE) was responsible for licensing the UNIX system > at the time and only provided source code for the UNIX system for > the PDP11 computer with an MMU for $20K. LSX source code > was not included in this. > > I also developed (actually modified and wrote device drivers for) > a version of the UNIX system that ran on the PDP11/10 computer, > which also did not have an MMU. It could support up to four users. > I believe that the source code for this system (Mini-UNIX) was > provided to some universities by the UNIX Support group at > Bell Labs. WE did not license this. > The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. People offered copies to any Unix licensees. Most of these were universities. Warner I do not believe that WE ever considered licensing a binary > version of LSX or the UNIX System to run on the IBM PC or > any other microcomputer. WE only offered binary licenses > later on, and then only for the PDP11 with an MMU first. > In hindsight, a missed opportunity, but that's another story. > > Doug may be able to offer some insight into this as well. > > Thanks for asking, > > Heinz Lycklama > > On 2/21/2020 2:37 AM, Ed Bradford wrote: > > I also worked with LSX - a stripped down version of Unix that required no > MMU. It worked on a PDP 11/03 and we delivered an LSX product to the > telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is > that true? > > Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC? > > Ed Bradford, BTL 1976-1983 > Columbus and Whippany > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 22 07:10:29 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 22 Feb 2020 08:10:29 +1100 (EST) Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Message-ID: On Fri, 21 Feb 2020, Warner Losh wrote: > The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. > People offered copies to any Unix licensees. Most of these were > universities.  It was fun to play with, but as the name implies it was pretty limited. I recall I got it working on one of those DEC PDT things, with 8" floppies; you had to turn off "/etc/update" otherwise it wore a groove where inode 1 was, or was it /dev/tty8? Something like that... -- Dave From wkt at tuhs.org Sat Feb 22 07:29:06 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 22 Feb 2020 07:29:06 +1000 Subject: [TUHS] Crabs Message-ID: <20200221212906.GA12694@minnie.tuhs.org> Just saw this in a tweet by Charlie Stross: How AT&T's Bell Labs became infected with crabs (in 1985): http://lucacardelli.name/Papers/Crabs.pdf Cheers, Warren From david at kdbarto.org Sat Feb 22 07:46:21 2020 From: david at kdbarto.org (David Barto) Date: Fri, 21 Feb 2020 13:46:21 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Message-ID: It was /etc/update. I used one of these in the Psych department at UCSD. When it started going weird I shut it down and removed the floppy. As you mentioned, the tracks at the start of the disk were worn smooth. David > On Feb 21, 2020, at 1:10 PM, Dave Horsfall wrote: > > On Fri, 21 Feb 2020, Warner Losh wrote: > >> The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. People offered copies to any Unix licensees. Most of these were universities. > > It was fun to play with, but as the name implies it was pretty limited. > > I recall I got it working on one of those DEC PDT things, with 8" floppies; you had to turn off "/etc/update" otherwise it wore a groove where inode 1 was, or was it /dev/tty8? Something like that... > > -- Dave From steffen at sdaoden.eu Sat Feb 22 08:43:00 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 21 Feb 2020 23:43:00 +0100 Subject: [TUHS] Crabs In-Reply-To: <20200221212906.GA12694@minnie.tuhs.org> References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: <20200221224300.ZEWCk%steffen@sdaoden.eu> Warren Toomey wrote in <20200221212906.GA12694 at minnie.tuhs.org>: |Just saw this in a tweet by Charlie Stross: | |How AT&T's Bell Labs became infected with crabs (in 1985): | |http://lucacardelli.name/Papers/Crabs.pdf Money for nothing, and your crabs for free. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dave at horsfall.org Sat Feb 22 10:01:38 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 22 Feb 2020 11:01:38 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: <20200221212906.GA12694@minnie.tuhs.org> References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: On Sat, 22 Feb 2020, Warren Toomey wrote: > http://lucacardelli.name/Papers/Crabs.pdf Sheer genius in its simplicity of implementation! For some reason I am reminded of "xroach": I used to surprise my cow-orkers with it... -- Dave From egbegb2 at gmail.com Sat Feb 22 16:48:25 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Sat, 22 Feb 2020 00:48:25 -0600 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Message-ID: Thank you Heinz for correcting my poor memory. I don't think we ever met. Using LSX was a fun project. LSX was before DOS and far better than any DOS in my view. Thank you for responding. Ed On Fri, Feb 21, 2020 at 12:35 PM Heinz Lycklama wrote: > Not true. LSX was developed by yours truly during the mid-70's > while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978, > page 2087-2101. It was developed to support some real-time > features like contiguous files and asynchronous I/O. A number > of groups in Bell Labs used LSX and added device drivers to > support their dedicated applications. > > Western Electric (WE) was responsible for licensing the UNIX system > at the time and only provided source code for the UNIX system for > the PDP11 computer with an MMU for $20K. LSX source code > was not included in this. > > I also developed (actually modified and wrote device drivers for) > a version of the UNIX system that ran on the PDP11/10 computer, > which also did not have an MMU. It could support up to four users. > I believe that the source code for this system (Mini-UNIX) was > provided to some universities by the UNIX Support group at > Bell Labs. WE did not license this. > > I do not believe that WE ever considered licensing a binary > version of LSX or the UNIX System to run on the IBM PC or > any other microcomputer. WE only offered binary licenses > later on, and then only for the PDP11 with an MMU first. > In hindsight, a missed opportunity, but that's another story. > > Doug may be able to offer some insight into this as well. > > Thanks for asking, > > Heinz Lycklama > > On 2/21/2020 2:37 AM, Ed Bradford wrote: > > I also worked with LSX - a stripped down version of Unix that required no > MMU. It worked on a PDP 11/03 and we delivered an LSX product to the > telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is > that true? > > Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC? > > Ed Bradford, BTL 1976-1983 > Columbus and Whippany > > > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigosloop at gmail.com Sat Feb 22 18:04:45 2020 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sat, 22 Feb 2020 09:04:45 +0100 Subject: [TUHS] Crabs In-Reply-To: References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: here is the source for a working plan 9 version: http://www.9front.org/extra/crabs.tgz fun to watch. On Sat, Feb 22, 2020, 1:02 AM Dave Horsfall wrote: > On Sat, 22 Feb 2020, Warren Toomey wrote: > > > http://lucacardelli.name/Papers/Crabs.pdf > > Sheer genius in its simplicity of implementation! For some reason I am > reminded of "xroach": I used to surprise my cow-orkers with it... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat Feb 22 20:42:32 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 22 Feb 2020 02:42:32 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> Message-ID: <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> On 2/21/20 10:34 AM, Heinz Lycklama wrote: > I believe that the source code for this system (Mini-UNIX) was > provided to some universities by the UNIX Support group at > Bell Labs. WE did not license this. tape image at http://bitsavers.org/bits/ATT/mini-unix_120679.zip From egbegb2 at gmail.com Sat Feb 22 21:01:23 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Sat, 22 Feb 2020 05:01:23 -0600 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: What is the legal status of such old, no longer useful source code? On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > On 2/21/20 10:34 AM, Heinz Lycklama wrote: > > > I believe that the source code for this system (Mini-UNIX) was > > provided to some universities by the UNIX Support group at > > Bell Labs. WE did not license this. > > tape image at > http://bitsavers.org/bits/ATT/mini-unix_120679.zip > > > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From egbegb2 at gmail.com Sat Feb 22 21:08:07 2020 From: egbegb2 at gmail.com (Ed Bradford) Date: Sat, 22 Feb 2020 05:08:07 -0600 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: How do I open a .tap file in the .zip file for mini-unix? Also, do you have a date for this snapshot. A date would be very useful for "product comparisons" at that date. Ed On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > On 2/21/20 10:34 AM, Heinz Lycklama wrote: > > > I believe that the source code for this system (Mini-UNIX) was > > provided to some universities by the UNIX Support group at > > Bell Labs. WE did not license this. > > tape image at > http://bitsavers.org/bits/ATT/mini-unix_120679.zip > > > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Feb 23 02:38:28 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 22 Feb 2020 09:38:28 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: This should be covered by the ancient Unix license since it is derived from V6. Warner On Sat, Feb 22, 2020, 4:02 AM Ed Bradford wrote: > What is the legal status of such old, no longer useful source code? > > > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > >> On 2/21/20 10:34 AM, Heinz Lycklama wrote: >> >> > I believe that the source code for this system (Mini-UNIX) was >> > provided to some universities by the UNIX Support group at >> > Bell Labs. WE did not license this. >> >> tape image at >> http://bitsavers.org/bits/ATT/mini-unix_120679.zip >> >> >> > > -- > Advice is judged by results, not by intentions. > Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Feb 23 02:40:26 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 22 Feb 2020 09:40:26 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: On Sat, Feb 22, 2020, 4:08 AM Ed Bradford wrote: > How do I open a .tap file in the .zip file for mini-unix? > Also, do you have a date for this snapshot. A date would be > very useful for "product comparisons" at that date. > The file name suggests Dec 6, 1979, though that's us centric and it could be June 12, 79 as well... Warner Ed > > > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > >> On 2/21/20 10:34 AM, Heinz Lycklama wrote: >> >> > I believe that the source code for this system (Mini-UNIX) was >> > provided to some universities by the UNIX Support group at >> > Bell Labs. WE did not license this. >> >> tape image at >> http://bitsavers.org/bits/ATT/mini-unix_120679.zip >> >> >> > > -- > Advice is judged by results, not by intentions. > Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Feb 23 02:46:51 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 22 Feb 2020 11:46:51 -0500 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: .tap files are simh format files and 'look like a mag-tape' to the simulated tape hardware. There are tools that will convert to/from Bob's Simulator format as needed. On Sat, Feb 22, 2020 at 6:08 AM Ed Bradford wrote: > How do I open a .tap file in the .zip file for mini-unix? > Also, do you have a date for this snapshot. A date would be > very useful for "product comparisons" at that date. > > Ed > > > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > >> On 2/21/20 10:34 AM, Heinz Lycklama wrote: >> >> > I believe that the source code for this system (Mini-UNIX) was >> > provided to some universities by the UNIX Support group at >> > Bell Labs. WE did not license this. >> >> tape image at >> http://bitsavers.org/bits/ATT/mini-unix_120679.zip >> >> >> > > -- > Advice is judged by results, not by intentions. > Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Sun Feb 23 03:51:03 2020 From: heinz at osta.com (Heinz Lycklama) Date: Sat, 22 Feb 2020 09:51:03 -0800 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: <79463cdf-341d-fad0-b4bf-132762b968d6@osta.com> OK, that does look like the official Mini-UNIX release from Bell Labs in 1979. I'd have to look at the files in the .tap file to verify this. Note the name Mini-UNIX was also used by Andrew Tanenbaum for the system he developed at Vrije Universiteit in Amsterdam much later in 1987 independent of the Mini-UNIX that I developed at Bell Labs in the mid 1970's. See here: https://en.wikipedia.org/wiki/MINIX Heinz On 2/22/2020 8:46 AM, Clem Cole wrote: > .tap files are simh format files  and > 'look like a mag-tape' to the simulated tape hardware. > There are tools that will convert to/from Bob's Simulator format as > needed. > > On Sat, Feb 22, 2020 at 6:08 AM Ed Bradford > wrote: > > How do I open a .tap file in the .zip file for mini-unix? > Also, do you have a date for this snapshot. A date would be > very useful for "product comparisons" at that date. > > Ed > > > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow > wrote: > > On 2/21/20 10:34 AM, Heinz Lycklama wrote: > > > I believe that the source code for this system (Mini-UNIX) was > > provided to some universities by the UNIX Support group at > > Bell Labs. WE did not license this. > > tape image at > http://bitsavers.org/bits/ATT/mini-unix_120679.zip > > > > > -- > Advice is judged by results, not by intentions. >   Cicero > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Feb 23 04:11:28 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 22 Feb 2020 11:11:28 -0700 Subject: [TUHS] man Macro Package and pdfmark In-Reply-To: References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> Message-ID: <202002221811.01MIBSMu026637@freefriends.org> Warren, do you want to grab this for the archive also? Thanks, Arnold Warner Losh wrote: > This should be covered by the ancient Unix license since it is derived from > V6. > > Warner > > On Sat, Feb 22, 2020, 4:02 AM Ed Bradford wrote: > > > What is the legal status of such old, no longer useful source code? > > > > > > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow wrote: > > > >> On 2/21/20 10:34 AM, Heinz Lycklama wrote: > >> > >> > I believe that the source code for this system (Mini-UNIX) was > >> > provided to some universities by the UNIX Support group at > >> > Bell Labs. WE did not license this. > >> > >> tape image at > >> http://bitsavers.org/bits/ATT/mini-unix_120679.zip > >> > >> > >> > > > > -- > > Advice is judged by results, not by intentions. > > Cicero > > > > From dave at horsfall.org Sun Feb 23 06:34:44 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 23 Feb 2020 07:34:44 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: On Sat, 22 Feb 2020, Rodrigo G. López wrote: > here is the source for a working plan 9 version: > http://www.9front.org/extra/crabs.tgz > fun to watch. Thanks; I don't have Plan 9, but the source ought to be interesting. -- Dave From steffen at sdaoden.eu Sun Feb 23 08:07:44 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 22 Feb 2020 23:07:44 +0100 Subject: [TUHS] Crabs In-Reply-To: References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: <20200222220744.qlBe1%steffen@sdaoden.eu> Dave Horsfall wrote in : |On Sat, 22 Feb 2020, Rodrigo G. López wrote: | |> here is the source for a working plan 9 version: |> http://www.9front.org/extra/crabs.tgz |> fun to watch. | |Thanks; I don't have Plan 9, but the source ought to be interesting. I'm on Fire Time after Time, Easy Lover, Born in the U.S.A.! I Want to Know What Love Is, Like a Virgin. Careless Whisper On the Nightshift. We Built This City Part-Time Lover. Boys Of Summer Things Can Only Get Better. Walking On Sunshine We Don't Need Another Hero! You're the Inspiration. Too Late for Goodbyes. Don't Lose My Number. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dave at horsfall.org Sun Feb 23 08:10:51 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 23 Feb 2020 09:10:51 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: > Thanks; I don't have Plan 9, but the source ought to be interesting. And the source is amazingly simple; mind you, most of the work is done by the libraries. -- Dave From bakul at bitblocks.com Sun Feb 23 08:12:34 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 22 Feb 2020 14:12:34 -0800 Subject: [TUHS] Crabs In-Reply-To: Your message of "Sun, 23 Feb 2020 07:34:44 +1100." References: <20200221212906.GA12694@minnie.tuhs.org> Message-ID: <20200222221241.AAEFD156E411@mail.bitblocks.com> On Sun, 23 Feb 2020 07:34:44 +1100 Dave Horsfall wrote: > > On Sat, 22 Feb 2020, Rodrigo G. López wrote: > > > here is the source for a working plan 9 version: > > http://www.9front.org/extra/crabs.tgz > > fun to watch. > > Thanks; I don't have Plan 9, but the source ought to be interesting. You can run it under plan9ports. git clone https://github.com/9fans/plan9port.git cd plan9ports ./INSTALL # You may have to setenv PLAN9 to the above dir. I am not sure. tar xf crabs.tgz cd crabs # fix an unnamed parameter ed crabs.c < References: <202002171520.01HFKqKi026749@tahoe.cs.Dartmouth.EDU> <5a37e3af-0226-8080-533a-e2428646ce7d@osta.com> <1ee1bad8-e77b-53e8-94c4-79b080df3c43@bitsavers.org> <202002221811.01MIBSMu026637@freefriends.org> Message-ID: <20200222234146.GA3919@minnie.tuhs.org> On Sat, Feb 22, 2020 at 11:11:28AM -0700, arnold at skeeve.com wrote: > Warren, do you want to grab this for the archive also? Already there in https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/Kossow/ Thanks for the heads-up, though! Cheers, Warren From wkt at tuhs.org Sun Feb 23 09:52:24 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 23 Feb 2020 09:52:24 +1000 Subject: [TUHS] Tech memos from Heinz on MERT and others Message-ID: <20200222235224.GA6133@minnie.tuhs.org> All, Heinz Lycklama has shared a binder full of old technical memos with Clem Cole, who has scanned them in. Thanks to both of them for preserving these documents. I've just put them at: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/ Here's a list of the documents: A_Minicomputer_Satellite_Processor_System.pdf A_Virtual_Memory_Mini-Computer_System_516-TSS.pdf MM-71-1383-3_Performance_Simulation_and_Measurement_of_a_Virtual_Memory_Multi-progamming_System_for_a_Small_Computer_19710120.pdf MM-72-1353-16_Bus_Interface_in_a_Single_Bus_Multi-processor_Environment_19720920.pdf Office_Communication_Research_in_Lab_135_19770208.pdf TM-74-1352-1_Implementstion_of_Large_Contiguous_Files_and_Asynchronous_IO_in_UNIX_19740104.pdf TM-74-1352-7_Plotting_Facilities_for_Mini-Computer_Systems_19740614.pdf TM-75-1352-2_Emulation_of_UNIX_on_Peripheral_Processors_19750109.pdf TM-75-1352-3_GLANCE_Terminals_on_UNIX_Time-Sharing_19750303.pdf TM-75-1352-4_A_Structured_Operating_System_for_a_PDP-11.45_19750506.pdf TM-75-1352-7_MERT_A_Multi-Environment_Real-Time_Operating_System_19751118.pdf TM-77-1352-1_The_MINI-UNIX_19770103.pdf TM-78-3114-1_UNIX_on_a_Microprocessor_19780322.pdf TM-78-3114-2_A_Minicomputer_Satellite_Processor_System_19780322.pdf TM-78-3114-3_The_MERT_Operating_System_19780422.pdf TM-78-3114-4_The_MERT-UNIX_Supervisor_19780420.pdf TM-78-3114-5_File_System_Structures_for_Real-Time_Applications_19780420.pdf The_MERT_Operating_System.pdf UNIX_on_a_Microprocessor_19780322.pdf Cheers, Warren From dave at horsfall.org Mon Feb 24 05:13:52 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 24 Feb 2020 06:13:52 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: <20200222221241.AAEFD156E411@mail.bitblocks.com> References: <20200221212906.GA12694@minnie.tuhs.org> <20200222221241.AAEFD156E411@mail.bitblocks.com> Message-ID: On Sat, 22 Feb 2020, Bakul Shah wrote: >> Thanks; I don't have Plan 9, but the source ought to be interesting. > > You can run it under plan9ports. [...] Thanks for the pointer. -- Dave From wkt at tuhs.org Mon Feb 24 06:27:07 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 24 Feb 2020 06:27:07 +1000 Subject: [TUHS] Fwd: Unix V0 on SIMH PDP-9 Message-ID: <20200223202707.GB16651@minnie.tuhs.org> All, I received this interesting e-mail from Michael Thompson: ----- Date: Fri, 21 Feb 2020 12:50:12 -0500 From: Michael Thompson To: Warren Toomey Subject: Unix V0 on SIMH PDP-9 I modified the PDP-7 .simh file so it will run on a SIMH PDP-9. (attached) We have a running PDP-9 at the RICM. If I added EAE, (we likely have the necessary parts) and made a disk emulator like the one at the LCM, we could also run UNIX V0 on it. It would be nice to have the disk emulator emulate an RB disk, but that would also require emulating a DMA adapter. I am considering making an FPGA to emulate the memory controller and 32KW of memory. If I did that, I could put the RB and DMA emulation in the same device. -- Michael Thompson ----- End forwarded message ----- set cpu 8k set cpu eae set cpu history=100 show cpu # set up SIMH devices: # UNIX character translations (CR to NL, ESC to ALTMODE): set tti unix # RB09 fixed head disk: set rb ena att rb image.fs # enable TELNET in GRAPHICS-2 keyboard/display(!!) #set g2in ena #att -U g2in 12345 # disable hardware UNIX-7 doesn't know about: set lpt disa set drm disa set dt disa set mt disa set rf disa set ttix disa set ttox disa # show device settings: show dev # load and run the paper tape bootstrap # (loads system from disk) load boot.rim 010000 go Cheers, Warren From stewart at serissa.com Mon Feb 24 08:13:36 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Sun, 23 Feb 2020 17:13:36 -0500 Subject: [TUHS] Crabs Message-ID: This explains something, I think! Luca Cardelli and Mark Manasse later worked at the Digital Systems Research Center in Palo Alto, which was formed in 1984 after PARC fired Bob Taylor. Mark helped write the window system we used, and at some point a cat appeared, which would sleep until you moved the mouse and then come over to pat at the mouse. My impression was that Luca wrote it, be he was cagy about it. This later evolved into xneko for X Windows. -Larry From jnc at mercury.lcs.mit.edu Mon Feb 24 08:39:04 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 23 Feb 2020 17:39:04 -0500 (EST) Subject: [TUHS] Tech memos from Heinz on MERT and others Message-ID: <20200223223904.2A5A018C09B@mercury.lcs.mit.edu> > From: Warren Toomey > Heinz Lycklama has shared a binder full of old technical memos with > Clem Cole, who has scanned them in. Thanks to both of them for > preserving these documents. A big thank you to Heinz and Clem for their roles in making this happen! Very interesting material. I live in hope that someday the source will turn up - even a listing would be enough. Noel From dave at horsfall.org Mon Feb 24 08:43:53 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 24 Feb 2020 09:43:53 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: References: Message-ID: On Sun, 23 Feb 2020, Lawrence Stewart wrote: [...] > This later evolved into xneko for X Windows. There were lots of similar programs springing up around that time, such as "xoj" (modelled after the famous O.J. Simpson car chase) etc. -- Dave From finnoleary at inventati.org Mon Feb 24 13:54:36 2020 From: finnoleary at inventati.org (Finn O'Leary) Date: Mon, 24 Feb 2020 03:54:36 +0000 Subject: [TUHS] Crabs In-Reply-To: References: Message-ID: <22d064af4a08c57b11c2a632d908e766@inventati.org> On 2020-02-23 22:43, Dave Horsfall wrote: > On Sun, 23 Feb 2020, Lawrence Stewart wrote: > > [...] > >> This later evolved into xneko for X Windows. > > There were lots of similar programs springing up around that time, > such as "xoj" (modelled after the famous O.J. Simpson car chase) etc. > > -- Dave A version of this that still compiles on modern systems can be found here :) http://www.daidouji.com/oneko/ It has a couple of settings to change the icons to various different characters - finn From athornton at gmail.com Tue Feb 25 01:32:35 2020 From: athornton at gmail.com (Adam Thornton) Date: Mon, 24 Feb 2020 08:32:35 -0700 Subject: [TUHS] [COFF] Fwd: Old and Tradition was V9 shell In-Reply-To: <20200224151929.GJ30841@mcvoy.com> References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: "I'd go to the local University that teaches Fortran and ask around." Aye, there's the rub. SIUE (Southern Illinois University at Edwardsville) still had a COBOL curriculum a decade ago, and they might still. They were fairly forthright in training people to go work at a lot of the stodgier St. Louis enterprises that still had a large COBOL footprint (AB, Enterprise Rent-A-Car, Caterpillar, et al). By 2010, though, Express Scripts was trying hard to move away from its ANCHOR (COBOL) system and whatever-it-was-they-had running on VMS, and it sure felt like in the early 2010s STL was mostly Java EE. I would think that FORTRAN is likelier to be passed around as folk wisdom and ancient PIs (uh, Primary Investigators, not the detective kind) thrusting a dog-eared FORTRAN IV manual at their new grad students and snarling "RTFM!" than as actual college courses. That said, if you want to learn FORTRAN and don't mind working from modern FORTRAN back, I really was impressed by https://lfortran.org/ , and the ability to run it in a JupyterLab playground environment is fantastic for quick-turnaround experimentation. Plus Ondřej Čertík was fun to talk to and hang out with. On Mon, Feb 24, 2020 at 8:19 AM Larry McVoy wrote: > On Mon, Feb 24, 2020 at 10:40:10AM +0100, Sijmen J. Mulder wrote: > > Larry McVoy wrote: > > > Fortran programmers are formally trained (at least I > > > was, there was a whole semester devoted to this) in accumulated errors. > > > You did a deep dive into how to code stuff so that the error was > reduced > > > each time instead of increased. It has a lot to do with how floating > > > point works, it's not exact like integers are. > > > > I was unaware that there's formal training to be had around this but > > it's something I'd like to learn more about. Any recommendations on > > materials? I don't mind diving into Fortran itself either. > > My training was 35 years ago, I have no idea where to go look for this > stuff now. I googled and didn't find much. I'd go to the local > University that teaches Fortran and ask around. > _______________________________________________ > 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 Tue Feb 25 02:15:46 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Feb 2020 11:15:46 -0500 Subject: [TUHS] [COFF] Fwd: Old and Tradition was V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: First please continue this discussion on COFF (which has been CC'ed). While Fortran is interesting to many, it not a UNIX topic per say. Also, as I have noted in other places, I work for Intel - these comments are my own and I'm not trying to sell you anything. Just passing on 45+ years of programming experience. On Mon, Feb 24, 2020 at 10:34 AM Adam Thornton wrote: > I would think that FORTRAN is likelier to be passed around as folk wisdom > and ancient PIs (uh, Primary Investigators, not the detective kind) > thrusting a dog-eared FORTRAN IV manual at their new grad students and > snarling "RTFM!" than as actual college courses. > FWIW: I was at CMU last week recruiting. Fortran, even at a leading CS place like CMU, is hardly "folk wisdom". All the science PhD's (Chem, Mat Sci, Bio, Physics) that I interviewed all knew and used Fortran (nad listed on their CV's) as their primary language for their science. As I've quipped before, Fortran pays my own (and a lot of other people's salaries in the industry). Check out: https://www.archer.ac.uk/status/codes/ Fortran is about 90% of the codes running (FWIW: I have seen similar statistics from other large HPC sites - you'll need to poke). While I do not write in it, I believe there are three reasons why these statistics are true and* going to be true for a very long time*: 1. The math being used has not changed. Just open up the codes and look at what they are doing. You will find that they all are all solving systems of partial differential equations using linear algebra (-- see the movie: "Hidden Figures"). 2. 50-75 years of data sets with know qualities and programs to work with them. If you were able to replace the codes magically with something 'better' - (from MathLab to Julia or Python to Java) all their data would have to be requalified (it is like the QWERTY keyboard - that shipped sailed years ago). 3. The *scientists want to do their science* for their work to get their degree or prize. The computer and its programs *are a tool* for them look at data *to do their science*. They don't care as long as they get their work done. Besides Adam's mention of flang, there is, of course, gfortran; but there are also commerical compilers available for use: Qualify for Free Software | Intel® Software I believe PGI offers something similar, but I have not checked in a while. Most 'production' codes use a real compiler like Intel, PGI or Cray's. FWIW: the largest number of LLVM developers are at Intel now. IMO, while flang is cute, it will be a toy for a while, as the LLVM IL really can not handle Fortran easily. There is a huge project to put a number of the learnings from the DEC Gem compilers into LLVM and one piece is gutting the internal IL and making work for parallel architectures. The >>hope<< by many of my peeps, (still unproven) is that at some point the FOSS world will produce a compiler as good a Gem or the current Intel icc/ifort set. (Hence, Intel is forced to support 3 different compiler technologies internally in the technical languages group). -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Feb 25 02:19:33 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 24 Feb 2020 11:19:33 -0500 Subject: [TUHS] [COFF] Fwd: Old and Tradition was V9 shell In-Reply-To: References: <20200212030152.GJ852@mcvoy.com> <20200224104010.2d8510cfe00da71439f5d05e@sjmulder.nl> <20200224151929.GJ30841@mcvoy.com> Message-ID: I probably should have added, it's not just the learnings from DEC Gem folks, but also the old "Kuck and Associates" team formerly in Champaign (Intel moved them all to Austin). On Mon, Feb 24, 2020 at 11:15 AM Clem Cole wrote: > > First please continue this discussion on COFF (which has been CC'ed). > While Fortran is interesting to many, it not a UNIX topic per say. > > Also, as I have noted in other places, I work for Intel - these comments > are my own and I'm not trying to sell you anything. Just passing on 45+ > years of programming experience. > > On Mon, Feb 24, 2020 at 10:34 AM Adam Thornton > wrote: > >> I would think that FORTRAN is likelier to be passed around as folk wisdom >> and ancient PIs (uh, Primary Investigators, not the detective kind) >> thrusting a dog-eared FORTRAN IV manual at their new grad students and >> snarling "RTFM!" than as actual college courses. >> > FWIW: I was at CMU last week recruiting. Fortran, even at a leading CS > place like CMU, is hardly "folk wisdom". All the science PhD's (Chem, Mat > Sci, Bio, Physics) that I interviewed all knew and used Fortran (nad listed > on their CV's) as their primary language for their science. > > As I've quipped before, Fortran pays my own (and a lot of other people's > salaries in the industry). Check out: > https://www.archer.ac.uk/status/codes/ Fortran is about 90% of the codes > running (FWIW: I have seen similar statistics from other large HPC sites > - you'll need to poke). > > While I do not write in it, I believe there are three reasons why these > statistics are true and* going to be true for a very long time*: > > 1. The math being used has not changed. Just open up the codes and > look at what they are doing. You will find that they all are all solving > systems of partial differential equations using linear algebra (-- see the > movie: "Hidden Figures"). > 2. 50-75 years of data sets with know qualities and programs to work > with them. If you were able to replace the codes magically with something > 'better' - (from MathLab to Julia or Python to Java) all their data would > have to be requalified (it is like the QWERTY keyboard - that shipped > sailed years ago). > 3. The *scientists want to do their science* for their work to get > their degree or prize. The computer and its programs *are a tool* > for them look at data *to do their science*. They don't care as long > as they get their work done. > > > Besides Adam's mention of flang, there is, of course, gfortran; but there > are also commerical compilers available for use: Qualify for Free > Software | Intel® Software > I > believe PGI offers something similar, but I have not checked in a while. > Most 'production' codes use a real compiler like Intel, PGI or Cray's. > > FWIW: the largest number of LLVM developers are at Intel now. IMO, > while flang is cute, it will be a toy for a while, as the LLVM IL really > can not handle Fortran easily. There is a huge project to put a number of > the learnings from the DEC Gem compilers into LLVM and one piece is gutting > the internal IL and making work for parallel architectures. The >>hope<< > by many of my peeps, (still unproven) is that at some point the FOSS world > will produce a compiler as good a Gem or the current Intel icc/ifort set. > (Hence, Intel is forced to support 3 different compiler technologies > internally in the technical languages group). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Feb 25 08:28:52 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 25 Feb 2020 09:28:52 +1100 (EST) Subject: [TUHS] Crabs In-Reply-To: <22d064af4a08c57b11c2a632d908e766@inventati.org> References: <22d064af4a08c57b11c2a632d908e766@inventati.org> Message-ID: On Mon, 24 Feb 2020, Finn O'Leary wrote: >> There were lots of similar programs springing up around that time, >> such as "xoj" (modelled after the famous O.J. Simpson car chase) etc. > > A version of this that still compiles on modern systems can be found here :) > http://www.daidouji.com/oneko/ > > It has a couple of settings to change the icons to various different > characters Thanks! -- Dave From wkt at tuhs.org Fri Feb 28 09:31:34 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 28 Feb 2020 09:31:34 +1000 Subject: [TUHS] First COFF Video Session in ~22 hours Message-ID: <20200227233134.GA26401@minnie.tuhs.org> All, I've had a few queries about the proposed video chat sessions, so I'll kick the first one off tomorrow: UTC Brisbane London New York Friday, 28 Feb 2020 at 21:00 Sat 7:00am Fri 9:00pm Fri 4:00 pm I'll only be able to stay for an hour but the chat session should continue when I've gone. URL: https://meet.tuhs.org/COFF Password: unix Cheers, Warren